https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93693
Bug ID: 93693
Summary: [GCOV] incorrect coverage when compiled with option
'-fsanitize=undefined' for function defined inside
other function
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93692
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
--- Comment #38 from Andrew Pinski ---
(In reply to Wilco from comment #37)
> (In reply to Andrew Pinski from comment #36)
> > MIPS is still broken. I might look into MIPS brokenness next week.
>
> Yes it seems builtin_longjmp has the exact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #9 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:91f993b7e31ce85676148dca180bc0d827d4245e
commit r10-6590-g91f993b7e31ce85676148dca180bc0d827d4245e
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
David Malcolm changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #25 from Rich Felker ---
I think standards-conforming excess precision should be forced on, and added to
C++; there are just too many dangerous ways things can break as it is now. If
you really think this is a platform of dwindling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #13 from Segher Boessenkool ---
nonzero_bits is not reliable. We also cannot really do what you propose
here, all of this is done for *every* combination.
We currently generate
(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93692
--- Comment #3 from Andrew Pinski ---
The documentation does describe more what super means :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93626
--- Comment #2 from Yibiao Yang ---
(In reply to Martin Liška from comment #1)
> I would not recommend combining --coverage and a sanitizer.
Thanks for the suggestion. Yes, this is an abnormal combination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93692
--- Comment #2 from Andrew Pinski ---
Note there is a -fdump-analyzer-supergraph so it looks like there is a copy and
paste issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052
Kewen Lin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93682
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 11 Feb 2020, bugdal at aerifal dot cx wrote:
> I think the underlying issue here is just that -mpc64 (along with -mpc32) is
> just hopelessly broken and should be documented as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:d6ef77e023cfe0bb3b12b88ae46b77da356d7f85
commit r10-6586-gd6ef77e023cfe0bb3b12b88ae46b77da356d7f85
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93690
Florian Schiffmann changed:
What|Removed |Added
CC||floschiffmann at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694
Bug ID: 93694
Summary: Inconsistent grammar in darwin.opt
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93212
--- Comment #6 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:35e24106fc1b782e70f8339e0a1321a2bc7a7f15
commit r10-6588-g35e24106fc1b782e70f8339e0a1321a2bc7a7f15
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #8 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:35e24106fc1b782e70f8339e0a1321a2bc7a7f15
commit r10-6588-g35e24106fc1b782e70f8339e0a1321a2bc7a7f15
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93692
Bug ID: 93692
Summary: Possible typo: supergraph vs. callgraph
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695
Bug ID: 93695
Summary: Allocation and freeing memory for array members in
loops is not handled properly by the analyzer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93697
Bug ID: 93697
Summary: pr93661.c does not warn on (32-bit) powerpc-linux
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #11 from pmatos at gcc dot gnu.org ---
(In reply to David Malcolm from comment #10)
> Should be fixed by the above commit.
David, does this mean the analyzer has C++ support now or just that this
specific bug is fixed in-tree?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93690
--- Comment #2 from Florian Schiffmann ---
Hi Steve,
the complication here is that it is not the type with the assignment that is a
vector but the Outer type. The type with assignment is a scalar member of the
vector type. Hence the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #24 from joseph at codesourcery dot com ---
On Tue, 11 Feb 2020, ch3root at openwall dot com wrote:
> So, yeah, it seems integers have to be stable. OTOH, now that there is sse and
> there is -fexcess-precision=standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052
--- Comment #16 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:4d2248bec5d22061ab252724bd59d45c8a47e009
commit r10-6591-g4d2248bec5d22061ab252724bd59d45c8a47e009
Author: Kewen Lin
Date: Tue Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694
--- Comment #1 from Roland Illig ---
double space:
> architecture \"name\"
unnecessarily verbose:
> Specify that the output file should be generated for architecture "name"
Why not simply: Generate output file for the named architecture.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
--- Comment #2 from Mateusz Pusz ---
Thanks!
Mat
śr., 12 lut 2020, 01:09 użytkownik cvs-commit at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> napisał:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
>
> --- Comment #1 from CVS Commits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93696
Bug ID: 93696
Summary: AVX512VPOPCNTDQ writemask intrinsics produce incorrect
results
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
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
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
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=92196
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
--- 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[]
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=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=93662
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
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=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,
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=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=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=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
;
}
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 '__mmask16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||mark.eggleston at
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=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
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-
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
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=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:
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:
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=edit
gcc10-pr93582-wip.patch
WIP patch, so far only the store covering all the bits (the reconstruction from
pieces could
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=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
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=edit
gcc10-pr93673.patch
I meant this actually. QImode for const_0_to_255_operand is wrong, because
QImode CONST_INTs are
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=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=93670
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93663
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=93264
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
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=93673
Jakub Jelinek 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 #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=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=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
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
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
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=85957
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
---
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) ==
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
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
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
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
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
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
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=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=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
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)
--
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=93677
Bug ID: 93677
Summary: Create a warning for duplicate macro definition
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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=edit
gcc10-pr93670.patch
VL vs. DQ vs. BW where only one or two but not all 3 are enabled is a mess :(.
The extraction
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
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
1 - 100 of 169 matches
Mail list logo
