My first compiler bug: work around or redesign?

My first compiler bug: work around or redesign?

[Natasha Kerensikova]

Hello,

I happen to have encountered my very first compiler bug, or at least
something that claims to be in the following message:

+===========================GNAT BUG DETECTED==============================+
| 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134                  |
| Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
+==========================================================================+

So my first question is, would anyone be kind enough to try and
reproduce that bug?  The files involved are available individually at
http://fossil.instinctive.eu/dressup/dir?ci=bf54531f8dcf7117
or as a tarball at
http://fossil.instinctive.eu/dressup/tarball/Dressup-bf54531f8dcf7117.tar.gz?uuid=bf54531f8dcf71174ccb486812b886701222c342

The reason is that I'm using gnat AUX, derived from gcc 4.6.2, so it's
both unofficial and old (IIRC tasking in FreeBSD 9 is preventing the
next one from being available). It's difficult to create a new building
environment, so I would like to be sure it's really a bug before setting
out to make a minimalistic test case and reporting it.

I guess the problem somehow involves generics:
Dressup.Parsers is a generic package; so Dressup.Parsers.Markdown is
generic too, despite adding no further formal parameter.
markdown.adb:32:4 is the instantiation of Dressup.Parsers.Markdown (off
an instance of Dressup.Parsers instantiated on the line before).
dressup-parsers-markdown.adb:1651:7 is an instantiation of a subprogram
whose specification is at dressup-parsers-markdown.adb:184:4.

Could the issue be caused by having a generic instance inside a generic
instance inside a generic instance? Or is gnat supposed to handle well
such a level of nesting?



All this led me to question my approach and design and programming
practices, so that if I have to rewrite something to work around the
compiler bug, I can rewrite better.

So my first "best practices" question is about using generic subprograms
confined inside a package body. Here is a brutally-simplified version of
what is reported in the compiler bug message:

package Stuff is
   procedure Ordered_List (<some set of parameters);
   procedure Unordered_List (<the same set of parameters);
end Stuff;

package body Stuff is
   generic
      with Prefix (Line : String) return Natural;
   procedure Generic_List (<same set of parameters as previously>);

   function Ordered_Prefix (Line : String) return Natural;
   function Unordered_Prefix (Line : String) return Natural;

   -- subprogram bodies here

   procedure Ordered_List_Instance is new Generic_List (Ordered_Prefix);

   procedure Ordered_List (<same set of parameters as in the spec>)
      renames Oredered_List_Instance;

   procedure Unordered_List_Instance is new Generic_List (Unordered_Prefix);

   procedure Unordered_List (<same set of parameters as in the spec>)
      renames Unordered_List_Instance;

end Stuff;

The rationale here is that Ordered_List and Unordered_List are meant to
be completely independent, so they are presented in the specification as
being completely unrelated.

However, at implementation level, it turns out that they are very
similar: only the prefix recognition change, and further processing is
perfectly identical. So instead of cut-and-pasting code, I would write a
generic that handles all the common aspects, using a formal function for
the prefix part.

Is there something wrong with that approach?
Are there some caveat that I missed?
Are there advantages in avoiding the generics in that situation, for
example using a non-generic common function that takes an
access-to-subprogram extra parameter?

And as a tangential question, could anyone explain me why the "renames"
are required? How come a generic instantiation cannot provide a body for
a publicly-specified subprogram?




And the last part of the message here is about the general design of the
library. I have ended up using a lot of generics and access to
subprograms, but no tagged types (actually some types are tagged, but
only for future expansions, none of the code written here use any tagged
type feature).

I would understand anyone skipping that part of the discussion, but any
constructive comment will be appreciated (though not necessarily acted
upon).

The initial problem I was set out to solve was converting markdown into
HTML, but with enough modularity so that I can convert markdown into PDF
without changing the "markdown" part (that I call "parser", I hope I got
the word right), or convert creole into HTML without changing the "HTML"
part (that I call "renderer"). And as an extra requirement, I want
features of a parser to be easily and individually turned off (e.g.
removing the raw HTML inclusion in markdown for untrusted sources, or
removing the "wiki link" feature of creole where it is used outside of a
wiki).

In my previous iteration of markdown-to-HTML code (in C), I found that
a usable description of a renderer is a bunch of callbacks that operate
on the same shared state.

