[Bug libstdc++/51749] Including algorithm pollute global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-07 08:10:31 UTC --- 4.8.
[Bug tree-optimization/51780] New: Missed optimization for ==/!= comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51780
Bug #: 51780
Summary: Missed optimization for ==/!= comparison
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kti...@gcc.gnu.org
Target: *-*-*
Hi,
optimization misses to eliminate addition for 'b' in following code:
extern unsigned int ar[256];
int foo (int a, unsigned int b)
{
int c = ar[a] + b;
int d = (int) b;
return c != d;
}
compiled this code with -O2 we get tree-optimized as follwing:
;; Function foo (foo, funcdef_no=0, decl_uid=1600, cgraph_uid=0)
foo (int a, unsigned int b)
{
int d;
int c;
_Bool D.2717;
int D.2716;
unsigned int D.2715;
unsigned int D.2714;
bb 2:
D.2714_2 = ar[a_1(D)];
D.2715_4 = D.2714_2 + b_3(D);
c_5 = (int) D.2715_4;
d_6 = (int) b_3(D);
D.2717_7 = c_5 != d_6;
D.2716_8 = (int) D.2717_7;
L0:
return D.2716_8;
}
but optimized variant should be:
;; Function foo (foo, funcdef_no=0, decl_uid=1709, cgraph_uid=0)
foo (int a, unsigned int b)
{
_Bool D.1717;
int D.1716;
unsigned int D.1714;
bb 2:
D.1714_2 = ar[a_1(D)];
D.1717_7 = D.1714_2 != 0;
D.1716_8 = (int) D.1717_7;
return D.1716_8;
}
[Bug tree-optimization/51781] New: Missed optimization for ==/!= comparison type-sinking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51781
Bug #: 51781
Summary: Missed optimization for ==/!= comparison type-sinking
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kti...@gcc.gnu.org
Target: *-*-*
The following code shows an issue about missed optimization for ==/!=
comparisons.
extern unsigned char ar[256];
int foo (int x, int y)
{
int i = (int) ar[x];
return (i == (y 0xff));
}
Compiled with 4.7 using -O2 we get the following optimized tree:
;; Function foo (foo, funcdef_no=0, decl_uid=1600, cgraph_uid=0)
foo (int x, int y)
{
int i;
_Bool D.2716;
int D.2715;
int D.2714;
unsigned char D.2713;
bb 2:
D.2713_2 = ar[x_1(D)];
i_3 = (int) D.2713_2;
D.2715_5 = y_4(D) 255;
D.2716_6 = D.2715_5 == i_3;
D.2714_7 = (int) D.2716_6;
return D.2714_7;
}
But to be expected would be:
;; Function foo (foo, funcdef_no=0, decl_uid=1709, cgraph_uid=0)
foo (int x, int y)
{
unsigned char D.1719;
_Bool D.1716;
int D.1714;
unsigned char D.1713;
bb 2:
D.1713_2 = ar[x_1(D)];
D.1719_9 = (unsigned char) y_4(D);
D.1716_6 = D.1713_2 == D.1719_9;
D.1714_7 = (int) D.1716_6;
return D.1714_7;
}
[Bug lto/50490] ICE when compiling libglib2.0 with LTO, tree code 'optimization_node' is not supported in LTO streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50490 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Volker Reichelt reichelt at gcc dot gnu.org 2012-01-07 11:02:54 UTC --- Fixed by Richard's patch.
[Bug tree-optimization/51782] New: Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782
Bug #: 51782
Summary: Missing address-space information leads to wrong code
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: addr-space, wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr
This is a bug with named address spaces trunk gcc 4.7 for the following source.
struct rgb { char r, g, b; };
char read_rgb_ok (const __pgm struct rgb *s)
{
return s-r + s-g + s-b;
}
char read_rgb_bug (const __pgm struct rgb *s)
{
struct rgb t = *s;
return t.r + t.g + t.b;
}
Reading through *s must happen by means of LPM instructions (reading from
flash) and not by menas of LD instructions (reading from RAM).
However, the second function reads from RAM.
== Command Line ==
avr-gcc a-bug.c -S -Os -mmcu=avr4 -dp -fverbose-asm -v \
-fdump-tree-optimized -fdump-tree-original -fdump-rtl-expand
-fdump-tree-gimple
== configure ==
Generated from 4.7.0 sources (HEAD) from 2012-01-03 SVN 182900
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7-mingw32 --host=i386-mingw32
--build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared
--disable-lto --disable-checking --disable-libquadmath --with-dwarf2
Thread model: single
gcc version 4.7.0 20120102 (experimental) (GCC)
[Bug tree-optimization/51782] Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-07 CC||flamorce at videotron dot ||ca Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug tree-optimization/51782] Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-07 12:05:20 UTC --- Created attachment 26262 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26262 a-bug.c C source file triggering the bug.
[Bug tree-optimization/51782] Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-07 12:08:25 UTC --- Created attachment 26263 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26263 a-bug.s (assembler output) read_rgb_ok uses LPM instructions to read data (okay) read_rgb_bug uses LD/LDD instructions to read data (wrong)
[Bug tree-optimization/51783] New: Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783
Bug #: 51783
Summary: Missed optimization for X ==/!= (signed type)
((unsigned type) Y + Z)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kti...@gcc.gnu.org
Target: *-*-*
Hi,
for the following example shows the missed optimization
extern int ar[256];
int foo (int x, int y, unsigned int z)
{
int c = (int) ((unsigned int) x + z);
return y == c;
}
We produce in 4.7 for -O2 the following optimized gimple tree:
;; Function foo (foo, funcdef_no=0, decl_uid=1601, cgraph_uid=0)
foo (int x, int y, unsigned int z)
{
int c;
_Bool D.2717;
int D.2716;
unsigned int D.2715;
unsigned int x.0;
bb 2:
x.0_2 = (unsigned int) x_1(D);
D.2715_4 = z_3(D) + x.0_2;
c_5 = (int) D.2715_4;
D.2717_7 = y_6(D) == c_5;
D.2716_8 = (int) D.2717_7;
return D.2716_8;
}
But we could expect in this case:
;; Function foo (foo, funcdef_no=0, decl_uid=1710, cgraph_uid=0)
foo (int x, int y, unsigned int z)
{
int D.1720;
int c;
_Bool D.1717;
int D.1716;
bb 2:
D.1720_10 = (int) z_3(D);
c_5 = x_1(D) + D.1720_10;
D.1717_7 = y_6(D) == c_5;
D.1716_8 = (int) D.1717_7;
return D.1716_8;
}
[Bug tree-optimization/51782] Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-07 12:09:41 UTC --- Created attachment 26264 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26264 a-bug.c.003t.original a-bug.c.003t.original tree-dump, FYI
[Bug tree-optimization/51782] Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-07 12:11:03 UTC --- Created attachment 26265 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26265 a-bug.c.004t.gimple a-bug.c.004t.gimple tree-dump, FYI
[Bug tree-optimization/51782] Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-07 12:11:50 UTC --- Created attachment 26266 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26266 a-bug.c.149t.optimized a-bug.c.149t.optimized tree dump, FYI
[Bug tree-optimization/51782] Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-07 12:17:21 UTC --- Created attachment 26267 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26267 a-bug.c.150r.expand a-bug.c.150r.expand RTL dump, FYI As you can see in read_rgb_ok that move insns 8, 9, 13 are reading from AS1 which is __pgm. This code is correct In read_rgb_bug, insns 8, 9 and 13 are reading from generic address space brcause there is no address space information. This code is wrong.
[Bug target/43745] [avr] g++ puts VTABLES in SRAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||addr-space Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-07 Version|4.3.5 |4.7.0 Ever Confirmed|0 |1
[Bug target/49857] Put constant switch-tables into flash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||addr-space Target Milestone|--- |4.8.0
[Bug c++/51755] -Wconversion generates false warnings when the ternary operator is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51755 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-01-07 13:03:54 UTC --- (In reply to comment #6) Thus by 'opposite' of 'complete' you mean that nothing should be *added* to the patch, instead something removed from it? Great. You see I meant completing Yes. But probably the patch needs to be substantially changed. And you should check with Joseph whether he is happy with the additional complexity added. *the work*, thus committing and closing the PR. Anyway, Manuel, would you be willing to send over a patch answeing Joseph' concerns? Otherwise I'll try to do it myself, but probably it will take more time because I have start from scratch on this. Thanks! Sorry, I don't have enough free time to do this. Also, I am not sure anymore that it is worth to add these checks to gcc, which is not meant to be a static analysis tool or be used to build one. GCC FEs are very limited in the kind of analysis they can make, and this seems to be on purpose. It would be better to focus on scan-build http://clang-analyzer.llvm.org/scan-build.html or build a GPL static analyzer on top of clang.
[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-07 14:06:22 UTC --- I think that's the same issue as PR 51103, PR 51343, PR 51343. Typically those errors occur if MPFR does not work (for various reasons). However, there seems to be a particular issue with MacOS. Andrew wrote in the other PRs: Darwin's GCC can sometimes produce a broken MPRF. This is not a GCC bug.
[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-07 14:08:11 UTC --- I forgot to mention that there exist also unofficial binaries for MacOS at: http://gcc.gnu.org/wiki/GFortranBinaries#MacOS Thus, that could be an alternative to fixing the MPFR issue.
[Bug middle-end/51784] New: [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Bug #: 51784 Summary: [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution,-fprofile-generate -D_PROFILE_GENERATE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ja...@redhat.com Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 At revision 182975 on x86_64-apple-darwin10, the test gcc.dg/tree-prof/pr44777.c fails with a segmentation fault: Program received signal SIGSEGV, Segmentation fault. 0x900949d9 in __findenv () from /usr/lib/libSystem.B.dylib (gdb) bt #0 0x900949d9 in __findenv () from /usr/lib/libSystem.B.dylib #1 0x90094971 in getenv () from /usr/lib/libSystem.B.dylib #2 0x2640 in gcov_exit () at ../../../../work/libgcc/libgcov.c:334 #3 0x900b1c0a in __cxa_finalize () from /usr/lib/libSystem.B.dylib #4 0x900b1b14 in exit () from /usr/lib/libSystem.B.dylib #5 0x1cc8 in main () at /opt/gcc/work/gcc/testsuite/gcc.dg/tree-prof/pr44777.c:42 Although the test has been introduced at revision 182920, I have marked it as a regression since there is no segmentation fault at revision 182587.
[Bug gcov-profile/51715] [4.7 Regression] FAIL: gcc.misc-tests/gcov-13.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51715 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-01-07 15:27:22 UTC --- Author: danglin Date: Sat Jan 7 15:27:15 2012 New Revision: 182981 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182981 Log: PR gcov-profile/51715 PR gcov-profile/51717 * gcc.misc-tests/gcov-13.c: Skip on 32-bit hppa*-*-hpux*. * gcc.misc-tests/gcov-14.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.misc-tests/gcov-13.c trunk/gcc/testsuite/gcc.misc-tests/gcov-14.c
[Bug gcov-profile/51717] [4.7 Regression] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51717 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-01-07 15:27:22 UTC --- Author: danglin Date: Sat Jan 7 15:27:15 2012 New Revision: 182981 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182981 Log: PR gcov-profile/51715 PR gcov-profile/51717 * gcc.misc-tests/gcov-13.c: Skip on 32-bit hppa*-*-hpux*. * gcc.misc-tests/gcov-14.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.misc-tests/gcov-13.c trunk/gcc/testsuite/gcc.misc-tests/gcov-14.c
[Bug c++/51785] New: gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 Bug #: 51785 Summary: gets not anymore declared Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: drepper@gmail.com glibc 2.15 and later don't declare gets anymore for ISO C11 mode and if _GNU_SOURCE is defined. This causes problems with the cstdio header which unconditionally uses using ::gets; Something has to be done about this. If you want glibc to define a macro to signal that gets is not declared let me know. Otherwise recognize __USE_GNU. The problem still applies to the trunk.
[Bug gcov-profile/51717] [4.7 Regression] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51717 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2012-01-07 15:33:50 UTC --- Fixed.
[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||fxcoudert at gcc dot ||gnu.org, howarth at bromo ||dot med.uc.edu --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-07 15:34:28 UTC --- You may try to configure mpfr with --disable-thread-safe: see http://news.gmane.org/gmane.os.apple.fink.devel .
[Bug gcov-profile/51715] [4.7 Regression] FAIL: gcc.misc-tests/gcov-13.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51715 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2012-01-07 15:34:27 UTC --- Fixed.
[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu 2012-01-07 16:02:51 UTC --- On Sat, Jan 07, 2012 at 07:31:46AM +, zippy at anl dot gov wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779 --- Comment #2 from Tim Williams zippy at anl dot gov 2012-01-07 07:31:46 UTC --- (In reply to comment #1) What is the complete path for the gcc sources? /Users/zippy/Downloads/gcc-4.6.2/ What is the complete path for where you tried to build gcc? /Users/zippy/Downloads/gcc-4.6.2/build2 This might be a part of your problem. Others have noted that there are known issues with MacOS Loin. What is the configure command line you used? ../configure --prefix=$HOME/zippy_gcc --enable-checking=release --with-gmp=$HOME/zippy_gcc --with-mpfr=$HOME/zippy_gcc --with-mpc=$HOME/zippy_gcc --program-prefix=zippy- If helpful, I was using instructions from this blog as a guide (almost certainly I am doing/configuring something wrong---no implication that these instructions are wrong or that the blogger is in any way responsible): http://solarianprogrammer.com/2011/12/01/compiling-gcc-4-6-2-on-mac-osx-lion/ Try reading http://gcc.gnu.org/install/
[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-07 16:11:50 UTC --- Well, the problem here is that we compile with -O2 and function is not declared inline. Conequetely GCC inlines only when it thinks code size will shrink. Inliner always works one step at a time and it does not know that inlining process_fun_at is important to inline to inline add. We now have estimate_edge_devirt_benefit that I fixed last week to also notice indirect calls like this one. Unfortunately it is still not enough, since inliner won't get past the idea that replacing a call by two calls is increasing code size. For 4.8 I plan to include logic that allows to bypass the limits when inlining is known to be profitable, but I don't see much to do in 4.7 timeframe. 4.6 early inlined it more due to accounting bug. Honza
[Bug c++/51786] New: [c++0x] Invalid declaration with decltype accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51786
Bug #: 51786
Summary: [c++0x] Invalid declaration with decltype accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The error message declaration does not declare anything is not
triggered in certain cases when using decltype:
===
struct A {};
void foo() { decltype(A()); }
===
It *is* triggered if I write decltype(int) instead.
Another testcase is the following:
===
templateint struct A
{
A() { decltype(this); }
};
A0 a;
===
It *is* triggered if I make A a non-template class.
This bug is similar to PR21120 where the same problems occured with typeof.
[Bug c++/21120] Empty declaration with typeof accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21120 --- Comment #5 from Volker Reichelt reichelt at gcc dot gnu.org 2012-01-07 16:21:08 UTC --- Well, decltype has the same problems, so I opened a new bug report, see PR51786.
Product Samples .
Hello , We are currently searching for high-tech manufacturers and suppliers who are able to produce and supply the exact quality products on our website. Aicom group international is a leading industrial and commercial company based in vietnam founded in 1987, and has been existing in business since then. And it's proud of it's track record of prompt and dependable services . I am really interested in your products,kindly send me your catalog .Please inform me about the Minimum Order Quantity Delivery time Payment terms warranty . Your early reply is highly appreciated . Thank You . Thank you. Ghislaine Schryburt ( Miss ) . Email: b.iv...@postino.net .
[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-07 17:30:24 UTC --- Well, on second thought, we already have logic for -Os and cold calls that COMDAT functions are unlikely to be shared across compilation units. There is nothing that prevents us from enabling this also for -O2. Additionally Maxim's code has thinko in it disabling itself for indirect calls in many cases. Obviously this will still break when process_fun_at will be called more than one in the unit. But that is for 4.8. I am testing patch.
[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 18:25:19 UTC --- I think that would be an invalid transformation except when -fwrapv is used. The reason is: x.0_2 = (unsigned int) x_1(D); D.2715_4 = z_3(D) + x.0_2; --- wrapping semantics c_5 = (int) D.2715_4; While: D.1720_10 = (int) z_3(D); c_5 = x_1(D) + D.1720_10; Was undefined semantics for overflow. This cannot happen until we have signed operations which also have wrapping semantics.
[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-01-07 18:55:05 UTC --- Well, IMHO it is still valid in the case of argument of ne/eq comparison, as indeed here sign and wrap-around doesn't matter.
[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 18:57:52 UTC --- (In reply to comment #2) Well, IMHO it is still valid in the case of argument of ne/eq comparison, as indeed here sign and wrap-around doesn't matter. Maybe for this exact IR but what happens if someone later on used c somewhere else? Anyways I don't think this is a missed optimization at all because the code produced will be the same as PLUS_EXPR for both unsigned and signed int types will be expanded the same. The only thing that is removed is the cast which is a nop here.
[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-07 19:02:06 UTC --- FYI, the miscompilation of MPFR 3.1.0's tis support by clang is resolved in Xcode 4.2.1. This was radar://10291355, Xcode 4.2 miscompiles tls support in MPFR 3.1.0.
[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783 --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-01-07 19:04:13 UTC --- Hmm, here I disagree. See other ==/!= comparison missed optimization. Eg for 'x == (signed type)((unsigned type) x + z)' the transformation is profitable, as it allows later on reduction in comparison. This transformation leads to 'x == x + (int) z', which can be later on transformed to 'z == 0'.
[Bug c++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-01-07 19:05:28 UTC --- I thought this was fixed in glibc: http://sourceware.org/bugzilla/show_bug.cgi?id=13566 ?
[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779 --- Comment #8 from Tim Williams zippy at anl dot gov 2012-01-07 20:24:20 UTC --- (In reply to comment #7) FYI, the miscompilation of MPFR 3.1.0's tis support by clang is resolved in Xcode 4.2.1. This was radar://10291355, Xcode 4.2 miscompiles tls support in MPFR 3.1.0. Thanks, Jack. I should've been more specific: I am using Xcode 4.2.1. I'll try recompiling mpfr, and maybe try configuring mpfr with --disable-thread-safe as Dominique suggested.
[Bug bootstrap/51787] New: [4.7.0 Regression] internal compiler error: in inline_small_functions, at ipa-inline.c:1410
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787 Bug #: 51787 Summary: [4.7.0 Regression] internal compiler error: in inline_small_functions, at ipa-inline.c:1410 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: dougmenc...@gmail.com I'm trying to get GCC 4.7. Latest weekly snapshot done Dec 31, 2011 (gcc-v4.7-20111231) fails to bootstrap on stage2: /root/build-farm/_gcc_bootstrap/./prev-gcc/g++ -B/root/build-farm/_gcc_bootstrap/./prev-gcc/ -B/usr/powerpc-gnu-linux-uclibc/bin/ -nostdinc++ -B/root/build-farm/_gcc_bootstrap/prev-powerpc-gnu-linux-uclibc/libstdc++-v3/src/.libs -B/root/build-farm/_gcc_bootstrap/prev-powerpc-gnu-linux-uclibc/libstdc++-v3/libsupc++/.libs -I/root/build-farm/_gcc_bootstrap/prev-powerpc-gnu-linux-uclibc/libstdc++-v3/include/powerpc-gnu-linux-uclibc -I/root/build-farm/_gcc_bootstrap/prev-powerpc-gnu-linux-uclibc/libstdc++-v3/include -I/root/build-farm/gcc-v4.7-20111231.sourcedir/libstdc++-v3/libsupc++ -L/root/build-farm/_gcc_bootstrap/prev-powerpc-gnu-linux-uclibc/libstdc++-v3/src/.libs -L/root/build-farm/_gcc_bootstrap/prev-powerpc-gnu-linux-uclibc/libstdc++-v3/libsupc++/.libs -c -O3 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-v4.7-20111231.sourcedir/gcc -I../../gcc-v4.7-20111231.sourcedir/gcc/. -I../../gcc-v4.7-20111231.sourcedir/gcc/../include -I../../gcc-v4.7-20111231.sourcedir/gcc/../libcpp/include -I../../gcc-v4.7-20111231.sourcedir/gcc/../libdecnumber -I../../gcc-v4.7-20111231.sourcedir/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc-v4.7-20111231.sourcedir/gcc/cgraph.c -o cgraph.o In file included from ../../gcc-v4.7-20111231.sourcedir/gcc/cgraph.c:3060:0: ./gt-cgraph.h:66:2: internal compiler error: in inline_small_functions, at ipa-inline.c:1410 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [cgraph.o] Error 1 make[3]: Leaving directory `/root/build-farm/_gcc_bootstrap/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/root/build-farm/_gcc_bootstrap' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/root/build-farm/_gcc_bootstrap' make: *** [all] Error 2 ERROR: stage2 bootstrap error. Abort. I'm building everything with -O3. Configure line: ../gcc-v4.7-20111231.sourcedir/configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc --host=powerpc-gnu-linux-uclibc --target=powerpc-gnu-linux-uclibc --enable-languages=c,c++,fortran,java --enable-stage1-languages=c,c++,fortran --with-cpu=default32 --enable-threads=posix --with-system-zlib --with-libiconv-prefix=/usr --without-included-gettext --disable-nls --disable-werror --disable-multilib --disable-libssp --disable-__cxa_atexit --enable-shared --without-gjdoc --enable-libgcj --enable-libgcj-multifile --enable-interpreter --disable-libjava-multilib --disable-browser-plugin --enable-checking=release stage0's gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-gnu-linux-uclibc/4.6.1/lto-wrapper Target: powerpc-gnu-linux-uclibc Configured with: ../gcc-v4.6.1.sourcedir/configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc --host=powerpc-gnu-linux-uclibc --target=powerpc-gnu-linux-uclibc --enable-languages=c,c++,fortran,java --with-cpu=default32 --enable-threads=posix --with-system-zlib --with-libiconv-prefix=/usr --disable-nls --disable-werror --disable-multilib --disable-libssp --disable-__cxa_atexit --disable-checking --enable-shared --without-gjdoc --enable-libgcj --enable-libgcj-multifile --enable-interpreter --disable-libjava-multilib --disable-browser-plugin Thread model: posix gcc version 4.6.1 (GCC) cgraph.ii is attached. Lines 1399-1416 from ipa-inline.c: 1399: /* Be sure that caches are maintained consistent. 1400: We can not make this ENABLE_CHECKING only because it cause differnt 1401: updates of the fibheap queue. */ 1402: cached_badness = edge_badness (edge, false); 1403: reset_edge_growth_cache (edge); 1404: reset_node_growth_cache (edge-callee); 1405: 1406: /* When updating the edge costs, we only decrease badness in the keys. 1407: Increases of badness are handled lazilly; when we see key with out 1408: of date value on it, we re-insert it now. */ 1409: current_badness = edge_badness (edge, false); 1410: gcc_assert (cached_badness == current_badness); 1411: gcc_assert (current_badness = badness); 1412: if (current_badness != badness)
[Bug bootstrap/51787] [4.7.0 Regression] internal compiler error: in inline_small_functions, at ipa-inline.c:1410
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787 --- Comment #1 from Douglas Mencken dougmencken at gmail dot com 2012-01-07 20:48:15 UTC --- Created attachment 26268 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26268 pre-processed output of last failed operation (compressed)
[Bug bootstrap/51787] [4.7.0 Regression] internal compiler error: in inline_small_functions, at ipa-inline.c:1410
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-07 21:07:39 UTC --- Works for me with GCC 4.7.0 20120107 (experimental) [trunk revision 182980] on x86-64-linux (with and without -m32; without one gets the error cast from 'void*' to 'size_t' loses precision). I used the following flags but also some variants: g++ -O3 -gtoggle -m32 -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -c -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings cgraph.ii
[Bug middle-end/40386] wrong code generation for several SPEC CPU2000 benchmarks (lucas, mgrid, face, applu, apsi) with -O1 -fno-ira-share-spill-slots
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.5 --- Comment #14 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 21:31:58 UTC --- Fixed.
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-07 21:33:27 UTC --- Looks like an OS bug, not GCC bug, if getenv segfaults...
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725 --- Comment #20 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-01-07 21:37:20 UTC --- Author: aoliva Date: Sat Jan 7 21:37:15 2012 New Revision: 182982 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182982 Log: PR bootstrap/51725 * cselib.c (new_elt_loc_list): Promote addr_list to canonical node. Add canonical node to containing_mem chain after the non-canonical one, even if there weren't any locs to propagate. (remove_useless_values): Keep only canonical values. (add_mem_for_addr, cselib_lookup_mem): Canonicalize addr. (cselib_invalidate_mem): Likewise. Ensure v is canonical, and canonicalize mem_chain elements that are not discarded. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c
[Bug middle-end/40135] using alias-set zero for union accesses necessary because of RTL alias oracle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40135 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-07 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 21:41:20 UTC --- Confirmed.
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
--- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-07
22:14:15 UTC ---
See also discussion starting at
http://j3-fortran.org/pipermail/j3/2008-December/002123.html
Fortran 2003 has in 16.1 Scope of global identifiers
Program units, common blocks, external procedures, and entities with binding
labels are global entities of a program. The name of a program unit, common
block, or external procedure is a global identifier and shall not be the same
as the name of any other such global entity in the same program, except that an
intrinsic module may have the same name as another program unit, common block,
or external procedure in the same program. A binding label of an entity of the
program is a global identifier and shall not be the same as the binding label
of any other entity of the program; nor shall it be the same as the name of any
other global entity of the program that is not an intrinsic module, ignoring
differences in case. An entity of the program shall not be identified by more
than one binding label.
Fortran 2008 has in 16.2 Global identifiers - the {}/{} was added by
me for emphasis.
Program units, common blocks, external procedures, entities with binding
labels, external input/output units, pending data transfer operations, and
images are global entities of a program. The name of a common block with no
binding label, external procedure {}with no binding label{}, or program
unit that is not a submodule is a global identifier. The submodule identifier
of a submodule is a global identifier. A binding label of an entity of the
program is a global identifier. An entity of the program shall not be
identified by more than one binding label.
The global identifier of an entity shall not be the same as the global
identifier of any other entity. Furthermore, a binding label shall not be the
same as the global identifier of any other global entity, ignoring differences
in case.
See also: http://www.j3-fortran.org/doc/year/08/08-295.txt ; we might need to
handle also COMMON /foo/ where foo is also no global identifier any more.
(I don't know whether one needs to handle it somewhere.)
Cf. also
http://j3-fortran.org/doc/year/08/08-196.txt
http://j3-fortran.org/doc/year/08/08-187.txt
F03/0076 at http://j3-fortran.org/doc/year/08/08-006Ar4.txt
[Bug fortran/35161] [F2008] allow procedures with same binding label (invalid in F2003)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35161 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-07 22:15:51 UTC --- Mark as duplicate of PR 48858 - which has in PR 48858 comment 9 a better description why it is valid in F2008 - and links to an IR which confirms the invalidity in F2003. *** This bug has been marked as a duplicate of bug 48858 ***
[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.8.0 --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 22:16:57 UTC --- (In reply to comment #10) FWIW the problem is still there and prevents any 32bit kernel LTO builds -freg-struct-return changes the ABI so I don't think this is testcase is valid. Can someone explain why -freg-struct-return used not on the link line also?
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-07 22:15:51 UTC --- *** Bug 35161 has been marked as a duplicate of this bug. ***
[Bug fortran/51788] New: Unstable gfc_verify_binding_labels check for a binding label which collides with a global entity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51788
Bug #: 51788
Summary: Unstable gfc_verify_binding_labels check for a binding
label which collides with a global entity
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Blocks: 51578
Found when trying to create a patch for PR 51578. Seemingly, the generated tree
is now slightly different.
The problem is that the test case
gfortran.dg/binding_label_tests_10_main.f03
fails with my patch - without, one gets the following.
However, if one swaps the lines
use binding_label_tests_10_main
use binding_label_tests_10 ! { dg-error collides }
I get now an error with my patch - but none with the unpatched GCC.
Hence, the test case is not stable. At least with my patch it fails in
resolve.c's gfc_verify_binding_labels as:
if (sym-attr.if_source == IFSRC_DECL
is not fulfilled. The reason is that symbols loaded from .mod files are have
IFSRC_UNKNOWN.
A proper error message looks as follows:
gfortran.dg/binding_label_tests_10_main.f03:11.6:
use binding_label_tests_10 ! { dg-error collides }
1
gfortran.dg/binding_label_tests_10_main.f03:7.45:
integer(c_int), bind(c,name=c_one) :: one ! { dg-error collides }
2
Error: Binding label 'c_one' at (1) collides with global entity 'c_one' at (2)
(Cf. PR 48858 comment 9 for some information about binding labels.)
[Bug c/50720] deprecated doesn't work as expected for functions returning pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50720 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 22:23:37 UTC --- struct foo * __attribute__ ((deprecated)) old_fn1a(); The attribute there applies to the pointer ...
[Bug target/50766] Binutils 2.22.51 rejects bmi2 pext operation with memory operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 22:25:39 UTC --- Fixed.
[Bug target/50572] unstable performance on Atom due to loop alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50572 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 22:27:50 UTC --- Fixed.
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, wrong-code --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-07 22:30:44 UTC --- (In reply to comment #9) we might need to handle also COMMON /foo/ Example for a now (F2008) valid programs: a) Currently rejected - but shouldn't since F2008 use iso_c_binding contains subroutine one() bind(C, name=com1) :: /foo/ integer(c_int) :: a common /foo/ a end subroutine subroutine two() bind(C, name=com2) :: /foo/ integer(c_long) :: a common /foo/ a end subroutine two end b) For the following program no error is printed - but one gets: Warnung: Named COMMON block 'foo' at (1) shall be of the same size as elsewhere (4 vs 8 bytes) which is surprising as one should generate one common block with assembler name foo_ and one with assembler name com1. Currently only one is generated (which has either the name com1 or foo_): use iso_c_binding contains subroutine one() bind(C, name=com1) :: /foo/ integer(c_int) :: a common /foo/ a end subroutine subroutine two() integer(c_long) :: a common /foo/ a end subroutine two end
[Bug c++/51402] [4.6/4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51402 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-07 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 22:34:32 UTC --- Confirmed.
[Bug c++/51433] constexpr caching leads to incorrect dynamic initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51433 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-07 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 22:36:18 UTC --- Confirmed.
[Bug c++/51219] ICE with designated initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51219 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-07 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 22:38:13 UTC --- Confirmed.
[Bug tree-optimization/51084] bounds checking not optimized to a single comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51084 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-07 Component|middle-end |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07 22:39:53 UTC --- Confirmed.
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-07 22:40:07 UTC --- Looks like an OS bug, not GCC bug, if getenv segfaults... Well, revision 182587 uses the same OS and does not segfault. Also 'exit (0)' is used in many tests that pass.
[Bug c++/51789] New: GCC does not consider SFINAE in template parameter list of template parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51789
Bug #: 51789
Summary: GCC does not consider SFINAE in template parameter
list of template parameter pack
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
This code should not be accepted, but GCC accepts it
struct A {
template
typename ...T,
templatetypename std::enable_if
std::is_sameT, int::value, int
::type ...
class...
A(T...);
};
A a = {1, 2.0, 3};
[Bug fortran/51788] Unstable gfc_verify_binding_labels check for a binding label which collides with a global entity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51788
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-07
23:15:58 UTC ---
The problems is that:
if ((sym-attr.use_assoc bind_c_sym-mod_name
strcmp (bind_c_sym-mod_name, sym-module) != 0)
is not true as the gsym and the sym are for the same symbol.
However, one has an ambiguity:
(gdb) p sym-ns-sym_root-right-right-name
$44 = 0x2cc36018 one
(gdb) p sym-ns-sym_root-right-right-ambiguous
$45 = 1
This ambiguity will later lead to:
Error: Name 'one' at (1) is an ambiguous reference to 'one'
if one tries to reference the variable.
I do not see a good solution but as the ambiguity is diagnosed if one tries to
reference the variable, I am tempted to use the following patch:
--- a/gcc/testsuite/gfortran.dg/binding_label_tests_10_main.f03
+++ b/gcc/testsuite/gfortran.dg/binding_label_tests_10_main.f03
@@ -7 +7 @@ module binding_label_tests_10_main
- integer(c_int), bind(c,name=c_one) :: one ! { dg-error collides }
+ integer(c_int), bind(c,name=c_one) :: two ! { dg-error collides }
--- a/gcc/testsuite/gfortran.dg/binding_label_tests_11_main.f03
+++ b/gcc/testsuite/gfortran.dg/binding_label_tests_11_main.f03
@@ -8,2 +8,2 @@ contains
- function one() bind(c, name=c_one) ! { dg-error collides }
-integer(c_int) one
+ function two() bind(c, name=c_one) ! { dg-error collides }
+integer(c_int) two
@@ -11 +11 @@ contains
- end function one
+ end function two
[Bug fortran/51790] New: Broken ambiguity check when combining generic with nongeneric procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51790
Bug #: 51790
Summary: Broken ambiguity check when combining generic with
nongeneric procedures
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Blocks: 51578
Another bug which blocks my progress with PR 51578.
If one compiles
gfortran.dg/generic_11.f90
one gets the error:
call foo ! { dg-error is an ambiguous reference }
1
Error: Name 'foo' at (1) is an ambiguous reference to 'foo' from module
'm_foo'
However, if one swaps the order of
use m_foo
use m_bar
no error is printed.
The reason is that in symbol's gfc_find_sym_tree one has the check:
if (st-ambiguous !st-n.sym-attr.generic)
{
ambiguous_symbol (name, st);
However, one of the foo is generic and the other isn't. Thus, depending which
one is first in the symtree, an error is printed or not.
[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-07 23:35:13 UTC --- Author: hubicka Date: Sat Jan 7 23:35:08 2012 New Revision: 182983 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182983 Log: PR tree-optimization/51680 * ipa-inline.c (want_inline_small_function_p): Be more lax on functions whose inlining reduce unit size. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug tree-optimization/51600] [4.7 Regression] ice in estimate_local_effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51600 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-08 00:17:01 UTC --- Fixed.
[Bug tree-optimization/51600] [4.7 Regression] ice in estimate_local_effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51600 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-08 00:16:28 UTC --- Author: hubicka Date: Sun Jan 8 00:16:18 2012 New Revision: 182984 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182984 Log: PR tree-optimization/51600 * ipa-inline-analysis.c (estimate_edge_devirt_benefit): Disable code that benefits small functions. Added: trunk/gcc/testsuite/g++.dg/torture/pr51600.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-analysis.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602 --- Comment #12 from Andi Kleen andi-gcc at firstfloor dot org 2012-01-08 01:37:29 UTC --- LTO saves the options in the object files and collects them for the final link. This works as far as I know. The only thing it cannot handle is different incompatible options in different files (but that's more a limitation in LTO than incorrect code). The test case doesn't do that. I disagree with your assessment that the test case is invalid. Please undo it.
