https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119845
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119774
Bug ID: 119774
Summary: Missing -Wcast-align for reduced-alignment types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119733
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #56 from Alexander Monakov ---
I think you mean -fno-plt, not -mno-plt (here and your previous comment)?
Ideally we would be able to express a relocation to PLT, but without admitting
lazy binding (i.e. the trampoline will be in .pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #54 from Alexander Monakov ---
I think the x86_64 behavior is simply copied as-is from i386.
On i386, there was a time when Glibc wouldn't preserve eax+ecx+edx in the PLT
trampoline, but preserving those became necessary when GCC ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #51 from Alexander Monakov ---
Michael, can you give your ack/nack for Ard's proposal in comment #24 (the
second variant, I guess keying off -m[no-]direct-extern-access doesn't make
sense here). I think it properly addresses what you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #49 from Alexander Monakov ---
Aha, and I see the kernel employs the trick of preincluding a file containing '
'#pragma GCC visibility push(hidden)' when building PIE objects since 2020. So
the mcount-emitting macro in the i386 backe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #47 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #43)
> Non-PIC might be more efficient, but there are cases where we cannot use it.
> The early startup code on x86 runs from a different virtual mapping than it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #46 from Alexander Monakov ---
A small correction: -static-pie is not a linker option, it's a gcc (compiler
driver) option, which it decomposes into -static -pie --no-dynamic-linker -z
text for the linker; --no-dynamic-linker was add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #44 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #43)
> arch/arm64/Makefile specifies '-shared' for the linker flags, but does not
> pass -fpic of -fpie to the compiler. We used to pass '-pie -shared' but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #42 from Alexander Monakov ---
> In Linux, we don't even bother with PIC codegen, even though we link with
> -pie.
My git-grep for that is coming up empty, where should I look?
> ... on x86_64, where PIC and non-PIC codegen are r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #40 from Alexander Monakov ---
> In Linux, we don't even bother with PIC codegen, even though we link with
> -pie.
Earlier you said that building with -fPIC may be desirable, and your patch was
dealing with PIC codegen in GCC for m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #38 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #37)
> Yes, we can drop -mcmodel=kernel, and use -mcmodel=small instead. This is
> why I'm not keen on relying on that - it is ill-defined and there is really
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #36 from Alexander Monakov ---
Today, gcc rejects -fpic -mcmodel=kernel on the command line though, and it
doesn't look like you can drop -mcmodel=kernel, so... was there some plan for
dealing with that?
(considering new flags to co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #34 from Alexander Monakov ---
We have -mcmodel=kernel already, which is incompatible with -fpic.
Ard, where is -fpic in the kernel context coming from? Kernel's top-level
Makefile passes -fno-PIE, and arch/x86/Makefile passes -mcmo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #30 from Alexander Monakov ---
Sorry, sent too soon: a.out had the concept of PLT as well as GOT:
https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.c?id=c98f874233428d7e6ba83def7842fd703ac0ddf1#n820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #31 from Alexander Monakov ---
I am certainly missing some interesting history here, because on one hand, I
see that a.out uses call-pop combo in function prologue to find out current PC,
and then uses %ebx-relative addressing in PIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #29 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #21)
> GOT indirection for mcount has been there from the very beginning:
> https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.
> h?id=c98f874233428d7e6ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #21 from Alexander Monakov ---
GOT indirection for mcount has been there from the very beginning:
https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.h?id=c98f874233428d7e6ba83def7842fd703ac0ddf1#n623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #25 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #24)
> - never emit 'call mcount'
> - emit 'call *mcount@GOTPCREL(%rip)' if -fno-plt
> - emit 'call mcount@PLT' otherwise
As discussed, gcc was always using GOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #23 from Alexander Monakov ---
That's probably just copying existing behavior from 32-bit x86.
Can we preserve previous behavior that under -fpic -mno-direct-extern-access
mcount is called via GOT (and else emit mcount@PLT if -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #19 from Alexander Monakov ---
The question is why prior to your patch GCC emitted mcount@GOT (i.e. avoiding
the PLT trampoline for mcount on purpose), going all the way back to gcc-3.4
(and probably further).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #15 from Alexander Monakov ---
Any idea why prior to introduction of this bug, gcc always emitted a
GOT-indirect call for mcount? It looks like it is avoiding lazy PLT resolver,
but why is that necessary?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119368
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #36 from Alexander Monakov ---
We can flip the default from =fast to =on for -std=gnuXX any time we like, but
it must remain at =off for =std=cXX as long as STDC FP_CONTRACT pragma is not
implemented.
I have not attempted any mass r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118818
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118570
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #10 from Alexander Monakov ---
Yeah, I would expect compare_operand to be the proper place for a fix, not its
callers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926
--- Comment #5 from Alexander Monakov ---
Thanks, here's a variant of the small testcase that fails on gcc-14 too, just
needed to make the integer field the first in the struct:
struct s {
int i[2];
float f[2];
double d;
};
void f(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926
Bug ID: 117926
Summary: [15 Regression] emits MMX from autovectorized GIMPLE
without emms at -O2
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117469
--- Comment #4 from Alexander Monakov ---
The code in comment #3 is invalid: siglongjmp is called when the state saved in
env is no longer valid: plat_setjmp has returned (and the stack slot where its
return address is stored is overwritten).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117421
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
--- Comment #22 from Alexander Monakov ---
*** Bug 117532 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532
Alexander Monakov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117469
--- Comment #2 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #1)
> So if the tail-call uses [[musttail]] the alternative 3 should be "fine"?
Yes, plus annotating the callees that return twice with the attribute is still
require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117469
Bug ID: 117469
Summary: returns_twice on defined functions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #6 from Alexander Monakov ---
compare_operand is used in compare_asm_inputs_outputs, so this is broken too:
void foo32(void) {
asm("" :: "r"(-1));
}
void foo64(void) {
asm("" :: "r"(-1LL));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #1 from Alexander Monakov ---
Created attachment 59528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59528&action=edit
executable testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
Bug ID: 117432
Summary: [11/12/13/14/15 Regression] IPA ICF disregards types
of variadic arguments
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
--- Comment #12 from Alexander Monakov ---
On IRC Jakub mentioned gcc_assert (token() == TYPEDEF) in gengtype and Richi
further noted
tree-ssa-loop-ivopts.cc:gcc_assert (use->op_p = gimple_call_arg_ptr (call, 0));
cgraph.cc: gcc_assert (++edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #2)
> Alternatively,
> changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduce with PIE as well.
^
I meant 'if (o.i ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
--- Comment #2 from Alexander Monakov ---
Amazing bug. Note that it depends on high-order bits of return address
overwriting o.i, so may need -no-pie -fno-pie to reproduce. Alternatively,
changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #15 from Alexander Monakov ---
No, I didn't do older AMDs (btver2 & bdver3) and newer AMD (znver4) regressed
this once again. Here's the current picture of top 10:
nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116947
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
--- Comment #11 from Alexander Monakov ---
> It only handles switch statements, not computed gotos.
Oh, right, apologies for misunderstanding your question like that. For computed
gotos it is indeed not so easy, especially if there is more than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
--- Comment #9 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #8)
> Is there any pointer how to implement this instead?
It may be sufficient to change
(define_insn "@tablejump"
[(set (pc)
(match_operand:P 0 "register_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #12 from Alexander Monakov ---
Thanks. It's probably nicer to deduplicate computation of required padding to a
common header (libcpp/internal.h), I'll send a patch to that effect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #9 from Alexander Monakov ---
Okay, if you take the addition and the branch from the inlined variant:
addl %eax, %edx
je .L3
and add a 'test' instruction:
addl %eax, %edx
test %edx, %edx
je .L3
then Valgrind doesn't complain. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #8 from Alexander Monakov ---
Thanks for the reference, but it doesn't help. Something more subtle is going
on, because placing the shift-add combo in a separate function makes Valgrind
properly compute known bits even without the ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #6 from Alexander Monakov ---
As for Valgrind false positive, it handles this SSSE3 code really well and
misses the key point by a very narrow margin. We have
found = m1 + (m2 << 16);
where both m1 and m2 hold 16-bit masks from p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #3 from Alexander Monakov ---
David, thanks for Cc'ing me and for running Valgrind builds!
Richi, I'll check in more detail later today, I think we should unbreak
Valgrind builds ASAP by initializing padding under #ifdef
ENABLE_VALG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #15 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Alexander Monakov from comment #13)
> > fldt does not convert (otherwise there's no way to spill/reload x87
> > registers).
>
> Doesn't it st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #26 from Alexander Monakov ---
(In reply to Richard Biener from comment #24)
>
> That's because of -fno-vect-cost-model, it wouldn't be vectorized otherwise.
Thanks, I forgot. The testcase in PR 106902 was vectorized at plain -O3 b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #23 from Alexander Monakov ---
I suggest it to close this a dup of PR 106902 if there are no better ideas.
By the way, in both cases SLP introduces vectors in a loop where scalar
computations it's attempting to replace are not elimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #22 from Alexander Monakov ---
Similar to the RawTherapee issue, SLP opportunities are created by predcom, so
either -fno-predictive-commoning or -fno-tree-slp-vectorize avoids numerical
runaway on the small testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #20 from Alexander Monakov ---
Sam, can you provide more context? It seems there is no downstream bugreport?
How does the alleged miscompilation manifest?
Note that effects of interplay of fp-contract=fast and vectorization can be
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115333
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #23 from Alexander Monakov ---
(In reply to Sergei Trofimovich from comment #22)
> Here `pcmpeqd %xmm2,%xmm1` is a problematic instruction. Why does `gcc` use
> `%xmm2` (result of `cvttps2dq`) instead of, say `%xmm0` which contains
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #20 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #19)
> If we guarantee that we never constant fold FIX/UNSIGNED_FIX with
> -ftrapping-math (we shouldn't, as the exceptions should be raised), then
> using FIX/UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #18 from Alexander Monakov ---
No, allowing value-changing transformations under -ftrapping-math is really not
appropriate. Invoking the intrinsic on a large floating-point value is not UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115132
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944
--- Comment #4 from Alexander Monakov ---
Like this:
pandxmm1, XMMWORD PTR .LC0[rip]
movaps XMMWORD PTR [rsp-40], xmm0
xor eax, eax
xor edx, edx
movaps XMMWORD PTR [rsp-24], xmm1
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114960
Bug ID: 114960
Summary: [12/13/14/15 Regression] fails to clean up vector
casts
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #4 from Alexander Monakov ---
You can place points of possible access outside of abstract machine in a
fine-grained manner with volatile asms:
asm volatile("" : "=m"(buf));
This cannot be reordered against accesses to volatile va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #21 from Alexander Monakov ---
It is possible to reduce gcc_qsort workload by improving the presorted-ness of
the array, but of course avoiding quadratic behavior would be much better.
With the following change, we go from
261,2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #20 from Alexander Monakov ---
(note that if you uninclude the testcase and compile with -fno-exceptions it's
much faster)
On the smaller testcase from comment 14, prune_unused_phi_nodes invokes
gcc_qsort 53386 times. There are two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #10 from Alexander Monakov ---
Indeed, but OTOH according to bug 84402 comment 58 it caused a noticeable hit
on gimple-match.cc compilation:
733a1b777f16cd397b43a242d9c31761f66d3da8 13th January 2023
sched-deps: do not schedule pseu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #8 from Alexander Monakov ---
If we want to get rid of the compilation time regression sooner rather than
later, I can suggest limiting my change only to functions that call setjmp:
diff --git a/gcc/sched-deps.cc b/gcc/sched-deps.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
Alexander Monakov changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #3 from Alexander Monakov ---
The first attachment is empty (perhaps you made a non-recursive archive when
you meant to recursively zip a directory).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487
--- Comment #28 from Alexander Monakov ---
The bug is about the issue of lacking diagnostics, it should be fine to make
note of various approaches to remedy the problem in one bug report.
(in any case, all discussion of the Valgrind-based approa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113890
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113293
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
1 - 100 of 448 matches
Mail list logo
