--- Comment #10 from steven at gcc dot gnu dot org 2006-09-10 11:16 ---
I've decided to go with LABEL_PRESERVE_P after all...
Index: builtins.c
===
--- builtins.c (revision 116785)
+++ builtins.c (working copy)
@@ -
--- Comment #6 from steven at gcc dot gnu dot org 2006-09-10 11:56 ---
Patch was approved, but Zdenek still has to commit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28887
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Last reconfirmed|-00-00 00:00:00 |2006-09-10 13
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Last reconfirmed|-00-00 00:00:00 |2006-09-10 13
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Last reconfirmed|-00-00 00:00:00 |2006-09-10 13
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #12 from steven at gcc dot gnu dot org 2006-09-10 20:09 ---
Subject: Bug 26983
Author: steven
Date: Sun Sep 10 20:08:58 2006
New Revision: 116826
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116826
Log:
PR middle-end/26983
gcc/
* bu
--- Comment #13 from steven at gcc dot gnu dot org 2006-09-10 20:10 ---
Fixed on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2006-09-10 22:40 ---
Why is this ice-on-invalid-code a P2 bug?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28999
--- Comment #2 from steven at gcc dot gnu dot org 2006-09-15 15:23 ---
Re. comment #1 Yes, it is a _Recursive_ descent parser after all...
Probably the only solution is to parse the label and not descend. This is what
the C front end does, see c_parser_statement.
--
http
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-15 16:24 ---
Trying a fix (but don't hold your breath, the c++ parser is unexplored
territory for me ;-)
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-15 21:01 ---
Created an attachment (id=12279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12279&action=view)
tentative patch
This removes the recursion cycle
"cp_parser_statement -> cp_parser_la
--- Comment #5 from steven at gcc dot gnu dot org 2006-09-15 21:22 ---
Test case:
-
extern void bar ();
extern void baz ();
#define L1(x) \
case x##0: case x##1: case x##2: case x##3: \
case x##4: case x##5: case x##6: case x##7
#define L2(x
--- Comment #6 from steven at gcc dot gnu dot org 2006-09-15 23:48 ---
Created an attachment (id=12281)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12281&action=view)
Alternative patch (less obviously safe)
This one should resolve the problem completely by not recursi
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #31 from steven at gcc dot gnu dot org 2006-09-16 18:09 ---
sec has passed.
ping!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
--- Comment #11 from steven at gcc dot gnu dot org 2006-09-16 19:02 ---
(gdb) run
Starting program: /home/steven/devel/build-trunk/gcc/cc1plus -O
-ftree-vectorize -ftree-vectorizer-verbose=1 --param ggc-min-expand=0 --param
ggc-min-heapsize=0 t.cc
void foo() {GC 2466k -> 2190k} v
--- Comment #12 from steven at gcc dot gnu dot org 2006-09-16 19:13 ---
Dorit, your comments please. If I don't hear from you I'll commit this as
obvious.
Index: tree-vectorizer.c
===
--- tree-vectorizer.c
--- Comment #14 from steven at gcc dot gnu dot org 2006-09-16 20:07 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from steven at gcc dot gnu dot org 2006-09-17 09:54 ---
Created an attachment (id=12286)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12286&action=view)
patch implementing what Ian suggested
See http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00271.html
--
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-17 13:15 ---
Subject: Bug 25993
Author: steven
Date: Sun Sep 17 13:14:53 2006
New Revision: 117005
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117005
Log:
gcc/
PR c/25993
*
--- Comment #5 from steven at gcc dot gnu dot org 2006-09-17 13:17 ---
Fixed on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #2 from steven at gcc dot gnu dot org 2006-09-17 13:57 ---
Probably a problem with all 64 bit hosts.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-17 13:59 ---
This is an initial RTL generation problem. The ICE happens in
instantiate-virtual-regs but the offending insn already exists right after
expand:
;; Generating RTL for tree basic block 2
;; a = 25214903917
(insn 7
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-17 14:07 ---
Are you _really_ sure this worked with GCC 3.4.5?
$ ./cc1 --version
GNU C version 3.4.6 (hppa2.0-linux-gnu)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min
--- Comment #5 from steven at gcc dot gnu dot org 2006-09-17 14:18 ---
$ ./cc1 --version
GNU C version 3.3.6-hammer 20050117 (prerelease) (hppa2.0-linux-gnu)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=98 --param ggc
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Known to fail|4.1.1 4.2.0 |3.3.6 3.4.6 4.1.1
--- Comment #7 from steven at gcc dot gnu dot org 2006-09-18 04:15 ---
To cut down the estimate for the loop size, you need to treat CALL_EXPRs to
machine specific builtins specially (and probably some of the normal builtins
too). See estimate_num_insns_1, the case for CALL_EXPR. You
--- Comment #2 from steven at gcc dot gnu dot org 2006-09-18 14:33 ---
And this is a regression because...?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-18 14:34 ---
Because of PR28489. Right.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-09-18 15:32 ---
Subject: Bug 29087
Author: steven
Date: Mon Sep 18 15:32:43 2006
New Revision: 117026
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117026
Log:
PR c++/29087
*
--- Comment #9 from steven at gcc dot gnu dot org 2006-09-18 15:42 ---
Fix for GCC 4.1 coming later today.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-09-18 22:35 ---
Not fixed just yet.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2006-09-19 21:22 ---
Subject: Bug 21299
Author: steven
Date: Tue Sep 19 21:22:31 2006
New Revision: 117061
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117061
Log:
PR rtl-optimization/21299
* reload1.c
--- Comment #10 from steven at gcc dot gnu dot org 2006-09-19 21:23 ---
Fixed on trunk for GCC 4.2.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-20 22:05 ---
The bug database is no place for this kind of question. First you should look
for answers in the source code. This will be trial and error, but this is your
exercise so don't ask us to make it for you. If yo
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-20 22:19 ---
*** This bug has been marked as a duplicate of 24929 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2006-09-20 22:19 ---
*** Bug 28405 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2006-09-21 20:24 ---
No working test case, no feedback for two months -> no reason to keep this
open.
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #10 from steven at gcc dot gnu dot org 2006-09-21 20:27 ---
Subject: Bug 29087
Author: steven
Date: Thu Sep 21 20:27:36 2006
New Revision: 117120
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117120
Log:
2006-09-21 Steven Bosscher <[EMAIL PROTECTED]&g
--- Comment #11 from steven at gcc dot gnu dot org 2006-09-21 21:31 ---
Fixed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from steven at gcc dot gnu dot org 2006-09-21 21:32 ---
Denis, this should be fixed in the next release of GCC 4.1 (which will be GCC
4.1.2) and in GCC 4.2. Thanks for reporting the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29087
--- Comment #53 from steven at gcc dot gnu dot org 2006-09-23 09:44 ---
Is this still a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-23 15:14 ---
This is where we ICE:
Breakpoint 1, fancy_abort (file=0xbfb788 "../../trunk/gcc/haifa-sched.c",
line=4337,
function=0xbfc0a0 "move_block_after_check") at
../../trunk/gcc/diagnostic.c:642
642
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-23 15:19 ---
Breakpoint 1, fancy_abort (file=0xde98b0 "../../trunk/gcc/cp/class.c",
line=272,
function=0xde98a0 "build_base_path") at ../../trunk/gcc/diagnostic.c:642
642 internal_error ("i
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-24 08:19 ---
The choice to do things the way gcc does has been discussed many times over,
and the conclusion always has been that either all warnings should be done in
the front end, or dataflow analysis has to be used. The
--- Comment #13 from steven at gcc dot gnu dot org 2006-09-24 09:58 ---
VRP bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #14 from steven at gcc dot gnu dot org 2006-09-24 10:05 ---
Value ranges after VRP without -fwrapv:
e_1: VARYING
n_2: VARYING
e_3: VARYING
tn_4: VARYING
D.1875_5: [0, 65535] EQUIVALENCES: { } (0 elements)
bb_6: VARYING
D.1876_7: [0, +INF] EQUIVALENCES: { } (0 elements
--- Comment #15 from steven at gcc dot gnu dot org 2006-09-24 10:08 ---
Significant difference:
n_15: [0, +INF] EQUIVALENCES: { } (0 elements) without -fwrapv
n_15: [1, 65534] EQUIVALENCES: { } (0 elements) with -fwrapv
With -fwrapv this results in:
Folding predicate n_15 != 0 to
--- Comment #16 from steven at gcc dot gnu dot org 2006-09-24 10:11 ---
Actually looks like SCEV derives the wrong range.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-25 15:04 ---
Either show that it is a regression, or dont put the regression marker in the
subject.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-30 09:25 ---
Typically something I'd hope the new out-of-ssa pass would improve.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from steven at gcc dot gnu dot org 2006-10-02 21:46 ---
Re comment #5: "A quick pass to look for these cases and transform those PHIs
into copies at the appropriate place would accomplish the same thing."
That is exactly what I'd expect the out-of-ssa pa
--- Comment #4 from steven at gcc dot gnu dot org 2006-10-07 10:02 ---
New patch. New link. One-oh-one.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2006-10-07 10:05 ---
Would anyone object if I'd propose to disable reassociation for floating point
thingies on x86 for GCC 4.2? We can re-enable it if/when amacleod's new
out-of-ssa stuff fixes this for real...
--- Comment #69 from steven at gcc dot gnu dot org 2006-10-07 10:06 ---
The linked-to patch is already on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2006-10-10 06:48 ---
I'll look into this.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from steven at gcc dot gnu dot org 2006-10-12 21:22 ---
I thought it would simply be a matter of using TREE_NO_WARNING ... until I
realized this was not a warning but an error.
Anyway, following the method of the fix for PR19375, I bootstrapped and tested
this patch
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
--- Comment #19 from steven at gcc dot gnu dot org 2006-10-14 14:17 ---
Someone should make gdb understand the DW_AT_calling_convention attribute.
This is the bit necessary to make it work for Fortran. I considered stealing a
bit on FUNCTION_DECL to mark it as the main program but it
--- Comment #2 from steven at gcc dot gnu dot org 2006-10-14 14:19 ---
We should actually emit DW_AT_calling_convention for the main program. The
DW_AT_entry_point attribute is for alternate entries, which, yes, we should
also emit but don't.
G77 also never got this
--- Comment #3 from steven at gcc dot gnu dot org 2006-10-14 14:21 ---
There is support for Fortran module variables in DWARF3, see
http://dwarf.freestandards.org/Dwarf3.pdf.
Unfortunately GDB doesn't seem to support this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24526
--- Comment #3 from steven at gcc dot gnu dot org 2006-10-14 14:47 ---
The patch in http://sourceware.org/ml/gdb-patches/2005-11/msg00217.html
implements this quite nicely AFAICT. I'll try and take care of the rest.
--
steven at gcc dot gnu dot org changed:
--- Comment #4 from steven at gcc dot gnu dot org 2006-10-14 15:15 ---
This works with the patch I mentioned in comment #3. That patch is in the GDB
source tree since 2006-02-24, so this is "fixed" in GDB 6.5. On the GCC side
we seem to do the right thing for scalar compon
--- Comment #6 from steven at gcc dot gnu dot org 2007-01-27 22:30 ---
Approval of the patch at
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01429.html was posted today:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02253.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
dBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30619
--- Comment #7 from steven at gcc dot gnu dot org 2007-02-03 15:28 ---
Is this now being looked into by Diego or Aldy?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #13 from steven at gcc dot gnu dot org 2007-02-03 16:20 ---
Haven't seen any reports of wrong-code coming out of register renaming in a
while. Register renaming is enabled if loop unrolling / peeling is enabled. So
the test coverage of this pass is much better than it
--- Comment #7 from steven at gcc dot gnu dot org 2007-02-03 16:26 ---
Ping!
Nick, is there still a bug to fix here? The pattern you hacked in comment #4
is still not fixed AFAICT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11738
--- Comment #8 from steven at gcc dot gnu dot org 2007-02-03 16:27 ---
moving to WAITING pending Nick's reply.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from steven at gcc dot gnu dot org 2007-02-03 17:59 ---
Created an attachment (id=13001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13001&action=view)
disallow NRV optimization if there are stores into components of
--
http://gcc.gnu.org/b
--- Comment #5 from steven at gcc dot gnu dot org 2007-02-03 18:08 ---
Re. comment #2
Thomas, there is no option to turn off the NRV pass. I don't know why there
isn't one, but I believe there should be. Looks like an oversight.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #5 from steven at gcc dot gnu dot org 2007-02-03 18:28 ---
Has been in WAITING status for almost a year. Punt.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2007-02-03 18:35 ---
Mark was going to leave this for GCC 4.2, but hasn't fixed this for GCC 4.2
yet, either. What's going to happen with this bug?
--
steven at gcc dot gnu dot org changed:
What
--- Comment #10 from steven at gcc dot gnu dot org 2007-02-05 22:23 ---
Reported as fixed, see comment #9.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2007-02-05 22:30 ---
I don't think there is a compelling reason to have the patch in GCC 4.2. But
it would still be nice to get this out of the way, to reduce the number of VOPs
a bit further.
I have updated the patch of comme
--- Comment #15 from steven at gcc dot gnu dot org 2007-02-05 22:46 ---
Closing as DONTCARE, by request from Diego :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #3 from steven at gcc dot gnu dot org 2007-02-15 20:06 ---
The third hunk of the patch changes something:
Index: local-alloc.c
===
--- local-alloc.c (revision 121794)
+++ local-alloc.c (working copy
--- Comment #4 from steven at gcc dot gnu dot org 2007-02-15 20:15 ---
NB we don't add the REG_EQUIV note because insn 136 has multiple sets. Such
insns can't have REG_EQ* notes according to set_unique_reg_note. But that, I
think, is not the bug. More likely is that I
--- Comment #6 from steven at gcc dot gnu dot org 2007-02-16 05:26 ---
What Ian said is probably right, and the patch below should fix it. I haven't
tried it yet, though...
Index: local-alloc.c
===
--- local-al
--- Comment #8 from steven at gcc dot gnu dot org 2007-02-17 14:12 ---
*** Bug 30790 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-17 14:12 ---
*** This bug has been marked as a duplicate of 30773 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #70 from steven at gcc dot gnu dot org 2007-02-17 16:01 ---
The -ftree-loop-linear work is still too buggy at this time to be taken
seriously. I would strongly recommend against even considering the use of it.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #1 from steven at gcc dot gnu dot org 2007-02-17 20:24 ---
(gdb) run
Starting program: ./f951 -O2 -ftree-loop-linear t.f90
xas_env_init
Analyzing compilation unit
Performing interprocedural optimizations
Assembling functions:
xas_env_init
Program received signal
--- Comment #9 from steven at gcc dot gnu dot org 2007-02-18 22:33 ---
Subject: Bug 30773
Author: steven
Date: Sun Feb 18 22:33:23 2007
New Revision: 122106
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122106
Log:
PR rtl-optimization/30773
* local
--- Comment #10 from steven at gcc dot gnu dot org 2007-02-18 22:34 ---
Fixed on the trunk. I'll open a new PR for the missed rematerialization
opportunity that this causes.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-20 21:45 ---
Has this been checked against comp.lang.fortran?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30883
--- Comment #1 from steven at gcc dot gnu dot org 2007-02-21 15:53 ---
On i686, this happens too, due to fwprop1:
In insn 47, replacing
(mem/s:SI (plus:SI (plus:SI (mult:SI (reg:SI 75 [ ivtmp.37 ])
(const_int 4 [0x4]))
(reg/f:SI 91
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-21 15:58 ---
Problem here is combine.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2007-02-21 17:42 ---
So, ehm... What do the asm dumps for AVR look like? Can you attach them, so we
know what we're talking about here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-21 17:55 ---
Bonus points if you can reduce this to a C test case ;-)
Starting with the gimple dumps, this is usually not hard to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #1 from steven at gcc dot gnu dot org 2007-02-21 20:59 ---
Confirmed, we almost never do cross-jumping on the dataflow-branch anymore:
only after regmove.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-21 22:09 ---
On the trunk, *and* on the dataflow branch, we crossjump the code starting with
"if (i != 1)" on the first cleanup_cfg iteration when it's called from
rest_of_handle_stack_adjustments. Trunk
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-22 23:26 ---
I cannot reproduce this.
Please paste the output of gcc -v.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #1 from steven at gcc dot gnu dot org 2007-03-09 23:27 ---
I can't get the test case to fail. Can you give the output of
g++ -O2 -ftracer -v
on your test case please? Thanks.
--
steven at gcc dot gnu dot org changed:
What|Re
701 - 800 of 3051 matches
Mail list logo