So for my Ada library, I decided to describe a renderer as a state
object and a set of accesses to procedure. The idea being that each
procedure renders a particular element (e.g. an ordered list, and the
callback for HTML would output "<ol>", the contents and "</ol>").
Language elements without a renderer callback are considered as
disabled.

That way, the renderer does not need to know anything about the parser,
and the parser only handles callbacks and an opaque, so it is also
independent from any particular renderer. Only the client has to care
about both the particular renderer and the particular parser in use.

I went for access to subprogram rather than a tagged type for element
renderers to ensure that all callbacks do share the same state, since in
the tagged type version each element renderer object would have its own
state (presumably referring to some shared state like the output
string or stream), there would then be no compile-time guarantee that
all renderer elements indeed belong to the same renderer. A client who
mistakenly mixes callbacks and ends up with a set of callbacks referring
to one state and another set referring to another, would have no
indication of their mistake before seeing garbage at run time.

Moreover, using dynamic dispatching of tagged type instead of access to
subprogram would mean storing somewhere object of a class-wide type,
i.e. indefinite. So it would mean extra complications like holders
objects, which make the program harder to read and to understand.
These drawbacks without benefit (unless I'm missing something) was
enough for me to rule out the option.

I then proceeded to write the (X)HTML renderer. While thinking about the
implementation, I realized that I would only need to append string
fragments. So I wrote it as a generic package, with an Accumulator
formal type and an Append procedure. Again it looked much simpler than
using an approach based on tagged type (and interfaces), but this time
en client side rather than on library side: Unbounded_String are bundled
with an Append procedure that fits perfectly, streams might be useful
out of box if String'Write can be used directly for Append. With a
interfaces, the client would have to maintain a wrapper around
Unbounded_String or streams or whatever accumulator they re-use, and it
feels to me like unnecessary clutter. Moreover it seems possible and
relatively simple to instance the generic markdown renderer with an
interface type, while the advantages of the generic version seem out of
reach of a version based on interfaces.

With this representation of renderers, I started shaping the parser with
a generic ancestor package Dressup.Parsers, that only defines the type
Element_Renderer used for the callbacks.

The extra genericity and accesses to subprograms of
Dressup.Parsers.Lexers follows the same rationale as for renderers.

I think that covers all the debatable choices, though if you feel like
discussion another one, feel free to do so.



Thanks a lot in advance for your helpful insights,
Natasha

Re: My first compiler bug: work around or redesign?

[Ludovic Brenta]

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> Hello,
>
> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:
>
> +===========================GNAT BUG DETECTED==============================+
> | 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134                  |
> | Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|

This seems similar to http://gcc.gnu.org/PR43806, the workaround for
which is not to use -gnatE.  Were you compiling with -gnatE?

> So my first question is, would anyone be kind enough to try and
> reproduce that bug?  The files involved are available individually at
> http://fossil.instinctive.eu/dressup/dir?ci=bf54531f8dcf7117
> or as a tarball at
> http://fossil.instinctive.eu/dressup/tarball/Dressup-bf54531f8dcf7117.tar.gz?uuid=bf54531f8dcf71174ccb486812b886701222c342

I'll try later if I find the time :/

-- 
Ludovic Brenta.

Re: My first compiler bug: work around or redesign?

[Jeffrey Carter]

On 03/23/2012 09:29 AM, Natasha Kerensikova wrote:
>
> However, at implementation level, it turns out that they are very
> similar: only the prefix recognition change, and further processing is
> perfectly identical. So instead of cut-and-pasting code, I would write a
> generic that handles all the common aspects, using a formal function for
> the prefix part.
>
> Is there something wrong with that approach?
> Are there some caveat that I missed?
> Are there advantages in avoiding the generics in that situation, for
> example using a non-generic common function that takes an
> access-to-subprogram extra parameter?

There's nothing wrong with that approach. I've used it successfully many times.

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: My first compiler bug: work around or redesign?

[Jeffrey Carter]

On 03/23/2012 09:29 AM, Natasha Kerensikova wrote:
>
> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:
>
> +===========================GNAT BUG DETECTED==============================+
> | 4.6.2 20111026 (release) -=>  GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134                  |
> | Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
> | Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
> | Use a subject line meaningful to you and us to track the bug.            |
> | Include the entire contents of this bug box in the report.               |
> | Include the exact gcc or gnatmake command that you entered.              |
> | Also include sources listed below in gnatchop format                     |
> | (concatenated together with no headers between files).                   |
> +==========================================================================+
>
> So my first question is, would anyone be kind enough to try and
> reproduce that bug?  The files involved are available individually at
> http://fossil.instinctive.eu/dressup/dir?ci=bf54531f8dcf7117
> or as a tarball at
> http://fossil.instinctive.eu/dressup/tarball/Dressup-bf54531f8dcf7117.tar.gz?uuid=bf54531f8dcf71174ccb486812b886701222c342

I get:

jrcarter@jrcarter-gateway-1:~/Code/Natasha/Dressup-bf54531f8dcf7117$ gnatmake -p 
-P markdown.gpr
object directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/obj" created
exec directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/bin" created
gcc-4.4 -c -gnatafnovy -gnateE -gnatwae -fstack-check -O3 -I- -gnatA 
/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb
gnat1: invalid switch: -gnateE
gnatmake: "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb" 
compilation error

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Re: My first compiler bug: work around or redesign?

[Simon Wright]

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:
>
> +===========================GNAT BUG DETECTED==============================+
> | 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|

If you get a bug box, it's a compiler error!

Same (barring line number in decl.c) on Mac OS X with GCC 4.6.0 and GCC
4.8.0 20120314 (experimental) [trunk revision 185379].

Re: My first compiler bug: work around or redesign?

[Dmitry A. Kazakov]

On Fri, 23 Mar 2012 16:29:06 +0000 (UTC), Natasha Kerensikova wrote:

> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message

First, make sure your code is legal. In some cases GNAT crashes when
detects an error in the program. One method to find the problem is to
comment offending source code lines until it compiles and then twist it
this or that way.

> I guess the problem somehow involves generics:

Yep,  there are always problems with generics in GNAT, usually related to
visibility. Use renaming/subtyping of the formal parameters. This might
help to work around bugs.

...
I think AdaCore should drop the current model and redesign generics from
scratch allowing sharing the bodies. The model is not only buggy. It makes
compilation painfully slow, consuming unreasonably huge amounts of memory
(3GB+).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: My first compiler bug: work around or redesign?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> First, make sure your code is legal. In some cases GNAT crashes when
> detects an error in the program. One method to find the problem is to
> comment offending source code lines until it compiles and then twist it
> this or that way.

It's easier to use the -gnatdO switch, which is documented
in debug.adb.

- Bob

Re: My first compiler bug: work around or redesign?

[Jeffrey Carter]

On 03/23/2012 09:29 AM, Natasha Kerensikova wrote:
>
> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:
>
> +===========================GNAT BUG DETECTED==============================+
> | 4.6.2 20111026 (release) -=>  GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134                  |
> | Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
> | Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
> | Use a subject line meaningful to you and us to track the bug.            |
> | Include the entire contents of this bug box in the report.               |
> | Include the exact gcc or gnatmake command that you entered.              |
> | Also include sources listed below in gnatchop format                     |
> | (concatenated together with no headers between files).                   |
> +==========================================================================+
>
> So my first question is, would anyone be kind enough to try and
> reproduce that bug?  The files involved are available individually at
> http://fossil.instinctive.eu/dressup/dir?ci=bf54531f8dcf7117
> or as a tarball at
> http://fossil.instinctive.eu/dressup/tarball/Dressup-bf54531f8dcf7117.tar.gz?uuid=bf54531f8dcf71174ccb486812b886701222c342

I get:

jrcarter@jrcarter-gateway-1:~/Code/Natasha/Dressup-bf54531f8dcf7117$ gnatmake -p 
-P markdown.gpr
object directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/obj" created
exec directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/bin" created
gcc-4.4 -c -gnatafnovy -gnateE -gnatwae -fstack-check -O3 -I- -gnatA 
/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb
gnat1: invalid switch: -gnateE
gnatmake: "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb" 
compilation error

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Re: My first compiler bug: work around or redesign?

[Natasha Kerensikova]

On 2012-03-23, Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
> Natasha Kerensikova <lithiumcat@gmail.com> writes:
>
>> Hello,
>>
>> I happen to have encountered my very first compiler bug, or at least
>> something that claims to be in the following message:
>>
>> +===========================GNAT BUG DETECTED==============================+
>> | 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
>> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134                  |
>> | Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
>
> This seems similar to http://gcc.gnu.org/PR43806, the workaround for
> which is not to use -gnatE.  Were you compiling with -gnatE?

No, there is no gnatE in my gpr file. I haven't seen any way of
overriding it should it be somehow on by default.

I do have -gnateE though, but as far as I can tell it's completely
unrelated.

Just as a double-check, I tried compling with -gnatE and/or without
-gnateE, but it did not change anything in the compiler output.


Thanks for your help,
Natasha

Re: My first compiler bug: work around or redesign?

[Natasha Kerensikova]

On 2012-03-23, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
>> So my first question is, would anyone be kind enough to try and
>> reproduce that bug?  The files involved are available individually at
>> http://fossil.instinctive.eu/dressup/dir?ci=bf54531f8dcf7117
>> or as a tarball at
>> http://fossil.instinctive.eu/dressup/tarball/Dressup-bf54531f8dcf7117.tar.gz?uuid=bf54531f8dcf71174ccb486812b886701222c342
>
> I get:
>
> jrcarter@jrcarter-gateway-1:~/Code/Natasha/Dressup-bf54531f8dcf7117$ gnatmake -p 
> -P markdown.gpr
> object directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/obj" created
> exec directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/bin" created
> gcc-4.4 -c -gnatafnovy -gnateE -gnatwae -fstack-check -O3 -I- -gnatA 
> /home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb
> gnat1: invalid switch: -gnateE
> gnatmake: "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb" 
> compilation error

Could you please try without -gnateE switch (removing line 32 from
markdown.gpr)? It has been shown to be irrelevant for the error.


Thanks for your help,
Natasha

Re: My first compiler bug: work around or redesign?

[Natasha Kerensikova]

On 2012-03-23, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Fri, 23 Mar 2012 16:29:06 +0000 (UTC), Natasha Kerensikova wrote:
>
>> I happen to have encountered my very first compiler bug, or at least
>> something that claims to be in the following message
>
> First, make sure your code is legal. In some cases GNAT crashes when
> detects an error in the program. One method to find the problem is to
> comment offending source code lines until it compiles and then twist it
> this or that way.

I tried that method, until there was so much to remove that nothing made
sense anymore. As far as I can tell, any "local" generic instantiation
in that package triggers the compiler error.

Surprisingly (at least for me), the error is triggered on the first
instantiation, even though the message reports the declaration location
first and then only the instantiation location.

>> I guess the problem somehow involves generics:
>
> Yep,  there are always problems with generics in GNAT, usually related to
> visibility. Use renaming/subtyping of the formal parameters. This might
> help to work around bugs.

I don't really understand how visibility comes into play here, since
declaration, body and instantiation all reside in the same package body.
However I admit that compiler writing is arcane enough to lead to
unintuitive situation, but such a flat single isolated namespace should
be the easiest to deal with.


Thanks for your help,
Natasha

Re: My first compiler bug: work around or redesign?

[Natasha Kerensikova]

On 2012-03-23, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> First, make sure your code is legal. In some cases GNAT crashes when
>> detects an error in the program. One method to find the problem is to
>> comment offending source code lines until it compiles and then twist it
>> this or that way.
>
> It's easier to use the -gnatdO switch, which is documented
> in debug.adb.

I tried compiling my code with that extra flag, and I got exactly the
same error output.

I don't know really know what conclusion to draw from there.
Documentation says it makes the compiler fail faster, I guess minimizing
the surface for potential other errors.

Anyway, I tend to believe my code to be legal, since it's very close to
the previous version that did compile and run correctly. But then again,
even small differences can affect legality...



Thanks for your help,
Natasha

Re: My first compiler bug: work around or redesign?

[Jeffrey Carter]

On 03/23/2012 02:23 PM, Natasha Kerensikova wrote:
>
> Could you please try without -gnateE switch (removing line 32 from
> markdown.gpr)? It has been shown to be irrelevant for the error.

jrcarter@jrcarter-gateway-1:~/Code/Dressup-bf54531f8dcf7117$ gnatmake -p -P markdown
object directory "/home/jrcarter/Code/Dressup-bf54531f8dcf7117/obj" created
exec directory "/home/jrcarter/Code/Dressup-bf54531f8dcf7117/bin" created
gcc-4.4 -c -gnatafnovy -gnatwae -fstack-check -O3 -I- -gnatA 
/home/jrcarter/Code/Dressup-bf54531f8dcf7117/markdown.adb

GNAT 4.4.6
Copyright 1992-2008, Free Software Foundation, Inc.

Compiling: /home/jrcarter/Code/Dressup-bf54531f8dcf7117/markdown.adb (source 
file time stamp: 2012-03-20 12:29:06)
  138 lines: No errors

raised STORAGE_ERROR : stack overflow (or erroneous memory access)
gnatmake: "/home/jrcarter/Code/Dressup-bf54531f8dcf7117/markdown.adb" 
compilation error

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Re: My first compiler bug: work around or redesign?

[Georg Bauhaus]

On 23.03.12 22:40, Natasha Kerensikova wrote:
> On 2012-03-23, Robert A Duff<bobduff@shell01.TheWorld.com>  wrote:
>> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  writes:
>>
>>> First, make sure your code is legal. In some cases GNAT crashes when
>>> detects an error in the program. One method to find the problem is to
>>> comment offending source code lines until it compiles and then twist it
>>> this or that way.
>>
>> It's easier to use the -gnatdO switch, which is documented
>> in debug.adb.
>
> I tried compiling my code with that extra flag, and I got exactly the
> same error output.
>
> I don't know really know what conclusion to draw from there.

A bug seems present, with or without switches, in GNAT GPL 2011/Mac, too.

+===========================GNAT BUG DETECTED==============================+
| GPL 2011 (20110419) (x86_64-apple-darwin10.2.0) GCC error:               |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4121                  |
| Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|

 From the looks of it, it seems there is a probability that
the bug is related to passing information between GNAT
and other parts of GCC. The rest is speculation by mere mortals :-)


