https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119526
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #2
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
The following ought to be accepted in C++17 and later:
```
struct Foo {int* x = 0;};
class Bar {
static constexpr Foo foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
--- Comment #7 from James Y Knight ---
On the libc++ side, a suggestion was given that instead of making this an
_error_, we could instead emit a warning if "a constexpr or constinit object is
a basic_string or contains a basic_string subobject,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
--- Comment #5 from James Y Knight ---
> Does using __builtin_is_constant_p on the union member not work?
I've created a proof-of-concept patch for libc++ to support SSO strings during
constant evaluation. It works.
If everyone disagrees with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
--- Comment #4 from James Y Knight ---
vector and string are different in one key way: a zero-sized vector has no
accessible storage, while a zero-sized string has 1 byte of readable storage --
the NUL terminator. Because of that, I don't think
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
In C++20, libstdc++ currently allows an std::string instance to escape from
constant evaluation to runtime, as long as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #37 from James Y Knight ---
(In reply to qinzhao from comment #35)
> I think that -Wstrict-flex-arrays will need to be cooperated with
> -fstrict-flex-arrays=N, i.e, only when -fstrict-flex-arrays=N is presenting,
> -Wstrict-flex-arr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #36 from James Y Knight ---
(In reply to Kees Cook from comment #34)
> > Great. Adding that flag, and eliminating the -fstrict-flex-arrays=3 option
> > from this proposal would be good.
>
> Hmm? No, -fstrict-flex-arrays=3 is still n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #33 from James Y Knight ---
(In reply to qinzhao from comment #32)
> there is a Bugzilla that has been filed for GCC to request the same warning
> for GCC:
> https://gcc.gnu.org/bugzilla//show_bug.cgi?id=94428
>
> -Wzero-length-arra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99858
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685
--- Comment #5 from James Y Knight ---
(oops submitted commit by mistake, continuing...)
Strangely, it appears that Clang and GCC both have odd behaviors currently, but
somewhat opposites:
- GCC appears to evaluate weak constants _only_ in fron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104602
--- Comment #4 from James Y Knight ---
Yea that should work. Or even just `auto`.
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
I'm working on implementing __builtin_source_location() in Clang
(https://reviews.llvm.org/D120159).
In testing it against the libstdc++ header, I ran into a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918
--- Comment #6 from James Y Knight ---
I realize that my suggestion above could only solve _most_ of the problem --
e.g. the original example, where the noexcept function doesn't have a try/catch
in it.
In that original example, there's no entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100953
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115
--- Comment #10 from James Y Knight ---
Seeing as GCC is now in Stage 4 before the next release, I'd like to ping this
bug.
Should the priority be upgraded? I think fixing this so that GCC doesn't use
'v111__alignof__' should be considered a rel
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
CC: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC parses the following program (by Richard Smith) as `g` less-than `a`
greater-than `(a)` instead of a call to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115
--- Comment #9 from James Y Knight ---
Proposed patch posted for the itanium-cxx-abi:
https://github.com/itanium-cxx-abi/cxx-abi/pull/115/files
using the syntax:
u * E
And to Clang, to use that syntax:
https://reviews.llvm.org/D93922
I hope
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
This is a regression due to the MMX in SSE work in GCC10. As far as I can tell,
it affects only these two functions.
Example test, which
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
#include
int test(__m64 a) {
return _mm_extract_pi16 (a, 0);
}
Compiles to (x86_64 gcc, -O2):
pextrw $0, %xmm0, %eax
cwtl
ret
Which results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115
--- Comment #7 from James Y Knight ---
I've created an ABI proposal against itanium abi, here:
https://github.com/itanium-cxx-abi/cxx-abi/issues/112
I realized since writing my last comment here that
::= u [] # vendor extended type
has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115
--- Comment #6 from James Y Knight ---
> c++: Change the mangling of __alignof__ [PR88115]
The new mangling chosen for __alignof__(type) seems problematic, and I think
this commit ought to be reverted until a new mangling scheme has been cho
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
After 3427e31331677ca826c5588c87924214f7e5c54b, "clang -std=c++17" (using
libstdc++ headers), on a fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95722
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855
--- Comment #7 from James Y Knight ---
Ugh, GCC doesn't wrap quoted text? Re-posting the quote from
http://eel.is/c++draft/headers#5 without a quote marker...
"""
Except as noted in [library] through [thread] and [depr], the contents of each
hea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855
--- Comment #6 from James Y Knight ---
Someone has pointed out to me that the standard actually says "name", which I
had internalized as meaning "declaration", but it doesn't. This arguably does
make the GCC implementation non-compliant with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #7
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
In the following, I use the function "log" as an example, but this applies to
effectively everything in cmath, and ::abs in cstdl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #24
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
std::alignment_of is currently defined based on "__alignof__", but according to
the standard [meta.unary.prop.query],
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
On both GCC 8.2 and "trunk" on godbolt (https://godbolt.org/z/ykszUZ) given the
following program, compiled for x86 -m32,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87521
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #10 from James Y Knight ---
I suppose since it doesn't affect most common platforms, nobody's noticed the
brokenness yet?
ARM is probably the most common architecture which is missing atomics on common
CPU models, but when targeting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #7 from James Y Knight ---
(In reply to Jim Wilson from comment #6)
> On Thu, 2018-05-31 at 15:07 +0000, foom at fuhm dot net wrote:
> > (But also, why doesn't it implement __atomic_add_fetch inline?)
>
> If y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
--- Comment #12 from James Y Knight ---
Since this would at least theoretically be a c++11 ABI change -- although it
seems likely not to impact the ABI of most actual software -- it seems like
it'd be a really good idea to fix it ASAP, before too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438
James Y Knight changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438
--- Comment #9 from James Y Knight ---
What good is having special code to allow linking compatibility, if the program
then can't work anyways? Isn't that anti-useful?
> I didn't realise you were the maintainer and knew what's supposed to work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438
James Y Knight changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
If you compile this program with GCC 4.9, but you have libstdc++ version 5.1
installed on your system. (E.g., this is the case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
--- Comment #11 from James Y Knight ---
As far as I can tell, the C++ ABI discussion,
http://comments.gmane.org/gmane.comp.lang.c++.abi/265
concluded that alignof(nullptr_t) should be alignof(void*) already.
Any chance this change can be made an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53364
--- Comment #3 from foom at fuhm dot net 2012-05-16 04:28:21 UTC ---
> Does -fno-tree-vrp fix the issue?
Nope, "g++ -O2 -fno-tree-vrp -c test.cpp" is no different than without.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53364
--- Comment #1 from foom at fuhm dot net 2012-05-16 04:10:59 UTC ---
Asm generated. Note that at no point is anything ever actually written to the
stack, only read from it:
:
0:83 3d 00 00 00 00 09 cmpl $0x9,0x0(%rip
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53364
Bug #: 53364
Summary: [4.7/4.8 Regression] Wrong code generation
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53356
Bug #: 53356
Summary: ICE in verify_gimple_stmt, at tree-cfg.c:4258
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561
foom at fuhm dot net changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment
ion: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45060
+0x mode
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44487
--- Comment #18 from foom at fuhm dot net 2010-03-10 20:32 ---
Sorry for the extreme delay in responding. I can confirm that applying that
patch on top of:
gcc-4.5 (Debian 4.5-20100227-1) 4.5.0 20100227 (experimental) [trunk revision
157109]
*does* make my issue go away, and my program
--- Comment #17 from foom at fuhm dot net 2010-02-12 21:46 ---
Thanks, I will try doing that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
--- Comment #15 from foom at fuhm dot net 2010-02-10 23:24 ---
Nope, adding -fno-indirect-inlining has no effect.
I'm now using:
g++-4.5 (Debian 4.5-20100202-1) 4.5.0 20100202 (experimental) [trunk revision
156452]
Problem still occurs, -fno-ipa-cp still makes it go away.
--
--- Comment #1 from foom at fuhm dot net 2010-01-19 06:15 ---
Error also occurs with:
g++ -O1 -fipa-sra -g -std=c++0x -c test.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42797
>::allocator() [with _Tp = Foo]
--
Summary: call of overloaded 'allocator()' is ambiguous
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42797
--- Comment #13 from foom at fuhm dot net 2010-01-12 06:27 ---
The crash is still present for my code. I'm using:
g++ (Debian 20091228-2) 4.5.0 20091228 (experimental) [trunk revision 155486]
on AMD64.
Passing -fno-ipa-cp also makes the bug disappear for me. But apparently r15467
--- Comment #5 from foom at fuhm dot net 2009-10-30 02:42 ---
An error very much like this is also causing a bunch of files in my program to
fail to compile with 4.5 with -O1 and above. I was unable to reduce a simple
test case from my (private) code, though: many changes that seem like
cc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foom at fuhm dot net
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
70 matches
Mail list logo
