-*-*
Status|UNCONFIRMED |NEW
Known to work||7.3.0
Keywords||wrong-code
Last reconfirmed||2019-04-20
CC||amonakov at gcc dot gnu.org
Ever
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Controlling expression in _Generic undergoes lvalue conversion, so it will have
const/volatile qualifiers stripped. Therefore, a qualified
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Alexander Monakov ---
The compiler cannot perform this hoisting, because the computation 'n*(i) +
(j)' happens in 'unsigned int' type, where wrapping o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90292
--- Comment #3 from Alexander Monakov ---
When changing iterators to 'int', you also need to change n to int as well,
otherwise in 'n*(i) + (j)', i and j are promoted to unsigned anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #10 from Alexander Monakov ---
Author: amonakov
Date: Thu May 9 18:13:28 2019
New Revision: 271039
URL: https://gcc.gnu.org/viewcvs?rev=271039&root=gcc&view=rev
Log:
sel-sched: allow negative insn priority (PR 88879)
PR rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Alexander Monakov changed:
What|Removed |Added
Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
ostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC 9 introduced a new warning (-Waddress-of-packed-member) for situations
where the code tries to assign ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90394
--- Comment #7 from Alexander Monakov ---
Author: amonakov
Date: Thu May 16 12:36:33 2019
New Revision: 271287
URL: https://gcc.gnu.org/viewcvs?rev=271287&root=gcc&view=rev
Log:
tree-ssa-uninit: avoid ICE with BIT_AND_EXPR (PR 90394)
2019-05-16
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #8 from Alexander Monakov ---
Should be resolved by Vlad's patch - thanks for the report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523
--- Comment #2 from Alexander Monakov ---
See also PR 87076, which has a reduced testcase and some root-cause analysis
(likely a duplicate).
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Alexander Monakov ---
Documentation for -Wuninitialized points out that you need -Winit-self to catch
such patterns (and you do get a warning in that case). Seems to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
--- Comment #3 from Alexander Monakov ---
Thanks. The change in the attached patch looks good to me, but I must admit I
don't see how the testcase triggers the problem. Basically, it's not obvious
how the controlling if condition becomes true:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90817
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
--- Comment #7 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 46479 [details]
> gcc10-pr90811-overalign.patch
>
> Perhaps during estimate_stack_frame_size we should make sure not to adjust
> DECL_ALIG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
Alexander Monakov changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86388
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
--- Comment #5 from Alexander Monakov ---
Sorry, this still seems over-reduced: the 'cmp' variable is uninitialized, and
gcc-7 completely optimizes out the block with large stack usage guarded by 'cmp
== 0' test, so gcc-7 vs gcc-8 is not directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #8 from Alexander Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86420
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Alexander Monakov ---
Without -fpic, f1 is considered not interposable. With -fpic, gcc needs
-fsemantic-interposition to optimize f2 to 'return 0;'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
--- Comment #4 from Alexander Monakov ---
(In reply to H.J. Lu from comment #3)
> It is because gold doesn't check archive for a common definition.
Please elaborate - does ld.bfd try to extract static archive members when it
already has a common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
--- Comment #6 from Alexander Monakov ---
(In reply to H.J. Lu from comment #5)
> When ld sees a common symbol, it will use a non-common definiton
> in a library, .a or .so, to override it.
This is surprising, is it documented somewhere? I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
--- Comment #8 from Alexander Monakov ---
(In reply to H.J. Lu from comment #7)
> It is to be consistent for common symbol linked against .a or .so.
That seems like a really strange reason because without --whole-archive there
are other ways to
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Currently stage2 and 3 use the same warning options, but that is redundant: if
any warnings are generated, they will be present at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #4 from Alexander Monakov ---
Yep, that's correct: -Wno-narrowing is necessary for build to succeed at all.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
#include
std::vector
f()
{
std::vector r;
return r;
}
starting with gcc-8 ICEs using 'g++ -fcompare-debug=-Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #6 from Alexander Monakov ---
GCC 7 sadly has a similar list of miscomparing files. Did not check GCC 6 yet.
So far I managed to catch one set of misbehaving warnings by checking testsuite
fallout with -fcompare-debug=-Wall, but unfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #7 from Alexander Monakov ---
cp/mangle.o miscompares due to -Wsign-compare, possibly due to caching in
maybe_constant_value as in the above PR.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
bool b;
int main ()
{
return ((!b) != 0);
}
ICEs with g++ -fcompare-debug=-Wnonnull-compare (this is bool6.C in the
testsuite). It looks as if the warning prevents folding &#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #8 from Alexander Monakov ---
Other files seem to miscompare due to -Wnonnull-compare: PR 86569.
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
void
f2 (int a, int b, int c, int d)
{
switch (b)
{
default:
for (int e = 0; e < c; ++e)
if (e == d)
break;
}
}
ICEs as bot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #9 from Alexander Monakov ---
One more: -Wimplicit-fallthrough issue uncovered by the testsuite: PR 86575.
So far all issues appeared in gcc-6 or more recent.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Blocks: 86518
Target Milestone: ---
void f ()
{
__builtin_cpu_supports ("avx2") && __builtin_cpu_supports ("ssse3");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586
--- Comment #7 from Alexander Monakov ---
Another possible compromise is to add 'bool for_warnings = false' argument to
maybe_constant_value, store it along with the reduced tree in cv_cache (perhaps
even by setting a flag on the tree itself?), a
|UNCONFIRMED |NEW
Last reconfirmed||2018-07-21
CC||amonakov at gcc dot gnu.org
Summary|Volatile qualifier is |[6/7/8/9 Regression]
|ignored sometimes for |Volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Alexander Monakov changed:
What|Removed |Added
Summary|Inefficient division of |[6/7/8/9 Regression] Signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
--- Comment #5 from Alexander Monakov ---
Yeah, looks like a change that was done on gcc-7 trunk and got backported,
appearing in 6.3 and 5.5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
Alexander Monakov changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #16 from Alexander Monakov ---
> I don't see what should we warn about.
I think the suggestion was to warn when a register const variable appears in
constraints, because the asm is not then guaranteed to receive that operand in
that
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
On the following testcase all 4 generated calls to memcpy/malloc should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #11 from Alexander Monakov ---
(In reply to Richard Biener from comment #10)
> Hmm, I don't remember whether uninit reads invoke undefined behavior, esp.
> result in a trap representation, but the original testcase doesn't seem to
> r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #18 from Alexander Monakov ---
Author: amonakov
Date: Mon Jul 30 12:26:37 2018
New Revision: 263065
URL: https://gcc.gnu.org/viewcvs?rev=263065&root=gcc&view=rev
Log:
doc: discourage const/volatile on register variables (PR 86673)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86819
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86819
--- Comment #3 from Alexander Monakov ---
Right, sorry, somehow I imagined the hook has to do with instructions for
computing approximate inverse. Indeed the two aspects are independent.
I think there may be realistic situations where the change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86819
--- Comment #5 from Alexander Monakov ---
(In reply to Marc Glisse from comment #4)
> But unless your FPU can do 2 divisions in parallel, you have to take into
> account the delay before a second division can start (related to
> throughput), whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418
Alexander Monakov changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418
--- Comment #8 from Alexander Monakov ---
Author: amonakov
Date: Fri Aug 10 10:13:37 2018
New Revision: 263467
URL: https://gcc.gnu.org/viewcvs?rev=263467&root=gcc&view=rev
Log:
i386: do not use SImode mul-highpart on 64-bit (PR 82418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2018-08-10
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Alexander Monakov ---
This is interesting. First scev-cprop emits computation of final value of 'buf'
before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86927
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85640
--- Comment #3 from Alexander Monakov ---
(first paragraph of previous comment had 'before'/'after' swapped, sorry)
Also note that adjusting the testcase to use size_t rather than unsigned int
for the 'len' variable (as production code probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948
--- Comment #2 from Alexander Monakov ---
Thanks for the heads-up. At present, BRIG frontend cannot rely on
MULT_HIGHPART, as the pattern is optional and, as this bug shows, generic
expansion is not implemented. BRIG frontend is already somewhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948
--- Comment #3 from Alexander Monakov ---
Created attachment 44537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44537&action=edit
expose mult-highpart via GIMPLE FE
Attaching a patch that allows creating MULT_HIGHPART_EXPR via GIMPLE FE,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948
--- Comment #4 from Alexander Monakov ---
Created attachment 44541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44541&action=edit
generic expansion for mult-highpart
This patch implements fallback via widening multiply; works for the gim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86971
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86999
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amker at gcc dot gnu.org,
||amonakov at gcc dot gnu.org
Summary|GCC miscompiles at -O3 on |[8/9 Regression]
|valid code |miscompilation with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87046
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||2018-08-21
CC||amonakov at gcc dot gnu.org
Component|middle-end |rtl-optimization
Summary|gcc 7 & 8 - performance |[7/8/9 Regression]
|regression because of |perform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #4 from Alexander Monakov ---
This is probably due to logic issue in PR 78120 fix. Its Changelog said,
(noce_process_if_block): Compute an estimate for the original cost when
optimizing for speed, using the minimum of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86983
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #5 from Alexander Monakov ---
... and avoiding the wrong branch fixes this bug without regressing pr78120.c
testcase:
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -3413,7 +3413,7 @@ noce_process_if_block (struct noce_if_info *if_info)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87071
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948
--- Comment #6 from Alexander Monakov ---
Please follow up on the ML to
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01128.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87071
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #8 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #7)
> Treating the missing else cost as 0 cost isn't right either, it is ok to
> accept some small cost, otherwise we wouldn't do the if conversion ever with
> miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #10 from Alexander Monakov ---
Scaling costs by edge probabilities would also solve this issue, perhaps in a
cleaner way.
(to be clear: if speed_p, instead of taking the weird faux-minimum, add to
original_cost the linear combination
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
On this small example:
void g(int, char *);
static void f(int x)
{
char c[2048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87105
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85758
--- Comment #3 from Alexander Monakov ---
Author: amonakov
Date: Mon Aug 27 14:08:50 2018
New Revision: 263887
URL: https://gcc.gnu.org/viewcvs?rev=263887&root=gcc&view=rev
Log:
match.pd: add single-use check for (x & y) ^ y -> ~x & y (PR 85758)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85758
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86726
--- Comment #1 from Alexander Monakov ---
Author: amonakov
Date: Wed Aug 29 12:39:12 2018
New Revision: 263955
URL: https://gcc.gnu.org/viewcvs?rev=263955&root=gcc&view=rev
Log:
doc: document -ftree-scev-cprop
PR other/86726
* i
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Alexander Monakov ---
Fixed, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190
--- Comment #3 from Alexander Monakov ---
Remember that -fvisibility is not a perfect substitute to proper annotations
via the visibility pragma and attributes. If you do
extern void foo(void);
void bar()
{
foo();
}
then with -fvisibility=hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87191
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87254
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||2018-09-11
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Alexander Monakov ---
Please either attach a compressed file as indicated by Andrew, or if you want
to minimize the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87237
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87237
--- Comment #3 from Alexander Monakov ---
(In reply to Richard Smith from comment #2)
> I think that's only true for objects whose size corresponds to that of a
> fundamental type. Consider:
>
> struct B { char c[3]; };
>
> Here, an atomic obje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87242
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337
Alexander Monakov changed:
What|Removed |Added
CC||minshall at acm dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87311
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220
--- Comment #8 from Alexander Monakov ---
(In reply to Eric Botcazou from comment #7)
> We cannot reasonably document that a feature does exactly the opposite of
> what it is intended to do, can we? You need to compile the entire software
> with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220
--- Comment #13 from Alexander Monakov ---
(In reply to Eric Botcazou from comment #12)
> We're going in circles... -fstack-clash-protection is not stack checking a
> la Ada, it's stack protection against clash attacks and it indeed has
> differ
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Starting from gcc-8 the following function is no longer optimized to a simple
register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436
Alexander Monakov changed:
What|Removed |Added
Summary|Missed optimization with|[8/9 Regression] Missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567
--- Comment #4 from Alexander Monakov ---
I think the problem is not exactly that maybe_constant_value keeps a lookup
cache, but rather that invoking maybe_constant_value may cause allocation of
uids. So it wouldn't be enough to simply avoid popu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87453
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
301 - 400 of 1199 matches
Mail list logo