I worked around by adding switch -gnat95 and then mechanically following
the compiler's complaints. Less than I did might do the trick, though,
with GNAT at least, or any compiler that accepts Ada 2005 from the RTS in
Ada 95 programs.

http://home.arcor.de/bauhaus/Ada/Dressup-bf54531f8dcf7117.diff

(A huge fraction of the patch is just syntax.)


I have let warnings about Ada.Containers (being 2005) be warnings.
The same relaxed attitude might work with GNAT and the new Strings.Fixed,
the one with the From parameter.

I seem not to have changed the generics part which you have been mentioning.
Moreover, I have added generics where procedures such as Iterate require
anonymous subprogram pointers now---no fancy downwards closures needed
here, though, and simple instantiations would do.

The resulting executable bin/markdown does output HTML for
*, \n==, etc., but I'm not sure that I have been sufficiently meticulous.
(Is bin/markdown supposed to successfully run a test suite yet?
I found test cases in something called MarkdownTest_1.0.zip,
which has a driver program written in Perl in it. I haven't used
it directly, but fed Tests/Tabs.text from this distribution
to bin/markdown and compared the results, just to see if I hadn't
messed up).

Re: My first compiler bug: work around or redesign?

[Natasha Kerensikova]

On 2012-03-24, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:
> A bug seems present, with or without switches, in GNAT GPL 2011/Mac, too.
>
> +===========================GNAT BUG DETECTED==============================+
>| GPL 2011 (20110419) (x86_64-apple-darwin10.2.0) GCC error:               |
>| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4121                  |
>| Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
>
>  From the looks of it, it seems there is a probability that
> the bug is related to passing information between GNAT
> and other parts of GCC. The rest is speculation by mere mortals :-)

