https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
--- Comment #4 from Kip Warner ---
Hey Markus. I'm able to replicate your minimal with...
$ g++ --version
g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
Well I'll be damned. It looks as though we've actually managed to find a bona
fide bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
Kip Warner changed:
What|Removed |Added
CC||kip at thevertigo dot com
--- Comment #2
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
While building streflop via my PPA (personal package archive) I managed to
actually make GCC crash. I've attached two logs. One is the full build log
which is very large (11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
--- Comment #1 from Kip Warner ---
Created attachment 37623
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37623=edit
Complete build log (very big, 11 MB decompressed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
Kip Warner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
--- Comment #15 from Kip Warner ---
Thank you for your hard work, Richard. It's very appreciated. I can't imagine
what it would be like to debug GCC.
Which stable version of GCC should I look for that will be the newest to carry
your fix? I'm
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
Created attachment 43248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43248=edit
Mini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055
--- Comment #2 from Kip Warner ---
Created attachment 43250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43250=edit
Assembly listing of minimal.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055
--- Comment #1 from Kip Warner ---
Created attachment 43249
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43249=edit
Pre-processed intermediate form of minimal.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055
--- Comment #6 from Kip Warner ---
Hey Martin. Yes, you are right. I see it now in cl_platform.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055
--- Comment #4 from Kip Warner ---
Thanks Martin. I'm curious where the __int32 type was even coming from.
cl_platform.h has the following typedef, among others that use it...
typedef unsigned __int32cl_uint;
...but no where can I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #5 from Kip Warner ---
The reason I asked is because of that inconsistency in the -mcpu usage on
targets. Thanks for clarifying.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #9 from Kip Warner ---
Yup. Agreed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #7 from Kip Warner ---
I understand what you mean from a maintainer's standpoint. But from a user's
standpoint, that's an inconsistency.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #4 from Kip Warner ---
I'm going to do some more testing tonight and report back after.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #3 from Kip Warner ---
Martin, is -mcpu deprecated for all architectures or just x86?
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
On amd64 I see the following:
$ gcc-10 -Q --help=param -mcpu=sdfdsf
gcc-10: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
The following options control parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #7 from Kip Warner ---
So it looks like even with GCC 11 in trunk it's still sometimes wrong on
power9.
Wrong L2 cache size when no -mcpu specified:
$ gcc -Q --help=param | grep -i cache
--param=l1-cache-line-size= 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #6 from Kip Warner ---
Created attachment 49333
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49333=edit
Autoconf configuration log on POWER9.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
While investigating the memory hierarchy on my Romulus POWER9 (CPU revision
2.2) I discovered GCC's default L1 cache and line sizes on POWER9 are not
correct.
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
Kip Warner changed:
What|Removed |Added
Version|10.2.0 |11.0
--- Comment #1 from Kip Warner ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #2 from Kip Warner ---
Sorry, not same issue. It appears as though this was fixed in gcc-11.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
Created attachment 49792
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49792=edit
Example to generate seg fault.
I am experienc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #7 from Kip Warner ---
Not if I want any certainty at compile time that it is single precision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #10 from Kip Warner ---
Thanks Jonathan, but I disagree. The point is that the caller might be wrong in
any number of assumptions. The library designers were in agreement, hence why
there is an explicit ceilf function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #14 from Kip Warner ---
Thanks Jonathan, but I still think you are mistaken in that you don't
understand why the function exists in its various forms. Your explanation is
technical and not philosophical.
Whether it was originally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #12 from Kip Warner ---
I didn't say STL. I said library designers which includes the standard C
runtime. And no, I don't agree with you. Separate names are helpful for greater
certainty. As for std::ceilf existing just for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98368
--- Comment #5 from Kip Warner ---
*face palm* Yes, you are right! I totally forgot about the invocation at the
end of the CLI! That's what happens when I don't get enough sleep.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98368
--- Comment #3 from Kip Warner ---
Sorry, the _compiler_ crashing is expected behaviour?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
Kip Warner changed:
What|Removed |Added
CC||kip at thevertigo dot com
--- Comment #5
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
I've managed to reproduce this issue on two different machines, one amd64 and
the other ppc64le. Both were using g++-11 (Ubuntu 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
--- Comment #1 from Kip Warner ---
Suggestion: Maybe a unit test that includes all the standard STL headers, does
nothing with them, and that's expected to emit no warnings would mitigate
problems like this occurring in the future.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
--- Comment #3 from Kip Warner ---
Thanks Andrew. I've opened an issue downstream:
https://bugs.launchpad.net/gcc/+bug/1933775
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
The following is a minimal:
// Standard C++ / POSIX system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
--- Comment #8 from Kip Warner ---
And for anyone finding this from a search engine, the temporary workaround is
to use std::copy_n.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
--- Comment #11 from Kip Warner ---
Thanks Jonathan. That was a constructive follow up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107140
--- Comment #2 from Kip Warner ---
Created attachment 53673
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53673=edit
Minimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107140
--- Comment #3 from Kip Warner ---
If you click the Save button in Godbolt's CE, you can download a compressed
archive. I've attached it for you.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
I am aware there have been other related issues that have already been opened.
I am not sure if this adds anything
39 matches
Mail list logo
