[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #6 from weiguo.zhou weiguo.zhou at spreadtrum dot com --- (In reply to Dmitry Vyukov from comment #4) Yes, asan should work on android/arm32. There is some ongoing work on arm64. +eugeni can provide more details. according to official documents on Google's site: https://code.google.com/p/address-sanitizer/wiki/Android Android How to use AddressSanitizer on Android Updated Jul 20, 2015 by euge...@google.com NOTE: this document is about running Android applications built with the NDK under AddressSanitizer. For information about using AddressSanitizer on Android platform components, see AndroidPlatform. NOTE: ASan is broken on Android L. Use a K* build. This will be fixed in one of the future L updates (or the current AOSP master branch). NOTE: AddressSanitizer on Android requires a rooted device (either -eng or -userdebug build, or any other setup that allows editing the contents of the /system partition). Android NDK supports AddressSanitizer on arm, armv7 and x86 ABIs starting with version r10d. It seems Google's official docs indicate the asan only supported on Android with LLVM-based clang toolchain. in the fact, it should be supported well on Android with gcc-based toolchain. the keypoint to enable asan running well with gcc-based toolchain on Android as following: 1)build a cross-compile toolchain for ARM-32 Android system; 2)disable -Os optimization options in Android build system; becase the asan pass must be called in the GCC's internal to handle GENERIC/GIMPLY transformation; 3)modify the code in the gcc-4.9.2/config/arm/arm.c
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #22 from Filipe Brandenburger filbranden at google dot com --- (In reply to Jan Engelhardt from comment #20) Seems like the short route is to add a new attribute ((warn_unused_result_with_void_cancelling)) that exhibits the desired behavior of (void) cancelling the warning, and then make glibc use that. Simple, no? I'd rather see ((warn_unused_result_without_void_cancelling)). Or, better yet, add both in and add a command-line flag to allow ((warn_unused_result)) to use one or the other. I still don't see the point of preventing (void) from cancelling it since you can just store the result on an otherwise unused discard variable, I mean, if the programmer *really* wants to ignore the result, they can do it in many ways, ((warn_unused_result)) is to prevent programming mistakes where the programmer *meant* to look at the results but mistakenly forgot it... I also fail to see what else a void cast can mean other than explicitly indicating that the programmer *knows* the function returns a non-empty value but decided to ignore it... Anyways, let's not go on that rant again... If you get to implement the new attribute that would be awesome! Cheers, Filipe
[Bug sanitizer/67286] New: asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286
Bug ID: 67286
Summary: asan doen't work on Android(32bit ARM)
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: zhouweiguo2008 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
cat invalid-free.cc
// RUN: %clangxx_asan -O0 %s -o %t
// RUN: not %run %t 21 | FileCheck %s --check-prefix=CHECK
--check-prefix=MALLOC-CTX
// Also works if no malloc context is available.
// RUN: env ASAN_OPTIONS=malloc_context_size=0:fast_unwind_on_malloc=0 not %run
%t 21 | FileCheck %s
// RUN: env ASAN_OPTIONS=malloc_context_size=0:fast_unwind_on_malloc=1 not %run
%t 21 | FileCheck %s
// XFAIL: arm-linux-gnueabi
#include stdlib.h
#include string.h
int main(int argc, char **argv) {
char *x = (char*)malloc(10 * sizeof(char));
memset(x, 0, 10);
int res = x[argc];
free(x + 5); // BOOM
// CHECK: AddressSanitizer: attempting free on address{{.*}}in thread T0
// CHECK: invalid-free.cc:[[@LINE-2]]
// CHECK: is located 5 bytes inside of 10-byte region
// CHECK: allocated by thread T0 here:
// MALLOC-CTX: invalid-free.cc:[[@LINE-8]]
return res;
}
when running above testcase (could be found at
external/compiler-rt/test/asan/TestCases)on Android5.0 phone,
the testcase will SEGV as following(in the fact, all testcases would be SEGV on
android phone):
[1m[31m==3909==ERROR: AddressSanitizer: SEGV on unknown address 0x369a00fe
(pc 0xb6f51662 bp 0xbeb58a1c sp 0xbeb589e0 T0)
[1m[0m#0 0xb6f51661 in main TestCases/invalid-free.cc:14
#1 0xb69c0e09 (/system/lib/libc.so+0x12e09)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV TestCases/invalid-free.cc:14 main
==3909==ABORTING
the root cause is that when using Asan on 32-bit ARM android system, the shadow
offset should be zero, not 0x2000(129).
this serious bug could be fixed according to following steps:
modify function
static unsigned HOST_WIDE_INT arm_asan_shadow_offset(void)
in the gcc-4.9.2/config/arm/arm.c
from
static unsigned HOST_WIDE_INT
arm_asan_shadow_offset (void)
{
return (unsigned HOST_WIDE_INT) 1 29;
}
to
static unsigned HOST_WIDE_INT
arm_asan_shadow_offset (void)
{
#ifdef TARGET_ANDROID
return 0;
#else
return (unsigned HOST_WIDE_INT) 1 29;
#endif
}
[Bug libstdc++/63176] std::generate_canonicalfloat, std::numeric_limitsfloat::digits() generates 1.0f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63176 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-20 CC||redi at gcc dot gnu.org, ||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #13 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 36225 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36225action=edit Diff of the disassembly of the stripped versions of cfteexpr.dmd.o for stage 2 and 3
[Bug middle-end/67285] ICE with (rdiv (POW:s @0 REAL_CST@1) @0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67285 --- Comment #2 from hs.naveen2u at gmail dot com --- Created attachment 36226 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36226action=edit Testcase to reproduce the issue aarch64-thunder-elf-gcc pr67285.c -O2 -funsafe-math-optimizations
[Bug rtl-optimization/49054] useless cmp+jmp generated for switch when default: is unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054 Johannes Pfau johannespfau at gmail dot com changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #5 from Johannes Pfau johannespfau at gmail dot com --- This would also be useful for the GDC frontend. There's a `final switch` statement which forces the developer to handle all possible cases. Would be nice if we could get rid of the `cmp` check for these `final switch` statements.
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #11 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 36223 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36223action=edit Stage 2 compiled version of ctfeexpr.dmd.o (unstripped)
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #12 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 36224 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36224action=edit Stage 3 compiled version of ctfeexpr.dmd.o (unstripped)
[Bug tree-optimization/67287] New: FRE should CSE sqrt() calls even with -ferrno-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67287
Bug ID: 67287
Summary: FRE should CSE sqrt() calls even with -ferrno-math
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
double sqrt(double x);
double t (double x)
{
double a = sqrt (x);
double b = sqrt (x);
return a * b;
}
should be optimized to
double t (double x)
{
double a = sqrt (x);
return a * a;
}
with -fmath-errno. FRE currently gives up too early and the alias oracle
can handle errno-style references (but it can't use a call as a ref, so
the errno-only side-effect has to be modeled by creating a special ref
for performing the walking for math builtins setting errno as their only
side-effect).
We may not miscompile
sqrt (x);
errno = 0;
sqrt (x);
if (errno != 0)
...
to CSE the second sqrt.
[Bug tree-optimization/67287] FRE should CSE sqrt() calls even with -ferrno-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67287 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-20 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #8 from weiguo.zhou weiguo.zhou at spreadtrum dot com --- (In reply to Yury Gribov from comment #5) (In reply to Dmitry Vyukov from comment #4) +eugeni can provide more details. Please! E.g. how do you build compiler and runtime? the keypoint to generate a gcc-based cross-compiler toolchain for android/arm32 as following: 1) generate an stage-1 cross-compile gcc toolchain with the existing native gcc; 2) build the sysroot from scratch with the stage-1 cross-compile toolchain; 3) generate the final cross-compile gcc_toolchain with the corresponding sysroot. you can see the keypoint is that we should create a right sysroot for the final cross-compile gcc-toolchain for android/arm32.
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #11 from weiguo.zhou weiguo.zhou at spreadtrum dot com --- you can got the dynamic libasan.so.2 with following step: ../gcc-4.9.2-sprd/libsanitizer/configure --host=arm-linux-androideabi --prefix=/tmp/toolchain-build-linux-4.9.2/prefix --enabl e-shared --disable-static
[Bug target/67143] [5/6 Regression] ICE (could not split insn) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67143 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-20 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed.
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279 --- Comment #6 from Vittorio Zecca zeccav at gmail dot com --- On my side it has to do with the C standard. Compilation with -ansi or -std=c90 is successful. Compilation with -std=c99 fails. Compiling with g++ is OK. The behaviour I would like to see is a warning at compile time and a runtime error: message at run time.
[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #59 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to John Paul Adrian Glaubitz from comment #58) Oh, and according to the Debian changelog, it must be a regression that was introduced somewhere between r218987 and r222750 of the gcc-4.9 branch. Please ignore this comment! This was supposed to go into PR/target 66312! The bug tracker just hopped to the next PR with me noticing, sorry!
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #15 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Oh, and according to the Debian changelog, it must be a regression that was introduced somewhere between r218987 and r222750 of the gcc-4.9 branch. Currently, the buildds did not build any snapshot version between those two revisions unfortunately, but I can just do more test builds to narrow down the revision range where we need to look for the change that introduced the regression. Adrian
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #5 from Yury Gribov y.gribov at samsung dot com --- (In reply to Dmitry Vyukov from comment #4) +eugeni can provide more details. Please! E.g. how do you build compiler and runtime?
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #9 from weiguo.zhou weiguo.zhou at spreadtrum dot com --- (In reply to Yury Gribov from comment #7) (In reply to weiguo.zhou from comment #6) It seems Google's official docs indicate the asan only supported on Android with LLVM-based clang toolchain. That was my impression as well. in the fact, it should be supported well on Android with gcc-based toolchain. I'm not sure what you mean. Is ASan runtime (libasan.so) built when you build Android cross-compiler? If it's not, then ASan is not supported by GCC on Android. as I explained just now, after generate the final cross-compile toolchain for android/arm32 successfully, the last step is generate the libasasn.so.2 with the final cross-compile toolchain(because the runtime detection asan library should be running on real ARM32 board).
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #10 from Yury Gribov y.gribov at samsung dot com --- (In reply to weiguo.zhou from comment #9) as I explained just now, after generate the final cross-compile toolchain for android/arm32 successfully, the last step is generate the libasasn.so.2 How do you generate libasan.so?
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #1 from zhouweiguo2008 at gmail dot com --- this bug had been fixed and validated with gcc 4.9.2 and gcc 5.2.0. and the testcases (from external/compiler-rt/test/asan/TestCases) could be running normally on the 32-bit Android 5.0 phone.
[Bug target/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-20 CC||cbaylis at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |cbaylis at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from cbaylis at gcc dot gnu.org --- I will have a look at this.
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, I think I'll change this.
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #7 from Yury Gribov y.gribov at samsung dot com --- (In reply to weiguo.zhou from comment #6) It seems Google's official docs indicate the asan only supported on Android with LLVM-based clang toolchain. That was my impression as well. in the fact, it should be supported well on Android with gcc-based toolchain. I'm not sure what you mean. Is ASan runtime (libasan.so) built when you build Android cross-compiler? If it's not, then ASan is not supported by GCC on Android.
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Does GCC even support ASan on Android i.e. builds libasan.so? That's news to me.
[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #58 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Oh, and according to the Debian changelog, it must be a regression that was introduced somewhere between r218987 and r222750 of the gcc-4.9 branch. Currently, the buildds did not build any snapshot version between those two revisions unfortunately, but I can just do more test builds to narrow down the revision range where we need to look for the change that introduced the regression. Adrian
[Bug middle-end/67285] ICE with (rdiv (POW:s @0 REAL_CST@1) @0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67285 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Testcase?
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #4 from Dmitry Vyukov dvyukov at google dot com --- Yes, asan should work on android/arm32. There is some ongoing work on arm64. +eugeni can provide more details.
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 weiguo.zhou zhouweiguo2008 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from weiguo.zhou zhouweiguo2008 at gmail dot com --- validated with gcc 4.9.2 and gcc 5.2.0. and the testcases (from external/compiler-rt/test/asan/TestCases) could be running normally on the 32-bit Android 5.0 phone.
[Bug regression/67288] New: [4.9 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
Bug ID: 67288
Summary: [4.9 regression] non optimal simple function (useless
additional shift/remove/shift/add)
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: christophe.le...@c-s.fr
Target Milestone: ---
The following function (Linux Kernel, compiled with -O2) was resulting in a
good assembly with GCC 4.8.3. With GCC 4.9.3 there are a lot of unneccessary
instructions
/* L1_CACHE_BYTES = 16 */
/* L1_CACHE_SHIFT = 4 */
#define mb() __asm__ __volatile__ (sync : : : memory)
static inline void dcbf(void *addr)
{
__asm__ __volatile__ (dcbf 0, %0 : : r(addr) : memory);
}
void flush_dcache_range(unsigned long start, unsigned long stop)
{
void *addr = (void *)(start ~(L1_CACHE_BYTES - 1));
unsigned int size = stop - (unsigned long)addr + (L1_CACHE_BYTES - 1);
unsigned int i;
for (i = 0; i size L1_CACHE_SHIFT; i++, addr += L1_CACHE_BYTES)
dcbf(addr);
if (i)
mb();
}
Result with GCC 4.9.3: (15 insns)
c000d970 flush_dcache_range:
c000d970: 54 63 00 36 rlwinm r3,r3,0,0,27
c000d974: 38 84 00 0f addir4,r4,15
c000d978: 7c 83 20 50 subfr4,r3,r4
c000d97c: 54 89 e1 3f rlwinm. r9,r4,28,4,31
c000d980: 4d 82 00 20 beqlr
c000d984: 55 24 20 36 rlwinm r4,r9,4,0,27
c000d988: 39 24 ff f0 addir9,r4,-16
c000d98c: 55 29 e1 3e rlwinm r9,r9,28,4,31
c000d990: 39 29 00 01 addir9,r9,1
c000d994: 7d 29 03 a6 mtctr r9
c000d998: 7c 00 18 ac dcbf0,r3
c000d99c: 38 63 00 10 addir3,r3,16
c000d9a0: 42 00 ff f8 bdnzc000d998 flush_dcache_range+0x28
c000d9a4: 7c 00 04 ac sync
c000d9a8: 4e 80 00 20 blr
The following section is just useless: (shift left 4 bits, remove 16, shift
right 4 bits, add 1)
c000d984: 55 24 20 36 rlwinm r4,r9,4,0,27
c000d988: 39 24 ff f0 addir9,r4,-16
c000d98c: 55 29 e1 3e rlwinm r9,r9,28,4,31
c000d990: 39 29 00 01 addir9,r9,1
Result with GCC 4.8.3 was correct: (11 insns)
c000d894 flush_dcache_range:
c000d894: 54 63 00 36 rlwinm r3,r3,0,0,27
c000d898: 38 84 00 0f addir4,r4,15
c000d89c: 7d 23 20 50 subfr9,r3,r4
c000d8a0: 55 29 e1 3f rlwinm. r9,r9,28,4,31
c000d8a4: 4d 82 00 20 beqlr
c000d8a8: 7d 29 03 a6 mtctr r9
c000d8ac: 7c 00 18 ac dcbf0,r3
c000d8b0: 38 63 00 10 addir3,r3,16
c000d8b4: 42 00 ff f8 bdnzc000d8ac flush_dcache_range+0x18
c000d8b8: 7c 00 04 ac sync
c000d8bc: 4e 80 00 20 blr
[Bug driver/67301] New: Unable to compile program using extended assembly and asmSymbolicName
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67301
Bug ID: 67301
Summary: Unable to compile program using extended assembly and
asmSymbolicName
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
The following program:
$ cat test.cxx
int main(int argc, char* argv[])
{
__asm__ __volatile__ (
\t movl %[__ARGC], %%eax \n
:
: __ARGC (argc)
);
return 0;
}
Results in a failed compile:
$ g++ test.cxx
test.cxx: In function ‘int main(int, char**)’:
test.cxx:7:5: error: expected string-literal before ‘__ARGC’
: __ARGC (argc)
^
test.cxx:7:5: error: expected ‘(’ before ‘__ARGC’
test.cxx:7:5: error: ‘__ARGC’ was not declared in this scope
test.cxx:7:12: error: expected ‘)’ before string constant
: __ARGC (argc)
^
test.cxx:7:12: error: expected ‘)’ before string constant
Above, I am trying to use GCC's extended ASM like Microsoft's MASM.
According to the online manual and Assembler Instructions with C Expression
Operands, § 6.44.3.1 Input Operands
(https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html), asmSymbolicName is
being used correctly.
Operands are separated by commas. Each operand has this format:
[ [asmSymbolicName] ] constraint (cexpression)
asmSymbolicName
Specifies a symbolic name for the operand. Reference the name in the
assembler template by enclosing it in square brackets (i.e. ‘%[Value]’).
The scope of the name is the asm statement that contains the definition.
Any valid C variable name is acceptable, including names already defined
in the surrounding code.
[Bug driver/67301] Unable to compile program using extended assembly and asmSymbolicName
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67301
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
Try:
int main(int argc, char* argv[])
{
__asm__ __volatile__ (
\t movl %[__ARGC], %%eax \n
:
: [__ARGC] r (argc)
);
return 0;
}
Basically the syntax for naming operands is [XYZ] but since it is optional, [
is used to say it is optional part of the syntax. Yes it is slightly confusing
but that is what you get when you use [] as both part of the actual syntax and
saying it is an optional part.
[Bug tree-optimization/67284] libgo fails to build on trunk r227015 / *-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67284
Mikhail Maltsev miyuki at gcc dot gnu.org changed:
What|Removed |Added
Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu,
||x64_64-pc-linux-gnu
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-21
CC||miyuki at gcc dot gnu.org
Component|go |tree-optimization
Assignee|ian at airs dot com|unassigned at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org ---
Reduced testcase:
$ cat test.go
package a
type Decoder struct {
wireType map[int32]*int32
}
func (Decoder) ignoreMap(keyOp, elemOp func())
var decIgnoreOpMap map[int32]func()
func (dec Decoder) decIgnoreOpFor(wireId int32) func() {
var op func()
wire := dec.wireType
if wire != nil {
keyId := *dec.wireType[wireId]
elemId := *dec.wireType[wireId]
keyOp := dec.decIgnoreOpFor(keyId)
elemOp := dec.decIgnoreOpFor(elemId)
op = func() {
dec.ignoreMap(keyOp, elemOp)
}
}
return op
}
$ ./go1 -O2 test.go
test.go: In function 'a.decIgnoreOpFor.N12_go.a.Decoder':
test.go:11:1: internal compiler error: in operator[], at vec.h:714
func (dec Decoder) decIgnoreOpFor(wireId int32) func() {
^
0x85bcee vecedge_def*, va_gc, vl_embed::operator[](unsigned int)
/home/miyuki/gcc/src/gcc/vec.h:714
[Bug c++/67065] [DR 1886] Missing diagnostics for ill-formed program with main variable instead of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Aug 20 10:18:03 2015 New Revision: 227027 URL: https://gcc.gnu.org/viewcvs?rev=227027root=gccview=rev Log: /cp 2015-08-20 Paolo Carlini paolo.carl...@oracle.com PR c++/67065 * decl.c (grokvardecl): Reject 'main' as global variable. /testsuite 2015-08-20 Paolo Carlini paolo.carl...@oracle.com PR c++/67065 * g++.dg/other/pr67065.C: New. Added: trunk/gcc/testsuite/g++.dg/other/pr67065.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #10 from Sujoy ssaraswati at gmail dot com --- (In reply to jos...@codesourcery.com from comment #9) There is no need to wait for bugs to move state (rather, if working on a bug, you may wish to change it to ASSIGNED yourself with yourself as assignee). Ok, I started working on this and hope to send a fix soon.
[Bug c++/67291] New: error: 'asm' operand has impossible constraints when compiling gromacs 5.1 testsuite on PPC64 and PPC64LE with VSX SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67291
Bug ID: 67291
Summary: error: 'asm' operand has impossible constraints when
compiling gromacs 5.1 testsuite on PPC64 and PPC64LE
with VSX SIMD
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominik at greysector dot net
Target Milestone: ---
When gromacs-5.1 is configured for double precision, I get the following
compilation error when building the internal tests (make check):
[...]
[ 94%] Building CXX object
src/gromacs/simd/tests/CMakeFiles/simd-test.dir/simd_integer.cpp.o
cd /builddir/build/BUILD/gromacs-5.1/openmpi_d/src/gromacs/simd/tests
/usr/bin/c++ -DGMX_DOUBLE -DGTEST_USE_OWN_TR1_TUPLE=1 -DHAVE_CONFIG_H
-DTEST_DATA_PATH=\src/gromacs/simd/tests\
-DTEST_TEMP_PATH=\/builddir/build/BUILD/gromacs-5.1/openmpi_d/src/gromacs/simd/tests/Testing/Temporary\
-mvsx -std=c++0x -O2
-g -pipe -Wall -Werror=format-security -Wp
,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -Wundef
-Wextra -Wno-missing-field-initializers -Wpointer-arith -Wall
-Wno-unused-function -funroll-all-loops -fexcess-precision=fast
-Wno-array-bounds -isystem
/builddir/build/BUILD/gromacs-5.1/src/external/gmock-1.7.0/gtest/include
-isystem /builddir/build/BUILD/gromacs-5.1/src/external/gmock-1.7.0/include
-I/builddir/build/BUILD/gromacs-5.1/openmpi_d/src/external/tng_io/include
-I/builddir/build/BUILD/gromacs-5.1/src/external/tng_io/include
-I/builddir/build/BUILD/gromacs-5.1/openmpi_d/src
-I/builddir/build/BUILD/gromacs-5.1/src/external/thread_mpi/include
-I/builddir/build/BUILD/gromacs-5.1/src
-I/usr/include/openmpi-ppc64-Wno-unused-variable -o
CMakeFiles/simd-test.dir/simd_integer.cpp.o -c
/builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/tests/simd_integer.cpp
In file included from
/builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/simd.h:138:0,
from
/builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/tests/simd_integer.cpp:37:
/builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/impl_ibm_vsx/impl_ibm_vsx.h:
In member function 'virtual void
gmx::test::{anonymous}::SimdIntegerTest_gmxSimdCvtI2R_Test::TestBody()':
/builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/impl_ibm_vsx/impl_ibm_vsx.h:452:80:
error: 'asm' operand has impossible constraints
__asm__ (xvcvsxwdp %0,%1 : =ww (x) : ww ((__vector signed int)
(ix)));
^
/builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/impl_ibm_vsx/impl_ibm_vsx.h:452:80:
error: 'asm' operand has impossible constraints
__asm__ (xvcvsxwdp %0,%1 : =ww (x) : ww ((__vector signed int)
(ix)));
^
src/gromacs/simd/tests/CMakeFiles/simd-test.dir/build.make:209: recipe for
target 'src/gromacs/simd/tests/CMakeFiles/simd-test.dir/simd_integer.cpp.o'
failed
make[3]: ***
[src/gromacs/simd/tests/CMakeFiles/simd-test.dir/simd_integer.cpp.o] Error 1
[...]
This happens on:
$ cat /proc/cpuinfo
processor : 0
cpu : POWER8E (raw), altivec supported
clock : 3425.00MHz
revision: 2.1 (pvr 004b 0201)
processor : 1
cpu : POWER8E (raw), altivec supported
clock : 3425.00MHz
revision: 2.1 (pvr 004b 0201)
timebase: 51200
platform: pSeries
model : IBM pSeries (emulated by qemu)
machine : CHRP IBM pSeries (emulated by qemu)
using
$ /usr/bin/c++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/c++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/5.1.1/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --disable-libmpx --enable-gnu-indirect-function
--enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
in Fedora rawhide (F24) chroot while building the gromacs package
(http://pkgs.fedoraproject.org/cgit/gromacs.git) under mock.
You have to remove the %ifnarch ppc64 ppc64le part in %install section
to reproduce.
More details here: http://redmine.gromacs.org/issues/1808
[Bug middle-end/67285] ICE with (rdiv (POW:s @0 REAL_CST@1) @0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67285 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- There are two issues here - one is side-effects (virtual definition) and one is dependences (virtual uses). The first one you hit with -fmath-errno, the second you hit with -frounding-math. On GENERIC there can be nothing inbetween components of the matched expression so things are usually fine. On GIMPLE there can be random statements inbetween the statements composing the matched expression. Like _1 = pow (x, 2) fesetround(); _2 = _1 / x; we may not move pow () across fesetround () with -frounding-math, thus we may not generate the expression replacement at the point of the _2 definition. The actual ICE is about our failure to keep the virtual operand SSA form up-to-date in fold_stmt. As we generally do not want to do IL walks to find a suitable VUSE/DEF we can use for that (apart from looking at the current statement) we generally have to fail doing the expression replacement. Implementation-wise the easiest is to fail when we are trying to generate a builtin function call which is not CONST. That doesn't avoid all questionable transforms but at least should avoid the ICEs due to non-up-to-date virtual operand form. There are cases we could relax (like replacing a call with another call), but let's do that separately. Note that this will require -fno-math-errno for any late transforms regarding to math builtins.
[Bug c++/67065] [DR 1886] Missing diagnostics for ill-formed program with main variable instead of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug target/67290] New: powerpc: suboptimal add of u64 with u32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67290
Bug ID: 67290
Summary: powerpc: suboptimal add of u64 with u32
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: christophe.le...@c-s.fr
Target Milestone: ---
#define u32 unsigned long
#define u64 unsigned long long
u64 target(u64 base, u32 offset)
{
return base + offset;
}
With GCC 4.9.3 we get: (same with GCC 4.8.3)
target:
0: 7c ab 2b 78 mr r11,r5
4: 39 40 00 00 li r10,0
8: 7c 84 58 14 addcr4,r4,r11
c: 7c 63 51 14 adder3,r3,r10
10: 4e 80 00 20 blr
I would expect:
target:
addc r4,r4,r5
addze r3,r3
blr
[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728 --- Comment #6 from Ulrich Weigand uweigand at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #4) Testing a patch. It involves tightening the mode of the rtx returned by rtl_for_decl_location, as well as new asserts, so some fallout is likely... Hi Richard, just a quick ping ... Were you able to make any progress with this?
[Bug bootstrap/67289] New: ICE in ipa-devirt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67289 Bug ID: 67289 Summary: ICE in ipa-devirt.c Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rai...@emrich-ebersheim.de Target Milestone: --- Trying to bootstrap trunk revision 227003 using build configuration bootstrap-lto and ada enabled fails with an ICE in stage 2 while linking gnat1. /opt/devel/SCRATCH/tmp.Gw2rTvUmtk/gcc-6.0.0-test/gcc-6.0.0-test/./prev-gcc/xg++ -B/opt/devel/SCRATCH/tmp.Gw2rTvUmtk/gcc-6.0.0-test/gcc-6.0.0-test/./prev-gcc/ -B/opt/devel/gnu/gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_13.2/gcc-6.0.0-test/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/opt/devel/SCRATCH/tmp.Gw2rTvUmtk/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/opt/devel/SCRATCH/tmp.Gw2rTvUmtk/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/opt/devel/SCRATCH/tmp.Gw2rTvUmtk/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/opt/devel/SCRATCH/tmp.Gw2rTvUmtk/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/opt/devel/gnu/src/gcc/gcc-6.0.0-test/libstdc++-v3/libsupc++ -L/opt/devel/SCRATCH/tmp.Gw2rTvUmtk/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/opt/devel/SCRATCH/tmp.Gw2rTvUmtk/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -no-pie -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o gnat1 ada/adadecode.o ada/adaint.o ada/argv.o ada/cio.o ada/cstreams.o ada/env.o ada/init.o ada/initialize.o ada/raise.o ada/seh_init.o ada/targext.o ada/cuintp.o ada/decl.o ada/rtfinal.o ada/rtinit.o ada/misc.o ada/utils.o ada/utils2.o ada/trans.o ada/targtyps.o ada/a-charac.o ada/a-chlat1.o ada/a-elchha.o ada/a-except.o ada/a-ioexce.o ada/ada.o ada/spark_xrefs.o ada/ali.o ada/alloc.o ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o ada/exp_aggr.o ada/exp_spark.o ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_unst.o ada/exp_util.o ada/expander.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o ada/frontend.o ada/g-byorma.o ada/g-hesora.o ada/g-htable.o ada/g-spchge.o ada/g-speche.o ada/g-u3spch.o ada/get_spark_xrefs.o ada/get_targ.o ada/ghost.o ada/gnat.o ada/gnatvsn.o ada/hostparm.o ada/impunit.o ada/inline.o ada/interfac.o ada/itypes.o ada/krunch.o ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-writ.o ada/lib-xref.o ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o ada/nlists.o ada/nmake.o ada/opt.o ada/osint-c.o ada/osint.o ada/output.o ada/par.o ada/par_sco.o ada/prep.o ada/prepcomp.o ada/put_spark_xrefs.o ada/put_scos.o ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o ada/s-addope.o ada/s-assert.o ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-excdeb.o ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o ada/s-os_lib.o ada/s-parame.o ada/s-purexc.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strcom.o ada/s-strhas.o ada/s-string.o ada/s-strops.o ada/s-traent.o ada/s-unstyp.o ada/s-utf_32.o ada/s-valint.o ada/s-valuns.o ada/s-valuti.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scans.o ada/scil_ll.o ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o ada/sem.o ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o ada/sem_case.o ada/sem_cat.o ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o ada/sem_ch9.o ada/sem_dim.o ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_mech.o ada/sem_prag.o ada/sem_res.o ada/sem_scil.o ada/sem_smem.o ada/sem_type.o ada/sem_util.o ada/sem_warn.o ada/set_targ.o ada/sinfo-cn.o ada/sinfo.o ada/sinput-d.o
[Bug middle-end/48544] might be clobbered by ‘longjmp’ diagnostic for unmodified variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48544 --- Comment #1 from Alexandre Duret-Lutz adl at gnu dot org --- This works OK with 4.8 and 5.1, so not an issue anymore as far as I'm concerned. (Might be related to #48968 which is reported as half-fixed -- I haven't tried.)
[Bug tree-optimization/67283] GCC regression over inlining of returned structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-20
CC||jamborm at gcc dot gnu.org
Component|c |tree-optimization
Ever confirmed|0 |1
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
;; Function demo_3 (demo_3, funcdef_no=4, decl_uid=1849, cgraph_uid=4,
symbol_order=4)
Candidate (1904): foo
Candidate (1901): foo
Candidate (1898): foo
Candidate (1870): D.1870
Candidate (1869): D.1869
Candidate (1868): D.1868
! Disqualifying D.1868 - No scalar replacements to be created.
Created a replacement for D.1869 offset: 0, size: 32: SR.30
...
demo_3 ()
{
int foo;
int foo;
int SR.30;
struct foo foo;
struct foo foo;
struct foo foo;
struct foo D.1870;
struct foo D.1869;
struct foo D.1868;
bb 2:
foo = {};
D.1868 = foo;
foo ={v} {CLOBBER};
foo = D.1868;
foo_12 = MEM[(struct foo *)D.1868];
foo_11 = 1;
MEM[(struct foo *)foo] = foo_11;
D.1869 = foo;
SR.30_13 = foo_11;
SR.30_14 = 1;
MEM[(struct foo *)D.1869] = SR.30_14;
foo = D.1869;
foo_16 = SR.30_14;
foo_17 = 3;
MEM[(struct foo *)foo] = foo_17;
D.1870 = foo;
some_unknown_function (D.1870);
return;
}
so it does _some_ SRA but not all required SRA for some reason.
Starts (IMHO) even with new_foo itself during early opts:
Candidate (1835): foo
! Disqualifying foo - No scalar replacements to be created.
new_foo ()
{
struct foo foo;
bb 2:
foo = {};
retval = foo;
foo ={v} {CLOBBER};
return retval;
}
where for some reason we fail to scalarize foo. Similar add_flag
which ends up with
add_flag (struct foo foo, int flag)
{
int foo$flags;
int _2;
int _4;
bb 2:
foo$flags_5 = MEM[(struct foo *)foo];
_2 = foo$flags_5;
_4 = _2 | flag_3(D);
foo$flags_7 = _4;
MEM[(struct foo *)foo] = foo$flags_7;
retval = foo;
return retval;
}
hmm, but here we are returning a parameter - we can't scalarize the parameter
and we can't scalarize the return. But we still want to avoid storing
into 'foo' and store into retval directly.
;; Function demo_1 (demo_1, funcdef_no=2, decl_uid=1843, cgraph_uid=2,
symbol_order=2)
Candidate (1890): foo
Candidate (1858): D.1858
! Disqualifying D.1858 - No scalar replacements to be created.
! Disqualifying foo - No scalar replacements to be created.
demo_1 ()
{
struct foo foo;
struct foo D.1858;
bb 2:
foo = {};
D.1858 = foo;
foo ={v} {CLOBBER};
some_unknown_function (D.1858);
return;
so no total scalarization for foo? Maybe SRA is confused by the CLOBBER?
[Bug c++/67291] error: 'asm' operand has impossible constraints when compiling gromacs 5.1 testsuite on PPC64 and PPC64LE with VSX SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67291 --- Comment #1 from Dominik Mierzejewski dominik at greysector dot net --- Created attachment 36227 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36227action=edit Preprocessed source (gzipped) Preprocessed source generated with: cd /builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/tests /usr/bin/c++ -DGMX_DOUBLE -DGTEST_USE_OWN_TR1_TUPLE=1 -DHAVE_CONFIG_H -DTEST_DATA_PATH=\src/gromacs/simd/tests\ -DTEST_TEMP_PATH=\/builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/tests/Testing/Temporary\ -mvsx -std=c++0x -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -Wundef -Wextra -Wno-missing-field-initializers -Wpointer-arith -Wall -Wno-unused-function -funroll-all-loops -fexcess-precision=fast -Wno-array-bounds -isystem /builddir/build/BUILD/gromacs-5.1/src/external/gmock-1.7.0/gtest/include -isystem /builddir/build/BUILD/gromacs-5.1/src/external/gmock-1.7.0/include -I/builddir/build/BUILD/gromacs-5.1/src/external/tng_io/include -I/builddir/build/BUILD/gromacs-5.1/src -I/builddir/build/BUILD/gromacs-5.1/src/external/thread_mpi/include -Wno-unused-variable -o CMakeFiles/simd-test.dir/simd_floatingpoint.cpp.o -save-temps -c /builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/tests/simd_floatingpoint.cpp
[Bug target/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.3
[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #12 from weiguo.zhou weiguo.zhou at spreadtrum dot com --- (In reply to weiguo.zhou from comment #8) (In reply to Yury Gribov from comment #5) (In reply to Dmitry Vyukov from comment #4) +eugeni can provide more details. Please! E.g. how do you build compiler and runtime? the keypoint to generate a gcc-based cross-compiler toolchain for android/arm32 as following: 1) generate an stage-1 cross-compile gcc toolchain with the existing native gcc; 2) build the sysroot from scratch with the stage-1 cross-compile toolchain; 3) generate the final cross-compile gcc_toolchain with the corresponding sysroot. you can see the keypoint is that we should create a right sysroot for the final cross-compile gcc-toolchain for android/arm32. 1) generate an stage-1 cross-compile gcc toolchain with the existing native gcc; 2) build the sysroot from scratch with the stage-1 cross-compile toolchain; 3) generate the final cross-compile gcc_toolchain (with --enable-libsanitizer option) with the corresponding sysroot;so the final cross-compile could instrument the check code according to the excellent paper address_sanity_checker.pdf; 4) reset the PATH environment variable, the generate the libasan.so.2 with the final cross-compile gcc-toolchain: mkdir libasan-for-android-build cd libasan-for-android-build ../gcc-source-tree/libsanitizer/configure --host=arm-linux-androideabi --prefix=/tmp/toolchain-build-linux-4.9.2/prefix --enable-shared --disable-static don't use any cross-tool like utility here. we should create anything we need from scratch. Thanks to great Google, the powerful AddressSanitizer, and the excellent creator of the AddressSantizer.(kcc and other greate engineer in Google)
[Bug middle-end/67285] ICE with (rdiv (POW:s @0 REAL_CST@1) @0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67285 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug regression/67288] [4.9 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||powerpc* Target Milestone|--- |4.9.4
[Bug target/63672] xbegin/xend/xabort missing memory barriers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63672 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #1 from Peter Bergner bergner at gcc dot gnu.org --- Andi, did this bug ever get fixed? I ask, since we're hitting a similar issue on POWER with our __builtin_tbegin() builtin. I know we need a minimum of a memory barrier on our HTM builtins, but I also wonder whether a full optimization barrier is needed to stop even non loads and stores from being moved outside of the transaction body. The following shows a test case that seems to need a full optimization barrier: https://www.sourceware.org/ml/libc-alpha/2015-08/msg00880.html
[Bug target/67291] error: 'asm' operand has impossible constraints when compiling gromacs 5.1 testsuite on PPC64 and PPC64LE with VSX SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67291 --- Comment #7 from Dominik Mierzejewski dominik at greysector dot net --- Thanks a lot, everyone. This was really helpful. I'll bring this back to gromacs upstream.
[Bug target/67297] New: PowerPC does not support all vector interfaces from the ELFv2 1.1 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67297 Bug ID: 67297 Summary: PowerPC does not support all vector interfaces from the ELFv2 1.1 ABI Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org Target Milestone: --- Target: powerpc64le-unknown-linux-gnu Created attachment 36229 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36229action=edit List of missing vector interfaces Version 1.1 of the Power Architecture 64-Bit ELF V2 ABI Specification: OpenPOWER ABI for Linux Supplement contains an appendix describing built-in functions for vector programming that compliant compilers should implement. GCC currently supports most of these, but a significant number are not yet implemented. A full list of missing interfaces is attached. Intended semantics for the interfaces are described in Appendix A of the ABI document, which can be obtained here: https://www-03.ibm.com/technologyconnect/tgcm/TGCMServlet.wss?alias=OpenPOWER. (Unfortunately free registration is still required to access the document at this site, but you will not be spammed as a result.)
[Bug c++/67292] valgrind error from cc1plus: search_line_sse2(unsigned char const*, unsigned char const*) (lex.c:380)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67292
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Oops I forgot the command:
./cc1plus -std=c++11 -o /dev/null - -quiet 'class k{int k{4};};'
[Bug middle-end/67295] New: [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67295
Bug ID: 67295
Summary: [ARM][6 Regression] FAIL:
gcc.target/arm/builtin-bswap-1.c scan-assembler-times
revshne\\t 1
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
Target: arm*
After the big copyrename patch r226901 I'm seeing these two fails on arm:
FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1
FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times rev16ne\\t 1
The reduced part from these tests is:
extern short foos16 (short);
/* revshne */
short swaps16_cond (short x, int y)
{
short z = x;
if (y)
z = __builtin_bswap16 (x);
return foos16 (z);
}
Compile with -O2.
With the new revision we generate:
cmp r1, #0
rev16ne r0, r0
uxthne r0, r0
.L2:
sxthr0, r0
b foos16
whereas before that we generated:
cmp r1, #0
revshne r0, r0
.L2:
b foos16
Never mind the extra label, I think that's a practically harmless artifact of
if-conversion.
My arm-none-eabi cross compiler was configured with:
--with-arch=armv7-a --with-float=hard --with-fpu=neon-vfpv4
Note, the subsequent commit:
Author: aoliva aoliva@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Aug 19 17:00:32 2015 +
[PR64164] fix regressions reported on m68k and armeb
Defer stack slot address assignment for all parms that can't live in
pseudos, and accept pseudos assignments in assign_param_setup_block.
for gcc/ChangeLog
PR rtl-optimization/64164
* cfgexpand.c (parm_maybe_byref_p): Renamed to...
(parm_in_stack_slot_p): ... this. Disregard mode, what
matters is whether the parm will live in a pseudo or a stack
slot.
(expand_one_ssa_partition): Deal with params without a default
def. Disregard mode.
* cfgexpand.h: Renamed function declaration.
* tree-ssa-coalesce.c: Adjust.
* function.c (split_complex_args): Allocate stack slot for
unassigned parms before splitting.
(parm_in_unassigned_mem_p): New. Use it instead of
parm_maybe_byref_p throughout this file.
(assign_parm_setup_block): Use it. Accept pseudos in the
expand-assigned rtl.
(assign_parm_setup_reg): Drop BLKmode requirement.
(assign_parm_setup_stack): Allocate and fill in the address of
unassigned MEM parms.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@227015
138bc75d-0d04-0410-961f-82ee72b054a4
didn't fix this.
Let me know if any more information is needed
[Bug debug/67293] Very large DW_AT_const_value produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67293 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The difference is of course when not optimized out but using only(?) DW_AT_const_value you can't refer to a in the debugger: (gdb) p a Can't take address of a which isn't an lvalue.
[Bug c++/67292] New: valgrind error from cc1plus: search_line_sse2(unsigned char const*, unsigned char const*) (lex.c:380)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67292 Bug ID: 67292 Summary: valgrind error from cc1plus: search_line_sse2(unsigned char const*, unsigned char const*) (lex.c:380) Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu Build: i686-pc-linux-gnu ==25450== Memcheck, a memory error detector ==25450== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==25450== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==25450== Command: ./cc1plus -std=c++11 -o foo.s - ==25450== ==25450== Invalid read of size 16 ==25450==at 0x8A022A4: search_line_sse2(unsigned char const*, unsigned char const*) (lex.c:380) ==25450==by 0x8A02A1B: _cpp_clean_line (lex.c:843) ==25450==by 0x8A02DCC: _cpp_get_fresh_line.part.6 (lex.c:2209) ==25450==by 0x8A04DEC: _cpp_get_fresh_line (lex.c:2197) ==25450==by 0x8A04DEC: _cpp_lex_direct (lex.c:2274) ==25450==by 0x8A05B6D: _cpp_lex_token (lex.c:2148) ==25450==by 0x8A09FF0: cpp_get_token_1(cpp_reader*, unsigned int*) (macro.c:2359) ==25450==by 0x82771FA: c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) (c-lex.c:302) ==25450==by 0x81AD351: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*) (parser.c:761) ==25450==by 0x81D9703: cp_parser_initial_pragma (parser.c:31423) ==25450==by 0x81D9703: cp_lexer_new_main (parser.c:631) ==25450==by 0x81D9703: cp_parser_new (parser.c:3407) ==25450==by 0x81D9703: c_parse_file() (parser.c:31694) ==25450==by 0x827BF69: c_common_parse_file() (c-opts.c:1067) ==25450==by 0x855B36A: compile_file() (toplev.c:548) ==25450==by 0x855CFF5: do_compile (toplev.c:1926) ==25450==by 0x855CFF5: toplev_main(int, char**) (toplev.c:2002) ==25450== Address 0x418b2a0 is 8 bytes before a block of size 36 alloc'd ==25450==at 0x400720D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==25450==by 0x8A2FA47: xmalloc (xmalloc.c:147) ==25450==by 0x89FF7D3: read_file_guts (files.c:695) ==25450==by 0x89FF7D3: read_file(cpp_reader*, _cpp_file*) (files.c:751) ==25450==by 0x8A00563: should_stack_file (files.c:796) ==25450==by 0x8A00563: _cpp_stack_file (files.c:874) ==25450==by 0x8A0208C: cpp_read_main_file(cpp_reader*, char const*) (init.c:617) ==25450==by 0x827B7AF: c_common_post_options(char const**) (c-opts.c:993) ==25450==by 0x855C891: process_options (toplev.c:1246) ==25450==by 0x855C891: do_compile (toplev.c:1895) ==25450==by 0x855C891: toplev_main(int, char**) (toplev.c:2002) ==25450==by 0x89E04EA: main (main.c:36) ==25450==
[Bug target/67291] error: 'asm' operand has impossible constraints when compiling gromacs 5.1 testsuite on PPC64 and PPC64LE with VSX SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67291 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||meissner at gcc dot gnu.org --- Comment #3 from Peter Bergner bergner at gcc dot gnu.org --- (In reply to Alan Modra from comment #2) I think this is a user error. The ww constraint is for the single precision vsx insns, like xsaddsp. This constraint is only enabled for vsx regs when compiling with -mcpu=power8 (or when you compiler defaults to -mcpu=power8), or when explicitly enabled with -mupper-regs-sf. So if your compiler defaults to -mcpu=power7, you'll get the impossible constraints message. Agreed. Looking at the configure options above, this is a big-endian build that did not use --with-cpu=..., so the -mcpu= default is much older than power8. IIRC, it's even a pre-power4 ISA.
[Bug debug/67293] New: Very large DW_AT_const_value produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67293
Bug ID: 67293
Summary: Very large DW_AT_const_value produced
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: memory-hog, missed-optimization
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
There seems to be no limit on the size of DW_AT_const_value attributes we
generate:
static const int a[100] = { 1, [99] = 1 };
int main() {}
with -O0 -g we produce
16b: Abbrev Number: 7 (DW_TAG_variable)
6c DW_AT_name: a
6e DW_AT_decl_file : 1
6f DW_AT_decl_line : 1
70 DW_AT_type: 0x7e
74 DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
while with -O -g we end up with
16b: Abbrev Number: 7 (DW_TAG_variable)
6c DW_AT_name: a
6e DW_AT_decl_file : 1
6f DW_AT_decl_line : 1
70 DW_AT_type: 0x3d0978
74 DW_AT_const_value : 400 byte block: 1 0 0 0 0 0 0 0 0 0 0 0
I think that's hardly useful nor very friendly to consumers.
We also fail to take the opportunity to represent the not optimized out
constant value in the DW_AT_const_value form if it is shorter:
static const int a = 1;
int main() {}
produces
151: Abbrev Number: 4 (DW_TAG_variable)
52 DW_AT_name: a
54 DW_AT_decl_file : 1
55 DW_AT_decl_line : 1
56 DW_AT_type: 0x5b
5a DW_AT_const_value : 1
15b: Abbrev Number: 5 (DW_TAG_const_type)
when optimized out (1 byte for the const value), compared to
151: Abbrev Number: 4 (DW_TAG_variable)
52 DW_AT_name: a
54 DW_AT_decl_file : 1
55 DW_AT_decl_line : 1
56 DW_AT_type: 0x64
5a DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
164: Abbrev Number: 5 (DW_TAG_const_type)
when not optimized out (10 bytes on 64bit archs, 6 bytes on 32bit archs).
I am arriving here because with early LTO debug I'd like to output more
DW_AT_const_value early (before we know whether the decl will go away).
I think the size optimization is obvious (maybe to some extend even factor
in relocation cost, thus allow bigger than 10 or 6 byte constants, like
arbitrary non-aggregate constants), a limit on the maximum size should very
likely be controlled by a --param.
[Bug target/67291] error: 'asm' operand has impossible constraints when compiling gromacs 5.1 testsuite on PPC64 and PPC64LE with VSX SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67291
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2 from Alan Modra amodra at gmail dot com ---
I think this is a user error.
The ww constraint is for the single precision vsx insns, like xsaddsp. This
constraint is only enabled for vsx regs when compiling with -mcpu=power8 (or
when you compiler defaults to -mcpu=power8), or when explicitly enabled with
-mupper-regs-sf. So if your compiler defaults to -mcpu=power7, you'll get the
impossible constraints message.
Reduced testcase, which compiles OK with -mcpu=power8, but fails with
-mcpu=power7.
__vector double
gmx_simd_cvt_i2d_ibm_vsx(__vector signed int ix)
{
const __vector unsigned char perm = {4, 5, 6, 7, 0, 1, 2, 3, 12, 13, 14, 15,
8, 9, 10, 11};
__vector double x;
ix = __builtin_vec_perm(ix, ix, perm);
__asm__ (xvcvsxwdp %x0,%x1 : =ww (x) : ww (ix));
return x;
}
I believe the asm should be using =wd and wa constraints. Also, that
vec_perm is a bit ugly. Putting the words of ix in the right place would
better be done with xxsldwi.
[Bug libstdc++/67294] New: FAIL: 30_threads/*timed_mutex/unlock/2.cc (test for excess errors) on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67294 Bug ID: 67294 Summary: FAIL: 30_threads/*timed_mutex/unlock/2.cc (test for excess errors) on x86_64-apple-darwin14 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, redi at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin14 Target: x86_64-apple-darwin14 Build: x86_64-apple-darwin14 On x86_64-apple-darwin14 I see the following failures FAIL: 30_threads/recursive_timed_mutex/unlock/2.cc (test for excess errors) UNRESOLVED: 30_threads/recursive_timed_mutex/unlock/2.cc compilation failed to produce executable FAIL: 30_threads/timed_mutex/unlock/2.cc (test for excess errors) UNRESOLVED: 30_threads/timed_mutex/unlock/2.cc compilation failed to produce executable The tests have been introduced at revision r226863 and the failures are /opt/gcc/work/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc:28:25: error: 'recursive_timed_mutex' in namespace 'std' does not name a type using mutex_type = std::recursive_timed_mutex; ^ /opt/gcc/work/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc:30:1: error: 'mutex_type' does not name a type mutex_type m; ^ /opt/gcc/work/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc: In function 'void f()': /opt/gcc/work/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc:34:19: error: 'mutex_type' was not declared in this scope std::lock_guardmutex_type l(m); ^ /opt/gcc/work/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc:34:29: error: template argument 1 is invalid std::lock_guardmutex_type l(m); ^ /opt/gcc/work/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc:34:33: error: 'm' was not declared in this scope std::lock_guardmutex_type l(m); ^
[Bug driver/67301] Unable to compile program using extended assembly and asmSymbolicName
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67301
--- Comment #2 from Jeffrey Walton noloader at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
Try:
int main(int argc, char* argv[])
{
__asm__ __volatile__ (
\t movl %[__ARGC], %%eax \n
:
: [__ARGC] r (argc)
);
return 0;
}
Basically the syntax for naming operands is [XYZ] but since it is optional,
[ is used to say it is optional part of the syntax. Yes it is slightly
confusing but that is what you get when you use [] as both part of the
actual syntax and saying it is an optional part.
Oh, I see. Yes, that's confusing.
When I read it, I thought the double square brackets were a typo that should
have read something like the following, meaning the asmSymbolicName is optional
(which it is):
[ [asmSymbolicName] constraint (cexpression) ]
Perhaps the docs should call that out specifically to avoid confusion?
[Bug libstdc++/67294] FAIL: 30_threads/*timed_mutex/unlock/2.cc (test for excess errors) on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67294 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Should be OK now.
[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728 --- Comment #7 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- (In reply to Ulrich Weigand from comment #6) (In reply to rsand...@gcc.gnu.org from comment #4) Testing a patch. It involves tightening the mode of the rtx returned by rtl_for_decl_location, as well as new asserts, so some fallout is likely... Hi Richard, just a quick ping ... Were you able to make any progress with this? As expected there was a lot of fallout from trying to tighten the mode. We just seem to be very loose with our type safety here. Sometimes the mode of the value associated with the decl is DECL_MODE, sometimes it's the result of promote_decl_mode, sometimes it's BLKmode when the DECL_MODE isn't, sometimes the DECL_MODE is BLKmode when the rtl isn't, etc. It all turned into a bit of a rathole. I suppose I'm just going to have to admit defeat and use the type or mode of the decl only in the case where the rtl is a scalar integer constant -- which seems very inconsistent.
[Bug target/67211] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67211 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Attachment #36218|0 |1 is obsolete|| --- Comment #11 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 36230 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36230action=edit Patch to fix problem for gcc 5.x that was submitted to gcc-patches
[Bug target/67211] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67211 --- Comment #12 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 36231 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36231action=edit Patch to fix problem for gcc 6.x that was submitted to gcc-patches [gcc] 2015-08-20 Michael Meissner meiss...@linux.vnet.ibm.com PR target/67211 * config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Set -mefficient-unaligned-vsx on ISA 2.7. * config/rs6000/rs6000.opt (-mefficient-unaligned-vsx): Convert option to a masked option. * config/rs6000/rs6000.c (rs6000_option_override_internal): Rework logic for -mefficient-unaligned-vsx so that it is set via an arch ISA option, instead of being set if -mtune=power8 is set. Move -mefficient-unaligned-vsx and -mallow-movmisalign handling to be near other default option handling. [gcc/testsuite] 2015-08-20 Michael Meissner meiss...@linux.vnet.ibm.com PR target/67211 * g++.dg/pr67211.C: New test.
[Bug target/67296] New: [HSA] ICE in register allocator (assignment of this argument in a ctor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67296
Bug ID: 67296
Summary: [HSA] ICE in register allocator (assignment of this
argument in a ctor)
Product: gcc
Version: hsa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: matz at suse dot de, mjambor at suse dot cz
Target Milestone: ---
Created attachment 36228
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36228action=edit
Test case
Hello Michael.
Similar problem as yesterday:
$ ./xg++ -B. /tmp/t.c -fdump-tree-hsagen -fdump-tree-hsagen
/tmp/t.c: In constructor ‘C0::C0()’:
/tmp/t.c:4:25: internal compiler error: in linear_scan_regalloc, at
hsa-regalloc.c:686
__attribute__ ((hsa)) C0() {}
^
0xd93138 linear_scan_regalloc
../../gcc/hsa-regalloc.c:686
0xd93725 regalloc
../../gcc/hsa-regalloc.c:793
0xd937de hsa_regalloc()
../../gcc/hsa-regalloc.c:813
0xd8ba12 generate_hsa
../../gcc/hsa-gen.c:3799
0xd8c5e1 execute
../../gcc/hsa-gen.c:4041
$ cat t.c.189t.hsagen
;; Function C0::C0() (_ZN2C0C2Ev, funcdef_no=1, decl_uid=2259, cgraph_uid=1,
symbol_order=1)
--- Generated SSA form ---
HSAIL IL for __base_ctor
BB 0:
ld_kernarg_u64 $_0, [%this]
Fall-through to BB 1
BB 1:
ret_none
--- After out-of-SSA: ---
HSAIL IL for __base_ctor
BB 0:
ld_kernarg_u64 $_0, [%this]
Fall-through to BB 1
BB 1:
ret_none
Thanks,
Martin
[Bug middle-end/67298] New: [6 Regression] 254.gap in SPEC CPU 2000 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67298 Bug ID: 67298 Summary: [6 Regression] 254.gap in SPEC CPU 2000 is miscompiled Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: naveenh at gcc dot gnu.org Target Milestone: --- On Linux/x86-64, r226847 compiles 254.gap in SPEC CPU 2000 into an infinite loop with -O2 -ffast-math -DSPEC_CPU2000_LP64
[Bug c++/67299] New: demangler mishandles complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67299
Bug ID: 67299
Summary: demangler mishandles complex types
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
This tiny C++ program
void f(_Complex float c) {}
compiles into this symbol
_Z1fCf
which is demangled as
f(floatcomplex )
It should probably be
f(_Complex float)
[Bug libstdc++/67294] FAIL: 30_threads/*timed_mutex/unlock/2.cc (test for excess errors) on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67294 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-20 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Sorry about that, I shouldn't be testing features that aren't supported on Darwin. Fix coming up ...
[Bug libstdc++/67294] FAIL: 30_threads/*timed_mutex/unlock/2.cc (test for excess errors) on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67294 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu Aug 20 20:36:19 2015 New Revision: 227043 URL: https://gcc.gnu.org/viewcvs?rev=227043root=gccview=rev Log: libstdc++/67294 Don't run timed mutex tests on Darwin PR libstdc++/67294 * testsuite/30_threads/recursive_timed_mutex/unlock/2.cc: Do not run on Darwin. * testsuite/30_threads/timed_mutex/unlock/2.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/2.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/unlock/2.cc
[Bug middle-end/67298] [6 Regression] 254.gap in SPEC CPU 2000 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67298 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This could be a bug in gap. Have you tried using -fsantitized=undefined on the sources? How about a reduced testcase?
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #20 from Eric ejolson at unr dot edu --- I've been looking at the code in lex_identifier as well as what goes on in forms_identifier_p and so forth. As some point each identifier needs to be stored in the symbol table using ht_lookup_with_hash. Proper functioning requires that UTF-8 and UCN representations of the same unicode characters are treated as the same symbol. Thus, there needs to be some point at which the identifiers are regularized to be either all UTF-8 or all UCN escaped ASCII. As gcc is working with UCNs right now, the obvious implementation allocates temporary memory to hold the UCN escaped ASCII version of an UTF-8 identifier and then frees it again after calling ht_lookup. Any comments would be appreciated.
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #14 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- The issue still reproduces with gcc_4.9_4.9.3-3 in Debian which corresponds to SVN revision r226107 of the gcc-4.9 branch: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/d/ctfeexpr.dmd.o differs Makefile:19827: recipe for target 'compare' failed I have attached the stage 2 and 3 versions of gcc/d/ctfeexpr.dmd.o respectively and also disassembled both after stripping them to be able to generate a diff for the disassembled code. Unlike PR/target 67002, the diff seems rather large this time. Let me know if you need anything else, I have kept the full build of the compiler after it failed the compare target. Adrian
[Bug preprocessor/67292] valgrind error from cc1plus: search_line_sse2(unsigned char const*, unsigned char const*) (lex.c:380)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67292 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 45386. *** This bug has been marked as a duplicate of bug 45386 ***
[Bug preprocessor/45386] [4.6 Regression] valgrind reports out-of-bounds read in search_line_sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45386 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 67292 has been marked as a duplicate of this bug. ***
[Bug target/67291] error: 'asm' operand has impossible constraints when compiling gromacs 5.1 testsuite on PPC64 and PPC64LE with VSX SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67291 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Peter Bergner bergner at gcc dot gnu.org --- Closing as invalid.
[Bug preprocessor/45386] [4.6 Regression] valgrind reports out-of-bounds read in search_line_sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45386 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- It should be possible to create a suppression file to silence false positives: http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress but a comment in the code search_line_sse2 (lex.c:372) is probably as good to avoid further duplicates.
[Bug c++/67292] valgrind error from cc1plus: search_line_sse2(unsigned char const*, unsigned char const*) (lex.c:380)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67292 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This is not a bug. If you look this is an aligned access so it will never fault. This means we can read past the array bounds without any issues as long as we don't use those elements of the vector (which we don't).
[Bug target/67291] error: 'asm' operand has impossible constraints when compiling gromacs 5.1 testsuite on PPC64 and PPC64LE with VSX SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67291 --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org --- Ww is the wrong constraint to use for this instruction. The ww constraint is intended to be used with the VSX scalar single precision floating point instructions added in ISA 2.07 (i.e. power8). On ISA 2.06 (i.e. power7), ww becomes NO_REGS, because that machine did not provide those instructions. This is so we can encode SFmode operations in one insn. Here is a simplification of the add insn for single precision floating point to show how ww is used: (define_insn addsf3 [(set (match_operand:SF 0 register_operand =f,ww) (plus:SF (match_operand:SF 1 register_operand f,ww) (match_operand:SF 2 register_opreand f,ww)] ... @ fadds %0,%1,%2 xsaddsp %x0,%x1,%x2) The appropriate constraint for vector float is wf (you can use wa which is the constraint for all VSX registers, since we map wf and wd to wa). There is no constraint that targets integer vectors specifically. If you are using a VSX instruction you want the wa constraint (instructions with a xs or xv prefix). If you are using an Altivec instruction (typically instructions with a v prefix) you want to use v.
[Bug target/67291] error: 'asm' operand has impossible constraints when compiling gromacs 5.1 testsuite on PPC64 and PPC64LE with VSX SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67291 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Peter Bergner bergner at gcc dot gnu.org --- I'm going to mark this bug as invalid, since it is a gromacs source code error and not a GCC error. That said, gromacs should be fixed. Dominik, are you planning on pushing those changes?
[Bug other/67300] New: -foffload* undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67300 Bug ID: 67300 Summary: -foffload* undocumented Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: tschwinge at gcc dot gnu.org Target Milestone: --- The -foffload= and -foffload-abi= options have no documentation in invoke.texi.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #21 from joseph at codesourcery dot com joseph at codesourcery dot com --- _cpp_interpret_identifier converts UCNs to UTF-8 which is the canonical internal form for identifiers - for UTF-8 in identifiers, you just need to pass in straight through unmodified there. (cpplib takes care to store the original spelling of the identifier as well for purposes for which that matters, but that's simply a matter of lex_identifier calling cpp_lookup on the original spelling as well as using _cpp_interpret_identifier to get the canonical version.) So you never need to convert UTF-8 to UCNs in order to handle UTF-8 in identifiers (cpplib has logic to do so when needed for output, but you don't need to add anything new in that regard). You do need to decode UTF-8 into character values for the code that checks normalization, which characters are allowed at the start of identifiers, etc., just as the existing code decodes UCNs into such values. (But as I noted, a UCN not allowed in identifiers is lexed as part of an identifier, which is then considered invalid, whereas a UTF-8 character not allowed in identifiers should be lexed as a separate pp-token. However, UTF-8 for a character allowed in identifiers but not at the start of an identifier should, I think, be lexed as an identifier character even at the start of an identifier, and then give an error for an invalid identifier if it appears at the start of an identifier. That's my reading of the syntax productions in the C standard.) You can ignore anything claiming to handle UTF-EBCDIC.
