http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927
--- Comment #5 from Uroš Bizjak ---
(In reply to Christian Widmer from comment #4)
> Here is a short patch adding Ivy Bridge and Haswell detection. Because Ivy
> Bridge does not support AVX2 it differs a bit from the suggestion above.
Please pos
version 4.9.0 20130826 (experimental) [trunk revision 201986] (GCC)
$ gcc-trunk -O2 reduced.c
$ a.out
1
$ gcc-4.8 -O3 reduced.c
$ a.out
1
$ gcc-trunk -O3 reduced.c
$ a.out
0
$
--
int printf (const char *, ...);
struct S
{
int u;
};
int a = 1, b
regression from
4.8.x.
It is likely a duplicate of 57592, although the stack traces are somewhat
different.
$ gcc-trunk -v
gcc version 4.9.0 20130826 (experimental) [trunk revision 201986] (GCC)
$ gcc-trunk -O2 -c reduced.c
$ gcc-4.8 -O3 -c reduced.c
$ gcc-trunk -O3 -c reduced.c
reduced.c: In
above in
both 32-bit and 64-bit modes.
$ gcc-trunk -v
gcc version 4.9.0 20130826 (experimental) [trunk revision 201986] (GCC)
$ gcc-trunk -O0 small.c
$ a.out
1
$ gcc-trunk -O1 small.c
$ a.out
0
$ gcc-4.8 -O1 small.c
$ a.out
0
$ gcc-4.7 -O1 small.c
$ a.out
0
$ gcc-4.6 -O1 small.c
$ a.out
0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927
Christian Widmer changed:
What|Removed |Added
CC||shadow at umbrox dot de
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153
--- Comment #6 from Kenton Varda ---
Yep, I realize that erase_after would need to be added to the standard. I was
just speculating that it may be something the standard committee should
consider.
I've long since solved my problem by changing my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245
--- Comment #3 from Rich Felker ---
We already do that; the patch is in the musl-cross repo here:
https://bitbucket.org/GregorR/musl-cross or
https://github.com/GregorR/musl-cross
However, we want the stack-protector behavior for GCC with musl t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245
--- Comment #2 from Andrew Pinski ---
The best solution: Don't use the same triplet as the GNU (glibc) one. Have
musl have its own triplet.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245
--- Comment #1 from Rich Felker ---
One more thing: I would be happy with either of two solutions, either:
(1) Checking the canary before calling a noreturn function, just like
performing a check before a tail-call, or
(2) Eliminating the dead-c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245
Bug ID: 58245
Summary: -fstack-protector[-all] does not protect functions
that call noreturn functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58238
DJ Delorie changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58238
--- Comment #2 from DJ Delorie ---
Please try the attached patch. I tested it with a simple "#include stdint.h"
but we made the type names exact matches (way back when) for a reason...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #8 from Martin Konôpka ---
Yes, I understand now. Thanks. The lines with the sin() functions were not
evaluated with the local declaration. My apologies for reporting the false bug.
I will try to close the bug if I am allowed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153
--- Comment #5 from François Dumont ---
And your remark is good too and will avoid me to spend some time on this idea.
Standard requirements regarding validity of iterators won't let us have
iterators invalidated because another iterator is erased
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39057
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208
--- Comment #11 from Tammy Hsu ---
Thank you. Yes, on the fedora 19 systems, I don't have these 3 i686 rpms
installed. I will add them.
Do you have any comments on the crash issue we have on CentOS 5.8 or RHEL
5.5/RHEL 6.3 after building gcc481
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #7 from Andreas Schwab ---
Now try the same code with -O0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #6 from Martin Konôpka ---
(I am sorry that I do not understand internals of compilers.)
I first hit the issue in a bigger code having more than 11000 lines. First I
did not understand at all what is going on. I started to isolate the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #5 from Martin Konôpka ---
I do not fully understand the question. In both cases I used the same
optimisation (-O2). My other comment a while ago was lost. I must retype it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #4 from Andreas Schwab ---
gcc was able to optimize your code to make it 6000 times faster. How is that a
regression?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #3 from Marc Glisse ---
With auxval local, the compiler knows that computing suma, etc is useless and
removes all that code, including the calls to sin. So you would like the
compiler to do the same for a global auxval? That requires t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #2 from Martin Konôpka ---
It it is confirmed, it is a very serious performance issue. In my test the code
with the global declaration executed about 6 times slower than the code
with the local declaration.
For people doing HPC th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
--- Comment #1 from Andrew Pinski ---
Why do you think this is a bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58244
Bug ID: 58244
Summary: global variable: many THOUSANDS times slower execution
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
Jorn Wolfgang Rennecke changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208
--- Comment #9 from Tammy Hsu ---
I tried to run the g++ build on RHEL 5.5 on a RHEL 6.3 system, import seg
fault.
I then tried to rebuild gcc481 on RHEL 6.3 and rerun the testcase, it still
crash.
The glibc on RHEL 6.3 is glibc-2.12-1.80.el6.x8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58243
Bug ID: 58243
Summary: Suboptimal structure initialization with tree-sra
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58242
Uroš Bizjak changed:
What|Removed |Added
CC||aivchenk at gmail dot com
--- Comment #1 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58240
--- Comment #13 from shiyan ---
Hi all,
Thank you for all your explanation. This seems more like a philosophical
discussion :)
I do can understand what GCC is doing (as I mentioned, it may be optimized to
*s1-*s2). And I know that this is som
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58242
Bug ID: 58242
Summary: [4.9 regression] linux-android.c:40:7: error:
'OPTION_BIONIC' was not declared in this scope breaks
bootstrap on powerpc64-linux
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58240
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58240
--- Comment #11 from Marc Glisse ---
(In reply to shiyan from comment #7)
> Thank you for the suggestion. Yes, I know -fno-builtin can work around it. I
> can think of many possible ways to work around itbut whatever, it is a
> bug.
in your c
33 matches
Mail list logo
