: 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&acti
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&action=edit
Pre-processed intermediate form of minimal.cpp
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&action=edit
Assembly listing of minimal.cpp
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 f
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.
: 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 larg
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&action=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
CC||kip at thevertigo dot com
--- Comment #2
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
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 gu
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.
nt: c
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 param
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
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 ---
Ju
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.
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?
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 #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=97324
--- Comment #9 from Kip Warner ---
Yup. Agreed.
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=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&action=edit
Autoconf configuration log on POWER9.
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&action=edit
Example to generate seg fault
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=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=79700
Kip Warner changed:
What|Removed |Added
CC||kip at thevertigo dot com
--- Comment #5
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 #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 consistenc
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 inh
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 1
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
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
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&action=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.
39 matches
Mail list logo
