https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79161
Ulya changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
--- Comment #5 from Ulya ---
(In reply to Jakub Jelinek from comment #4)
Right, I see.
Bugzilla forced me to add the previous comment when I changed the status. ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
Ulya changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
--- Comment #2 from Ulya ---
(In reply to Jakub Jelinek from comment #1)
> It is a front-end warning, so there is no constant propagation possible.
> You can use -fsanitize=shift to detect this stuff at runtime.
Ok, understood. Maybe someday it
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
Consider this program (1.cc):
#include
void foo ()
{
int32_t x = -32768;
x << 31;
const int32_t y = -32768;
y << 31;
}
GCC detects shift overfl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87264
Ulya changed:
What|Removed |Added
CC||skvadrik at gmail dot com
--- Comment #1 from
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
A recent talk on the C++ Russia conference showed GCC performing ~1.5x worse
than Clang on a simple test that calls std::find_if on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
Ulya changed:
What|Removed |Added
CC||skvadrik at gmail dot com
--- Comment #12 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
--- Comment #4 from Ulya ---
Just in case, here is the output of the latest crashing 'g++ -v':
$ g++ -v
Using built-in specs.
COLLECT_GCC=/home/ulya/devel/gcc-9-20180701-install/bin/g++
COLLECT_LTO_WRAPPER=/home/ulya/devel/gcc-9-20180701-install
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
--- Comment #3 from Ulya ---
Also, please delete the original file when you download it -- my co-workers are
not happy with it being pasted here. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
--- Comment #2 from Ulya ---
Sorry, forgot to paste the last line in the minimal file:
template class a;
template class b;
class c {
virtual bool d();
};
template class e : c {
public:
template e(f);
};
void g() { (e>>(g)); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
--- Comment #1 from Ulya ---
Created attachment 44355
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44355&action=edit
original reproducer
: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 44354
--> ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86320
--- Comment #7 from Ulya ---
Thank you, that was really fast!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86320
Ulya changed:
What|Removed |Added
Summary|very long compilatio n |very long compilation time
|
: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80458
--- Comment #4 from Ulya ---
That sounds reasonable, however if I comment out 'if (!p) exit(1);', I get
warning no matter inline or not:
$ cat 1.cc
#include // exit
extern void *f();
inline void *g() {
void *p = f();
//if (!p) exit(1);
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
On the following example (missing return statement in a member function) GCC
emits no warning:
$ cat 1.cc
#include
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
Created attachment 40553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40553&action=edit
a.c
Consider the following example (a.c in attach):
static void f(const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67783
--- Comment #6 from Ulya ---
(In reply to Richard Biener from comment #5)
> Fixed on trunk sofar.
Thank you! Compiles much faster now.
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
Created attachment 36423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36423&action=edit
1.c, real1.c
Consider the following co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Ulya changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #6 from Ulya ---
(In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Ulya changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from Ulya ---
So GCC's inte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
--- Comment #2 from Ulya ---
$ gcc -W -Wall -Wextra -c 1.c
gives the same result: no warning
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 35065
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35065&action=edit
1.c
Given the following code:
extern void f ();
void g ()
{
for (;;)
{
f ();
c
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 35023
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35023&action=edit
files 1.c (source), 1.s (gcc assembly), 2.s (clang assembly)
Consider the following code:
voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
--- Comment #4 from Ulya ---
Ah! Now I see the problem, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
--- Comment #2 from Ulya ---
> we have to assume that p == q and thus the store to *q invalidates the
> previously load *p
I see.
It seemed to me from GIMPLE dumps that both cases are equally easy to optimize,
perhaps I'm missing something.
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 34403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34403&action=edit
1.c 2.c 1.c.028t.esra 2.c.028t.esra 1.c.030t.fre1 2.c.030t.fre1 1.s 2.s
compile_gcc.sh
Files 1.c
: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 33410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33410&action=edit
obscure_error.h
Given the following program (file obscure_error.h):
class A {
inline void * f (size_t n) {r
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 32521
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32521&action=edit
wmaybe_uninitialized_strange_behavior.c
Given th
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 32510
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32510&action=edit
wreturn_false_positive.c
Given this program (see attachment):
// wreturn_false_positive.c
32 matches
Mail list logo
