https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394
--- Comment #3 from spinpx ---
CVE-2019-9071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89395
--- Comment #3 from spinpx ---
CVE-2019-9070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #27 from Xi Ruoyao ---
I confirm it is back in 8.3.0.
See https://gcc.godbolt.org/z/QoSa3W.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482
--- Comment #9 from David ---
(In reply to Ciro Santilli from comment #8)
- I haven't posted a patch file since I wasn't sure that I was all that close
to being done. But I'm certainly not opposed to the idea. Were you
volunteering to move thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542
--- Comment #2 from puffydaemon at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
> Are you sure this is not an binutils bug at reporting the wrong line numbers
> based on the preprocessed output?
No, I am not sure. Even I dont und
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542
--- Comment #1 from Andrew Pinski ---
Are you sure this is not an binutils bug at reporting the wrong line numbers
based on the preprocessed output?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542
Bug ID: 89542
Summary: Error reported on incorrect line number when using GCC
to compile .S files using #include
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89531
--- Comment #3 from Arseny Solokha ---
In my case the target is 32-bit BE powerpc.
Additionally, the testcase fails w/ -fno-PIC and/or ( -fstack-protector-all or
-fno-stack-protector ); it does not fail w/ -fPIC and/or
-fstack-protector{,-explic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89541
Bug ID: 89541
Summary: [9 Regression] ICE in VN_INFO(tree_node*)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88100
Li Jia He changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
--- Comment #2 from Andres Takach ---
You are right. I did use LD_LIBRARY_PATH, but the issue I had is that I used
the "lib" instead of the "lib64" version (I did not build 32-bit compatability)
so I was picking up the wrong version since "lib" w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89526
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459
--- Comment #4 from joseph at codesourcery dot com ---
In fact, having tested it, and used static linking to make sure the new
libquadmath was used rather than an older distribution version, this bug
was fixed in GCC 8, presumably by the r25034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
--- Comment #1 from joseph at codesourcery dot com ---
Are you sure you're using (at runtime) the libquadmath from the GCC
version you're using (via -rpath / LD_LIBRARY_PATH, or linking with static
rather than shared libquadmath), rather than a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #9 from H. Peter Anvin ---
I can confirm this bug is still present as of gcc 8.2.1.
I have attached a test case which clearly shows __udivdi3 called with the
regparm convention, but libgcc definitely does not expect it:
objdump -dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Fri Mar 1 00:08:58 2019
New Revision: 269293
URL: https://gcc.gnu.org/viewcvs?rev=269293&root=gcc&view=rev
Log:
PR c++/88183 - ICE with .* fold-expression.
build_m_component_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86969
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Fri Mar 1 00:08:21 2019
New Revision: 269292
URL: https://gcc.gnu.org/viewcvs?rev=269292&root=gcc&view=rev
Log:
PR c++/86969 - ICE with constexpr if and recursive generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #8 from H. Peter Anvin ---
Created attachment 45862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45862&action=edit
Test code (object output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #7 from H. Peter Anvin ---
Created attachment 45861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45861&action=edit
Test case (assembly output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #6 from H. Peter Anvin ---
Created attachment 45860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45860&action=edit
Test case (preprocessed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
H. Peter Anvin changed:
What|Removed |Added
CC||hpa at zytor dot com
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
Bug ID: 89540
Summary: roundq(x) returning value with non-zero fractional
part
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89534
--- Comment #1 from jon_y <10walls at gmail dot com> ---
Weak symbols aren't quite supported with PE, I'm not sure if making the symbol
weak is the right approach.
Do you have a test case to show this will lead to the correct behavior with
MAKE_D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
sa-dom.c (edge_info::derive_equivalences) : Test
only whether bit #0 of the value is 0 instead of the entire value.
Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/20190228-1.c
- copied unchanged from r269289,
trunk/gcc/testsuite/gcc.c-torture/execute/20190228-1.c
sa-dom.c (edge_info::derive_equivalences) : Test
only whether bit #0 of the value is 0 instead of the entire value.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20190228-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539
Bug ID: 89539
Summary: [9.0 regression] gcc fails to build/bootstrap on
MACOSX
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77604
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #5 from Dominique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #19 from Eric Botcazou ---
> We do take the range as granted in both cases. If for BIT_NOT_EXPR on say
> int the result is -2 or -1, then your TREE_INT_CST_LOW fix would DTRT, sure.
> If the result is any other value, then we run int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87068
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87068
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Thu Feb 28 22:29:42 2019
New Revision: 269288
URL: https://gcc.gnu.org/viewcvs?rev=269288&root=gcc&view=rev
Log:
PR c++/87068 - missing diagnostic with fallthrough statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576
--- Comment #29 from Dominique d'Humieres ---
> Is this still an issue?
I still get the stack-buffer-overflow reported in comment 26 with 8.2 and trunk
(9.0) but not with 7.4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544
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=60576
--- Comment #28 from anlauf at gcc dot gnu.org ---
Is this still an issue?
On x86_64-pc-linux-gnu and with current trunk, I do only get a memory
leak with -fsanitize=address (both -m32 and -m64), which disappears
if I deallocate the arrays at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87751
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77604
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #6 from Jonathan Wakely ---
(In reply to Marek Polacek from comment #5)
> 89537.C:9:18: error: invalid use of non-static member function ‘void B<
> , ,
> , >::keys() [with _Tp =
> int; = int; = A;
> = A]’
> 9 | : keys(p1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544
--- Comment #9 from Harald Anlauf ---
(In reply to kargl from comment #8)
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c (revision 266281)
> +++ gcc/fortran/res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538
Bug ID: 89538
Summary: [7.3.0] GCC miscompiling LLVM because of wrong
vectorization
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538
--- Comment #1 from Taewook Oh ---
And I confirmed that this bug doesn't reproduce with GCC5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #2 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:36 2019
New Revision: 269287
URL: https://gcc.gnu.org/viewcvs?rev=269287&root=gcc&view=rev
Log:
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #10 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:23 2019
New Revision: 269286
URL: https://gcc.gnu.org/viewcvs?rev=269286&root=gcc&view=rev
Log:
[PR72741] For all Fortran OpenACC 'routine' directive variants chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #11 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:36 2019
New Revision: 269287
URL: https://gcc.gnu.org/viewcvs?rev=269287&root=gcc&view=rev
Log:
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #1 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:01 2019
New Revision: 269285
URL: https://gcc.gnu.org/viewcvs?rev=269285&root=gcc&view=rev
Log:
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'rout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #9 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:01 2019
New Revision: 269285
URL: https://gcc.gnu.org/viewcvs?rev=269285&root=gcc&view=rev
Log:
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'rout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
--- Comment #13 from Thomas Koenig ---
This looks like it does the trick (test case passes):
Index: trans-types.c
===
--- trans-types.c (Revision 269260)
+++ trans-types.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #18 from Jakub Jelinek ---
We do take the range as granted in both cases. If for BIT_NOT_EXPR on say int
the result is -2 or -1, then your TREE_INT_CST_LOW fix would DTRT, sure. If
the result is any other value, then we run into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #17 from Eric Botcazou ---
> How is BIT_NOT_EXPR expanded for the prec > 1 BOOLEAN_TYPEs btw? If it is
> normal QImode or SImode etc. one's complement, then I'd say it is a bug if
> match.pd generates such BIT_NOT_EXPRs.
No idea abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #16 from Eric Botcazou ---
> So, for BIT_AND_EXPR we only handle the case where the result of
> BIT_AND_EXPR is known to be non-zero. That means both operands have to be
> non-zero (and have at least one common bit). Now, if say the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #15 from Jakub Jelinek ---
How is BIT_NOT_EXPR expanded for the prec > 1 BOOLEAN_TYPEs btw? If it is
normal QImode or SImode etc. one's complement, then I'd say it is a bug if
match.pd generates such BIT_NOT_EXPRs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #14 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #12)
> > Adding integer_onep wouldn't be
> > correct IMHO, if you have some non-boolean non-prec==1 integral type, even
> > if you know rhs has range [0, 1], if BIT_NO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #13 from Eric Botcazou ---
> On the testcase, value is -2 and before your change it would derive
> correctly that if BIT_NOT_EXPR is -2, then rhs must be ~-2, i.e. 1, but
> after the patch it says rhs must be 0.
The oversight is actu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #12 from Eric Botcazou ---
> On the testcase, value is -2 and before your change it would derive
> correctly that if BIT_NOT_EXPR is -2, then rhs must be ~-2, i.e. 1, but
> after the patch it says rhs must be 0.
Right, an annoying ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #11 from Jakub Jelinek ---
The [0, 1] range in that case (if not boolean or prec==1) is not the property
of the type, but just that optimizations figured out the SSA_NAME will not have
other values. In tree-ssa-dom.c it goes in the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #10 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #9)
> > Then I don't understand the problem in the BIT_NOT_EXPR case: we have int
> > type and [0, 1] range for rhs; if we know that BIT_NOT_EXPR is zero, we can
> > d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #9 from Eric Botcazou ---
> Then I don't understand the problem in the BIT_NOT_EXPR case: we have int
> type and [0, 1] range for rhs; if we know that BIT_NOT_EXPR is zero, we can
> deduce that it must be 1 too.
So the problem is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #8 from Eric Botcazou ---
> Isn't that different though? I mean, even if we have int type and have [0,
> 1] range and have a check that the value isn't 0, then it must be 1.
Then I don't understand the problem in the BIT_NOT_EXPR ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
Jakub Jelinek changed:
What|Removed |Added
Attachment #45856|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #7 from Eric Botcazou ---
> Isn't that different though? I mean, even if we have int type and have [0,
> 1] range and have a check that the value isn't 0, then it must be 1.
Then I don't understand the problem in the BIT_NOT_EXPR ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542
--- Comment #11 from G. Steinmetz ---
Well, the ICEs are gone for all posted test cases above.
Assuming that different shapes are not supported as an extension
(aka feature), as such they are not standard-conforming.
F2018 7.5.10 item 2 says
"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049
Jason Merrill changed:
What|Removed |Added
Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #6 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #5)
> There is very likely the same issue in the BIT_AND_EXPR case then.
Isn't that different though? I mean, even if we have int type and have [0, 1]
range and have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Thu Feb 28 17:29:48 2019
New Revision: 269283
URL: https://gcc.gnu.org/viewcvs?rev=269283&root=gcc&view=rev
Log:
PR c++/88049 - ICE with undefined destructor and anon namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #5 from Marek Polacek ---
With this patch
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index fb67d905acd..d9073d7c23d 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4246,7 +4246,7 @@ resolve_args (vec *args, tsubst_flags_t
complain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #5 from Eric Botcazou ---
> I wonder if we shouldn't do:
> --- gcc/tree-ssa-dom.c.jj 2019-02-26 14:13:08.296824100 +0100
> +++ gcc/tree-ssa-dom.c2019-02-28 15:46:52.285495060 +0100
> @@ -346,6 +346,9 @@ edge_info::derive_e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049
--- Comment #7 from Jan Hubicka ---
I am happy with the patch in #5, so you can consider it pre-approved. It is
probably your call whether to declare the code invalid at first place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #4 from Marek Polacek ---
loc is UNKNOWN_LOCATION:
(gdb) up
#1 0x00b98003 in invalid_nonstatic_memfn_p (loc=0, expr=,
complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck.c:1896
1896 error_at (loc, "inva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #3 from Marek Polacek ---
template class A {};
template class B;
class C {
using mapped_type = int;
public:
template
C(B, A> *p1, unsigned)
: keys(p1->keys), values(p1->values) {}
A keys;
A values;
};
class D {
pub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #13 from Jakub Jelinek ---
Created attachment 45856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45856&action=edit
WIP
For that test the following helps, but guess I'm still not handling anonymous
aggregates right there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88585
--- Comment #5 from Jan Hubicka ---
Author: hubicka
Date: Thu Feb 28 16:45:44 2019
New Revision: 269282
URL: https://gcc.gnu.org/viewcvs?rev=269282&root=gcc&view=rev
Log:
PR lto/88585
* tree.c (find_atomic_core_type): Move ahead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88585
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
--- Comment #2 from Marek Polacek ---
struct tuple;
template
struct S { };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #12 from Jakub Jelinek ---
#c2 with it still fails though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88235
--- Comment #4 from Jan Hubicka ---
I think you can add cgraph predicate
former_thunk_p which tests that
return !thunk_p && (thunk_info.fixed_offset || virtual_offset_p ||
indirect_offset)
Every thunk should set one of those (it may be good to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #11 from Jakub Jelinek ---
So like (untested):
--- gcc/call.c.jj 2019-02-28 08:14:58.251562934 +0100
+++ gcc/call.c 2019-02-28 17:04:49.697357298 +0100
@@ -819,7 +819,7 @@ build_list_conv (tree type, tree ctor, i
conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #10 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #9)
> So, shall we never try ck_list conversion for CONSTRUCTORs with any
> designators (while for -std=c++2a we'll complain if there is a mix of
> designated initiali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #11 from Jakub Jelinek ---
Any progress on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #1 from Jonathan Wakely ---
Created attachment 45855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45855&action=edit
gzipped unreduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
Bug ID: 89537
Summary: missing location for error
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89533
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #3 from Jakub Jelinek ---
I wonder if we shouldn't do:
--- gcc/tree-ssa-dom.c.jj 2019-02-26 14:13:08.296824100 +0100
+++ gcc/tree-ssa-dom.c 2019-02-28 15:46:52.285495060 +0100
@@ -346,6 +346,9 @@ edge_info::derive_equivalences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Summary|[9 Regression] wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89455
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89455
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Feb 28 14:24:52 2019
New Revision: 269281
URL: https://gcc.gnu.org/viewcvs?rev=269281&root=gcc&view=rev
Log:
i386: Identify Westmere from PCLMUL
Since AES has been removed fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875
--- Comment #5 from Jakub Jelinek ---
Those pragmas are all extensions, so the standard doesn't cover them.
/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190228 (experimental) [trunk revision 269278] (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89456
--- Comment #3 from H.J. Lu ---
Created attachment 45853
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45853&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89535
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89520
--- Comment #7 from Jakub Jelinek ---
*** Bug 89521 has been marked as a duplicate of this bug. ***
1 - 100 of 138 matches
Mail list logo
