[Bug c++/39409] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39409 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-02 CC|amit at mobiletornado dot |dje at gcc dot gnu.org |com, gcc-bugs at gcc dot| |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 10:05:55 UTC --- Can you try a much more recent compiler, say in the 4.6.x series? gcc4.2.x is not maintained anymore.
[Bug c++/39681] Compile error is not descriptive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |manu at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 10:07:33 UTC --- Manuel, can I have your opinion about this one?
[Bug c++/39950] __unix__ macro is not predefined on AIX platform (C and C++)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39950 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |dje at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 10:08:40 UTC --- David, is this (still) an issue? In case, seems easy to fix..
[Bug c++/44827] g++4.3.4 segfaults when using boost::intrusive::list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44827 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 10:15:28 UTC --- Fixed in 4.6.x.
[Bug c++/44855] Static members not initialised in explicit template instances of library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44855 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 10:19:01 UTC --- Closing.
[Bug c++/47906] r170459 regresses g++.dg/abi/mangle39.C on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47906 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|jason at redhat dot com | Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 10:20:27 UTC --- Fixed then.
[Bug c/45404] /*code-comment*/ related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45404 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID
[Bug c/22133] In MinGW trailling slash forward not allowed in include path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22133 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 10:22:35 UTC --- Fixed.
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #26 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-02 10:41:27 UTC --- Author: hubicka Date: Sun Oct 2 10:41:24 2011 New Revision: 179424 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179424 Log: PR lto/47247 * lto-plugin.c (get_symbols_v2): New variable. (write_resolution): Use V2 API when available. (onload): Handle LDPT_GET_SYMBOLS_V2. * lto-symtab.c (lto_symtab_resolve_symbols): Do not resolve when resolution is already availbale from plugin. (lto_symtab_merge_decls_1): Handle LDPR_PREVAILING_DEF_IRONLY_EXP. * cgraph.c (ld_plugin_symbol_resolution): Add prevailing_def_ironly_exp. * lto-cgraph.c (LDPR_NUM_KNOWN): Update. * ipa.c (varpool_externally_visible_p): IRONLY variables are never externally visible. * varasm.c (resolution_to_local_definition_p): Add LDPR_PREVAILING_DEF_IRONLY_EXP. (resolution_local_p): Likewise. * common.c (lto_resolution_str): Add new resolution. * common.h (lto_resolution_str): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/ipa.c trunk/gcc/lto-cgraph.c trunk/gcc/lto-symtab.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/common.c trunk/gcc/lto/common.h trunk/gcc/varasm.c trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c
[Bug middle-end/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565
--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-10-02
10:43:54 UTC ---
Created attachment 25393
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25393
reduced test case
cat pr50565.c
/* pr50565.c */
struct netmessage {
unsigned char pos[2];
};
static struct netmessage nmsgbuf;
const int offset0 = (int)((void*)nmsgbuf.pos[0] - (void*)nmsgbuf) + 0*(1U);
const int offset1 = (int)((void*)nmsgbuf.pos[0] - (void*)nmsgbuf) + 1*(1U);
objdir/gcc/xgcc -Bobjdir/gcc/ -O2 -S pr50565.c
pr50565.c:7: error: initializer element is not computable at load time
That's the offset1 initializer it's complaining about. Note that the offset0
initializer is accepted. If we comment out the offset1 definition we get:
perl -pi -e 's,^const int offset1,//const int offset1,g' pr50565.c
objdir/gcc/xgcc -Bobjdir/gcc/ -O2 -S pr50565.c
cat pr50565.s
.file pr50565.c
.globl offset0
.section.rodata
.align 4
.type offset0, @object
.size offset0, 4
offset0:
.long 0
.local nmsgbuf
.comm nmsgbuf,2,1
.ident GCC: (GNU) 4.5.0 20090329 (experimental)
.section.note.GNU-stack,,@progbits
The common offsetof emulation is clearly computable at compile-time, so one
would expect the same + 1 to also be computable at compile-time, but gcc
doesn't seem to think so.
[Bug target/50588] New: gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 Bug #: 50588 Summary: gcc produce bad inlined code with -march=athlon -O2 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: news...@duradsl.dyndns.org Created attachment 25394 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25394 Reduced example that trigger the bug When the attached file (which is a reduced testcase from inetutils traceroute.c) is compiled with -march=athlon -O2, the resulting binary segfault: gcc -march=athlon -O2 -o traceroute traceroute.c ./traceroute Before Segmentation fault When inlining is disabled, no problem: gcc -march=athlon -O2 -fno-inline -o traceroute traceroute.c ./traceroute Before After The problem can be reproduced on athlon-xp and core2 machines with 32 bits libs. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.6.1/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib Thread model: posix gcc version 4.6.1 (GCC)
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-10-02 11:58:09 UTC --- Doesn't fail for me on Fedora 13 / i686 (C2Q6600) with gcc 4.7, 4.6, 4.5, or 4.4. Please upload _preprocessed_ source.
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #2 from newsgrp at duradsl dot dyndns.org 2011-10-02 11:58:39 UTC --- Created attachment 25395 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25395 preprocessed result of traceroute.c This seems to be a regression from gcc 4.5.x Will try to make a git bisect in next few days
[Bug preprocessor/36819] memleak in split_quote_chain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36819 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-10-02 12:31:46 UTC --- Author: paolo Date: Sun Oct 2 12:31:40 2011 New Revision: 179426 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179426 Log: 2011-10-02 Paolo Carlini paolo.carl...@oracle.com PR preprocessor/36819 * incpath.c (merge_include_chains): Call free_path on heads[QUOTE] and tails[QUOTE]. Modified: trunk/gcc/ChangeLog trunk/gcc/incpath.c
[Bug preprocessor/36819] memleak in split_quote_chain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36819 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 12:33:53 UTC --- Fixed.
[Bug ada/50589] New: [4.7] Ada bootstrap failure on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50589 Bug #: 50589 Summary: [4.7] Ada bootstrap failure on sparc-linux Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se I'm attempting to bootstrap a plain sparc-linux gcc on sparc64-linux, by passing --build=sparc-unknown-linux --host=sparc-unknown-linux --target=sparc-unknown-linux --enable-targets=all --with-cpu=v8 --enable-multilib to configure. The build fails however in Ada: /mnt/scratch/objdir47/./gcc/xgcc -B/mnt/scratch/objdir47/./gcc/ -B/mnt/scratch/install47/sparc-unknown-linux/bin/ -B/mnt/scratch/install47/sparc-unknown-linux/lib/ -isystem /mnt/scratch/install47/sparc-unknown-linux/include -isystem /mnt/scratch/install47/sparc-unknown-linux/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg s-linux.ads -o s-linux.o s-linux.ads:38:16: warning: unit C is not referenced make[7]: *** [s-linux.o] Error 1 make[7]: *** Waiting for unfinished jobs make[7]: Leaving directory `/mnt/scratch/objdir47/gcc/ada/rts' make[6]: *** [gnatlib] Error 2 make[6]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[5]: *** [gnatlib-shared-default] Error 2 make[5]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[4]: *** [gnatlib-shared-dual] Error 2 make[4]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir47/sparc-unknown-linux/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir47' make: *** [bootstrap] Error 2 The complete configuration is: /mnt/scratch/gcc-4.7-20111001/configure --prefix=/mnt/scratch/install47 --with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-5.0.2 --with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.0.1 --with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-0.9 --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c,ada --disable-build-poststage1-with-cxx --build=sparc-unknown-linux --host=sparc-unknown-linux --target=sparc-unknown-linux --enable-targets=all --with-cpu=v8 --enable-multilib The reason I'm overriding build/host/target is that a recent change on trunk broke the ability to build a sparc64-linux gcc that defaults to -m32, see PR50354.
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-10-02 13:00:42 UTC --- The preprocessed test case SEGVs for me with gcc-4.6-20110930, but works with 4.7-20111001, 4.5-20110929, and 4.4-20110927.
[Bug tree-optimization/50587] ICE init_range_entry, at tree-ssa-reassoc.c:1698 caused by recent change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50587 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-10-02 13:18:00 UTC --- It also breaks LTO build of Firefox with the same ICE.
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||bernds at gcc dot gnu.org, ||mikpe at it dot uu.se --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-10-02 15:22:46 UTC --- The first smaller test case started failing with r163935: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00227.html
[Bug c/50581] stdarg doesn't support array types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581 --- Comment #6 from Wolfgang at Solfrank dot net 2011-10-02 16:08:51 UTC --- (In reply to comment #5) On Sat, 1 Oct 2011, Wolfgang at Solfrank dot net wrote: Passing va_list as a function argument is generally hard, whether or not variadic, since you don't know whether it will be passed by reference or by value or what the type of the address of a va_list parameter will be. Portable code needs to pass a pointer to va_list or a structure containing va_list or use some other such means of avoiding dependence on whether va_list is an array. Huh? What about vprintf and friends? They are defined to take a va_list as their last parameter. There are some things you can do - for example, calling those functions in accordance with the rules given in the C standard. There are various things that cause problems - for example, taking the address of a parameter declared as a va_list (because the parameter type may have been changed from va_list to pointer-to-element-of-va_list as part of the parameter type adjustment of parameters declared as arrays, so the type of parameter may not be va_list *). But I don't want to take the address of a va_list parameter. I just want to handle it with stuff defined in stdarg.h. Actually, I'm not sure why va_list is defined as an array in some of the architectures. The problem wouldn't arise if va_list were just defined as the structure that it's currently defined as an array of. Anyway, I still consider it a bug that gcc when called with -std=c99 compiles va_arg with array type without any hint into code that cannot possibly be useful, as it expects the array to be passed by value to the variadic function.
[Bug c/50590] New: Initializing a variable to itself yields garbage/UB and no warning.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50590 Bug #: 50590 Summary: Initializing a variable to itself yields garbage/UB and no warning. Classification: Unclassified Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: eyal.lo...@gmail.com Exact version string: gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 This is very similar to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10538 But weirdly, while: int x = x + 1; Does yield a warning, this: int x = x; does not. This may accidentally happen in e.g macros: #define F(_x) \ int _x = x; ... use _x ... expands to: int x = x; use x;
[Bug c/50590] Initializing a variable to itself yields garbage/UB and no warning.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50590 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-10-02 16:43:09 UTC --- This is a feature, use -Winit-self.
[Bug c/50591] New: C linker not considering number of parameters with extern linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50591
Bug #: 50591
Summary: C linker not considering number of parameters with
extern linkage
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: srikaw...@gmail.com
Please find the inline program to explain the bug detail.
SampleADT.c
---
#includestdio.h
int fun(int a,int b,int c)
{
printf(fun %d %d %d,a,b,c);
return 0;
}
int extrafun(int a,int b,int c)
{
printf(efun %d %d %d %d,a,b,c,*(c+1));
return 0;
}
SampleMain.c
#includestdio.h
/* inline functions are defined with 3 arguments in SampleADT.c
However wrongly declared here!! */
extern int fun(int a,int b);
extern int extrafun(int a,int b,int c,int d);
int main(int argc,char *argv[])
{
fun(10,20);
extrafun(10,20,30,40);
return 0;
}
gcc -c SampleADT.c SampleMain.c
./a.out
The above program compiles and linked successfully without any linker errors.
C-linker links function call to function definition only by name and number of
parameters were not considered.
[Bug c/50591] C linker not considering number of parameters with extern linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50591 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-10-02 17:20:39 UTC --- If you want type-safe linking use C++. The usual ABIs for C don't provide this information.
[Bug c++/50592] New: g++ fails to see function side effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50592 Bug #: 50592 Summary: g++ fails to see function side effect Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: nospam.gccboostix.20.le...@spamgourmet.com Hello, I’m currently facing a problem with a program using boost: https://svn.boost.org/trac/boost/ticket/4452 But after having had a deeper look on it, I think that the problem is coming from gcc because the occurrence of the problem depends on the optimization level (I have deactivated strict aliasing rule since it is a known case of breakage of wrong code) and appears only with gcc 4.5 and 4.6. With gcc 4.4, the program works fine. (The exact versions tested were: 4.4.6 (OK), 4.5.3 (KO) and 4.6.1 (KO). All on x86_64-linux-gnu) I have attached a pre-processed program that reproduces the issue. It behaves differently depending on the optimization level. When compiled without any optimization with g++ -Wall -Wextra -o testboost testboost.i -g -lrt The program exits normally When compiled with optimization with g++ -Wall -Wextra -o testboost testboost.i -g -O1 -fno-strict-aliasing -lrt The program issue a segmentation error. What’s even more weird is what happens when the following line of testboost.i is uncommented: //abort(); // Uncommenting this abort makes this program work. Then, the program exits normally. This indicates that: — this line and this abort are in a path that is not executed by this program (otherwise, the program wouldn’t have exited normally.); — adding this line has a deep impact on the code generated. Here is the stack that lead to the execution of the function that contains that abort: #0 boost::intrusive::detail::tree_algorithms…::insert_commit (…) at …/tree_algorithms.hpp:907 #1 0x00406bdd in insert_equal_upper_bound… (…) at …/tree_algorithms.hpp:1071 #2 insert_equal_upper_bound… (…) at …/rbtree_algorithms.hpp:538 #3 insert_equal (…) at …/rbtree.hpp:482 #4 insert (…) at …/set.hpp:1569 #5 boost::interprocess::rbtree_best_fit…::priv_add_segment (…) at …/rbtree_best_fit.hpp:538 … #14 main () at testboost.cpp:11 And here is the stack of the segmentation fault: #0 get_color (…) at …/rbtree_node.hpp:136 #1 boost::intrusive::rbtree_algorithms…::rebalance_after_insertion (…) at …/rbtree_algorithms.hpp:855 #2 0x00406bbd in insert_equal_upper_bound… (…) at …/rbtree_algorithms.hpp:539 #3 insert_equal (…) at …/rbtree.hpp:482 #4 insert (…) at …/set.hpp:1569 #5 boost::interprocess::rbtree_best_fit…::priv_add_segment (…) at …/rbtree_best_fit.hpp:538 … #14 main () at testboost.cpp:11 When, in gdb, I put a breakpoint in the function that contains (or not) the abort, when the abort is commented, the program segfaults without hitting the breakpoint. This observation makes me wonder if a gcc optimization may have missed a side effect of a piece of code and decided to skip, or at least to delay, its execution. Even when looking at the generated assembler code, I have the feeling that insert_commit is not called when the abort is left commented.
[Bug c++/50592] g++ fails to see function side effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50592 --- Comment #1 from nospam.gccboostix.20.lenex at spamgourmet dot com 2011-10-02 17:24:43 UTC --- Created attachment 25396 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25396 Pre-processed program to use to reproduce the issue
[Bug target/49696] ICE on mips when compiling drizzle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49696 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-10-02 17:45:16 UTC --- Author: rsandifo Date: Sun Oct 2 17:45:10 2011 New Revision: 179431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179431 Log: gcc/ PR target/49696 * config/mips/sync.md (sync_optab_12): Allow zero operands. (sync_old_optab_12, sync_new_optab_12, sync_nand_12): Likewise. (sync_old_nand_12, sync_new_nand_12, test_and_set_12): Likewise. gcc/testsuite/ * gcc.dg/pr49696.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr49696.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/sync.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-02 17:46:44 UTC --- Created attachment 25397 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25397 updated patch for revision 179415 The patch in comment #12 no longer applies cleanly (the changes in resolve.c are now obsolete, I have mechanically replaced four times !gfc_compare_types with !gfc_TK_compatible, although it does not introduce regression, this should be checked by someone understanding the code better than I do). I had also to do a similar change in gcc/fortran/check.c to allow move_alloc_5.f90 and select_type_23.f03 to pass (otherwise they fail with Error: 'from' argument of 'move_alloc' intrinsic at (1) must be the same type and kind as 'to' I have also updated null_1.f90. With these changes I had no regression and my tests passed without the glitch reported in comment #13 (the previous patch probably exposed some rampant bug that has been fixed).
[Bug target/49696] ICE on mips when compiling drizzle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49696 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rsandifo at gcc dot gnu.org Resolution||FIXED --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-10-02 17:47:53 UTC --- Patch applied to trunk. I don't think this is a regression, so it probably isn't suitable for the release branches.
[Bug middle-end/50061] [4.7 regression] emit_library_call_value_1 change broke SF-TI conversion on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50061 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-10-02 17:49:10 UTC --- Patch applied to trunk.
[Bug middle-end/50113] [4.7 Regression] soft-float MIPS64 compiler is miscompiling ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50113 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-10-02 17:48:40 UTC --- Patch applied to trunk.
[Bug target/50579] [4.7 regression] gcc.target/mips/20020620-1.c FAILs on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50579 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-10-02 18:29:30 UTC --- Author: rsandifo Date: Sun Oct 2 18:29:27 2011 New Revision: 179433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179433 Log: gcc/testsuite/ PR target/50579 * gcc.target/mips/mips.exp (mips_long32_abi_p, mips_long64_abi_p): New procedures. (mips-dg-options): Force an ABI option if the current ABI is incompatible with the required -mlong setting. Likewise force a long setting if the current one is incompatible with the chosen ABI. Keep abi_test_option_p, abi and eabi_p updated throughout procedure. * gcc.target/mips/abi-o64-long64.c: Require -mno-abicalls instead of addressing=absolute. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/mips/abi-o64-long64.c trunk/gcc/testsuite/gcc.target/mips/mips.exp
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2011-10-02 18:35:02 UTC --- The second larger test case from Matthias started failing with r161831: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00185.html
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2011-10-02 18:55:45 UTC --- The failure started with r164552: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00849.html It's enough to pass -O2 -mtune=athlon to trigger the bug, you don't need -march. I don't see anything x86-specific in that revision so quite possibly it's just triggering a latent x86 backend error.
[Bug c/50581] stdarg doesn't support array types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581 Steven Fuerst svfuerst at gmail dot com changed: What|Removed |Added CC||svfuerst at gmail dot com --- Comment #7 from Steven Fuerst svfuerst at gmail dot com 2011-10-02 19:47:46 UTC --- Actually, I'm not sure why va_list is defined as an array in some of the architectures. The underlying issue is that the ABI on some architectures requires it. They may use register windows instead of stacks to pass parameters to functions. i.e. r1-r5 might refer to the registers in the function that called you. r6-r10 might refer to the registers in the function that called the function that called you. etc. The act of calling a function then changes the values a set of registers refers to. So when you call a function, what it sees as r6-r10 are the values that you see in r1-r5. With this type of ABI, you access your parameters from i.e. r1-r5. Any functions that you call cannot do this though... as the registers are renamed. So va_list cannot be a pointer type as there is nothing to point to. So how do you implement va_args for these arches then? The trick is to use an array. C requires that an array decays to a pointer when it is passed as an argument. This means that the array must be stored on the stack, and not in the renamable registers. This allows the code to get a handle on how many stack (and register) frames up the calling sequence it needs to go to find the parameters. The array can then store information about i.e. how many integer and floating point registers have been read from the variable argument list.
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-02 20:35:59 UTC --- This could be a bug in FD_SET/FD_ZERO.
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-10-02 20:45:07 UTC --- So which libc was this originally compiled against? Some things in traceroute.i make me think it's glibc, but I don't see any indication of which version it was.
[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2011-10-02 21:45:08 UTC --- Author: jason Date: Sun Oct 2 21:45:01 2011 New Revision: 179436 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179436 Log: PR c++/35722 Implement N2555 (expanding pack expansion to fixed parm list) * pt.c (coerce_template_parms): Allow expanding a pack expansion to a fixed-length argument list. (unify_pack_expansion): Handle explicit args properly. (unify) [TREE_VEC]: Handle pack expansions here. [TYPE_ARGUMENT_PACK]: Not here. (tsubst_pack_expansion): Don't try to do partial substitution. (pack_deducible_p): New. (fn_type_unification): Use it. (find_parameter_packs_r): Take the TYPE_MAIN_VARIANT of a type parameter. (check_non_deducible_conversion): Split from type_unification_real. (unify_one_argument): Split from type_unification_real... (unify_pack_expansion): ...and here. Drop call_args_p parm. (type_unification_real, unify, more_specialized_fn): Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic-explicit1.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-nondeduce1.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic117.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic118.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/variadic105.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic35.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic65.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic82.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic83.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/util/testsuite_tr1.h
[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #17 from Jason Merrill jason at gcc dot gnu.org 2011-10-02 21:53:23 UTC --- Fixed for 4.7.
[Bug c++/50593] New: improve __attribute__((format(printf)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50593 Bug #: 50593 Summary: improve __attribute__((format(printf))) Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: b.r.longb...@gmail.com Created attachment 25398 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25398 8 tests There are a number of cases where the compiler should be able to use a constant string to check the arguments of a printf-like function. Expected Result: GCC always warns about format argument errors, when it can. Actual Result: GCC only warns in a couple of cases. In particular, note: * const char[] works in C but not C++. * Directly using the result of a constexpr function doesn't work, but assigning it to a variable does. (This is fortunate, because it allowed me to write the most awesome code ever, a safe wrapper that allows passing e.g. a std::string to printf!) Versions tested: All tests: 4.6.1 (gentoo), r179098 from branch 4.6, and trunk sometime near that. Tests 1,2,6,7,8 (without constexpr): 4.5.3, 4.4.6, 4.3.6 (gentoo) Tests 1,2 (C++98): 4.2.4 (gentoo) Tests 1,2 in C: all mentioned versions.
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #7 from newsgrp at duradsl dot dyndns.org 2011-10-02 22:00:15 UTC --- Created attachment 25399 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25399 glibc-2.14 patches
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #8 from newsgrp at duradsl dot dyndns.org 2011-10-02 22:01:23 UTC --- (In reply to comment #6) So which libc was this originally compiled against? Some things in traceroute.i make me think it's glibc, but I don't see any indication of which version it was. The glibc version is 2.14 and is compiled with the attached patches.
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #18 from Mikael Morin mikael at gcc dot gnu.org 2011-10-02 22:05:20 UTC --- Created attachment 25400 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25400 the farthest I went about this pr For what's worth, I have just unburied the patch above (only updated to recent trunk, not tested in any way). This is the farthest I went in fixing this PR before moving to something else. As it wasn't submitted, I suppose it comes with some regressions.
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #9 from newsgrp at duradsl dot dyndns.org 2011-10-02 22:39:42 UTC --- (In reply to comment #4) The failure started with r164552: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00849.html It's enough to pass -O2 -mtune=athlon to trigger the bug, you don't need -march. I don't see anything x86-specific in that revision so quite possibly it's just triggering a latent x86 backend error. http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00849.html is the first bad commit here too.
[Bug c++/50594] New: Option -fwhole-program discards replaced new operator for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
Bug #: 50594
Summary: Option -fwhole-program discards replaced new operator
for std::string
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: z...@sogetthis.com
The following program fails to output the messages in the replaced allocation
operators, but *only* during the string allocation *and* when the option
`-fwhole-program` is present. (Tested on 4.6.1 and 4.4.3.) That is, the program
behaves differently when compiles with the following two commands:
g++ -std=c++0x -o prog prog.cpp
g++ -std=c++0x -o prog prog.cpp -fwhole-program
Note that the allocation used by the map is always done correctly.
Program code:
#include new
#include string
#include iostream
#include cstdlib
#include map
void * operator new(std::size_t n) throw(std::bad_alloc)
{
void * const p = std::malloc(n);
if (p == NULL) throw std::bad_alloc();
std::cerr new() requests n bytes, allocated at p .\n;
return p;
}
void operator delete(void * p) throw()
{
std::cerr delete() at p .\n;
std::free(p);
}
int main()
{
std::string s = Hello World.;
std::mapint, int m { { 0, 1 } };
return s.length();
}
[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-02 23:03:17 UTC --- I think you need to mark operator new and delete as being exported.
[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 23:08:12 UTC --- Note that basic_stringchar, at variance with any std::map instantiation, is exported by the *.so, in particular the functions managing memory.
[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594 --- Comment #3 from Kerrek SB z0sh at sogetthis dot com 2011-10-02 23:32:47 UTC --- Thank you for the replies. Is this behaviour standard-conforming? Also, could you tell me how I mark the operators as exported, or just anything else that'll make the program behave as expected?
[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-02 23:41:39 UTC --- I don't see anything non-standard conforming in the library, for sure. Better asking Richard, I think, but I'm afraid you can't really do what you would like to do as soon as you start linking in code from *any* library (not just the standard C++ library and its basic_string instantiations) managing memory.
[Bug c++/39653] [C++0x] error referencing a more specialized variadic template from primary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39653 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-10-03 00:26:27 UTC --- Fixed by the patch for bug 35722.
[Bug c++/50595] New: template overload resolution insufficiently sensitive to name dependency?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50595 Bug #: 50595 Summary: template overload resolution insufficiently sensitive to name dependency? Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: za...@panix.com Created attachment 25401 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25401 test case Per http://stackoverflow.com/questions/7630806 the expected output of the attached test case should be f(char): 1 f(int): T(1) f(int): t f(char): 1 f(char): T(1) f(char): t since the second and third calls to f() in g() have arguments that are template-dependent, so resolution of *those* function calls (but not the first call) should be deferred until the point of instantiation (h()), at which time both f(int) and f(char) are visible. What actually happens with g++ 4.6 is f(char): 1 f(char): T(1) f(char): t f(char): 1 f(char): T(1) f(char): t I'm not 100% convinced by the argument above, but I am convinced enough to see what y'all think.
