[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #51 from Jakub Jelinek --- (In reply to Roland Schulz from comment #50) > I must say I don't know how the internals work. But I assume that reductions > are implemented in libgomp (I know they are in iomp). Thus for any code > which uses OpenMP reduce statements, libgomp would touch user data. Your assumption is wrong, reductions are not handled in libgomp, but in the code emitted by the compiler.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #52 from Joost VandeVondele --- (In reply to Jakub Jelinek from comment #51) > Your assumption is wrong, reductions are not handled in libgomp, but in the > code emitted by the compiler. does this imply that the combination of -fsanitize=thread and a libgomp as obtained with --disable-linux-futex is indeed a 'proper' solution for this PR, or do you think that building two libraries such as suggested in comment #42 would be best ?
[Bug c/61756] New: arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756
Bug ID: 61756
Summary: arm-none-eabi-gcc-4.10.0 internal compiler error with
atomic_flag
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: robertgjenssen at gmail dot com
Created attachment 33093
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33093&action=edit
sh script to build arm-none-eabi binutils, newlib and arm-none-eabi-gcc-4.10.0
1. uname -a:
Linux morgawr 3.15.3-200.fc20.x86_64 #1 SMP Tue Jul 1 16:18:00 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux
2. Construct an arm-none-eabi-gcc toolchain with the attached script,
build-arm-toolchain.sh
3. Compile the following code (tt.c):
#include
static volatile atomic_flag guard = ATOMIC_FLAG_INIT;
void try_atomic_flag_test_and_set(void)
{
atomic_flag_test_and_set(&guard);
}
with:
arm-toolchain/bin/arm-none-eabi-gcc-4.10.0 -c -o obj/tt.o -std=c11 -O0 -g
-mcpu=arm7tdmi -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -save-temps tt.c
and get:
$ arm-toolchain/bin/arm-none-eabi-gcc-4.10.0 -c -o obj/tt.o -std=c11 -O0 -g
-mcpu=arm7tdmi -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -save-temps tt.c
In file included from tt.c:3:0:
tt.c: In function ‘try_atomic_flag_test_and_set’:
tt.c:9:3: internal compiler error: in emit_move_insn, at expr.c:3575
atomic_flag_test_and_set(&guard);
^
0x7074a3 emit_move_insn(rtx_def*, rtx_def*)
../../gcc-4.10-20140706/gcc/expr.c:3574
0x8d3d74 expand_atomic_test_and_set(rtx_def*, rtx_def*, memmodel)
../../gcc-4.10-20140706/gcc/optabs.c:7355
0x60f094 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc-4.10-20140706/gcc/builtins.c:6739
0x700b62 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-4.10-20140706/gcc/expr.c:10344
0x62d48f expand_expr
../../gcc-4.10-20140706/gcc/expr.h:451
0x62d48f expand_call_stmt
../../gcc-4.10-20140706/gcc/cfgexpand.c:2307
0x62d48f expand_gimple_stmt_1
../../gcc-4.10-20140706/gcc/cfgexpand.c:3202
0x62d48f expand_gimple_stmt
../../gcc-4.10-20140706/gcc/cfgexpand.c:3354
0x62e4bd expand_gimple_basic_block
../../gcc-4.10-20140706/gcc/cfgexpand.c:5192
0x62ff8d execute
../../gcc-4.10-20140706/gcc/cfgexpand.c:5799
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Here is tt.i:
# 1 "tt.c"
# 1 "/home/robj/TMP//"
# 1 ""
# 1 ""
# 1 "tt.c"
# 1
"/home/robj/TMP/arm-toolchain/lib/gcc/arm-none-eabi/4.10.0/include/stdatomic.h"
1 3 4
# 29
"/home/robj/TMP/arm-toolchain/lib/gcc/arm-none-eabi/4.10.0/include/stdatomic.h"
3 4
typedef enum
{
memory_order_relaxed = 0,
memory_order_consume = 1,
memory_order_acquire = 2,
memory_order_release = 3,
memory_order_acq_rel = 4,
memory_order_seq_cst = 5
} memory_order;
typedef _Atomic _Bool atomic_bool;
typedef _Atomic char atomic_char;
typedef _Atomic signed char atomic_schar;
typedef _Atomic unsigned char atomic_uchar;
typedef _Atomic short atomic_short;
typedef _Atomic unsigned short atomic_ushort;
typedef _Atomic int atomic_int;
typedef _Atomic unsigned int atomic_uint;
typedef _Atomic long atomic_long;
typedef _Atomic unsigned long atomic_ulong;
typedef _Atomic long long atomic_llong;
typedef _Atomic unsigned long long atomic_ullong;
typedef _Atomic short unsigned int atomic_char16_t;
typedef _Atomic long unsigned int atomic_char32_t;
typedef _Atomic unsigned int atomic_wchar_t;
typedef _Atomic signed char atomic_int_least8_t;
typedef _Atomic unsigned char atomic_uint_least8_t;
typedef _Atomic short int atomic_int_least16_t;
typedef _Atomic short unsigned int atomic_uint_least16_t;
typedef _Atomic long int atomic_int_least32_t;
typedef _Atomic long unsigned int atomic_uint_least32_t;
typedef _Atomic long long int atomic_int_least64_t;
typedef _Atomic long long unsigned int atomic_uint_least64_t;
typedef _Atomic int atomic_int_fast8_t;
typedef _Atomic unsigned int atomic_uint_fast8_t;
typedef _Atomic int atomic_int_fast16_t;
typedef _Atomic unsigned int atomic_uint_fast16_t;
typedef _Atomic int atomic_int_fast32_t;
typedef _Atomic unsigned int atomic_uint_fast32_t;
typedef _Atomic long long int atomic_int_fast64_t;
typedef _Atomic long long unsigned int atomic_uint_fast64_t;
typedef _Atomic int atomic_intptr_t;
typedef _Atomic unsigned int atomic_uintptr_t;
typedef _Atomic unsigned int atomic_size_t;
typedef _Atomic int atomic_ptrdiff_t;
typedef _Atomic long long int atomic_intmax_t;
typedef _Atomic long long unsigned int atomic_uintmax_t;
# 232
"/home/robj/TMP/arm-toolchain/lib/gcc/arm-none-eabi/4.10.0/include/stdatomic.h"
3 4
typedef _Atomic struct
{
_Bool __val
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #53 from Dmitry Vyukov --- If we instrument libgomp with tsan, this can introduce lots of extraneous synchronization which is useful only for verification of libgomp itself, but harmful for libgomp users (as it will lead to false positives). What can be useful (but not top priority if nobody complains) is to insert some manual annotations for tsan into libgomp. I don't know enough about libgomp internals and have not used libgomp+tsan, so don't know what exactly they must do. But potentially they can do: 1. Tell tsan about accesses to user memory. I.e. if libgomp still accesses some user memory in some cases, then can tell tsan about that. 2. Tell tsan about precise synchronization model for user. E.g. I suspect that interactions with scheduler in parallel for construct synchronize all user threads (if the scheduler calls pthread_mutex_lock/unlock); this synchronization can lead to false positives in user programs. We can suppress that synchronization and instead tell tsan what is the documented synchronization guarantees for user. 3. Improve reports.
[Bug bootstrap/61757] New: genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Bug ID: 61757 Summary: genmodes failure with enable-checking Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com I just tried a bootstrap of revision 212385 with extra flag --enable-checking=yes and got echo timestamp > s-genrtl-h build/genmodes -m > tmp-min-modes.c build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be set build/genmodes: config/i386/i386-modes.def:24: (XF) field format must not be set build/genmodes: machmode.def:203: (DF) field format must not be set build/genmodes: machmode.def:202: (SF) field format must not be set build/genmodes: machmode.def:244: (TD) field format must not be set build/genmodes: machmode.def:243: (DD) field format must not be set build/genmodes: machmode.def:242: (SD) field format must not be set make[3]: *** [s-modes-m] Error 1 Configure line is ../src/trunk/configure --prefix=/home/dcb/gcc/results --enable-checking=yes --enable-languages=c,c++,fortran --disable-werror CC="clang -g -O2 -Wall -fheinous-gnu-extensions" CXX="clang++ -g -O2 -Wall -fheinous-gnu-extensions" Bootstrap line is (date; time make BOOT_CFLAGS='-g -O3' CFLAGS_FOR_TARGET='-g -O3' -j 5 bootstrap; date) > mk.out 2>&1 &
[Bug ipa/61602] [4.10 Regression] ICE in lto1 on x86_64-linux-gnu in ipa_single_use, at ipa.c:1257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61602 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-09 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r211925 (at least the #c1 testcase).
[Bug c++/59361] cannot expand parenthesized pack expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jul 9 08:32:43 2014 New Revision: 212386 URL: https://gcc.gnu.org/viewcvs?rev=212386&root=gcc&view=rev Log: /cp 2014-07-09 Andrew Sutton Paolo Carlini PR c++/59361 * parser.c (cp_parser_tokens_start_cast_expression): Return 0 for CPP_ELLIPSIS too. /testsuite 2014-07-09 Andrew Sutton Paolo Carlini PR c++/59361 * g++.dg/cpp0x/vt-59361.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-59361.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59361] cannot expand parenthesized pack expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #5 from Paolo Carlini --- Fixed.
[Bug target/48183] ICE [arm] immed_double_const at emit-rtl.c (-mfpu=neon -g -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48183 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from ktkachov at gcc dot gnu.org --- >From what I can see in the Linaro report this has been fixed. I can't reproduce it on 4.10 trunk or 4.8.3
[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from ktkachov at gcc dot gnu.org --- 4.6 is no longer maintained and this is fixed on the maintained releases.
[Bug target/52412] another unnecessary register move on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52412
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||ktkachov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from ktkachov at gcc dot gnu.org ---
Both trunk 4.10 and 4.8.3 generate:
t0m:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
ldr r3, [r0, #4]
movsr1, #10
push{r4, r5, lr}
ldr r5, .L8
uxtbr2, r3
.L2:
ldr r4, [r0, #268]
subsr1, r1, #1
eor r4, r4, r2
ldr r4, [r5, r4, lsl #2]
str r4, [r0, #268]
bne .L2
add r3, r3, r0
movsr1, #1
strbr1, [r3, #12]
ldr r3, [r0, #8]
cmp r3, r1
beq .L5
cmp r3, #2
beq .L5
pop {r4, r5, pc}
.L5:
ldr r3, [r0]
strbr2, [r3]
pop {r4, r5, pc}
.L9:
.align 2
.L8:
.word Table
No superfluous mov appears, so I think this can be closed now...
[Bug bootstrap/61757] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- See also https://gcc.gnu.org/ml/gcc-regression/2014-07/ Same thing here on x86_64-apple-darwin13 at r212373 configured with $ ../p_work/configure --prefix=/opt/gcc/gcc4.10p-212373 --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2 My bootstrap compiler is gcc r211652. With it I have successfully boostrapped r212366 configured with $ ../work/configure --prefix=/opt/gcc/gcc4.10w --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 or r212374 configured with $ ../_clean/configure --prefix=/opt/gcc/gcc4.10c --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
[Bug testsuite/61453] [4.10 Regression]: gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453 --- Comment #3 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Wed Jul 9 09:01:06 2014 New Revision: 212387 URL: https://gcc.gnu.org/viewcvs?rev=212387&root=gcc&view=rev Log: 2014-07-09 Dominique d'Humieres PR testsuite/61453 * gfortran.dg/gfortran.dg/bind_c_array_params_2.f90: Adjust regexp for more targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
[Bug testsuite/61453] [4.10 Regression]: gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres --- Hopefully fixed. Closing.
[Bug libstdc++/61758] New: std::chrono::steady_clock::now() no longer exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 Bug ID: 61758 Summary: std::chrono::steady_clock::now() no longer exported Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: Martin.vGagern at gmx dot net Between 4.8.0 and 4.8.1, SVN commit 199331 changed the implementation of compatibility-chrono.cc. Up to that point, it basically included chrono.cc which provided implementations for system_clock and steady_clock, but bound them to specific symbol versions. That commit changes the approach to make use of an inline namespace, which is certainly more portable. The compatibility implementation was modified to no longer include chrono.cc but instead duplicate part of its functionality. And therein lies the rub: only PART of the implementation has been copied to the compatibility file. Now system_clock is included there, but steady_clock is not. Which causes ABI breakage, as observed in https://bugs.gentoo.org/513386.
[Bug target/43999] Gcc (lib1funcs.asm) doesn't build on ARM/Thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43999 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from ktkachov at gcc dot gnu.org --- Closing this. It's fixed in all currently maintained versions
[Bug target/49423] [4.8/4.9/4.10 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #30 from ktkachov at gcc dot gnu.org --- This testcase now works on trunk 4.10. Charles, can this be closed? or is there some backporting to be done?
[Bug target/49423] [4.8/4.9/4.10 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||cbaylis at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |cbaylis at gcc dot gnu.org --- Comment #31 from cbaylis at gcc dot gnu.org --- I intend to backport to 4.8 and 4.9, once this change has had a week of testing on trunk.
[Bug target/61756] arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||arm* Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-09 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.10.0, 4.9.1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. Fails on 4.9 and 4.10 trunk. 4.8 doesn't accept this code: error: expected specifier-qualifier-list before 'int_least8_t' typedef _Atomic(int_least8_t) atomic_int_least8_t; ^ -O0 -march=armv6 are the options needed to reproduce this. Any architecture level at armv6 and below will cause this.
[Bug target/52435] ICE in arm_select_dominance_cc_mode, at config/arm/arm.c:10625
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52435 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-09 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- I can't reproduce this with 4.8.3, 4.9.1 or 4.10 trunk. Is this still an issue?
[Bug bootstrap/61757] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||aarch64-linux, x86, ia64 CC||ktkachov at gcc dot gnu.org, ||mshawcroft at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed on aarch64 as well
[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 --- Comment #1 from Martin von Gagern --- I just read https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01553.html indicating that this is likely a deliberate ABI breakage for an experimental API. If that is your official position, feel free to close WONTFIX. Too bad that this kind of information contained in the email isn't included in the commit message. Would have saved me a lot of time.
[Bug target/59843] ICE with return of generic vector on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 --- Comment #7 from Jakub Jelinek --- Isn't even this change ABI changing? I know you ICE when returning such vectors, but doesn't the change from BLKmode to V1DFmode change how such vars are laid out in structures, or passed in as arguments, or when present in aggregates (structs/unions) passed by value etc.?
[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 --- Comment #2 from Jonathan Wakely --- It is totally unsupported (and unlikely to work) to mix C++11 code built with GCC 4.x and 4.y, for any x!=y Mixing code built with 4.8.x and 4.8.y should work, and does with the default configuration. You didn't actually provide the information required by http://gcc.gnu.org/bugs such as the output of 'gcc -v' but I assume you're building GCC with --enable-libstdcxx-time, in which case there are fewer guarantees. If Gentoo is using that option (which should not be necessary with GCC 4.8 anyway) then you need to rebuild all the libraries that depend on the types. We could potentially export a steady_clock::now() compatibility symbol for the --enable-libstdcxx-time config, but I'd prefer to see that option go away rather than keep it on life support.
[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The main problem was that --enable-libstdcxx-time used to be ABI incompatible option in the past.
[Bug bootstrap/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Richard Biener changed: What|Removed |Added Keywords||build Priority|P3 |P1 Version|4.9.0 |4.10.0 Target Milestone|--- |4.10.0 Summary|genmodes failure with |[4.10 Regression] genmodes |enable-checking |failure with ||enable-checking
[Bug lto/61741] wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 --- Comment #4 from Richard Biener --- The testcase fails without LTO as well if you use -Os -fno-strict-overflow, fixed by -fno-tree-vrp (not necessarily caused by it though). Also fails with -O2 -fno-strict-overflow. Smells similar to PR61184. The patch originally posted for that bug is thus still required.
[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725
Marat Zakirov changed:
What|Removed |Added
CC||joseph at codesourcery dot com,
||m.zakirov at samsung dot com
--- Comment #7 from Marat Zakirov ---
Another neon alloc issue.
Code:
#include
#include
extern uint16x8x4_t m0;
extern uint16x8x4_t m1;
void foo(uint16_t * in_ptr)
{
uint16x8x4_t t0, t1;
t0 = vld4q_u16((uint16_t *)&in_ptr[0 ]);
t1 = vld4q_u16((uint16_t *)&in_ptr[64]);
t0.val[0] *= 333;
t0.val[1] *= 333;
t0.val[2] *= 333;
t0.val[3] *= 333;
t1.val[0] *= 333;
t1.val[1] *= 333;
t1.val[2] *= 333;
t1.val[3] *= 333;
m0 = t0;
m1 = t1;
}
Asm file:
.vsave {d8, d9, d10, d11, d12, d13, d14, d15}
add r1, r0, #160
vld4.16 {d8, d10, d12, d14}, [r0]
add r0, r0, #32
.pad #64
sub sp, sp, #64
vld4.16 {d16, d18, d20, d22}, [r2]
movwr3, #:lower16:m1
movwr2, #:lower16:m0
vldrd6, .L3
vldrd7, .L3+8
movtr3, #:upper16:m1
movtr2, #:upper16:m0
vld4.16 {d9, d11, d13, d15}, [r0]
vld4.16 {d17, d19, d21, d23}, [r1]
vmul.i16q12, q3, q4
vstmia sp, {d16-d23} <<< *
vld1.64 {d4-d5}, [sp:64] <<< *
vmul.i16q13, q3, q5 <<< **
vmul.i16q9, q3, q9
vmul.i16q14, q3, q6 <<< **
vmul.i16q10, q3, q10
vmul.i16q8, q3, q2 <<< **, ***
vmul.i16q15, q3, q7 <<< **
vmul.i16q11, q3, q11
vstmia r2, {d24-d31}
vstmia r3, {d16-d23}
add sp, sp, #64
@ sp needed
fldmfdd sp!, {d8-d15}
bx lr
So my qustion are:
1) Why do we need * and why compiler used q2 in *** ?
2) Why compiler didn't reuse registers q5,q6,q2,q7 in ** ?
Command line:
cc1 -quiet -v t.c -quiet -dumpbase t.c -mfpu=neon -mcpu=cortex-a15
-mfloat-abi=softfp -marm -mtls-dialect=gnu -auxbase-strip t.s -O3
-Wno-error=unused-local-typedefs -version -fdump-tree-all -fdump-rtl-all
-funwind-tables -o t.s
gcc version = 4.10.0
--build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu
--target=arm-v7a15v5r2-linux-gnueabi
--Marat
[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758
--- Comment #4 from Martin von Gagern ---
Thanks for the quick reply.
(In reply to Jonathan Wakely from comment #2)
> It is totally unsupported (and unlikely to work) to mix C++11 code built
> with GCC 4.x and 4.y, for any x!=y
Any particular reason why you don't change the SONAME of the library for every
change from x to y in this case?
The way I see it, this might be causing serious problems for Gentoo in the near
future. As far as I understand things, Gentoo will always dynamically link
against the latest version of libstdc++, even though different versions of gcc
(and there can be several installed concurrently) will compile against their
own matching version. Assuming ABI backwards-compatibility, at least with the
help of symbol versioning, this probably worked well enough so far. But if
there are no such guarantees for C++11 then things will break more often as
applications start to use C++11.
> Mixing code built with 4.8.x and 4.8.y should work, and does with the
> default configuration.
I've got some doubts regarding 4.8.0 to 4.8.1 since the commits I mentioned
were in between. But I don't have evidence to support my doubts, and I'm more
interested in the 4.7 to 4.8 issues.
> You didn't actually provide the information required by
> http://gcc.gnu.org/bugs such as the output of 'gcc -v' but I assume you're
> building GCC with --enable-libstdcxx-time, in which case there are fewer
> guarantees. If Gentoo is using that option
It is, as per https://bugs.gentoo.org/411681
> (which should not be necessary with GCC 4.8 anyway) then you need to
> rebuild all the libraries that depend on the types.
Using gcc 4.8 throughout works fine, it's the mixing of a 4.7 compiler,
configured as system default, and a 4.8 library used since it's the latest,
which is causing the specific troubles on Gentoo.
> We could potentially export a steady_clock::now() compatibility symbol for
> the --enable-libstdcxx-time config, but I'd prefer to see that option go
> away rather than keep it on life support.
In what way has the ABI actually changed between chrono::steady_clock::now()
and chrono::_V2::steady_clock::now()? Looking at
http://repo.or.cz/w/official-gcc.git/blobdiff/95da0dc6f30722a5c46af68d1d6a24e7830b4b68..HEAD:/libstdc%2B%2B-v3/src/c%2B%2B11/chrono.cc
it looks to me as if you added that syscall capability, which I consider an
internal modification only, and you changed the #ifdef
_GLIBCXX_USE_CLOCK_MONOTONIC from completely removing the function to falling
back on system_clock. Right? So either the old lib did export that symbol or it
did not, but the new lib always export the symbol, and does so in a compatible
fashion. Is there any drawback from unconditionally exporting that new
implementation as an alias for the old? Something like this:
#if defined(_GLIBCXX_SYMVER_GNU) && defined(_GLIBCXX_SHARED) \
&& defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE) \
&& defined(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT)
// alias for backwards abi compatibility, see #61758
asm (".symver "
"_ZNSt6chrono3_V212steady_clock3nowEv,"
"_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17");
#endif
That way, you would not have to maintain the --enable-libstdcxx-time config
setting, and you would also help portability in those cases where code was
compiled on a 4.7 system with --enable-libstdcxx-time no matter the setting
used for the 4.8 system where the code is executed.
[Bug target/61756] arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- I'll take it.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Andreas Schwab changed: What|Removed |Added CC||rguenther at suse dot de Component|bootstrap |tree-optimization --- Comment #3 from Andreas Schwab --- Broken by r212352.
[Bug objc++/61759] New: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 Bug ID: 61759 Summary: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792 Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ Assignee: unassigned at gcc dot gnu.org Reporter: dougmencken at gmail dot com I cannot compile some LibreOffice .mm files using gcc-4.8.3 on OS X 10.5. Many of them fails with ICE when -O2 is used, but with -O(1) they compiles. I cannot also compile .cxx files when -x objective-c++ is used on gcc line. All of them ICE at the same spot: "in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792" This one (vcl/osx/a11yselectionwrapper.mm) ICEs even with -O: S=/lo-build && I=$S/instdir && W=$S/workdir && mkdir -p $W/ObjCxxObject/vcl/osx/ $W/Dep/ObjCxxObject/vcl/osx/ && cd /lo-build && /usr/bin/ccache g++ -save-temps -mmacosx-version-min=10.5 -DCPPU_ENV=gcc3 -DLIBO_INTERNAL_ONLY -DMACOSX -DMACOSX_SDK_VERSION=1050 -DMAC_OS_X_VERSION_MAX_ALLOWED=1050 -DMAC_OS_X_VERSION_MIN_REQUIRED=1050 -DNDEBUG -DNO_PTHREAD_PRIORITY -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DPOWERPC -DPPC -DSUPD=440 -DUNIX -DUNX -D_PTHREADS -D_REENTRANT -DRTL_USING -DVCL_DLLIMPLEMENTATION -DCUI_DLL_NAME=\"libcuilo.dylib\" -DDESKTOP_DETECTOR_DLL_NAME=\"\" -DTK_DLL_NAME=\"libtklo.dylib\" -DVCLPLUG_SVP_DLL_NAME=\"\" -DMACOSX_BUNDLE_IDENTIFIER=\"org.libreoffice.script\" -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fno-threadsafe-statics -fPIC -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fno-strict-aliasing -fsigned-char -std=gnu++11 -O -c $S/vcl/osx/a11yselectionwrapper.mm -o $W/ObjCxxObject/vcl/osx/a11yselectionwrapper.o -MMD -MT $W/ObjCxxObject/vcl/osx/a11yselectionwrapper.o -MP -MF $W/Dep/ObjCxxObject/vcl/osx/a11yselectionwrapper.d_ -I$S/vcl/osx/ -I$W/UnpackedTarball/lcms2/include -I$W/UnpackedTarball/icu/source -I$W/UnpackedTarball/icu/source/i18n -I$W/UnpackedTarball/icu/source/common -I$W/UnpackedTarball/boost -I$W/UnpackedTarball/jpeg -I$S/include -isystem /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers -I$S/config_host -I$W/CustomTarget/officecfg/registry -I$W/CustomTarget/vcl/generic/fontmanager -I$S/vcl/inc -I$W/UnoApiHeadersTarget/udkapi/normal -I$W/UnoApiHeadersTarget/offapi/normal -I$W/CustomTarget/officecfg/registry -I$W/UnpackedTarball/nss/dist/public/nss -I$W/UnpackedTarball/nss/dist/out/include && mv $W/Dep/ObjCxxObject/vcl/osx/a11yselectionwrapper.d_ $W/Dep/ObjCxxObject/vcl/osx/a11yselectionwrapper.d $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-unknown-darwin/4.8.3/lto-wrapper Target: powerpc-unknown-darwin Configured with: ../gcc-4.8.3/configure --build=powerpc-unknown-darwin --host=powerpc-unknown-darwin --target=powerpc-unknown-darwin --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --with-slibdir=/usr/lib --program-prefix= --enable-languages=c,c++,objc,obj-c++ --enable-checking=release --enable-stage1-checking --enable-shared --enable-static --enable-threads=posix --with-__thread --with-system-zlib --disable-werror Thread model: posix gcc version 4.8.3 (GCC)
[Bug objc++/61759] internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #1 from Douglas Mencken --- Created attachment 33094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33094&action=edit preprocessed a11yselectionwrapper.mm Attaching preprocessed a11yselectionwrapper.mm (a11yselectionwrapper.mii)
[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 --- Comment #5 from Jonathan Wakely --- (In reply to Martin von Gagern from comment #4) > (In reply to Jonathan Wakely from comment #2) > > It is totally unsupported (and unlikely to work) to mix C++11 code built > > with GCC 4.x and 4.y, for any x!=y > > Any particular reason why you don't change the SONAME of the library for > every change from x to y in this case? Think about it. That would prevent you from combining C++03 code compiled with different versions, and that works fine and is not experimental. Forcing millions of lines of C++03 code to be recompiled because of changes to experimental C++11 features would not be acceptable. > The way I see it, this might be causing serious problems for Gentoo in the > near future. As far as I understand things, Gentoo will always dynamically > link against the latest version of libstdc++, even though different versions > of gcc (and there can be several installed concurrently) will compile > against their own matching version. Assuming ABI backwards-compatibility, at > least with the help of symbol versioning, this probably worked well enough > so far. But if there are no such guarantees for C++11 then things will break > more often as applications start to use C++11. There will be guarantees soon, when the ABI stabilises. Until then, if Gentoo does that then it's Gentoo's problem. We can devote our limited resources to getting the ABI stable sooner, or we can spend our time on loads of nasty hacks to maintain compatibility for people using unsupported configurations and expecting behaviour we never guaranteed. > > Mixing code built with 4.8.x and 4.8.y should work, and does with the > > default configuration. > > I've got some doubts regarding 4.8.0 to 4.8.1 since the commits I mentioned > were in between. But I don't have evidence to support my doubts, and I'm > more interested in the 4.7 to 4.8 issues. There is no guarantee of compatibility for C++11 features between those releases, so any issues are irrelevant. > > (which should not be necessary with GCC 4.8 anyway) then you need to > > rebuild all the libraries that depend on the types. > > Using gcc 4.8 throughout works fine, it's the mixing of a 4.7 compiler, > configured as system default, and a 4.8 library used since it's the latest, > which is causing the specific troubles on Gentoo. You can't do that for code that uses C++11 library types. Period. Not a bug. > That way, you would not have to maintain the --enable-libstdcxx-time config > setting, and you would also help portability in those cases where code was > compiled on a 4.7 system with --enable-libstdcxx-time no matter the setting > used for the 4.8 system where the code is executed. I'm not interested in supporting C++11 code built with 4.7 and linking to 4.8 at runtime. Don't do that.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #4 from Andreas Schwab --- This also breaks gcc.dg/tree-ssa/20030922-2.c on m68k.
[Bug objc++/61759] internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #2 from Douglas Mencken --- Also, there's builder.cxx (one of files which compiles after removing -x objective-c++ from line, but not with it): S=/lo-build && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/vcl/source/window/ $W/Dep/CxxObject/vcl/source/window/ && cd /lo-build && /usr/bin/ccache g++ -mmacosx-version-min=10.5 -DCPPU_ENV=gcc3 -DLIBO_INTERNAL_ONLY -DMACOSX -DMACOSX_SDK_VERSION=1050 -DMAC_OS_X_VERSION_MAX_ALLOWED=1050 -DMAC_OS_X_VERSION_MIN_REQUIRED=1050 -DNDEBUG -DNO_PTHREAD_PRIORITY -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DPOWERPC -DPPC -DSUPD=440 -DUNIX -DUNX -D_PTHREADS -D_REENTRANT -DRTL_USING -DVCL_DLLIMPLEMENTATION -DCUI_DLL_NAME=\"libcuilo.dylib\" -DDESKTOP_DETECTOR_DLL_NAME=\"\" -DTK_DLL_NAME=\"libtklo.dylib\" -DVCLPLUG_SVP_DLL_NAME=\"\" -DMACOSX_BUNDLE_IDENTIFIER=\"org.libreoffice.script\" -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fno-threadsafe-statics -fPIC -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fno-strict-aliasing -fsigned-char -std=gnu++11 -Wno-long-double -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -O2 -x objective-c++ -fobjc-exceptions -c $S/vcl/source/window/builder.cxx -o $W/CxxObject/vcl/source/window/builder.o -MMD -MT $W/CxxObject/vcl/source/window/builder.o -MP -MF $W/Dep/CxxObject/vcl/source/window/builder.d_ -I$S/vcl/source/window/ -I$W/UnpackedTarball/lcms2/include -I$W/UnpackedTarball/icu/source -I$W/UnpackedTarball/icu/source/i18n -I$W/UnpackedTarball/icu/source/common -I$W/UnpackedTarball/boost -I$W/UnpackedTarball/jpeg -I$S/include -isystem /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers -I$S/config_host -I$W/CustomTarget/officecfg/registry -I$W/CustomTarget/vcl/generic/fontmanager -I$S/vcl/inc -I$W/UnoApiHeadersTarget/udkapi/normal -I$W/UnoApiHeadersTarget/offapi/normal -I$W/CustomTarget/officecfg/registry -I$W/UnpackedTarball/nss/dist/public/nss -I$W/UnpackedTarball/nss/dist/out/include && mv $W/Dep/CxxObject/vcl/source/window/builder.d_ $W/Dep/CxxObject/vcl/source/window/builder.d ** Error message: vcl/source/window/builder.cxx: In member function 'void VclBuilder::loadTranslations(const LanguageTag&, const rtl::OUString&)': vcl/source/window/builder.cxx:91:6: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792 void VclBuilder::loadTranslations(const LanguageTag &rLanguageTag, const OUString& rUri) ^ libbacktrace could not find executable to open ** Error message for vcl/osx/a11yselectionwrapper.mm was: ./vcl/osx/a11yselectionwrapper.mm:31:61: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792 +(id)selectedChildrenAttributeForElement:(AquaA11yWrapper *)wrapper
[Bug objc++/61759] internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #3 from Douglas Mencken --- Created attachment 33095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33095&action=edit preprocessed builder.cxx Attaching preprocessed builder.cxx (builder.mii)
[Bug c++/58155] -Wliteral-suffix warns about tokens which are skipped by preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58155 --- Comment #2 from emsr at gcc dot gnu.org --- Author: emsr Date: Wed Jul 9 13:33:58 2014 New Revision: 212392 URL: https://gcc.gnu.org/viewcvs?rev=212392&root=gcc&view=rev Log: libcpp/ 2014-07-09 Edward Smith-Rowland <3dw...@verizon.net> PR c++/58155 - -Wliteral-suffix warns about tokens which are skipped by preprocessor * lex.c (lex_raw_string ()): Do not warn about invalid suffix if skipping. (lex_string ()): Ditto. gcc/testsuite/ 2014-07-09 Edward Smith-Rowland <3dw...@verizon.net> PR c++/58155 - -Wliteral-suffix warns about tokens which are skipped g++.dg/cpp0x/pr58155.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr58155.C Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/lex.c
[Bug c/59850] Support sparse-style pointer address spaces (type attributes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #31 from Tom Tromey --- (In reply to Tom Tromey from comment #28) > > Please let me know what I can do to help complete this branch. I'd be happy > > to help write the documentation, for instance. > > It's maybe not quite ready for testing. I did a bit more work on it now. Josh, could you take a look? It's g...@github.com:tromey/gcc.git add-sparse-attributes Most useful, I think, would be a review of the tests, to make sure that they are complete and correct; and a review of the docs. force, adddress_space, and noderef are the final 5 commits on the branch. I didn't squash it all into submission form yet.
[Bug c/59850] Support sparse-style pointer address spaces (type attributes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #32 from Tom Tromey --- (In reply to Tom Tromey from comment #31) > force, adddress_space, and noderef are the final 5 commits on the branch. Err, 8 commits.
[Bug c++/58155] -Wliteral-suffix warns about tokens which are skipped by preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58155 --- Comment #3 from emsr at gcc dot gnu.org --- Author: emsr Date: Wed Jul 9 15:10:43 2014 New Revision: 212393 URL: https://gcc.gnu.org/viewcvs?rev=212393&root=gcc&view=rev Log: libcpp/ 2014-07-09 Edward Smith-Rowland <3dw...@verizon.net> PR c++/58155 - -Wliteral-suffix warns about tokens which are skipped by preprocessor * lex.c (lex_raw_string ()): Do not warn about invalid suffix if skipping. (lex_string ()): Ditto. gcc/testsuite/ 2014-07-09 Edward Smith-Rowland <3dw...@verizon.net> PR c++/58155 - -Wliteral-suffix warns about tokens which are skipped g++.dg/cpp0x/pr58155.C: New. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/pr58155.C Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/libcpp/ChangeLog branches/gcc-4_9-branch/libcpp/lex.c
[Bug c++/58155] -Wliteral-suffix warns about tokens which are skipped by preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58155 emsr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from emsr at gcc dot gnu.org --- Fixed on trunk and 4.9.
[Bug target/59843] ICE with return of generic vector on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 Alan Lawrence changed: What|Removed |Added CC||alan.lawrence at arm dot com --- Comment #8 from Alan Lawrence --- Passing a vector of one double as argument also ICE'd prior to this patch, so no worries there. Likewise passing such a vector in as varargs. Regarding struct layout: *IIUC, gcc generally lays out structs in memory according to the sizes of the data members, which hasn't changed. *The AAPCS64 does not mention gcc vector extensions explicitly, only the architectural concept of short vectors, but if we consider gcc vector extensions as mapping to these short vectors (as they have done) - then there is no dependency on gcc's concept of "mode". *I've verified this with some by-hand testcases, using typedef double gcc_vector_f64x1 __attribute__ ((__vector_size__ ((8; passing and returning by value *a small struct of a single gcc_vector_f64x1 *a small struct of a char and a gcc_vector_f64x1 *a struct of four gcc_vector_f64x1's (classed as a Homogenous Vector Aggregate) all passed in registers, and *a large struct (of over 16 bytes, containing char, gcc_vector_f64x1, char, gcc_vector_f64x2) ...written to memory and passing a pointer. Also explicitly passing pointers to structs in memory. In all cases the layout (in registers/memory) is the same regardless of whether we have V1DFmode or the gcc_vector_f64x1 is just assigned BLKmode. (FWIW code generation is usually, tho not in all cases, better with V1DFmode.) Do you believe the ABI has changed, or are you merely concerned that it may have? Whilst I can never claim my checks have been exhaustive, at this point I don't see reason for concern.
[Bug target/59843] ICE with return of generic vector on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843
--- Comment #9 from Jakub Jelinek ---
I've been just concerned, many backends derive (perhaps incorrectly) passing
conventions from DECL_MODE or TYPE_MODE and so any changes in that are a red
flag to me.
If passing as arguments and returning the vectors sized the same as element
size always ICEd, then it is not an ABI issue, because any old program using
those wouldn't compile. Are the ICEs on both the caller and callee side
though?
I mean, which of these tests ICE?
test1.c:
typedef double V __attribute__ ((vector_size (8)));
V foo (void);
V x;
void bar (void)
{
x = foo ();
}
test2.c:
typedef double V __attribute__ ((vector_size (8)));
void foo (V);
V x;
void bar (void)
{
foo (x);
}
test3.c:
typedef double V __attribute__ ((vector_size (8)));
V x;
V foo (void)
{
return x;
}
test4.c:
typedef double V __attribute__ ((vector_size (8)));
V x;
void foo (V y)
{
x = y;
}
If not all 4 ICE, then perhaps one could compile with 4.9.0 objects containing
just the caller (or just the callee) and try to put it together with 4.9.1
built objects.
[Bug c++/61057] [C++11] operator . considered part of User Defined Literal invocation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61057 emsr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from emsr at gcc dot gnu.org --- As someone who has dabbled in Ruby I am sympathetic to the request to have this work. After looking at the standard language and our implementation I must conclude that your code is invalid. I then tried to imagine a way, for example, if the stuff after a dot could not be a mantissa stop processing chars at the dot so the remainder can become an invocation or access. Unfortunately, 123. is a valid double so this idea can't work even as an extension. FWIW, character and string user-defined literals can have invocations like "Hello, World!!!"s.length(). Perhaps two dots could signal a termination of a literal as was tried for '_' as digit separator. This would require much noodling by the standards folks though. I'll ponder this last idea but I'll mark this as resolved invalid.
[Bug c++/61057] [C++11] operator . considered part of User Defined Literal invocation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61057 --- Comment #3 from emsr at gcc dot gnu.org --- Leaving a space before the dot also works.
[Bug target/59843] ICE with return of generic vector on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 --- Comment #10 from Alan Lawrence --- I can confirm that prior to V1DFmode, all four of those cases gave an ICE (in emit_move_insn, via a variety of routes).
[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754 emsr at gcc dot gnu.org changed: What|Removed |Added CC||emsr at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |emsr at gcc dot gnu.org --- Comment #1 from emsr at gcc dot gnu.org --- This is not my reading of the standard- which isn't really clear on when a message is to be written. This issue is known.
[Bug c/61741] wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 Richard Biener changed: What|Removed |Added Component|lto |c Known to work||4.10.0 Known to fail||4.8.3, 4.9.1 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Jul 9 17:14:11 2014 New Revision: 212400 URL: https://gcc.gnu.org/viewcvs?rev=212400&root=gcc&view=rev Log: 2014-07-09 Richard Biener PR c-family/61741 * c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions using unsigned arithmetic if overflow does not wrap instead of if overflow is undefined. * c-c++-common/torture/pr61741.c: New testcase. Added: trunk/gcc/testsuite/c-c++-common/torture/pr61741.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-gimplify.c trunk/gcc/testsuite/ChangeLog --- Comment #6 from Richard Biener --- Fixed on trunk (sofar).
[Bug c/61741] wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 Richard Biener changed: What|Removed |Added Component|lto |c Known to work||4.10.0 Known to fail||4.8.3, 4.9.1 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Jul 9 17:14:11 2014 New Revision: 212400 URL: https://gcc.gnu.org/viewcvs?rev=212400&root=gcc&view=rev Log: 2014-07-09 Richard Biener PR c-family/61741 * c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions using unsigned arithmetic if overflow does not wrap instead of if overflow is undefined. * c-c++-common/torture/pr61741.c: New testcase. Added: trunk/gcc/testsuite/c-c++-common/torture/pr61741.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-gimplify.c trunk/gcc/testsuite/ChangeLog --- Comment #6 from Richard Biener --- Fixed on trunk (sofar).
[Bug c++/61760] New: -Wconversion inconsistency between gcc and g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61760
Bug ID: 61760
Summary: -Wconversion inconsistency between gcc and g++
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: js at alien8 dot de
Given the code:
unsigned char foo(unsigned char x)
{
return x >> 1;
}
If you compile this with 'gcc -Wconversion -c foo.c', there is no warning. If
you compile it with 'g++ -Wconversion -c foo.c' you get:
foo.c:3:11: warning: conversion to ‘unsigned char’ from ‘int’ may alter its
value [-Wconversion]
return x >> 1;
I would argue that the conversion warning is false in both cases, because there
is no information loss involved, even though the intermediate result is cast to
an int.
Is there a reason why g++ produces the warning here or is this a bug?
This happens using 4.8.3 and 4.9.1 20140706 (prerelease) on x86_64.
[Bug libstdc++/61761] New: [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761
Bug ID: 61761
Summary: [C++11] std::proj returns incorrect values
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
std::proj returns incorrect values if _GLIBCXX_USE_C99_COMPLEX is not defined.
For example, std::proj(std::complex(1, 2)) should be
std::complex(1, 2) but libstdc++ returns
std::complex(0.33,0.67).
If _GLIBCXX_USE_C99_COMPLEX is defined, the sample code below can show the
difference between a glibc version and a libstdc++ version.
sample source
#include
#include
#include
void check(const std::complex& c)
{
// libstdc++ version
std::complex r1 = std::__complex_proj(c);
std::cout << "libstdc++ version : proj( " << c << " ) = " << r1 << std::endl;
// glibc version
std::complex r2 = std::__complex_proj(c.__rep());
std::cout << "glibc version : proj( " << c << " ) = " << r2 << std::endl;
}
int main()
{
check(std::complex(1, 2));
check(std::complex(1, NAN));
}
sample output
libstdc++ version : proj( (1,2) ) = (0.33,0.67)
glibc version : proj( (1,2) ) = (1,2)
libstdc++ version : proj( (1,nan) ) = (nan,nan)
glibc version : proj( (1,nan) ) = (1,nan)
===
According to C99 standard 7.3.9.4 (referenced from C++11 standard 26.4.7
[complex.value.ops] paragraph 8), "z projects to z except that all complex
infinities (even those with one infinite part and one NaN part) project to
positive infinity on the real axis."
Note that the glibc version 2.11 or below had the same bug.
(For std::complex(1, NAN), the glibc version 2.18 or below had a
different bug.)
[Bug c++/61760] -Wconversion inconsistency between gcc and g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61760 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-09 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- The C FE produces: unit size align 32 symtab 0 alias set -1 canonical type 0x7740a690 precision 32 min max pointer_to_this > arg 0 unit size align 8 symtab 0 alias set -1 canonical type 0x7740a3f0 precision 8 min max > arg 0 used unsigned QI file /home/manuel/test.c line 1 col 33 size unit size align 8 context arg-type > arg 1 > /home/manuel/test.c:3:12> that is (int) (x >> 1). The C++ FE produces: unit size align 32 symtab 0 alias set -1 canonical type 0x7740a690 precision 32 min max pointer_to_this > arg 0 arg 0 used unsigned QI file /home/manuel/test.c line 1 col 33 size unit size align 8 context arg-type >> arg 1 constant 1> /home/manuel/test.c:3:12> that is (((int)x) >> 1) I am not sure which one is more correct, but the latter prevents unsafe_conversion_p from seeing that the implicit conversion cannot alter the value.
[Bug c++/61760] -Wconversion inconsistency between gcc and g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61760 --- Comment #2 from Manuel López-Ibáñez --- I see now that the C FE has a FE optimization (short_shift in build_binary_op) that the C++ FE doesn't have. The optimization is probably useless for code generation, but for improving -Wconversion, it would need to be moved to c-common.c and used in unsafe_conversion_p, like we do with shorten_binary_op. I don't have time to work on this, so any help is welcome.
[Bug middle-end/61762] New: failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
Bug ID: 61762
Summary: failure to optimize memcpy from constant string
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: froydnj at gcc dot gnu.org
There's probably a duplicate of this, but GCC HEAD on the following testcase:
unsigned int f()
{
static const char string[] = "Private";
unsigned int priv;
__builtin_memcpy(&priv, &string[0], sizeof(priv));
return priv;
}
produces for x86-64:
f:
.LFB0:
.cfi_startproc
movl_ZZ1fvE6string(%rip), %eax
ret
.cfi_endproc
Compare clang (~3.0) for x86-64:
f:
.Ltmp0:
.cfi_startproc
# BB#0:
movl$1986622032, %eax # imm = 0x76697250
ret
[Bug bootstrap/61763] New: [4.9 Regression] gcc-4.9.0 "Bootstrap comparison failure!"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763 Bug ID: 61763 Summary: [4.9 Regression] gcc-4.9.0 "Bootstrap comparison failure!" Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dougmencken at gmail dot com I tried to bootstrap gcc-4.9.0 release on OS X 10.5 (darwin9). My host compiler is currently gcc-4.8.3. That's what I've got: make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH" "TARGET_SUBDIR=powerpc-unknown-darwin" "bindir=/usr/bin" "datadir=/usr/share" "exec_prefix=/usr" "includedir=/usr/include" "datarootdir=/usr/share" "docdir=/usr/share/doc/" "infodir=/usr/share/info" "pdfdir=/usr/share/doc/" "htmldir=/usr/share/doc/" "libdir=/usr/lib" "libexecdir=/usr/libexec" "lispdir=" "localstatedir=/usr/var" "mandir=/usr/share/man" "oldincludedir=/usr/include" "prefix=/usr" "sbindir=/usr/sbin" "sharedstatedir=/usr/com" "sysconfdir=/etc" "tooldir=/usr/powerpc-unknown-darwin" "build_tooldir=/usr/powerpc-unknown-darwin" "target_alias=powerpc-unknown-darwin" "AWK=awk" "BISON=bison" "CC_FOR_BUILD=powerpc-unknown-darwin-gcc" "CFLAGS_FOR_BUILD=-O3" "CXX_FOR_BUILD=powerpc-unknown-darwin-g++" "EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS_FOR_BUILD=" "LEX=flex" "M4=gm4" "MAKE=make" "RUNTEST=runtest" "RUNTESTFLAGS=" "SED=/usr/bin/sed" "SHELL=/bin/sh" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "ADA_CFLAGS=" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=-gnatpg' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "BOOT_CFLAGS=-O3 -mdynamic-no-pic" "BOOT_LDFLAGS=" "CFLAGS=-O3" "CXXFLAGS=-O3" "LDFLAGS=" "LIBCFLAGS=-O3" "LIBCXXFLAGS=-O3 -fno-implicit-templates" "STAGE1_CHECKING=--enable-checking=yes" "STAGE1_LANGUAGES=c,c++" "GNATBIND=no" "GNATMAKE=no" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as" "CC_FOR_TARGET=/Volumes/hfsplushd/Development/gcc-toolchain/_gcc_build/./gcc/xgcc -B/Volumes/hfsplushd/Development/gcc-toolchain/_gcc_build/./gcc/" "CFLAGS_FOR_TARGET=-O3" "CPPFLAGS_FOR_TARGET=" "CXXFLAGS_FOR_TARGET=-O3" "DLLTOOL_FOR_TARGET=dlltool" "FLAGS_FOR_TARGET=-B/usr/powerpc-unknown-darwin/bin/ -B/usr/powerpc-unknown-darwin/lib/ -isystem /usr/powerpc-unknown-darwin/include -isystem /usr/powerpc-unknown-darwin/sys-include" "GCJ_FOR_TARGET=" "GFORTRAN_FOR_TARGET=" "GOC_FOR_TARGET=" "GOCFLAGS_FOR_TARGET=-O3" "LD_FOR_TARGET=ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-O3" "LIBCXXFLAGS_FOR_TARGET=-O3 -fno-implicit-templates" "NM_FOR_TARGET=nm" "OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_TARGET=ranlib" "READELF_FOR_TARGET=readelf" "STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" "WINDMC_FOR_TARGET=windmc" "BUILD_CONFIG=bootstrap-debug" "`echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "STAGE1_CFLAGS=-mdynamic-no-pic" "STAGE1_CXXFLAGS=-mdynamic-no-pic" "STAGE1_TFLAGS=" "STAGE2_CFLAGS=-O3 -mdynamic-no-pic -gtoggle" "STAGE2_CXXFLAGS=-O3 -mdynamic-no-pic -gtoggle" "STAGE2_TFLAGS=" "STAGE3_CFLAGS=-O3 -mdynamic-no-pic" "STAGE3_CXXFLAGS=-O3 -mdynamic-no-pic" "STAGE3_TFLAGS=" "STAGE4_CFLAGS=-O3 -mdynamic-no-pic" "STAGE4_CXXFLAGS=-O3 -mdynamic-no-pic" "STAGE4_TFLAGS=" "STAGEprofile_CFLAGS=-O3 -mdynamic-no-pic -gtoggle -fprofile-generate" "STAGEprofile_CXXFLAGS=-O3 -mdynamic-no-pic -gtoggle -fprofile-generate" "STAGEprofile_TFLAGS=" "STAGEfeedback_CFLAGS=-O3 -mdynamic-no-pic -fprofile-use" "STAGEfeedback_CXXFLAGS=-O3 -mdynamic-no-pic -fprofile-use" "STAGEfeedback_TFLAGS=" "CXX_FOR_TARGET= $r/./gcc/xg++ -B$r/./gcc/ -nostdinc++ `if test -f $r/powerpc-unknown-darwin/libstdc++-v3/scripts/testsuite_flags; then /bin/sh $r/powerpc-unknown-darwin/libstdc++-v3/scripts/testsuite_flags --build-includes; else echo -funconfigured-libstdc++-v3 ; fi` -L$r/powerpc-unknown-darwin/libstdc++-v3/src -L$r/powerpc-unknown-darwin/libstdc++-v3/src/.libs -L$r/powerpc-unknown-darwin/libstdc++-v3/libsupc++/.libs" "TFLAGS=" "CONFIG_SHELL=/bin/sh" "MAKEINFO=makeinfo --split-size=500 --split-size=500" compare rm -f stage_current Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/tree-loop-distribution.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2 gcc-4.8.3 bootstraps perfectly (both with -O2 and -O3) on my side.
[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59800 --- Comment #3 from Matteo Riondato --- What exactly does the "WAITING" status mean?
[Bug bootstrap/61764] New: gcc fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61764 Bug ID: 61764 Summary: gcc fails to build Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: us15 at os dot inf.tu-dresden.de Created attachment 33096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33096&action=edit Full build log The build process fails at this point: echo timestamp > s-options-h /gcc-631efe2fd9a431796b41b24641a87a15/gcc.build.lnx/./prev-gcc/xg++ -B/gcc-631efe2fd9a431796b41b24641a87a15/gcc.build.lnx/./prev-gcc/ -B/usr/x86_64-slackware-linux/bin/ build/genmddeps.o build/read-md.o build/errors.o .././libiberty/libiberty.a /gcc-631efe2fd9a431796b41b24641a87a15/gcc.build.lnx/./prev-gcc/xg++ -B/gcc-631efe2fd9a431796b41b24641a87a15/gcc.build.lnx/./prev-gcc/ -B/usr/x86_64-slackware-linux/bin/ build/genmodes.o build/errors.o .././libiberty/libiberty.a build/gengenrtl > tmp-genrtl.h /bin/sh ../../gcc-4.10.0/gcc/../move-if-change tmp-genrtl.h genrtl.h echo timestamp > s-genrtl-h build/genmodes -m > tmp-min-modes.c build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be set build/genmodes: config/i386/i386-modes.def:24: (XF) field format must not be set build/genmodes: machmode.def:203: (DF) field format must not be set build/genmodes: machmode.def:202: (SF) field format must not be set build/genmodes: machmode.def:244: (TD) field format must not be set build/genmodes: machmode.def:243: (DD) field format must not be set build/genmodes: machmode.def:242: (SD) field format must not be set make[3]: *** [s-modes-m] Error 1 make[3]: *** Waiting for unfinished jobs
[Bug bootstrap/61764] gcc fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61764 --- Comment #1 from Udo Steinberg --- This is with SVN version 212406.
[Bug bootstrap/61764] gcc fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61764 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- Duplicate of pr61757. *** This bug has been marked as a duplicate of bug 61757 ***
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Dominique d'Humieres changed: What|Removed |Added CC||us15 at os dot inf.tu-dresden.de --- Comment #5 from Dominique d'Humieres --- *** Bug 61764 has been marked as a duplicate of this bug. ***
[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59800 Manuel López-Ibáñez changed: What|Removed |Added Status|WAITING |NEW CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez --- The meaning is explained here: https://gcc.gnu.org/bugs/management.html but I think it was a slip in this case. Probably the uninit pass is not powerful enough, but in this case the warning should be suppressed for system-headers: manuel@gcc10:~$ ~/test1/210581/install/bin/g++ -std=c++11 -O2 -Wsystem-headers -Wmaybe-uninitialized test.cc In file included from /home/manuel/test1/210581/install/include/c++/4.10.0/random:51:0, from test.cc:3: /home/manuel/test1/210581/install/include/c++/4.10.0/bits/random.tcc: In function ‘int main(int, char**)’: /home/manuel/test1/210581/install/include/c++/4.10.0/bits/random.tcc:1964:2: warning: ‘*((void*)(& my_lognormal)+16).std::normal_distribution::_M_saved’ may be used uninitialized in this function [-Wmaybe-uninitialized] __ret = __ret * __param.stddev() + __param.mean(); ^ test.cc:11:33: note: ‘*((void*)(& my_lognormal)+16).std::normal_distribution::_M_saved’ was declared here lognormal_distribution my_lognormal(0.0, 1.0); ^ and -flto bypassed the system_header pragma somehow.
[Bug c++/46097] Switch to warn of global variables in a C++ shared object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 Phil Miller changed: What|Removed |Added CC||unmobile at gmail dot com --- Comment #32 from Phil Miller --- A switch to generate warnings about global variables would be useful to me and my colleagues (http://ppl.cs.illinois.edu/) for a reason totally distinct from ODR violations. We have a parallel programming system that includes a feature for running application code in multiple, nominally independent, user-level threads within a process. A mechanism to call attention to code that may fail or misbehave in this setting would be helpful. I would definitely agree that this doesn't belong in -Wall or -Wextra, as such. So a -fnote-global-variables might be more appropriate.
[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jul 9 21:23:06 2014 New Revision: 212410 URL: https://gcc.gnu.org/viewcvs?rev=212410&root=gcc&view=rev Log: /cp 2014-07-09 Paolo Carlini DR 1584 PR c++/57466 * pt.c (check_cv_quals_for_unify): Implement resolution, disregard cv-qualifiers of function types. /testsuite 2014-07-09 Paolo Carlini DR 1584 PR c++/57466 * g++.dg/template/pr57466.C: New. * g++.dg/cpp0x/pr57466.C: Likewise. * g++.dg/template/unify6.C: Update. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr57466.C trunk/gcc/testsuite/g++.dg/template/pr57466.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/unify6.C
[Bug libstdc++/57465] Failed postcondition for std::function constructed with null function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57465 Bug 57465 depends on bug 57466, which changed state. Bug 57466 Summary: [DR 1584] Argument deduction fails for 'const T*' when T is function type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #5 from Paolo Carlini --- Fixed for 4.10.
[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743 --- Comment #2 from Phil Miller --- I just went to look at this in more detail, and I'm not sure how to interpret what I've found. If the DR in question in 225 (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#225), following from 197, that seems to suggest that the other compilers *shouldn't* be be treating int as if it were associated with the global namespace, since the standards committee said the lack of associated namespace is Not A Defect. Does the committee need another nudge on this point, as practice has shifted? As a user, I'd much prefer if fundamental types were not special-cased in this setting, with the standard blessing what Clang, IBM, Intel, and PGI have done, and GCC, Microsoft, and Cray adopting that approach.
[Bug libstdc++/61728] [4.10 regression] lost symbol FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj@@CXXABI_1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61728 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/61728] [4.10 regression] lost symbol FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj@@CXXABI_1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61728 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Jul 9 22:21:49 2014 New Revision: 212413 URL: https://gcc.gnu.org/viewcvs?rev=212413&root=gcc&view=rev Log: PR libstdc++/61728 * libsupc++/cxxabi.h: Define __pbase_type_info::__pointer_catch here. * libsupc++/tinfo.h: Not here. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/cxxabi.h trunk/libstdc++-v3/libsupc++/tinfo.h
[Bug libstdc++/61728] [4.10 regression] lost symbol FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj@@CXXABI_1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61728 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743 --- Comment #3 from Phil Miller --- The latest release of Microsoft Visual C++ (per the version available at http://rise4fun.com/Vcpp) now accepts this code without complaint. Cray compilers version 8.2 and onwards also accept this code. As of my tests against the GCC 4.9.0 release, that seems to leave g++ all alone (among the myriad compilers I have access to) in not accepting this code.
[Bug fortran/61765] New: Rejects valid BIND(C) ENTRY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61765 Bug ID: 61765 Summary: Rejects valid BIND(C) ENTRY Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org gfortran 4.9 and 4.10 reject the code below with: subroutine sub(x) integer, intent(in) :: x entry sub_c(x) bind(c) end subroutine sub a.f90:3.16-16: entry sub_c(x) bind(c) 12 Error: Procedure sub_c with binding label sub_c at (1) uses the same global identifier as entity at (2) As far as I can tell, this code is standard-conforming (related to non-legal code from PR 35031). It should be accepted.
[Bug fortran/61765] Rejects valid BIND(C) ENTRY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61765 Francois-Xavier Coudert changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-09 Blocks||32630 Ever confirmed|0 |1
[Bug fortran/35031] ELEMENTAL procedure with BIND(C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35031 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert --- That code is now rejected (for a wrong reason), due to PR61765.
[Bug c++/56908] Spurious warning when XOR-ing uint8_t values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56908 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-09 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- Confirmed, perhaps a regression. More analysis here: https://gcc.gnu.org/ml/gcc-help/2014-07/msg00042.html
[Bug c++/60686] message " only declarations of constructors can be ‘explicit’ " now conflicting with C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60686 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jul 9 22:44:42 2014 New Revision: 212415 URL: https://gcc.gnu.org/viewcvs?rev=212415&root=gcc&view=rev Log: /cp 2014-07-09 Paolo Carlini PR c++/60686 * decl.c (grokdeclarator): Adjust error messages about 'explicit' outside class declaration, in friend declaration, and neither on constructor nor conversion operator. /testsuite 2014-07-09 Paolo Carlini PR c++/60686 * g++.dg/cpp0x/explicit8.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/explicit8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60686] message " only declarations of constructors can be ‘explicit’ " now conflicting with C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60686 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #4 from Paolo Carlini --- Fixed for 4.10.
[Bug fortran/61765] [4.9/4.10 Regression] Rejects valid BIND(C) ENTRY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61765 Dominique d'Humieres changed: What|Removed |Added Summary|Rejects valid BIND(C) ENTRY |[4.9/4.10 Regression] ||Rejects valid BIND(C) ENTRY --- Comment #1 from Dominique d'Humieres --- The code is accepted up to r199034 (2013-05-17) and rejected after r199221 (2013-05-22). Likely r199118, r199119, or r199120 (pr 48858).
[Bug fortran/61766] New: [4.9 regression] ICE on trans-array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61766 Bug ID: 61766 Summary: [4.9 regression] ICE on trans-array.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de The following code triggers an ICE with 4.9.0 but seems to work with 4.7.X, 4.8.X, and 4.10: gfortran -c prc_gosam.f90 prc_gosam.f90: In function ‘__final_prc_gosam_Gosam_writer_t’: prc_gosam.f90:62:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:145 end module prc_gosam ^ prc_gosam.f90:62:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) The code is (with the standard iso_varying_string.f90): 1module prclib_interfaces 2 use iso_varying_string, string_t => varying_string !NODEP! 3 implicit none 4 private 5 public :: prc_writer_f_module_t 6 7 type, abstract :: prc_writer_t 8 contains 9 procedure(get_const_string), nopass, deferred :: type_name 10 end type prc_writer_t 11 12 type, extends (prc_writer_t), abstract :: prc_writer_f_module_t 13 end type prc_writer_f_module_t 14 15 abstract interface 16 function get_const_string () result (string) 17 import 18 type(string_t) :: string 19 end function get_const_string 20 end interface 21 22end module prclib_interfaces 23 24! 25 26module blha_config 27 use iso_varying_string, string_t => varying_string !NODEP! 28 implicit none 29 private 30 public :: blha_configuration_t 31 type :: blha_configuration_t 32 type(string_t), dimension (2) :: matrix_element_square_type_other 33 end type blha_configuration_t 34end module blha_config 35 36! 37 38module prc_gosam 39 use iso_varying_string, string_t => varying_string !NODEP! 40 use prclib_interfaces 41 use blha_config 42 implicit none 43 private 44 type, extends (prc_writer_f_module_t) :: gosam_writer_t 45type(blha_configuration_t) :: blha_cfg 46 contains 47procedure, nopass :: type_name => gosam_writer_type_name 48 end type gosam_writer_t 49 50contains 51 52 function gosam_writer_type_name () result (string) 53type(string_t) :: string 54string = "gosam" 55 end function gosam_writer_type_name 56 57 function gosam_writer_get_process_string (writer) result (s_proc) 58class(gosam_writer_t), intent(in) :: writer 59type(string_t) :: s_proc 60 end function gosam_writer_get_process_string 61 62end module prc_gosam
[Bug fortran/61766] [4.9 regression] ICE on trans-array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61766 --- Comment #1 from Jürgen Reuter --- Created attachment 33097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33097&action=edit Code that triggers the ICE
[Bug c++/46097] Switch to warn of global variables in a C++ shared object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 --- Comment #33 from Jonathan Wakely --- Write a plugin. It's trivial using gcc-python-plugin, see http://blog.cuviper.com/2014/01/23/add-new-warnings-to-gcc-with-python/ A custom plugin is far more suitable to your purpose than adding yet another option to GCC that has to be maintained and tested forever when most people aren't interested in it.
[Bug fortran/56789] Wrong code with contiguous dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Sean Santos changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #3 from Sean Santos --- I just want to note that I've encountered this in the wild using GCC 4.8. As you would guess, the strides are not necessary; any argument that has to be packed will cause a segfault when freeing the temporary, such as: call foo(a(:4,:))
[Bug fortran/56789] Wrong code with contiguous dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 --- Comment #4 from Sean Santos --- Oops, I mean a free() error as in comment 0, not a segfault.
[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743 --- Comment #4 from Jonathan Wakely --- (In reply to Phil Miller from comment #2) > Does the committee need another nudge on this point, as practice has shifted? I don't believe practice has shifted. The difference in GCC's behaviour is probably just a bug related to friend functions not a different interpretation of ADL for fundamental types.
[Bug fortran/61767] New: ICE in generate_finalization_wrapper at fortran/class.c:1491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61767 Bug ID: 61767 Summary: ICE in generate_finalization_wrapper at fortran/class.c:1491 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: reubendb at gmail dot com Hello, My code generates ICE with gfortran from trunk. I've tried to reduce it as much as possible. Here's the backtrace: ]$ gfortran -c Communicator_Form.f90 ]$ gfortran -c Message_Template.f90 f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1492 0x5578f3 generate_finalization_wrapper ../../gcc_trunk/gcc/fortran/class.c:1491 0x5578f3 gfc_find_derived_vtab(gfc_symbol*) ../../gcc_trunk/gcc/fortran/class.c:2326 0x5d1c74 resolve_fl_derived ../../gcc_trunk/gcc/fortran/resolve.c:12718 0x5cc807 resolve_symbol ../../gcc_trunk/gcc/fortran/resolve.c:12995 0x5e3b3b do_traverse_symtree ../../gcc_trunk/gcc/fortran/symbol.c:3630 0x5cf92c resolve_types ../../gcc_trunk/gcc/fortran/resolve.c:14739 0x5cb640 gfc_resolve(gfc_namespace*) ../../gcc_trunk/gcc/fortran/resolve.c:14840 0x5b6c26 gfc_parse_file() ../../gcc_trunk/gcc/fortran/parse.c:5083 0x5f57d5 gfc_be_parse_file ../../gcc_trunk/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. ]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc/4.10/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc/4.10 --enable-languages=c,fortran,c++ --disable-multilib Thread model: posix gcc version 4.10.0 20140709 (experimental) (GCC) "svn info" of the gcc source code shows Revision 212004. The two source code that can be used to reproduce this issue are as follow: ]$ cat Communicator_Form.f90 module Communicator_Form implicit none private type, public :: CommunicatorForm contains final :: & Finalize end type CommunicatorForm contains subroutine Finalize ( C ) type ( CommunicatorForm ), intent ( inout ) :: & C end subroutine Finalize end module Communicator_Form ]$ cat Message_Template.f90 module Message_Template use Communicator_Form implicit none private type, public, abstract :: MessageTemplate type ( CommunicatorForm ), pointer :: & Communicator => null ( ) end type MessageTemplate contains subroutine InitializeTemplate ( M ) class ( MessageTemplate ), intent ( inout ), target :: & M end subroutine InitializeTemplate end module Message_Template Thank you for looking into this.
[Bug fortran/61767] ICE in generate_finalization_wrapper at fortran/class.c:1491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61767 Reuben Budiardja changed: What|Removed |Added Severity|critical|normal
[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330
--- Comment #5 from wangzheyu ---
(In reply to Richard Biener from comment #1)
> Seems the parser fails to set DECL_HARD_REGISTER on that bogus decl.
Hi Richard,
I find that in function make_decl_rtl(gcc/varasm.c:1357), there's one line
comment:
/* As a register variable, it has no section. */
And for the correct reigster type declaration like: register int *a asm(“r1”),
the program will just directly return(gcc/varasm.c:1358), and won't sink into
the symbol ref generation part. So symtab_get_node won't be called.
It seems to be a long time for the invalid register type declaration to be sink
into the symbol ref generation part of function make_decl_rtl, which will also
lead to wrong rtx generation.
register int *a asm("r1")=>(reg:SI 1 r1 [orig:0 a] [0])
register int *a asm("unknown register")=>(symbol_ref:SI ("unknown register")
[flag 0x80])
