https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
It would be nice if GCC could pattern-match the typical pattern for
overflow-safe addition and optimize it to just branch on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86029
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86029
--- Comment #5 from Tavian Barnes ---
(In reply to Zsolt from comment #3)
> What is the difference between gcc's and clang's __mulsc3?
The important difference is that Clang (and GCC trunk) expand the fastpath
inline, and fall back on __mulsc3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90246
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90766
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
$ cat test.c
struct a {
};
struct a *const b = &(struct a){};
int main() {
struct {
char *s;
struct a *t;
} a[] = {&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87806
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
GCC 6 warns on this code; GCC 5 didn't.
boost::container::string uses this pattern as part of its SSO implementation,
s
IRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
Created attachment 38438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38438&action=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #3 from Tavian Barnes ---
Because their long_t is not POD. I don't know why that is though. It could be
POD if they removed the default/copy constructors and assignment operator.
Actually they're probably worried about custom alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #5 from Tavian Barnes ---
> But if it is not POD then assuming it gets copied correctly when
> init-constructing a POD union where they placed such object is
> an interesting assumption...
Hrm? They seem to always copy it manually w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #11 from Tavian Barnes ---
Yeah I reported the Boost bug as https://svn.boost.org/trac/boost/ticket/12183.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
Created attachment 38516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38516&action=edit
Reduced testcase
The fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71177
Tavian Barnes changed:
What|Removed |Added
Attachment #38516|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71177
--- Comment #4 from Tavian Barnes ---
> I remember seeing a similar bugreport.
PR57199 is very similar, pretty much an exact dupe actually.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81515
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #7 from Tavian Barnes ---
> the warning is issued for variables which are alive after return from longjmp
> but not marked as volatile. Such variables will have undefined value
> according to C standard
> (http://pubs.opengroup.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #10 from Tavian Barnes ---
> I think it is - __cancel_arg is assigned inside a while loop
Specifically a do { } while(0); loop, which obviously has only one iteration.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Created attachment 32762
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32762&action=edit
Source file
On gcc 4.9.0 (but not on 4.8.2 or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #1 from Tavian Barnes ---
Created attachment 32763
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32763&action=edit
Preprocessed source file
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tavianator at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
--- Comment #2 from tavianator at gmail dot com 2010-04-26 23:47 ---
Created an attachment (id=20497)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20497&action=view)
Full testcase
Proper output:
Stored: 0x40071c
Got:0x40071c
Hello world!
Output with -O -foptimize-
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Created attachment 33715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33715&action=edit
Reproducer
At -O2 and above on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63537
--- Comment #2 from Tavian Barnes ---
Is it possible to make SRA work even if the loop isn't unrolled? If the array
size is increased to 4 then -O2 doesn't unroll the loop at all, resulting in:
movq%rdi, %rax
xorl%edx, %edx
.L3:
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Created attachment 33877
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33877&action=edit
Preprocessed source
GCC allows narrowing convers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723
--- Comment #2 from Tavian Barnes ---
It's decltype(requires_conversion({std::declval()})). Not sure why
it says .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723
--- Comment #4 from Tavian Barnes ---
Still happens with 4.9.2 though. Is a backport of the fix possible?
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Created attachment 33953
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33953&action=edit
Reproducer
std::function's copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510
--- Comment #4 from Tavian Barnes ---
I have a testing tool that automatically inserts operator new failures, to help
test exception safety and check for leaks. This bug causes all kinds of
spurious failures that I have to work around, since any
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Created attachment 34280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34280&action=edit
Test case
The following is a fairly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308
--- Comment #3 from Tavian Barnes ---
@Richard Biener: Yes the range for _16 could be [0, 4294967294]. Why can't VRP
can't assume division by zero doesn't occur? If it can then it could say
anything mod [a, b] fits in [0, b - 1].
That's a reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723
--- Comment #8 from Tavian Barnes ---
Actually it is a regression: according to http://gcc.godbolt.org/, GCC 4.6.4
compiled it correctly with -std=c++0x and
typedef decltype(helper(0)) type;
instead of
using type = decltype(helper(0));
wh
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
The following program produces a spurious warning:
$ cat ternary-warning.cpp
const char&
foo(const char* ptr)
{
return ptr ? *ptr : throw ptr;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372
--- Comment #4 from Tavian Barnes ---
I meant to include -std=c++11 in the OP, it still happens with that flag set.
Good suggestion for the replacement though. The actual code was closer to i <
length ? a[i] : throw ... but I guess that can bec
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Created attachment 33205
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33205&action=edit
Test case
On x86-64 Linux, the attached testcase produces the du
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Created attachment 33529
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33529&action=edit
Preprocessed source
The following file giv
mal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
Created attachment 53580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53580&action=edit
Assembly from gcc -O3 -S bug.c
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952
--- Comment #2 from Tavian Barnes ---
(In reply to Alexander Monakov from comment #1)
> Note, your 'max' function is the same as 'min' (the issue remains with that
> corrected).
Whoops, thanks.
Also I just noticed that GCC 12.2 does better (bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
This is counter-productive, as I wrote the memmove() specifically to get the
sanitizers to check that ptr really points to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748
--- Comment #2 from Tavian Barnes ---
(In reply to Andrew Pinski from comment #1)
> Does -fsanitize=address remove it?
Yes, it's still removed with -fsanitize=address.
While ASAN is necessary to check that the memory is really allocated, UBSAN
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113430
--- Comment #5 from Tavian Barnes ---
(In reply to Xi Ruoyao from comment #3)
> Updated the title to make it more precise.
>
> Note that even with Linux 6.7 the default value of CONFIG_ARCH_MMAP_RND_BITS
> is still 28 (32 is set by some distro
49 matches
Mail list logo
