https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #6 from Jürgen Reuter ---
In the linking before I do see the following warning:
ld: warning: direct access in function 'operator new[](unsigned long,
std::nothrow_t const&) [clone .cold]' from file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #15 from Romain Geissler ---
Thanks for these remarks.
FYI, what I am following are the Linux From Scratch guidelines, which build the
initial gcc like this (with both c and C++ support, disabling libstdc++ build):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #5)
> Hmm, the test case is explicitly adding the options
> -ffpe-trap=overflow,invalid, so is this a test case error? We tell it to
> trap on invalid fp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #4 from Jakub Jelinek ---
Thanks.
So, can you for that sort.i do -da -fdump-tree-all when compiled both with
stage1 and stage2 and see where things start to differ?
Or, try to change either:
STAGE1_TFLAGS += -fno-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #11 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #10)
> The trunk, svn 267657, all newest versions of gmp, mpfr, mpc. It seems that
> the problem is also solved when I use the libtool flag -static instead of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88754
Volker Reichelt changed:
What|Removed |Added
Known to work||3.4.0, 3.4.6, 4.1.0, 4.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81980
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #12 from Will Wray ---
On further investigation the logic of using first_initializer_p looks correct.
The comment on reshape_init suggests that it wasn't intended for scalar init:
/* Undo the brace-elision allowed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53320
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
--- Comment #5 from Peter Bergner ---
Hmm, the test case is explicitly adding the options
-ffpe-trap=overflow,invalid, so is this a test case error? We tell it to trap
on invalid fp operations which we force it to do when generating the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #3 from Mikael Pettersson ---
Created attachment 45384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45384=edit
pre-processed source for libiberty/sort.c
One of the smallest .o files that differ is from libiberty's sort.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
--- Comment #6 from Steve Kargl ---
On Tue, Jan 08, 2019 at 08:37:11PM +, bergner at gcc dot gnu.org wrote:
> Confirmed. I don't think the mentioned revision caused the problem, other
> than
> adding a new test case that fails the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #12 from Jürgen Reuter ---
No, unfortunately a working svn # is difficult, I first observed it by doing
svn up on another Macbook around Christmas. What do you mean by transcripts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88538
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86322
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88376
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88457
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 8 21:36:21 2019
New Revision: 267739
URL: https://gcc.gnu.org/viewcvs?rev=267739=gcc=rev
Log:
PR target/88457
* gcc.target/powerpc/pr88457.c: Remove -m32, -c and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593
--- Comment #25 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 8 22:29:56 2019
New Revision: 267740
URL: https://gcc.gnu.org/viewcvs?rev=267740=gcc=rev
Log:
PR rtl-optimization/79593
* config/i386/i386.md (reg = mem; mem =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88723
--- Comment #10 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Jan 8 19:09:52 2019
New Revision: 267734
URL: https://gcc.gnu.org/viewcvs?rev=267734=gcc=rev
Log:
PR bootstrap/88721
* config/sparc/sparc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88721
--- Comment #7 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Jan 8 19:09:52 2019
New Revision: 267734
URL: https://gcc.gnu.org/viewcvs?rev=267734=gcc=rev
Log:
PR bootstrap/88721
* config/sparc/sparc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88721
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88764
Bug ID: 88764
Summary: [nvptx, libgomp, testsuite] Update testsuite for
default vector length larger than 32
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
--- Comment #14 from mateuszb at poczta dot onet.pl ---
The patch from comment #13 solve my problems. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
>
> Vlad, could you please have a look?
I've just started to work on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86322
--- Comment #4 from Steve Kargl ---
On Tue, Jan 08, 2019 at 08:15:46PM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86322
>
> janus at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #13 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #12)
> No, unfortunately a working svn # is difficult, I first observed it by doing
> svn up on another Macbook around Christmas.
hmm ... that's tricky - a busy time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #19 from Jonathan Wakely ---
Author: redi
Date: Tue Jan 8 23:00:46 2019
New Revision: 267742
URL: https://gcc.gnu.org/viewcvs?rev=267742=gcc=rev
Log:
PR libstdc++/87855 fix optional for types with non-trivial copy/move
When the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #20 from Wilco ---
I see Kyrill added some examples that show LLVM knows how to unroll loops:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
This kind of thing is much worse than a trailing loop, both for branch
prediction and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 88721, which changed state.
Bug 88721 Summary: [9 regression] -Wmaybe-uninitialized warnings in sparc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88721
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #16 from joseph at codesourcery dot com ---
On Tue, 8 Jan 2019, romain.geissler at amadeus dot com wrote:
> FYI, what I am following are the Linux From Scratch guidelines, which build
> the
> initial gcc like this (with both c and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #21 from Wilco ---
(In reply to Eric Botcazou from comment #20)
> > BITS_BIG_ENDIAN is just a convenience to the target code writer. The other
> > four do matter, and are quite obvious really (and all four are necessary).
>
> Yes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #10 from Jürgen Reuter ---
The trunk, svn 267657, all newest versions of gmp, mpfr, mpc. It seems that the
problem is also solved when I use the libtool flag -static instead of
-static-libtool-libs for libtool to build these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #18 from Segher Boessenkool ---
Well, it is always possible to generate code with the opposite endianness to
what the hardware "wants". It just won't be very fast code.
BITS_BIG_ENDIAN is just a convenience to the target code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
Bug ID: 88763
Summary: Better Output for Loop Unswitching
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #19 from Wilco ---
(In reply to Segher Boessenkool from comment #18)
> Well, it is always possible to generate code with the opposite endianness to
> what the hardware "wants". It just won't be very fast code.
>
> BITS_BIG_ENDIAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88653
--- Comment #22 from Dominique d'Humieres ---
> Apparently, this is some kind of cygwin problem.
Did you report the problem to cygwin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88653
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84245
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #9 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #8)
Thanks!
I've been using gmp-6.1.2, mpfr-3.1.6, mpc-1.1.0 isl-0.20 on all my recent
builds (for trunk, gcc-8 and gcc-7)
You don't (I think) mention whether the GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #22 from Eric Botcazou ---
> Is it really pure RTL, therefore not used in tree? So the above patch using
> BITS_BIG_ENDIAN for tree stuff would be incorrect to use it?
I wouldn't say incorrect, just inappropriate and unnecessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047
--- Comment #8 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Jan 8 19:29:01 2019
New Revision: 267735
URL: https://gcc.gnu.org/viewcvs?rev=267735=gcc=rev
Log:
2019-01-08 Janus Weil
PR fortran/88047
* class.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #13 from Bence Szabó ---
ICE still occurs with current trunk (r267728) patched with gcc9-pr88331.patch
from PR88331. r266345 seems to give quite a hard time for cygwin / mingw
targets, might be worth reverting as the gcc 9 release is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #20 from Eric Botcazou ---
> BITS_BIG_ENDIAN is just a convenience to the target code writer. The other
> four do matter, and are quite obvious really (and all four are necessary).
Yes, I agree that BITS_BIG_ENDIAN shouldn't matter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #8 from Jürgen Reuter ---
Yes I know:
here is the non-working library resolution:
static_1.exe:
lib/libcuttools.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/libopenloops.dylib (compatibility version 0.0.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68426
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752
--- Comment #3 from Marek Polacek ---
Nevertheless the ICE seems to have started with r259043.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #14 from Eric Botcazou ---
> ICE still occurs with current trunk (r267728) patched with
> gcc9-pr88331.patch from PR88331. r266345 seems to give quite a hard time for
> cygwin / mingw targets, might be worth reverting as the gcc 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88762
Bug ID: 88762
Summary: C++17 Deduction guide and operator expression produces
missing template argument error
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
--- Comment #8 from Davin McCall ---
(In reply to ensadc from comment #7)
> Note that the "never defined" part is also misleading: the warning persists
> when `i::dispatch` does have a definition
Yes; and actually, I note that in the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #14 from Jürgen Reuter ---
Well, it seems that r267488 from Dec 31 was still working, on the other hand, I
saw a problem on the other MACbook definitely around at latest Dec 26 or so.
Probably before Christmas. It might be that small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88538
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Tue Jan 8 22:33:04 2019
New Revision: 267741
URL: https://gcc.gnu.org/viewcvs?rev=267741=gcc=rev
Log:
PR c++/88538 - braced-init-list in template-argument-list.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88756
--- Comment #1 from Tom de Vries ---
Author: vries
Date: Wed Jan 9 00:07:55 2019
New Revision: 267747
URL: https://gcc.gnu.org/viewcvs?rev=267747=gcc=rev
Log:
[libgomp, testsuite, openacc] Don't use const int for dimensions
Const int is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 87214, which changed state.
Bug 87214 Summary: [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU
2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86322
--- Comment #5 from Steve Kargl ---
On Tue, Jan 08, 2019 at 09:40:29PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> Naw, it is is not due to my patch. Rather my patch has
> exposed or uncovered a bug in gfortran. gfortran needs
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87436
--- Comment #13 from Daniel Gibson ---
Great, thanks a lot for fixing this!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431
--- Comment #16 from Jonathan Wakely ---
Author: redi
Date: Tue Jan 8 23:15:49 2019
New Revision: 267743
URL: https://gcc.gnu.org/viewcvs?rev=267743=gcc=rev
Log:
Pretty printer test fixes and improvements
Test that StdUniquePtrPrinter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77990
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Tue Jan 8 23:15:49 2019
New Revision: 267743
URL: https://gcc.gnu.org/viewcvs?rev=267743=gcc=rev
Log:
Pretty printer test fixes and improvements
Test that StdUniquePtrPrinter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #20 from Jonathan Wakely ---
Fixed for GCC 9, but I might make the minimal fix on the gcc-8-branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88744
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Tue Jan 8 23:54:47 2019
New Revision: 267744
URL: https://gcc.gnu.org/viewcvs?rev=267744=gcc=rev
Log:
PR c++/88744
* g++.dg/cpp2a/nontype-class12.C: New test.
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88744
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #16 from Jürgen Reuter ---
Yes, after the problem occurred, I did a completely clean new build of gmp,
mpfr, mpc, gcc (configured with ../configure --prefix=/usr/local/
--with-gmp=/usr/local/ --with-mpfr=/usr/local/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #15 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #14)
> Well, it seems that r267488 from Dec 31 was still working, on the other
> hand, I saw a problem on the other MACbook definitely around at latest Dec
> 26 or so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88765
Bug ID: 88765
Summary: powerpc64le-linux-gnu sub-optimal code generation for
builtin atomic ops
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88744
--- Comment #2 from Marek Polacek ---
Err, this one:
#define SA(X) static_assert((X),#X)
struct S {
int a;
int b;
constexpr S(int a_, int b_) : a{a_}, b{b_} { }
};
template
struct X {
static constexpr int i = s.a;
static constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88376
--- Comment #3 from Steve Kargl ---
On Tue, Jan 08, 2019 at 08:35:21PM +, janus at gcc dot gnu.org wrote:
>
> --- Comment #2 from janus at gcc dot gnu.org ---
> (In reply to Dominique d'Humieres from comment #1)
> > The change of behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88744
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #23 from John Dong ---
diff -urp a/gcc/expr.c b/gcc/expr.c
--- a/gcc/expr.c2019-01-09 03:19:03.750205982 +0800
+++ b/gcc/expr.c2019-01-09 03:38:23.414174738 +0800
@@ -10760,6 +10760,16 @@ expand_expr_real_1 (tree exp,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718
--- Comment #2 from joseph at codesourcery dot com ---
Note that there are also such cases as
static int x;
struct s { int a[sizeof(x)]; } inline *f (void) { return 0; }
where the reference to x is part of the return type (still syntactically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #16 from rguenther at suse dot de ---
On Tue, 8 Jan 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
>
> --- Comment #15 from Wilco ---
> (In reply to rguent...@suse.de from comment #14)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #17 from Wilco ---
(In reply to rguent...@suse.de from comment #16)
> But you can't elide the checks in the peeled copies and for 4-times
> unrolling you have most cases exiting on the first or fourth check.
See comment #8 for an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88701
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88758
Bug ID: 88758
Summary: [9 Regression] 186.crafty in SPEC CPU 2000 failed to
build
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88757
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684
--- Comment #7 from Martin Liška ---
(In reply to Jakub Jelinek from comment #6)
> I'd check what would they say about upstream change and if they are strongly
> against, make a local change. Even when clang++ is used with libstdc++ the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #5)
> I think the problem is that while we make TYPE_MODE something dynamic for
> vector types (which takes into account whether the current function supports
> in hw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87488
--- Comment #7 from David Malcolm ---
I'm unconvinced that doing it for filenames is a good idea (based on the
objections in comment #3), but I think that there could be other good uses
tagging URLs into the output.
For example, a static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88758
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88066
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Tue Jan 8 13:25:19 2019
New Revision: 267726
URL: https://gcc.gnu.org/viewcvs?rev=267726=gcc=rev
Log:
PR libstdc++/88066 use <> for includes not ""
Using #include "..." to include a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88066
Jonathan Wakely changed:
What|Removed |Added
Summary|[7/8/9 Regression] Relative |[7/8 Regression] Relative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55752
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Last reconfirmed|2012-12-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #15 from Wilco ---
(In reply to rguent...@suse.de from comment #14)
> On Mon, 7 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
> >
> > --- Comment #13 from Wilco ---
> > So to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65425
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2015-03-18 00:00:00 |2019-1-8
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88757
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #18 from Jakub Jelinek ---
The duffs device doesn't need to be done with computed jump, it can be done
with 3 conditional branches + 3 comparisons too. The advantage of doing that
is especially if the iter isn't really very small,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587
--- Comment #5 from Jakub Jelinek ---
I think the problem is that while we make TYPE_MODE something dynamic for
vector types (which takes into account whether the current function supports in
hw such vectors or not):
#define TYPE_MODE(NODE) \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47896
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48620
Bug 48620 depends on bug 47896, which changed state.
Bug 47896 Summary: wrong code with -O -fno-early-inlining -fipa-pta
-fno-tree-dominator-opts -fno-tree-forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47896
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88756
Bug ID: 88756
Summary: [nvptx, openacc] Override too many num_workers in
nvptx plugin, instead of erroring out
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Richard Biener changed:
What|Removed |Added
Keywords||alias
Last reconfirmed|2013-05-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88757
Bug ID: 88757
Summary: GCC wrongly treats dependent name as a type when it
should be treated as a value
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88753
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88753
--- Comment #5 from Martin Liška ---
Author: marxin
Date: Tue Jan 8 14:45:28 2019
New Revision: 267728
URL: https://gcc.gnu.org/viewcvs?rev=267728=gcc=rev
Log:
Use proper type in linear transformation in tree-switch-conversion (PR
1 - 100 of 275 matches
Mail list logo
