https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
Bug ID: 93865
Summary: .debug_line with LTO refers to bogus file-names
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #21 from Andrew Pinski ---
(In reply to Oleg Endo from comment #20)
> (In reply to Andrew Pinski from comment #19)
> > t = (const uintptr_t *)(e - (4 -1));
> >
> > is problemantic though. e is not known to be aligned to uintptr_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #20 from Oleg Endo ---
(In reply to Andrew Pinski from comment #19)
> t = (const uintptr_t *)(e - (4 -1));
>
> is problemantic though. e is not known to be aligned to uintptr_t.
That's right. But it makes me wonder, why this h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87488
--- Comment #24 from WHR ---
Looks like commit r10-6643-g458c8d6459c4005fc9886b6e25d168a6535ac415 is a well
fix, and my terminal is no longer nosiy running GCC 10.
I have a suggestion, consider check for a few more 'TERM' types that would
certai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93861
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic, easyhack
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93860
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic, easyhack
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
--- Comment #15 from Andrew Pinski ---
(In reply to rguent...@suse.de from comment #13)
> On February 21, 2018 2:13:22 PM GMT+01:00, "egallager at gcc dot gnu.org"
> wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
> >
> >Eric Gallag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #16 from Alexander Cherepanov ---
On 21/02/2020 03.40, vincent-gcc at vinc17 dot net wrote:
> Concerning -fno-signed-zeros, your code has undefined behavior since the sign
> of zero is significant in "1 / x == 1 / 0.", i.e. changing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386
Jeffrey A. Law changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93589
--- Comment #9 from John Downing ---
(In reply to Jason Merrill from comment #7)
> Rather, it was suppressed for the simple case where the RHS has a suitable
> type. As Jonathan says, (CHAR_BIT * static_cast(i)) has type int (it
> would be unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #15 from Vincent Lefèvre ---
Note that there are very few ways to be able to distinguish the sign of zero.
The main one is division by zero. Other ones are:
* Conversion to a character string, e.g. via printf(). But in this case, if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93589
--- Comment #8 from John Downing ---
> (In reply to John Downing from comment #5)
> > This will generate a warning, for the char and short cases, when the "|="
> > happens. This is despite "val" being explicitly declared as a char or an
> > sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #14 from Rich Felker ---
Indeed, without Anenx F, division by zero is UB, so it's fine to do anything if
the program performs division by zero. So we need examples without division by
zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93863
--- Comment #1 from David Malcolm ---
What version of gcc was this with? This ought to have been fixed by
r10-6667-gf76a88ebf089871dcce215aa0cb1956ccc060895 (for PR analyzer/93388).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #13 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #12)
> To me the meaning of internal consistency is very clear: that the semantics
> of the C language specification are honored and that the only valid
> transformati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #12 from Rich Felker ---
To me the meaning of internal consistency is very clear: that the semantics of
the C language specification are honored and that the only valid
transformations are those that follow the "as-if rule". Since C w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #11 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #10)
> I don't think it's at all clear that -fno-signed-zeros is supposed to mean
> the programmer is promising that their code has behavior independent of the
> sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #3 from Michael Meissner ---
I looked at this a little. The proposed patch doesn't generate the expected
code any more (due to setting the length attribute, which makes it look like
the fix generates slower code).
I re-implemented i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #10 from Rich Felker ---
I don't think it's at all clear that -fno-signed-zeros is supposed to mean the
programmer is promising that their code has behavior independent of the sign of
zeros, and that any construct which would be influ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #9 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #8)
> A similar problem happens with -fno-signed-zeros -fno-trapping-math. Not
> sure if a separate PR should be filed...
Concerning -fno-signed-zeros, your c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #19 from Andrew Pinski ---
t = (const uintptr_t *)(e - (4 -1));
is problemantic though. e is not known to be aligned to uintptr_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93862
--- Comment #2 from Marek Polacek ---
In build_static_cast_1:
7397 tree lref = cp_build_reference_type (TREE_TYPE (type), false);
7398 result = (perform_direct_initialization_if_possible
7399 (lref, expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93862
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #18 from Oleg Endo ---
(In reply to Andrew Pinski from comment #17)
> In the original code we have:
> if ((uintptr_t)p % 4) {
> int l = 4 - (uintptr_t)p % 4;
> p += l;
> switch (l) {
>
> l range should be 0...3
Ha!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93864
Bug ID: 93864
Summary: typo: paramter
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: una
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93863
Bug ID: 93863
Summary: internal compiler error: unhandled tree code in
region_model::get_lvalue_1: ‘integer_cst’
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93862
Bug ID: 93862
Summary: ICE on static_cast of rvalue-reference-to-array of
unknown bound [P0338] to its known static bound
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93861
Bug ID: 93861
Summary: typo in warning: %qs is not valid for
%
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93814
--- Comment #3 from kargl at gcc dot gnu.org ---
Patch is against svn r280157.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/reso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93860
Bug ID: 93860
Summary: darwin: wrong quotation in diagnostic #pragma options
align=reset
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93191
--- Comment #4 from Will Wray ---
Reduced code for deduction of element type
for reference-to-array https://godbolt.org/z/tpkKjN:
int f(auto(&a)[1]);
int g(auto(&a)[ ]);
int test_f = f("");
int test_g = g(""); // error: no match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90966
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #29 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90997
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93801
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93801
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:96cbc56ed96490c58a9800f3e7507758b6602777
commit r10-6768-g96cbc56ed96490c58a9800f3e7507758b6602777
Author: Martin Sebor
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
--- Comment #6 from CVS Commits ---
The releases/gcc-8 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:e4a43b20c564aaca847ae74cc17ca0b48ce6d3ff
commit r8-10042-ge4a43b20c564aaca847ae74cc17ca0b48ce6d3ff
Author: Uros Bizjak
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:bd2537ed5d4cda1a896974f30bd62dfb68ae39b0
commit r9-8260-gbd2537ed5d4cda1a896974f30bd62dfb68ae39b0
Author: Uros Bizjak
Date:
dantic -Wall -Wextra -fno-signed-zeros -fno-trapping-math -O3
test.c && ./a.out
zero = 0
zero = 1
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200220 (experimental)
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93859
Bug ID: 93859
Summary: missing test for diagnostic: the omitted middle
operand will always be true
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93858
Bug ID: 93858
Summary: missing question mark in diagnostic: unknown option
after #pragma GCC diagnostic
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93853
--- Comment #3 from Roland Illig ---
Thanks for the explanation.
Since there are many users of GCC who are not native English speakers, it might
make sense to avoid such complicated grammar. The GCC users should rather
concentrate on fixing thei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
--- Comment #4 from Roland Illig ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Roland Illig from comment #2)
> > While here, the comment style should be made the same in
> > attr-access-read-write.c and attr-access-read-only.c. C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
--- Comment #4 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:d56779b8ae587c599bf46b20587afcd6ee51fcaa
commit r10-6766-gd56779b8ae587c599bf46b20587afcd6ee51fcaa
Author: Uros Bizjak
Date: Thu Fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
--- Comment #3 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:f6088573d81d52e8573b704984fdb515e4391b1a
commit r10-6765-gf6088573d81d52e8573b704984fdb515e4391b1a
Author: Uros Bizjak
Date: Thu Fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93857
--- Comment #1 from Roland Illig ---
I wrote a small example program, which I thought would trigger the diagnostic,
but it didn't do that in GCC 9.2.1.
int main(void) {
if (3 ? 4 : 5) {
return 1;
}
return 0;
}
gcc -Wall -Wex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93857
Bug ID: 93857
Summary: missing test for diagnostic: using integer constants
in boolean context
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #17 from Andrew Pinski ---
In the original code we have:
if ((uintptr_t)p % 4) {
int l = 4 - (uintptr_t)p % 4;
p += l;
switch (l) {
l range should be 0...3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93856
Bug ID: 93856
Summary: missing test for diagnostic: attribute %qs invalid
positional argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
--- Comment #3 from Andrew Pinski ---
(In reply to Roland Illig from comment #2)
> While here, the comment style should be made the same in
> attr-access-read-write.c and attr-access-read-only.c. Currently, one file
> uses /* block comments */ wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
--- Comment #2 from Roland Illig ---
While here, the comment style should be made the same in
attr-access-read-write.c and attr-access-read-only.c. Currently, one file uses
/* block comments */ while the other uses // line-end comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
--- Comment #1 from Roland Illig ---
In addition, I had expected that the %i placeholder were 1-based. From
attr-access-read-only.c:
> int RDONLY (4)
> rdonly_i_i_i_4 (int, int, int);
>// { dg-error "attribute 'access\\(read_only, 4\\)'
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93832
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
Bug ID: 93855
Summary: typo: function argument vs. parameter
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93853
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93853
--- Comment #1 from Andrew Pinski ---
No this is correct english.
It means one or more extra bytes were written.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93851
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93854
Bug ID: 93854
Summary: typo: defined here %qD
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93853
Bug ID: 93853
Summary: typo: writing one too many bytes
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93852
--- Comment #2 from Andrew Pinski ---
These are all diagonstic which normally don't go for normal compilation
including when user has provided invalid code. These are all have an internal
error message after them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93852
--- Comment #1 from Roland Illig ---
> error ("virtual def operand missing for statement");
Curiously, the diagnostic a few lines above this one uses the correct word
"definition".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93852
Bug ID: 93852
Summary: typo: def instead of definition
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70020
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93851
Bug ID: 93851
Summary: FAIL: 20_util/integer_comparisons/equal.cc execution
test
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93850
--- Comment #2 from Andreas Schwab ---
*** Bug 93849 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93849
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93850
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
--- Comment #12 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:e6f24f824beb8ba6805702e287bbd6153b472488
commit r10-6762-ge6f24f824beb8ba6805702e287bbd6153b472488
Author: Peter Bergner
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93825
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:2c52b2884ba10b1c5050fe066bae651680c8ebae
commit r10-6761-g2c52b2884ba10b1c5050fe066bae651680c8ebae
Author: Tobias Burnus
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93850
Bug ID: 93850
Summary: 'stack smashing detected' in the special index for an
array
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
--- Comment #11 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:b82d426662469ee8b78ec7e8f74abe950485c9d5
commit r10-6760-gb82d426662469ee8b78ec7e8f74abe950485c9d5
Author: Peter Bergner
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93849
Bug ID: 93849
Summary: 'Segmentation fault' in the special index for an array
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90248
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68531
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2016-07-11 00:00:00 |2020-2-20
Summary|incorrect co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Bug ID: 93848
Summary: missing -Warray-bounds warning for array subscript 1
is outside array bounds
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #16 from Oleg Endo ---
This seems to be actually valid code?!
switch (e - p)
{
default: __builtin_unreachable();
case 3: if (e[-3]&0x80) return e-3;
case 2: if (e[-2]&0x80) return e-2;
case 1: if (e[-1]&0x80) retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #14 from Oleg Endo ---
Created attachment 47879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47879&action=edit
reduced case
I've reduced the preprocessed file string.c down to the problematic function
'coderange_scan'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
--- Comment #1 from Giulio Benetti ---
Here is another test-case:
http://autobuild.buildroot.net/results/e22/e225e62ea2d48660df4110790664f0c3306c1ea9/
Here gcc is built from scratch instead of using Codesourcery one, so it should
be easy for you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
Bug ID: 93847
Summary: Nios II ICE
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #13 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #12)
> Building with -O1 fixes the problem for me. Now I need to compare the flags
> for -O1 and -O2 and check which one breaks the build.
It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826
--- Comment #1 from Tobias Burnus ---
The C code rejects this as follows.
The OpenACC specification talks about "tightly nested loops"; the OpenMP spec
is less clear but for "collapse" contrary to "tile" the implication that
tightly nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #191 from dave.anglin at bell dot net ---
On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #190 from Peter Bisroev ---
> (In reply to dave.anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93844
--- Comment #5 from Richard Biener ---
(In reply to Tom de Vries from comment #4)
> (In reply to Richard Biener from comment #1)
> > The only way to capture these may
> > be to introduce additional scoping in the FEs whenever new local decls
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709
--- Comment #4 from Jiu Fu Guo ---
This issue can be reproduced with GCC9 "-O2 -funroll-loops -mcpu=power9" or
"-O3 -mcpu=power9".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93846
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154
Martin Liška changed:
What|Removed |Added
CC||rezso at rezso dot net
--- Comment #11 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709
--- Comment #3 from Jiu Fu Guo ---
This issue may relates to cunroll and cunrollli; after cunroll, for power9 some
special instructions were selected.
In RTL, for power9, 'smax' is generated at ce1 pass;
While for power8, 'smax' is not used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93846
Bug ID: 93846
Summary: libsanitizer compilation error with glibc 2.31
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
Bug 81652 depends on bug 93656, which changed state.
Bug 93656 Summary: FAIL: gcc.target/i386/pr67770.c execution test with
-fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
--- Comment #3 from CVS Commits ---
The releases/gcc-8 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:b4edc88453b61d6f3bdb9143cd0486536f95598d
commit r8-10040-gb4edc88453b61d6f3bdb9143cd0486536f95598d
Author: H.J. Lu
Date: Thu Fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
--- Comment #2 from CVS Commits ---
The releases/gcc-9 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:f55bf4ddbfac3c7360cb00f3200b663c19baf504
commit r9-8259-gf55bf4ddbfac3c7360cb00f3200b663c19baf504
Author: H.J. Lu
Date: Thu Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93831
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 141 matches
Mail list logo
