[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-05/msg00609.htm ||l AssignedTo|unassigned at gcc dot |hp at gcc dot gnu.org |gnu.org | --- Comment #24 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-05-09 06:22:41 UTC --- Generic patch posted. I'll assign myself until the patch is shot down, though I haven't even tested whether it fixes the original target reported.
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #4 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-09 06:29:40 UTC --- Hi Honza, I forgot to say that I tried both -flto-partition=1to1 and -flto-partition=none with the same result the point is that the symbols in question refers to a templated function explicitly defined as template edm::eventsetup::EventSetupRecordKey edm::eventsetup::heterocontainer::makeKey_recordclassname_, edm::eventsetup::EventSetupRecordKey() in the attached there are three of those: only one is hidden. In the real library there are 307 of those, only 7 are hidden! SO I suspect some sort of bug in lto I will try to produce a synthetic test
[Bug tree-optimization/53290] New: ICE compiling aermod with Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53290 Bug #: 53290 Summary: ICE compiling aermod with Ofast Classification: Unclassified Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: venkataramanan.ku...@amd.com Command: gfortran aermod.f90 -O3 -o aermod Revision bug encountered: gcc187276 aermod.f90: In function âdeltahâ: aermod.f90:39547:0: error: definition in block 26 follows the use SUBROUTINE DELTAH(XARG) ^ for SSA_NAME: reassocpow.10153_319 in statement: reassocpow.10153_166 = __builtin_powif (reassocpow.10153_319, 2); aermod.f90:39547:0: internal compiler error: verify_ssa failed SUBROUTINE DELTAH(XARG) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I shall see which version cause that.
[Bug target/53291] New: Code generated for xtest is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291 Bug #: 53291 Summary: Code generated for xtest is wrong Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: kirill.yuk...@intel.com Hi, Andi discovered that xtest instruction generation is wrong. It generates xorl%esi, %esi xtest sete%sil but correct is reverse movl $1,%esi xtest setne %sil
[Bug tree-optimization/53290] ICE compiling aermod with Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53290 Venkataramanan venkataramanan.kumar at amd dot com changed: What|Removed |Added Target||x86_64-unknown-linux-gnu Host||x86_64-unknown-linux-gnu --- Comment #1 from Venkataramanan venkataramanan.kumar at amd dot com 2012-05-09 07:32:52 UTC --- (In reply to comment #0) Command: gfortran aermod.f90 -O3 -o aermod Revision bug encountered: gcc187276 aermod.f90: In function âdeltahâ: aermod.f90:39547:0: error: definition in block 26 follows the use SUBROUTINE DELTAH(XARG) ^ for SSA_NAME: reassocpow.10153_319 in statement: reassocpow.10153_166 = __builtin_powif (reassocpow.10153_319, 2); aermod.f90:39547:0: internal compiler error: verify_ssa failed SUBROUTINE DELTAH(XARG) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I shall see which version cause that. The command used is gfortran aermod.f90 -Ofast -o aermod
[Bug c++/53292] New: multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 Bug #: 53292 Summary: multi-threaded (OpenMP) is slower than single-threaded Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: f...@hotmail.com Created attachment 27352 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27352 cpp file to compile Hello, The problem is : multi-threaded (OpenMP) is slower than single-threaded Test has been ran several times successively. ChunkSize imposed to avoid false sharing. Test ran on Ubuntu 12.04 64 bits / 4Gb RAM / CPU i3 (dual core hyper-threaded : 2 physical cores + 2 logical cores) / gcc version : 4.6.2. Is the problem related to CPU ? i3 hyper-threaded would not be handled correctly by g++ or Ubuntu ? Can somebody help or give me clue ? Thanks, FH PS : I am not used to post bug, if this bug has not been posted in the right place feel free to tell me where to post it
[Bug target/53271] powerpc-eabispe build fails with ice on unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53271 --- Comment #2 from Alan Modra amodra at gcc dot gnu.org 2012-05-09 08:17:24 UTC --- Author: amodra Date: Wed May 9 08:17:09 2012 New Revision: 187316 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187316 Log: PR target/53271 * config/rs6000/rs6000.c (gen_frame_set): New function. (gen_frame_load, gen_frame_store): New functions. (rs6000_savres_rtx): Use the above. (rs6000_emit_epilogue, rs6000_emit_prologue): Here too. Correct mode used for CR2 in save/restore_world patterns. Don't emit instructions for eh_return frame unwind reg info. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/53271] powerpc-eabispe build fails with ice on unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53271 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Alan Modra amodra at gmail dot com 2012-05-09 08:18:09 UTC --- fixed
[Bug target/53271] powerpc-eabispe build fails with ice on unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53271 --- Comment #4 from hainque at adacore dot com hainque at adacore dot com 2012-05-09 08:52:01 UTC --- On May 9, 2012, at 10:18 , amodra at gmail dot com wrote: --- Comment #3 from Alan Modra amodra at gmail dot com 2012-05-09 08:18:09 UTC --- fixed Indeed ! Thanks a lot Alan :-)
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 09:10:35 UTC --- (In reply to comment #4) Hi Honza, I forgot to say that I tried both -flto-partition=1to1 and -flto-partition=none with the same result the point is that the symbols in question refers to a templated function explicitly defined as template edm::eventsetup::EventSetupRecordKey edm::eventsetup::heterocontainer::makeKey_recordclassname_, edm::eventsetup::EventSetupRecordKey() in the attached there are three of those: only one is hidden. In the real library there are 307 of those, only 7 are hidden! SO I suspect some sort of bug in lto I will try to produce a synthetic test All hidden symbols are postfixed with something like .local.77.4195, making them no longer the symbols for the explicitely instantiated functions. I suppose you say that the bug is that you have explicitely instantiated some templates which you want to have appear in the library as exported but LTO makes all instances hidden so that no externally visible symbol for that explicitely instantiated template remains?
[Bug tree-optimization/53290] ICE compiling aermod with Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53290 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 09:15:22 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53217 ***
[Bug tree-optimization/53217] [4.8 Regression] internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53217 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||venkataramanan.kumar at amd ||dot com --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 09:15:22 UTC --- *** Bug 53290 has been marked as a duplicate of this bug. ***
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 --- Comment #1 from FH fh_p at hotmail dot com 2012-05-09 09:17:29 UTC --- I am not sure to know if this problem is related rather to gcc or rather to Ubuntu. I started with the assumption that is should rather to related to gcc.
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 --- Comment #11 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-05-09 09:23:03 UTC --- Author: rsandifo Date: Wed May 9 09:22:57 2012 New Revision: 187320 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187320 Log: gcc/ PR middle-end/53249 * dwarf2out.h (get_address_mode): Move declaration to... * rtl.h: ...here. * dwarf2out.c (get_address_mode): Move definition to... * rtlanal.c: ...here. * var-tracking.c (get_address_mode): Delete. * combine.c (find_split_point): Use get_address_mode instead of targetm.addr_space.address_mode. * cselib.c (cselib_record_sets): Likewise. * dse.c (canon_address, record_store): Likewise. * emit-rtl.c (adjust_address_1, offset_address): Likewise. * expr.c (move_by_pieces, emit_block_move_via_loop, store_by_pieces) (store_by_pieces_1, expand_assignment, store_expr, store_constructor) (expand_expr_real_1): Likewise. * ifcvt.c (noce_try_cmove_arith): Likewise. * optabs.c (maybe_legitimize_operand_same_code): Likewise. * reload.c (find_reloads): Likewise. * sched-deps.c (sched_analyze_1, sched_analyze_2): Likewise. * sel-sched-dump.c (debug_mem_addr_value): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/cselib.c trunk/gcc/dse.c trunk/gcc/dwarf2out.c trunk/gcc/dwarf2out.h trunk/gcc/emit-rtl.c trunk/gcc/expr.c trunk/gcc/ifcvt.c trunk/gcc/optabs.c trunk/gcc/reload.c trunk/gcc/rtl.h trunk/gcc/rtlanal.c trunk/gcc/sched-deps.c trunk/gcc/sel-sched-dump.c trunk/gcc/var-tracking.c
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #12 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-05-09 09:24:16 UTC --- Patch applied.
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #6 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-09 09:39:54 UTC --- On 9 May, 2012, at 11:10 AM, rguenth at gcc dot gnu.org wrote: All hidden symbols are postfixed with something like .local.77.4195, making them no longer the symbols for the explicitely instantiated functions. I suppose you say that the bug is that you have explicitely instantiated some templates which you want to have appear in the library as exported but LTO makes all instances hidden so that no externally visible symbol for that explicitely instantiated template remains? correct. The additional point is that this happens only for some symbols, not all, even if the definitions/declarations are identical.
[Bug c/53293] New: Internal Compiler Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53293 Bug #: 53293 Summary: Internal Compiler Error Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: vikram2rh...@gmail.com -O2 : Internal Compiler Error (Segmentation fault) : gcc compiler fails on --param min-crossjump-insns=0 Command: gcc biariencode.i -c -O2 --param min-crossjump-insns=0
[Bug c/53293] Internal Compiler Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53293 --- Comment #1 from vikram vikram2rhyme at gmail dot com 2012-05-09 09:46:11 UTC --- Created attachment 27353 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27353 Preprocessed file
[Bug c/53293] Internal Compiler Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53293 --- Comment #2 from vikram vikram2rhyme at gmail dot com 2012-05-09 09:48:00 UTC --- ICE:SEGFAULT
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-09 Ever Confirmed|0 |1 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 09:58:09 UTC --- (In reply to comment #6) On 9 May, 2012, at 11:10 AM, rguenth at gcc dot gnu.org wrote: All hidden symbols are postfixed with something like .local.77.4195, making them no longer the symbols for the explicitely instantiated functions. I suppose you say that the bug is that you have explicitely instantiated some templates which you want to have appear in the library as exported but LTO makes all instances hidden so that no externally visible symbol for that explicitely instantiated template remains? correct. The additional point is that this happens only for some symbols, not all, even if the definitions/declarations are identical. Ok, so the question would be - why does GCC think this symbol is not possibly referenced from outside of the LTO unit?
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #8 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-09 10:03:33 UTC --- On 9 May, 2012, at 11:58 AM, rguenth at gcc dot gnu.org wrote: Ok, so the question would be - why does GCC think this symbol is not possibly referenced from outside of the LTO unit? Indeed.
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 10:15:21 UTC --- Btw, the testcase does not reproduce for me. What binutils version and which linker do you use? Do you actually end up using -fuse-linker-plugin? Because it reproduces for me with -fno-use-linker-plugin only (a path that is probably not very well tested these days ...)
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 --- Comment #2 from FH fh_p at hotmail dot com 2012-05-09 10:16:52 UTC --- I have just tested on another computer (CPU : Xeon5650 12 cores + OS : Scientific Linux) = I reproduce the unexpected behavior (OpenMP slower than single-threaded). So, I believe the problem is rather related to gcc (than to the OS) When I use more threads (export OMP_NUM_THREADS=2, then 6, then 12), OpenMP is more slower than single-threaded. (behavior related to thread initialisation ?)
[Bug c++/53294] New: Optimize out some exception code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53294
Bug #: 53294
Summary: Optimize out some exception code
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Hello,
it would be great if the compiler could transform code like:
try {
throw 42;
} catch(...) {
}
into nothing (or in practice into a simple goto, since there will be code
around). It already knows to remove the code after throw, it could statically
check that the exception will be caught locally and thus skip the __cxa_throw,
__cxa_begin_catch game.
Filed as C++ front-end, but it might be for the middle-end, since it would be
best if this optimization happened after inlining.
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #10 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-09 10:40:08 UTC --- On 9 May, 2012, at 12:15 PM, rguenth at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 10:15:21 UTC --- Btw, the testcase does not reproduce for me. What binutils version and which linker do you use? Do you actually end up using -fuse-linker-plugin? Because it reproduces for me with -fno-use-linker-plugin only (a path that is probably not very well tested these days …)we use ld -v GNU gold (GNU Binutils 2.21.1) 1.11 and we do not use explicitely -fuse-linker-plugin, gcc is configured as follow c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++,fortran --disable-multilib --enable-gold=yes --disable-nls --enable-lto --with-mpc=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --with-gmp=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --with-mpfr=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --prefix=/afs/cern.ch/user/i/innocent/w3/gcc47slc5 : (reconfigured) ./configure --enable-languages=c,c++,fortran --disable-multilib --enable-gold=yes --disable-nls --enable-lto --with-mpc=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --with-gmp=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --with-mpfr=/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0 --prefix=/afs/cern.ch/user/i/innocent/w3/gcc47slc5 Thread model: posix gcc version 4.7.1 20120508 (prerelease) [gcc-4_7-branch revision 187276] (GCC)
[Bug c++/53289] unnecessary repetition of caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53289 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09 10:45:38 UTC --- There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01836.html No comments so far. Feel free to comment.
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #11 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-09 10:47:02 UTC --- if I add -fuse-linker-plugin I get c++: error: -fuse-linker-plugin is not supported in this configuration my understanding was that since 4.6 linker-plugin was not required anymore for lto
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #2 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 10:50:35 UTC --- Created attachment 27354 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27354 Original C code
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #3 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 10:51:15 UTC --- Created attachment 27355 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27355 Preprocessed with -O0 optimization flag
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #4 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 10:51:52 UTC --- Created attachment 27356 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27356 Preprocessed with -O1 optimization flag
[Bug c++/53287] self-initialization warning doesn't seem to work for non-primitive types...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53287 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-09 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09 10:51:44 UTC --- For sure this is a bug. What is the correct behaviour is not so clear.
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #5 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 10:52:50 UTC --- Created attachment 27357 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27357 Preprocessed with -O2 optimization flag
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #6 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 10:53:19 UTC --- Created attachment 27358 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27358 Preprocessed with -O3 optimization flag
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #7 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 10:54:33 UTC --- Hello: I attach the preprocessed files with optimization flags -O0, -O1, -O2 and -O3 Thanks
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #8 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 10:56:34 UTC --- I have used gcc 4.7.0
[Bug c/50476] Warn of pointer set to object whose lifetime is limited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09
11:05:39 UTC ---
I think it is only undefined behaviour to access the pointer after the
life-time of y has finished, however, the following probably isn't, no?
void g()
{
...
*x = 2;
...
}
void f()
{
...
x = y;
...
g();
...
x = NULL;
}
The C/C++ FE cannot distinguish between these two cases.
Do you have a suggestion about how to implement this?
I think it would require some kind of constant propagation to know that the
final value of x is safe, but no existing contributor is interested in
implementing such thing, so someone new has to step up and do the work.
[Bug c++/50359] poor error message for an undeclared identifier in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50359 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org Known to fail||4.7.1 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09 11:10:21 UTC --- And in G++ 4.8.0. I guess this has something to do with tentative parsing, but someone would need to launch GDB and investigate what goes wrong in detail.
[Bug other/53284] Several libatomic tests fail on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53284 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-05-09 11:45:10 UTC --- --- Comment #1 from Richard Henderson rth at gcc dot gnu.org 2012-05-08 22:39:35 UTC --- Can you investigate why configure decides that __atomic_compare_exchange_8 is implemented inline? That it isn't inline is obvious from the recursion. That was the critical hint, thanks. Comparing i386-pc-solaris2.10 and i686-unknown-linux-gnu config.log, I see that in the Linux case the test is run as a link test and includes -fno-sync-libcalls $XCFLAGS, while in the Solaris case, it's an compile test and lacks all of them. Was the configure change to CFLAGS in fact wrong? No, that's unrelated. The following patch works for me and lets all tests in the above configuration pass. I've chosen to add to CFLAGS rather than adding $XCFLAGS since otherwise we loose -fno-sync-libcalls. Ok for mainline? Thanks. Rainer 2012-05-09 Rainer Orth r...@cebitec.uni-bielefeld.de * acinclude.m4 (LIBAT_TEST_ATOMIC_BUILTIN): Add -O0 -S to CFLAGS instead of overriding. * configure: Regenerate. diff --git a/libatomic/acinclude.m4 b/libatomic/acinclude.m4 --- a/libatomic/acinclude.m4 +++ b/libatomic/acinclude.m4 @@ -67,7 +67,7 @@ AC_DEFUN([LIBAT_TEST_ATOMIC_BUILTIN],[ else old_CFLAGS=$CFLAGS # Compile unoptimized. - CFLAGS='-O0 -S' + CFLAGS=$CFLAGS -O0 -S if AC_TRY_EVAL(ac_compile); then if grep __atomic_ conftest.s /dev/null 21 ; then eval $2=no
[Bug c/50476] Warn of pointer set to object whose lifetime is limited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476
--- Comment #3 from Rui Maciel rui.maciel at gmail dot com 2012-05-09
11:47:49 UTC ---
(In reply to comment #2)
I think it is only undefined behaviour to access the pointer after the
life-time of y has finished, however, the following probably isn't, no?
void g()
{
...
*x = 2;
...
}
As x hasn't been declared at that point, it should throw a compiler error.
If x was a global pointer which was declared previously then a similar problem
would arise. Take, for example, the following code:
code
#include stdio.h
int *x = 0;
void f(void)
{
int a = 2;
x = a;
}
int main(void)
{
f();
printf(Value: %d\n,*x);
return 0;
}
/code
Again, x is set to the address of a local variable, which is then accessed at a
point where the local variable's lifetime has ended. This behaviour is
explicitly left undefined in ISO 9899:1999 6.2.4 2. Therefore, it would be
nice if the compiler warned about that.
void f()
{
...
x = y;
...
g();
...
x = NULL;
}
The C/C++ FE cannot distinguish between these two cases.
Do you have a suggestion about how to implement this?
From the user's point of view, it would be nice if the compiler warned if an
object was being accessed after its lifetime. This should happen at least when
the user explicitly specified the use of a standard which stated that this
behaviour is undefined.
Granted, this might not be an easy thing to implement. As I don't have any
knowledge on gcc's inner workings, I'm not in a position to suggest how this
might be done.
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org 2012-05-09 11:50:09
UTC ---
glibc still has:
# define strspn(s, accept) \
__extension__ \
({ char __a0, __a1, __a2; \
(__builtin_constant_p (accept) __string2_1bptr_p (accept) \
? ((__builtin_constant_p (s) __string2_1bptr_p (s)) \
? __builtin_strspn (s, accept) \
: ((__a0 = ((const char *) (accept))[0], __a0 == '\0') \
? ((void) (s), 0) \
: ((__a1 = ((const char *) (accept))[1], __a1 == '\0')\
? __strspn_c1 (s, __a0)\
: ((__a2 = ((const char *) (accept))[2], __a2 == '\0') \
? __strspn_c2 (s, __a0, __a1) \
: (((const char *) (accept))[3] == '\0' \
? __strspn_c3 (s, __a0, __a1, __a2) \
: __builtin_strspn (s, accept)) \
: __builtin_strspn (s, accept)); })
The lone 0 in the middle should be explicitly cast to size_t, like it is for
fread_unlocked. Could you report it to glibc please?
gcc could avoid this warning when converting a constant, I am pretty sure the
same issue (possibly with another macro) already led to such a conversation...
[Bug c/53293] Internal Compiler Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53293
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org 2012-05-09 12:06:37
UTC ---
typedef struct {
unsigned Ebits_to_go ;
int C
} * EncodingEnvironmentPtr ;
arienco_done_encoding ( EncodingEnvironmentPtr eep ) {
if ( ( eep - Ebits_to_go ) ) {
while ( eep - C ) {
while ( 7 ) {
}
}
}
}
[Bug tree-optimization/53295] New: Vectorizer support for non-constant strided loads depends on gather support overwriting the data-ref with bogus data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53295
Bug #: 53295
Summary: Vectorizer support for non-constant strided loads
depends on gather support overwriting the data-ref
with bogus data
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: m...@gcc.gnu.org
If you look at the testcase for PR53185 you can see that we compute the
data-reference for the strided load twice:
Creating dr for *D.1732_13
analyze_innermost: failed: evolution of base is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: *pretmp.15_35
Access function 0: {0B, +, (long unsigned int) pretmp.17_38 * 4}_2
this is the failing one (because analyze_innermost does not allow for
non-constant strides - sth to be really fixed).
Creating dr for *D.1732_13
analyze_innermost: success.
base_address: pretmp.15_35 + (long unsigned int) D.1729_10 * 4
offset from base address: 0
constant offset from base address: 0
step: 0
aligned to: 128
base_object: *D.1732_13
that's the one by gather support, guarded by
targetm.vectorize.builtin_gather != NULL (which is only !NULL on x86). But
this DR is for basic-block analysis, thus does not properly reflect
what the non-constant strided load code would want to use (it doesn't use
that info though).
Possibly the non-constant strided load testcases fail on targets other than
x86 (with support for vectorizing doubles).
[Bug tree-optimization/53295] Vectorizer support for non-constant strided loads depends on gather support overwriting the data-ref with bogus data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53295 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 12:15:43 UTC --- The testcase probably only fails on SPU (the only target besides x86 that has target support for vect_double according to the testsuite harness ...)
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-09 12:15:53 UTC --- This is just a bad test. You are storing the values in the different threads, but then reading everything in a single thread only.
[Bug tree-optimization/53226] [4.8 Regression] Endless loop in forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-09 12:19:41 UTC --- Author: jakub Date: Wed May 9 12:19:34 2012 New Revision: 187328 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187328 Log: PR tree-optimization/53226 * tree-ssa-forwprop.c (ssa_forward_propagate_and_combine): Remove prev and prev_initialized vars, gimple_set_plf (stmt, GF_PLF_1, false) before processing it and gimple_set_plf (stmt, GF_PLF_1, true) if it doesn't need to be revisited, look for earliest stmt with !gimple_plf (stmt, GF_PLF_1) if something changed. * gcc.c-torture/compile/pr53226.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr53226.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #12 from Jan Hubicka hubicka at ucw dot cz 2012-05-09 12:21:38 UTC --- if I add -fuse-linker-plugin I get c++: error: -fuse-linker-plugin is not supported in this configuration my understanding was that since 4.6 linker-plugin was not required anymore for lto No, LTO plugin is needed for proper LTO and will always be. We have alternative non-plugin path that results in poorer code quality. In non-plugin path there is logic to privatize comdats whose address is not taken, since they can be duplicated. With explicit instantiation this code however should not trigger. I will check. Honza
[Bug tree-optimization/53226] [4.8 Regression] Endless loop in forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-09 12:31:47 UTC --- Fixed.
[Bug tree-optimization/53290] ICE compiling aermod with Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53290 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-05-09 12:33:16 UTC --- As a temporary work around for aermod.f90, you can compile it with '-fprotect-parens -Ofast' (it does not work for the code in pr53217). Also a patch has been submitted at http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00607.html
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #13 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-09 12:35:51 UTC --- On 9 May, 2012, at 2:21 PM, hubicka at ucw dot cz wrote: No, LTO plugin is needed for proper LTO and will always be. We have alternative non-plugin path that results in poorer code quality. I see. could you please specify the configure options to be used ? I tried --enable-linker-plugin and does not help thois is how I configured latest version of the trunk c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl --with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib --enable-linker-plugin Thread model: posix gcc version 4.8.0 20120509 (experimental) [trunk revision 187326] (GCC) and I get c++ -fuse-linker-plugin -fvisibility-inlines-hidden -O2 -flto -shared -fPIC -o bha.so d1.cc d2.cc d3.cc c++: error: -fuse-linker-plugin is not supported in this configuration
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09 12:45:54 UTC --- (In reply to comment #9) gcc could avoid this warning when converting a constant, I am pretty sure the same issue (possibly with another macro) already led to such a conversation... This is not a constant. It is a conditional expression of type int. This is PR51294. And there is PR52617. Plenty of bugs to fix...
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 --- Comment #4 from FH fh_p at hotmail dot com 2012-05-09 12:53:46 UTC --- I don't understand your answer. Timing just times the for loop. Checking array content is single threaded : this is added to make sure the for loop has done the job correctly and this check is not timed. The array to initialize is shared by threads (shared by default) ans not private to each thread. To me, the test seems relevant. If it's not, why ? And how to modify it ?
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 FH fh_p at hotmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from FH fh_p at hotmail dot com 2012-05-09 12:55:56 UTC --- To me, the test seems relevant. If it's not, why ? And how to modify it ?
[Bug tree-optimization/18437] vectorizer failed for matrix multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 12:59:49 UTC --- Author: rguenth Date: Wed May 9 12:59:46 2012 New Revision: 187330 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187330 Log: 2012-05-09 Richard Guenther rguent...@suse.de PR tree-optimization/18437 * gfortran.dg/vect/rnflow-trs2a2.f90: Move ... * gfortran.dg/vect/fast-math-rnflow-trs2a2.f90: ... here. Added: trunk/gcc/testsuite/gfortran.dg/vect/fast-math-rnflow-trs2a2.f90 - copied unchanged from r187329, trunk/gcc/testsuite/gfortran.dg/vect/rnflow-trs2a2.f90 Removed: trunk/gcc/testsuite/gfortran.dg/vect/rnflow-trs2a2.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #11 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 13:06:56 UTC --- Report to glibc sent
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #12 from Marc Glisse glisse at gcc dot gnu.org 2012-05-09 13:11:01 UTC --- (In reply to comment #10) This is PR51294. Looks different. Here the compiler complains about casting 0 to size_t. And there is PR52617. That one is not a bug, unless you want to do the opposite of what the OP asked and use constant propagation to remove the current warning as well.
[Bug c/52617] -Wconversion does not work for strlen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52617 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09 13:11:56 UTC --- This is not a bug, but a feature. If the result of strlen fits in the target type, no warning is given. If you make s1 a signed char and strlen a very very long string, then you get an overflow warning.
[Bug lto/48423] crash when using lto, linker plugin with bfd ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48423 --- Comment #11 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-09 13:16:30 UTC --- I found the reference in the binutil bugzilla http://sourceware.org/bugzilla/show_bug.cgi?id=12629 was fixed by Ian in gold on 2011-06-30.
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-09 13:29:00 UTC --- Sorry, missed you aren't measuring it with the single-threaded loop. Anyway, the test is still not relevant, it is purely memory bound, and as you can see from running it with very small arguments, the thread creation and omp for initial overhead is in the noise, what you see is just how the cache hierarchy of your CPU works. The inner loop in which all the measured time is spent in is very similar (and even if hand edited to be identical it doesn't help at all).
[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249 --- Comment #13 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-05-09 13:32:22 UTC --- Author: hjl Date: Wed May 9 13:32:13 2012 New Revision: 187331 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187331 Log: Add a test for PR middle-end/53249 PR middle-end/53249 * gcc.target/i386/pr53249.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr53249.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09 13:34:15 UTC --- (In reply to comment #12) (In reply to comment #10) This is PR51294. Looks different. Here the compiler complains about casting 0 to size_t. No, it is not. GCC gives a very different message for implicit constant conversions. Looking in more detail, I think the problem may be ((void)s, 0), which is not recognized as a constant by Wconversion. And there is PR52617. That one is not a bug, unless you want to do the opposite of what the OP asked and use constant propagation to remove the current warning as well. You are right. Closed.
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09 13:45:15 UTC --- (In reply to comment #11) if I add -fuse-linker-plugin I get c++: error: -fuse-linker-plugin is not supported in this configuration my understanding was that since 4.6 linker-plugin was not required anymore for lto Since GCC 4.6 a linker-plugin is used automatically if a suitable linker is found. If that doesn't work for you that means the configure check linker plugin support fails - you have to check why. Did you build binutils with support for plugins?
[Bug c++/53294] Optimize out some exception code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53294
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-05-09
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-09
13:55:37 UTC ---
Certainly interesting. We lower things too early into __cxa calls though
(I think) to make this work easily.
Consider cases like
struct X { int i; };
int foo (void)
{
try {
X x;
x.i = 5;
throw x;
} catch (X x) {
return x.i;
} catch (...) {
return 0;
}
}
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 --- Comment #7 from FH fh_p at hotmail dot com 2012-05-09 14:36:00 UTC --- Well... Still don't really get why it is not possible to improve performance for such basic things. I tried with allocations up to 7 Gb or more (RAM full + SWAP full) : I still get the same result that looks unexpected to me ?! Anyway, I guess I won't be able to get the logic of this...
[Bug lto/53282] lto and visibility-inlines-hidden makes wrongly hidden symbols and in a way that depends on the order of the input compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282 --- Comment #15 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-09 14:48:20 UTC --- I'm indeed using a ld that is not the one of the system. googling around I found this: http://comments.gmane.org/gmane.comp.gcc.help/41304 titled g++: error: -fuse-linker-plugin is not supported in this configuration at some point it hints to the fact the gcc configure seems to ignore the ld in the path and uses the system one, detects no plugin etc. I configured gcc with --with-ld=/usr/local/bin/ld and it does not help LD=/usr/local/bin/ld neither. I'm sure that plugin is supported by this version of ld. I wil try more, any suggestion is appreciated. in the mean time we can change the bug report saying that it happens if the linker-plugin is not used…
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-09
15:01:24 UTC ---
Just try equivalent pthread program and you'll note the same behavior.
#include pthread.h
#include stdlib.h
double *p;
int c;
void *tf (void *x)
{
int i, s = ((long) x) * c, e = s + c;
for (i = s; i e; i++)
p[i] = 1.0;
return NULL;
}
int
main (int argc, char **argv)
{
int n = atoi (argv[1]), i;
int sz = atoi (argv[2]);
if (n 32 || n 1 || sz 128 || (sz % n) != 0)
return 1;
p = malloc (sz * sizeof (double));
if (p == NULL)
return 1;
c = sz / n;
pthread_t t[32];
for (i = 1; i n; i++)
pthread_create (t[i], NULL, tf, (void *)(long) i);
tf ((void *) 0L);
for (i = 1; i n; i++)
pthread_join (t[i], NULL);
return 0;
}
[Bug c/53277] Warning using -Wconversion and -Ox in gcc 4.5, 4.6 and 4.7 but not in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 --- Comment #14 from José Luis García Pallero jgpallero at gmail dot com 2012-05-09 15:01:30 UTC --- Fixed in glibc: http://sourceware.org/bugzilla/show_bug.cgi?id=14083 http://sourceware.org/git/?p=glibc.git;a=commit;h=1a4b75a190006bb013a61f2031a4de86e93a629f
[Bug target/53291] Code generated for xtest is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-09 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-09 15:17:03 UTC --- Testcase?
[Bug fortran/45424] F2008: Add is_contiguous intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-09 15:36:40 UTC --- Created attachment 27359 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27359 Draft patch: is_contiguous.diff Attached is a mostly ready patch for IS_CONTIGUOUS. The main TODO is to understand when IS_CONTIGUOUS should print .TRUE. and when .FALSE. The standard is not very clear about it, cf. 5.3.7 of F2008. a) Array element with nonzero strides (which is still a single array element): a(1:1:1) vs. a(1:1:5). With the attached patch but also with ifort and crayftn, the result is .true. and .false. The attached patch only checks the stride, ignoring the number of elements. b) The same - but instead of a single element, using zero-sized arrays: a(2:1:1) vs. a(2:1:2). c) The following example is mishandled as we have a stride and not a stride multiplied (sm): type t integer :: i, j end type t type(t) :: x(5) print *, is_contiguous(x(:)) ! Shall be (and is) true print *, is_contiguous(x(:)%i) ! Shall be false - but prints true. end The fortran-devel solution would be to use: sm == TYPE_SIZE(a%i). The trunk solution is to compare the array spec's object a with the the type-size of a%i - and if it differs to abort. d) The gfc_is_simply_contiguous function needs to be refined and extended - and a gfc_is_simply_noncontiguous has to be added. e) More tests are needed - including polymorphic arrays and compile-time checks for the code in simplify.c. [Which is related to (d).] f) For TS29113, one needs to handle assumed-rank arrays, including rank-1 ones. Again the question is whether the dummy argument associated with a scalar is then contiguous or not.
[Bug fortran/53296] New: Segfault on non-constant character array constructor containing kind spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53296 Bug #: 53296 Summary: Segfault on non-constant character array constructor containing kind spec Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: gccbgz.li...@xoxy.net Created attachment 27360 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27360 source raising the segfault Executing the binary compiled from attached source prints: size 78 arr: ABCDEGHIJ size 1 Speicherzugriffsfehler (Speicherabzug geschrieben) Besides the segfault, the array size should not change. This is not reproducable when replacing the character(*)-type entities by integer(INT64) nor when omitting the function call in the constructor.
[Bug c/53277] -Wconversion cannot handle compound expresions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277
--- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09
15:52:48 UTC ---
A simpler testcase:
int main() {
char i = 1;
char x = ((void) i, 0);
x = i ? x : ((void) i, 0);
return 0;
}
[Bug c++/53287] self-initialization warning doesn't seem to work for non-primitive types...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53287 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-09 15:56:15 UTC --- I'm pretty sure this is a dup - it's at least discussed in another bug I've commented on, w.r.t self-init of a std::string
[Bug c++/53281] poor error message for calling a non-const method from a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-09 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-09 15:59:09 UTC --- confirmed (but any change to the diagnostic should not mention the word method because C++ has member functions not methods)
[Bug c/53275] GCC-4.4.4 gives error: ld: fatal: Symbol referencing errors. No output written to sparc_SunOS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53275 birender.singh at hotmail dot com changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from birender.singh at hotmail dot com 2012-05-09 15:59:33 UTC --- This error resolved by adding library -lresolv -lrt Thanks to all. -Birender
[Bug fortran/45424] F2008: Add is_contiguous intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-09 16:02:18 UTC --- (In reply to comment #1) a) Array element with nonzero strides I meant: A an array containing a single element and having a nonunity stride. type t integer :: i, j end type t print *, is_contiguous(x(:)%i) ! Shall be false - but prints true. Those kind of arguments can get really tricky! Assume as component a: integer :: i(1) ! or i(2) or class(t), allocatable :: a or integer, allocatable :: a(:) which is accessed as is_contiguous(x(:)%a(1)). Intel and Cray handle it simply: by always returning F - even for type t; integer :: i; end type, which should have no padding and be contiguous in memory. We could do the same - or we rule out BT_CLASS, arrays and coarrays and do then a size check: whole derived type == expr-ts.type size. Another issue are substrings. For those one needs to check that the substring range matches the string length.
[Bug libstdc++/53297] New: Linker error on solaris 10 using gcc-4.4.4 64bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297 Bug #: 53297 Summary: Linker error on solaris 10 using gcc-4.4.4 64bit. Classification: Unclassified Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: birender.si...@hotmail.com Machine used: Solaris10 sparc After successfully Build gcc-4.4.4 64bit on solaris10 sparc and using it. Below error received while compiling a test code using GCC-4.4.4 64bit. . . . . ../prodStartLicTest/prodStartLicTest.h: In member function 'int prodStartLicTest::verifyDecryptedText(char*)': ../prodStartLicTest/prodStartLicTest.h:1361: warning: cannot pass objects of non-POD type 'struct std::string' through '...'; call will abort at runtime ../prodStartLicTest/prodStartLicTest.h: In member function 'void prodStartLicTest::prodStartEnumTest(char*, const char*, int, SLIC_STATUS)': ../prodStartLicTest/prodStartLicTest.h:1509: warning: deprecated conversion from string constant to 'char*' ../prodStartLicTest/prodStartLicTest.h: In member function 'void prodStartLicTest::prodStartEnumTest(char*, const char*, int, SLIC_STATUS, int, int)': ../prodStartLicTest/prodStartLicTest.h:1692: warning: deprecated conversion from string constant to 'char*' ../../../nobuilds/bin/fipsld -m64 -o sparc_SunOS_64/release/SuiteMain sparc_SunOS_64/release/SuiteMain.o -L/els/install/staf64/lib -lSTAF ../../../nobuilds /key/sparc_SunOS_64/release/slic_devkey.o -L../../../nobuilds/lib/sparc_SunOS_64/release -lslic -lPoco -lopenssl -lm -lstdc++ ../SlicTestLib/sparc_SunOS_64/r elease/libSlicTest.a -lresolv -lrt -lc -ldl -lsocket -lnsl Undefined first referenced symbol in file std::basic_streambufchar, std::char_traitschar ::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode) ../../../nobuilds/lib/sparc_SunOS_64/release/l ibPoco.a(Base64Decoder.o) ld: fatal: Symbol referencing errors. No output written to sparc_SunOS_64/release/SuiteMain collect2: ld returned 1 exit status make[3]: *** [sparc_SunOS_64/release/SuiteMain] Error 1 make[3]: Leaving directory `/els/licensing/licensing_sdk/trunk/qa/SuiteMain' make[2]: *** [all] Error 2 make[2]: Leaving directory `/els/licensing/licensing_sdk/trunk/qa/SuiteMain' make[1]: *** [all_subdirs] Error 1 make[1]: Leaving directory `/els/licensing/licensing_sdk/trunk/qa' make: *** [all] Error 2 Please provide some solution. Regards, -BK
[Bug c/53275] GCC-4.4.4 gives error: ld: fatal: Symbol referencing errors. No output written to sparc_SunOS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53275 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-05-09 16:07:32 UTC --- It's invalid because it isn't a compiler issue.
[Bug driver/31351] gcc -v --help has poor documentation for some shared Ada/C options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31351 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-09 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-09 16:08:47 UTC --- This is a bug yes, but it won't get fixed unless someone that cares about it steps up to fix it.
[Bug tree-optimization/53185] [4.8 Regression] segmentation fault in vectorizable_load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185 --- Comment #6 from Michael Matz matz at gcc dot gnu.org 2012-05-09 16:08:37 UTC --- Author: matz Date: Wed May 9 16:08:26 2012 New Revision: 187340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187340 Log: PR tree-optimization/53185 * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Disable peeling when we see strided loads. testsuite/ * gcc.dg/vect/pr53185.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr53185.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 --- Comment #6 from Nick Clifton nickc at gcc dot gnu.org 2012-05-09 16:20:33 UTC --- Author: nickc Date: Wed May 9 16:20:17 2012 New Revision: 187341 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187341 Log: PR bootstrap/50461 * configure.ac (mpfr-dir): When using in-tree MPFR sources allow for the fact that from release v3.1.0 of MPFR the source files were moved into a src sub-directory. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
[Bug libstdc++/53297] Linker error on solaris 10 using gcc-4.4.4 64bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-09 Ever Confirmed|0 |1 Severity|major |normal --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-09 16:23:13 UTC --- This isn't a proper bug report, see: http://gcc.gnu.org/bugs/#report Also note that the 4.4.x release series is not maintained anymore, thus I would first check a more recent release, eg, 4.6.x.
[Bug libstdc++/53297] Linker error on solaris 10 using gcc-4.4.4 64bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-09 16:28:20 UTC --- Oh well. *** This bug has been marked as a duplicate of bug 53275 ***
[Bug c/53275] GCC-4.4.4 gives error: ld: fatal: Symbol referencing errors. No output written to sparc_SunOS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53275 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-09 16:28:20 UTC --- *** Bug 53297 has been marked as a duplicate of this bug. ***
[Bug target/53256] [avr] Attribute 'interrupt' shall override attribute 'signal'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53256 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-09 16:29:06 UTC --- Author: gjl Date: Wed May 9 16:28:53 2012 New Revision: 187342 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187342 Log: PR target/53256 * config/avr/elf.h (ASM_DECLARE_FUNCTION_NAME): Remove. * config/avr/avr-protos.h (avr_asm_declare_function_name): Remove. * config/avr/avr.h (struct machine_function): Add attributes_checked_p. * config/avr/avr.c (avr_asm_declare_function_name): Remove. (expand_prologue): Move initialization of cfun-machine-is_naked, is_interrupt, is_signal, is_OS_task, is_OS_main from here to... (avr_set_current_function): ...this new static function. (TARGET_SET_CURRENT_FUNCTION): New define. (avr_function_ok_for_sibcall): Use cfun-machine-is_* instead of checking attributes of current_function_decl. (avr_regs_to_save): Ditto. (signal_function_p): Rename to avr_signal_function_p. (interrupt_function_p): Rename to avr_interrupt_function_p. * doc/extend.texi (Function Attributes): Better explanation of 'interrupt' and 'signal' for AVR. Move 'ifunc' down to establish alphabetical order. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/elf.h trunk/gcc/doc/extend.texi
[Bug target/53256] [avr] Attribute 'interrupt' shall override attribute 'signal'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53256 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-09 16:39:39 UTC --- Author: gjl Date: Wed May 9 16:39:33 2012 New Revision: 187343 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187343 Log: Backport from 2012-05-12 mainline r187342. PR target/53256 * config/avr/elf.h (ASM_DECLARE_FUNCTION_NAME): Remove. * config/avr/avr-protos.h (avr_asm_declare_function_name): Remove. * config/avr/avr.h (struct machine_function): Add attributes_checked_p. * config/avr/avr.c (avr_asm_declare_function_name): Remove. (expand_prologue): Move initialization of cfun-machine-is_naked, is_interrupt, is_signal, is_OS_task, is_OS_main from here to... (avr_set_current_function): ...this new static function. (TARGET_SET_CURRENT_FUNCTION): New define. (avr_function_ok_for_sibcall): Use cfun-machine-is_* instead of checking attributes of current_function_decl. (avr_regs_to_save): Ditto. (signal_function_p): Rename to avr_signal_function_p. (interrupt_function_p): Rename to avr_interrupt_function_p. * doc/extend.texi (Function Attributes): Better explanation of 'interrupt' and 'signal' for AVR. Move 'ifunc' down to establish alphabetical order. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/avr/avr-protos.h branches/gcc-4_7-branch/gcc/config/avr/avr.c branches/gcc-4_7-branch/gcc/config/avr/avr.h branches/gcc-4_7-branch/gcc/config/avr/elf.h branches/gcc-4_7-branch/gcc/doc/extend.texi
[Bug tree-optimization/53185] [4.8 Regression] segmentation fault in vectorizable_load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Michael Matz matz at gcc dot gnu.org 2012-05-09 16:40:31 UTC --- Fixed.
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-09 16:44:07 UTC --- Hmm, I guess this is for the case where gthr-aix.h includes gthr-single.h, which doesn't define the C++11 interface. The configure script determined that _GLIBCXX_HAS_GTHREADS should be defined, but then that only works if gthr-posix.h gets included. A fix (maybe not the right one) would be to add the C++11 types and functions to gthr-single.h and make it define __GTHREADS_CXX0X, so that thread can be be compiled and the types found, even if the resulting classes can't actually be used in single-threaded mode. Another option would be for gthr-aix.h to #undef _GLBCXX_HAS_GTHREADS in the non-_THREAD_SAFE case, but I think that would be wrong, changing a property that should be fixed at configure time into one that depends on switches being used or not when the user compiles code. I won't be able to work on that until I'm back from holiday in two weeks, in the meanwhile --disable-libstdcxx-threads should allow you to bootstrap, or maybe just --disable-libstdcxx-pch
[Bug target/53291] Code generated for xtest is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
--- Comment #2 from Yukhin Kirill kirill.yukhin at intel dot com 2012-05-09
16:53:12 UTC ---
(In reply to comment #1)
Testcase?
It is trivial, so posting right here:
#include immintrin.h
unsigned a;
int
rtm_xtest (void)
{
if (_xtest ())
a = 1;
}
./build-x86_64-linux/gcc/xgcc -B./build-x86_64-linux/gcc 1.c -S -mrtm
$ cat 1.s
...
xtest
sete%al
movsbl %al, %eax
testl %eax, %eax
je .L4
movl$1, a(%rip)
...
[Bug target/44141] Redundant loads and stores generated for AMD bdver1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Keywords|ra | AssignedTo|venkataramanan.kumar at amd |ubizjak at gmail dot com |dot com | Target Milestone|--- |4.8.0 --- Comment #19 from Uros Bizjak ubizjak at gmail dot com 2012-05-09 16:58:58 UTC --- I have a patch in testing.
[Bug target/53256] [avr] Attribute 'interrupt' shall override attribute 'signal'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53256 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-09 17:03:49 UTC --- Added in 4.7.1
[Bug fortran/53298] New: ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298 Bug #: 53298 Summary: ICE in gfc_conv_scalarized_array_ref for ARRAY + substring Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Blocks: 45424 The following program segfaults. The problem is the expression array(:)(1:) ^^^ substring This combination is seemingly not handled by gfc_conv_expr_descriptor. At the end, one gets a segfault for: gfc_conv_scalarized_array_ref (se=0x7fffcfe0, ar=0x1700538) at fortran/trans-array.c:3016 3016 expr = ss-info-expr; which is called via gfc_conv_array_ref gfc_conv_variable gfc_conv_string_length get_array_charlen gfc_conv_expr_descriptor. character(len=5) :: str(3) call f(str(:)) contains subroutine f(x) character(len=*) :: x(:) logical :: print *, size(x(:)(1:)) end subroutine f end The program compiles flawlessly with NAG f95 and prints 3. It fails with GCC 4.1.2, 4.3.4, 4.8.0 and probably all other versions.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-09 17:12:14 UTC --- (In reply to comment #12) You might try configuring with --disable-libstdcxx-threads. It disables C++11 threads support. guard.cc is always built, it's part of libsupc++ so it's nothing to do with the C++11 thread library. I'm pretty sure we've already dealt with this failure elsewhere, IIRC the linuxthreads pthread_mutex_t type has a volatile member causing the default assignment operator to be deleted. For PR 51296 I added a way to force use of __GTHREAD_MUTEX_INIT_FUNCTION, by defining _GTHREAD_USE_MUTEX_INIT_FUNC in libstdc++-v3/config/os/.../os_defines.h We might want to put something in config/os/gnu-linux/os_defines.h so that the macro is defined when using linuxthreads
[Bug target/53291] Code generated for xtest is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291 --- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-09 17:17:56 UTC --- Correction. We can keep the xor %reg,%reg. We just need it because setnz only sets 8 bit to initialize the higher order bits. Alternatively the value can be zero extended afterwards or just stay at 8 bit if there is no need for it.
[Bug fortran/53296] Segfault on non-constant character array constructor containing kind spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53296 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org Known to fail||4.6.1, 4.8.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-09 17:22:43 UTC --- It also doesn't segfault if one replaces the call by: call rou( [character(len=120) :: 123,uCase(abcde),uCase(ghij)]) Namely: adding as first item in the constructor list a string literal (which by construction has a known length). According to VALGRIND, the problem is an Invalid free() / delete / delete[] / realloc() in line 10 or, if commented, in line 9. Line 9 is the call rou line. With ifort 12.1, the programs seems to work while with cryftn it fails at run time with an illegal instruction. In any case, the program looks valid to me.
[Bug c++/53288] [C++11] Reference fails to bind directly to prvalue member access expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-09 17:23:42 UTC --- It compiles fine with 4.7 or trunk. I think this is a dup of an existing bug Jason fixed, possibly one he reported himself, about elements of rvalue arrays.
[Bug c/53275] GCC-4.4.4 gives error: ld: fatal: Symbol referencing errors. No output written to sparc_SunOS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53275 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-09 17:31:17 UTC --- This Bugzilla is for bugs in GCC, not help fixing your code. Please use the gcc-h...@gcc.gnu.org mailing list for questions about using GCC and help fixing compilation failures. None of the bugs you've reported have been problems caused by GCC.
[Bug other/53284] Several libatomic tests fail on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53284 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-09 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2012-05-09 18:00:29 UTC --- Yep, that looks good.
[Bug target/44141] Redundant loads and stores generated for AMD bdver1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141 --- Comment #20 from uros at gcc dot gnu.org 2012-05-09 18:06:52 UTC --- Author: uros Date: Wed May 9 18:06:47 2012 New Revision: 187347 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187347 Log: PR target/44141 * config/i386/i386.c (ix86_expand_vector_move_misalign): Do not handle 128 bit vectors specially for TARGET_AVX. Emit sse2_movupd and sse_movupd RTXes for TARGET_AVX, TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL or when optimizing for size. * config/i386/sse.md (*movmode_internal): Remove TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL handling from asm output code. Calculate mode attribute according to optimize_function_for_size_p and TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL flag. (*sse_movussemodesuffixavxsizesuffix): Choose asm template depending on the mode of the instruction. Calculate mode attribute according to optimize_function_for_size_p, TARGET_SSE_TYPELESS_STORES and TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL flags. (*sse2_movdquavxsizesuffix): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md
[Bug other/53299] New: libiberty usage of GCC_PICFLAG causes -fPIC to be passed to non-GNU compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53299 Bug #: 53299 Summary: libiberty usage of GCC_PICFLAG causes -fPIC to be passed to non-GNU compiler Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: sparc64-sun-solaris2.8 Target: sparc64-sun-solaris2.8 Build: sparc64-sun-solaris2.8 In the course of bootstrapping 4.7.0 on Solaris using the vendor compiler, I saw this: [...] config.status: creating testsuite/Makefile config.status: creating config.h config.status: executing default commands gmake[3]: Entering directory `/tmp/gcc-build/libiberty' if [ x-fPIC != x ] [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir if [ x-fPIC != x ]; then \ cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g -I. -I/home/src/gcc-4.7.0/libiberty/../include -fPIC /home/src/gcc-4.7.0/libiberty/regex.c -o pic/regex.o; \ else true; fi cc: Warning: illegal option -fPIC cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g -I. -I/home/src/gcc-4.7.0/libiberty/../include /home/src/gcc-4.7.0/libiberty/regex.c -o regex.o if [ x-fPIC != x ]; then \ cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g -I. -I/home/src/gcc-4.7.0/libiberty/../include -fPIC /home/src/gcc-4.7.0/libiberty/cplus-dem.c -o pic/cplus-dem.o; \ else true; fi cc: Warning: illegal option -fPIC [...] I traced the -fPIC flag to the GCC_PICFLAG macro in the libiberty configure script. There needs to be a check for whether $CC is GNU or not, because passing in a bogus flag won't necessarily raise an error (even with -errwarn).
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #15 from dave.anglin at bell dot net 2012-05-09 18:45:15 UTC --- On 5/9/2012 1:12 PM, redi at gcc dot gnu.org wrote: We might want to put something in config/os/gnu-linux/os_defines.h so that the macro is defined when using linuxthreads I'm thinking a test needs to be added to GLIBCXX_CHECK_GTHREADS in acinclude.m4. Dave
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #16 from Sriraman Tallam tmsriram at google dot com 2012-05-09 19:03:01 UTC --- Bug fixed, patch here: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00694.html Thanks for trying, -Sri. On Tue, May 8, 2012 at 2:18 AM, vincenzo.innocente at cern dot ch gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #14 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-05-08 09:18:01 UTC --- added your patch on top of c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl --with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib : (reconfigured) ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 -enable-gold=yes --enable-lto --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl --with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native' -enable-libitm -disable-multilib CC=gcc CXX=g++ --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.8.0 20120508 (experimental) [trunk revision 187276] (GCC) configured as above ad got ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' collect2: ld returned 1 exit status make[3]: *** [lto1] Error 1 make[3]: *** Waiting for unfinished jobs ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' collect2: ld returned 1 exit status make[3]: *** [cc1] Error 1 ../.././gcc/multiversion.c:613: error: undefined reference to 'cgraph_add_to_same_comdat_group' collect2: ld returned 1 exit status make[3]: *** [cc1plus] Error 1 rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod make[3]: Leaving directory `/home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/data/newsoft/gcc-trunk' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/data/newsoft/gcc-trunk' make: *** [all] Error 2 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
