--- Comment #39 from rob1weld at aol dot com 2009-04-17 23:32 ---
(In reply to comment #38)
Maybe fixed now (the reduced testcase is). Please re-open if not.
Confirmed. Thank you Richard.
# uname -a
OpenBSD openbsd.localdomain 4.5 GENERIC#19 i386
Host Compiler:
# egcc -v
Reading
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:33
---
Created an attachment (id=17646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17646action=view)
Reduced testcase.
To be gnatchop-ed and compiled at -O.
--
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:57
---
Richard,
the removal of
/* If the RHS of the MODIFY_EXPR may throw or make a nonlocal goto
and the LHS is a user variable, then we need to introduce a formal
temporary. This way the optimizers can
--- Comment #30 from rguenther at suse dot de 2009-04-16 08:06 ---
Subject: Re: [4.5 regression] Revision 145338 breaks
ability to build Ada
On Thu, 16 Apr 2009, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:57
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2009-04-16 08:33
---
Do you happen to have a testcase?
Attached in the PR.
bb 22:
formal_24(ab) = p__proc_next (formal_6(ab));
goto bb 3;
# formal_7(ab) = PHI formal_9(ab)(2), formal_5(ab)(3), formal_5(ab)(4),
--- Comment #32 from rguenther at suse dot de 2009-04-16 08:45 ---
Subject: Re: [4.5 regression] Revision 145338 breaks
ability to build Ada
On Thu, 16 Apr 2009, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2009-04-16 08:33
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2009-04-16 09:13
---
Ok, so we _do_ run lower_eh_constructs, but
formal = p__proc_next (formal);
returns false for stmt_could_throw_p (stmt). Why? (Not that I can follow
the Ada testcase ... but I suppose the above
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 regression] Revision |[4.5 Regression] Revision
|145338 breaks ability
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-04-16 10:45
---
Maybe fixed now (the reduced testcase is). Please re-open if not.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-04-16 08:59
---
And of course the testcase compiles fine with -fexceptions. Hmmm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-04-16 08:58
---
Ok, so we _do_ run lower_eh_constructs, but
formal = p__proc_next (formal);
returns false for stmt_could_throw_p (stmt). Why? (Not that I can follow
the Ada testcase ... but I suppose the above function call
--- Comment #36 from rguenth at gcc dot gnu dot org 2009-04-16 09:22
---
Created an attachment (id=17647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17647action=view)
patch
Ok, I think I see the issue. The attached patch should fix it (it does fix
the testcase). I am going
--- Comment #23 from charlet at gcc dot gnu dot org 2009-04-09 06:37
---
Certainly, pa-hpux and ia64-hpux are two very different platforms as far as
GCC is concerned.
Also, yes, FSF GCC and GNAT Pro are two very different beasts with a different
list of supported/tested platforms,
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2009-04-09 08:07
---
Would that be what we refer to as hpux-ia64 ?
No, IA-64 and PA-RISC are different things.
GNAT Pro is the natural Ada solution for HPs Alpha server and Integrity
server (I64) platforms or is gcc's Ada not
--- Comment #25 from rob1weld at aol dot com 2009-04-09 15:16 ---
That is good news, (that hppa2.0w-hp-hpux11.11 (PA-RISC 2.0.), which we
claim is supported, is not the same/similar to hpux-ia64, which has two
ZCX = False entries). We don't want to break that. Nice machine.
Is the
--- Comment #26 from charlet at gcc dot gnu dot org 2009-04-09 15:40
---
Is the (small amount of ?) code in Gnat Pro going to be available
(someday) for gcc Ada. That may fix these problems.
There's still confusion I'm afraid. GCC Ada is just an Ada compiler.
GNAT Pro is a complete
--- Comment #22 from rob1weld at aol dot com 2009-04-09 03:51 ---
(In reply to comment #21)
It looks like this would affect: hpux-ia64, lynxos-ppc, lynxos-x86, ...
...
You can exclude all cross platforms; moreover hpux-ia64 is not really
supported.
URL
--- Comment #20 from rob1weld at aol dot com 2009-04-07 04:00 ---
(In reply to comment #8)
Bug is not in an FSF-GCC supported port.
Does the problem reproduce on supported targets? Otherwise this bug
should be closed as INVALID.
(In reply to comment #12)
As for the backend issue,
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2009-04-07 05:13
---
It looks like this would affect: hpux-ia64, lynxos-ppc, lynxos-x86,
vxworks-arm, vxworks-m68k, vxworks-mips, vxworks-sparcv9 and vxworks-x86
with the default ./configure _AND_ every other Target _IF_ the
--- Comment #7 from rob1weld at aol dot com 2009-04-05 17:31 ---
I can build gcc with the Ada Language using Trunk revision 145337
but the changes made in the next revision cause the build to fail.
The Changelog indicates Richard Guenther made the changes on 2009-03-31.
There were no
--- Comment #8 from steven at gcc dot gnu dot org 2009-04-05 17:40 ---
Bug is not in an FSF-GCC supported port.
Does the problem reproduce on supported targets? Otherwise this bug should be
closed as INVALID.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2009-04-05 17:55
---
Using the BSD Ports I was able to build Ada, up until revision 145338 .
While I do not use Ada it would be unfortunate to lose this Language.
This language is not supported in the FSF tree on OpenBSD, i.e.
--- Comment #10 from laurent at guerby dot net 2009-04-05 18:12 ---
I think this should be kept open as an enhancement request, if we have a
willing tester on openbsd I'll try to help.
As for the backend issue, may be it will show up on i386-unknown-freebsd too (a
primary platform),
--- Comment #11 from laurent at guerby dot net 2009-04-05 18:18 ---
For reference, NetBSD Ada support patch was also posted recently:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-04-05 18:26
---
As for the backend issue, may be it will show up on i386-unknown-freebsd too
(a
primary platform), and there's a gcc/ada/system-freebsd-x86.ads in the FSF
tree.
Most probably not, you need FE SJLJ
--- Comment #13 from laurent at guerby dot net 2009-04-05 18:46 ---
Is there a supported platform currently using FE SJLJ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
--- Comment #14 from rob1weld at aol dot com 2009-04-05 20:03 ---
(In reply to comment #10)
I think this should be kept open as an enhancement request, if we have a
willing tester on openbsd I'll try to help.
I'll do my best to help but I know that there are numerous people who are
--- Comment #15 from rob1weld at aol dot com 2009-04-05 20:10 ---
(In reply to comment #9)
Using the BSD Ports I was able to build Ada, up until revision 145338 .
While I do not use Ada it would be unfortunate to lose this Language.
This language is not supported in the FSF tree
--- Comment #16 from laurent at guerby dot net 2009-04-05 20:23 ---
I've found machines and hosting to add i686 free/net/openBSD to the compile
farm, they should be online in the coming weeks, this allow smoother GCC
development and testing on these platforms.
--- Comment #17 from rob1weld at aol dot com 2009-04-05 20:53 ---
I've found machines and hosting to add i686
What a great guy!
More patches / support files / etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34717
ports/lang/gcc/4.3/patches/
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2009-04-05 21:43
---
Is there a supported platform currently using FE SJLJ?
Windows.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
--- Comment #19 from rainer at emrich-ebersheim dot de 2009-04-05 22:18
---
(In reply to comment #18)
Is there a supported platform currently using FE SJLJ?
Windows.
I confirm the exactly same issue for i686-pc-cygwin. And I think it is the same
for the *mingw32 targets.
--
32 matches
Mail list logo
