http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
Ian Lance Taylor changed:
What|Removed |Added
Depends on||52205
--- Comment #5 from Ian Lance Ta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921
--- Comment #11 from Ian Lance Taylor 2012-02-11 00:10:13
UTC ---
Note that the C++ example must be compiled -fnon-call-exceptions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
Ian Lance Taylor changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47656
--- Comment #4 from Ian Lance Taylor 2012-02-12 05:59:42
UTC ---
Yes, __builtin_init_heap_trampoline is new for 4.7. Sorry for not answering
earlier, I missed the e-mail message somehow.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
--- Comment #7 from Ian Lance Taylor 2012-02-12 06:04:42
UTC ---
In current mainline I'm not aware of any test failures on Solaris. The SPARC
Solaris system I am using is very slow and I do see some timeouts. However, I
do not see any more actu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
--- Comment #8 from Ian Lance Taylor 2012-02-12 06:05:36
UTC ---
Sorry, I should clarify that I don't see any failures on Solaris if I patch the
compiler to avoid PR 51921.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52084
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218
--- Comment #1 from Ian Lance Taylor 2012-02-12 19:34:43
UTC ---
Please look at the test case for SETCONTEXT_CLOBBERS_TLS in libgo/configure.ac
and figure out why it fails on arm-linux-gnueabi. That test case should not
fail on any GNU/Linux sys
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
--- Comment #6 from Ian Lance Taylor 2012-02-12 19:52:02
UTC ---
The patch fixes the test case and also passes some relevant Go tests.
Rainer, if OK, I'd like to leave it to you to comment on the patch and do a
full testsuite run.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829
--- Comment #27 from Ian Lance Taylor 2012-02-13 17:12:57
UTC ---
Vladimir: if you want to report this problem, please open a new bug report.
Please do not tag on to this unrelated bug report. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50654
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48501
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48411
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #10 from Ian Lance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48411
Ian Lance Taylor changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #2 from Ian Lance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48411
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48410
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48243
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48122
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47726
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47524
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #18 from Ian Lan
||ian at airs dot com
Resolution||FIXED
--- Comment #2 from Ian Lance Taylor 2012-02-14 20:01:35
UTC ---
This particular problem has been fixed, so closing this bug report. I don't
know what the current status is on FreeBSD. gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48407
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #26 from Ian Lance Taylor 2012-02-16 15:48:18
UTC ---
I think it would be great if somebody would tell me something I can used
instead of makecontext/getcontext/setcontext. Unless somebody can come up with
one, then I think the only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #28 from Ian Lance Taylor 2012-02-16 16:50:13
UTC ---
Using pthreads will be much less efficient than the current code using
getcontext/setcontext. Writing machine-specific replacement code would be a
much better idea than that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52266
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50166
--- Comment #5 from Ian Lance Taylor 2012-02-17 15:59:42
UTC ---
Can this PR be closed? It seems to have been fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218
--- Comment #5 from Ian Lance Taylor 2012-02-21 18:33:14
UTC ---
If ARM GNU/Linux does not support getcontext/setcontext, then this particular
configure test is not particularly relevant, since the library isn't going to
work anyhow. I suppose t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349
--- Comment #5 from Ian Lance Taylor 2012-02-23 14:16:41
UTC ---
Richi's patch is approved (I'm testing it myself, but go ahead and commit if it
looks fine to you).
Thanks.
||ian at airs dot com
Known to work||4.7.0
Resolution||FIXED
--- Comment #2 from Ian Lance Taylor 2012-02-27 18:52:04
UTC ---
Fixed on mainline. A patch for the 4.6 branch is fine with me but I don't pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52342
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52342
--- Comment #4 from Ian Lance Taylor 2012-03-05 15:38:36
UTC ---
Don't worry, I will fix that one too, although it's odd that I don't see it
myself.
It's fairly important that gcc 4.7 support the Go 1 release, and that is going
to require a few
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52532
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571
Bug #: 52571
Summary: vectorizer changes alignment of common symbols
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571
--- Comment #3 from Ian Lance Taylor 2012-03-13 15:48:36
UTC ---
I agree: if the symbol is always common, the linker should use the largest
alignment. But the symbol need not always be common. Consider one file with
"unsigned long int *p;" and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52557
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52557
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52557
--- Comment #8 from Ian Lance Taylor 2012-03-13 22:13:24
UTC ---
>From the log files, looks like there is some problem with unwinding the stack.
My first guess would be that there is something wrong with the ARM-specific
code in libgo/runtime/go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #2 from Ian Lance Taylor 2012-03-15 05:27:03
UTC ---
What's failing is not Printf or Println, but the filename and line number.
Those are retrieved using DWARF lookup on the PC, and evidently something is
going wrong in that area. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #4 from Ian Lance Taylor 2012-03-15 16:23:33
UTC ---
If you look at the test (libgo/go/log/log_test.go), you'll see that it simply
does
if useFormat {
Printf("hello %d world", 23)
} else {
Println("hello", 23,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #6 from Ian Lance Taylor 2012-03-16 03:18:46
UTC ---
Thanks for looking at this.
The first step is to run readelf --debug=line FILE to make sure that the line
number information is recorded correctly. Which of course it probably is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #12 from Ian Lance Taylor 2012-03-17 16:41:21
UTC ---
Can you attach the output of readelf --debug (not just --debug=line) for the
program that fails?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51206
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com, ktietz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52787
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #92 from Ian Lance Taylor 2012-04-18 03:50:51
UTC ---
As I said in comment #47 and elsewhere, you should not confuse the order in
which entries appear in .ctors or .init_array sections with the order in which
they appear in the binary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #94 from Ian Lance Taylor 2012-04-19 00:14:01
UTC ---
It is misleading to think that the linker accumulates code in translation unit
order for a C++ program. E.g., that is not what happens for template code or
string constants. And
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #97 from Ian Lance Taylor 2012-04-22 17:03:24
UTC ---
One option you have is to configure gcc with --disable-initfini-array.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #102 from Ian Lance Taylor 2012-04-22
21:16:14 UTC ---
To be clear, nothing has changed in collect2. The only thing that has changed
is that data that was being emitted in the .ctors section is now being emitted
in the .init_array se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #104 from Ian Lance Taylor 2012-04-22
22:26:50 UTC ---
I'm not sure what you mean. Each object file will have a .init_array section.
The linker will assemble those sections in the usual manner.
The order of global constructors in a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
--- Comment #16 from Ian Lance Taylor 2012-04-24 16:33:13
UTC ---
At some point, can you update this bug with the current set of test failures
using Go on Irix? No rush.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52359
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52462
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #16 from Ian Lance Taylor 2012-04-24 20:43:33
UTC ---
I think that the problems with the log test should be fixed now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
Ian Lance Taylor changed:
What|Removed |Added
Version|4.7.0 |4.7.1
--- Comment #19 from Ian Lance T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52341
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Version|4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #21 from Ian Lance Taylor 2012-04-25 14:56:56
UTC ---
I no longer see any failures on i386 Solaris. I see a few failures on x86_64
Solaris. They are all crashing in x86_64_fallback_frame_state when trying to
unwind through a signal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125
Bug #: 53125
Summary: Very slow register allocation on SPARC
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
--- Comment #2 from Ian Lance Taylor 2012-04-25 22:15:19
UTC ---
SPARC register allocator slowness filed as PR 53125.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125
--- Comment #1 from Ian Lance Taylor 2012-04-25 22:34:17
UTC ---
Out of curiousity I tried compiling the test case with -O2. On x86_64 it took
57.4 seconds, on SPARC it took 20 minutes 33 seconds.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #3 from Ian Lance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52360
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #22 from Ian Lan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52358
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
CC: vmakarov at redhat dot com
The appended test case should run without error and return 0. When I compile
it with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59099
--- Comment #7 from Ian Lance Taylor ---
Thanks, Martin.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
--- Comment #1 from Ian Lance Taylor ---
FYI, the point of the test is to get that segmentation violation and ensure
that the signal handler generates a runtime panic as it should. The actual
problem is presumably happening some time later.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29997
--- Comment #6 from Ian Lance Taylor ---
All the insns in sh_expand_epilogue need to be examined to see if they need
REG_CFA notes. Some of them already have them. I don't know what more are
needed.
For example, look at the changes made to the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59506
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59506
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51151
Bug #: 51151
Summary: Invalid -Woverflow warning in C++ frontend
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51151
Ian Lance Taylor changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255
Bug #: 51255
Summary: Using -flto breaks code which puts values in .ctors or
.init_array
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #17 from Ian Lance Taylor 2011-12-14 01:43:11
UTC ---
The most recent patch is against gcc 4.6, and mainline is different.
I have just moved the support for reading export data out of the Go frontend
proper. The purpose of this move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51592
Bug #: 51592
Summary: ICE with -fnon-call-exceptions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51592
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51576
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50012
--- Comment #7 from Ian Lance Taylor 2012-01-07 01:31:36
UTC ---
Created attachment 26260
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26260
Possible patch
I did not like the first approach because I think that checking c_dialect_cxx
in t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50012
Ian Lance Taylor changed:
What|Removed |Added
Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51598
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50656
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47656
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Version|4.6.0
--- Comment #6 from ian at airs dot com 2007-04-27 21:50 ---
Fixed on mainline and 4.2 branch.
--
ian at airs dot com changed:
What|Removed |Added
Status
--- Comment #8 from ian at airs dot com 2007-04-28 05:26 ---
I don't see why this PR should count as a regression, since there is no
regression in the generated code. There is only a change in VRP behaviour.
The generated code is the same. This PR is only going to be r
--- Comment #2 from ian at airs dot com 2007-05-01 04:34 ---
Created an attachment (id=13467)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13467&action=view)
Proposed patch
I'm testing this now.
--
ian at airs dot com changed:
What
--- Comment #10 from ian at airs dot com 2007-05-01 18:58 ---
Please let me know if this is still a problem after revision 124334.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31710
--- Comment #4 from ian at airs dot com 2007-05-01 18:59 ---
Fixed on mainline.
--
ian at airs dot com changed:
What|Removed |Added
CC|ian at gcc dot gnu
--- Comment #29 from ian at airs dot com 2007-05-02 16:57 ---
Created an attachment (id=13497)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13497&action=view)
Patch
Here is one approach which fixes the test case. This introduces a new tree
code, ALIASING_CONVERT_EXPR.
--- Comment #33 from ian at airs dot com 2007-05-03 20:33 ---
Created an attachment (id=13504)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13504&action=view)
Patch
Here is a much simpler patch which also fixes the problem. This simply inserts
a memory clobber befo
--- Comment #40 from ian at airs dot com 2007-05-04 07:37 ---
Created an attachment (id=13506)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13506&action=view)
Patch
Here is yet another patch, an improvement over the previous one. It finally
dawned on me that we can use
--- Comment #47 from ian at airs dot com 2007-05-04 16:54 ---
Unfortunately there is no obvious way to avoid creating the asm if the types
are the same. The reason is that the dynamic types are different, and we don't
know the dynamic type.
Look at your original test case:
--- Comment #49 from ian at airs dot com 2007-05-12 00:22 ---
Created an attachment (id=13543)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13543&action=view)
Patch
Like sands through the hourglass, so are the patches to PR 29286.
This version creates a new tree code.
--- Comment #54 from ian at airs dot com 2007-05-12 19:41 ---
Regarding comment #51: I think the code is OK. What it does is, at the RTL
level, make the two types alias each other for the entire function. This is
different from what was happening on comment #47; that patch was making
--- Comment #55 from ian at airs dot com 2007-05-12 19:43 ---
Regarding comment #52: do you have a reasonably sized test case? I didn't see
any problems when I ran the C++ testsuite.
I think tree-ssa-operands.c does the right thing:
case CHANGE_DYNAMIC_TYPE
--- Comment #58 from ian at airs dot com 2007-05-14 04:45 ---
Created an attachment (id=13551)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13551&action=view)
Patch
That test case turns out to be an oversight in my patch to tree-ssa-dce.c.
Here is the new patch against m
--- Comment #64 from ian at airs dot com 2007-05-14 17:42 ---
Re: comment #59: CHANGE_DYNAMIC_TYPE_EXPR does not have a result. I set it up
so that it is essentially volatile, and represents an additional type aliasing
at that point in the program.
One of the earlier patches set it up
--- Comment #65 from ian at airs dot com 2007-05-14 18:14 ---
Created an attachment (id=13553)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13553&action=view)
Patch
Thanks for the new test case. Here is a new patch. The change compared to the
previous patch is just
401 - 500 of 1633 matches
Mail list logo
