http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
James Y Knight foom at fuhm dot net changed:
What|Removed |Added
CC||foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
James Y Knight foom at fuhm dot net changed:
What|Removed |Added
CC||foom at fuhm
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
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
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:
main:
0:83 3d 00 00 00 00 09 cmpl $0x9,0x0
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=54170
James Y Knight foom at fuhm dot net changed:
What|Removed |Added
CC||foom at fuhm dot net
parameter
Product: gcc
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
--- 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
--- 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 r154673
did
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 #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
--- 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.
--
http
--- 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 #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
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
: 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
: unassigned at gcc dot gnu dot org
ReportedBy: foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
--- Comment #11 from James Y Knight foom at fuhm dot net ---
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
: 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=66438
James Y Knight foom at fuhm dot net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438
--- Comment #9 from James Y Knight foom at fuhm dot net ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438
James Y Knight foom at fuhm dot net changed:
What|Removed |Added
CC||doko at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
--- Comment #12 from James Y Knight foom at fuhm dot net ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
James Y Knight foom at fuhm dot net changed:
What|Removed |Added
CC||foom at fuhm dot
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=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 you do
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=87521
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #5
: 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,
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],
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: ---
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=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
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
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
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=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
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
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
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
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
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
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
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
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
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #5
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
minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104602
--- Comment #4 from James Y Knight ---
Yea that should work. Or even just `auto`.
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=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=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
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
: 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
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
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=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
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=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
>
>
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
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,
>
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=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=98112
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #8
68 matches
Mail list logo
