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.
++
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 '!b
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.
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
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 #4 from Alexander Monakov ---
Yep, that's correct: -Wno-narrowing is necessary for build to succeed at all.
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
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
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
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
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=86442
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=86420
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #8 from Alexander
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
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=86350
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86311
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86311
--- Comment #1 from Alexander Monakov ---
Author: amonakov
Date: Mon Jun 25 17:44:15 2018
New Revision: 262092
URL: https://gcc.gnu.org/viewcvs?rev=262092=gcc=rev
Log:
gcc_qsort: avoid overlapping memcpy (PR 86311)
PR middle-end/86311
Status|UNCONFIRMED |WAITING
Last reconfirmed||2018-06-21
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86174
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 ---
This is the *assembler* segfaulting, not the *compiler*. The assembly produced
by trunk is not different from gcc-8 output on empty input, so it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #3 from Alexander Monakov ---
-fabi-version=12 is not documented, not mentioned in release notes, and not
wired up in -Wabi.
||2018-06-09
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
df_mw_compare has:
if (mw1->mw_reg != mw2->mw_reg)
return mw1->mw_order - mw2-
, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
When compiling the following with -O2 -std=c++11:
struct S {
S(S&&) = default;
||2018-06-08
CC||amonakov at gcc dot gnu.org
Known to work||7.3.0
Summary|volatile ignored on pointer |[8/9 Regression] volatile
|in C|ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86072
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 ---
In GCC there's no way to selectively enable a few optimizations with their -f
flags at -O0 level: -O0 means that optimizations are completely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86026
--- Comment #3 from Alexander Monakov ---
Tree optimizations already manage to avoid "optimizing" f_intadd, but
unfortunately on RTL types and casts are not visible in IR and various passes
make no distinction between (char*)((uintptr_t)t + o)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86026
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85994
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #10 from Alexander Monakov ---
Also note that both the original and the reduced testcase can be tweaked to
exhibit the surprising transformation even when -fexcess-precision=standard is
enabled. A "lazy" way is via -mpc64, but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #9 from Alexander Monakov ---
Sorry, the above comment should have said 'b * 1e6' every time it said 'b'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #8 from Alexander Monakov ---
To expand a bit: DOM makes the small testcase behave as if 'b' and 'ib' are
evaluated twice:
* one time, 'b' is evaluated in precision matching 'a' (either infinite or
double), and 'ib' is evaluated to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||2018-05-29
CC||amonakov at gcc dot gnu.org
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #7 from Alexander Monakov ---
Reopening, the issue here is way more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85921
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 79985, which changed state.
Bug 79985 Summary: ICE in code_motion_path_driver, at sel-sched.c:6580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
--- Comment #9 from Alexander Monakov ---
Author: amonakov
Date: Wed May 23 15:01:28 2018
New Revision: 260613
URL: https://gcc.gnu.org/viewcvs?rev=260613=gcc=rev
Log:
df-scan: remove ad-hoc handling of global regs in asms
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80318
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||2018-05-16
CC||amonakov at gcc dot gnu.org
Resolution|WONTFIX |---
Ever confirmed|0 |1
--- Comment #10 from Alexander Monakov ---
Reopening: the request to be able
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Alexander Monakov ---
Starting from gcc-4.5 (released in 2010) GCC emits pcmpeq for the
explicit-constructor variant (where it would previously emit a load) as well
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
The following should be translated as-is:
void f(int a, int b);
void g(int a, int b, int m, int s)
{
m &= s;
a
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
This is minimized from one of suboptimal stack consumption issues in gcc_qsort
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-07
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Smaller testcase:
void f(void
||2018-05-06
CC||abel at gcc dot gnu.org,
||amonakov at gcc dot gnu.org
Blocks||84301
Assignee|unassigned at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
--- Comment #14 from Alexander Monakov ---
Thanks. I think the root cause on this x86_64 testcase is different.
Arseny, in the meantime if by chance you have another x86_64 variant of this
failure that doesn't require -funroll-all-loops, please
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Alexander Monakov ---
I'm not sure Richard is correct about the definition of volatile asms: similar
to reads of volatile objects, volatile asms can produce different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 85423, which changed state.
Bug 85423 Summary: [8 Regression] ICE in code_motion_process_successors, at
sel-sched.c:6403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463
Bug 80463 depends on bug 85423, which changed state.
Bug 85423 Summary: [8 Regression] ICE in code_motion_process_successors, at
sel-sched.c:6403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
--- Comment #8 from Alexander Monakov ---
Unfortunately the above doesn't fully address the issue, as schedulers and
other passes still have no idea that DF makes those assumptions and will allow
reordering of asms:
register int r asm("ebx");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
--- Comment #7 from Alexander Monakov ---
Or rather like this:
diff --git a/gcc/df-scan.c b/gcc/df-scan.c
index 95e1e0df2d5..732705c0385 100644
--- a/gcc/df-scan.c
+++ b/gcc/df-scan.c
@@ -3207,11 +3207,11 @@ df_insn_refs_collect (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416
--- Comment #13 from Alexander Monakov ---
This is most likely a variant of
https://bugzilla.redhat.com/show_bug.cgi?id=1421121
so hitting this bug requires a specific CPU model.
It looks as if SSE-AVX transition penalties appear when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
--- Comment #8 from Alexander Monakov ---
Or as Jakub (thanks!) noted on IRC, gcc/auto-host.h from the build tree may be
also helpful and simpler for us to work with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
--- Comment #7 from Alexander Monakov ---
The testcase is not easily reproducible because the rs6000 backend has some
implicit dependencies on capabilities of configure-time binutils, and they are
not visible as 'gcc -v' flags.
So, to reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
Alexander Monakov changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
Bug 84659 depends on bug 85354, which changed state.
Bug 85354 Summary: [8 regression] ICE with gcc.dg/graphite/pr84872.c starting
with r259313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354
--- Comment #4 from Alexander Monakov ---
Author: amonakov
Date: Thu Apr 12 15:40:44 2018
New Revision: 259348
URL: https://gcc.gnu.org/viewcvs?rev=259348=gcc=rev
Log:
sel-sched: move cleanup_cfg before calculate_dominance_info (PR 85354)
Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot
gnu.org
--- Comment #1 from Alexander Monakov ---
Thanks. Judging from the backtrace, we shouldn't call cleanup_cfg after
dominators are computed: it will invalidate dominators without freeing or
fixing them. I wonder if that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
Bug 82407 depends on bug 84566, which changed state.
Bug 84566 Summary: error: qsort comparator not anti-commutative: -1, -1 on
aarch64 in sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 84566, which changed state.
Bug 84566 Summary: error: qsort comparator not anti-commutative: -1, -1 on
aarch64 in sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
What|Removed
at gcc dot gnu.org |amonakov at gcc dot
gnu.org
Summary|[6/7/8 Regression] ICE in |[6/7 Regression] ICE in
|create_pre_exit, at |create_pre_exit, at
|mode-switching.c:451|mode-switching.c:451
Known to fail|8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
--- Comment #4 from Alexander Monakov ---
Author: amonakov
Date: Wed Apr 11 14:36:04 2018
New Revision: 259322
URL: https://gcc.gnu.org/viewcvs?rev=259322=gcc=rev
Log:
sched-deps: respect deps->readonly in macro-fusion (PR 84566)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Wed Apr 11 14:32:32 2018
New Revision: 259321
URL: https://gcc.gnu.org/viewcvs?rev=259321=gcc=rev
Log:
sched-rgn: run add_branch_dependencies for sel-sched (PR 84301)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
Alexander Monakov changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
--- Comment #4 from Alexander Monakov ---
Author: amonakov
Date: Wed Apr 11 10:48:42 2018
New Revision: 259314
URL: https://gcc.gnu.org/viewcvs?rev=259314=gcc=rev
Log:
fix PR 84659 references in ChangeLog files
Modified:
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
I expected predcom to eliminate one of the loads in this loop at -O3:
int is_sorted(int *a, int n)
{
for (int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #13 from Alexander Monakov ---
> (in the diffs, plus-lines correspond to -Wnonnull added to command line)
No, sorry, it was the other way around. Here's the reverse diff with more
context:
if (0)
{
<;
}
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #12 from Alexander Monakov ---
I can reproduce it with downloaded Debian's cc1plus, and for me -Wnonnull alone
is sufficient to cause diverging codegen. It diverges very early, in the
frontend: diff of .tu dumps starts with:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84861
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
The following code (derived from a hot loop in a Huffman encoder, reported by
Fabian Giesen) suffers from TER activity too much on x86-64. TER lifts
loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
--- Comment #2 from Alexander Monakov ---
Bah, built a wrong branch, not the trunk. I'll recheck later, sorry for the
noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
--- Comment #1 from Alexander Monakov ---
Sorry, I cannot reproduce this. I've built a cross-compiler from today's trunk
via 'configure --target aarch64-linux-gnu && make all-gcc' (i.e. just to
cc1plus, no binutils etc.) and it doesn't abort.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301
--- Comment #4 from Alexander Monakov ---
Moreover, without --param selsched-max-lookahead=2 sel-sched moves both the
assignment and use into middle of BB 2, breaking the assumption in
mode-switching that retval use is the last insn:
249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84191
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
--- Comment #7 from Alexander Monakov ---
Code in comment #0 is also valid, it's just rather questionable (the octal
literal is \00) and most likely unintended (or intentionally misleading).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 43272
--> https://gcc.gnu.org/bugzilla/attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83913
--- Comment #2 from Alexander Monakov ---
Thanks. While I could not find why we blow up with Haswell tuning but not say
Sandybridge, the main problem is that with all those -fno-... flags we have a
few insns of the form rK = rN where rN is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83573
Alexander Monakov changed:
What|Removed |Added
Summary|[8 Regression] invalid |[6/7/8 Regression] invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83513
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
Bug 82407 depends on bug 83513, which changed state.
Bug 83513 Summary: [8 Regression] ICE: qsort checking failed (error: qsort
comparator non-negative on sorted output: 3) in fill_vec_av_set in selective
scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83513
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Tue Dec 26 14:34:33 2017
New Revision: 256001
URL: https://gcc.gnu.org/viewcvs?rev=256001=gcc=rev
Log:
sel-sched: fix zero-usefulness case in sel_rank_for_schedule (PR 83513)
|UNCONFIRMED |NEW
Last reconfirmed||2017-12-25
CC||amker at gcc dot gnu.org,
||amonakov at gcc dot gnu.org
Summary|Wrong constant folding |[8
701 - 800 of 1128 matches
Mail list logo
