[Bug rtl-optimization/53785] coalescing multiple static instances in function scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53785 --- Comment #1 from Andrew Pinski 2012-06-27 06:59:08 UTC --- The question comes, do we want to have a lock for each variable or one for the scope? One for each variable was easier to implement and might be more correct. What happens if getId has weird side effects depending on which thread calls it?
[Bug rtl-optimization/53785] New: coalescing multiple static instances in function scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53785
Bug #: 53785
Summary: coalescing multiple static instances in function scope
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
I come across this kind of pattern (repeated over and over in many functions)
static const EvtId DM=EvtPDL::getId("D-");
static const EvtId DP=EvtPDL::getId("D+");
static const EvtId D0=EvtPDL::getId("D0");
static const EvtId D0B=EvtPDL::getId("anti-D0");
static const EvtId KM=EvtPDL::getId("K-");
static const EvtId KP=EvtPDL::getId("K+");
static const EvtId K0=EvtPDL::getId("K0");
static const EvtId KB=EvtPDL::getId("anti-K0");
static const EvtId KL=EvtPDL::getId("K_L0");
static const EvtId KS=EvtPDL::getId("K_S0");
static const EvtId PIM=EvtPDL::getId("pi-");
static const EvtId PIP=EvtPDL::getId("pi+");
static const EvtId PI0=EvtPDL::getId("pi0");
that materialized in
nm -C statics.so | grep " b "
3908 b guard variable for a1::bar(int)::D0
38e8 b guard variable for a1::bar(int)::DM
38f8 b guard variable for a1::bar(int)::DP
3948 b guard variable for a1::bar(int)::K0
3958 b guard variable for a1::bar(int)::KB
3968 b guard variable for a1::bar(int)::KL
3928 b guard variable for a1::bar(int)::KM
3938 b guard variable for a1::bar(int)::KP
3978 b guard variable for a1::bar(int)::KS
3918 b guard variable for a1::bar(int)::D0B
39a8 b guard variable for a1::bar(int)::PI0
3988 b guard variable for a1::bar(int)::PIM
3998 b guard variable for a1::bar(int)::PIP
3910 b a1::bar(int)::D0
38f0 b a1::bar(int)::DM
3900 b a1::bar(int)::DP
3950 b a1::bar(int)::K0
3960 b a1::bar(int)::KB
3970 b a1::bar(int)::KL
3930 b a1::bar(int)::KM
3940 b a1::bar(int)::KP
3980 b a1::bar(int)::KS
3920 b a1::bar(int)::D0B
39b0 b a1::bar(int)::PI0
3990 b a1::bar(int)::PIM
39a0 b a1::bar(int)::PIP
which generates a huge "bss" and most probably also a serious performance
penalty due to all those gard variables
I worked around with this simple transformation
static struct {
const EvtId DM=EvtPDL::getId("D-");
const EvtId DP=EvtPDL::getId("D+");
const EvtId D0=EvtPDL::getId("D0");
const EvtId D0B=EvtPDL::getId("anti-D0");
const EvtId KM=EvtPDL::getId("K-");
const EvtId KP=EvtPDL::getId("K+");
const EvtId K0=EvtPDL::getId("K0");
const EvtId KB=EvtPDL::getId("anti-K0");
const EvtId KL=EvtPDL::getId("K_L0");
const EvtId KS=EvtPDL::getId("K_S0");
const EvtId PIM=EvtPDL::getId("pi-");
const EvtId PIP=EvtPDL::getId("pi+");
const EvtId PI0=EvtPDL::getId("pi0");
} const parts;
so I am wandering if the complier would be able to do something similar,
recognizing that all those static objects can, after all, be guarded by just
one variable (I think this will work no matter what side effects getId has)
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #23 from Keean Schupke 2012-06-27 06:48:28 UTC --- (In reply to comment #22) > (In reply to comment #21) > > Is there any chance this 'feature' of GCC could be kept as a g++ specific > > extension in 'gnu++11' mode, as I think the old behaviour is an improvement > > over that suggested in the standard, and GCC provides other extensions to > > standard behaviour where it is useful. > > I doubt it. The old behaviour was the source of several long-standing bug > reports. Now G++ implements the standard's required behaviour and agrees with > other leading compilers. GNU extensions usually allow new features by > supporting new syntax not by changing the meaning of valid code, it would not > be a pure extension. I have started a discussion on the C++ Standard discussion group about whether the code in the original example should work. So far the only responses have been to indicate that the code I posted is intended to work. Anyone wishing to discuss this further should post there: https://groups.google.com/a/isocpp.org/d/msg/std-discussion/OABibx-FK-o/srhSRlQduJAJ
[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 --- Comment #19 from Alexandre Oliva 2012-06-27 06:30:05 UTC --- Alas, it doesn't work on i686 or x86_64: the free_alloc_pool in vt_finalize has to be conditional on non-NULL, because we will skip vt_emit_notes (and thus the initializer) in some cases. I'm in awe that this didn't happen on ia64!
[Bug c/53784] Scalar vector binary operation - error with -std=c9x/c1x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53784 --- Comment #2 from Dag Lem 2012-06-27 06:12:37 UTC --- Yes, gcc -fexcess-precision=standard -mavx -S test.c triggers the bug.
[Bug debug/53740] [4.8 Regression] --enable-checking=yes,rtl bootstrap failure with ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53740 --- Comment #7 from Jakub Jelinek 2012-06-27 05:58:31 UTC --- (In reply to comment #6) > The bug was introduced in r188527, with the conditionalization of calling > insert_dead_debug_temp in the “else” clause, so that we would no longer insert > debug temps for sets that were not themselves dead, but that were used in > debug > stmts after their death. This caused a chain of debug temps to be incorrectly > introduced, which ended up triggering the problem. If you are going to fix this by making it unconditional again, I think both word_dce_process_block and dce_process_block should do it unconditionally.
[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 --- Comment #18 from Alexandre Oliva 2012-06-27 05:43:33 UTC --- I've just successfully bootstrapped a recent tree with (and without) the patch on ia64-linux-gnu, so I'm going to regtest it and post it (with proper credit).
[Bug c/53784] Scalar vector binary operation - error with -std=c9x/c1x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53784 --- Comment #1 from Andrew Pinski 2012-06-27 05:42:16 UTC --- This is most likely due to -fexcess-precision= handling.
[Bug debug/53740] [4.8 Regression] --enable-checking=yes,rtl bootstrap failure with ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53740 --- Comment #6 from Alexandre Oliva 2012-06-27 05:42:26 UTC --- The bug was introduced in r188527, with the conditionalization of calling insert_dead_debug_temp in the “else” clause, so that we would no longer insert debug temps for sets that were not themselves dead, but that were used in debug stmts after their death. This caused a chain of debug temps to be incorrectly introduced, which ended up triggering the problem. Now, there is indeed a bug in the way we deal with multiregs: we're happily using paradoxical SUBREGs to extend the value stored in a single REG to determine the value of the whole multi-reg expression. We only refrained from doing so if the SET was already a SUBREG, but we had to do that for REGs too. In the patch I'm testing now, I fix both problems. Will post soon.
[Bug c/53784] New: Scalar vector binary operation - error with -std=c9x/c1x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53784
Bug #: 53784
Summary: Scalar vector binary operation - error with
-std=c9x/c1x
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@nimrod.no
Test code:
--
typedef float v8sf __attribute__ ((vector_size (4*8)));
v8sf add_scalar(v8sf v, float s)
{
return v + s;
}
--
If any non-GNU language standard is chosen (e.g. gcc -std=c99 -mavx -S test.c),
the compilation fails with the following error:
error: conversion of scalar to vector involves truncation
As far as I can tell, there should not be any truncation involved here.
Adding -ffast-math makes gcc accept the code.
[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #17 from Alexandre Oliva 2012-06-27 01:59:22 UTC --- Rainer, I pretty sure Uros' revised patch in comment 10 should fix the problem. We shouldn't release th pool before we destroy the dataflow sets, because they will access and release backrefs that may be in the pool. Uros, you reported it ddn't bootstrap, bu you didn't provide any details. Are you sure it wasn't for some unrelated reason? I'll momentarily test a variant of that patch on ia64, but I don't see why it would fare any different.
[Bug c++/53783] New: [4.8 Regression] lambda in lambda in template function rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53783
Bug #: 53783
Summary: [4.8 Regression] lambda in lambda in template function
rejected
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lu...@math.hu-berlin.de
The following valid program is rejected (using latest version from trunk)
template void foo() { [] { [] {}; }; }
int main() { foo(); }
daniel@daniel-VirtualBox:~/projects/Code/gcctest$ /opt/gcc/trunk/bin/g++
-std=c++11 test.cpp
test.cpp: In instantiation of ‘foo() [with =
void]::’:
test.cpp:1:32: required from ‘struct foo() [with =
void]::’
test.cpp:1:31: required from ‘void foo() [with =
void]’
test.cpp:2:24: required from here
test.cpp:1:36: error: use of ‘foo() [with =
void]::’ before deduction of ‘auto’
template void foo() { [] { [] {}; }; }
^
test.cpp: In instantiation of ‘struct foo() [with =
void]’:
test.cpp:1:36: required from ‘foo() [with =
void]::’
test.cpp:1:32: required from ‘struct foo() [with =
void]::’
test.cpp:1:31: required from ‘void foo() [with =
void]’
test.cpp:2:24: required from here
test.cpp:1:37: error: use of ‘foo() [with =
void]’ before deduction of ‘auto’
template void foo() { [] { [] {}; }; }
^
test.cpp:1:37: error: invalid use of ‘auto’
test.cpp:1:37: error: inconsistent deduction for ‘auto’: ‘auto’ and then ‘void’
[Bug other/33190] tm.texi describes some non-existing hooks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33190 --- Comment #6 from Steven Bosscher 2012-06-26 22:21:17 UTC --- (In reply to comment #2) > Learned some more. (For reference, this is all from Fr 17 Aug 21:29:16 UTC > 2007 (revision 127595).) > > Not defined by any target, but used in the main sources: I have gone over these again. Some of the macros listed were actually used in libgcc or they are target hooks. A couple have also already been removed in the mean time. The updated list looks like this: IFCVT_EXTRA_FIELDS (doc/tm.texi.in config/frv/frv.c config/frv/frv.h) SYSROOT_HEADERS_SUFFIX_SPEC (cppdefault.c gcc.c doc/tm.texi.in) LARGEST_EXPONENT_IS_NORMAL (defaults.h doc/tm.texi.in config/arm/arm.h ../libgcc/fp-bit.c) SHORT_FRACT_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h config/mips/mips.h) FRACT_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h config/mips/mips.h) LONG_FRACT_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h config/mips/mips.h) LONG_LONG_FRACT_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h config/mips/mips.h) SHORT_ACCUM_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h config/mips/mips.h) ACCUM_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h config/mips/mips.h) LONG_ACCUM_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h config/mips/mips.h) LONG_LONG_ACCUM_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h config/mips/mips.h) LIBGCC2_HAS_DF_MODE (doc/tm.texi.in config/rl78/rl78.h config/rx/rx.h ../libgcc/fixed-bit.h ../libgcc/libgcc2.c ../libgcc/libgcc2.h) SF_SIZE (doc/tm.texi.in ../libgcc/libgcc2.c ../libgcc/libgcc2.h) DF_SIZE (doc/tm.texi.in ../libgcc/libgcc2.c ../libgcc/libgcc2.h) INTMAX_TYPE (defaults.h doc/tm.texi.in c-family/c-common.c fortran/trans- types.c fortran/iso-c-binding.def) UINTMAX_TYPE (defaults.h doc/tm.texi.in c-family/c-common.c) STACK_CHECK_PROTECT (explow.c defaults.h doc/tm.texi.in config/alpha/alpha.c config/i386/i386.c config/ia64/ia64.c config/rs6000/rs6000.c config/sparc/sparc.c config/ia64/hpux.h config/ia64/vms.h config/rs6000/freebsd64.h config/rs6000/linux64.h) STACK_CHECK_MAX_FRAME_SIZE (explow.c function.c reload1.c defaults.h doc/tm.texi.in) STACK_CHECK_FIXED_FRAME_SIZE (reload1.c defaults.h doc/tm.texi.in) STACK_CHECK_MAX_VAR_SIZE (calls.c function.c gimplify.c defaults.h doc/tm.texi.in ada/gcc-interface/decl.c) GEN_ERRNO_RTX (builtins.c doc/tm.texi.in) ASM_OUTPUT_POOL_EPILOGUE (varasm.c doc/tm.texi.in) ASM_OUTPUT_SIZE_DIRECTIVE (defaults.h doc/tm.texi.in config/elfos.h config/openbsd.h config/mips/mips.c config/pa/pa.c config/alpha/elf.h config/bfin/bfin.h config/c6x/c6x.h config/i386/sol2.h config/lm32/lm32.h config/mcore/mcore-elf.h config/rs6000/sysv4.h config/rx/rx.h config/sparc/sol2.h) DEBUG_SYMS_TEXT (dbxout.c xcoffout.h doc/tm.texi.in) DBX_TYPE_DECL_STABS_CODE (dbxout.c xcoffout.h doc/tm.texi.in) DBX_STATIC_CONST_VAR_CODE (dbxout.c xcoffout.h doc/tm.texi.in) DBX_REGPARM_STABS_CODE (dbxout.c xcoffout.h doc/tm.texi.in) DBX_REGPARM_STABS_LETTER (dbxout.c xcoffout.h doc/tm.texi.in) DBX_BLOCKS_FUNCTION_RELATIVE (dbxout.c doc/tm.texi.in config/dbxcoff.h config/dbxelf.h) DBX_OUTPUT_MAIN_SOURCE_FILENAME (dbxout.c xcoffout.h doc/tm.texi.in) NO_DBX_MAIN_SOURCE_DIRECTORY (dbxout.c xcoffout.h doc/tm.texi.in) NO_DBX_GCC_MARKER (dbxout.c xcoffout.h doc/tm.texi.in) DBX_OUTPUT_MAIN_SOURCE_FILE_END (dbxout.c xcoffout.h doc/tm.texi.in) CASE_USE_BIT_TESTS (stmt.c doc/tm.texi.in) VECTOR_STORE_FLAG_VALUE (simplify-rtx.c doc/rtl.texi doc/tm.texi.in) POWI_MAX_MULTS (tree-ssa-math-opts.c doc/tm.texi.in)
[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 Alexandre Oliva changed: What|Removed |Added AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | --- Comment #16 from Alexandre Oliva 2012-06-26 20:29:28 UTC --- I'm taking this over, at Jakub's request.
[Bug debug/53740] [4.8 Regression] --enable-checking=yes,rtl bootstrap failure with ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53740 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-26 AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from Alexandre Oliva 2012-06-26 20:27:00 UTC --- I'm taking this over, at Richard's request.
[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-06-26 20:25:16 UTC ---
The problem still exists in gcc 4.8.0 20120610 (experimental) compiled with
-Wall -pedantic -std=c++11. Here a variation of Johannes example based on a
similar Clang bug report from Doug Gregor:
//
template
void print(const T&) {}
template
void accept_all(T&&...){}
template
void print_all(const T&... t)
{
accept_all([&]()->int { print(t); return 0; }...); // Line 10
}
int main()
{
print_all(1, true, 'a');
}
//
"10|error: parameter packs not expanded with '...':|
10|note: 't'|
|In function 'void print_all(const T& ...)':|
10|error: expansion pattern '#'lambda_expr' not supported by
dump_expr#' contains no argument packs"
[Bug target/53682] [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53682 Alexandre Oliva changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #10 from Alexandre Oliva 2012-06-26 20:24:54 UTC --- Fixed in the 4.7 branch too.
[Bug target/53682] [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53682 --- Comment #9 from Alexandre Oliva 2012-06-26 20:22:05 UTC --- Author: aoliva Date: Tue Jun 26 20:21:58 2012 New Revision: 188997 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188997 Log: PR debug/53682 * cselib.c (promote_debug_loc): Don't crash on NULL argument. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cselib.c
[Bug c++/53782] New: Pointer to static function member expression rejected in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53782
Bug #: 53782
Summary: Pointer to static function member expression rejected
in class template
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.8.0 20120610 (experimental) compiled with -Wall (also tested with
-pedantic and -std=c++11) rejects the following code:
//-
template
struct func_ptr{};
template
struct S {
static void invariants() {}
typedef func_ptr<&invariants> enforce_evaluation; // Line 7
};
S s;
//-
"7|error: template argument 1 is invalid"
I'm reporting this, because there is only a very small set of valid forms
accepted by all compilers I have to support. The form used above is valid
according to the language rules and accepted by all other compilers I tested
(Comeau, VC 11 Beta, Clang 3.0) but not by gcc. A current workaround is to
write "&S::invariants" instead, but it seems a pity that the "obvious" syntax
doesn't work.
[Bug tree-optimization/53774] Reassociator generates non-canonical addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53774 --- Comment #4 from William J. Schmidt 2012-06-26 18:52:44 UTC --- Yeah, looking at the test case it's an uninitialized variable. Seems like a hole in the ranking system that it gets a rank of zero. I think a default value that isn't a parm should be treated like a parm -- add 1 to the value of the last parm's rank and give it that rank.
[Bug tree-optimization/53774] Reassociator generates non-canonical addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53774 --- Comment #3 from William J. Schmidt 2012-06-26 18:42:41 UTC --- I wonder why fp_6(D) gets a rank of zero. Is it an uninitialized variable or a parameter? Parms are supposed to get small positive numbers for ranks. Maybe the "right" fix is to force fp_6(D) to get a nonzero rank?
[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769 --- Comment #5 from joseph at codesourcery dot com 2012-06-26 17:13:52 UTC --- On Tue, 26 Jun 2012, vincent-gcc at vinc17 dot net wrote: > OK, this makes clear that for portability, programs should do configure tests > instead of relying on the values of standard macros. I think this should be Exactly. Cf. the issues GCC had with system headers on FreeBSD checking __cplusplus to enable C++11 features (where GCC generally has more C++11 support than Clang, but not the particular feature used by those headers; bug 51705). Eventually there will be features implemented in all compilers people are likely to care about and those features can be used without worrying about compilers from during the transitional period. But during the transitional period while major features of a new standard such as C++11 or C11 are being implemented by compilers, you need to test for the features you want to use. And it's entirely plausible that an implementation will have fully functional _Thread_local without C11 threads.h (thread-local storage for pthreads or another form of threads), so test for what you actually want to use.
[Bug c++/53781] ICE when compiling a deeply nested template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53781 Oleg Grunin changed: What|Removed |Added CC||oleg00 at gmail dot com Version|unknown |4.7.0 --- Comment #3 from Oleg Grunin 2012-06-26 16:55:15 UTC --- To recreate the precompiled source: cat xaa xab > gnu.bug.cpp.bz2 bunzip gnu.bug.cpp.bz2
[Bug c++/53781] ICE when compiling a deeply nested template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53781 --- Comment #2 from Oleg Grunin 2012-06-26 16:52:17 UTC --- Created attachment 27708 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27708 bzipped precompiled source part 2
[Bug c++/53781] ICE when compiling a deeply nested template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53781 --- Comment #1 from Oleg Grunin 2012-06-26 16:51:15 UTC --- Created attachment 27707 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27707 bzipped precompiled source part 1
[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 William J. Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #15 from William J. Schmidt 2012-06-26 16:25:08 UTC --- *** Bug 53779 has been marked as a duplicate of this bug. ***
[Bug bootstrap/53779] Bootstrap hangs waiting for a lock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779 William J. Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from William J. Schmidt 2012-06-26 16:25:08 UTC --- Thanks, H.J. Definitely the same problem. *** This bug has been marked as a duplicate of bug 53706 ***
[Bug fortran/47692] Numeric inaccuracy reported in testing lapack-3.3.0 BLAS module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47692 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #18 from kargl at gcc dot gnu.org 2012-06-26 16:16:54 UTC --- (In reply to comment #17) > Thank you for reminding me to submit a follow-up. Yes, blas and lapack test > cleanly with gcc and gfortran version 4.6.3. > > I have since encountered a difficulty with the Octave program involving blas. > A > section of code in Octave that I think compiles the documentation fails to > recognize the values returned by calls to dlamch (?) as valid ieee754 values. > I've tried a couple of obtimization settings unsuccessfully. If I can't set > flags for dlamch and slamch to produce standard ieee754 values, this too might > be worth a bug report. suggested flags? Try -O -ffloat-store.
[Bug c++/53781] New: ICE when compiling a deeply nested template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53781 Bug #: 53781 Summary: ICE when compiling a deeply nested template Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ole...@gmail.com gcc 4.7.0 crashed when the template nesting level approaches ~35. The code compiles fine on gcc 4.5.0 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/jpm/ro/3rd/gcc/4.7.0-g++/x86_64-linux-2.6-libc6/libexec/gcc/x86_64-aim-linux-gnu/4.7.0/lto-wrapper Target: x86_64-aim-linux-gnu Configured with: ../../src/configure --prefix=/jpm/ro/3rd/gcc/4.7.0-g++/common --exec-prefix=/jpm/ro/3rd/gcc/4.7.0-g++/x86_64-linux-2.6-libc6 --host=x86_64-aim-linux-gnu --build=x86_64-aim-linux-gnu --target=x86_64-aim-linux-gnu --prefix=/jpm/ro/3rd/gcc/4.7.0-g++/x86_64-linux-2.6-libc6 --with-local-prefix=/jpm/ro/3rd/gcc/4.7.0-g++/x86_64-linux-2.6-libc6 --libdir=/jpm/ro/3rd/gcc-runtime/4.7.0-g++/x86_64-linux-2.6-libc6/lib --oldincludedir=/jpm/ro/3rd/glibc/2.13/x86_64-linux-2.6-libc6/include --with-gxx-include-dir=/jpm/ro/3rd/gcc/4.7.0-g++/x86_64-linux-2.6-libc6/include --disable-bootstrap --disable-multilib --disable-nls --enable-shared --enable-languages=c,c++ --enable-__cxa_atexit CFLAGS='-g -O2 -D__USE_XOPEN2K8' CXXFLAGS='-g -O2 -D__USE_XOPEN2K8' 'XGCC_FLAGS_FOR_TARGET=-g -O2 -D__USE_XOPEN2K8' Thread model: posix gcc version 4.7.0 (GCC) Preprocessed source is attached. Compile with: c++ -O3 -std=c++0x -DNDEBUG gcc.bug.cpp
[Bug bootstrap/53779] Bootstrap hangs waiting for a lock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779 --- Comment #4 from H.J. Lu 2012-06-26 15:58:40 UTC --- (In reply to comment #3) > I wonder if the recent changes to var-tracking.c contain the possibility for a > double-free. > PR 53706.
[Bug lto/53780] New: [l4.7.1 lto] linker fails with lto and "standard" object file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53780
Bug #: 53780
Summary: [l4.7.1 lto] linker fails with lto and "standard"
object file
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
here mostly for the record as works with 4.8.0 and it has an easy workaround
it maybe related to PR53337
either on vanilla fedora 17
or with
gcc version 4.7.2 20120615 (prerelease) [gcc-4_7-branch revision 188650] (GCC)
GNU gold (GNU Binutils 2.22.52.20120515) 1.11
linker fails in the following example
c++ -fPIC -std=c++11 -fvisibility-inlines-hidden -O2 -flto -c boostLto.cc
c++ -fPIC -std=c++11 -fvisibility-inlines-hidden -Os -c boostLto2.cc
echo link ok
c++ -flto -O2 -pthread boostLto2.o boostLto.o -shared -fPIC -o bha.so
-fvisibility-inlines-hidden -std=c++11
echo link fails
c++ -flto -O2 -pthread boostLto.o boostLto2.o -shared -fPIC -o bha.so
-fvisibility-inlines-hidden -std=c++11
fedora 17
link ok
link fails
`_ZTIN5boost6detail15sp_counted_baseE' referenced in section
`.data.rel.ro._ZTVN5boost6detail15sp_counted_baseE[_ZTVN5boost6detail15sp_counted_baseE]'
of boostLto2.o: defined in discarded section
`.gnu.linkonce.t._ZTIN5boost6detail15sp_counted_baseE' of boostLto.o (symbol
from plugin)
`_ZThn16_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorD1Ev'
referenced in section
`.data.rel.ro._ZTVN5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorE[_ZTVN5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorE]'
of boostLto2.o: defined in discarded section
`.gnu.linkonce.t._ZN5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorD5Ev'
of boostLto.o (symbol from plugin)
`_ZThn16_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorD0Ev'
referenced in section
`.data.rel.ro._ZTVN5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorE[_ZTVN5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorE]'
of boostLto2.o: defined in discarded section
…..
`_ZThn56_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorD0Ev'
referenced in section `.data.rel.ro' of /tmp/ccnOkzqM.ltrans1.ltrans.o: defined
in discarded section
`.gnu.linkonce.t._ZN5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorD0Ev'
of boostLto.o (symbol from plugin)
/bin/ld: bha.so: hidden symbol `.LTHUNK2.3978' isn't defined
/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
=
with
gcc version 4.7.2 20120615 (prerelease) [gcc-4_7-branch revision 188650] (GCC)
GNU gold (GNU Binutils 2.22.52.20120515) 1.11
link ok
link fails
boostLto2.o:boostLto2.cc:function vtable for
boost::exception_detail::clone_impl
>: warning: relocation refers to discarded section
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: error: hidden symbol
'_ZThn16_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_9gregorian16bad_day_of_monthD1Ev'
is not defined locally
…..
/tmp/innocent/ccZ6RxXH.ltrans1.ltrans.o:ccZ6RxXH.ltrans1.o:function vtable for
boost::exception_detail::clone_impl
> [clone .local.282]: warning: relocation refers to discarded section
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: error: hidden symbol
'_ZThn56_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_9gregorian15bad_day_of_yearD0Ev'
is not defined locally
collect2: error: ld returned 1 exit status
==
code
cat boostLto.cc
#include "boost/thread/mutex.hpp"
namespace edm0 {
boost::mutex* getGlobalMutex();
}
boost::mutex* edm0::getGlobalMutex() {
static boost::mutex m_;
return &m_;
}
[innocent@pcphsftkepler ctest]$ cat boostLto2.cc
#include "boost/thread/mutex.hpp"
namespace edm2 {
boost::mutex* getGlobalMutex();
}
boost::mutex* edm2::getGlobalMutex() {
static boost::mutex m_;
return &m_;
}
#include "boost/shared_ptr.hpp"
#include "boost/date_time.hpp"
#include "boost/date_time/gregorian/gregorian_types.hpp"
#include "boost/date_time/posix_time/posix_time_types.hpp"
#include "boost/date_time/c_local_time_adjustor.hpp"
typedef boost::posix_time::ptime TimePoint_t;
typedef boost::posix_time::time_duration Duration_t;
#include
#include
#include
#include
struct A {
A(){}
virtual ~A(){}
A(int j) : i(j){}
int i;
};
struct B {
A & a() {return *pa;}
boost::shared_ptr pa;
int j;
};
boost::shared_ptr make2(int i) {
return boost::shared_ptr(new A(i));
}
int get2(boost::shared_ptr a) {
return (*a).i;
}
int get2(B b
[Bug bootstrap/53779] Bootstrap hangs waiting for a lock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779 William J. Schmidt changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #3 from William J. Schmidt 2012-06-26 15:07:33 UTC --- I wonder if the recent changes to var-tracking.c contain the possibility for a double-free. I think it's not directly due to my patch for the following reason: This has happened on two different working patches recently. One makes memory allocation changes in the vectorizer; the other made memory allocation changes in IVOPTS. In both cases, the stack was nearly the same -- blowing up when freeing some memory in the var-tracking phase. In one case it was a call to free_alloc_pool, in the other a call to delete_htab. Copying Alexandre for his opinion. What do you think?
[Bug fortran/47692] Numeric inaccuracy reported in testing lapack-3.3.0 BLAS module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47692 --- Comment #17 from John T 2012-06-26 15:07:48 UTC --- Thank you for reminding me to submit a follow-up. Yes, blas and lapack test cleanly with gcc and gfortran version 4.6.3. I have since encountered a difficulty with the Octave program involving blas. A section of code in Octave that I think compiles the documentation fails to recognize the values returned by calls to dlamch (?) as valid ieee754 values. I've tried a couple of obtimization settings unsuccessfully. If I can't set flags for dlamch and slamch to produce standard ieee754 values, this too might be worth a bug report. suggested flags?
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #64 from Martin Jambor 2012-06-26 15:01:28 UTC --- (In reply to comment #62) > (In reply to comment #61) > > (In reply to comment #57) > > > > Anyway, on the machine where are debugged this, compilation at -O3 > > took over 16 seconds which dropped to about 13.5 seconds when I also > > What? Must be a future machine. On everything I have access to the reduced > testcase (6309 lines) takes about 800 to 1000 seconds. Do you build without > any checking? Minutes! Of course I meant minutes, the drop is thus from ~1000 seconds to ~810 seconds. I forgot I was using bash time instead of /usr/bin/time -f%U which I was regularly using only a few days ago. > > In any case, the proposed patch does reduce the time to basically nothing for > the alias tree walker, so: thanks :) I've experimentally disabled the walker in is_parm_modified_before_stmt and am now waiting for results but I guess it won't have any measurable impact.
[Bug target/35294] iwmmxt intrinsics, internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294 --- Comment #16 from Nick Clifton 2012-06-26 14:59:54 UTC --- Author: nickc Date: Tue Jun 26 14:59:45 2012 New Revision: 188988 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188988 Log: * doc/extend.texi (__builtin_arm_tinsrb): Add missing second parameter. (__builtin_arm_tinsrh): Likewise. (__builtin_arm_tinsrw): Likewise. (__builtin_arm_wsadb): Add missing v2si parameter. (__builtin_arm_wsadh): Likewise. (__builtin_arm_getwcx): Delete. (__builtin_arm_setwcx): Delete. (__builtin_arm_getwcgr0): Add. (__builtin_arm_getwcgr1): Add. (__builtin_arm_getwcgr2): Add. (__builtin_arm_getwcgr3): Add. (__builtin_arm_setwcgr0): Add. (__builtin_arm_setwcgr1): Add. (__builtin_arm_setwcgr2): Add. (__builtin_arm_setwcgr3): Add. PR target/35294 * gcc.target/arm/mmx-2.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/mmx-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #63 from Richard Guenther 2012-06-26 14:58:31 UTC --- (In reply to comment #61) > (In reply to comment #57) > > > > I will, on Monday. > > And by Monday I obviously meant yesterday ;-) > > Anyway, on the machine where are debugged this, compilation at -O3 > took over 16 seconds which dropped to about 13.5 seconds when I also > added -fno-devirtualize (-ftime-report showed that alias stmt walking > dropped from 82% to 75%). This is mainly due to calls to > detect_type_change from compute_known_type_jump_func, there are 36454 > of them and all are of course completely pointless because we do not > devirtualize in Fortran. > > Looking into the code, it is apparent that I even attempted to avoid > such situations but somehow was not paying enough attention. The > rather obvious patch below fixes that. With it, the compile time at > -O3 drops to 13.5 without any additional options (~50 calls to > detect_type_change_ssa and detect_type change from other places remain > but those are not a big problem here, they are not so easy to get rid > of and I hope to eventually remove the type detection machinery from > IPA altogether so I'll keep those for later). > > I'll bootstrap and test the patch and post it to the mailing list > soon. > > Index: gcc/ipa-prop.c > === > --- gcc/ipa-prop.c (revision 188931) > +++ gcc/ipa-prop.c (working copy) > @@ -912,8 +912,8 @@ compute_known_type_jump_func (tree op, s >|| is_global_var (base)) > return; > > - if (detect_type_change (op, base, call, jfunc, offset) > - || !TYPE_BINFO (TREE_TYPE (base))) > + if (!TYPE_BINFO (TREE_TYPE (base)) > + || detect_type_change (op, base, call, jfunc, offset)) > return; That change qualifies for a backport to all branches it applies to ...
[Bug bootstrap/53779] Bootstrap hangs waiting for a lock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779 --- Comment #1 from Andreas Schwab 2012-06-26 14:55:34 UTC --- Try running it under valgrind. Your patch is apparently causing a memory corruption, and the SIGABRT handler tries to call back into malloc/free, which cannot work. Most likely target_cost_data is freed twice. --- Comment #2 from David Edelsohn 2012-06-26 14:56:32 UTC --- Alan and my patch was to libjava and did not change anything in the common support for atomics. Unless the build is using libjava at that point, there is no way for the libjava locks.h patch to affect this. This may be due to some indirect change in the process memory layout after Steven's change. But the real problem appears to libc free() crashing in a call from var-tracking. libc raises a signal, GCC catching it and tries to print a pretty error and cleanup before exiting. The cleanup calls free() again and hangs. Is there some memory problem in var-tracking or an underlying data structure that was exposed by Steven's change? Some weird page crossing or some dangling pointer that accidentally pointed to valid memory before the process layout changed?
[Bug bootstrap/53779] Bootstrap hangs waiting for a lock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779 --- Comment #1 from Andreas Schwab 2012-06-26 14:55:34 UTC --- Try running it under valgrind. Your patch is apparently causing a memory corruption, and the SIGABRT handler tries to call back into malloc/free, which cannot work. Most likely target_cost_data is freed twice.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #62 from Michael Matz 2012-06-26 14:44:58 UTC --- (In reply to comment #61) > (In reply to comment #57) > > Anyway, on the machine where are debugged this, compilation at -O3 > took over 16 seconds which dropped to about 13.5 seconds when I also What? Must be a future machine. On everything I have access to the reduced testcase (6309 lines) takes about 800 to 1000 seconds. Do you build without any checking? In any case, the proposed patch does reduce the time to basically nothing for the alias tree walker, so: thanks :)
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #61 from Martin Jambor 2012-06-26 14:26:34 UTC --- (In reply to comment #57) > > I will, on Monday. And by Monday I obviously meant yesterday ;-) Anyway, on the machine where are debugged this, compilation at -O3 took over 16 seconds which dropped to about 13.5 seconds when I also added -fno-devirtualize (-ftime-report showed that alias stmt walking dropped from 82% to 75%). This is mainly due to calls to detect_type_change from compute_known_type_jump_func, there are 36454 of them and all are of course completely pointless because we do not devirtualize in Fortran. Looking into the code, it is apparent that I even attempted to avoid such situations but somehow was not paying enough attention. The rather obvious patch below fixes that. With it, the compile time at -O3 drops to 13.5 without any additional options (~50 calls to detect_type_change_ssa and detect_type change from other places remain but those are not a big problem here, they are not so easy to get rid of and I hope to eventually remove the type detection machinery from IPA altogether so I'll keep those for later). I'll bootstrap and test the patch and post it to the mailing list soon. Index: gcc/ipa-prop.c === --- gcc/ipa-prop.c (revision 188931) +++ gcc/ipa-prop.c (working copy) @@ -912,8 +912,8 @@ compute_known_type_jump_func (tree op, s || is_global_var (base)) return; - if (detect_type_change (op, base, call, jfunc, offset) - || !TYPE_BINFO (TREE_TYPE (base))) + if (!TYPE_BINFO (TREE_TYPE (base)) + || detect_type_change (op, base, call, jfunc, offset)) return;
[Bug tree-optimization/53774] Reassociator generates non-canonical addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53774
Richard Guenther changed:
What|Removed |Added
Keywords||missed-optimization
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Richard Guenther 2012-06-26
14:24:13 UTC ---
I am testing instead
@@ -2299,8 +2299,16 @@ rewrite_expr_tree (gimple stmt, unsigned
print_gimple_stmt (dump_file, stmt, 0, 0);
}
- gimple_assign_set_rhs1 (stmt, oe1->op);
- gimple_assign_set_rhs2 (stmt, oe2->op);
+ if (tree_swap_operands_p (oe1->op, oe2->op, true))
+ {
+ gimple_assign_set_rhs1 (stmt, oe2->op);
+ gimple_assign_set_rhs2 (stmt, oe1->op);
+ }
+ else
+ {
+ gimple_assign_set_rhs1 (stmt, oe1->op);
+ gimple_assign_set_rhs2 (stmt, oe2->op);
+ }
update_stmt (stmt);
if (rhs1 != oe1->op && rhs1 != oe2->op)
remove_visited_stmt_chain (rhs1);
which fixes it. OTOH there are many other places reassoc adjusts
stmt operands (but it eventually relies on operand order). Adding
a canonicalize_operand_order_and_update_stmt () wherever we
call update_stmt afer adjusting operands might be better ... or
simply calling fold_stmt on all stmts we touch which does the re-ordering, too.
Well, I'm not really sure where we should enforce canonical ordering ...
[Bug c++/53752] [4.8 Regression] ice in write_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53752 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Richard Guenther 2012-06-26 14:03:27 UTC --- Fixed.
[Bug c++/53752] [4.8 Regression] ice in write_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53752 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Richard Guenther 2012-06-26 14:03:06 UTC --- Author: rguenth Date: Tue Jun 26 14:03:02 2012 New Revision: 188987 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188987 Log: 2012-06-26 Richard Guenther PR c++/53752 * mangle.c (write_array_type): Truncate the number-of-elements result. * g++.dg/torture/pr53752.C: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr53752.C Modified: branches/gcc-4_7-branch/gcc/cp/mangle.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog --- Comment #9 from Richard Guenther 2012-06-26 14:03:27 UTC --- Fixed.
[Bug c++/53752] [4.8 Regression] ice in write_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53752 --- Comment #8 from Richard Guenther 2012-06-26 14:03:06 UTC --- Author: rguenth Date: Tue Jun 26 14:03:02 2012 New Revision: 188987 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188987 Log: 2012-06-26 Richard Guenther PR c++/53752 * mangle.c (write_array_type): Truncate the number-of-elements result. * g++.dg/torture/pr53752.C: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr53752.C Modified: branches/gcc-4_7-branch/gcc/cp/mangle.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/53779] New: Bootstrap hangs waiting for a lock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779 Bug #: 53779 Summary: Bootstrap hangs waiting for a lock Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: wschm...@gcc.gnu.org CC: amo...@gmail.com, berg...@vnet.ibm.com, d...@gcc.gnu.org, stevenb@gmail.com Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Created attachment 27706 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27706 Patch that exhibits the problem I've run into a couple of situations recently where bootstrap gets hung up during stage2 on a locking problem in the runtime memory support. This doesn't occur with the current code in the trunk, but has occurred for me on two unrelated working patches. For the current patch I'm working on, I bisected the problem to r188838, which makes little sense. That revision is: 2012-06-20 Steven Bosscher * system.h: Poison ASM_OUTPUT_IDENT and IDENT_ASM_OP. This doesn't seem likely to be directly related, but it is consistent that all revisions prior to that bootstrap with this patch and all revisions afterwards don't. I wonder whether revision 188829 could be involved: 2012-06-20 David Edelsohn Alan Modra * sysdep/powerpc/locks.h (compare_and_swap): Use GCC atomic intrinsics. (release_set): Same. (compare_and_swap_release): Same. (read_barrier): Same. (write_barrier): Same. and 188830 which contains a one-line fix for the above. It seems possible that there is some sort of issue there that only appears when the stars align just so. In both cases where I've seen this, the problem comes while compiling tree-vect-stmts.c for stage 2. In one working patch, I made changes to this part, while in the other I did not. When I attach to the hung process, this is the stack trace I see: #0 0x042ff298 in .__lll_lock_wait_private () from /lib64/power7/libc.so.6 #1 0x04285e30 in .__libc_free () from /lib64/power7/libc.so.6 #2 0x11095278 in operator delete (ptr=) at ../../../../libstdc++-v3/libsupc++/del_op.cc:49 #3 0x1105fee0 in deallocate (__p=, this=) at /usr/src/packages/BUILD/gcc-4.3.4-20091019/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/ext/new_allocator.h:98 #4 std::string::_Rep::_M_destroy (this=, __a=) at /usr/src/packages/BUILD/gcc-4.3.4-20091019/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/bits/basic_string.tcc:424 #5 0x110623ac in _M_dispose (__a=, this=) at /usr/src/packages/BUILD/gcc-4.3.4-20091019/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/bits/basic_string.h:236 #6 std::basic_string, std::allocator >::~basic_string (this=, __in_chrg=) at /usr/src/packages/BUILD/gcc-4.3.4-20091019/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/bits/basic_string.h:494 #7 0x0423baac in .__run_exit_handlers () from /lib64/power7/libc.so.6 #8 0x0423bb28 in .exit () from /lib64/power7/libc.so.6 #9 0x10dc9c88 in ._ZL30diagnostic_action_after_outputP18diagnostic_cont extP15diagnostic_info.isra.2 () #10 0x10dc9e8c in ._Z28diagnostic_report_diagnosticP18diagnostic_contextP15diagnostic_info () #11 0x10dcaa20 in ._Z14internal_errorPKcz () #12 0x10817fbc in ._ZL12crash_signali () #13 #14 0x04238100 in .raise () from /lib64/power7/libc.so.6 #15 0x04239dc0 in .abort () from /lib64/power7/libc.so.6 #16 0x04278924 in .__libc_message () from /lib64/power7/libc.so.6 #17 0x04280428 in .malloc_printerr () from /lib64/power7/libc.so.6 #18 0x042808c8 in .malloc_consolidate () from /lib64/power7/libc.so.6 #19 0x04281fc8 in ._int_free () from /lib64/power7/libc.so.6 #20 0x04285d30 in .__libc_free () from /lib64/power7/libc.so.6 #21 0x10410b2c in ._Z16empty_alloc_poolP14alloc_pool_def () #22 0x10410bb8 in ._Z15free_alloc_poolP14alloc_pool_def () #23 0x10a8a174 in ._ZL11vt_finalizev () #24 0x10aa0290 in ._Z22variable_tracking_mainv () #25 0x107454f8 in ._Z16execute_one_passP8opt_pass () #26 0x107459d4 in ._Z17execute_pass_listP8opt_pass () #27 0x107459ec in ._Z17execute_pass_listP8opt_pass () #28 0x107459ec in ._Z17execute_pass_listP8opt_pass () #29 0x1049ced8 in ._ZL15expand_functionP11cgraph_node () #30 0x1049f664 in ._Z7compilev () It appears to be attempting to handle an error of some sort (perhaps a double free?) when it gets hung. Note there are two calls to __libc_free on the stack which I suppose could lead
[Bug c++/53752] [4.8 Regression] ice in write_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53752 --- Comment #7 from Richard Guenther 2012-06-26 13:55:39 UTC --- Author: rguenth Date: Tue Jun 26 13:55:34 2012 New Revision: 188986 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188986 Log: 2012-06-26 Richard Guenther PR c++/53752 * mangle.c (write_array_type): Truncate the number-of-elements result. * g++.dg/torture/pr53752.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr53752.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/53771] inconsistent padding long double: mixture of 96 and 128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53771 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus 2012-06-26 12:37:41 UTC --- (In reply to comment #2) > > If you want to use REAL*16, upgrade the compiler and that has support for > > REAL*16. Namely: GCC 4.6 supports REAL*16, including all math intrinsics. > Can the compiler be installed privately by a user without admin > privileges on the system? The staff here would not be willing to > upgrade in the near future. Yes, that possibly. You can simply install it into some directory and directly call the installed compiler binary (though it is more convenient to put the "bin" directory into the path). Only for calling the compiled program, you should make sure that the libraries are found (on Linux/Unix: set the LD_LIBRARY_PATH) - or you link statically or you set an "-Wl,-rpath". For a quick guide to compiling GCC oneself and to some *unofficial* binaries, see http://gcc.gnu.org/wiki/GFortranBinaries My guess is that you are on a Red Hat Enterprise Linux 5.x system. RHEL 5 also contains a technical preview of a newer GCC (which can be installed in parallel), unfortunately, it only has GCC 4.4 and not 4.6 (or newer). Otherwise, that would have been alternative.
[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-06-26 12:29:30 UTC --- (In reply to comment #0) > I have a function in my Fortran code base that looks like this: [...] Can you create a full example? It is usually not easy to debug such issues without having a handle to a full example. Additionally, the code shown does typically not contain the full information. For instance, the issue might be due to inlining - but then it depends also on how and where it is inlined. > If this issue is already known and something along that fixed (in 4.7, > perhaps?), that would be a nice surprise. Well, the easiest is that you try it yourself as you have the full source code. Unofficial builds of 4.7 and 4.8 are available at http://gcc.gnu.org/wiki/GFortranBinaries Having said that, I am not aware of any recent fix which could have directly fixed that, nor do I know of any issue related to -foptimize-sibling-calls which still affects the fairly recent 4.6.3.
[Bug other/33190] tm.texi describes some non-existing hooks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33190 --- Comment #5 from Steven Bosscher 2012-06-26 11:27:47 UTC --- Author: steven Date: Tue Jun 26 11:27:41 2012 New Revision: 188984 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188984 Log: PR other/33190 * doc/tm.texi.in: Document LOGICAL_OP_NON_SHORT_CIRCUIT. * doc/tm.texi: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in
[Bug other/33190] tm.texi describes some non-existing hooks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33190 --- Comment #4 from Steven Bosscher 2012-06-26 10:47:05 UTC --- Author: steven Date: Tue Jun 26 10:47:01 2012 New Revision: 188983 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188983 Log: PR other/33190 * config/mips/mips.h: Do not define ALL_COP_ADDITIONAL_REGISTER_NAMES. * config/frv/frv.h: Do not define REVERSE_CONDEXEC_PREDICATES_P. * doc/tm.texi.in: Remove documentation for unused target macros ALL_COP_ADDITIONAL_REGISTER_NAMES, DBX_OUTPUT_LBRAC, DBX_OUTPUT_NFUN, DBX_OUTPUT_RBRAC, RANGE_TEST_NON_SHORT_CIRCUIT, REAL_VALUE_TRUNCATE, REVERSE_CONDEXEC_PREDICATES_P, TARGET_ALIGN_ANON_BITFIELDS, and TARGET_NARROW_VOLATILE_BITFIELDS. Document that MD_HANDLE_UNWABI is a macro in libgcc. * doc/tm.texi: Regenerate. * system.h: Poison target macros ALL_COP_ADDITIONAL_REGISTER_NAMES, DBX_OUTPUT_LBRAC, DBX_OUTPUT_NFUN, DBX_OUTPUT_RBRAC, RANGE_TEST_NON_SHORT_CIRCUIT, REAL_VALUE_TRUNCATE, REVERSE_CONDEXEC_PREDICATES_P, TARGET_ALIGN_ANON_BITFIELDS, and TARGET_NARROW_VOLATILE_BITFIELDS Modified: trunk/gcc/ChangeLog trunk/gcc/config/frv/frv.h trunk/gcc/config/mips/mips.h trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/system.h
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 --- Comment #9 from Jan Hubicka 2012-06-26 10:15:22 UTC --- Author: hubicka Date: Tue Jun 26 10:15:18 2012 New Revision: 188982 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188982 Log: PR lto/53572 * cgraph.h (varpool_can_remove_if_no_refs): Fix handling of used symbols. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h
[Bug fortran/53778] New: bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 Bug #: 53778 Summary: bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thomas.or...@awi.de Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu I have a function in my Fortran code base that looks like this: function dat_init_wind(handle, x, perturb) result(wind) type(datafield_t), intent(in) :: handle real(kind=8), dimension(:), intent(in) :: x logical, intent(in), optional :: perturb real(kind=8), dimension(handle%world%dims) :: wind logical :: pert pert = .true. if(present(perturb)) pert = perturb; select case(handle%initial_state) case(dat_init_geosiso) wind = geosiso_wind(handle, handle%bottomwind, x) case(dat_init_baroiso) wind = baroiso_wind(handle, handle%bottomwind, x) case(dat_init_baroclinpoly) wind = baroclinpoly_wind(handle, handle%baroclinpoly, x) case default wind = handle%base_speeds * bottomwind_profile(handle%bottomwind, world_map_y(handle%world, x)) end select_ if(pert .and. handle%perturb_wind /= 0) call pert_perturb(handle%pert, wind(handle%perturb_wind), x, handle%world%scale%space /& & handle%world%scale%time) end function This worked fine until a recent change, where I changed innerworkings of pert_perturb(). Suddenly the result (wind) was a set of NaN instead of 0 (in the considered configuration). Note that pert is false, as is (handle%perturb_wind /= 0), so the changes to pert_perturb() should have no influence on the result. Also, I noticed that adding a printout to the function fixes things, even if it is not actually called: select case(handle%initial_state) case(-100) write(0,0) 'This is a stub that never is executed but prevent compiler BUG 25 from triggering. Apparently.' case(dat_init_geosiso) Also, dropping the call to bottomwind_profile() from the 'default' case, which is what is actually executed, fixes the issue, but makes the code rather no-op for me. While the recent changes in my code also touch that function, it itself still computes correclty (as does pert_perturb()). That somehow fits with me narrowing down the issue to the minimal optimization flags needed (down from simple -g -O2): -O -g -foptimize-sibling-calls (The -g can be dropped, I strongly assume.) So it is something with optimizing function calls / stack mess-around. Note that I was unable to further reduce what is behind -O, I can activate all flags that make up -O here individually and the issue does not come into play. But also, setting -O and disabling all flags also does not trigger (it's a combination I guess). So it is plus sibling call optimization. Now, does this description ring a bell? It would be so swell if this situation was clear enough to diagnose the error in gfortran's optimization. If not, I will have to try to extract something self-contained out of my codebase again ... which might need considerable time. If this issue is already known and something along that fixed (in 4.7, perhaps?), that would be a nice surprise. I apologize if this turns out to be a bug in my code after all, but since I work with -fbounds-check -ffpe-trap=invalid,zero,overflow usually, I don't see much possibility to produce such breakage in Fortran. If this were a C program, I'd look harder for me messing up someplace;-)
[Bug other/33190] tm.texi describes some non-existing hooks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33190 Steven Bosscher changed: What|Removed |Added Status|NEW |ASSIGNED CC||steven at gcc dot gnu.org Component|middle-end |other
[Bug lto/53777] [lto] lto does not propagate optimization flags from command lines given at "compilation time"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-06-26 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-06-26 09:10:25 UTC --- ;) There are a vast number of things the developer might expect when flags used at compile time differ from flags used at link-optimization time. At the moment the semantics are (roughly) that you can think of the link-optimization time flags to be appended to the flags used at compile-time. Thus -O2 overrides -Os here. The implementation does not explicitely retain (all) of the compile-time flags - they might differ between different CUs after all - but only a very selected subset - and expects that meaningful link-optimization time options are present. You seem to want that code compiled with -Os would be implicitely wrapped in a optimize/target pragma with the options specified at compile-time. Note that this would inhibit inlining -Os code into -O2 code or vice-versa. Note also that in your example the -O2 given at link-time would be ignored? Note also that the optimize attribute/pragma has serious implementation issues and thus this kind of general use would not likely be a good idea. Suggestions (with formal specification ;)) of how to produce from Options(CU1), Options(CU2) ..., Options(Link-Time) a set of options effective at link-time is welcome. The current logic is implemented inside lto-wrapper.c (the LTO driver) and lto-opts.c (which pre-filters which options from compile-time are presented to the LTO driver).
[Bug regression/53729] [4.8 regression] PR53636 fix caused bb-slp-16.c to FAIL on sparc64 and powerpc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53729 Ulrich Weigand changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Ulrich Weigand 2012-06-26 09:09:28 UTC --- Fixed.
[Bug regression/53729] [4.8 regression] PR53636 fix caused bb-slp-16.c to FAIL on sparc64 and powerpc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53729 --- Comment #2 from Ulrich Weigand 2012-06-26 09:05:55 UTC --- Author: uweigand Date: Tue Jun 26 09:05:48 2012 New Revision: 188979 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188979 Log: PR tree-optimization/53729 PR tree-optimization/53636 * tree-vect-slp.c (vect_slp_analyze_bb_1): Delay call to vect_verify_datarefs_alignment until after statements have been marked as relevant/irrelevant. * tree-vect-data-refs.c (vect_verify_datarefs_alignment): Skip irrelevant statements. (vect_enhance_data_refs_alignment): Use STMT_VINFO_RELEVANT_P instead of STMT_VINFO_RELEVANT. (vect_get_data_access_cost): Do not check for supportable alignment before calling vect_get_load_cost/vect_get_store_cost. * tree-vect-stmts.c (vect_get_store_cost): Do not abort when handling unsupported alignment. (vect_get_load_cost): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/53636] SLP may create invalid unaligned memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636 --- Comment #3 from Ulrich Weigand 2012-06-26 09:05:56 UTC --- Author: uweigand Date: Tue Jun 26 09:05:48 2012 New Revision: 188979 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188979 Log: PR tree-optimization/53729 PR tree-optimization/53636 * tree-vect-slp.c (vect_slp_analyze_bb_1): Delay call to vect_verify_datarefs_alignment until after statements have been marked as relevant/irrelevant. * tree-vect-data-refs.c (vect_verify_datarefs_alignment): Skip irrelevant statements. (vect_enhance_data_refs_alignment): Use STMT_VINFO_RELEVANT_P instead of STMT_VINFO_RELEVANT. (vect_get_data_access_cost): Do not check for supportable alignment before calling vect_get_load_cost/vect_get_store_cost. * tree-vect-stmts.c (vect_get_store_cost): Do not abort when handling unsupported alignment. (vect_get_load_cost): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c
[Bug middle-end/53776] pragma optimize does not support Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53776 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-26 Blocks||48110 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-06-26 08:57:52 UTC --- Confirmed.
[Bug tree-optimization/53774] Reassociator generates non-canonical addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53774
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-06-26
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2012-06-26
08:56:35 UTC ---
Confirmed with -O1. get_rank (fp_6(D)) returns the same value as
get_rank (constant). Constants should always have a lesser rank than
non-constants.
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c (revision 188927)
+++ gcc/tree-ssa-reassoc.c (working copy)
@@ -337,7 +337,7 @@ get_rank (tree e)
{
/* Constants have rank 0. */
if (is_gimple_min_invariant (e))
-return 0;
+return -1;
/* SSA_NAME's have the rank of the expression they are the result
of.
would fix it, but I'm not sure we want negative ranks.
[Bug bootstrap/53731] [4.7] Bootstrap fails for libgfortran on Solaris 10 x86 with error "Where has __float128 gone?"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53731 Martin changed: What|Removed |Added Severity|normal |major
[Bug target/53772] Failed to combine load and jump on vtable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53772 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2012-06-26 08:52:10 UTC --- This is a sibcall, for which we currently don't allow MEM operands: ;; Similarly, but for tail calls, in which we cannot allow memory references. (define_special_predicate "sibcall_insn_operand" (ior (match_test "constant_call_address_operand (op, mode == VOIDmode ? mode : Pmode)") (match_operand 0 "register_no_elim_operand"))) We could allow there MEMs, but only if we can prove the MEM doesn't live on the stack below the red-zone.
[Bug tree-optimization/53773] Vectorizer generates non-canonical multiplies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53773 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-26 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther 2012-06-26 08:52:21 UTC --- Confirmed.
[Bug lto/53768] [4.7 Regression] Undefined references with boost 1.46/1.48/1.49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53768 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug middle-end/53776] pragma optimize does not support Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53776 --- Comment #1 from Andrew Pinski 2012-06-26 08:43:36 UTC --- Ofast is recorded as PR 48110.
[Bug tree-optimization/53773] Vectorizer generates non-canonical multiplies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53773
--- Comment #2 from rguenther at suse dot de
2012-06-26 08:35:59 UTC ---
On Tue, 26 Jun 2012, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53773
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
> --- Comment #1 from Jakub Jelinek 2012-06-26
> 08:31:36 UTC ---
> Seems this is vect_is_simple_reduction_1's:
> if (check_reduction)
> {
> /* Swap operands (just for simplicity - so that the rest of the code
> can assume that the reduction variable is always the last
> (second)
> argument). */
> if (vect_print_dump_info (REPORT_DETAILS))
> report_vect_op (def_stmt,
> "detected reduction: need to swap operands: ");
>
> swap_tree_operands (def_stmt, gimple_assign_rhs1_ptr (def_stmt),
> gimple_assign_rhs2_ptr (def_stmt));
> }
>
> at least on the first testcase. Now, the question is how hard would it be to
> adjust the vectorizer so that it would work even without doing this swapping,
> or
> alternatively if we shouldn't canonicalize the operand order afterwards.
Or change it to "just for simplicity - ... that the reduction variable is
always the first argument.". Eventually that will wreck with reduction
of MINUS_EXPR though, not sure.
Richard.
[Bug lto/53777] New: [lto] lto does not propagate optimization flags from command lines given at "compilation time"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777
Bug #: 53777
Summary: [lto] lto does not propagate optimization flags from
command lines given at "compilation time"
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
we are used to mix in the same library code compiled with -O2 and -Os
Lto seems to ignore the options used in the "compilation" steps
It does honor "pragma GCC optimize" though
example
cat optopt.cc
// #pragma GCC optimize ("0")
void bar(int);
inline void foo(int i, int j) {
if (i>0) bar(i);
if (j>0) bar(j);
if (i>0) bar(j);
if (j>0) bar(i);
};
void foo1(int i, int j) {
foo(i,j);
}
void foo2(int i, int j) {
foo(i,j);
}
void foo3(int i, int j) {
foo(i,j);
}
c++ -flto -fno-fat-lto-objects -Os -c optopt.cc -fPIC
c++ -flto -O2 -shared optopt.o -fPIC -o optopt.so; nm -C optopt.so
….
U bar(int)
07a0 T foo1(int, int)
0740 T foo2(int, int)
06e0 T foo3(int, int)
….
c++ -flto -Os -shared optopt.o -fPIC -o optopt.so; nm -C optopt.so
….
U bar(int)
06e0 t foo(int, int) [clone .local.0.2370]
071c T foo1(int, int)
071a T foo2(int, int)
0718 T foo3(int, int)
…
if I decomment the pragma I get what intended
c++ -flto -fno-fat-lto-objects -O2 -c optopt.cc -fPIC
c++ -flto -O2 -shared optopt.o -fPIC -o optopt.so; nm -C optopt.so
U bar(int)
06e0 t foo(int, int) [clone .local.0.2370]
0760 T foo1(int, int)
0750 T foo2(int, int)
0740 T foo3(int, int)
due to PR53776 I cannot specify Os using a pragma. so I am a bit stuck
[Bug tree-optimization/53773] Vectorizer generates non-canonical multiplies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53773
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek 2012-06-26
08:31:36 UTC ---
Seems this is vect_is_simple_reduction_1's:
if (check_reduction)
{
/* Swap operands (just for simplicity - so that the rest of the code
can assume that the reduction variable is always the last (second)
argument). */
if (vect_print_dump_info (REPORT_DETAILS))
report_vect_op (def_stmt,
"detected reduction: need to swap operands: ");
swap_tree_operands (def_stmt, gimple_assign_rhs1_ptr (def_stmt),
gimple_assign_rhs2_ptr (def_stmt));
}
at least on the first testcase. Now, the question is how hard would it be to
adjust the vectorizer so that it would work even without doing this swapping,
or
alternatively if we shouldn't canonicalize the operand order afterwards.
[Bug tree-optimization/53748] [4.8 Regression] ice in fold_convert_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53748 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek 2012-06-26 08:24:32 UTC --- Fixed.
[Bug middle-end/53776] New: pragma optimize does not support Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53776
Bug #: 53776
Summary: pragma optimize does not support Os
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
I need to compile optimized for size some portion of code.
The easiest is to "inject" pragmas in the source code at building time
unfortunately Os (and I think also Ofast) are not supported in
pragma optimize (and I think also not by __attribute__)
only numbers works
for instance take
cat optopt.cc
#pragma GCC optimize ("s")
void bar(int);
inline void foo(int i, int j) {
if (i>0) bar(i);
if (j>0) bar(j);
if (i>0) bar(j);
if (j>0) bar(i);
};
void foo1(int i, int j) {
foo(i,j);
}
void foo2(int i, int j) {
foo(i,j);
}
void foo3(int i, int j) {
foo(i,j);
}
c++ -O2 -c optopt.cc; nm -C optopt.o
U bar(int)
T foo1(int, int)
0060 T foo2(int, int)
00c0 T foo3(int, int)
c++ -Os -c optopt.cc; nm -C optopt.o
U bar(int)
W foo(int, int)
T foo1(int, int)
0005 T foo2(int, int)
000a T foo3(int, int)
with
#pragma GCC optimize ("1")
one gets what intended
c++ -O2 -c optopt.cc; nm -C optopt.o
U bar(int)
W foo(int, int)
T foo1(int, int)
0010 T foo2(int, int)
0020 T foo3(int, int)
[Bug tree-optimization/53748] [4.8 Regression] ice in fold_convert_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53748 --- Comment #5 from Jakub Jelinek 2012-06-26 08:02:31 UTC --- Author: jakub Date: Tue Jun 26 08:02:20 2012 New Revision: 188975 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188975 Log: PR tree-optimization/53748 * tree-ssa-phiopt.c (conditional_replacement): Only optimize if arg0/arg1 have integral or pointer types. * gcc.c-torture/compile/pr53748.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr53748.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
