[Bug bootstrap/45751] [4.6 Regression] Bootstrap failure: at stage 1 xgcc segfault
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-09-23 15:28 --- Side question: what could be the meaning of sizeof (struct cl_decoded_option *)? The size of the pointer (which can be useful sometimes but not in this case). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||build, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-09-23 15:28:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45751
[Bug c++/45762] Same binary prints sign of nan on different systems.
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-23 16:00 --- Therefore the glibc fix is required to get the correct output. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45762
[Bug driver/45749] Response file unwrapped between collect2.exe and ld.exe
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-22 16:41 --- I totally thought this was fixed in 4.5.0 when support was added because of LTO. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
[Bug driver/45749] Response file unwrapped between collect2.exe and ld.exe
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-22 16:42 --- Can you provide the output of the -v command when you get that error? Also what version of ld are you using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
[Bug driver/45749] Response file unwrapped between collect2.exe and ld.exe
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-22 17:42 ---
See the code in collect_execute:
if (HAVE_GNU_LD at_file_supplied argv[0] != NULL)
{
/* If using @file arguments, create a temporary file and put the
contents of argv into it. Then change argv to an array corresponding
to a single argument @FILE, where FILE is the temporary filename. */
So maybe HAVE_GNU_LD is not true when it should be.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
[Bug rtl-optimization/45728] [4.4 Regression] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45728
[Bug rtl-optimization/45728] [4.4 Regression] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|2010-09-22 23:10:37 |2010-09-22 23:14:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45728
[Bug bootstrap/45737] Bootstrap comparison failure
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal GCC target triplet||ia64-linux-gnu Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45737
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-09-22 00:33 --- (In reply to comment #13) I seem to be getting this bug on arm thumb also That is a different bug, see PR 38644. This bug records the PowerPC specific bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug target/45731] gcc 4.5.1 -march=corei7 fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-20 04:27 --- -march=corei7 is successful. Yes and that is kinda expected as --help does not process options at all really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45731
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-20 04:52 --- What binutils version are you using? movteq is a valid ARM v7 instruction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug middle-end/45705] [4.3/4.4/4.5/4.6 Regression] Useless store not optimized away
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-17 15:19 --- ce1+combine removed it. I think it still does on targets that don't have a direct to memory store of 0 like PPC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
[Bug c/45707] infinite loop
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-17 16:32 --- This code depends on two undefined behavior. First it depends on an uninitialized value of i. If i is greater than 0 to begin with it depends on signed integer overflow which is undefined. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45707
[Bug middle-end/45709] [4.3/4.4/4.5/4.6 regression] internal compiler error: in add_phi_arg, at tree-phinodes.c:395
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-17 20:25 ---
Reduced testcase:
struct Region {
int storage[4];
int count;
};
static inline Region subtract(int lhs)
{
Region reg;
int* storage = reg.storage;
if (lhs 0)
storage++;
reg.count = storage - reg.storage;
return reg;
}
void bar(int a)
{
const Region copyBack(subtract(a));
}
CUT ---
Comes from inlining.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-09-17 20:25:35
date||
Target Milestone|--- |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45709
[Bug middle-end/45709] [4.3/4.4/4.5/4.6 regression] internal compiler error: in add_phi_arg, at tree-phinodes.c:395
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-17 20:35 ---
Not what is happening is an interaction between the inlining and the return
slot optimization and the named value optimization.
Before inlining we have:
# storage_1 = PHI retval.storage[0](2), retval.storage[1](3)
...
copyBack.1_1 = (struct Region *) copyBack;
*copyBack.1_1 ={v} subtract (a_2(D)) [return slot optimization];
--- Cut
Since (*copyBack.1_1).storage[0] is not a constant we get an ICE. Why we
don't remove the extra cast to begin is questionable. If we change:
const Region copyBack(subtract(a));
to
const Region copyBack = (subtract(a));
We can remove the cast and it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45709
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 21:36 --- iant manphiz: it's a bug the build_debug and install_debug targets in libstdc++-v3/src/Makefile.am are broken if you run configure using a relative path iant the Makefile.am is broken it does cd debug make install iant that fails because it is using the wrong relative path to install.sh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug middle-end/45687] [4.6 Regression] possible wrong code bug
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||wrong-code Summary|possible wrong code bug |[4.6 Regression] possible ||wrong code bug Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45687
[Bug c/45691] Floating point comparison failure
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-16 17:08 --- *** This bug has been marked as a duplicate of 323 *** *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #138 from pinskia at gcc dot gnu dot org 2010-09-16 17:08 --- *** Bug 45691 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at macky dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, GC, ice-on-valid-code Summary|Dangling reference about|[4.6 Regression] Dangling |saved cpp_macro for push/pop|reference about saved |macro |cpp_macro for push/pop macro Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-09-16 22:00 --- GC issues normally don't show at different times depending on the layout of memory and such. Sometimes it depends on env variables being slightly different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45696] Continuation character gets lost or not taken into account
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-16 23:55 --- C preprocessor is not a generic preprocessor. The continuation character is removed so the correct line number is used. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
[Bug preprocessor/45696] Continuation character gets lost or not taken into account
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 00:06 --- (In reply to comment #2) I don't understand why the continuation character should be removed. For the C parser that character is not special (only for the C preprocessor it is), nor it confuses its line number accountancy. Or am I mistaken ? You are confused. It is removed so that the column information for the call to AlreadyWaitingForGDB is on the correct line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
[Bug target/45683] Segmentation fault on large unsigned integer values in C99 mode
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-15 20:56 --- D.1837_4 = (unnamed-signed:128) D.1836_3; Looks like the support 128bit integer is not fully there for x86. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu|i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45683
[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-15 21:00 --- *** Bug 45684 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kjetil1001 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085
[Bug gcov-profile/45684] Internal compiler error when compiling gcc-4.5.1 from source with profilebootstrap
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-15 21:00 --- *** This bug has been marked as a duplicate of 43085 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45684
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-14 22:34 --- *** Bug 45666 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug bootstrap/45666] ICE: /mingw/include/winnt.h:3350:5: Segmentation fault
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-14 22:34 --- This is the same issue as PR 45362, PR 45362 has a description of what is happening though it does show when it happened. *** This bug has been marked as a duplicate of 45362 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45666
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-14 22:35 --- (In reply to comment #2) http://gcc.gnu.org/bugs/#need Since this is a bug in the preprocessor it is hard to get a preprocessed source that causes a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug fortran/45659] LTO / function pointers with iso_c_binding
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-13 17:58 --- void (*build_eri)(); In C means something different from: void (*build_eri)(void); Please try with the void. --- CUT -- void (*build_eri)(); In C means that the build_eri takes a variable arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45659
[Bug rtl-optimization/44281] [4.3/4.4/4.5/4.6 Regression] Global Register variable pessimisation
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-12 14:11 --- This is caused by revision 160124: Not really, it is a noreturn function so the behavior is correct for our policy of allowing a more correct backtrace for noreturn functions. The testcase is a incorrect one based on size and not really that interesting anymore with respect of global register variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
[Bug target/45637] Suspicious code for bit fields
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 15:30 --- 1. index is constant or variable, and Yes that is correct. 2. the 'bar' field type. The alignment of the access is different in those cases. In any case byte accesses should be used. Why, word access is just as fast (if not faster) than a byte access on PPC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637
[Bug target/45637] Suspicious code for bit fields
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 15:46 --- For volatile fields we should use accesses of the appropriate width. The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC it says they should be doing the largest available (up to the register size) size. This is different from the ARM ABI which says the opposite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637
[Bug fortran/45641] configure: error: GNU Fortran is not working
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 17:20 --- libmpfr.so.1: undefined symbol: __gmp_get_memory_functions That means libmpfr is finding the incorrect GMP. This is not a GCC bug but rather a bug in your LD_LIBRARY_PATH or ld.so configuration. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45641
[Bug c++/45642] g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-10 17:34 --- I think you need __attribute((aligned(16))) on the original forward declared class too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
[Bug c++/45642] g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 17:35 --- This seems related to PR 45112. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-09 07:20 --- I first triggered this bug in a freestanding environment You need to include -fno-threadsafe-statics to disable the use of __cxa_guard_acquire. This functions is part of the normal C++ ABI we follow (the IA64 C++ ABI and it is included in the ARM C++ EABI too). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug c++/45603] cc1plus crashes in build_addr_func
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-09 07:27 --- I can use that as a quick workaround but I'll eventually need __cxa_guard_acquire. Then you should look into the ABI to see how it is defined. I think this ICE only happens when it is declared incorrectly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug target/45616] internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-09 17:00 --- --with-cpu=arm926ej-s --with-tune=arm926ej-s --with-arch=armv5te --with-fpu=vfp --with-float=hard Hmm, these default CPUs don't support vfp in thumb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45616
[Bug c/45620] GCC library allows the use of a negative value for 'NAN'
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 19:28 --- negative NAN. Yes you can, the sign bit is set. But then again this is a glibc issue and not a GCC issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45620
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-09 22:17 --- There have been no ABI changes in 4.5 that I know of for PowerPC64 or even differences between the trunk and 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug fortran/45624] Division by zero compiler error
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 22:19 --- PARAMETER are special as it is an exact replacement for those variables. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45624
[Bug bootstrap/45554] -lgmpxx is before GMPLIB for graphite
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 23:55 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||build Last reconfirmed|-00-00 00:00:00 |2010-09-09 23:55:32 date|| Summary|gmp in nonstandard-location |-lgmpxx is before GMPLIB for |results in '-lgmpxx: not|graphite |found' | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45554
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-10 01:40 --- (In reply to comment #3) Mozilla bugs say Platform: x86 Linux. But gcc bug says powerpc64-*-linux. What is going on? I must have missed since I saw Linux64 I was thinking powerpc64 :). Really there have been none x86_64 ones either. Though the normal thing here that might happen is strict aliasing issues. Can you try -fno-strict-aliasing. Also maybe look for buffer overflows which might cause issues you think are compiler related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug preprocessor/45599] Remove all code applying to obsolete #pragma once
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-08 14:46 --- #pragma once Can you explain why you think it can be completely ignored? It can be used without macro guards. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug preprocessor/45599] Remove all code applying to obsolete #pragma once
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-08 15:04 --- At one point we deprecated it and then undeprecated it. See PR 11569. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug target/45600] gcc generates illegal AVX aligned moves
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-08 17:39 --- I think this code is undefined with respect of alignment requirements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug target/45600] gcc generates illegal AVX aligned moves
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-08 17:43 --- Yes this is invalid with respect of alignment requirements. It becomes obvious from the optimized at -O0 on the trunk. v4df llvm_cbe_r5585; v4df llvm_cbe_r5584; struct l_DV1 llvm_cbe__24__StackDv_P53; unsigned int * D.3215; struct l_DV1 * llvm_cbe__24__StackDv_P53.0; bb 2: llvm_cbe__24__StackDv_P53.0_1 = llvm_cbe__24__StackDv_P53; MEM[(v4df *)llvm_cbe__24__StackDv_P53.0_1] = llvm_cbe_r5584_2(D); // requires v4df alignment D.3215_3 = llvm_cbe__24__StackDv_P53.field1.field5; MEM[(struct *)D.3215_3].data = llvm_cbe_r5585_4(D); // requires v4df alignment -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug target/45600] gcc generates illegal AVX aligned moves
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-08 18:55 --- The alignment of llvm_cbe__24__StackDv_P53 is only 64bits so you are casting to a greater aligned type and then dereferencing it. That being said, the LLVM C back-end produces crazy c code that is also undefined because of aliasing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug target/45600] gcc generates illegal AVX aligned moves
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-09-08 19:01 --- If it's an illegal program, gcc should at least emit a warning, if not an error. It is not an invalid program, it is just undefined at runtime. There was a defect report against the C standard asking if a diagnostic can be required for undefined behavior and it was rejected. Oh there is a patch to enable warnings for this case already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug target/45600] gcc generates illegal AVX aligned moves
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-08 19:01 --- vector types are naturally aligned just like integer types. That is they are aligned on their size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug c++/45605] Missed devirtualization
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 01:17 --- I think this is the same issue as PR 19816. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug tree-optimization/45256] Missed arithmetic simplification at tree level
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-07 18:41 --- ret_59 = (i_53 + 1) * 32 - (32 - ret_56) So this looks like a re-association issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45256
[Bug testsuite/45590] FAIL: gcc.dg/graphite/pr44391.c: unrecognized command line option '-m32'
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-07 23:19 --- Just remove the -m32, people who care about -m32 will have use it while running the testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45590
[Bug c++/45553] Warning Suppression: C++ Templates, Unsigned, and comparison of unsigned expression 0 is always false
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-06 06:48 --- I thought Stallman hated those things The reason why Stallman hated them is that they did not work with macros and that changed with C99 adding support of _Pragma which can be used in macros now. So his argument against Pragma went away when that come in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45553
[Bug target/45559] [4.4 regression] wrong conversion from unsigned int/long to float
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
[Bug rtl-optimization/41849] optimization fails when register variables are used for an interrupt
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41849
[Bug target/41999] Bug in generation of interrupt function code for ARM processor
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-05 06:41 --- *** Bug 45540 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ethan at evolution dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41999
[Bug target/45540] interrupt handler stack pointer is wrong
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-05 06:41 --- *** This bug has been marked as a duplicate of 41999 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45540
[Bug target/45548] Add with carry - missed optimization on x86
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-05 22:15 --- Confirmed. zero_extendsidi2_32 and adddi3_doubleword are being split too late. Which causes no optimizations to happen on those two things. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-09-05 22:15:50 date|| Summary|Add with carry - missed |Add with carry - missed |optimization|optimization on x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45548
[Bug rtl-optimization/45551] [4.6 Regression]: gcc.c-torture/execute/990326-1.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45551
[Bug c++/45553] Warning Suppression: C++ Templates, Unsigned, and comparison of unsigned expression 0 is always false
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-06 05:24 --- *** This bug has been marked as a duplicate of 11856 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45553
[Bug c++/11856] unsigned warning in template
--- Comment #29 from pinskia at gcc dot gnu dot org 2010-09-06 05:24 --- *** Bug 45553 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||noloader at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug c++/45553] Warning Suppression: C++ Templates, Unsigned, and comparison of unsigned expression 0 is always false
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-06 05:39 --- It is still a dup of bug 11856. Note the use of bug here is really dealing with how do you describe all issues (enhancements or otherwise). The use is not saying it is a software bug in the normal sense. *** This bug has been marked as a duplicate of 11856 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45553
[Bug c++/11856] unsigned warning in template
--- Comment #30 from pinskia at gcc dot gnu dot org 2010-09-06 05:39 --- *** Bug 45553 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug pch/45536] PCH uses -o file even when there are other arguments
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-04 19:31 --- The problem is the specs is producing the output file for the PCH. [andrew-pinskis-computer:~] apinski% file t.out t.out: GCC precompiled header (version 013) for C Related to PR 33980. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |pch GCC build triplet|elf_x86_64 | GCC host triplet|elf_x86_64 | GCC target triplet|elf_x86_64 | Summary|gcc updates output timestamp|PCH uses -o file even when |even when compilation fails |there are other arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536
[Bug pch/45536] PCH uses -o file even when there are other arguments
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-04 19:32 --- This has enough information to reproduce the bug. Thanks again for the testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-04 19:32:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536
[Bug pch/45536] PCH uses -o file even when there are other arguments
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-04 19:33 --- (In reply to comment #1) Please provide a complete testcase, including Makefile. The description has enough information to produce the issue. The driver is producing a PCH and an executable with the same output filename. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536
[Bug libstdc++/43785] [C++0x] std::make_pair vs explicit template arguments
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-09-04 19:41 --- *** Bug 45537 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug libstdc++/45537] [c++0x] reject valid? no matching function for call to 'make_pair(void*, int)'
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-04 19:41 --- std::make_pair void*, int takes rvalue references which cannot bind to lvalues. See the discussion in PR 43785. *** This bug has been marked as a duplicate of 43785 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45537
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-04 02:13 --- (In reply to comment #9) --- gcc 2010-09-03 22:04:53.0 -0400 +++ libgcc 2010-09-03 22:01:16.0 -0400 @@ -11,34 +11,26 @@ esac ], [ - case $target in + case $host in This is correct as libgcc is a target library so the host there is what we originally had as the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-02 22:28 --- The problem with the configure is the libgcc specs are very target dependent. Anyways I don't see the issue with using -R in a wrapper script and while bootstrapping in LIB_CFLAGS=-R . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
[Bug c++/43850] ice: tree code �template_type_parm� is not supported in gimple streams
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-09-02 22:40 --- (In reply to comment #10) What is the changeset that fixed this on trunk? I'd really need to try to patch my 4.5.1 if possible bcs this bug is a showstopper for me LTO is an experimental feature for 4.5.x. That is it has been tested but there could be some bugs in it. It is designed to be able to test it and see the improvements that are coming. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ice: tree code |ice: tree code |template_type_parm is not |�template_type_parm� is |supported in gimple streams |not supported in gimple ||streams http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
[Bug c++/45510] Bug with anonymous unions and bit-fields
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-03 01:10 ---
union {
unsigned int a : 1,
b : 4;
unsigned int data;
};
This is an union of three elements each over lapping, that is a:1 overlaps with
b:4 and data. So this is expected behavior as far as I can tell.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45510
[Bug c++/45510] Bug with anonymous unions and bit-fields
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-03 01:13 ---
You can use a GCC extension of anonymous structs:
struct bfa {
union {
struct {
unsigned int a : 1,
b : 4;
};
unsigned int data;
};
};
To get the behavior you want.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45510
[Bug middle-end/45497] [4.3/4.4/4.5/4.6 Regression] bogus warning at -O0 (control reaches end of non-void function).
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-03 04:51 --- Reopening as that bug was marked as being fixed in 4.4.0 but this is not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45497
[Bug middle-end/45497] [4.3/4.4/4.5/4.6 Regression] bogus warning at -O0 (control reaches end of non-void function).
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-03 04:53 --- Not to mention t2.cpp is really a dup of bug 20681. And yes this is a dup of that bug as this is a switch that is causing issue. *** This bug has been marked as a duplicate of 20681 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45497
[Bug c++/20681] [4.3/4.4/4.5/4.6 Regression] wrong control reaches warning with switches
--- Comment #27 from pinskia at gcc dot gnu dot org 2010-09-03 04:53 --- *** Bug 45497 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-09-01 18:25
---
(In reply to comment #10)
typedef my_unaligned_aliasing_uint32 uint32
__attribute__((aligned(1),may_alias));
inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr)
{
return *(const my_unaligned_aliasing_uint32 *)ptr;
}
It does not:
READ_UINT32:
j $31
lw $2,0($4)
The aligned attribute is ignored there I think. memcpy produces:
lbu $2,3($4)
lbu $6,0($4)
lbu $5,1($4)
lbu $3,2($4)
addiu $sp,$sp,-16
sb $6,0($sp)
sb $5,1($sp)
sb $3,2($sp)
sb $2,3($sp)
lw $2,0($sp)
j $31
addiu $sp,$sp,16
Which is bad and could be improved by using lwl/lwr. I will file a bug about
that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug c++/45490] Confusing error message for local type arguments
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-01 21:36 --- On the trunk we get: t.cc: In function âvoid foo()â: t.cc:9:39: error: no matching function for call to âdistance(foo()::my_iter, foo()::my_iter)â /home/apinski/local-gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_iterator_base_funcs.h:111:59: note: candidate is: templateclass _InputIterator typename std::iterator_traits::difference_type std::distance(_InputIterator, _InputIterator) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45490
[Bug c++/45490] Confusing error message for local type arguments
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-01 21:37 --- Not to mention it is accepted with -std=c++0x as local types in C++0x can be now template arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45490
[Bug c++/45492] G++ permits function-to-data pointer conversions with __extension__ in functions, but not function templates
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-02 00:30 --- Related to PR 21385. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45492
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-09-02 00:44 ---
Doing:
catch (int i)
{
Guard g(ioSync);
cout Caught i endl flush;
sched_yield();
pthread_testcancel();
}
Fixes the issue. Note there is a blog entry about POSIX thread cancel and C++
exceptions by Uli somewhere. There was huge discussion on a mailing list about
it too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-02 01:19 --- http://lmgtfy.com/?q=posix+thread+cancel+C%2B%2B+exceptions the third link is an interesting news group entry. http://udrepper.livejournal.com/21541.html etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 17:45 --- I think the return value for character(16) returns are passed via the first argument. So I think this is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 20:19 --- GCC 3.4.5 did. That is because GCC 4.5 and above support -Wuninitialized at -O0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-31 20:28 ---
#include stdio.h
int main(void)
{
int i;
printf (%d\n, i);
return 0;
}
Is warned about with -Wuninitialized at -O0. We don't warn about the uses that
might be used unitialized. That means if i is gets put into a PHI before the
use, we don't warn.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-08-31 20:37 --- so it still seems GCC 4.5.1 should warn about `-O' not being specified. No, I showed an example of where it does warn without -O. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-08-31 20:40 --- (In reply to comment #7) I am pointing out a case where it does not warn (and it seems to me that it should); what is your point? My point is that you should open a different bug that says we should warn about that case with -O0 rather than warning that -Wuninitialized needs -O. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-08-31 20:49 --- (In reply to comment #9) Though, GCC does not warn about a missing `-O' (or `-Oxxx') flag, which was the point of this bug report. That the `-O0' flag doesn't work is another story. And I showed a case where it does with at -O0 so warning it does not work at -O0 is not fully true as it does partly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug target/45469] When building cross compiler cannot compute suffix of object files.
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-31 21:27 --- ./configure First don't build in the source directory. Second can you attach /home/Leo/Documents/gcc-cross-mactel-4.6.0/i386-apple-darwin/libgcc/config.log ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|When building cross compiler|When building cross compiler |cannot compute suffix of|cannot compute suffix of |object files. |object files. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469
[Bug target/45469] When building cross compiler cannot compute suffix of object files.
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-08-31 22:28 --- Can you attach /home/Leo/i386appledarwinbuild/i386-apple-darwin/libgcc/config.log ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469
[Bug target/45469] When building cross compiler cannot compute suffix of object files.
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-31 23:01 --- /home/Leo/i386appledarwinbuild/./gcc/as: line 83: exec: : not found The as is not being found. checking for as... no checking for i386-apple-darwin-as... no You don't have the cross binutils/cctools installed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469
[Bug pch/45471] ICE with PCH and differening strict-aliasing settings
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 23:14 --- The PCH should be rejected for the differences in strict-aliasing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE: in typeid_ok_p, at |ICE with PCH and differening |cp/rtti.c:311 when using|strict-aliasing settings |precompiled headers | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45471
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-08-29 05:13 --- Extra diagnostic checks enabled; compiler may run slowly. Make sure you configure the trunk with --enable-checking=release to get the same timing results as what a release would be. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-08-29 05:23 --- (In reply to comment #12) Extra diagnostic checks enabled; compiler may run slowly. Make sure you configure the trunk with --enable-checking=release to get the same timing results as what a release would be. s/release/release branch/ :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug c++/45428] Address of template function even if fully named as a template-id is not properly determined
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-27 18:33 --- *** This bug has been marked as a duplicate of 11407 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug c++/11407] [DR 115] Function cannot be resolved
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-08-27 18:33 --- *** Bug 45428 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||roger dot ferrer at bsc dot ||es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407
[Bug middle-end/45416] [4.5/4.6 Regression] Code size regression between 4.6(4.5) and 4.4 for ARM
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|middle-end Summary|Code size regression between|[4.5/4.6 Regression] Code |4.6(4.5) and 4.4 for ARM|size regression between ||4.6(4.5) and 4.4 for ARM Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416
[Bug c++/986] g++ misses warning for on temporary
--- Comment #27 from pinskia at gcc dot gnu dot org 2010-08-27 22:21 --- This first one is inspired by the code I was working on: Your two functions are well defined as the scope of the temp is only lost after going out of scope. So there is no references to a temp escaping unlike the original example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