According to you and Simon Wright, it seems useful to report this bug
then. Now I just have to figure out to who and how, and maybe work out a
minimal test case.

I still have trouble interpreting Jeffrey Carter's results though.

> I worked around by adding switch -gnat95 and then mechanically following
> the compiler's complaints. Less than I did might do the trick, though,
> with GNAT at least, or any compiler that accepts Ada 2005 from the RTS in
> Ada 95 programs.
>
> http://home.arcor.de/bauhaus/Ada/Dressup-bf54531f8dcf7117.diff
>
> (A huge fraction of the patch is just syntax.)

Thanks a lot, I will try to study that patch. I'm still surprised
2005 vs 95 can have something to do with it.

> The resulting executable bin/markdown does output HTML for
> *, \n==, etc., but I'm not sure that I have been sufficiently meticulous.
> (Is bin/markdown supposed to successfully run a test suite yet?
> I found test cases in something called MarkdownTest_1.0.zip,
> which has a driver program written in Perl in it. I haven't used
> it directly, but fed Tests/Tabs.text from this distribution
> to bin/markdown and compared the results, just to see if I hadn't
> messed up).

It is supposed to almost pass the test. It's a redesign from a
previous-working but (IMHO) ugly version, available at
http://fossil.instinctive.eu/dressup/info/de3a2cbc2d

