[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53701 --- Comment #5 from Mikael Pettersson 2012-07-27 07:14:20 UTC --- Unfortunately r177658 seems to be the cause of wrong-code PR53975.
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #21 from François Dumont 2012-07-27 07:57:59 UTC --- I haven't touch the grow speed for the moment. I prefer to fix the reserve Standard conformity first. Now I can restore the 4.6 grow speed as it seems to be a relatively correct one. Note that 3x slower with so many more rehash operations doesn't seem so bad ! Of course growing faster will also induce higher memory consumption which is not shown by the simple benchmark proposed here.
[Bug c++/54101] Using std::declval for types without a default constructor and with a deleted copy constructor errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54101 --- Comment #2 from Jonathan Wakely 2012-07-27 08:05:40 UTC --- Yes, I was thinking the same thing, PR 53000
[Bug c/54103] New: ICE at gimplify.c:7790 on current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54103
Bug #: 54103
Summary: ICE at gimplify.c:7790 on current trunk
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mer...@savhon.org
Hello !
Joseph on PR53418 suggested me to file this as a different bug, so here it is.
GCC as of 4.8-20120722, 4.7-20120721, 4.6-20120720, and 4.5-20120628 (thanks to
Mikael Pettersson for testing all those versions) appears to trigger an ICE
while compiling the following testcase :
$ cat ice.c
void f(void)
{
0 || 0 / 0 ? : 0;
}
$ gcc -w ice.c
ice.c: In function ‘f’:
ice.c:3:12: internal compiler error: in gimplify_expr, at gimplify.c:7790
0 || 0 / 0 ? : 0;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug c++/54104] New: no default argument for 'XXX'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54104
Bug #: 54104
Summary: no default argument for 'XXX'
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: likan_999.stud...@sina.com
The following piece of code doesn't compile under gcc 4.7.1 with flag
-std=gnu++11:
template struct X {};
template class P = X, typename U>
void f(const U& m) {
auto g = [] () {};
}
Clang accepts it correctly.
If I remove the line `auto g=...', it compiles successfully.
I am not an expert to standard. So can anyone take a look, and confirm whether
it is a bug of clang or a bug of gcc? Thanks.
[Bug c/53418] [4.5 Regression] ICE at gimplify.c:7773
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53418 --- Comment #13 from Antoine Balestrat 2012-07-27 08:51:54 UTC --- Filed as PR54103.
[Bug c++/54104] Parser error for lambda expression if function template has default parameter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54104
--- Comment #1 from likan_999.student at sina dot com 2012-07-27 09:04:49 UTC
---
The example can be further reduced to:
template
void f(const U& m) {
auto g = [] () {};
}
[Bug c++/54104] Parser error for lambda expression if function template has default parameter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54104 --- Comment #2 from likan_999.student at sina dot com 2012-07-27 09:06:48 UTC --- BTW: the compiler error is c.cpp: In function 'void f(const U&)': c.cpp:3:15: error: no default argument for 'U'
[Bug c++/54104] Parser error for lambda expression if function template has default parameter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54104 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-27 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 Severity|critical|normal --- Comment #3 from Jonathan Wakely 2012-07-27 09:31:17 UTC --- I think the code is valid. U doesn't need a default template argument, as per DR 226 [temp.param]/11 only applies to class templates and alias templates, not function templates. G++ accepts the code if the lamdba isn't present or if U has a default template-argument. It seems that seen_def_arg_p needs to be reset before parsing the lambda expression.
[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53787 --- Comment #10 from Martin Jambor 2012-07-27 09:34:41 UTC --- (In reply to comment #9) > Shouldn't IPA-CP be able to do this already? It does appear to handle > CONST_DECLs already... Only if it finds them in the call statement itself, it relies on early constant propagation to get the constants there. But (AFAIK) nothing propagates (even scalar) constants through non-gimple-registers and n is not a register because it has its address taken.
[Bug c++/54104] Parser error for lambda expression if function template has default parameter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54104 --- Comment #4 from likan_999.student at sina dot com 2012-07-27 09:58:50 UTC --- @Jonathan Wakely, thanks for the fast response. Can you assign it to an appropriate person?
[Bug c++/54104] Parser error for lambda expression if function template has default parameter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54104 --- Comment #5 from Jonathan Wakely 2012-07-27 10:04:37 UTC --- I already CC'd a C++ maintainer, he will assign it to himself if works on it.
[Bug c++/54104] Parser error for lambda expression if function template has default parameter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54104 --- Comment #6 from likan_999.student at sina dot com 2012-07-27 10:19:11 UTC --- @Jonathan Wakely, thanks a lot :-)
[Bug c++/53792] [C++11][constexpr] improving compiler-time constexpr evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53792 --- Comment #4 from vincenzo Innocente 2012-07-27 10:47:49 UTC --- is "__attribute__((always_inline)) " not making foo to transform in foo2 in a very early compiler's stage? I can make getV a macro if helps: I do not like SetV due to its "not natural" syntax
[Bug testsuite/54105] New: FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54105 Bug #: 54105 Summary: FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: r...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 The test gcc.target/i386/asm-dialect-1.c (revision 189854) fails on x86_64-apple-darwin10: FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) Excess errors: /opt/gcc/work/gcc/testsuite/gcc.target/i386/asm-dialect-1.c:1:0: error: -masm=intel not supported in this configuration The test should be skipped on targets not supporting -masm=intel.
[Bug target/54106] New: OMAP3: encountered a blocking structure assignment, occurring only on OMAP3 processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54106 Bug #: 54106 Summary: OMAP3: encountered a blocking structure assignment, occurring only on OMAP3 processors Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: wolfgang.hauser.exter...@cassidian.com Created attachment 27880 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27880 Example causing the problem and showing the workarround Hello, we use an structure assignment, containing a int64 variable (example: line 79), in our project which runs on any systems using an Intel processor, using the same source on an OMAP3 the assignment blocks/breaks the processing.(see attached little test program). If we replace this structure assignment by assigning the values of the structure step by step, especially assigning the int64 value using an helping structure containing int32 variables, the processing work fine on the OMAP3 too. What we encountered: OMAP3 (oma3evm (mistral) and beagleboard): kernel 2.6.32 (linux-omap-psp-2.6.32 Openembedded: branch 2011.03-maintenance): processing was blocked kernel 2.6.37 (android gingerbread+extensions): processing breaks with bus error INTEL: Debian lenny/squeeze, Opensuse, SLES, Windows -> no problems at all What we use to build the program: Openembedded SDK (derived from meta-toolchain.bb) Branch: 2011.03-maintenance Distro: angstrom Compiler command: arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb --sysroot=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi -g -O2 -Wall -Wno-long-long -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wswitch -Wunused -Wuninitialized -D__arch__=32 -fPIC -Wsynth -Wreorder -Wnon-virtual-dtor -Woverloaded-virtual -pedantic -c -o blocking_assignment_test.o blocking_assignment_test.cpp Linker command arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb --sysroot=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi -o blocking_assignment_test blocking_assignment_test.o Compiler version (GCC) 4.5.3 20110223 (prerelease) eglibc Version: libc-2.12.2.so Our question now: What cause this problem ? compiler, eglibc, kernel, OMAP3 ? Is it eventually impossible to fit this structure assignment on an OMAP3 ? Is there a solution to solve the problem w/o our workaround ? Compiler,eglibc,kernel ?? Some patches ? Usage of the example program: Calling w/o an argument -> blocking behavior Calling argument -w -> working workaround Compiler Infos: Using built-in specs. COLLECT_GCC=arm-angstrom-linux-gnueabi-gcc Target: arm-angstrom-linux-gnueabi Configured with: /angstrom/temp/warrior21_angstrom/work/i686-armv7a-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.5-r33.2+svnr170443/gcc-4_5-branch/configure --build=i686-linux --host=i686-linux --target=arm-angstrom-linux-gnueabi --prefix=/usr/local/angstrom/arm --exec_prefix=/usr/local/angstrom/arm --bindir=/usr/local/angstrom/arm/bin --sbindir=/usr/local/angstrom/arm/bin --libexecdir=/usr/local/angstrom/arm/libexec --datadir=/usr/local/angstrom/arm/share --sysconfdir=/usr/local/angstrom/arm/etc --sharedstatedir=/usr/local/angstrom/arm/share/com --localstatedir=/usr/local/angstrom/arm/var --libdir=/usr/local/angstrom/arm/lib --includedir=/usr/local/angstrom/arm/include --oldincludedir=/usr/local/angstrom/arm/include --infodir=/usr/local/angstrom/arm/share/info --mandir=/usr/local/angstrom/arm/share/man --with-libtool-sysroot --disable-largefile --disable-nls --enable-ipv6 --with-gnu-ld --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-sysroot=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi --with-build-time-tools=/angstrom/temp/warrior21_angstrom/sysroots/i686-linux/usr/armv7a/arm-angstrom-linux-gnueabi/bin --with-build-sysroot=/angstrom/temp/warrior21_angstrom/sysroots/armv7a-angstrom-linux-gnueabi --disable-libunwind-exceptions --with-mpfr=/angstrom/temp/warrior21_angstrom/sysroots/i686-linux/usr --with-system-zlib --enable-__cxa_atexit Thread model: posix gcc version 4.5.3 20110223 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-march=armv7-a' '-mtune=cortex-a8' '-mfpu=neon' '-mfloat-abi=softfp' '-mthumb-interwork' '-mno-thumb' '-v' '-c' /usr/local/angstrom/arm/libexec/gcc/arm-angstrom-linux-gnueabi/4.5.3/cc1plus -quiet -v -isysroot /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi -D_GNU_SOURCE blocking_assignment_test.cpp -quiet -dumpbase blocking_assig
[Bug target/54106] OMAP3: encountered a blocking structure assignment, occurring only on OMAP3 processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54106 --- Comment #1 from wohauser 2012-07-27 11:57:04 UTC --- Created attachment 27881 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27881 Original source of the example
[Bug fortran/54107] New: [4.8 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 Bug #: 54107 Summary: [4.8 Regression] Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@net-b.de The following test module computation_data implicit none type computation_method character(len=40) :: name procedure(compute_routine), pointer, nopass :: compute end type abstract interface subroutine compute_routine( param_value, zfunc, probability ) real, dimension(:), intent(in) :: param_value procedure(compute_routine) :: zfunc real, intent(in) :: probability end subroutine end interface end module computation_data coming from http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4b313361fd13ca8d# used to compile up to revision 189440 (with the patches for assumed-rank array). It now (after revision 189780 gives a segmentation fault after a very long time (~19 minutes) and using a lot of memory (more than 6462064 kb).
[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 Dominique d'Humieres changed: What|Removed |Added Summary|[4.8 Regression]|[4.8 Regression] Memory hog ||with abstract interface --- Comment #1 from Dominique d'Humieres 2012-07-27 12:05:08 UTC --- Forgot to fill the summary;-(
[Bug target/54106] OMAP3: encountered a blocking structure assignment, occurring only on OMAP3 processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54106 --- Comment #2 from graham.stott at btinternet dot com 2012-07-27 13:18:28 UTC --- No a GCC bug. The source and dest needs to be correctly aligned From: wolfgang.hauser.external at cassidian dot com To: gcc-bugs@gcc.gnu.org Sent: Friday, 27 July 2012, 12:57 Subject: [Bug target/54106] OMAP3: encountered a blocking structure assignment, occurring only on OMAP3 processors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54106 --- Comment #1 from wohauser 2012-07-27 11:57:04 UTC --- Created attachment 27881 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27881 Original source of the example
[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/54106] OMAP3: encountered a blocking structure assignment, occurring only on OMAP3 processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54106 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther 2012-07-27 13:55:07 UTC --- Thus, invalid. Btw, GCC 4.5.3 is no longer supported.
[Bug c++/53792] [C++11][constexpr] improving compiler-time constexpr evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53792 --- Comment #5 from Jason Merrill 2012-07-27 15:06:31 UTC --- On 07/27/2012 06:47 AM, vincenzo.innocente at cern dot ch wrote: > is "__attribute__((always_inline)) " not making foo to transform in foo2 in a > very early compiler's stage? Fairly early, but not as early as constant expression folding. Jason
[Bug c/54088] ICE at dwarf2out.c:20632 with -O1 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54088 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-27 CC||ebotcazou at gcc dot ||gnu.org Summary|ICE at dwarf2out.c:20632|ICE at dwarf2out.c:20632 |with -O1 and sparc |with -O1 -g Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-07-27 15:55:34 UTC --- We just need a preprocessed file as explained in http://gcc.gnu.org/bugs/
[Bug tree-optimization/53773] Vectorizer generates non-canonical multiplies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53773 --- Comment #4 from William J. Schmidt 2012-07-27 16:26:47 UTC --- Operand swapping is also done in vect_is_slp_reduction. Places that rely on the reduction operand being the last operand: * vect_model_reduction_cost * vectorizable_reduction * vect_recog_dot_prod_pattern * vect_recog_widen_sum_pattern Some commentary in vectorizable_reduction indicates that the last-operand rule is not used for nested cycles, so there are a few places where a reduc_index parameter is passed around instead.
[Bug other/52278] [avr] inefficient register allocation for SUBREGs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278
Wouter van Gulik changed:
What|Removed |Added
CC||wvangulik at xs4all dot nl
--- Comment #5 from Wouter van Gulik 2012-07-27
17:23:59 UTC ---
Note that the same behavior is seen for pointers and long.
long add(long l)
{
return l + 1;
}
and
char* add(char* p)
{
return p + 1;
}
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #2 from Oleg Endo 2012-07-27 17:36:30 UTC --- Author: olegendo Date: Fri Jul 27 17:36:20 2012 New Revision: 189917 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189917 Log: PR target/54089 * config/sh/sh.c (shiftcosts): Remove case where first operand is a const_int. Move COSTS_N_INSNS usage into caller ... (sh_rtx_costs) ... here. Return false when shiftcosts cannot be calculated instead of MAX_COST. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug middle-end/34548] GCC generates too many alignment adds for alloca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34548 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-27 CC||rth at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Henderson 2012-07-27 18:14:12 UTC --- I'll take a stab.
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 --- Comment #11 from John David Anglin 2012-07-27 18:16:46 UTC --- Adding early clobbers to the various 32-bit DImode patterns in pa.md didn't make any difference. The bug appears to have been introduced in revision 188786. The following four fails were introduced in this revision: RUN c96005a ,.,. C96005A ACATS 2.5 12-07-26 09:57:57 C96005A CHECK THAT THE ADDITION AND SUBTRACTION FUNCTIONS FOR VALUES OF TYPE TIME WORK CORRECTLY. * C96005A DIFFERENCE OF TIMES IS INCORRECT - (A)1. * C96005A DIFFERENCE OF TIMES IS INCORRECT - (A)2. raised ADA.CALENDAR.TIME_ERROR : a-calend.adb:301 FAIL: c96005a RUN c96005f ,.,. C96005F ACATS 2.5 12-07-26 09:58:05 C96005F CHECKING PACKAGE CALENDAR + AND - FUNCTIONS. * C96005F FAILURE IN ADDING 1 DAY TO 'CURR_DAY1'. * C96005F FAILURE IN ADDING 1 DAY TO 'CURR_DAY2'. * C96005F FAILURE IN ADDING 1 DAY TO 'CURR_DAY3'. * C96005F FAILURE IN SUBTRACTING 1 DAY FROM 'CURR_DAY1'. * C96005F FAILURE IN SUBTRACTING 1 DAY FROM 'CURR_DAY2'. * C96005F FAILURE IN SUBTRACTING 1 DAY FROM 'CURR_DAY3'. C96005F FAILED . FAIL: c96005f RUN c96008a ,.,. C96008A ACATS 2.5 12-07-26 09:58:13 C96008A CHECK MISCELLANEOUS FUNCTIONS IN THE PACKAGE CALENDAR. - C96008A TIME_OF AND SPLIT ARE NOT INVERSES WHEN SECONDS IS ANON-MODEL NUMBER - (A). * C96008A SPLIT(TIME_OF) CHANGED VALUE OF YR - (A). * C96008A SPLIT(TIME_OF) CHANGED VALUE OF MO - (A). * C96008A SPLIT(TIME_OF) CHANGED VALUE OF DY - (A). * C96008A SPLIT(TIME_OF) CHANGED VALUE OF SEC - (A). * C96008A TIME_OF() DID NOT ZERO SECONDS - (C). * C96008A YEAR() DID NOT RETURN CORRECT VALUE - (D). * C96008A MONTH() DID NOT RETURN CORRECT VALUE - (D). * C96008A DAY() DID NOT RETURN CORRECT VALUE - (D). * C96008A SECONDS() DID NOT RETURN CORRECT VALUE - (D). C96008A FAILED . FAIL: c96008a RUN c96008b ,.,. C96008B ACATS 2.5 12-07-26 09:58:16 C96008B CHECK THAT TIME_OF() ADVANCES DAY. * C96008B TIME_OF DID NOT CONVERT 86_400 SECONDS TO A DAY. * C96008B DAY OF NOW2 INCORRECT. * C96008B TIME_OF DID NOT ADVANCE DAY. C96008B FAILED . FAIL: c96008b After revision 189441, almost all acats tests fail with the ADA.CALENDAR.TIME_ERROR.
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #12 from John David Anglin 2012-07-27 18:19:26 UTC --- Duplicate of 53823. *** This bug has been marked as a duplicate of bug 53823 ***
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #3 from John David Anglin 2012-07-27 18:19:26 UTC --- *** Bug 53974 has been marked as a duplicate of this bug. ***
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #22 from Dennis Lubert 2012-07-27 19:20:54 UTC --- Am on vacation so I don't have the testcase at hand, but it is the same as likan posted in the original bugreport, minus the reserve. The main difference is that without reserve I see 21 rehashes in gcc 4.6 and 155 rehashes. I have added some code that after each insert tests if the bucket count has changed, I think that should be trivial to add for yourselves without me providing it.
[Bug target/46453] MIPS backend is not using special instructions for __builtin_bswap32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46453 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | --- Comment #3 from Andrew Pinski 2012-07-27 21:29:20 UTC --- Mine, I will submit a patch soon for both issues.
[Bug target/43902] suboptimal MIPS widening multiply accumulate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #15 from Andrew Pinski 2012-07-27 21:33:16 UTC --- Fixed.
[Bug lto/54108] New: 35% bigger binary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54108 Bug #: 54108 Summary: 35% bigger binary Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://sourceforge.net/projects/qemplayer/files/source%20code/qemplayer-12.6.tar.xz/download with -flto 478896 bytes without -flto 354896 bytes compiler flags can be changed in file SConstruct
[Bug middle-end/54109] New: ICE at tree-ssa-structalias.c:3049 in get_constraint_for_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54109
Bug #: 54109
Summary: ICE at tree-ssa-structalias.c:3049 in
get_constraint_for_component_ref
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mer...@savhon.org
Hello !
I was trying to compile the Linux 3.5 kernel with GCC 4.8.0 as of 20120725 (at
-O{2,3}) when it ICEd on kernel/cpuset.c. Here is a reduced testcase that
reproduces the issue :
$ cat cpuset.c
typedef struct
{
unsigned long bits[4];
} nodemask_t;
struct cpuset
{
long flags;
nodemask_t mems_allowed;
struct cpuset *parent;
} b;
void func1(unsigned long *p1, int p2)
{
p1[p2 - 1] = 0;
}
void func2(nodemask_t *p1, int p2)
{
func1(p1->bits, p2);
}
void func3(void)
{
func2(&b.mems_allowed, 0);
}
$ xgcc -c cpuset.c -O2
cpuset.c: In function ‘func3’:
cpuset.c:26:1: internal compiler error: in get_constraint_for_component_ref, at
tree-ssa-structalias.c:3049
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
GCC 4.7.0 compiles it fine.
[Bug c++/54104] Parser error for lambda expression if function template has default parameter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54104 --- Comment #7 from Andrew Pinski 2012-07-27 23:35:00 UTC --- Related to PR 53624 .
[Bug target/54093] ICE in in extract_insn, at recog.c:2129
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54093 --- Comment #6 from Alan Modra 2012-07-28 00:04:15 UTC --- Author: amodra Date: Sat Jul 28 00:04:10 2012 New Revision: 189921 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189921 Log: PR target/54093 * config/rs6000/rs6000.c (rs6000_secondary_reload): Limit 32-bit multi-gpr reload to cases where predicate passes. Do the same for 64-bit multi-gpr reload. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/54093] ICE in in extract_insn, at recog.c:2129
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54093 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Alan Modra 2012-07-28 00:06:42 UTC --- Fixed
[Bug rtl-optimization/54110] New: lower-subreg related code quality for long long function return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54110
Bug #: 54110
Summary: lower-subreg related code quality for long long
function return
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
powerpc-linux-gcc -m32 -O2
long long ll (long long *x) { return *x; }
Rev 189440 output
lwz r4,4(r3)
lwz r3 0(r3)
blr
Rev 189441 output
mr r9,r3
lwz r3,0(r9)
lwz r4,4(r9)
blr
Not a big deal, but it gets a little worse for
long long llo (long long *x) { return x[4095]; }
Current mainline
lwz r11,32764(r3)
lwz r10,32760(r3)
mr r4,r11
mr r3,r10
blr
Current mainline less r189441 patch
lwz r4,32764(r3)
lwz r3,32760(r3)
blr
Noticed when developing testcases for pr53914. I happened to be working with a
copy of mainline a day before r189441 and saw ideal code being generated with
my pr53914 fix.
Some notes
- Obviously we don't want to revert r189441 as without that the lower-subreg
pass is effectively disabled on powerpc.
- Without lower-subreg, combine merges (set (reg:DI 124) (mem:DI (...));
(set (reg:DI 121) (reg:DI 124)); (set (reg:DI 3) (reg:DI 121)
into (set (reg:DI 3) (mem:DI (...)); Combine can't do that when lowered to
SImode.
- For llo.c, lower-subreg leaves the mem as DImode due to offsettable_memref
quirks. For smaller offsets the mem is split and you get addi,lwz,lwz,blr.
- If we have a DImode mem it persists until the split after reload. It is
there that rs6000_split_multireg_move gets into play, and is reponsible for
reordering the loads.
- I'm not sure under what conditions loads that might trap can be reordered.
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #3 from Marc Glisse 2012-07-28 06:47:49 UTC --- (In reply to comment #0) > without -flto 106856 bytes > with -flto 156312 bytes But is it faster?
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #4 from wbrana 2012-07-28 06:54:06 UTC --- one of tests is faster
