-Wtype-limits should not produce warnings in the following example:
template
bool foo(integer x)
{
if(x >= 0)
{
// Do something here if integer is positive.
return false;
}
else if(x < 0) // Used else if() here instead of just else to
--- Comment #10 from rguenther at suse dot de 2010-05-07 08:39 ---
Subject: Re: PR36320 breaks boost
On Thu, 6 May 2010, knocte at gmail dot com wrote:
> --- Comment #9 from knocte at gmail dot com 2010-05-06 18:02 ---
> Hello.
>
> I'm in a position in which I cannot upgrade
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-07 08:43 ---
The problem has been fixed on the LTO side. The Frontend issues remain but
are tracked in PR40976.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-05-07 08:49
---
this seems like a good candidate for using template specialisation to alter the
behaviour
I think the warning is still useful for templates, since it warns you of a
potential mistake in your logic. It doesn't ma
--- Comment #10 from burnus at gcc dot gnu dot org 2010-05-07 09:16 ---
Created an attachment (id=20592)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20592&action=view)
Third draft patch
Updated patch: Support structure constructor if no generic function matches,
function
constra
--- Comment #11 from burnus at gcc dot gnu dot org 2010-05-07 09:20 ---
(In reply to comment #10)
> Created an attachment (id=20592)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20592&action=view) [edit]
Third draft patch
To continue the tradition: There is again something "wron
--- Comment #3 from gcc at cohi dot at 2010-05-07 09:33 ---
(In reply to comment #1)
> Most likely related to PR 43277. I want to say Darwin10's unwinder is broken
> ...
Update: The general problem of some exceptions not being caught in
catch-clauses occurs less frequently (i.e. in les
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-07 09:40 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-07 09:46
---
There may be a dup of this bug (can't find it right now).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-07 09:53 ---
"Not enough space" is an error from the OS.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-07 10:11 ---
Well, it probably failed before with -funroll-loops. Why's the cpuid functions
not marked with noinline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44018
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-05-07 10:26
---
Subject: Bug 40989
Author: ebotcazou
Date: Fri May 7 10:25:54 2010
New Revision: 159149
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159149
Log:
PR 40989
* gcc-interface/misc.c (gnat_ha
> gfortran --version
GNU Fortran (GCC) 4.5.0 20100128 (experimental)
> uname -a
Linux loanamd25 2.6.16.46-0.10-smp #1 SMP Mon May 7 13:37:05 UTC 2007 x86_64
x86_64 x86_64 GNU/Linux
> cat used_dummy.f90
FUNCTION DGEES_SELECTH(SELECT)
LOGICAL :: DGEES_SELECTH
--- Comment #2 from crossroads at googlemail dot com 2010-05-07 11:22
---
Having to specialize for every unsigned or signed integer types makes no sense,
depends on the standard being used (e.g. if there is a long long type or not),
and whether or not the given implementation has ad
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-07 11:55 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-07 11:55 ---
Subject: Bug 44020
Author: rguenth
Date: Fri May 7 11:55:21 2010
New Revision: 159150
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159150
Log:
2010-05-07 Richard Guenther
PR tree-optimization/
--- Comment #3 from redi at gcc dot gnu dot org 2010-05-07 12:09 ---
I didn't suggest specialising on every type, you could specialise on
numeric_limits::is_signed
--
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
--- 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
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 #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
--- 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 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
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 #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
--- 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
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 #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
--- 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
--
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 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
---
--- 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
--
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 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
--- 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 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 #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 #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 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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
---
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 #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
--- 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
--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:53 ---
Paul, this PR seems to be fixed. Can it be closed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- 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 #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 #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 #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 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 #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 #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 #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 #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 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 #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 #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 #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 #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
---
--
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 #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_...
--- 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 #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
-
--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 #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|
--
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 #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
--- 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 #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 #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
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 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.
1 - 100 of 117 matches
Mail list logo
