http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #6 from Richard Guenther 2011-10-07
18:53:44 UTC ---
(In reply to comment #3)
> Hmm, this is not as trivial as PR50638. fortran frontend generates this
> static variable local to MAIN:
>
> static struct __vtype_MAIN___T1 __vtab_MAIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50660
--- Comment #3 from Paolo Carlini 2011-10-07
18:57:12 UTC ---
I guess we can avoid the , just use __null.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #7 from Richard Guenther 2011-10-07
18:59:26 UTC ---
(In reply to comment #6)
> (In reply to comment #3)
> > Hmm, this is not as trivial as PR50638. fortran frontend generates this
> > static variable local to MAIN:
> >
> > static s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50660
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659
--- Comment #3 from janus at gcc dot gnu.org 2011-10-07 19:32:25 UTC ---
Here is a variant which gives the same ICE, but after a regular error message:
program p
implicit none
procedure(Proc) :: Proc_Get
contains
function Proc (arg)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[F03] ICE on invalid with |[4.5/4.6/4.7 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50646
--- Comment #2 from Roger Meyer 2011-10-07
20:50:23 UTC ---
indeed, it would cause problems. i.e. compile some stuff with wrong endianness
and later silently crash.
in this specific case here the build stops later on on another error, caused by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50647
--- Comment #2 from Roger Meyer 2011-10-07
20:57:27 UTC ---
indeed, this should not happen.
but configure fails to figure that sbrk _is_ provided by the libc.
probably it doesn't use the proper feature test macros.
or it just err'd on compilatio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50585
--- Comment #9 from janus at gcc dot gnu.org 2011-10-07 21:01:06 UTC ---
Author: janus
Date: Fri Oct 7 21:01:02 2011
New Revision: 179696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179696
Log:
2011-10-07 Janus Weil
PR fortran/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50625
--- Comment #7 from janus at gcc dot gnu.org 2011-10-07 21:01:06 UTC ---
Author: janus
Date: Fri Oct 7 21:01:02 2011
New Revision: 179696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179696
Log:
2011-10-07 Janus Weil
PR fortran/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50625
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50585
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50646
--- Comment #3 from joseph at codesourcery dot com 2011-10-07 21:46:20 UTC ---
Until comparatively recently, the only thing that cared about host
endianness was decimal floating-point support. However, now the lexer
cares as well.
What is the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50647
--- Comment #3 from joseph at codesourcery dot com 2011-10-07 21:49:58 UTC ---
In general the declarations in system.h are expected to be used only for
very archaic hosts that do not have prototypes in their system headers.
For such hosts, int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50647
--- Comment #4 from joseph at codesourcery dot com 2011-10-07 21:54:27 UTC ---
In general, please see our bug reporting instructions. Reports of
problems building GCC are not useful without details of the build, host
and target systems and the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50646
--- Comment #4 from Andreas Schwab 2011-10-07 22:27:41
UTC ---
Your bootstrap compiler must be broken, because the test is correctly
implemented: a successful run of the test program means little endian. Since
the test exited with non-zero exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50647
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50646
--- Comment #5 from Andreas Schwab 2011-10-07 22:30:14
UTC ---
*** Bug 50647 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46093
--- Comment #1 from ian at gcc dot gnu.org 2011-10-07
22:51:16 UTC ---
Author: ian
Date: Fri Oct 7 22:51:11 2011
New Revision: 179702
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179702
Log:
PR target/46093
* generic-morestack.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46093
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659
--- Comment #6 from janus at gcc dot gnu.org 2011-10-07 23:05:59 UTC ---
(In reply to comment #4)
> In any case, here is a draft patch which fixes the ICE:
The patch in comment #4 regtests cleanly.
Of course it simply avoids the ICE by removing t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Bug #: 50661
Summary: std::equal should use more efficient version for
arrays of pointers
Classification: Unclassified
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34927
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50662
Bug #: 50662
Summary: Incorrect diagnostic returning non-const array pointer
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50196
--- Comment #5 from watsonsong 2011-10-08
06:30:52 UTC ---
(In reply to comment #4)
> I'll look into doing this for 4.7
Thank you.
101 - 127 of 127 matches
Mail list logo