Specifically, the "known failures", that I consider as "won't fix" are:
  - I don't add an extra end-of-line when the file does not end with
    one, but that only makes a difference in code blocks, with
    </code></pre> being at the end of the line vs on the next line.
  - I don't render empty href attributes, so there is a <a>stuff</a>
    vs <a href="">stuff</a>.
  - I don't remove spaces in a line that only contain them, again that
    is only significant in code blocks (in
    "Markdown Documentation - Basics.text" there is a code block with
    two lines containing only 8 spaces, 4 of them are removed as the
    code block marker, and the remaining 4 are output, while the
    reference HTML has a spaceless empty line instead).



Thanks again for your help,
Natasha

Re: My first compiler bug: work around or redesign?

[Natasha Kerensikova]

Hello,

On 2012-03-23, Natasha Kerensikova <lithiumcat@gmail.com> wrote:
> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:

There is a new development in the situation, and would love to have your
collective opinion about what to do next.

It turns out that simply replacing all occurrences of
"in not null Element_Renderer" by "in Element_Renderer" is enough to
make compilation succeed (and the binary does pass the Markdown test
suite, except for the known little differences I detailed in my previous
post).

Thanks a lot to Georg Bauhaus for the Ada-95-ification patch, which
contained a lot of "not null" removal. Combined with a look in
gnat_to_gnu_entity source (barely enough to understand the assertion
fails because of something about the type of an argument), it led me to
try this.



