In gcc for VMS there is some mechanism to rename functions.
See the files:
/src/gcc-4.5.0/gcc/config/vms/vms-crtl-64.h
/src/gcc-4.5.0/gcc/config/vms/vms-crtl.h
which are mostly just lists of function from/to.
As well in gcc there is a mechanism for optimizing various "builtin" functions,
like
--- Comment #11 from sandra at codesourcery dot com 2010-05-08 03:43
---
I've posted the patch to fix the first testcase here:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00564.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #2 from kargl at gcc dot gnu dot org 2010-05-08 01:48 ---
Jakub,
Is the patch in comment #2 correct? If yes, I'll
follow up with a ChangeLog and dejagnu-ify the
submitted code for the testsuite.
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-08 01:44 ---
Created an attachment (id=20600)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20600&action=view)
Allow external entities in a default(none)
This patch allows the code to compile. I, however,
do not know if thi
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-08 00:40 ---
It is caused by revision 152533:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00182.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-08 00:35 ---
It failed with gcc 4.4.3 and 4.5.0.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
If the OMP parallel default is set to 'none', then there
is no way to call an external function. As an example:
external f
!$OMP parallel default(none) &
!$OMP shared (f)
Because f is an external function then gfortran quits with the
error:
!$OMP shared (f)
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-07 23:32 ---
This PR lacks the ICE-on-{valid,invalid}-code keyword.
It's too late for me now to attempt to judge which needs to be added.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
Often, the information to fix internals documentation is available as GPLed
code - e.g. example code, comments, function signatures. The internals
Documentation is GFDLed, and thus it requires a new license grant from the
FSF (or from the the author/Copyright assigner if (s)he gives notice
beforeh
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-07 22:31 ---
Ah, the old argument. But true. GCC internals documentation is almost
constantly out of sync with reality because of this. It's been like this for
years now and it is an underestimated problem.
Anyway, confirmed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-07 22:28 ---
Indeed. A serious issue.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Se
--- Comment #43 from steven at gcc dot gnu dot org 2010-05-07 22:23 ---
FIXED for x86_64-apple-darwin:
http://gcc.gnu.org/viewcvs?view=revision&revision=159173
ix86 and ppc* are still to be done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
The definition of target hooks is spread across multiple files, which makes
it hard to add new or modify existing target hooks in a consistent manner.
--
Summary: target hooks are hard to maintain
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
The target hook documentation does not always get updated when new hooks are
added or existing ones modified, and therefore is always incomplete and
always or most of the time partially incorrect.
--
Summary: The target hook documentation is chronically out-of-sync
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-07 22:09 ---
Not related to ISO-C.
Reduced test case:
MODULE f03_test
INTERFACE
INTEGER FUNCTION build(lib, np)
END FUNCTION
END INTERFACE
PROCEDURE(build), POINTER :: pbuild
CONTAINS
!
--- Comment #7 from longb at cray dot com 2010-05-07 22:06 ---
The original problem reported in the Description concerned a missing error
message. So, fixing the segfault (while an excellent situation) does not
address the original issue. My 2 cents is this is not ready to close yet.
Because the internals documentation is distributed under the GFDL, it is not
safe to cut&paste examples or instructions from the documentation when writing
new code in GCC, since that code needs to be released under the GPL.
Documentation that pertains to the modification of a program must come wit
--- Comment #7 from changpeng dot fang at amd dot com 2010-05-07 21:41
---
(In reply to comment #4)
> (In reply to comment #3)
> > Subject: Re: gcc should vectorize this loop
> > through "iteration range splitting"
> > You mean that the problem is the if-conversion of the stor
--- Comment #3 from changpeng dot fang at amd dot com 2010-05-07 21:33
---
I just found that the test case in the same as (similar to) bug 35229.
The subject of this bug is wrong. Scalar expansion is not appropriate
for this case.
Actually the loop can be transform to:
void foo(int n)
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-07 21:30 ---
This PR is a tad short on details ^^
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40899
--- Comment #6 from scovich at gmail dot com 2010-05-07 21:20 ---
Aha! The problem is not that gcc fails to emit the proper debug info, it's that
it doesn't always track well which instructions came from which function.
For example, if we compile this toy program:
int volatile global
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ice in subst_reloads, at|[4.6 Regression] ice in
|reload.c:6327
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-07 21:14 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r159144-install
--program-prefix=r159144- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100507 (experimental) (GCC)
[reg...@bethe tmp600]$ current-gcc -O -c small.c
small.c: In function
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-07 21:02
---
(In reply to comment #9)
> It even works!
Paul, any news here? This looks very useful!
See also PR41137.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-07 21:01 ---
See also PR40598.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-07 20:57 ---
Confirmed.
Found partial redundancy for expression {g_...@.mem_13(D) (0003)
Inserted pretmp.6_26 = g_54;
in predecessor 6
Created phi prephitmp.7_20 = PHI
in block 3
Found partial redundancy for expression {g_...
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44030
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-07 20:52 ---
It is caused by revision 159106:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00156.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-07 20:30 ---
(In reply to comment #8)
> I guess everything is fixed now. Can we close this PR?
Ping?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-07 20:25 ---
Slightly more reduced testcase:
void
foo (unsigned f, long v, unsigned *w, unsigned a, unsigned b, unsigned e,
unsigned c, unsigned d)
{
unsigned h = v / 4, x[16];
while (f < h)
{
unsigned i;
f++;
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-07 20:24 ---
#c3 testcase is actually from PR44023. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44028
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-07 20:15 ---
This PR seems to be fixed. The dump does not contain any reference to
builtin_pack/builtin_unpack any more and I can't identify anything that looks
like a call to transfer.
Can it thus be closed?
--
dfranke at g
--- Comment #4 from hjl dot tools at gmail dot com 2010-05-07 20:14 ---
It is caused by revision 152927:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00580.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44028
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-07 20:13 ---
Slightly more reduced testcase:
void
foo (unsigned f, long v, unsigned *w, unsigned a, unsigned b, unsigned e,
unsigned c, unsigned d)
{
unsigned h = v / 4, x[16];
while (f < h)
{
unsigned i;
f++;
--- Comment #5 from scovich at gmail dot com 2010-05-07 20:12 ---
Belated follow-up: I just tried to use sparc-sun-solaris2.10-gcc-4.4.0 (built
from sources) and it does not emit the DW_AT_call_* debug attributes which gdb
expects in order to unwind inlined functions.
I have searched b
--- Comment #4 from rwild at gcc dot gnu dot org 2010-05-07 20:11 ---
Fixed.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from rwild at gcc dot gnu dot org 2010-05-07 20:11 ---
Subject: Bug 44016
Author: rwild
Date: Fri May 7 20:11:01 2010
New Revision: 159170
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159170
Log:
Fix link to outdated cxx0x status page.
gcc/:
PR documen
--- Comment #2 from rwild at gcc dot gnu dot org 2010-05-07 20:11 ---
Subject: Bug 44016
Author: rwild
Date: Fri May 7 20:10:32 2010
New Revision: 159169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159169
Log:
Fix link to outdated cxx0x status page.
gcc/:
PR documen
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-07 20:10 ---
(In reply to comment #2)
> Therefore, I vote for a confirm.
Paul, did you mean to assign this PR to you as well? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36497
--- Comment #1 from rwild at gcc dot gnu dot org 2010-05-07 20:10 ---
Subject: Bug 44016
Author: rwild
Date: Fri May 7 20:10:09 2010
New Revision: 159168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159168
Log:
Fix link to outdated cxx0x status page.
gcc/:
PR documen
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-07 19:56 ---
Paul, any reason not to commit the patch in comment #1?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-07 19:53 ---
Paul, this PR seems to be fixed. Can it be closed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r159144-install
--program-prefix=r159144- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100507 (experimental) (GCC)
[reg...@bethe tmp601]$ current-gcc -O2 -c small.c
small.c: In function '
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-07 19:50 ---
(In reply to comment #5)
> I tried 4.4.2 and do not any longer see the segfault on the Cray XT system.
This PR can thus be closed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-07 19:46 ---
(In reply to comment #5)
> * shared DO termination
Ahh, I'd like to see that one!
(In reply to comment #6)
That's your PR40165 ;)
--
dfranke at gcc dot gnu dot org changed:
What|Removed
The GNAT User Guide (source gnat_ugn.texi) is referenced in several places from
gnat_rm.texi. However, when the User Guide is built, gnat_ugn.texi is
preprocessed into gnat_ugn_unw.texi (Unix, Windows) or gnat_ugn_vms.texi (VMS),
so that the links from the Reference Manual don't work.
Go to
http://
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-07 18:12 ---
*** Bug 43539 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-07 18:12 ---
$ gfortran-svn -v
gcc version 4.6.0 20100506 (experimental) (GCC)
$ gfortran-svn -std=f2003 pr43539.f90
pr43539.f90:9.32:
write(*,'(a,i0)') 'In f08: ', C_SIZEOF(sp)
1
Error: Fu
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-07 18:06 ---
*** This bug has been marked as a duplicate of 43289 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-07 18:06 ---
*** Bug 39289 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43289
--- Comment #23 from rus at google dot com 2010-05-07 17:49 ---
Subject: Re: ext/profile/all.cc fails on Solaris
On Thu, May 6, 2010 at 11:53 PM, kgardas at objectsecurity dot com
wrote:
>
>
> --- Comment #22 from kgardas at objectsecurity dot com 2010-05-07 06:53
> ---
> Vi
--- Comment #12 from vmakarov at redhat dot com 2010-05-07 17:49 ---
When allocno is finished, its some info is propagated into upper allocno.
When several allocnos with same regno are finished, info can be propagated
directly to survived upper allocno or through one allocno will be f
--- Comment #2 from ubizjak at gmail dot com 2010-05-07 17:46 ---
The difference starts in sched1 dumps:
[...]
+{r127:XF=float(r150:SI);clobber [frame:DI-0x44];}
+REG_DEAD: r150:SI
{r160:HI=r160:HI|0xc00;clobber flags:CC;}
REG_UNUSED: flags:CC
r106:XF=r106:XF+r120:XF
REG_DEAD: r120:
--- Comment #25 from sezeroz at gmail dot com 2010-05-07 17:44 ---
(In reply to comment #23)
> My build log seems to be clean (i686-pc-linux-gnu).
> Is this PR still needed?
>
The commit from comment #14 (as inlined in comment #9) introduces a new warning
of "passing argument 2 of 'wri
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-07 17:41 ---
(In reply to comment #1)
> I believe, this is eventually the same as PR32365.
Stupid me. There's actually an easy fix for this one:
Index: openmp.c
==
--- Comment #6 from mrs at gcc dot gnu dot org 2010-05-07 17:35 ---
Thanks.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from mrs at gcc dot gnu dot org 2010-05-07 17:34 ---
Subject: Bug 43708
Author: mrs
Date: Fri May 7 17:34:31 2010
New Revision: 159164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159164
Log:
PR target/43708
* config/darwin-c.c (darwin_pragma_un
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-07 17:23 ---
In openmp.c (gfc_match_omp_end_nowait), we match "nowait" and end-of-string. If
there's anything but whitespace after the nowait, the match is rejected.
With "nowait" being rejected, parse.c (match_word) rejects the
--- Comment #24 from nightstrike at gmail dot com 2010-05-07 17:18 ---
This is for mingw, not linux.
I can test again when our buildbot farm is back up. Should be in the next few
days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
--- Comment #6 from ubizjak at gmail dot com 2010-05-07 17:12 ---
The differences in IRA insn stream dumps are then:
[...]
-$28:DI=[$30:DI+0x78]
-$28:DI=leu($28:DI,$16:DI)
-[$30:DI+0x70]=$28:DI
+$0:DI=[$30:DI+0x78]
+$0:DI=leu($0:DI,$16:DI)
+[$30:DI+0x70]=$0:DI
[...]
-$28:SI=0xfff
--- Comment #5 from ubizjak at gmail dot com 2010-05-07 17:04 ---
For some reason, IRA chooses different reload registers.
--- t1.c.190r.ira 2010-05-07 18:57:36.0 +0200
+++ t1.c.gk.190r.ira2010-05-07 18:57:36.0 +0200
These are differences in chosen reload regi
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-05-07 16:41
---
Any news here? Can this one be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41977
--- Comment #12 from burnus at gcc dot gnu dot org 2010-05-07 16:37 ---
Created an attachment (id=20599)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20599&action=view)
Fourth version of the draft patch
And fourth version. I have just realized that the patch is too simplistic and
--- Comment #4 from ubizjak at gmail dot com 2010-05-07 16:32 ---
Created an attachment (id=20598)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20598&action=view)
reduced testcase
Reduced testcase, 45 lines. Beware, crypto code ahead...
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #23 from dfranke at gcc dot gnu dot org 2010-05-07 16:00
---
My build log seems to be clean (i686-pc-linux-gnu).
Is this PR still needed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
Subject: Bug 43857
Author: rguenth
Date: Fri May 7 15:53:40 2010
New Revision: 159159
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159159
Log:
2010-05-07 Richard Guenther
* gcc.c (LINK_COMMAND_
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
Subject: Bug 43371
Author: rguenth
Date: Fri May 7 15:53:40 2010
New Revision: 159159
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159159
Log:
2010-05-07 Richard Guenther
* gcc.c (LINK_COMMAND_
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #1 from zsojka at seznam dot cz 2010-05-07 15:53 ---
Created an attachment (id=20597)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20597&action=view)
reduced testcase (from gcc.c-torture/execute/20030914-1.c)
Different code is generated with x86_64-linux as target
-
--- Comment #13 from jason at gcc dot gnu dot org 2010-05-07 15:52 ---
Subject: Bug 43951
Author: jason
Date: Fri May 7 15:52:06 2010
New Revision: 159158
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159158
Log:
PR c++/43951
* init.c (diagnose_uninitialized_cs
Command line:
$ gcc -O1 -fregmove -fsched-pressure -ftree-vectorize -funroll-loops
-fschedule-insns -fcompare-debug testcase.c
or
$ gcc -O3 -fsched-pressure -fschedule-insns -fcompare-debug testcase.c
Tested revisions:
r159062 - fail
r159045 - fail
r158683 - fail
r153685 - fail
--
Su
--- Comment #3 from ubizjak at gmail dot com 2010-05-07 15:46 ---
Jakub, reverting your r159063 fixes the failure:
PR debug/43478
* df-problems.c (struct dead_debug_use, struct dead_debug): New.
(dead_debug_init, dead_debug_finish): New functions.
(dead_d
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-07 15:42 ---
As requested in PR 44026: Mark this report as duplicate.
Regarding the error message itself: As the manual state (man gcc or
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#index-malign_002ddouble-
--- Comment #3 from burnus at gcc dot gnu dot org 2010-05-07 15:42 ---
*** Bug 44027 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44026
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-07 15:40 ---
>From quick skim the first difference is on a sha1.c:350 insn in *.ira dump.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44023
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-07 15:37 ---
Subject: Bug 40728
Author: dfranke
Date: Fri May 7 15:36:45 2010
New Revision: 159155
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159155
Log:
gcc/fortran/:
2010-05-07 Daniel Franke
PR fortran
--- Comment #2 from Igor dot Katchaev at cern dot ch 2010-05-07 14:47
---
Subject: Re: Segfault on internal read with -malign-double
Ok, thanks.
Please remove duplicate #44027, sorry.
Igor
On Fri, 7 May 2010, kargl at gcc dot gnu dot org wrote:
--- Comment #1 from kargl at gc
Results and status of internal read are wrong if -malign-double
option is specified. Seen on (32 bit)
SLC4 gfortran 4.3.3 (i686-pc-linux-gnu),
Ubuntu9 gfortran 4.4.1 (Ubuntu 4.4.1-4ubuntu9),
rhel6 beta (4.4.3-1.el6.i386).
No problem on g77 and gfortran (4.1.2-44.EL4_8.1.i386) on SLC4,
gfortran (4.
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-07 14:35 ---
DO NOT USE -malign-double.
You need to recompile gfortran's runtime library if this
option is to be used.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
Results and status of internal read are wrong if -malign-double
option is specified. Seen on (32 bit)
SLC4 gfortran 4.3.3 (i686-pc-linux-gnu),
Ubuntu9 gfortran 4.4.1 (Ubuntu 4.4.1-4ubuntu9),
rhel6 beta (4.4.3-1.el6.i386).
No problem on g77 and gfortran (4.1.2-44.EL4_8.1.i386) on SLC4,
gfortran (4.
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-07 13:57 ---
*** This bug has been marked as a duplicate of 30566 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-07 13:57 ---
*** Bug 41825 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenther at suse dot de|rguenth at gcc dot gnu dot
|
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-05-07
13:29 ---
Subject: Re: xgcc: error trying to exec
'/test/gnu/gcc/objdir/./prev-gcc/gnat1': execv: Not e
> "Not enough space" is an error from the OS.
Yes, but I saw this on two separate machines, one with 8 GB of m
--- Comment #1 from carrot at google dot com 2010-05-07 13:19 ---
Created an attachment (id=20596)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20596&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
Compile the attached source code with options -Os -march=armv7-a -mthumb, gcc
generates:
bar4:
push{r3, r4, r5, lr}
ldr r2, [r0, #520]
mov r4, r0
mov r3, r0
mov r1, r0
movsr0, #0// A
b .L2
.L4:
ld
--- Comment #28 from bangerth at gmail dot com 2010-05-07 13:15 ---
*** Bug 44021 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at gmail dot com 2010-05-07 13:15 ---
*** This bug has been marked as a duplicate of 11856 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
The commit
http://gcc.gnu.org/viewcvs?view=revision&revision=122551
changed gcc's behaviour in
-
int bar();
int a = ((void *) bar) != 0;
We used to accept it, but now we produce
test.c:2: error: initializer element is not constant
Th
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-07 13:08 ---
Manuel: As this is a middle-end warning, do you have an idea?
dgees_selecth (logical(kind=4) (*) (void) select)
{
logical(kind=4) __result_dgees_selecth.0;
logical(kind=4) D.1538;
logical(kind=4) __result_dgee
--- Comment #5 from hjl dot tools at gmail dot com 2010-05-07 13:08 ---
For some reason, when I change it to C, it compiles.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2010-05-07 12:39 ---
Created an attachment (id=20595)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20595&action=view)
preprocessed source
Preprocessed source (can be compiled on a crosscompiler), triggers stage2/3
bootstrap compare fai
Recent changes broke bootstrap on alphaev68-pc-linux-gnu, due to stage2/3
compare failure in libiberty/sha1.o.
Soon to be attached preprocessed file triggers -fcompare-debug failure (also on
a crosscompiler from x86_64-pc-linux-gnu):
~/gcc-build-alpha/gcc/xgcc -B ~/gcc-build-alpha/gcc -mcpu=ev67
--- Comment #4 from redi at gcc dot gnu dot org 2010-05-07 12:20 ---
alternatively you could just use std::less()(x, 0) which avoids the
warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
--- Comment #4 from ubizjak at gmail dot com 2010-05-07 12:19 ---
(In reply to comment #3)
> Well, it probably failed before with -funroll-loops. Why's the cpuid
> functions
> not marked with noinline?
Because it is only one instruction?
--
http://gcc.gnu.org/bugzilla/show_bug.cg
1 - 100 of 117 matches
Mail list logo
