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=33529action=edit
Preprocessed source
The following file gives a confused by earlier
: 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=33715action=edit
Reproducer
At -O2 and above on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63537
--- Comment #2 from Tavian Barnes tavianator at gmail dot com ---
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
: 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=32762action=edit
Source file
On gcc 4.9.0 (but not on 4.8.2 or earlier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #1 from Tavian Barnes tavianator at gmail dot com ---
Created attachment 32763
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32763action=edit
Preprocessed source file
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
http://gcc.gnu.org/bugzilla
--- 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=20497action=view)
Full testcase
Proper output:
Stored: 0x40071c
Got:0x40071c
Hello world!
Output with -O -foptimize-sibling
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=33877action=edit
Preprocessed source
GCC allows narrowing conversions in braced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723
--- Comment #2 from Tavian Barnes tavianator at gmail dot com ---
It's decltype(requires_conversionTo2({std::declvalFrom2()})). Not sure why
it says missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723
--- Comment #4 from Tavian Barnes tavianator at gmail dot com ---
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=33953action=edit
Reproducer
std::function's copy constructor looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510
--- Comment #4 from Tavian Barnes tavianator at gmail dot com ---
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
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=34280action=edit
Test case
The following is a fairly typical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308
--- Comment #3 from Tavian Barnes tavianator at gmail dot com ---
@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723
--- Comment #8 from Tavian Barnes tavianator at gmail dot com ---
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(helperFrom, To(0)) type;
instead
: 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;
}
$ g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372
--- Comment #4 from Tavian Barnes tavianator at gmail dot com ---
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
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,
so I'm
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=71177
Tavian Barnes changed:
What|Removed |Added
Attachment #38516|0 |1
is obsolete|
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=edit
Reduced testcase
The following
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.
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
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
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=edit
Reduced t
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
>
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.
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90766
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=90205
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
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=edit
Assembly from gcc -O3 -S bug.c
The fol
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
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
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
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
47 matches
Mail list logo
