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.
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
Bug ID: 107140
Summary: Potential false positive uninitialized variable
warning with -Wmaybe-uninitialized
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Sev
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
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
Bug ID: 101228
Summary: #include triggers Intel TBB warning for
tbb/task.h
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priorit
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=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
Bug ID: 99402
Summary: std::copy creates _GLIBCXX_DEBUG false positive for
attempt to subscript a dereferenceable
(start-of-sequence) iterator
Product: gcc
Versio
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
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 #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 #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
Kip Warner changed:
What|Removed |Added
CC||kip at thevertigo dot com
--- Comment #5 fr
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=98368
Bug ID: 98368
Summary: Seg fault on template method missing required return
statement
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
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.
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 #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=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 #3 from Kip Warner ---
Martin, is -mcpu deprecated for all architectures or just x86?
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=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
Bug ID: 97329
Summary: POWER9 default cache and line sizes appear to be wrong
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
Bug ID: 97324
Summary: -mcpu= isn't validated on x86
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
28 matches
Mail list logo
