On 09/01/2011 12:33 PM, Richard Guenther wrote:
> On Thu, Sep 1, 2011 at 11:34 AM, Arnaud Charlet wrote:
>> After doing a binary search, the first revision which breaks bootstrap on
>> my environment with Ada enabled is the following:
>>
>> r178353 | vries | 2011-08-31 09:04:25 +0200 (Wed, 31 Aug
On Thu, Sep 1, 2011 at 11:34 AM, Arnaud Charlet wrote:
> After doing a binary search, the first revision which breaks bootstrap on
> my environment with Ada enabled is the following:
>
> r178353 | vries | 2011-08-31 09:04:25 +0200 (Wed, 31 Aug 2011) | 8 lines
>
> 2011-08-31 Tom de Vries
>
>
> > After doing a binary search, the first revision which breaks bootstrap on
> > my environment with Ada enabled is the following:
> >
> > r178353 | vries | 2011-08-31 09:04:25 +0200 (Wed, 31 Aug 2011) | 8 lines
> > ...
>
> This is probably related to pr50251 also caused by r178353.
Thanks. So
> After doing a binary search, the first revision which breaks bootstrap on
> my environment with Ada enabled is the following:
>
> r178353 | vries | 2011-08-31 09:04:25 +0200 (Wed, 31 Aug 2011) | 8 lines
> ...
This is probably related to pr50251 also caused by r178353.
Dominique
After doing a binary search, the first revision which breaks bootstrap on
my environment with Ada enabled is the following:
r178353 | vries | 2011-08-31 09:04:25 +0200 (Wed, 31 Aug 2011) | 8 lines
2011-08-31 Tom de Vries
PR middle-end/43513
* Makefile.in (tree-ssa-ccp.o): Add
On Thu, Sep 1, 2011 at 9:06 AM, Richard Guenther
wrote:
> On Wed, Aug 31, 2011 at 6:34 PM, Arnaud Charlet wrote:
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_PROTECTION_FAILURE at address: 0x
>>> 0x001c4fa0 in lib__writ__write_ali ()
>>> (gdb) bt
>
> OK. Still trying to reproduce here and trying to figure out blindly what
> could be the cause of this behavior for now.
I could finally reproduce on another machine (i686-linux), so I am now
doing a binary search to find out precisely what change caused this
failure, so no need for other people
> My bootstrap compiler is GCC 4.3.4, the error occurs in stage3 (well, when
> building the RTS). It will take some time to check the revs you quoted.
OK. Still trying to reproduce here and trying to figure out blindly what could
be the cause of this behavior for now.
Olivier is also trying to r
On Wed, Aug 31, 2011 at 6:34 PM, Arnaud Charlet wrote:
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_PROTECTION_FAILURE at address: 0x
>> 0x001c4fa0 in lib__writ__write_ali ()
>> (gdb) bt
>> #0 0x001c4fa0 in lib__writ__write_ali ()
>> #1 0x0036799a i
On 31 Aug 2011, at 20:07, Iain Sandoe wrote:
On 31 Aug 2011, at 17:34, Arnaud Charlet wrote:
In particular I'd be curious to know if revision 178376 has the
failure or not.
different failure;
built with BOOT_CFLAGS="-O0 -g" ..
.. it fails debug-compare (ada/exp_ch6.o).
There are a lot
On 31 Aug 2011, at 20:07, Iain Sandoe wrote:
Same for revision 178311
will set this going .. prob. tomorrow before a report.
fails with:
"exp_light.ali" not found "exp_light.adb" must be compiled
(that issue was already reported by Richi).
so .. not much progress ... will try bisec
On 31 Aug 2011, at 17:34, Arnaud Charlet wrote:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x001c4fa0 in lib__writ__write_ali ()
(gdb) bt
#0 0x001c4fa0 in lib__writ__write_ali ()
#1 0x0036799a in _ada_gnat1drv ()
#2
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x
> 0x001c4fa0 in lib__writ__write_ali ()
> (gdb) bt
> #0 0x001c4fa0 in lib__writ__write_ali ()
> #1 0x0036799a in _ada_gnat1drv ()
> #2 0x000305f5 in gnat_parse_file ()
I j
On 31 Aug 2011, at 16:57, Arnaud Charlet wrote:
(x86_64-unknown-linux-gnu) |
| Storage_Error stack overflow or erroneous memory
access |
| Error detected at system.ads:
175:5 |
+
=
=
=
=
=
=
===
On 31 Aug 2011, at 16:53, Joseph S. Myers wrote:
On Wed, 31 Aug 2011, Arnaud Charlet wrote:
+===GNAT BUG
DETECTED==+
| 4.7.0 20110831 (experimental) [trunk revision 161655]
(x86_64-unknown-linux-gnu) |
| Storage_Error stack overflow or erron
> (x86_64-unknown-linux-gnu) |
> | Storage_Error stack overflow or erroneous memory access |
> | Error detected at system.ads:175:5 |
> +==+
>
>
>
> Please include these
On Wed, 31 Aug 2011, Arnaud Charlet wrote:
> > >> +===GNAT BUG
> > >> DETECTED==+
> > >> | 4.7.0 20110831 (experimental) [trunk revision 161655]
> > >> (x86_64-unknown-linux-gnu) |
> > >> | Storage_Error stack overflow or erroneous memory access
> >> +===GNAT BUG
> >> DETECTED==+
> >> | 4.7.0 20110831 (experimental) [trunk revision 161655]
> >> (x86_64-unknown-linux-gnu) |
> >> | Storage_Error stack overflow or erroneous memory access
> >> |
> >> | Error detected at a-el
On Wed, Aug 31, 2011 at 1:16 PM, Arnaud Charlet wrote:
>> Bootstrap with Ada included was broken at random revisions throughout
>> the last days which made testing any patch quite painful (well, as someone
>> who includes Ada in bootstrap and testing by default).
>>
>> Can you please ensure that y
> Bootstrap with Ada included was broken at random revisions throughout
> the last days which made testing any patch quite painful (well, as someone
> who includes Ada in bootstrap and testing by default).
>
> Can you please ensure that you don't break bootstrap all the time? I'm
> now simply tes
On Wed, Aug 31, 2011 at 11:43 AM, Arnaud Charlet wrote:
> If a declaration within a generic unit has aspects, the capture of references
> within the aspect expressions has to be done in a separate step because the
> aspect specificatios are not directly attached to the tree for the
> declaration.
If a declaration within a generic unit has aspects, the capture of references
within the aspect expressions has to be done in a separate step because the
aspect specificatios are not directly attached to the tree for the declaration.
The following must compile quietly:
gcc -c -gnat12 -gnata ml
22 matches
Mail list logo
