https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84212
--- Comment #3 from Jay Foad ---
Here you go:
$ gcc -O3 -flto a.o b.o -Wno-stringop-overflow -v -###
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
See example below: I'm getting warnings emitted by the -flto link stage. I'd
like to selectively disable these warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78472
--- Comment #4 from Jay Foad ---
Works for me, thanks!
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
Target Milestone: ---
If I compile x.h as C and as C++, and link the two together with LTO, I get
this warning, which seems spurious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473
Jay Foad changed:
What|Removed |Added
CC||jay.foad at gmail dot com
--- Comment #6
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
Target Milestone: ---
Consider this simplified example:
$ cat x.cpp
namespace {
template
int f() { return 0; }
}
int g(int n) {
static int (*const
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
Target Milestone: ---
I've just built gcc from svn r224315 on x86_64-unknown-linux-gnu. I get:
$ cat x.c
void f(int p) {}
int g() {
void f();
g();
return 0;
}
$ ~/gcc/local/bin/gcc -g -O3 -c x.c
x.c
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
On x86_64 I get decent code at -O2:
$ cat zplus.c
typedef struct { double a, b; } Z;
Z zplus(Z x, Z y) { return (Z){ x.a + y.a, x.b + y.b }; }
$ gcc -O2 -S -o
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
I get this with GCC 4.10.0 20140619 (experimental):
$ gcc -mno-sse -O3 -S -o - -x c - int f(float x) { return x == (int)x; }
...
f:
fnstcw-2(%rsp)
movzwl-2(%rsp), %eax
flds8(%rsp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61563
--- Comment #2 from Jay Foad jay.foad at gmail dot com ---
I hadn't considered spurious invalid exceptions. I was only thinking about
the result of the whole expression, which I think is the same regardless of
rounding mode even for double
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
If I compile this code for x86-64 I get:
$ cat jcc.c
extern int f(int x);
int g(int x) { return x 3 ? f(x) : x; }
$ cc1 -quiet -O3 jcc.c -o -
...
g:
.LFB0:
.cfi_startproc
cmpl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166
--- Comment #3 from Jay Foad jay.foad at gmail dot com ---
I've bisected this to r191805:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=191805
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01764.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166
Jay Foad jay.foad at gmail dot com changed:
What|Removed |Added
Known to fail||4.8.0
--- Comment #2
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
Created attachment 30660
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30660action=edit
C source for testcase
On the attached test case I get
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
Created attachment 30652
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30652action=edit
C source for testcase
On the attached test case I get:
$ gcc -marm -S -O2 ~/mul.c -o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54355
Bug #: 54355
Summary: ICE on invalid code in switch statement
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
Bug #: 52415
Summary: memcpy to local variable generates unnecessary stack
frame for armv7
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
--- Comment #2 from Jay Foad jay.foad at gmail dot com 2012-02-28 11:51:00
UTC ---
On the tree level nothing guarantees that 'p' is properly aligned.
This is a digression, but what about C99 (Committee Draft -- April 12, 2011)
6.3.2.3p7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
--- Comment #5 from Jay Foad jay.foad at gmail dot com 2012-02-28 13:03:50
UTC ---
But to answer your question, how you can assert it is properly aligned, in gcc
4.7.0 you can write:
__builtin_memcpy (i, __builtin_assume_aligned (p, sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200
Jay Foad jay.foad at gmail dot com changed:
What|Removed |Added
CC||jay.foad at gmail dot
20 matches
Mail list logo