Here is the context I think relevant.

The type involved is Element_Renderer, defined as:

   type Element_Renderer is access procedure
     (State : in out Renderer_State_Type;
      Actions : in Render_Action_Set;
      Parameters : in Parameter_Map;
      Contents : in String);

where Renderer_State is an unconstrained limited private formal type,
Render_Action_Set and Parameter_Map are definite normal types defined in
a parent package.

The type is used by the parser to retrieve renderer callback provided by
the client. A null value is used as default to indicate no renderer
(but NOT no rendering) thus disabling the language element.

Somewhere in parser internals I use another kind of callbacks, that I
call lexers (but I'm not completely sure I use the word with its correct
meaning, though it does refer to code that find token start and end in a
given String). These callbacks match the following type:

   type Element_Lexer is
      access procedure
        (State : in out Lexer_State_Type;
         Source : String;
         Position : in out Positive;
         Renderer : in not null Element_Renderer;
         Renderer_State : in out Renderer_State_Type;
         Render_Param : in out Parameter_Map);

At this point, it does not make sense for Renderer to be null, because
as explained above, a null value would have disabled the element and the
Element_Lexer would never be called. So I added the "not null"
constrained.

I have to admit I don't really master everything about anonymous access
types and stuff like that, I thought that "not null Element_Renderer"
would be a subtype of Element_Renderer just like
"Natural range 1 .. Natural'Last" would be a subtype of Natural. But
maybe I'm creating an access type out of nowhere or something like that.

So to make my code compile successfully, it's enough to remove the
"not null" in Element_Lexer declaration and in all the matching
procedure from Dressup.Parsers.Markdown.



So now, the questions.

Does it make sense to use "not null" in such a way?
That is, if the bug did not exist, would my code be better off with it
or without it?

Is it really worth reporting? Thinking about it, I'm not even sure my
code is actually legal: could "not null Element_Renderer" be illegal but
previously interpreted correctly because of a fluke? Or should it be
accepted?

And assuming I should report it, how to so? AdaCore seemed the best
starting point, but their website isn't exactly straightforward on how
to be send bug reports. Is there anything better than
http://libre.adacore.com/libre/contact/  ?



Thanks for your insights,
Natasha

Re: My first compiler bug: work around or redesign?

[Simon Wright]

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> Is it really worth reporting? Thinking about it, I'm not even sure my
> code is actually legal: could "not null Element_Renderer" be illegal
> but previously interpreted correctly because of a fluke? Or should it
> be accepted?

I think (and ISTR AdaCore making a similar point) that _any_ bug box
ought to be reported; if the code is wrong it should trigger a sensible
error message.

Re: My first compiler bug: work around or redesign?

