http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #15 from Michael Matz matz at gcc dot gnu.org 2012-08-03 14:43:14
UTC ---
Author: matz
Date: Fri Aug 3 14:43:09 2012
New Revision: 190126
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190126
Log:
PR tree-optimization/54146
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
--- Comment #2 from Michael Matz matz at gcc dot gnu.org 2012-07-04 12:11:10
UTC ---
ISL generally has speed problems. For instance graphite/interchange-8.c
needs quite long to compile (well, several seconds), and _all_ of the runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #62 from Michael Matz matz at gcc dot gnu.org 2012-06-26 14:44:58
UTC ---
(In reply to comment #61)
(In reply to comment #57)
Anyway, on the machine where are debugged this, compilation at -O3
took over 16 seconds which dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53688
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 2012-06-21 12:18:31
UTC ---
Author: matz
Date: Thu Jun 21 12:18:23 2012
New Revision: 188852
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188852
Log:
PR middle-end/53688
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53688
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #18 from Michael Matz matz at gcc dot gnu.org 2012-06-21 14:36:29
UTC ---
Just today I had to debug another crash in our package management code.
This time a c++98 library picked up a std::list operator= from a c++11
library resulting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #20 from Michael Matz matz at gcc dot gnu.org 2012-06-21 15:25:59
UTC ---
As I stumbled over this problem complex recently already I had a hunch that it
might again be a 11/98 mixture. Having the symbols would have made
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #21 from Michael Matz matz at gcc dot gnu.org 2012-06-21 15:32:07
UTC ---
(In reply to comment #20)
certainty. But it wouldn't have helped me that much further. I still would
have had to find out which functions were causing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705
--- Comment #2 from Michael Matz matz at gcc dot gnu.org 2012-06-17 15:36:19
UTC ---
Or alternatively cselib doesn't respect one invariant in constructing the
locations of its VALUEs. As seen above it constructs two values for the same
memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #58 from Michael Matz matz at gcc dot gnu.org 2012-06-15 14:56:33
UTC ---
Author: matz
Date: Fri Jun 15 14:56:26 2012
New Revision: 188667
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188667
Log:
PR middle-end/38474
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #59 from Michael Matz matz at gcc dot gnu.org 2012-06-15 15:12:59
UTC ---
There should be no compile performance problems in expand anymore.
The alias stmt walker as used from IPA remains a problem, though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #15 from Michael Matz matz at gcc dot gnu.org 2012-06-13 12:07:38
UTC ---
I think so, yes. I initially really reported this as general c++ problem,
with the testcase of course being about a concrete instance of the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Bug #: 53646
Summary: Surprising effects of cxx11 vs cxx98 ABI compatibility
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #5 from Michael Matz matz at gcc dot gnu.org 2012-06-12 15:36:01
UTC ---
(In reply to comment #2)
N.B. std::pair is not a POD in c++98 or c++11, so I don't know what libstdc++
could have done to cause the FE to change how it returns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 2012-06-12 15:41:49
UTC ---
FWIW, it's finish_struct_bits setting TREE_ADDRESSABLE, because
type_has_nontrivial_copy_init returns true for pair with that ctor.
I think this indeed makes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 2012-06-12 16:02:28
UTC ---
Yep, defaulting that ctor changes the ABI back to register passing.
If we could change that in libstdc++, all the better, but I still think the
issue is larger
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #54 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #55 from Michael Matz matz at gcc dot gnu.org 2012-05-29 13:08:52
UTC ---
FWIW the node-callees list in yukawa_gn_full has 25076 entries.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 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=gccview=revrev=187340
Log:
PR tree-optimization/53185
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
--- Comment #11 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
--- Comment #13 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
--- Comment #18 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #5 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #8 from Michael Matz matz at gcc dot gnu.org 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 matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #12 from Michael Matz matz at gcc dot gnu.org 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 matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
--- Comment #15 from Michael Matz matz at gcc dot gnu.org 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=gccview=revrev=187074
Log:
PR bootstrap/53197
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52977
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 2012-04-19 13:29:34
UTC ---
Author: matz
Date: Thu Apr 19 13:29:29 2012
New Revision: 186593
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186593
Log:
PR middle-end/52977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 2012-04-17 13:54:36
UTC ---
Author: matz
Date: Tue Apr 17 13:54:26 2012
New Revision: 186530
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186530
Log:
PR tree-optimization/18437
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52934
Bug #: 52934
Summary: enhancement: cshift0 should be inlined
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52908
Bug #: 52908
Summary: xop-mul-1:f9 miscompiled on bulldozer (-mxop)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52910
Bug #: 52910
Summary: xop-mul-1:f13 miscompiled on bulldozer (-mxop)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 2012-03-06 12:06:08
UTC ---
(In reply to comment #9)
(In reply to comment #8)
I still have an unfinished patch to convert SCCVN to
http://dl.acm.org/citation.cfm?id=512536
I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
--- Comment #3 from Michael Matz matz at gcc dot gnu.org 2012-03-01 12:56:40
UTC ---
Created attachment 26802
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26802
candidate fix
This fixes the problem by remembering the last seen call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 2012-03-01 14:10:08
UTC ---
Bah, no. That won't generally work. In particular it might be calls that
don't necessarily dominate the non-trapping stmt that make it trapping
again:
*X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
--- Comment #5 from Michael Matz matz at gcc dot gnu.org 2012-03-01 16:08:18
UTC ---
(In reply to comment #4)
We can ignore back edges,
hence the path between both accesses are acyclic, so we might still get away
with a non-iterating algorithm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52020
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794
--- Comment #9 from Michael Matz matz at gcc dot gnu.org 2012-01-26 13:25:06
UTC ---
Author: matz
Date: Thu Jan 26 13:24:58 2012
New Revision: 183559
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183559
Log:
PR tree-optimization/48794
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #20 from Michael Matz matz at gcc dot gnu.org 2012-01-26 15:50:43
UTC ---
Author: matz
Date: Thu Jan 26 15:50:33 2012
New Revision: 183566
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183566
Log:
PR tree-optimization/46590
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794
--- Comment #8 from Michael Matz matz at gcc dot gnu.org 2012-01-25 15:54:29
UTC ---
(In reply to comment #7)
Well, that is a different testcase for a different bug, better would be not
to reuse this one for that.
Hmm, perhaps. Too late now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #18 from Michael Matz matz at gcc dot gnu.org 2012-01-19 15:06:14
UTC ---
Author: matz
Date: Thu Jan 19 15:06:04 2012
New Revision: 183305
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183305
Log:
PR tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #19 from Michael Matz matz at gcc dot gnu.org 2012-01-19 15:10:43
UTC ---
The var-expansion slowness is fixed again. The rest of course still applies.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51117
--- Comment #9 from Michael Matz matz at gcc dot gnu.org 2011-12-13 13:59:42
UTC ---
Author: matz
Date: Tue Dec 13 13:59:35 2011
New Revision: 182283
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182283
Log:
PR tree-optimization/51117
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275
--- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-12-05 16:02:10
UTC ---
As said, this would still require ugly fiddling with exception edges.
Getting rid of some of the clobbers a posteriori seems cleaner.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #51 from Michael Matz matz at gcc dot gnu.org 2011-12-02 13:23:57
UTC ---
Nope, I don't have more than a couple hacks to try different approaches
as of right now. I should dust them off for next stage1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50317
--- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-11-28 13:46:45
UTC ---
(In reply to comment #6)
Patch to drop ={v} {CLOBBER} stmts when the lhs lost TREE_ADDRESSABLE bit
during execute_update_addresses_taken.
Actually it's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50317
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 2011-11-28 14:52:50
UTC ---
(In reply to comment #8)
Perhaps we could drop the var ={v} {CLOBBER} stmts when renaming the var
into SSA instead.
I think your current patch is better
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 2011-11-23 14:12:11
UTC ---
Andrew: yes, I considered something similar. To work really well it requires
some changes to the conflict generation code, though. Without the clobbers
all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264
--- Comment #9 from Michael Matz matz at gcc dot gnu.org 2011-11-22 13:32:20
UTC ---
Author: matz
Date: Tue Nov 22 13:32:15 2011
New Revision: 181615
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181615
Log:
PR c++/51264
* tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 2011-11-22 14:18:35
UTC ---
Fixed. Improving the situation with the clobbers should be tracked somewhere
else.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125
--- Comment #8 from Michael Matz matz at gcc dot gnu.org 2011-11-22 14:56:03
UTC ---
Author: matz
Date: Tue Nov 22 14:55:58 2011
New Revision: 181619
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181619
Log:
PR other/51125
* trans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 2011-11-21 13:28:08
UTC ---
Yes, the patch submission to the mailing list was incorrect and contained a
non-intended change. The patch as committed and ChangeLogged is correct.
Aldy: yes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||zsojka at seznam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51130
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741
--- Comment #8 from Michael Matz matz at gcc dot gnu.org 2011-11-17 16:04:04
UTC ---
Author: matz
Date: Thu Nov 17 16:03:56 2011
New Revision: 181443
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181443
Log:
PR middle-end/50644
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #20 from Michael Matz matz at gcc dot gnu.org 2011-11-17 16:04:04
UTC ---
Author: matz
Date: Thu Nov 17 16:03:56 2011
New Revision: 181443
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181443
Log:
PR middle-end/50644
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51117
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50857
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 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=gccview=revrev=180833
Log:
libcpp/
PR bootstrap/50857
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50857
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #17 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #18 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #19 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #8 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 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=50741
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 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__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
--- Comment #32 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
--- Comment #2 from Michael Matz matz at gcc dot gnu.org 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 matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50658
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||jojelino at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
--- Comment #12 from Michael Matz matz at gcc dot gnu.org 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=gccview=revrev=179745
Log:
PR middle-end/50638
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #2 from Michael Matz matz at gcc dot gnu.org 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 matz at gcc dot gnu.org 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 matz at gcc dot gnu.org 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
201 - 300 of 357 matches
Mail list logo
