https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93663
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93662
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
--- Comment #10 from Marc Glisse ---
Flags like -ftrapping-math can prevent gcc from folding at compile-time when
the result is infinite (or maybe it always refuses to fold in that case). In
your example, gcc generates a runtime call to __muldc3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90691
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:dfffecb802681fbdb56629d3bdd96491ac660be0
commit r10-6572-gdfffecb802681fbdb56629d3bdd96491ac660be0
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93650
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:dfffecb802681fbdb56629d3bdd96491ac660be0
commit r10-6572-gdfffecb802681fbdb56629d3bdd96491ac660be0
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
--- Comment #3 from Eric Niebler ---
> Is this a duplicate / variant of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516?
Bug 93516 is not triggered by [[no_unique_addresss]] and the ICE is not on the
same line. That's why I created a new i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Bug ID: 93672
Summary: std::basic_istream::ignore hangs if delim MSB is set
Product: gcc
Version: 9.1.0
URL: https://stackoverflow.com/questions/60140947/stdbasic-
ist
;
}
return result;
}
---
gcc10_trunk test.c -S -O0 -mavx512f
error:
#1 with x86-64 gcc (trunk)
In file included from
/opt/compiler-explorer/gcc-trunk-20200211/lib/gcc/x86_64-linux-gnu/10.0.1/include/immintrin.h:55,
from :1:
: In function '__mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93673
--- Comment #1 from Hongtao.liu ---
Affected instrinsics
_kshiftli_mask16
_kshiftri_mask16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Guenther :
https://gcc.gnu.org/g:9714f1a70d184fb6d282ac543c57734ed1fb39ac
commit r10-6573-g9714f1a70d184fb6d282ac543c57734ed1fb39ac
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93662
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Guenther :
https://gcc.gnu.org/g:9714f1a70d184fb6d282ac543c57734ed1fb39ac
commit r10-6573-g9714f1a70d184fb6d282ac543c57734ed1fb39ac
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
--- Comment #10 from Tony E Lewis ---
I confirm that my testcase remains fixed on the Godbolt build of g++ trunk
("20200210").
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Guenther :
https://gcc.gnu.org/g:667afe5a49ccb73947c6b895780d266f4a4dac73
commit r10-6574-g667afe5a49ccb73947c6b895780d266f4a4dac73
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93662
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Guenther :
https://gcc.gnu.org/g:667afe5a49ccb73947c6b895780d266f4a4dac73
commit r10-6574-g667afe5a49ccb73947c6b895780d266f4a4dac73
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93662
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #20 from Jakub Jelinek ---
Created attachment 47814
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47814&action=edit
gcc10-pr93582-wip.patch
WIP patch, so far only the store covering all the bits (the reconstruction from
pieces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||mark.eggleston at codet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92196
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #21 from Richard Biener ---
The shift_bytes_in_array_{left,right} routines should go next to
native_{encode,interpret} where maybe also a comment should indicate how to
combine both?
The vn_reference_lookup_3 part looks OK to me, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Bug ID: 93674
Summary: GCC eliminates conditions it should not, when
strict-enums is on
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
--- Comment #12 from CVS Commits ---
The releases/gcc-8 branch has been updated by Tamar Christina
:
https://gcc.gnu.org/g:0e35a433f8ec02ac46eb5ceb4a9bc6a25e88b05c
commit r8-9975-g0e35a433f8ec02ac46eb5ceb4a9bc6a25e88b05c
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
--- Comment #13 from CVS Commits ---
The releases/gcc-9 branch has been updated by Tamar Christina
:
https://gcc.gnu.org/g:f6e9ae4da8f040ab2ef2eb37d0fb4da6f823bf81
commit r9-8210-gf6e9ae4da8f040ab2ef2eb37d0fb4da6f823bf81
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
--- Comment #4 from Jonathan Wakely ---
I think it's required by http://eel.is/c++draft/new.delete#single-12 and
http://eel.is/c++draft/new.delete#array-11 which says you have to use the
matching form. delete must be used with new, and delete[] m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #22 from Jakub Jelinek ---
(In reply to Richard Biener from comment #21)
> The shift_bytes_in_array_{left,right} routines should go next to
> native_{encode,interpret} where maybe also a comment should indicate how to
> combine both?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
--- Comment #5 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #3)
> I found http://eel.is/c++draft/expr.delete#2 but for the non-array delete it
> talks about previous new-expression, which even the array one is.
Although it do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
--- Comment #6 from Jonathan Wakely ---
Although "a pointer to a non-array object created by a previous new-expression"
does rule out arrays created by an array new-expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #23 from rguenther at suse dot de ---
On Tue, 11 Feb 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
>
> --- Comment #22 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #1 from Andrew Pinski ---
-fstrict-enums
Allow the compiler to optimize using the assumption that a value of enumerated
type can only be one of the values of the enumeration (as defined in the C++
standard; basically, a value that can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93663
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #2 from Gábor Buella ---
(In reply to Andrew Pinski from comment #1)
> -fstrict-enums
> Allow the compiler to optimize using the assumption that a value of
> enumerated type can only be one of the values of the enumeration (as defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #3 from Gábor Buella ---
In case anyone would still get confused about the what values get casted to
enum, here is another way to write that example:
enum some_enum { x0, x1, x2, x3, x4, x5, x6, x7,
x8, x9,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93673
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93650
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
Bug ID: 93675
Summary: Starship operator on a hidden friend operator does not
work
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264
--- Comment #3 from Richard Biener ---
In general it's a bad idea to try go "back" to CFG layout mode and the fix is
to not do that. Which probably means scheduling pass_sms earlier and indeed
then best before pass_partition_blocks. I don't see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93673
--- Comment #2 from H.J. Lu ---
Something like this:
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 902ea318999..b3b6552e13b 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1650,7 +1650,7 @@ (define_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93673
--- Comment #3 from Jakub Jelinek ---
Created attachment 47816
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47816&action=edit
gcc10-pr93673.patch
I meant this actually. QImode for const_0_to_255_operand is wrong, because
QImode CONST_IN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
Bug ID: 93676
Summary: crash in build_value_init
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #4 from Jonathan Wakely ---
I can't reproduce this with GCC 9, only 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #5 from Richard Earnshaw ---
I'm seeing it on AArch64 for master. Adding an enum value with an initializer
of -1 causes the problem to go away. So it looks like the 'unsigned'
conversion is happening too soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #6 from Gábor Buella ---
(In reply to Jonathan Wakely from comment #4)
> I can't reproduce this with GCC 9, only 8.
$ cat code.cc
enum some_enum { x = 1000 };
void sink(some_enum);
void func()
{
for (int i = 0; i < 3; ++i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93670
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93669
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93677
Bug ID: 93677
Summary: Create a warning for duplicate macro definition
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93670
--- Comment #2 from Jakub Jelinek ---
Created attachment 47817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47817&action=edit
gcc10-pr93670.patch
VL vs. DQ vs. BW where only one or two but not all 3 are enabled is a mess :(.
The extracti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
Bug ID: 93678
Summary: ICE in 9.2/9.2.1 not happening in previous gfortran
versions
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #152 from Peter Bisroev ---
(In reply to David Malcolm from comment #151)
> (In reply to Peter Bisroev from comment #139)
>
> [...]
>
> > I am not sure how these selftests work yet but will take a look into them to
> > see if we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93679
Bug ID: 93679
Summary: gccgo cannot bootstrap go1.14
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Jakub Jelinek changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #9 from Jakub Jelinek ---
Basically, I think ivopts should try to avoid using types which have lower
TYPE_PRECISION or TYPE_MIN_VALUE/TYPE_MAX_VALUE that is not the minimum or
maximum value of the corresponding precision, unless all o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
Marek Polacek changed:
What|Removed |Added
Known to work||4.9.4
--- Comment #2 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93680
Bug ID: 93680
Summary: [GCOV] "do-while" structure in case statement leads to
incorrect code coverage
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #153 from Peter Bisroev ---
Hi Everyone, just wanted to give you an update on where I am at the moment.
Unfortunately I did not have much time to dig into this more, but last night
while trying to figure out what is causing those ICE
tributes -m32 -march=i686 -O3
test.c && ./a.out
z = 0
z is one
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--
ot;z = %d\n", z);
}
}
--
$ gcc -std=gnu11 -pedantic -Wall -Wextra -m32 -march=i686 -O3 test.c && ./a.out
z = 0
z = 1
--
gcc x86-64 version: gcc (GCC) 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- C
-
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--
All the same but the computation of `i` is hoisted from the `if` in the
133t.pre pass so dom3 doesn't have a chance to fold it.
Another interesting aspect:
---
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--
p;
./a.out
one = 0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #22 from Alexander Cherepanov ---
(In reply to jos...@codesourcery.com from comment #11)
> Yes, I agree that any particular conversion to integer executed in the
> abstract machine must produce some definite integer value for each
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #23 from Alexander Cherepanov ---
(In reply to Alexander Monakov from comment #10)
> Also note that both the original and the reduced testcase can be tweaked to
> exhibit the surprising transformation even when -fexcess-precision=stan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
--- Comment #3 from Marek Polacek ---
We hit this assert in build_value_init:
/* The AGGR_INIT_EXPR tweaking below breaks in templates. */
gcc_assert (!processing_template_decl
|| (SCALAR_TYPE_P (type) || TREE_CODE (type) == A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
--- Comment #8 from Andreas Schwab ---
Yes, nothing has changed.
test.c
during RTL pass: mach
lz4_decompress.c:10:1: internal compiler error: in sel_target_adjust_priority,
at sel-sched.c:3334
10 | }
Reproduced both with 9.2 and current HEAD
$ ia64-linux-gcc --version
ia64-linux-gcc (GCC) 9.2.1 20200211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93682
--- Comment #2 from Rich Felker ---
I think the underlying issue here is just that -mpc64 (along with -mpc32) is
just hopelessly broken and should be documented as such. It could probably be
made to work, but there are all sorts of issues like fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #154 from dave.anglin at bell dot net ---
On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> We already know that we currently cannot compile stage1 with -O0 as it causes
> binaries to become huge and we get PCREL21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #155 from Peter Bisroev ---
(In reply to dave.anglin from comment #154)
> On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> > We already know that we currently cannot compile stage1 with -O0 as it
> > causes
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #15 from Alexander Monakov ---
This should not be reproducible with current HEAD because the assert was simply
eliminated. If GCC master definitely fails, can you please provide the exact
diagnostic?
As for 9.2 this is sadly expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #156 from dave.anglin at bell dot net ---
On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> However the above can be compiled with -O0 with the same compiler. So I
> changed
> my build line to use -O0 as well:
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #157 from dave.anglin at bell dot net ---
On 2020-02-11 12:27 p.m., peter.bisroev at groundlabs dot com wrote:
> Just to confirm though, using gcc 4.7.4 that I have previously compiled with
> aCC that adequately passed 'make check' tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
--- Comment #6 from Peter Bergner ---
So we are in an infinite loop in process_address() calling process_address_1().
I've hacked in some code to ICE if we loop for too long and I'm currently
using creduce to minimize the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93634
--- Comment #1 from Cassio Neri ---
FYI, this is what clang trunk generates:
imull $-1431655765, %edi, %eax # imm = 0xAAAB
addl $1431655764, %eax # imm = 0x5554
rorl %eax
cmpl $715827882, %eax # imm = 0x2AAA
setb %al
retq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #158 from Peter Bisroev ---
(In reply to dave.anglin from comment #156)
> On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> > However the above can be compiled with -O0 with the same compiler. So I
> > changed
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #159 from Peter Bisroev ---
(In reply to dave.anglin from comment #157)
> On 2020-02-11 12:27 p.m., peter.bisroev at groundlabs dot com wrote:
> > Just to confirm though, using gcc 4.7.4 that I have previously compiled with
> > aCC th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #16 from Arnd Bergmann ---
Right, I was on the releases/gcc-9 branch, not HEAD. Sorry about the confusion.
I applied your fix and have a working 9.2 build that can build the kernel now.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
--- Comment #4 from Marek Polacek ---
A bit shorter test:
struct P {
int x = 0;
};
template
struct S {
S() { new P[2][2]; }
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Wilco changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657
--- Comment #4 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:5e17c1bdadbbd5606d869b1178ed3e653f931cda
commit r10-6579-g5e17c1bdadbbd5606d869b1178ed3e653f931cda
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93649
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:cd28b75921354c64fd4c8a1c238991e522abc38e
commit r10-6580-gcd28b75921354c64fd4c8a1c238991e522abc38e
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93669
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:a0e4929b0461226722d6d08b1fdc2852b9100b75
commit r10-6581-ga0e4929b0461226722d6d08b1fdc2852b9100b75
Author: David Malcolm
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93374
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:a60d98890bba58649c26c2fc0c6f28cd6073aaaf
commit r10-6582-ga60d98890bba58649c26c2fc0c6f28cd6073aaaf
Author: David Malcolm
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93669
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93649
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 169 matches
Mail list logo
