[Bug target/49385] Invalid RTL intstruction for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49385 --- Comment #6 from jye2 at gcc dot gnu.org 2011-09-19 08:13:09 UTC --- Author: jye2 Date: Mon Sep 19 08:13:02 2011 New Revision: 178955 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178955 Log: 2011-09-19 Jiangning Liu Backport r175427 from mainline 2011-06-27 Richard Guenther PR tree-optimization/49169 * fold-const.c (get_pointer_modulus_and_residue): Don't rely on the alignment of function decls. 2011-09-19 Jiangning Liu Backport r175208 from mainline 2011-06-20 Ramana Radhakrishnan PR target/49385 * config/arm/thumb2.md (*thumb2_movhi_insn): Make sure atleast one of the operands is a register. 2011-09-19 Jiangning Liu Backport r174803 from mainline 2011-06-08 Julian Brown * config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI for double-precision helper functions in hard-float mode if only single-precision arithmetic is supported in hardware. Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.c branches/ARM/embedded-4_6-branch/gcc/config/arm/thumb2.md branches/ARM/embedded-4_6-branch/gcc/fold-const.c
[Bug rtl-optimization/49169] ARM: optimisations strip the Thumb/ARM mode bit off function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49169 --- Comment #6 from jye2 at gcc dot gnu.org 2011-09-19 08:13:09 UTC --- Author: jye2 Date: Mon Sep 19 08:13:02 2011 New Revision: 178955 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178955 Log: 2011-09-19 Jiangning Liu Backport r175427 from mainline 2011-06-27 Richard Guenther PR tree-optimization/49169 * fold-const.c (get_pointer_modulus_and_residue): Don't rely on the alignment of function decls. 2011-09-19 Jiangning Liu Backport r175208 from mainline 2011-06-20 Ramana Radhakrishnan PR target/49385 * config/arm/thumb2.md (*thumb2_movhi_insn): Make sure atleast one of the operands is a register. 2011-09-19 Jiangning Liu Backport r174803 from mainline 2011-06-08 Julian Brown * config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI for double-precision helper functions in hard-float mode if only single-precision arithmetic is supported in hardware. Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.c branches/ARM/embedded-4_6-branch/gcc/config/arm/thumb2.md branches/ARM/embedded-4_6-branch/gcc/fold-const.c
[Bug target/50022] [4.7 regression] "incorrect condition in IT block" when building mozilla code base for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50022
--- Comment #8 from jye2 at gcc dot gnu.org 2011-09-19 08:35:45 UTC ---
Author: jye2
Date: Mon Sep 19 08:35:37 2011
New Revision: 178960
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178960
Log:
2011-09-19 Jiangning Liu
Backport r177759 from mainline
2011-08-15 Ramana Radhakrishnan
PR target/50022
* config/arm/arm.c (output_move_double): Add 2 parameters
to count the number of insns emitted and whether to emit or not.
Use the flag to decide when to emit and count number of instructions
that will be emitted.
Handle case where output_move_double might be called for calculating
lengths with an invalid constant.
(arm_count_output_move_double_insns): Define.
* config/arm/arm-protos.h (arm_count_output_move_double_insns): Declare.
(output_move_double): Adjust prototype.
* config/arm/vfp.md ("*movdi_vfp"): Adjust call to
output_move_double.
("*movdi_vfp_cortexa8"): Likewise and add attribute
for ce_count.
* config/arm/arm.md ("*arm_movdi"): Adjust call to output_move_double.
("*movdf_soft_insn"): Likewise.
* config/arm/cirrus.md ("*cirrus_arm_movdi"): Likewise.
("*cirrus_thumb2_movdi"): Likewise.
("*thumb2_cirrus_movdf_hard_insn"): Likewise.
("*cirrus_movdf_hard_insn"): Likewise.
* config/arm/neon.md (*neon_mov VD): Likewise.
* config/arm/iwmmxt.md ("*iwmmxt_arm_movdi"): Likewise.
("mov_internal VMMX"): Likewise.
* config/arm/fpa.md (*movdf_fpa, *thumb2_movdf_fpa): Likewise.
2011-09-19 Jiangning Liu
Backport r176867 from mainline
2011-07-28 Ramana Radhakrishnan
* config/arm/vfp.md ("*movdf_vfp"): Handle the VFP constraints
before the core constraints. Adjust attributes.
(*thumb2_movdf_vfp"): Likewise.
2011-09-19 Jiangning Liu
Backport r175588 from mainline
2011-06-28 Ramana Radhakrishnan
* config/arm/vfp.md ("*divsf3_vfp"): Replace '+' constraint modifier
with '=' constraint modifier.
(*divdf3_vfp): Likewise.
("*mulsf3_vfp"): Likewise.
("*muldf3_vfp"): Likewise.
("*mulsf3negsf_vfp"): Likewise.
("*muldf3negdf_vfp"): Likewise.
2011-09-19 Jiangning Liu
Backport r174894 from mainline
2011-06-10 Ramana Radhakrishnan
Richard Earnshaw
* config/arm/arm.c (const_ok_for_op): Check to see
if mvn can be used.
* config/arm/vfp.md (*arm_movdi_vfp): Delete.
(*thumb2_movdi_vfp): Delete.
(*arm_movdi_vfp_cortexa8): Delete.
(*movdi_vfp): Consolidate from *arm_movdi_vfp and *thumb2_movdi_vfp.
(*movdi_vfp_cortexa8): Likewise.
2011-09-19 Jiangning Liu
Backport r172777 from mainline
2011-04-20 Andrew Stubbs
* config/arm/arm.c (arm_gen_constant): Move movw support
(const_ok_for_op): ... to here.
2011-09-19 Jiangning Liu
Partially backport r171449 from mainline
2011-03-25 Bernd Schmidt
Andrew Stubbs
* config/arm/vfp.md (arm_movdi_vfp): Enable only when not tuning
for Cortex-A8.
(arm_movdi_vfp_cortexa8): New pattern.
* config/arm/arm.md: Move include arm-tune.md up a bit.
(define_attr "arch"): Add "onlya8" and "nota8" values.
(define_attr "arch_enabled"): Handle "onlya8" and "nota8".
Modified:
branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm-protos.h
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.c
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.md
branches/ARM/embedded-4_6-branch/gcc/config/arm/cirrus.md
branches/ARM/embedded-4_6-branch/gcc/config/arm/fpa.md
branches/ARM/embedded-4_6-branch/gcc/config/arm/iwmmxt.md
branches/ARM/embedded-4_6-branch/gcc/config/arm/neon.md
branches/ARM/embedded-4_6-branch/gcc/config/arm/vfp.md
[Bug testsuite/50435] FAIL: gcc.dg/vect/bb-slp-25.c (-flto)? scan-tree-dump-times slp "basic block vectorized using SLP" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50435 --- Comment #13 from Ira Rosen 2011-09-19 08:59:44 UTC --- (In reply to comment #12) > Note that I have replaced all the occurrences of __restrict with __restrict__ > I have found in gcc.dg/vect/* and bb-slp-25.c is the only test for which it > mattered. It is probably just doesn't matter in other tests: we can use versioning for alias in loop vectorization.
[Bug target/49437] interrupt return pop sometimes corrupts sp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49437 --- Comment #4 from jye2 at gcc dot gnu.org 2011-09-19 09:03:35 UTC --- Author: jye2 Date: Mon Sep 19 09:03:29 2011 New Revision: 178963 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178963 Log: 2011-09-19 Joey Ye Backport r177891 from mainline 2011-08-19 Matthew Gretton-Dann PR target/49437 * config/arm/arm.c (arm_output_epilogue): Properly handle epilogue when stack was realigned in interrupt handler prologue. testsuite: 2011-08-19 Joey Ye PR target/49437 * gcc.target/arm/handler-align.c: New test. * lib/target-supports.exp (check_effective_target_arm_cortex_m): New Function. 2011-09-19 Joey Ye Backport r177890 from mainline 2011-08-19 Joey Ye * gcc.c-torture/execute/20101011-1.c (DO_TEST): Skip on ARM. Added: branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/torture/pr49169.c branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.target/arm/handler-align.c branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.target/arm/pr46934.c Modified: branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.c branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.c-torture/execute/20101011-1.c branches/ARM/embedded-4_6-branch/gcc/testsuite/lib/target-supports.exp
[Bug tree-optimization/46021] 3 tree-ssa tests XPASS almost everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46021 --- Comment #10 from jye2 at gcc dot gnu.org 2011-09-19 09:32:59 UTC --- Author: jye2 Date: Mon Sep 19 09:32:54 2011 New Revision: 178967 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178967 Log: 2011-09-19 Terry Guo Backport r178628 from mainline 2011-09-07 Jiangning Liu PR tree-optimization/46021 * gcc.dg/tree-ssa/20040204-1.c: Don't XFAIL on arm*-*-*. 2011-09-19 Terry Guo Backport r177594 from mainline 2011-08-09 Ulrich Weigand * gcc.dg/pr49948.c: Require pthread effective target. 2011-09-19 Terry Guo Backport r176760 from mainline 2011-07-25 Rainer Orth * lib/target-supports.exp (check_effective_target_mmap): New proc. * gcc.dg/vect/pr49038.c: Remove dg-do run. Use dg-require-effective-target mmap. 2011-09-19 Terry Guo Backport r174115 from mainline 2011-05-24 Rainer Orth * gcc.dg/vect/pr48172.c: Remove dg-do run. Modified: branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/pr49948.c branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/pr48172.c branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/pr49038.c branches/ARM/embedded-4_6-branch/gcc/testsuite/lib/target-supports.exp
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856 --- Comment #7 from Paolo Carlini 2011-09-19 11:05:10 UTC --- But see: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01048.html. Thus, for the time being, I'm going to use __int128_t and __uint128_t in the implementation details: using the latter to define specializations instead of __int128 and unsigned __int128 should be undetectable from the user point of view.
[Bug c++/50454] New: Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454
Bug #: 50454
Summary: Unexpected problems with -pedantic / -pedantic-errors
and __int128 and unsigned __int128 specializations
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com
Consider the following, with -pedantic-errors (-pedantic triggers a warning):
template
struct limits;
template<>
struct limits<__int128> { };
template<>
struct limits { };
a.cc:8:26: error: ISO C++ does not support ‘__int128’ for ‘type name’
[-pedantic]
a.cc:8:10: error: redefinition of ‘struct limits<__int128>’
a.cc:5:10: error: previous definition of ‘struct limits<__int128>’
The first and second error lines are certainly incorrect. If I remove the
second specialization the error goes away completely. GCC system_header appear
to help, but then soon the problem resurfaces, eg, together with PCHs.
As an additional data point, the following appears to work, no errors or
warnings with either option:
template
struct limits;
template<>
struct limits<__int128_t> { };
template<>
struct limits<__uint128_t> { };
(and I'm using it for the time being for PR40856), but still isn't entirely OK,
I can still trigger errors post 40856 for the following user code snippet
compiled with -std=gnu++0x -pedantic-errors on, eg, x86_64-linux (at least
-pedantic is fine in this case)
#include
static_assert(std::numeric_limits<__int128_t>::is_specialized == true, "");
static_assert(std::numeric_limits<__uint128_t>::is_specialized == true, "");
Something is definitely fishy here, considering in particular that, I'm told,
__int128_t should be just a typedef for __int128, likewise __uint128_t for
unsigned __int128.
[Bug middle-end/49886] [4.6/4.7 Regression] pass_split_functions cannot deal with function type attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886 --- Comment #9 from Martin Jambor 2011-09-19 11:43:04 UTC --- Thanks for letting me know about this. However, as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886 the whole XFAIL will go away after I commit the patch today.
[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454 --- Comment #1 from Paolo Carlini 2011-09-19 11:44:23 UTC --- Scratch "but still isn't entirely OK, I can still trigger errors post 40856 for the following user code snippet compiled with -std=gnu++0x -pedantic-errors on, eg, x86_64-linux". Luckily for PR40856, this isn't true (was using an old tree). Thus the problem is entirely restricted to __int128 and unsigned __int128.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #8 from irar at gcc dot gnu.org 2011-09-19 11:46:05 UTC --- Author: irar Date: Mon Sep 19 11:46:00 2011 New Revision: 178968 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178968 Log: PR tree-optimization/50413 * tree-vect-data-refs.c (vect_analyze_data_refs): Fail to vectorize a basic block if one of its data-refs can't be analyzed. Added: trunk/gcc/testsuite/g++.dg/vect/slp-pr50413.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/vect/vect.exp trunk/gcc/tree-vect-data-refs.c
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856 --- Comment #8 from paolo at gcc dot gnu.org 2011-09-19 11:52:54 UTC --- Author: paolo Date: Mon Sep 19 11:52:49 2011 New Revision: 178969 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178969 Log: 2011-09-19 Paolo Carlini PR libstdc++/40856 * include/std/limits (numeric_limits<__int128_t>, numeric_limits<__uint128_t>): Add. * src/limits.cc:Define. * config/abi/pre/gnu.ver: Export. * include/ext/typelist.h (_GLIBCXX_TYPELIST_CHAIN16, 20): Add. * testsuite/util/testsuite_common_types.h (integral_types_gnu): Add (limits_tl): Use it. * testsuite/18_support/numeric_limits/requirements/ constexpr_functions.cc: Likewise. * testsuite/18_support/numeric_limits/40856.cc: New. * testsuite/18_support/numeric_limits/dr559.cc: Extend. * testsuite/18_support/numeric_limits/lowest.cc: Likewise. * testsuite/18_support/numeric_limits/max_digits10.cc: Likewise. * testsuite/29_atomics/atomic/cons/assign_neg.cc: Adjust dg-error line numbers. * testsuite/29_atomics/atomic/cons/copy_neg.cc: Likewise. * testsuite/29_atomics/atomic_integral/cons/assign_neg.cc: Likewise. * testsuite/29_atomics/atomic_integral/cons/copy_neg.cc: Likewise. * testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc: Likewise. * testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc: Likewise. * testsuite/29_atomics/atomic_integral/operators/increment_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/18_support/numeric_limits/40856.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/ext/typelist.h trunk/libstdc++-v3/include/std/limits trunk/libstdc++-v3/src/limits.cc trunk/libstdc++-v3/testsuite/18_support/numeric_limits/dr559.cc trunk/libstdc++-v3/testsuite/18_support/numeric_limits/lowest.cc trunk/libstdc++-v3/testsuite/18_support/numeric_limits/max_digits10.cc trunk/libstdc++-v3/testsuite/18_support/numeric_limits/requirements/constexpr_functions.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/increment_neg.cc trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #9 from Paolo Carlini 2011-09-19 11:54:59 UTC --- Done.
[Bug c++/50455] New: duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 Bug #: 50455 Summary: duplicate class/constructor silently accepted, wrong constructor linked Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: eda...@disemia.com Created attachment 25316 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25316 1 of 2 reproduction source files
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #1 from eda-qa at disemia dot com 2011-09-19 12:20:24 UTC --- The compiler/linker is silently ignoring that a class has been defined twice and this results in the linker linking to the incorrect constructor at instantiation time. This was found in a large set of libraries, but the two attached files reproduce the same problem. Reproduce: - Compile a program using the attached files and the instantiation in main() will use the wrong constructor. g++ -o test main.cpp duplicate.cpp Now, with optimizations the correct constructor is used, presumably since it is inlined and thus not subject to linking: g++ -O3 -o test main.cpp duplicate.cpp NOTE: The code is *invalid* but emits no diagnostic as one would expect. The issue is thus that the linker would be expected to emit a diagnostic message, likely an error about duplicate symbol.
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #2 from eda-qa at disemia dot com 2011-09-19 12:21:24 UTC --- Created attachment 25317 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25317 2 of 2 reproduction source files
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #3 from eda-qa at disemia dot com 2011-09-19 12:23:13 UTC --- Triage notes: As the issue is that no diagnostic is produced I was uncertain how to locate duplicates -- I tried a few search queries and came up empty. Also note that both source files are needed to reproduce the error, it cannot be reproduced (to my knowledge) with a single source file. The error *happens* at link time, but I'm uncertain what part in the tool chain is truly responsible for it.
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #4 from eda-qa at disemia dot com 2011-09-19 12:25:08 UTC --- g++ (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2) GNU ld version 2.20.51.0.2-20.fc13 20091009 Linux devbox 2.6.34.9-69.fc13.x86_64 #1 SMP Tue May 3 09:23:03 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #5 from Paolo Carlini 2011-09-19 12:31:58 UTC --- I'm pretty sure that this is one of those cases where the user violates the ODR, thus undefined behavior, but diagnostics isn't required, exactly because would have to produced at *link* time. You should search Bugzilla for closed PRs having to do with violations of the One Definition Rule, there are duplicates, for sure.
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #6 from Jakub Jelinek 2011-09-19 12:38:01 UTC --- And as the ctor is inline, it must have comdat linkage and therefore this user error is not detectable by the linker (as it is just fine to have multiple definitions in different translation units, just one of them will be selected, and as they can be compiled with different compiler options or versions, there is no guarantee they have identical assembly either).
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #7 from Paolo Carlini 2011-09-19 12:48:25 UTC --- Indeed, thanks Jakub.
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #4 from Jakub Jelinek 2011-09-19 12:51:59 UTC --- I've looked briefly at the http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00631.html patch, it seems the UNSPEC_REDUC* is unnecessary there (only used in the expanders ending with DONE, in that case just a list of the operands is enough), and I don't see any reason for the new RTL codes either (why not just use (gt:V4SI (reg:V4SF r1) (reg:V4SF r2)) etc. in the patterns instead?). Furthermore, the floating vs. integral operands in vcond* should now be handled on the trunk (just supported on i386/x86_64, but there is no reason why it can't be added for rs6000 too). The patch unfortunately doesn't apply cleanly, am trying to resolve the rejects now.
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 --- Comment #8 from eda-qa at disemia dot com 2011-09-19 12:53:33 UTC --- I agree that this is a violation of the ODR. I agree this might be difficult for the linker to detect. However for a user this is a serious problem that can be very hard to determine without the help of the tool chain. Consider that in my original project the duplicate definition was in some other library in the automake setup. This implies that linking with *any* external library/object can introduce this error into your project without any compiler/linker diagnostic. I would suspect an average user would expect a "duplicate symbol" error for this type of error. Otherwise this makes it unsafe to add new classes to any C++ library, ever: any new class may silently replace the constructor of some class by the user of the library.
[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-19 Ever Confirmed|0 |1 --- Comment #2 from Jason Merrill 2011-09-19 13:07:20 UTC --- This seems to be a bug with Kai's 2010-05-26 patch adding __int128 support. If we're going to pedwarn about __int128, that shouldn't depend on whether there is also a modifier like unsigned, and it should be suppressed in a system header.
[Bug middle-end/49886] [4.6/4.7 Regression] pass_split_functions cannot deal with function type attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886 --- Comment #10 from Martin Jambor 2011-09-19 13:27:00 UTC --- Author: jamborm Date: Mon Sep 19 13:26:50 2011 New Revision: 178973 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178973 Log: 2011-09-19 Martin Jambor PR middle-end/49886 * ipa-split.c (split_function): Do not change signature if it is not possible or there are attribute types. * testsuite/gcc.dg/torture/pr49886.c: Remove XFAILs. * testsuite/gcc.dg/torture/pr50287.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr50287.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/ipa-split.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr49886.c
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 Jonathan Wakely changed: What|Removed |Added Severity|major |normal --- Comment #9 from Jonathan Wakely 2011-09-19 13:35:27 UTC --- the gold linker detects some ODR violations note that there's a good reason the standard says "no diagnostic required" - consider if the constructor is defined inline in a header, one translation unit is compiled using the header, then the constructor definition in the header is changed, a second translation unit is compiled using the header and linked to the first object - you now have two copies of the inline constructor that don't agree, even thought they are the exact same function for the same class, defined on the same line of the same header. The linker can't even compare instructions in the objects because they could differ for valid reasons, e.g. due to different optimisations. In general, it is the user's responsibility to avoid ODR violations.
[Bug middle-end/49886] [4.6/4.7 Regression] pass_split_functions cannot deal with function type attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886 Martin Jambor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Martin Jambor 2011-09-19 13:35:35 UTC --- So this should now be fixed again.
[Bug debug/47471] [4.6/4.7 Regression] stdarg functions extraneous too-early prologue end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471 philipp at marek dot priv.at changed: What|Removed |Added CC||philipp at marek dot ||priv.at --- Comment #6 from philipp at marek dot priv.at 2011-09-19 13:53:18 UTC --- Is there a chance to get this fixed? I've got a fair number of setups where GDB gets a number of breakpoints set on startup, and some of these don't work anymore ... I've got gcc=4:4.6.1-2 and gdb=7.3-1.
[Bug debug/47471] [4.6/4.7 Regression] stdarg functions extraneous too-early prologue end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471 --- Comment #7 from Jan Kratochvil 2011-09-19 13:56:39 UTC --- FYI a workaround is now checked in to FSF GDB HEAD: http://sourceware.org/ml/gdb-patches/2011-09/msg00140.html I confirm gdb-7.3 / 7.3.1 does not have the workaround and gdb-7.4 is far away.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #9 from H.J. Lu 2011-09-19 14:09:08 UTC --- On Linux/x86, I got FAIL: g++.dg/vect/slp-pr50413.cc scan-tree-dump-times slp "basic block vectorized using SLP" 0
[Bug c++/50456] New: attributes ignored on member templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50456
Bug #: 50456
Summary: attributes ignored on member templates
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@gtk.org
Decorating a member template with __attribute__((error)) should trigger
compiler errors like declaring regular methods does. (A similar bug exists
about __attribute__((warning))).
Example code:
template struct Object;
template<> struct Object {
template static void
should_error (A a)
__attribute__ ((error ("Calling this function should trigger a compiler
error")))
;
};
int main (int argc, char *argv[]) {
typedef Object FloatObject;
FloatObject::should_error (7);
return 0;
}
// g++ -Wall -O2 x.cc && ./a.out
Actual result:
x.cc:(.text+0xa): undefined reference to `void
Object::should_error(int)'
Expected result:
x.cc:10: error: call to ‘Object::should_error’ declared with attribute
error: Calling this function should trigger a compiler error
Observed with g++-4.4 and g++-4.5 (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #10 from H.J. Lu 2011-09-19 14:19:59 UTC --- The checked-in testcase always passes since it has no check. It is missing: if (V.uint128.uint64_lower != 0x14b84800d4004001) abort (); at the end.
[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454 --- Comment #3 from Paolo Carlini 2011-09-19 14:33:33 UTC --- Thanks. I'll see if I can quickly adjust that code in this sense or ask Kai's help.
[Bug tree-optimization/50337] -ftree-dse performs wrong elimination on electric-fence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50337 --- Comment #4 from Colin Watson 2011-09-19 14:56:55 UTC --- Ah yes, it does indeed! I think it's fair enough to have to build efence with -fno-builtin-malloc, so feel free to close this bug.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #11 from Dominique d'Humieres 2011-09-19 15:20:22 UTC --- > On Linux/x86, I got > > FAIL: g++.dg/vect/slp-pr50413.cc scan-tree-dump-times slp "basic block > vectorized using SLP" 0 I get the same failure on x86_64-apple-darwin10. Grepping for SLP returns 170: Build SLP for V.uint128.uint64_lower = 0; 170: Build SLP for V.uint128.uint64_upper = 3556786177; 170: Basic block will be vectorized using SLP 170: SLPing BB 170: -->SLPing statement: V.uint128.uint64_lower = 0; 170: -->vectorizing SLP node starting from: V.uint128.uint64_lower = 0; 170: vectorizing stmts using SLP. 170: basic block vectorized using SLP /opt/gcc/work/gcc/testsuite/g++.dg/vect/slp-pr50413.cc:168: note: Failed to SLP the basic block. /opt/gcc/work/gcc/testsuite/g++.dg/vect/slp-pr50413.cc:168: note: not vectorized: failed to find SLP opportunities in basic block. If I omit '-fno-vect-cost-model', I get 170: Build SLP for V.uint128.uint64_lower = 0; 170: Build SLP for V.uint128.uint64_upper = 3556786177; /opt/gcc/work/gcc/testsuite/g++.dg/vect/slp-pr50413.cc:168: note: Failed to SLP the basic block. /opt/gcc/work/gcc/testsuite/g++.dg/vect/slp-pr50413.cc:168: note: not vectorized: failed to find SLP opportunities in basic block.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #12 from Dominique d'Humieres 2011-09-19 15:21:55 UTC --- Created attachment 25318 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25318 slp dump with -fno-vect-cost-model
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #13 from Dominique d'Humieres 2011-09-19 15:23:42 UTC --- Created attachment 25319 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25319 slp dump without -fno-vect-cost-model
[Bug testsuite/50076] FAIL: c-c++-common/cxxbitfields-3.c scan-assembler movl.*, var on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50076 --- Comment #2 from Aldy Hernandez 2011-09-19 15:37:37 UTC --- I will be contributing a testing harness that is back-end agnostic, so it won't depend on scanning the assembly. Stay tuned.
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #5 from Jakub Jelinek 2011-09-19 15:59:06 UTC --- Created attachment 25320 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25320 gcc47-pr50374-wip.patch Here is the ported patch with rejects hopefully resolved and a few bugfixes for the 4.6 -> 4.7 changes. I've omitted the vcondc/vcondcu stuff because the trunk handles mixed float/integral vcond/u already, the rs6000 stuff (because IMHO the first step for rs6000 should be to add support for the mixed float/integral vcond/u for rs6000 and I'm not familiar with rs6000 enough), GTF/EQF etc. dropped (I think that it is not needed) and testcases separated out of it for now. I had to make changes beyond rejects as COND_EXPR assignments are now represented differently and the pattern stmts are no longer emitted into the basic blocks. I see no reason why this should be limited to floating point comparisons and integral indexes, IMHO e.g. finding location of smallest integer is common too. That said, I'm now stuck with it, on the fast-math-no-pre-minmax-loc-1.c (on x86_64 -O2 -ftree-vectorize -fno-tree-pre) testcase the compound pattern recognition seems to work, but still the vectorizer gives up: 17: Unsupported pattern. 17: not vectorized: unsupported use in stmt. 17: unexpected pattern. Ira, do you think you could have a quick look at this?
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #15 from Jan Hubicka 2011-09-19 16:09:23 UTC --- BTW since the exception seems to be thrown from libuno_cppuhelpergcc3.so.3 that sounds like there is some sort of gcc specific magic that has good chance to break with LTO, I would suggest to try to compile that dso w/o linktime (you only need to add -fno-use-linker-plugin -fno-lto) and hopefully we get past this issue? Honza
[Bug target/50457] New: SH2A atomic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457 Bug #: 50457 Summary: SH2A atomic functions Classification: Unclassified Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: philip.stearns.an...@gmail.com The SH specific atomic functions don't seem to work properly with the SH2A processor. An example function from the gcc/config/sh/linux-atomic.asm is as follows: #define ATOMIC_FETCH_AND_OP(OP,N,T) \ .global__sync_fetch_and_##OP##_##N; \ HIDDEN_FUNC(__sync_fetch_and_##OP##_##N); \ .align2; \ __sync_fetch_and_##OP##_##N:; \ mova1f, r0; \ movr15, r1; \ mov#(0f-1f), r15; \ <<< SP modification 0:mov.##T@r4, r2; \ OPr2, r5; \ mov.##Tr5, @r4; \ 1:movr1, r15; \ <<< SP modification rts; \ movr2, r0; \ ENDFUNC(__sync_fetch_and_##OP##_##N) Functions following this style cause the application to eventually crash. I think this may be related to the locking mechanism around the instructions making use of an on-board MMU, since the SP is loaded with a negative value. As the SH2A does not have an MMU this poses a problem. Replacing the SP modifying code with direct interrupt disabling/enabling resolves the problem and the application no longer crashes: #define ATOMIC_FETCH_AND_OP(OP,N,T,EXT) \ .global__sync_fetch_and_##OP##_##N; \ HIDDEN_FUNC(__sync_fetch_and_##OP##_##N); \ .align2; \ __sync_fetch_and_##OP##_##N:; \ stcsr, r0; \ movr0, r1; \ or#0xf0, r0; \ ldcr0, sr; \ <<< interrupt disable mov.##T@r4, r2; \ OPr2, r5; \ mov.##Tr5, @r4; \ ldcr1, sr; \ <<< interrupt restore rts; \ EXTr2, r0; \ ENDFUNC(__sync_fetch_and_##OP##_##N)
[Bug target/50341] calls via function pointer wrongly scheduled giving invalid TOC pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50341 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Michael Meissner 2011-09-19 17:08:47 UTC --- Patch applied to trunk and GCC 4.6 branches not to split the load of the new TOC and the call. If we want to fix the underlying cause of the HIGH/LO_SUM not being optimized so the split can be re-enabled, reopen the bug.
[Bug tree-optimization/35261] GCC4.3 internal compiler error: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35261 --- Comment #5 from Harald van Dijk 2011-09-19 17:51:44 UTC --- My testcase failed with 4.3 and 4.4. 4.3.6 still rejects it, but it seems to be accepted by 4.4.6, so if 4.3 is no longer maintained, this looks fixed.
[Bug bootstrap/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50326 --- Comment #7 from Martin Jambor 2011-09-19 18:21:25 UTC --- The compilation before and after the patch seems to diverge at expand time and only in one instruction when processing this particular gimple statement: MEM[(struct prop_value_d *)&D.39146].lattice_val = val$lattice_val_443; When val$lattice_val is an enum type, it is expanded to: (insn 4927 4926 4928 593 (set (mem/s/c:SI (reg/f:DI 2698) [10 MEM[(struct prop_value_d *)&D.39146].lattice_val+0 S4 A128]) (reg:SI 433 [ val$lattice_val ])) /abuild/mjambor/trunk/src/gcc/tree-ssa-ccp.c:1685 -1 (nil)) whereas when it is , it is expanded to: (insn 4927 4926 4928 593 (set (mem/s/c:SI (reg/f:DI 2698) [4 MEM[(struct prop_value_d *)&D.39146].lattice_val+0 S4 A128]) (reg:SI 433 [ val$lattice_val ])) /abuild/mjambor/trunk/src/gcc/tree-ssa-ccp.c:1685 -1 (nil)) The difference is 4 instead of 10. Now I am entering an entirely unchartered territory for me on quite a few levels so don't hold your breath for any progress. I will keep looking into this, though.
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #7 from Ruben Van Boxem 2011-09-19 19:28:48 UTC --- I'm still experiencing the same behavior. I don't think the darwinx toolchain has the problems you say? Why do you think it uses a Darwin9 system framework and headers? It has GCC 4.2.1 and the Mac OS X 10.5 SDK, which are all pretty Darwin10 as far as I can see. Something changed in 4.6 vs 4.7. I have sys/malloc.h , objc/malloc.h, and malloc/malloc.h. Somehow, HAVE_MALLOC_H is being wrongfully defined to 1 when it should be 0. auto-host.h has the define commented out. auto-build.h has it defined. These are the same for GCC 4.6. So the problem must lie elsewhere... I noticed the gengtype-lex.o object file is build with i686-apple-darwin10-gcc for GCC 4.7, and (Linux) gcc for GCC 4.6. This cannot be intended behavior.
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 Iain Sandoe changed: What|Removed |Added CC||peter at pogma dot com --- Comment #8 from Iain Sandoe 2011-09-19 19:45:38 UTC --- (In reply to comment #7) > I'm still experiencing the same behavior. yes, I would guess so unless you re-build the cross tools (and that would probably not solve your config problems - given the other comments you made) ... > I don't think the darwinx toolchain has the problems you say? Why do you > think > it uses a Darwin9 system framework and headers? It has GCC 4.2.1 and the Mac > OS > X 10.5 SDK, which are all pretty Darwin10 as far as I can see. OSX 10.5 is darwin 9 (and gcc 4.2.1 is perfectly usable under OSX10.5/darwin9 - it's just not the default). Target: i686-apple-darwin10 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=i686-apple-darwin10 --enable-languages=c,objc,c++,obj-c++ --with-sysroot=/usr/darwinx/SDKs/MacOSX10.5.sdk . I'm not aware of a genuine darwin10 (OSX 10.6) cross-toolchain - but if there is I'd love to see it (I'm only aware of toolwhip and odcctools which are both on the darwin9 ld64 AFAIK).
[Bug c++/50455] duplicate class/constructor silently accepted, wrong constructor linked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50455 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug lto/50367] -flto and -Wl,--as-needed combination removes some needed libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50367
Matthias Klose changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #1 from Matthias Klose 2011-09-19
21:14:50 UTC ---
$ cat test-flto.c
#include
#include
int main()
{
printf("%le\n", gamma(42));
return 0;
}
$ gcc -Wl,--as-needed -flto test-flto.c -lm
/tmp/ccXjDUDX.ltrans0.ltrans.o: In function `main':
ccXjDUDX.ltrans0.o:(.text+0xd): undefined reference to `gamma'
collect2: ld returned 1 exit status
$ gcc -B/usr/lib/gold-ld/ -Wl,--as-needed -flto -o test-flto test-flto.c -lm
does work
[Bug lto/50367] -flto and -Wl,--as-needed combination removes some needed libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50367 --- Comment #2 from Matthias Klose 2011-09-19 21:21:53 UTC --- http://sourceware.org/bugzilla/show_bug.cgi?id=13201
[Bug c++/50458] New: ICE when using brace-initializer for new array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458
Bug #: 50458
Summary: ICE when using brace-initializer for new array
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: z...@sogetthis.com
The following causes a crash in GCC 4.6.1, with or without -std=c++0x:
char * p = new char[110] {};
[Bug c++/50458] ICE when using brace-initializer for new array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458 --- Comment #1 from Kerrek SB 2011-09-19 22:13:29 UTC --- (I am told that this is no longer a problem in the latest snapshot.)
[Bug c++/50458] ICE when using brace-initializer for new array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-19 CC||jason at gcc dot gnu.org Known to work||4.7.0 Ever Confirmed|0 |1 Known to fail||4.6.2 --- Comment #2 from Jonathan Wakely 2011-09-19 22:14:16 UTC --- yep, works ok on trunk, but confirmed with gcc version 4.6.2 20110917 (prerelease) [gcc-4_6-branch revision 178930] (GCC)
[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454
Paolo Carlini changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #4 from Paolo Carlini 2011-09-19
23:20:33 UTC ---
Looks like something is wrong in the grokdeclarator logic. We do:
if (explicit_int128)
{
if (int128_integer_type_node == NULL_TREE)
{
error ("%<__int128%> is not supported by this target");
ok = 0;
}
else if (pedantic)
{
pedwarn (input_location, OPT_pedantic,
"ISO C++ does not support %<__int128%> for %qs",
name);
if (flag_pedantic_errors)
ok = 0;
}
}
but *only* as part of the conditional:
/* Check all other uses of type modifiers. */
if (unsigned_p || signed_p || long_p || short_p)
This explains why the first specialization alone, which uses only plain
__int128, never triggers any warning or error, with -pedantic or
-pedantic-errors.
Then, as you can see above, in case of -pedantic-errors, ok is set = 0, which
implies, afterward (line 8717), that unsigned_p is set back to false, thus
obviously the following very weird redefinition error with my snippet.
Thus, I think we should first decide whether __int128 and unsigned __int128
should both consistently behave as, currently, __int128 and __int128_t and
__uint128_t, thus no warning or error whatsoever with -pedantic and
-pedantic-errors. Otherwise, have something consistent for __int128 and
unsigned __int128, which, for the latter, doesn't scrap away the unsigned (then
if we fix the latter issue, GCC system_error should work fine automatically)
What do you think? Maybe Kai has also something to say about the logic he meant
to implement, and/or wants to suggest the right place for the check:
if (int128_integer_type_node == NULL_TREE)
{
error ("%<__int128%> is not supported by this target");
ok = 0;
}
which I think we want anyway *somewhere*, both for __int128 and unsigned
__int128, if we don't have it already somewhere else.
[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454 --- Comment #5 from Paolo Carlini 2011-09-19 23:23:22 UTC --- s/GCC system_error/#pragma GCC system_header/
[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454 --- Comment #6 from Paolo Carlini 2011-09-19 23:56:22 UTC --- Created attachment 25321 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25321 patchlet Constructively, this is something which should lead to unsigned __int128 treated exactly like plain __int128 (note: not fully tested) On x86_64 -m32, where __int128 isn't available we reject with 'template argument 1 is invalid', we don't reach grokdeclarator at all.
[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 Bryce Lelbach (wash) changed: What|Removed |Added CC||blelbach at cct dot lsu.edu --- Comment #2 from Bryce Lelbach (wash) 2011-09-20 00:15:40 UTC --- (In reply to comment #1) > (In reply to comment #0) > > I realized that the complexity of std::list::size() is O(n), not O(1). > > > > This does not conform to standard. The standard states that size() function > > is > > in constant time for alls containers. > > No, the current standard does not. > > The C++0x draft does, but it's not yet a standard, and parts of it are not yet > implemented. The current standard is now C++11. 23.2.1, Table 96 explicitly states that the size() method of Containers must execute in constant time. Can this bug please be changed to confirmed? As of today (r178989), std::list<>::size() is still O(N).
[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 --- Comment #3 from Paolo Carlini 2011-09-20 00:28:37 UTC --- It's already confirmed, NEW means confirmed.
[Bug rtl-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #25 from carrot at gcc dot gnu.org 2011-09-20 00:57:44 UTC --- Author: carrot Date: Tue Sep 20 00:57:39 2011 New Revision: 178995 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178995 Log: PR rtl-optimization/49452 * postreload.c (reload_combine): Invalidate use information when across volatile insn. Modified: trunk/gcc/ChangeLog trunk/gcc/postreload.c
[Bug c/50459] New: alignof doesn't work on plain old constant, works with expressions containing it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459
Bug #: 50459
Summary: alignof doesn't work on plain old constant, works with
expressions containing it
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com
For certain types of constant, the exact form:
__attribute__((aligned(align)))
fails, even though 'align' can be used in other constant expressions.
Types of constants that fail:
// C
enum { align = 8 };
// C++
const int align = 8;
class Foo { static const int align = 8; };
// and lots of nasty template stuff
Anything that forms an expression succeeds, even if it's just (align).
sizeof() or a C++11 constexpr function also work.
Bad versions: 4.2.4, 4.3.6, 4.4.6, 4.5.3, 4.6.0, 4.6.1, and a couple of recent
builds from git.
Minimal testcase:
enum { align = 8 };
int succeeds __attribute__((aligned((align)) ));
int fails __attribute__((aligned(align) ));
[Bug lto/50367] -flto and -Wl,--as-needed combination removes some needed libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50367 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amodra at gmail dot com Resolution||INVALID --- Comment #3 from Alan Modra 2011-09-20 02:07:39 UTC --- Not a gcc bug.
[Bug middle-end/50460] New: [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460
Bug #: 50460
Summary: [4.7 Regression]
__builtin___strcpy_chk/__builtin_object_size don't
work
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
On Linux/x86, revision 178028 gave
[hjl@gnu-34 gcc]$ cat ~/tmp/foo.c
const char *str1 = "JIHGFEDCBA";
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) char *
__attribute__ ((__nothrow__)) strcpy (char *__restrict __dest, __const char
*__restrict __src)
{
return __builtin___strcpy_chk (__dest, __src, __builtin_object_size (__dest,
2 > 1));
}
int
main ()
{
struct A { char buf1[9]; char buf2[1]; } a;
strcpy (a.buf1 + (0 + 4), str1 + 5);
return 0;
}
[hjl@gnu-34 gcc]$ ./xgcc -B./ -O2 ~/tmp/foo.c
[hjl@gnu-34 gcc]$ ./a.out
[hjl@gnu-34 gcc]$
instead of
[hjl@gnu-34 gcc]$ ./a.out
*** buffer overflow detected ***: ./a.out terminated
=== Backtrace: =
/lib64/libc.so.6(__fortify_fail+0x37)[0x3e56103ca7]
/lib64/libc.so.6[0x3e56101c20]
./a.out[0x40041e]
/lib64/libc.so.6(__libc_start_main+0xed)[0x3e560215bd]
./a.out[0x400451]
=== Memory map:
0040-00401000 r-xp 08:11 52433950
/export/gnu/import/svn/gcc-test-ia32corei7/bld/gcc/a.out
0060-00601000 rw-p 08:11 52433950
/export/gnu/import/svn/gcc-test-ia32corei7/bld/gcc/a.out
00a33000-00a54000 rw-p 00:00 0 [heap]
3e55c0-3e55c22000 r-xp 08:06 392457
/lib64/ld-2.14.90.so
3e55e21000-3e55e22000 r--p 00021000 08:06 392457
/lib64/ld-2.14.90.so
3e55e22000-3e55e23000 rw-p 00022000 08:06 392457
/lib64/ld-2.14.90.so
3e55e23000-3e55e24000 rw-p 00:00 0
3e5600-3e561a6000 r-xp 08:06 392458
/lib64/libc-2.14.90.so
3e561a6000-3e563a5000 ---p 001a6000 08:06 392458
/lib64/libc-2.14.90.so
3e563a5000-3e563a9000 r--p 001a5000 08:06 392458
/lib64/libc-2.14.90.so
3e563a9000-3e563aa000 rw-p 001a9000 08:06 392458
/lib64/libc-2.14.90.so
3e563aa000-3e563b rw-p 00:00 0
3e5780-3e57815000 r-xp 08:06 392602
/lib64/libgcc_s-4.6.0-20110603.so.1
3e57815000-3e57a14000 ---p 00015000 08:06 392602
/lib64/libgcc_s-4.6.0-20110603.so.1
3e57a14000-3e57a15000 rw-p 00014000 08:06 392602
/lib64/libgcc_s-4.6.0-20110603.so.1
7fb292f73000-7fb292f76000 rw-p 00:00 0
7fb292f93000-7fb292f95000 rw-p 00:00 0
7fff0d60a000-7fff0d62b000 rw-p 00:00 0
[stack]
7fff0d68a000-7fff0d68b000 r-xp 00:00 0 [vdso]
ff60-ff601000 r-xp 00:00 0
[vsyscall]
Aborted (core dumped)
[hjl@gnu-34 gcc]$
Revision 177983 is OK.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #14 from Ira Rosen 2011-09-20 06:23:54 UTC --- The basic block that got vectorized on these platforms is in main(). I am going to remove it and leave only shift(), since the main purpose of the test is to check that shift () doesn't get vectorized. Thanks, Ira
