https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626
--- Comment #7 from Michael Matz ---
I've added it verbatim from PR48622, which itself was an autoreduced testcase
for
an ICE, at the time preventing bootstrapping. I haven't verified if making the
testcase conforming C (i.e. provide a definitio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94522
--- Comment #3 from Michael Matz ---
See the llvm link of the respective patch. They specify that the outputs are
reliable only on the fallthrough (i.e. no goto taken) path (in particular the
outputs might or might not have been changed on the j
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matz at gcc dot gnu.org
Target Milestone: ---
I believe gcc-10 miscompiles the following program when SVE and vectorization
are enabled. You need glibc to show this, or a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #3 from Michael Matz ---
(In reply to Richard Biener from comment #2)
> which means for non-memory gimple_could_trap_p (stmt) - sth you can
> easily check I guess.
Just note that _all_ floating point operations, not just divisions, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #10 from Michael Matz ---
(In reply to Andreas Schwab from comment #5)
> > Just note that _all_ floating point operations, not just divisions, can trap
> > (without fast-math). You never know if the user enabled stops for any of
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #11 from Michael Matz ---
(In reply to rguent...@suse.de from comment #9)
> How do we represent sNaNs with -fnon-call-exceptions? That is,
I think we're currently simply buggy at various stages as soon as sNaNs are
involved _and_ ST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #9 from Michael Matz ---
We could also punt: when enable-link-mutex we could artificially up the job
number for make to account for the waiting link steps. I.e. when normally -jN
was given, the link step could be done under -j(N + nr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #11 from Michael Matz ---
(In reply to Jan Hubicka from comment #10)
> > We could also punt: when enable-link-mutex we could artificially up the job
> > number for make to account for the waiting link steps. I.e. when normally
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #2 from Michael Matz ---
The psABI doesn't say anything about such types, no. Maybe it could in some
additional info pages, but it's always a problem to codify behaviour
retroactively
in it, when conflicting implementations already e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #7 from Michael Matz ---
(In reply to Richard Biener from comment #5)
> So vector types with element type T and N, a power-of-two, not otherwise
> specified are passes the same as
>
> struct S { T a[N] };
>
> ?
No. structs, if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #12 from Michael Matz ---
Author: matz
Date: Tue Oct 22 12:25:03 2019
New Revision: 277287
URL: https://gcc.gnu.org/viewcvs?rev=277287&root=gcc&view=rev
Log:
Fix PR middle-end/90796
PR middle-end/90796
* gimple-loop-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
Michael Matz changed:
What|Removed |Added
Summary|[8/9/10 Regression] GCC: O2 |[8/9 Regression] GCC: O2 vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #16 from Michael Matz ---
(In reply to Jakub Jelinek from comment #14)
> Time to backport now?
Hmpf, I've actually done the regstrapping for gcc9 already but then forgot to
submit. Thanks for the reminder.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #17 from Michael Matz ---
Author: matz
Date: Wed Nov 20 16:51:10 2019
New Revision: 278512
URL: https://gcc.gnu.org/viewcvs?rev=278512&root=gcc&view=rev
Log:
Fix PR90796
PR middle-end/90796
* gimple-loop-jam.c (any_acc
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matz at gcc dot gnu.org
Target Milestone: ---
A user of ours noted a difference in behaviour between gcc8 and gcc9 regarding
braced initializers. Take this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #1 from Michael Matz ---
I _think_ a reduced program would be this:
-
template struct remove_ref { typedef _Tp type; };
template struct remove_ref<_Tp&> { typedef _Tp type; };
template struct r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #4 from Michael Matz ---
Even though bugzilla isn't really for educating people, I'd still like to ask
why the two conversion sequences are deemed either incomparable or equal. In
S b { moveme(t) };
the return value of moveme() h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #6 from Michael Matz ---
(In reply to Jonathan Wakely from comment #5)
>
> Before choosing which conversion operator to use, the compiler considers the
> constructors of S, finding S(const S&) and S(S&&) as candidates. There is a
> v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92821
--- Comment #5 from Michael Matz ---
Yes, we (intentionally) haven't required any extensions to happen for arguments
or return values smaller than 64bit (e.g. we haven't even specified that
arguments <= 32bit would be zero-extended in the high bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93270
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #18 from Michael Matz ---
(In reply to Alexander Monakov from comment #17)
> I think part of the problem is trying to make "deaths" explicit via CLOBBERs
> without making "births" also explicit in the IR.
Yes, that's basically the cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #8 from Michael Matz ---
>From the GCC perspective, yes. From the standard-is-surprising perspective,
no, but that probably doesn't belong to the GCC bugzilla. So, yeah, can be
closed
for gcc 9 (theoretically it's still a bug in gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
--- Comment #9 from Michael Matz 2013-02-08 12:31:28
UTC ---
Author: matz
Date: Fri Feb 8 12:31:19 2013
New Revision: 195883
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195883
Log:
PR tree-optimization/52448
* tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #34 from Michael Matz 2012-09-03 15:39:20
UTC ---
Author: matz
Date: Mon Sep 3 15:39:15 2012
New Revision: 190897
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190897
Log:
PR tree-optimization/46590
* tree-cfg.c (gim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550
--- Comment #3 from Michael Matz 2012-09-11 15:48:10
UTC ---
Or with the more recent -fexcess-precision=standard option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54945
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54945
--- Comment #13 from Michael Matz 2012-10-19 13:12:35
UTC ---
(In reply to comment #12)
> What do you mean by invalid? It is certainly not undefined behavior.
No, but the expectation implicitely coded into the return code is invalid.
So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265
Michael Matz changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Michael Matz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #29 from Michael Matz 2011-01-17 13:52:20
UTC ---
> It is, btw, a sign of bad Fortran language design
I don't see that. The frontend merely needs to emit correctly typed
expressions. And that the type of 'a%b%ptr%d' depends on the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #32 from Michael Matz 2011-01-18 13:56:01
UTC ---
Yes, but it's possible I was going up the wrong tree. My idea was to
build the no-restrict variants of types on demand, as necessary, basically
from gfc_sym_type(), whenever sym->attr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #34 from Michael Matz 2011-01-19 16:39:30
UTC ---
> As I said in comment #27, gfc_component structs belonging to the type, they
> are shared between target and non-target variants. Thus one cannot set
> inherited target attributes on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #35 from Michael Matz 2011-01-20 16:36:23
UTC ---
Created attachment 23047
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23047
possible patch
So, this is my current version. I'm creating a different type for top-level
symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265
--- Comment #7 from Michael Matz 2011-01-25 12:58:33
UTC ---
FWIW removing the second recursive call doesn't regress the testsuite.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #40 from Michael Matz 2011-01-25 15:02:40
UTC ---
The patch from comment #35 requires another change in unrelated code, which
I think actually fixes a pre-existing bug in type extension support:
Index: fortran/trans-expr.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #43 from Michael Matz 2011-01-26 12:39:04
UTC ---
Yep. With my patch the saner looking
new_person->service.education.person.ss = *ss;
statement is generated. It's possible that class containers actually contain
something as first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47698
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #48 from Michael Matz 2011-02-18 19:52:19
UTC ---
Author: matz
Date: Fri Feb 18 19:52:16 2011
New Revision: 170284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170284
Log:
PR fortran/45586
* gfortran.h (struct gfc_co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47946
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
--- Comment #5 from Michael Matz ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Richard Biener from comment #3)
> > It seems the code really wants to use anti_dependence, not true_dependence.
> > We have
> >
> > ... = equiv_me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57569
--- Comment #2 from Michael Matz ---
My guess is that it's again somewhere using the wrong predicate
to test directed rw/wr/ww dependencies.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57569
--- Comment #3 from Michael Matz ---
It's cse, and it's because it indeed uses the wrong dependence test.
The CSE tables holds values read from memory which are supposed to be
clobbered by following writes, i.e. write-after-read, which has to use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #8 from Michael Matz ---
(In reply to petschy from comment #7)
> Is it a plausible assumption that if a function is not marked as 'noreturn'
> and the loop doesn't change the program's state then the loop could be
> optimized away?
It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
Known to
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: matz at gcc dot gnu.org
Came up in IRC, GCC invalidly moves a conversion innerwards:
% cat x.c
extern void abort (void);
float global;
int main()
{
unsigned long z = 1;
float x = -z;
global = x;
if (global <
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57886
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55771
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165
--- Comment #11 from Michael Matz 2011-08-26 16:02:21
UTC ---
Author: matz
Date: Fri Aug 26 16:02:17 2011
New Revision: 178118
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178118
Log:
PR lto/50165
* lto-streamer-in.c (canon_file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
--- Comment #6 from Michael Matz 2011-09-02 18:31:56
UTC ---
Author: matz
Date: Fri Sep 2 18:31:47 2011
New Revision: 178489
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178489
Log:
PR middle-end/50260
* ipa-split.c (split_func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
Bug #: 50419
Summary: Bad interaction between data-ref and disambiguation
with restrict pointers
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
--- Comment #1 from Michael Matz 2011-09-15 14:16:54
UTC ---
Created attachment 25293
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25293
(untested) patch
Potential fix for this. As yet untested.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
Michael Matz changed:
What|Removed |Added
Attachment #23268|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #2 from Michael Matz 2011-10-07 15:45:44
UTC ---
Try to find out what var is. The segfault should also happen with an
unoptimized cc1 so that you can see the value of var.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #4 from Michael Matz 2011-10-07 16:34:49
UTC ---
The fortran segfault is tracked as PR50640.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #3 from Michael Matz 2011-10-07 16:45:55
UTC ---
Hmm, this is not as trivial as PR50638. fortran frontend generates this
static variable local to MAIN:
static struct __vtype_MAIN___T1 __vtab_MAIN___T1 = {._hash=41707971, ._size=4,
.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #4 from Michael Matz 2011-10-07 16:50:10
UTC ---
Or another solution: should the fortran frontend perhaps put all these
variables not in MAINs scope (where they aren't referenced anyway), but
rather into file scope? That last solutio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
Michael Matz changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Michael Matz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
--- Comment #7 from Michael Matz 2011-10-07 17:00:59
UTC ---
Hmm, I can't build go due to:
../../../gcc/libgo/runtime/sigqueue.goc:79:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2243
but that seems unrelated.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
--- Comment #8 from Michael Matz 2011-10-07 17:02:00
UTC ---
Okay, so it's really the emutlv_v variables. That should be fixed by the
patch at gcc-patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
--- Comment #12 from Michael Matz 2011-10-10 11:59:33
UTC ---
Author: matz
Date: Mon Oct 10 11:59:29 2011
New Revision: 179745
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179745
Log:
PR middle-end/50638
* tree-emutls.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
Michael Matz changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50658
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
Michael Matz changed:
What|Removed |Added
CC||jojelino at gmail dot com
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
--- Comment #2 from Michael Matz 2011-10-12 15:09:53
UTC ---
Meeh, since the fix for PR49279 we don't retain the casts to restrict anymore,
making the testcase not work even with the fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #6 from Michael Matz 2011-10-13 14:04:36
UTC ---
See comment #2, you need to help in debugging it. I can't reproduce, the
emutls problem is fixed, and with the information I have I can't speculate
which (probably global) variables ne
||2011-10-14
CC||matz at gcc dot gnu.org
Component|libstdc++ |middle-end
Resolution|INVALID |
Ever Confirmed|0 |1
Severity|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741
--- Comment #4 from Michael Matz 2011-10-17 15:18:08
UTC ---
Reducable to:
% cat x.cc
struct PublishLo
{
const char *functionName;
~PublishLo();
};
struct A { A(); };
A::A()
{
static PublishLo _rL_53 = {__FUNCTION__};
}
The problem doesn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741
Michael Matz changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
--- Comment #32 from Michael Matz 2011-10-18 01:33:10
UTC ---
To be honest, this bug report is not under any discussion anymore. I tried to
get any sort of sanity, but in the end it's all about egos; you won't
get what you want, it's really usel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #8 from Michael Matz 2011-10-20 08:14:45
UTC ---
Andi, the patch you bisected transformed a pre-existing bug into a segfault.
Reverting it wouldn't fix anything.
You could try the stab-in-the-dark patch from PR50741, but if that does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #10 from Michael Matz 2011-10-20 16:15:36
UTC ---
Why is it so difficult to just fire up gdb? This all could be solved in a
couple of minutes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #17 from Michael Matz 2011-10-31 13:16:49
UTC ---
Thank you very much! This really helps and at least reveals something quite
strange with LTO. It falls over the __func__ member of one of the two
static initializers:
Program receiv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #18 from Michael Matz 2011-10-31 13:37:33
UTC ---
Ah, wrong, native_cpu_up of course calls check_tsc_sync_source, which under
LTO can be inlined. So it's the same issues as PR50741, the patch from
there works around the issue. Unfor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #19 from Michael Matz 2011-10-31 13:41:59
UTC ---
Bah, I checked against the patched compiler. Nope, with the unpatched
compiler both descriptor variables stay in the local_decls of native_cpu_up
after inlining (with the source chang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50857
--- Comment #4 from Michael Matz 2011-11-03 17:17:11
UTC ---
Author: matz
Date: Thu Nov 3 17:17:07 2011
New Revision: 180833
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180833
Log:
libcpp/
PR bootstrap/50857
* configure.ac: Ch
||matz at gcc dot gnu.org
Resolution||FIXED
--- Comment #5 from Michael Matz 2011-11-03 17:22:02
UTC ---
Fixed.
gcc dot |matz at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Michael Matz 2012-05-02 21:29:24
UTC ---
Hmpf, x86_64-linux works for me just fine.
Hopefully I can reproduce the 32bit bootstrap fail :-/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #5 from Michael Matz 2012-05-02 22:21:31
UTC ---
Without help this will be impossible to debug for me. I can't reproduce with
either x86_64-linux (no configure options), nor under linux32 personality
(without options and with HJs opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #8 from Michael Matz 2012-05-02 22:29:17
UTC ---
(In reply to comment #6)
>
> Are you using binutils 2.22 or newer?
No: binutils-2.21.1-60.1.x86_64 .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #11 from Michael Matz 2012-05-02 22:53:21
UTC ---
(In reply to comment #9)
> > > Are you using binutils 2.22 or newer?
> >
> > No: binutils-2.21.1-60.1.x86_64 .
>
> Please try binutils 2.22.
Even though Jonathan uses 2.20 and also
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #12 from Michael Matz 2012-05-02 23:22:26
UTC ---
(In reply to comment #11)
>
> I'll try binutils 2.22 now.
Doesn't help, still no miscompare :-/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #14 from Michael Matz 2012-05-03 00:13:16
UTC ---
Thanks to Jonathan I have a hunch now. He has BUILD_CONFIG=bootstrap-debug
whereas I have BUILD_CONFIG empty for all my machines.
This means that for him stage2 is built with -g -gto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #15 from Michael Matz 2012-05-03 02:32:13
UTC ---
Author: matz
Date: Thu May 3 02:32:08 2012
New Revision: 187074
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187074
Log:
PR bootstrap/53197
* tree-ssa-dse.c (dse_opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
--- Comment #18 from Michael Matz 2012-05-07 12:27:18
UTC ---
(In reply to comment #15)
> While looking for ways to speed up genattrtab itself, I found this patch,
> which
> doesn't speed up genattrtab, but would make the insn-*tab.c files small
:00:00 |2012-05-08
AssignedTo|unassigned at gcc dot |matz at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #8 from Michael Matz 2012-05-08 10:46:38
UTC ---
Yep, mine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
--- Comment #11 from Michael Matz 2012-05-08 12:12:20
UTC ---
(In reply to comment #9)
> I guess instead of using prev/prev_initialized, the loop could gimple_set_uid
> (stmt, 0) the stmts it is about to process and gimple_set_uid (stmt, 1) stmts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
--- Comment #13 from Michael Matz 2012-05-08 13:19:42
UTC ---
(In reply to comment #10)
> The other way is to try to get away without immediately removing propagated
> source stmts - the obvious downside is that transforms relying on
> single-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185
--- Comment #6 from Michael Matz 2012-05-09 16:08:37
UTC ---
Author: matz
Date: Wed May 9 16:08:26 2012
New Revision: 187340
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187340
Log:
PR tree-optimization/53185
* tree-vect-data-r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342
Michael Matz changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |matz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #54 from Michael Matz 2012-05-29 12:47:29
UTC ---
Yes, only the expand vars problem is attacked by my patch. The alias walking
seems to come from an IPA analysis via ipa_compute_jump_functions.
detect_type_change uses the walker fro
1 - 100 of 382 matches
Mail list logo
