> I suppose the CFG verifier should also catch this. I wonder how this can
> lead to wrong code as opossed to infinite loop?
> I can imagine DCE being confused about non-control-flow stmt and conclude
> the abnormal path as the path leaving the loop. I will look into the
> testcase more.
:
H.J.,
also once we get to bootstrapland with Ada and LTO, would be possible to enable
it on the LTO bootstrap tester, so we won't break it again?
Thanks,
Honza
Hi,
the change in my patch was intentional, I forgot to send the email. Sorry for
that.
The reason is that labels/predictions/debug statements now go specially though
DCE
and are marked as neecessary, but not really handled so (i.e. we can remove
conditional
controlling only debug statements).
T
> It's apparently another bug in the DCE pass.
But it comes from a stalled ABNORMAL flag after the FRE3 pass so:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 231856)
+++ tree-ssa-pre.c (working copy)
@@ -4128,6
> BTW for the LTO type merging issues one could probably just drop those types
> and all derivations to alias set 0. But indeed rewriting them to pointers
> would be better, especially for ABI compatibility.
>
> The Ada ICE I get is:
> Continuing.
> +===GNAT BUG DETECTED===
> I finally got around comitting the DCE patch so mainline lto bootstrap works
> up to this point.
Thanks!
> It would be great if you could take a look so we can get it finally fixed.
Let me commit a couple of Ada patches first and then I'll look into it.
--
Eric Botcazou
> BTW for the LTO type merging issues one could probably just drop those types
> and all derivations to alias set 0. But indeed rewriting them to pointers
> would
> be better, especially for ABI compatibility.
>
> The Ada ICE I get is:
> Continuing.
> +===GNAT BUG DETECTED
> > > If you have any clue how to debug it further, I would be happy to try.
> > > That atree code is real software engineering treat BTW
> >
> > I'll have a look at some point, once things have stabilized a bit.
>
> OK, I will push out the remaining patches needed to get LTO into a shape to
> co
> > If you have any clue how to debug it further, I would be happy to try.
> > That atree code is real software engineering treat BTW
>
> I'll have a look at some point, once things have stabilized a bit.
OK, I will push out the remaining patches needed to get LTO into a shape to
compile gnat1 an
> If you have any clue how to debug it further, I would be happy to try.
> That atree code is real software engineering treat BTW
I'll have a look at some point, once things have stabilized a bit.
--
Eric Botcazou
BTW for the LTO type merging issues one could probably just drop those types
and all derivations to alias set 0. But indeed rewriting them to pointers would
be better, especially for ABI compatibility.
The Ada ICE I get is:
Continuing.
+===GNAT BUG DETECTED=
> > Will it also fix
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954
>
> Yes, probably, as well as the m68k issue, if that's really doable.
Right, that's also why I think it's a more promising approach.
Pretending that system.address is just an unsigned integer is bound to cause
troub
> Will it also fix
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954
Yes, probably, as well as the m68k issue, if that's really doable.
--
Eric Botcazou
On Mon, Nov 23, 2015 at 8:02 AM, Eric Botcazou wrote:
>> But can't you on the GENERIC side drop System.Address to void_ptr_node
>> again and just not make use of the "heavy lifting" you were talking about?
>
> No "heavy lifting" in this thread, just a heavy machinery in the language. :-)
>
>> That
> But can't you on the GENERIC side drop System.Address to void_ptr_node
> again and just not make use of the "heavy lifting" you were talking about?
No "heavy lifting" in this thread, just a heavy machinery in the language. :-)
> That is, why is that speciality of System.Address not a Ada FE thi
On Mon, Nov 23, 2015 at 12:45 PM, Eric Botcazou wrote:
>> No, Interfaces.C.Extensions is non portable, so almost no Ada code out there
>> is using it. As I said, existing Ada code is using System.Address all the
>> time, so requiring any code change in this area is just a non starter. We'd
>> rath
> No, Interfaces.C.Extensions is non portable, so almost no Ada code out there
> is using it. As I said, existing Ada code is using System.Address all the
> time, so requiring any code change in this area is just a non starter. We'd
> rather require that people don't use LTO with Ada rather than te
> > So there is indeed no point in trying to fix one or two cases, and we should
> > instead instruct LTO somehow to treat System.Address is compatible with
> > void* otherwise we'll run into endless troubles on that since using
> > System.Address as void* is very common practice in Ada code.
>
>
> So there is indeed no point in trying to fix one or two cases, and we should
> instead instruct LTO somehow to treat System.Address is compatible with
> void* otherwise we'll run into endless troubles on that since using
> System.Address as void* is very common practice in Ada code.
Maybe we cou
> I updated the warning to actually check if the TBAA information is in
> conflict
> and silence warnings on allowed type transtions that are not
> useless_type_conversion_p
> (which is needed for Fortran, too). This is list of warnings I get which I
> suppose will need to be adressed.
Most if not
> > > ../../gcc/ada/s-os_lib.adb:1007:16: note: return value type
> > > mismatch
> > >function strerror (errnum : Integer) return System.Address;
> > > ^
> > >
> > > ../../gcc/ada/s-os_lib.adb:1007:16: note:
> > > ???system__os_lib__errno_message__strerror??? was previously
> > this patch fixes an ICE seen with Ada LTO bootstrap in reporting type
> > mismatches and it also makes us to stop complaining about C++ ODR
> > violation. The warnings are however correct. I looked at few:
> >
> > ../../libiberty/xstrerror.c:40:14: warning: type of �strerror� does not
> > ma
> > ../../gcc/ada/s-os_lib.adb:1007:16: note: return value type
> > mismatch
> >function strerror (errnum : Integer) return System.Address;
> > ^
> >
> > ../../gcc/ada/s-os_lib.adb:1007:16: note:
> > ???system__os_lib__errno_message__strerror??? was previously
> > declared
> this patch fixes an ICE seen with Ada LTO bootstrap in reporting type
> mismatches and it also makes us to stop complaining about C++ ODR
> violation. The warnings are however correct. I looked at few:
>
> ../../libiberty/xstrerror.c:40:14: warning: type of �strerror� does not
> match original
Hi,
this patch fixes an ICE seen with Ada LTO bootstrap in reporting type mismatches
and it also makes us to stop complaining about C++ ODR violation. The warnings
are however correct. I looked at few:
../../libiberty/xstrerror.c:40:14: warning: type of �strerror� does not match
original declar
25 matches
Mail list logo