[Ludovic Brenta]

Natasha Kerensikova wrote on comp.lang.ada:
> Is it really worth reporting?

Yes, especially if you can craft a small reproducer exposing the bug box.
Now that you know that "not null Named_Access_Type" triggers the bug, that
should be easy.  You've done the hardest part.

> Thinking about it, I'm not even sure my
> code is actually legal: could "not null Element_Renderer" be illegal but
> previously interpreted correctly because of a fluke? Or should it be
> accepted?

IIUC, "not null Element_Renderer" is legal in Ada 2005 and does not
create an anonymous type.  In Ada 95, anonymous types are implicitly
"not null" but named access types are implicitly "null" (i.e. "possibly
null") and there is no way to make them "not null".

> And assuming I should report it, how to so? AdaCore seemed the best
> starting point, but their website isn't exactly straightforward on how
> to be send bug reports. Is there anything better than
> http://libre.adacore.com/libre/contact/  ?

Report it to the FSF at http://gcc.gnu.org/bugzilla. IMHO, a public bug
database is worth a thousand private ones.

-- 
Ludovic Brenta.
The project manager deploys scalable Management Information Systems
reaped from our measured efficiency gain.

Re: My first compiler bug: work around or redesign?

[Georg Bauhaus]

On 26.03.12 20:15, Natasha Kerensikova wrote:

> Somewhere in parser internals I use another kind of callbacks, that I
> call lexers (but I'm not completely sure I use the word with its correct
> meaning, though it does refer to code that find token start and end in a
> given String). These callbacks match the following type:
>
>     type Element_Lexer is
>        access procedure
>          (State : in out Lexer_State_Type;
>           Source : String;
>           Position : in out Positive;
>           Renderer : in not null Element_Renderer;
>           Renderer_State : in out Renderer_State_Type;
>           Render_Param : in out Parameter_Map);
>
> At this point, it does not make sense for Renderer to be null, because
> as explained above, a null value would have disabled the element and the
> Element_Lexer would never be called. So I added the "not null"
> constrained.

Looks quite right to me to say "not null" when a parameter shouldn't
be null.  If this condition is checked at compile time, it avoids
the embarrassment that potential null pointers can cause :-) For ease
of software maintenance (in the presence of bugs in the compiler), one
might also define a null excluding subtype.  The workaround is
then easily turned on and off in the single declaration in case there
are more occurrences of "not null Element_Renderer".  Don't know if the
immediate presence of "not null" would be stylistically preferable,
on the other hand.

    subtype Valid_Element_Renderer is not null Element_Renderer;

(I have chosen Valid_ just to have a name for the subtype, with no
aspiration to quality of naming.)


> Is it really worth reporting?

Yes. An observable bug is a bug, whatever the laws are.

Re: My first compiler bug: work around or redesign?

[Per Sandberg]

Any way it is reported.

Re: My first compiler bug: work around or redesign?

[Dmitry A. Kazakov]

On Mon, 26 Mar 2012 23:47:17 +0200, Georg Bauhaus wrote:

> Looks quite right to me to say "not null" when a parameter shouldn't
> be null.

Yes.

From usability point of view it is better to use an anonymous type for a
procedures meant to be a downward closure. This is the most close
approximation to passing a procedure as a parameter (missing in Ada).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: My first compiler bug: work around or redesign?

[Natasha Kerensikova]

On 2012-03-26, Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
> Report it to the FSF at http://gcc.gnu.org/bugzilla. IMHO, a public bug
> database is worth a thousand private ones.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52752

Below is the minimal testcase I have worked out.

Is there anything I should do at this point? Or will everything leading
to a fix be handled from there?

Thanks for your help,
Natasha




package Test is

   type Callback is access procedure (State : in String);

   procedure Sample
     (State : in String;
      Action : in not null Callback);

end Test;

package body Test is

   procedure Simple_Init;

   generic
      with procedure Init;
   procedure Generic_Sample
     (State : in String;
      Action : in not null Callback);



   procedure Simple_Init is
   begin
      null;
   end Simple_Init;


   procedure Generic_Sample
     (State : in String;
      Action : in not null Callback) is
   begin
      Init;
      Action.all (State);
   end Generic_Sample;


   procedure Sample_Instance is new Generic_Sample (Simple_Init);

   procedure Sample
     (State : in String;
      Action : in not null Callback)
      renames Sample_Instance;

