https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84450
--- Comment #1 from Steven Noonan ---
Sorry for the comment spam, but...
I think DMARC/DKIM caused the notification for this bug to drop on the floor,
as I saw a DMARC report for my domain saying 65 messages on *@gnu.org were
rejected because
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
This bug has been around for at least a few GCC versions now, but I hadn't
gotten around to reporting it.
My configure flags:
--host=x86_64-pc-linux-gnu --build=x86_64-pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #14 from Steven Noonan ---
"testcase.i" can be reduced a lot (thanks creduce!). Literally just this:
---
__attribute__((target_clones("arch=sandybridge", "default"))) static _saxpy() {
#pragma omp parallel
;
}
saxpy() {}
---
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
Steven Noonan changed:
What|Removed |Added
Attachment #42417|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #12 from Steven Noonan ---
Created attachment 42418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42418=edit
nbody_CPU_AOS compile error testcase preprocessed source
Compile error case, preprocessed source.
Compile with:
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
Steven Noonan changed:
What|Removed |Added
Attachment #40333|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #9 from Steven Noonan ---
Actually, I lied. It's not quite working. It's obviously close though.
The following examples of the issue are using my n-body implementation:
https://github.com/tycho/nbody
Each of the variants of n-body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #12 from Steven Noonan ---
Oh this is kind of interesting. It runs fine at '-O1 -ggdb3'
$ go.gcc test -o testbin -gccgoflags '-O1 -ggdb3
-Wl,--compress-debug-sections=zlib'
OK: 136 passed
PASS
ok github.com/twstrike/ed448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #11 from Steven Noonan ---
Weird, I wonder why you can't repro it.
I built with this to get a stack trace (I assume -O and -ggdb work properly
when placed here):
$ go.gcc test -o testbin -gccgoflags '-O0 -ggdb3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #8 from Steven Noonan ---
Oh, awesome! I just tested a gcc trunk build and it's definitely working there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
Steven Noonan changed:
What|Removed |Added
Version|6.2.0 |7.2.1
--- Comment #6 from Steven Noonan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #9 from Steven Noonan ---
(In reply to Ian Lance Taylor from comment #8)
> Which version of GCC are you using in comment #7?
Oops, forgot to mention that bit. Built from trunk a few hours ago:
$ go.gcc version
go version go1.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337
--- Comment #18 from Steven Noonan ---
I'm still seeing an Ada-related failure when using
--with-build-config=bootstrap-lto on the current gcc-7-branch (r253607).
/build/gcc-multilib/src/gcc/gcc/ada/g-dyntab.adb: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #7 from Steven Noonan ---
With the compressed debug section support added to libbacktrace, gccgo will run
fine when built using a binutils configured with
--enable-compressed-debug-sections=all. However, programs built with that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #4 from Steven Noonan ---
This bug is still present, but I believe I know what is causing this.
At the time I reported this, I was using a binutils configured with
--enable-compressed-debug-sections=all. The resulting go.gcc binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82379
--- Comment #6 from Steven Noonan ---
Seems to resolve the link issue. Not sure how to test that internal_sigreturn
does what it should, though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82379
--- Comment #5 from Steven Noonan ---
(In reply to H.J. Lu from comment #4)
> (In reply to Steven Noonan from comment #3)
> > Are you sure that patch is sufficient? __x86_64__ is defined on both the
> > normal x86_64 ABI and on the x32 ABI. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82379
--- Comment #3 from Steven Noonan ---
Are you sure that patch is sufficient? __x86_64__ is defined on both the normal
x86_64 ABI and on the x32 ABI. The combination most often used to identify x32
is 'defined(__x86_64__) && defined(__ILP32__)'
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #3 from Steven Noonan ---
This is from a different go.gcc binary, because I've rebuilt several times to
try and troubleshoot. But this one still exhibits the bad behavior. Just in
case, I've uploaded a copy of the binary, the entire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #1 from Steven Noonan ---
Possibly better backtrace from an -O0 -g build of GCC:
Program received signal SIGSEGV, Segmentation fault.
0x7731307e in __generic_morestack (pframe_size=0x77fa3050,
old_stack=0x77fa3070,
: ian at airs dot com
Reporter: steven at uplinklabs dot net
CC: cmang at google dot com
Target Milestone: ---
I can't seem to get gcc-go to work in my builds of GCC, and I don't understand
why. Here's my build configuration:
$ gcc -v
Using built-in specs.
COLLECT_GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80626
--- Comment #5 from Steven Noonan ---
(In reply to H.J. Lu from comment #3)
> Please try
>
> diff --git a/gcc/ada/system-linux-x86.ads b/gcc/ada/system-linux-x86.ads
> index 22a212e..533d94e 100644
> --- a/gcc/ada/system-linux-x86.ads
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80634
--- Comment #1 from Steven Noonan ---
Created attachment 41323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41323=edit
icc 17.0.1 outputs for ELEMS=1 through ELEMS=32
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
Created attachment 41322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41322=edit
gcc 6.3.1 outputs for ELEMS=1 through ELEMS=32
(Not sure which compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80626
--- Comment #2 from Steven Noonan ---
It looks like this is just the first of several files with that build issue. If
I build with 'make -k' I see several others fail with the same warning, e.g.:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80626
--- Comment #1 from Steven Noonan ---
I configured with these flags, if they're needed for repro:
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib
: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
I'm sure this would be trivial to fix if I knew any Ada at all, but I've run
into this build failure for GCC 7.1.0 when built with
--with-multilib=m32,m64,mx32 for x86_64
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
Using modified version of test case from PR78808:
---
__attribute__((target_clones("avx2,fma,bmi,bmi2", "arch=sandybridge",
"default")))
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #3 from Steven Noonan ---
Created attachment 40335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40335=edit
compiled with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #2 from Steven Noonan ---
Created attachment 40334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40334=edit
compiled without -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #1 from Steven Noonan ---
Created attachment 40333
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40333=edit
test.c - test case for target_clones with(out) -fopenmp
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
Simple test case:
---
__attribute__((target_clones("arch=haswell", "arch=sandybridge", "default")))
static void _saxpy(int n, floa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70858
--- Comment #3 from Steven Noonan ---
Cool. I'll let the project maintainer know to not use the __builtin_* variants.
_bextr_u32 and _bextr_u64 look much more friendly, too.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/6.1.0/lto-wrapper
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337
--- Comment #9 from Steven Noonan steven at uplinklabs dot net ---
Sure.
$ gdb --args
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/./prev-gcc/xgcc
-B/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/./prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337
--- Comment #7 from Steven Noonan steven at uplinklabs dot net ---
Tried applying the patch mentioned in comment 6 and doing a build using
--with-build-config=bootstrap-lto. Ended with:
[...]
/build/gcc-multilib/src/gcc-build/./prev-gcc/xgcc
-B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828
--- Comment #2 from Steven Noonan steven at uplinklabs dot net ---
I just noticed that libtool appears to be stripping some of the arguments in
LDFLAGS when invoking GCC:
/bin/sh ../libtool --tag=CC --mode=link gcc -flto -Wall -Wstrict
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Host architecture is x86_64, GCC version is the 4.9-20150415 snapshot. I've
also seen this ICE on the 5-20150414 snapshot under the same conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828
--- Comment #1 from Steven Noonan steven at uplinklabs dot net ---
If you want a nice tarball with a ready-to-go repro case, I've put it here:
https://www.uplinklabs.net/files/lto-65828.tar.xz
Should just be able to run something like:
$ /usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409
--- Comment #4 from Steven Noonan steven at uplinklabs dot net ---
Ahh, didn't even think about an x32/ms_abi compatibility problems. That totally
makes sense. It probably shouldn't work anyway, but an ICE is obviously not the
right reaction from
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Created attachment 34335
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34335action=edit
Preprocessed source
Trying to build Mesa 10.4.0 for the X32 ABI on an x86_64 host, encountered an
ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409
--- Comment #1 from Steven Noonan steven at uplinklabs dot net ---
Just built and tried using the 20141224 snapshot. Same issue:
getproc.c: In function ‘D3DAdapter9GetProc’:
getproc.c:38:1: internal compiler error: in emit_move_insn, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
--- Comment #12 from Steven Noonan steven at uplinklabs dot net ---
Thanks for the fast resolution, Jakub!
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Running GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
--- Comment #2 from Steven Noonan steven at uplinklabs dot net ---
Created attachment 32147
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32147action=edit
/proc/cpuinfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
--- Comment #3 from Steven Noonan steven at uplinklabs dot net ---
Created attachment 32148
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32148action=edit
CPUID dump
Adding both /proc/cpuinfo and a dump from a userspace utility using
47 matches
Mail list logo
