[Bug c++/44021] New: Templates with -Wtype-limits produces warnings.
-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 get 2nd
warning.
{
// Do something else here if integer is negative.
return true;
}
}
int main()
{
foo(3);
foo(3);
return 0;
}
The first line in the main() function, together with -Wtype-limits (or
-Wextra), produces these warnings:
warning: comparison of unsigned expression >= 0 is always true
warning: comparison of unsigned expression < 0 is always false
While these warnings makes sense for all other cases, they should not occur for
comparison of template types, since it does not easily allow for warning-free
templates which can handle unsigned and signed integers and have different
behavior for negative numbers.
Disabling the warning with -Wno-type-limits works as a temporary solution, but
this also makes finding potential bugs in non-template code more difficult.
Regards,
Jason.
--
Summary: Templates with -Wtype-limits produces warnings.
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: crossroads at googlemail dot com
GCC build triplet: x86_64-linux-elf
GCC host triplet: x86_64-linux-elf
GCC target triplet: x86_64-linux-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
[Bug preprocessor/36453] PR36320 breaks boost
--- 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 my Boost libraries right now. > > So, is there a way that I can tell gcc to ignore this warning for now? No. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
[Bug fortran/40949] FAIL: gfortran.dg/proc_ptr_7.f90
--- 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 Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40949
[Bug c++/44021] Templates with -Wtype-limits produces warnings.
--- 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 make sense to have a template that can handle unsigned integers with negative values so I want to be warned if I write such code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- 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 constraint. Thus: All valid programs should work. TODO: Clean up and maybe extend test cases. Error print fix (likely to be deferred to PR 39695) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20567|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- 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 "wrong" with the patch: It accidentally also contains the patch for PR 43945 (resolve.c, cf. http://gcc.gnu.org/ml/fortran/2010-05/msg00037.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug target/43493] exception ignores catch-clause when std::ostringstream helps in throwing
--- 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 less code pieces, it's still deterministic) with GCC 4.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43493
[Bug middle-end/44020] [4.6 regression] Failed to build 200.sixtrack in SPEC CPU 2K
--- 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|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-07 09:40:01 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44020
[Bug rtl-optimization/44012] [4.5/4.6 Regression] ICE: SIGSEGV in ira_merge_allocno_live_ranges
--- 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 Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44012
[Bug bootstrap/44019] xgcc: error trying to exec '/test/gnu/gcc/objdir/./prev-gcc/gnat1': execv: Not e
--- 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 Version|4.5.0 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44019
[Bug inline-asm/44018] Using cpuid.h, can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
--- 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
[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags
--- 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_handle_option): Fix long line. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/misc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40989
[Bug fortran/44022] New: Spurious 'unused parameter' for a used procedure argument
> 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 LOGICAL, EXTERNAL :: SELECT DGEES_SELECTH = SELECT() END FUNCTION DGEES_SELECTH > gfortran -Wunused-parameter -c used_dummy.f90 used_dummy.f90:1:0: warning: unused parameter select Does PR40039 already fix this? -- Summary: Spurious 'unused parameter' for a used procedure argument Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mathewc at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44022
[Bug c++/44021] Templates with -Wtype-limits produces warnings.
--- 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 added additional types (which the standard allows). Also, it would completely defeat the purpose of having templates in the first place. So template specialization is not really a good solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
[Bug middle-end/44020] [4.6 regression] Failed to build 200.sixtrack in SPEC CPU 2K
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44020
[Bug middle-end/44020] [4.6 regression] Failed to build 200.sixtrack in SPEC CPU 2K
--- 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/44020 * tree-ssa-pre.c (execute_pre): Do not remove dead inserted code when PRE is not yet initialized. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44020
[Bug c++/44021] Templates with -Wtype-limits produces warnings.
--- 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
[Bug inline-asm/44018] Using cpuid.h, can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
--- 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.cgi?id=44018
[Bug c++/44021] Templates with -Wtype-limits produces warnings.
--- 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
[Bug debug/44023] New: -fcompare-debug failure (length) for alphaev67 target
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 -S -O2 -fcompare-debug sha1.i xgcc: sha1.i: -fcompare-debug failure (length) -- Summary: -fcompare-debug failure (length) for alphaev67 target Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC target triplet: alphaev67-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44023
[Bug debug/44023] -fcompare-debug failure (length) for alphaev67 target
--- 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 failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44023
[Bug inline-asm/44018] Using cpuid.h, can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
--- 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 CC||hjl dot tools at gmail dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-07 13:08:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44018
[Bug fortran/44022] Spurious 'unused parameter' for a used procedure argument
--- 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_dgees_selecth;
__result_dgees_selecth.0 = select ();
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org,
||burnus at gcc dot gnu dot
||org
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44022
[Bug c/44024] New: missed optimization
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 The new behaviour is actually the correct one, but it points out that the change had unintentional effects. Richard asked me to create his bug for him to investigate. -- Summary: missed optimization Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: rguenther at suse dot de ReportedBy: espindola at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44024
[Bug c++/44021] Templates with -Wtype-limits produces warnings.
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
[Bug c++/11856] unsigned warning in template
--- 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 CC||crossroads at googlemail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug rtl-optimization/44025] New: Multiple load 0 to register
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:
ldrbr5, [r3], #1@ zero_extendqisi2
cmp r5, #10
itt eq
moveq r1, r3
strbeq r0, [r3, #-1]
subsr2, r2, #1
.L2:
cmp r2, #0
bgt .L4
cmp r1, r4
bne .L8
movsr3, #0 //B
strbr3, [r1, #512] //C
b .L1
.L8:
ldr r3, [r4, #520]
addsr3, r4, r3
cmp r1, r3
bcc .L7
movsr3, #0 //D
str r3, [r4, #520] //E
b .L1
.L7:
subsr5, r1, r4
mov r0, r4
mov r2, r5
bl memmove
str r5, [r4, #520]
.L1:
pop {r3, r4, r5, pc}
Instructions B load constant 0 into register r3, and instruction C store 0 into
memory. Actually instruction A has already loaded 0 into register r0, and at
instruction C it is still available, so we can use r0 directly in instruction C
and remove B. Register r2 also contains 0 at instruction C, but it is more
difficult to detect. R0 can also be used at instruction E and remove D.
When compile with -O2 the result is similar.
Should this be handled by any cse pass and rematerialize it if there is high
register pressure?
--
Summary: Multiple load 0 to register
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
[Bug rtl-optimization/44025] Multiple load 0 to register
--- 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
[Bug bootstrap/44019] xgcc: error trying to exec '/test/gnu/gcc/objdir/./prev-gcc/gnat1': execv: Not e
--- 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 memory. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44019
[Bug c/44024] missed optimization
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenther at suse dot de|rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-07 13:46:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44024
[Bug c++/30566] -Wshadow warns about clashes between nested function parameters in C++
--- 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 CC||msebor at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30566
[Bug c++/41825] useless -Wshadow warning on function argument in local class
--- 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 Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41825
[Bug fortran/44026] New: Segfault on internal read with -malign-double
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.1.2-48.el5.i386) on slc5. Under Ubuntu9 gfortran 4.4.1: % gfortran -malign-double ttest.f && ./a.out Segmentation fault Under SLC4 gfortran 4.3.3: % gfortran -malign-double ttest.f && ./a.out Bad input 1 iostat -1 ival = 4685168 -- ttest.f -- program ttest implicit none integer ival, ierr character*1 str str = "1" read(str,*,iostat=ierr) ival if (ierr.ne.0) then write(0,*) 'Bad input ',str,' iostat',ierr endif write(0,*) 'ival = ', ival end -- EOF -- Regards, Igor -- Summary: Segfault on internal read with -malign-double Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Igor dot Katchaev at cern dot ch GCC build triplet: gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) GCC host triplet: Linux pcbecn 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:0 GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44026
[Bug fortran/44026] Segfault on internal read with -malign-double
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44026
[Bug fortran/44027] New: Segfault on internal read with -malign-double
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.1.2-48.el5.i386) on slc5. Under Ubuntu9 gfortran 4.4.1: % gfortran -malign-double ttest.f && ./a.out Segmentation fault Under SLC4 gfortran 4.3.3: % gfortran -malign-double ttest.f && ./a.out Bad input 1 iostat -1 ival = 4685168 -- ttest.f -- program ttest implicit none integer ival, ierr character*1 str str = "1" read(str,*,iostat=ierr) ival if (ierr.ne.0) then write(0,*) 'Bad input ',str,' iostat',ierr endif write(0,*) 'ival = ', ival end -- EOF -- Regards, Igor -- Summary: Segfault on internal read with -malign-double Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Igor dot Katchaev at cern dot ch GCC build triplet: gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) GCC host triplet: Linux pcbecn 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:0 GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44027
[Bug fortran/44026] Segfault on internal read with -malign-double
--- 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 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44026
[Bug fortran/40728] Bogus error "Error: Can't convert UNKNOWN to REAL(8) at (1)"
--- 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/40728 * intrinc.c (gfc_is_intrinsic): Do not prematurely mark symbol as external gcc/testsuite/: 2010-05-07 Daniel Franke PR fortran/40728 * gfortran.dg/coarray_1.f90: Fixed error message. * gfortran.dg/selected_char_kind_3.f90: Fixed error message. * gfortran.dg/intrinsic_std_1.f90: Fixed bogus message. * gfortran.dg/intrinsic_std_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_std_5.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_std_1.f90 trunk/gcc/testsuite/gfortran.dg/selected_char_kind_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40728
[Bug debug/44023] -fcompare-debug failure (length) for alphaev67 target
--- 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
[Bug fortran/44026] Segfault on internal read with -malign-double
--- 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
[Bug fortran/44027] Segfault on internal read with -malign-double
--- 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-1314
) the option -malign-double does:
"Control whether GCC aligns double, long double, and long long variables on a
two word boundary or a one word boundary" ("On x86-64, -malign-double is
enabled by default.")
But it also states:
"Warning: if you use the -malign-double switch, structures containing the
above types will be aligned differently than the published application binary
interface specifications for the 386 and will not be binary compatible with
structures in code compiled without that switch."
This includes in particular all libraries - and in particular the GNU Fortran
run-time library (libgfortran) but also the system's C library (libc, e.g.
GLIBC) and math library (libm). Depending what your program and what the
library is doing, a program might work, might not work or might more or less
silently fail.
Of course one could recompile all libraries, but the simpler solution is:
Simply avoid the flag -m(no-)align-double.
As this is a somewhat regularly recurring problem, it was suggested to enable a
warning in the front end (i.e. in the Fortran part of GCC). However, as this is
a target-dependent option, getting the warning right (e.g. warn on x86 for
-malign-double and on x86-64 for -mno-align-double while on non-x86 platforms
the flag does not even exist ...) was seen as too cumbersome and convoluted to
be useful and thus no warning was added.
*** This bug has been marked as a duplicate of 44026 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44027
[Bug debug/44023] -fcompare-debug failure (length) for alphaev67 target
--- 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_debug_add, dead_debug_insert_before): Likewise. (df_note_bb_compute): Initialize a dead_debug object, add dead debug uses to it, insert debug bind insns before death insns, reset debug insns that refer to pending uses at the end. * rtl.h (make_debug_expr_from_rtl): New prototype. * varasm.c (make_debug_expr_from_rtl): New function. [1] http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00112.html -- ubizjak at gmail dot com changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44023
[Bug rtl-optimization/44028] New: -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns
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 -- Summary: -fcompare-debug failure (length) with -O3 -fsched- pressure -fschedule-insns Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44028
[Bug c++/43951] [4.6 Regression] Revision 158918 miscompiled 483.xalancbmk in SPEC CPU 2006
--- 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_cst_or_ref_member_1): Returns the error count. Emit errors only if compain is true. (build_new_1): Do not return error_mark_node if diagnose_uninitialized_cst_or_ref_member_1 does not diagnose any errors. Delay the check for user-provided constructor. (perform_member_init): Adjust. * cp-tree.h (diagnose_uninitialized_cst_or_ref_member): Change the prototype. Added: trunk/gcc/testsuite/g++.dg/init/new29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43951
[Bug rtl-optimization/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44028
[Bug lto/43857] -fresolution causes an ICE
--- 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|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43857
[Bug lto/43857] -fresolution causes an ICE
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43857
[Bug driver/43371] Add -fresolution to the list of switches that take arguments
--- 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_SPEC): Provide a resolution file to the linker plugin. (store_arg): Queue temp_filename for deletion instead of the whole argument. lto/ PR lto/43857 PR lto/43371 * lang.opt (fresolution): Change to ... (fresolution=): ... this. * lto-lang.c (lto_handle_option): Adjust. lto-plugin/ * lto-plugin.c (free_2): Do not free resolution_file. (write_resolution): Check that we were passed a resolution file. (all_symbols_read_handler): Adjust. (cleanup_handler): Do not remove the resolution file. (process_option): Handle -fresolution=. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lang.opt trunk/gcc/lto/lto-lang.c trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43371
[Bug lto/43857] -fresolution causes an ICE
--- 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_SPEC): Provide a resolution file to the linker plugin. (store_arg): Queue temp_filename for deletion instead of the whole argument. lto/ PR lto/43857 PR lto/43371 * lang.opt (fresolution): Change to ... (fresolution=): ... this. * lto-lang.c (lto_handle_option): Adjust. lto-plugin/ * lto-plugin.c (free_2): Do not free resolution_file. (write_resolution): Check that we were passed a resolution file. (all_symbols_read_handler): Adjust. (cleanup_handler): Do not remove the resolution file. (process_option): Handle -fresolution=. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lang.opt trunk/gcc/lto/lto-lang.c trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43857
[Bug driver/43371] Add -fresolution to the list of switches that take arguments
--- 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|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43371
[Bug fortran/41219] libgfortran build warnings
--- 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 Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug debug/44023] -fcompare-debug failure (length) for alphaev67 target
--- 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_bug.cgi?id=44023
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- 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 that I might need go back to the drawing board. The following is currently not handled: a) Constraint check (cf. comment 3 [F03: C489, F08: C496]): the component-spec-list has to be different from the interface of any of the generic procedures (i.e. an actual-arg-spec-list matching the component-spec-list shall not match any of the generic functions). Note: This included handling default initializers as they act as optional arguments. b) The algorithm does not handle: Define function in one module,* define type in a different module, and use associate them [including constraint checking, cf. (a)]. Currently, the renaming is only handled if either the generic interface or the derived type is available before the other type is declared. (* That's possible because the functions do not need to return the derived type - even though that's the most common case.) I probably solve this by renaming derived types to @ and automatically generating an associated generic function with the specific name @ and a dummy arg list [including DT parents (plural)]. One needs to modify gfc_typename to print the type without @ and then one has also no problem with the trailing @ sign. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20592|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/41977] gfortran -fopenmp and ACML_MP seem incompatible
--- 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
[Bug debug/44023] -fcompare-debug failure (length) for alphaev67 target
--- 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 registers: -Reloads for insn # 583 +Reloads for insn # 697 Reload 0: reload_out (DI) = (reg:DI 789) GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0) reload_out_reg: (reg:DI 789) - reload_reg_rtx: (reg:DI 28 $28) + reload_reg_rtx: (reg:DI 0 $0) Reload 1: reload_in (DI) = (reg/v/f:DI 81 [ endp ]) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 2) reload_in_reg: (reg/v/f:DI 81 [ endp ]) - reload_reg_rtx: (reg:DI 28 $28) + reload_reg_rtx: (reg:DI 0 $0) [...] -Reloads for insn # 475 +Reloads for insn # 556 Reload 0: reload_in (SI) = (const_int -1894007588 [0x8f1bbcdc]) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 2), can't combine reload_in_reg: (reg:SI 795) - reload_reg_rtx: (reg:SI 28 $28) + reload_reg_rtx: (reg:SI 24 $24) [...] -Reloads for insn # 514 +Reloads for insn # 598 Reload 0: reload_in (SI) = (reg:SI 725) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1) reload_in_reg: (reg:SI 725) - reload_reg_rtx: (reg:SI 8 $8) + reload_reg_rtx: (reg:SI 27 $27) [...] -Reloads for insn # 584 +Reloads for insn # 698 Reload 0: reload_in (DI) = (reg:DI 789) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 2) reload_in_reg: (reg:DI 789) - reload_reg_rtx: (reg:DI 12 $12) + reload_reg_rtx: (reg:DI 1 $1) -Reloads for insn # 586 +Reloads for insn # 700 Reload 0: reload_in (DI) = (reg/v/f:DI 287 [ ctx ]) GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0) reload_in_reg: (reg/v/f:DI 287 [ ctx ]) - reload_reg_rtx: (reg:DI 13 $13) + reload_reg_rtx: (reg:DI 2 $2) Reload 1: reload_out (SI) = (mem/s:SI (reg/v/f:DI 287 [ ctx ]) [4 ctx_13(D)->A+0 S4 A32]) NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional reload_out_reg: (mem/s:SI (reg/v/f:DI 287 [ ctx ]) [4 ctx_13(D)->A+0 S4 A32]) -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44023
[Bug debug/44023] -fcompare-debug failure (length) for alphaev67 target
--- 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=0x8f1bbcdc
-$17:SI=$23:SI+$28:SI
+$24:SI=0x8f1bbcdc
+$17:SI=$23:SI+$24:SI
[...]
-$8:SI=[$30:DI+0x68]
-$24:SI=$8:SI+$25:SI
+$27:SI=[$30:DI+0x68]
+$24:SI=$27:SI+$25:SI
[...]
-$12:DI=[$30:DI+0x70]
-pc={($12:DI==0)?L598:pc}
+$1:DI=[$30:DI+0x70]
+pc={($1:DI==0)?L712:pc}
[...]
-$13:DI=[$30:DI+0x80]
-[$13:DI]=$9:SI
+$2:DI=[$30:DI+0x80]
+[$2:DI]=$9:SI
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44023
[Bug fortran/41219] libgfortran build warnings
--- 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
[Bug fortran/43711] Unformitive error message for two NOWAIT in OpenMP directive
--- 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 whole matching
sequence, { "end sections" "nowait" end-of-string } and returns to the last
known locus, here just after the "$omp".
67 if (m != MATCH_YES)
68{
69 gfc_current_locus = *old_locus;
70 reject_statement ();
71}
If line 69 is removed, one gets:
pr43711.f90:8.31:
!$omp end sections nowait nowait
1
Error: Unclassifiable OpenMP directive at (1)
But everything else is broken ^^
This is not specific for nowait, but for all OpenMP related things that
explicitly check for end-of-string.
I believe, this is eventually the same as PR32365.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-suse-linux |
GCC host triplet|x86_64-suse-linux |
GCC target triplet|x86_64-suse-linux |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43711
[Bug target/43708] [4.6 Regression] gcc.dg/pragma-darwin.c "set not used", not working with pragma
--- 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_unused): Set DECL_READ_P in addition to TREE_USED, to avoid "set but unused" warnings. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-c.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43708
[Bug target/43708] [4.6 Regression] gcc.dg/pragma-darwin.c "set not used", not working with pragma
--- 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 |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43708
[Bug fortran/43711] Unformitive error message for two NOWAIT in OpenMP directive
--- 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
===
--- openmp.c(revision 159154)
+++ openmp.c(working copy)
@@ -54,6 +54,8 @@ gfc_match_omp_eos (void)
return MATCH_YES;
}
+ gfc_error("Unexpected junk at end of OMP statement at %C");
+
gfc_current_locus = old_loc;
return MATCH_NO;
}
This gives:
$> gfortran-svn -g -Wall -W -fopenmp pr43711.f90
pr43711.f90:8.33:
!$omp end sections nowait nowait
1
Error: Unexpected junk at end of OMP statement at (1)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-05-07 17:41:39
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43711
[Bug fortran/41219] libgfortran build warnings
--- 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 'write_default_char4' discards qualifiers from pointer target type", because write_default_char4() accepts a gfc_char4_t* but we are sending it a const gfc_char4_t*. Easiest solution would be constifying the second arg of write_default_char4(), as well as that of write_utf8_char4() for that matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug rtl-optimization/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns
--- 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:XF
-{r127:XF=float(r150:SI);clobber [frame:DI-0x44];}
-REG_DEAD: r150:SI
[...]
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-05-07 17:46:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44028
[Bug rtl-optimization/44012] [4.5/4.6 Regression] ICE: SIGSEGV in ira_merge_allocno_live_ranges
--- 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 finished. It depends on region configuration and order of allocnos with the same regno in the corresponding list. The sigsegv occurs in the second case when we remove allocno and propagates this info through allready removed allocno. It happens because regno_allocno_map which is used to find allocno into which the info to propagate is not nullified after removing allocno. H.J.'s patch idea is right but the patch is complicated. I'll send a simplier patch soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44012
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- 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 > --- > Viola! Something happens now! Thanks for fixing this. Great! Sure, no problem. Let me know if you need help with anything in the profile extension. In particular, let me know if there's a class of diagnostics you'd like added to the few ones already there, or if you find bugs in the current diagnostics. Silvius -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug fortran/43289] Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram
--- 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
[Bug fortran/39289] Reject VOLATILE in PURE
--- 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 Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39289
[Bug fortran/43539] internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:995
--- 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: Function 'c_sizeof' at (1) has no IMPLICIT type Fixed by the patch for PR40728. Nothing specific to C_SIZEOF. *** This bug has been marked as a duplicate of 40728 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43539
[Bug fortran/40728] Bogus error "Error: Can't convert UNKNOWN to REAL(8) at (1)"
--- 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 CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40728
[Bug ada/44029] New: References from GNAT RM to GNAT UG are broken
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://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_rm/Pragma-No_005fStrict_005fAliasing.html#Pragma-No_005fStrict_005fAliasing and follow the link at the end to http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_ugn/Optimization-and-Strict-Aliasing.html#Optimization-and-Strict-Aliasing -- which gives a 404. It should be http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_ugn_unw/Optimization-and-Strict-Aliasing.html#Optimization-and-Strict-Aliasing -- Summary: References from GNAT RM to GNAT UG are broken Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon at pushface dot org GCC build triplet: n/a GCC host triplet: n/a GCC target triplet: n/a http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44029
[Bug fortran/40881] warn for obsolescent features
--- 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 |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881
[Bug fortran/40876] OpenMP private variable referenced in a statement 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 |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
[Bug c/44030] New: error: SSA name in freelist but still referenced
[reg...@bethe tmp601]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r159144-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --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 'func':
small.c:14:1: error: SSA name in freelist but still referenced
pretmp.6_10
small.c:24:7: note: in statement
g_54.1_5 = pretmp.6_10;
small.c:14:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[reg...@bethe tmp601]$ cat small.c
typedef int int32_t;
typedef unsigned int uint32_t;
static uint32_t
safe_sub_func_uint32_t_u_u (uint32_t ui1, uint32_t ui2)
{
return ui1 - ui2;
}
int32_t l_105[7];
int32_t g_4;
int32_t *g_54 = &g_4;
int32_t *
func (int32_t p_73, int32_t * p_74, int32_t p_75, int32_t * *p_76,
int32_t * *p_77)
{
lbl_110:for (g_4 = 0; g_4; g_4 = 1)
{
}
for (p_75 = -28; p_75; p_75 = safe_sub_func_uint32_t_u_u (p_75, 1))
{
if (g_4)
goto lbl_110;
*g_54 = 0;
}
return &l_105[5];
}
--
Summary: error: SSA name in freelist but still referenced
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44030
[Bug fortran/40875] ICE with illegal type conversion
--- 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 Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40875
[Bug fortran/40158] Misleading error message for passing a scalar to an array
--- 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 CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40158
[Bug other/44016] Old link inside the documentation
--- 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 documentation/44016 * doc/standards.texi (Standards): Link to unversioned cxx0x_status.html page. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/standards.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44016
[Bug fortran/36497] USE association, cray pointers and error checking
--- 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
[Bug other/44016] Old link inside the documentation
--- 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 documentation/44016 * doc/standards.texi (Standards): Link to unversioned cxx0x_status.html page. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/doc/standards.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44016
[Bug other/44016] Old link inside the documentation
--- 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 documentation/44016 * doc/standards.texi (Standards): Link to unversioned cxx0x_status.html page. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/doc/standards.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44016
[Bug other/44016] Old link inside the documentation
--- 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 |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44016
[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces
--- 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 both the gdb and gcc docs and cannot find any mention of (modern) machines/systems/situations where this is not supported; given that the required attributes are missing it seems like a gcc problem (feeding the .s file to gas doesn't help, so I doubt it's the sun assembler/linker, either) gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.4.0/configure --prefix=/export/home/ryanjohn/apps/gcc-4.4.0 --with-gmp=/export/home/ryanjohn/apps --with-mpfr=/export/home/ryanjohn/apps --without-gnu-ld --without-gnu-as Thread model: posix gcc version 4.4.0 (GCC) -- scovich at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED GCC host triplet||sparc-sun-solaris2.10 Known to fail||4.4.0 Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43828
[Bug debug/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns
--- 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++;
a |= (a >> 30);
d = (d << 30) | ((unsigned) d >> 30);
c = (c << 30) | ((unsigned) c >> 30);
b = 30 | ((unsigned) b >> 30);
d += a = (a << 30) | ((unsigned) a >> 2);
c += ((d << 5) | (d >> 27)) + ((e & (a ^ b))) + 0x5a827999 + x[12];
a += (c & e);
c = 30 | ((unsigned) c);
i = x[5] ^ x[7] ^ x[8] ^ x[3];
x[5] = (i << 1) | ((unsigned) i >> 31);
i = x[6] ^ x[2] ^ x[14] ^ x[13];
x[6] = (i << 1) | (i >> 31);
b += (c | (c >> 5)) + (d ^ e) + 0x6ed9eba1
+ (x[7] = (i << 1) | ((unsigned) i >> 31));
x[8] = i | 1;
e += (a | 5) + b + (i = x[9] ^ x[6], x[10] = (i << (unsigned) i));
e = 30 | ((unsigned) e >> 30);
i = x[12] ^ x[14] ^ x[12] ^ x[12], (x[12] = 1 | ((unsigned) i));
i = x[13] ^ x[5] ^ x[10], (x[13] = (i << (unsigned) 1));
i = x[2] ^ x[7] ^ x[12], (x[15] = i | ((unsigned) i >> 1));
i = x[2] ^ x[0] ^ x[13], (x[0] = (i << 1) | 31);
e = (e << 30) | 2;
i = x[14] ^ x[2] ^ x[15], (x[2] = i | 1);
x[3] = i | ((unsigned) i);
i = x[14] ^ x[12] ^ x[4], (x[4] = 1 | ((unsigned) i >> 1));
x[5] = i | 1;
e = (e << 30) | 30;
b += (5 | ((unsigned) e >> 5)) + 0x8f1bbcdc
+ (x[9] = (i | ((unsigned) i >> 1)));
i = x[2] ^ (x [10] = ((i << 1) | (i >> 1)));
x[13] = (i | ((unsigned) i >> 1));
(i = x[14] ^ x[0] ^ x[14], (x[14] = ((i << 1) | 31)));
a = *w += a;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44028
[Bug debug/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns
--- 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
[Bug fortran/37212] TRANSFER: Simplify array argument
--- 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 gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37212
[Bug debug/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns
--- 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
[Bug debug/44023] -fcompare-debug failure (length) for alphaev67 target
--- 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++;
a |= (a >> 30);
d = (d << 30) | ((unsigned) d >> 30);
c = (c << 30) | ((unsigned) c >> 30);
b = 30 | ((unsigned) b >> 30);
d += a = (a << 30) | ((unsigned) a >> 2);
c += ((d << 5) | (d >> 27)) + ((e & (a ^ b))) + 0x5a827999 + x[12];
a += (c & e);
c = 30 | ((unsigned) c);
i = x[5] ^ x[7] ^ x[8] ^ x[3];
x[5] = (i << 1) | ((unsigned) i >> 31);
i = x[6] ^ x[2] ^ x[14] ^ x[13];
x[6] = (i << 1) | (i >> 31);
b += (c | (c >> 5)) + (d ^ e) + 0x6ed9eba1
+ (x[7] = (i << 1) | ((unsigned) i >> 31));
x[8] = i | 1;
e += (a | 5) + b + (i = x[9] ^ x[6], x[10] = (i << (unsigned) i));
e = 30 | ((unsigned) e >> 30);
i = x[12] ^ x[14] ^ x[12] ^ x[12], (x[12] = 1 | ((unsigned) i));
i = x[13] ^ x[5] ^ x[10], (x[13] = (i << (unsigned) 1));
i = x[2] ^ x[7] ^ x[12], (x[15] = i | ((unsigned) i >> 1));
i = x[2] ^ x[0] ^ x[13], (x[0] = (i << 1) | 31);
e = (e << 30) | 2;
i = x[14] ^ x[2] ^ x[15], (x[2] = i | 1);
x[3] = i | ((unsigned) i);
i = x[14] ^ x[12] ^ x[4], (x[4] = 1 | ((unsigned) i >> 1));
x[5] = i | 1;
e = (e << 30) | 30;
b += (5 | ((unsigned) e >> 5)) + 0x8f1bbcdc
+ (x[9] = (i | ((unsigned) i >> 1)));
i = x[2] ^ (x [10] = ((i << 1) | (i >> 1)));
x[13] = (i | ((unsigned) i >> 1));
(i = x[14] ^ x[0] ^ x[14], (x[14] = ((i << 1) | 31)));
a = *w += a;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44023
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- 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 Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug c/44030] error: SSA name in freelist but still referenced
--- 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 CC||matz at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-07 20:52:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44030
[Bug c/44030] [4.6 Regression] error: SSA name in freelist but still referenced
-- 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
[Bug tree-optimization/44030] [4.6 Regression] error: SSA name in freelist but still referenced
--- 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_...@.mem_13(D) (0003)
Inserted pretmp.6_10 = g_54;
in predecessor 2
Created phi prephitmp.7_15 = PHI
in block 6
Replaced redundant PHI node defining prephitmp.7_20 with prephitmp.7_15
Replaced g_54 with prephitmp.7_15 in g_54.1_5 = g_54;
Replaced redundant PHI node defining prephitmp.7_15 with pretmp.6_10
Removing unnecessary insertion:pretmp.6_10 = g_54;
Removing unnecessary insertion:pretmp.6_26 = g_54;
oops. It looks like the necessity propagation does not work for
the prephitmp.7_15 replacement.
Before eliminate():
lbl_110:
g_4 = 0;
pretmp.6_10 = g_54;
goto ;
:
:
# p_75_22 = PHI
# prephitmp.7_20 = PHI
g_4.0_4 = g_4;
if (g_4.0_4 != 0)
goto ;
else
goto ;
:
g_54.1_5 = g_54;
*g_54.1_5 = 0;
p_75.2_6 = (uint32_t) p_75_22;
D.1987_17 = p_75.2_6 + 0x0;
p_75_8 = (int32_t) D.1987_17;
if (p_75_8 != 0)
goto ;
else
goto ;
:
return &l_105[5];
:
# prephitmp.7_15 = PHI
pretmp.6_26 = g_54;
goto ;
:
g_4 = 0;
goto ;
and before remove_dead_inserted_code():
lbl_110:
g_4 = 0;
pretmp.6_10 = g_54;
goto ;
:
:
# p_75_22 = PHI
g_4.0_4 = g_4;
if (g_4.0_4 != 0)
goto ;
else
goto ;
:
g_54.1_5 = pretmp.6_10;
*g_54.1_5 = 0;
p_75.2_6 = (uint32_t) p_75_22;
D.1987_17 = p_75.2_6 + 0x0;
p_75_8 = (int32_t) D.1987_17;
if (p_75_8 != 0)
goto ;
else
goto ;
:
return &l_105[5];
:
pretmp.6_26 = g_54;
goto ;
:
g_4 = 0;
goto ;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Component|c |tree-optimization
Last reconfirmed|2010-05-07 20:52:13 |2010-05-07 20:57:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44030
[Bug fortran/41137] inefficient zeroing of an array
--- 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
[Bug fortran/40598] Some missed optimizations in array assignment
--- 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 CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598
[Bug c/44031] New: ice in subst_reloads, at reload.c:6327
[reg...@bethe tmp600]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r159144-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --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 'int321':
small.c:35:1: internal compiler error: in subst_reloads, at reload.c:6327
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[reg...@bethe tmp600]$ cat small.c
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
typedef unsigned long int uint64_t;
static uint32_t
safe_add_func_uint32_t_u_u (uint32_t ui1, uint32_t ui2)
{
return ui1 + ui2;
}
static uint64_t
safe_div_func_uint64_t_u_u (uint64_t ui1, uint32_t ui2)
{
return ui2 ? : (ui1 / ui2);
}
uint8_t g_55;
uint8_t *g_73 = &g_55;
uint8_t **g_332 = &g_73;
int func_38(uint8_t *,int);
int func_8(int);
int int321 (void)
{
uint8_t l_26[4];
uint8_t *l_238 = &l_26[2];
uint8_t l_400;
l_400 &=
func_38 (&l_26[3],
safe_add_func_uint32_t_u_u (safe_div_func_uint64_t_u_u
(1, **g_332),
*l_238) >= *l_238 < func_8 (0)), 1;
return 0;
}
--
Summary: ice in subst_reloads, at reload.c:6327
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031
[Bug tree-optimization/44030] [4.6 Regression] error: SSA name in freelist but still referenced
--- 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|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-07 20:57:29 |2010-05-07 21:14:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44030
[Bug target/44031] [4.6 Regression] ice in subst_reloads, at reload.c:6327
-- 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 |subst_reloads, at ||reload.c:6327 Target Milestone|--- |4.6.0 Version|unknown |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031
[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces
--- 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;
int foo(int a) {
return a + global;
}
int bar(int a) {
return global + foo(a);
}
int baz(int a) {
return global + bar(a);
}
int main(int argc, char const* argv[]) {
return global + baz(argc);
}
Running it in gdb will seem to begin execution at exit from bar:
Dump of assembler code for function main:
0x000106cc <+0>: sethi %hi(0x20800), %g1
0x000106d0 <+4>: ld [ %g1 + 0x124 ], %g4! 0x20924
=> 0x000106d4 <+8>: ld [ %g1 + 0x124 ], %g3
0x000106d8 <+12>:ld [ %g1 + 0x124 ], %g2
0x000106dc <+16>:ld [ %g1 + 0x124 ], %g1
0x000106e0 <+20>:add %g4, %g1, %g1
0x000106e4 <+24>:add %g1, %g3, %g1
0x000106e8 <+28>:add %g1, %g2, %g1
0x000106ec <+32>:retl
0x000106f0 <+36>:add %g1, %o0, %o0
End of assembler dump.
Apparently someone made the reasonable judgment call that it was better to only
"enter" inlined functions once rather than jumping around, and even then only
if code from later in the containing function hasn't already run. Putting a
printf in foo() gave the expected result.
--
scovich at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WORKSFORME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43828
[Bug fortran/40899] Leakage with derived types with ALLOCATABLE components
--- 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
[Bug tree-optimization/43425] gcc should vectorize this loop by substitution
--- 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)
{
int i;
a[0] = b[0]; /* + t if t live before this point */
for(i=1; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43425
[Bug tree-optimization/43423] gcc should vectorize this loop through if-conversion
--- 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 stores
> > "a[i] = ..."
>
> If we rewrite the code like:
> int a[100], b[100], c[100];
>
> void foo(int n, int mid)
> {
> int i;
> for(i=0; i {
> int t;
> int ai = a[i], bi = b[i], ci = c[i];
> if (i < mid)
> t = ai + bi;
> else
> t = ai + ci;
> a[i] = t;
> }
> }
>
> --- CUT ---
> This gets vectorized as we produce an if-cvt first.
>
There are both correctness and performance issues in the re-written code.
b[i] or c[i] may not be executed in the original loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
[Bug other/44032] New: internals documentation is not legally safe to use
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 with a compatible license in order to be usable in a safe manner. -- Summary: internals documentation is not legally safe to use Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: blocker Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032
[Bug fortran/40876] OpenMP private variable referenced in a statement function
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