end Test;

with Ada.Text_IO;
with Test;

procedure Testcase is
   State : constant String := "Testcase";
begin
   Test.Sample (State, Ada.Text_IO.Put_Line'Access);
end Testcase;

Re: My first compiler bug: work around or redesign?

[Ludovic Brenta]

Natasha Kerensikova wrote on comp.lang.ada:
> Ludovic Brenta wrote:
>> Report it to the FSF at http://gcc.gnu.org/bugzilla. IMHO, a public bug
>> database is worth a thousand private ones.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52752
> 
> Below is the minimal testcase I have worked out.
> 
> Is there anything I should do at this point? Or will everything leading
> to a fix be handled from there?

Just wait for someone to fix the bug and then consider backporting
the fix into your distribution's version of GNAT.

But Per Sandberg wrote the day before on comp.lang.ada:
> Any way it is reported.

which pointed me to http://gcc.gnu.org/PR52735

So you should indicate that your bug is a duplicate with a more
minimal test case.

-- 
Ludovic Brenta.

Re: My first compiler bug: work around or redesign?

[onox]

On Mar 29, 10:25 am, Ludovic Brenta <ludo...@ludovic-brenta.org>
wrote:
> Natasha Kerensikova wrote on comp.lang.ada:
>
> > Ludovic Brenta wrote:
> >> Report it to the FSF athttp://gcc.gnu.org/bugzilla. IMHO, a public bug
> >> database is worth a thousand private ones.
>
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52752
>
> > Below is the minimal testcase I have worked out.
>
> > Is there anything I should do at this point? Or will everything leading
> > to a fix be handled from there?
>
> Just wait for someone to fix the bug and then consider backporting
> the fix into your distribution's version of GNAT.
>
> But Per Sandberg wrote the day before on comp.lang.ada:
>
> > Any way it is reported.
>
> which pointed me tohttp://gcc.gnu.org/PR52735
>
> So you should indicate that your bug is a duplicate with a more
> minimal test case.
>
> --
> Ludovic Brenta.

It seems the error is triggered in a different .c file with GPL 2010:

gnatmake -v -gnat05 -gnatd -O0 testcase.adb:

+===========================GNAT BUG
DETECTED==============================+
| GPL 2010 (20100603) (i686-pc-linux-gnu) GCC
error:                       |
| in simplify_subreg, at simplify-rtx.c:
4924                               |
| Error detected around test.adb:16
...
compilation abandoned

gnatmake -v -gnat05 -gnatd -O1 testcase.adb:

+===========================GNAT BUG
DETECTED==============================+
| GPL 2010 (20100603) (i686-pc-linux-gnu) GCC
error:                       |
| in simplify_subreg, at simplify-rtx.c:
4924                               |
| Error detected around test.adb:21
...
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423

gnatmake -v -gnat05 -gnatd -O2 testcase.adb:

gcc -c -gnat05 -gnatd -O2 test.adb

raised STORAGE_ERROR : stack overflow (or erroneous memory access)

No gnat bug box with -O2 :/

Re: My first compiler bug: work around or redesign?

[Ludovic Brenta]

onox writes on comp.lang.ada:
> Ludovic Brenta wrote:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52752
>> which pointed me tohttp://gcc.gnu.org/PR52735
>>
>> So you should indicate that your bug is a duplicate with a more
>> minimal test case.
>
> It seems the error is triggered in a different .c file with GPL 2010:

If you have not already, please add that information to the bug reports
in the Bugzilla database.  The part about different optimization levels
triggering the bug in different ways is particularly relevant.

-- 
Ludovic Brenta.

Re: My first compiler bug: work around or redesign?

[onox]

On Apr 2, 10:51 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> onox writes on comp.lang.ada:
>
> > Ludovic Brenta wrote:
> >>>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52752
> >> which pointed me tohttp://gcc.gnu.org/PR52735
>
> >> So you should indicate that your bug is a duplicate with a more
> >> minimal test case.
>
> > It seems the error is triggered in a different .c file with GPL 2010:
>
> If you have not already, please add that information to the bug reports
> in the Bugzilla database.  The part about different optimization levels
> triggering the bug in different ways is particularly relevant.
>
> --
> Ludovic Brenta.

I tried to avoid creating yet another account for something I will
only use once, but I've done what you asked for and added the info to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52752 ^_^