--- Comment #67 from ian at airs dot com 2007-05-14 22:35 ---
The patch in comment #65 passes bootstrap and the gcc and libstdc++-v3
testsuites on i686-pc-linux-gnu.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #69 from ian at airs dot com 2007-05-16 06:33 ---
Unless somebody feels strongly otherwise, I propose that we only fix this in
mainline (i.e., 4.3). Any fix is going to be delicate, this bug is unusual and
difficult to trigger, and there is a source code workaround
--- Comment #76 from ian at airs dot com 2007-05-16 18:01 ---
I don't believe that the C++ standards writers really meant to eliminate TBAA.
And that is the inevitable consequence of the dynamic memory type approach if
you are allowed to change the dynamic type in a function.
--- Comment #3 from ian at airs dot com 2007-05-17 05:02 ---
Created an attachment (id=13566)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13566&action=view)
Proposed patch
I'm testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31953
--- Comment #6 from ian at airs dot com 2007-05-18 06:53 ---
Fixed on mainline and 4.2 branch.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #78 from ian at airs dot com 2007-05-18 07:14 ---
The test case in comment #73 is just a standard aliasing violation. You are
casting a double* to an int* and writing to it both ways. As I argued in
comment #76, the only way this is going to work is if we eliminate TBAA in
--- Comment #79 from ian at airs dot com 2007-05-18 07:25 ---
The test case in comment #71 doesn't use placement new either.
This PR was originally about placement new. I think there is general agreement
thta placement new needs to avoid aliasing problem. I don't thin
--- Comment #86 from ian at airs dot com 2007-05-18 17:24 ---
Re comment #80, comment #81, comment #82. My patch handles the placement new
in comment #73 to indicate an alias between double and long. The mis-ordered
code is actually aliasing int and long. That aliasing is due to a
--- Comment #88 from ian at airs dot com 2007-05-18 17:35 ---
Regarding comment #85, this again relies on the notion of dynamic type of a
memory location such that the only possible end result is to eliminate TBAA
when compiling C++. The only thing I can say about this sort of test
--- Comment #87 from ian at airs dot com 2007-05-18 17:27 ---
I'm not sure what to make of comment #84. We don't determine aliasing by
alignment or size. We determine it by type. We don't currently treat int and
long as aliasing each other even if they happen t
--- Comment #94 from ian at airs dot com 2007-05-18 19:03 ---
I tried the original test case with icc, and it gets the right result. The
assignment b->p = 0 is discarded.
Unfortunately I'm not sure what this actually tells us.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #90 from ian at airs dot com 2007-05-18 18:38 ---
I agree that this is valid:
void f(double *p) { *(int*)p = 3; }
void g() {
int i;
f((double *)&i);
}
But I don't think that is the question at hand. The variable is always being
accessed in the same type, whic
--- Comment #5 from ian at airs dot com 2007-05-22 23:18 ---
The bug report as stated is clearly incorrect. gcc is perfectly free to insert
calls to __udivdi3. This is not forbidden by any part of the C language
standards.
To clarify for future readers, I gather that the actual
--- Comment #127 from ian at airs dot com 2007-05-23 15:23 ---
Re comment #105.
The case where TBAA is most useful is on a deeply pipelined in-order processor
with multiple function units and a high latency memory cache. One example I've
worked on is an embedded VLIW processor
--- Comment #130 from ian at airs dot com 2007-05-23 16:43 ---
In this example
void foo(int *p)
{
float *f = (float *)p;
new (p) float;
*f = 1.0;
}
the pointer is p. In fact the relevant pointer is always the argument to
placement new, and every pointer which PTA can associate
--- Comment #3 from ian at airs dot com 2007-05-24 23:14 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #159 from ian at airs dot com 2007-05-25 23:21 ---
Created an attachment (id=13613)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13613&action=view)
Patch
This version of the patch is based on some code from Daniel Berlin. Here we
determine which point
--- Comment #163 from ian at airs dot com 2007-05-28 17:30 ---
Richi, I tested my patch on every test case I saved. Can you just point me at
the one I missed? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #2 from ian at airs dot com 2007-05-29 13:48 ---
I think that having -Wall clobber -Wstrict-overflow in this way is confusing.
This isn't reversing the setting of the option, it's changing its level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
--- Comment #5 from ian at airs dot com 2007-05-30 19:41 ---
I think this is fixed by this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01079.html
I am currently testing that patch.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #6 from ian at airs dot com 2007-05-30 23:06 ---
Patch committed to mainline as revision 12503. The test case works for me.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #164 from ian at airs dot com 2007-05-30 23:18 ---
Created an attachment (id=13637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13637&action=view)
Patch
This is a modification of the previous patch which correctly handles the test
case in comment #85.
--
--- Comment #2 from ian at airs dot com 2007-06-01 15:09 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #167 from ian at airs dot com 2007-06-05 20:48 ---
Can you give me a .ii file for the performance regression, and point me at the
relevant function?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #169 from ian at airs dot com 2007-06-06 05:33 ---
What options are you using when you compile?
I don't see the symbol you mention, although I d
--- Comment #171 from ian at airs dot com 2007-06-08 07:49 ---
Created an attachment (id=13666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13666&action=view)
Patch
This variant of the previous patch does better on at least some of the tramp3d
functions. Here we elimin
--- Comment #4 from ian at airs dot com 2007-06-08 17:57 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 125521)
+++ tree-vrp.c (working copy)
@@ -2208,6 +2
--- Comment #7 from ian at airs dot com 2007-06-09 16:35 ---
Fixed. Thanks for reporting it.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #178 from ian at airs dot com 2007-06-12 18:10 ---
Fixed on mainline. No plans to backport the patch to previous releases.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #8 from ian at airs dot com 2007-06-12 18:25 ---
Undefined signed overflow is a language issue, not a processor issue. When
signed overflow is undefined, the compiler can and does make certain
assumptions about the results of operations. For example, it assumes that a +
1
--- Comment #19 from ian at airs dot com 2007-06-14 17:57 ---
Adding Richard in case he has any comment.
I don't agree with comment #17 from Doug. In the code in comment #16, if f
saves &c, there is no way that it could validly use it after the block scope
exits.
In gene
--- Comment #23 from ian at airs dot com 2007-06-30 17:57 ---
The patch in comment #19 of PR 32437 looks clearly correct. That
patch should not be reverted, at least not by itself. I'm not clear
on whether that was the patch that was reverted, but, if it was, I
don't think
--- Comment #13 from ian at airs dot com 2007-06-30 18:08 ---
The problem here is that although the stack pointer is not used in the
function, adjusting it does reserve space on the stack for the local variables
which are used. The local variables are accessed via the frame pointer
--- Comment #17 from ian at airs dot com 2007-07-02 01:45 ---
Before I tackle the specific questions, let me try to explain the issue that I
see. The issue is that during a function the value of the stack pointer
register must always be at or below the local variables. An interrupt
--- Comment #19 from ian at airs dot com 2007-07-02 02:50 ---
I don't see an inconsistency in my answers. If you mark local variables as
having a reference to the stack pointer before combine, then you should handle
log_links as appropriate.
I am explicitly not telling you what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88500
--- Comment #1 from Ian Lance Taylor ---
SETCONTEXT_CLOBBERS_TLS is set by libgo/configure.ac if this program fails to
exit successfully. So the first step in fixing this bug is finding out why
this program fails on SH.
#include
#include
#in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431
--- Comment #8 from Ian Lance Taylor ---
The workaround for this is probably to change gcc/go/gospec.c to remove the
need_thread variable. That would have the effect of changing the only use of
need_thread to only test library > 0, which would m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88202
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||ian at airs dot com
Resolution|--- |FIXED
--- Comment #2 from Ian Lance Taylor ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927
--- Comment #1 from Ian Lance Taylor ---
This is likely fixed by https://golang.org/cl/158717.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89019
--- Comment #2 from Ian Lance Taylor ---
Thanks for looking into this. The patch looks fine, want to send it to
gcc-patches with a ChangeLog entry? CC i...@golang.org. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
Ian Lance Taylor changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #6 from Ian Lance Taylor ---
Thanks. I could have predicted that that would be the change. Unfortunately
that isn't useful as that is a huge change, bringing in a large number of
upstream changes from the master Go library.
While a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #8 from Ian Lance Taylor ---
Created attachment 45590
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45590&action=edit
Sketch of patch
Thanks. That does make the problem obvious. I've attached a sketch of what a
patch should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52084
--- Comment #4 from Ian Lance Taylor ---
That seems like a new problem, not sure why you are reopening this bug report
from seven years ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52084
Ian Lance Taylor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227
--- Comment #1 from Ian Lance Taylor ---
Same as https://golang.org/issue/29046?
I would bet that this has something to do with the fact that testenv.HasLink is
inlinable. Something is wrong with the way that the frontend is passing the
inlinab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948
--- Comment #1 from Ian Lance Taylor ---
That is just the start of the problem. The garbage collector assumes that all
pointers are aligned to their natural boundary. That is, it expects that on a
system with four byte pointers, they are always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
--- Comment #1 from Ian Lance Taylor ---
Does the SPARC Solaris assembler support a syntax like
.section ".go.buildid",#exclude
? That's what gas seems to support for compatibility.
Does that syntax work for x86?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
--- Comment #7 from Ian Lance Taylor ---
Do you think you could work out a patch that handles the various different
cases?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
--- Comment #9 from Ian Lance Taylor ---
I suppose if worst comes to worst we can try it both ways.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
--- Comment #2 from Ian Lance Taylor ---
What are the contents of gotools/cmd_vet-testlog?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85630
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
--- Comment #4 from Ian Lance Taylor ---
Thanks. Which version of which linker are you running? For that matter, which
version of which assembler? I don't see the warnings and errors that you are
seeing, with GNU as 2.30 and GNU gold 2.30.51.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
--- Comment #3 from Ian Lance Taylor ---
I don't a reason to change the test to ==. I don't see what would be helped by
that. Note that Richi already approved the change to <=.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86213
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289
--- Comment #2 from Ian Lance Taylor ---
I think there is a real problem here. Filed https://golang.org/issue/26066.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86343
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
--- Comment #6 from Ian Lance Taylor ---
Thanks for the strace output.
The stat(NULL) is coming from libgo/runtime/go-caller.c in the function
__go_get_backtrace_state. It's a bug, but it's a different bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
--- Comment #7 from Ian Lance Taylor ---
To be clear, the problem is not that the go tool is failing to find its
subcommands. The problem is that the go tool thinks that the waitid system
call is returning an error. However, the strace shows th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
--- Comment #10 from Ian Lance Taylor ---
Thanks. The documentation for the syscall function say that it only sets errno
on failure, but I forgot about signal handlers. That is definitely a problem.
Since there is no generic way to detect whet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91172
--- Comment #2 from Ian Lance Taylor ---
That is the function (*Package).gccDebug, which on GCC 7 branch starts on line
1262 of libgo/go/cmd/cgo/gcc.go.
Like Richard I don't understand how you could get that warning. -Wreturn-type
is a C fronte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #23 from Ian Lance Taylor ---
Look for _kern in runtime.inc. See what struct it is part of. The struct is
likely defined in the generated file runtime_sysinfo.go. You may need to
modify libgo/mkrsysinfo.sh to not add that struct to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #25 from Ian Lance Taylor ---
The code in os_freebsd.go is written for the gc toolchain. You'll need to look
at it and see whether it makes sense for gccgo.
That said, that call to sysctl does seem to make sense. You'll need to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035
--- Comment #5 from Ian Lance Taylor ---
It's hard to see how this could be a bug in the Go frontend. At first glance
this looks like a problem with the split-stack support on S/390.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617
--- Comment #1 from Ian Lance Taylor ---
The cited revision was not to libgo, so my assumption is that there was
something wrong with it and there is nothing to change in the Go frontend. Let
me know if I'm mistaken.
This was also filed as http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617
--- Comment #3 from Ian Lance Taylor ---
To see how to run libgo tests, see the Debugging section in libgo/README.
The problem you are having with runtime.osinit looks related to a recent libgo
patch (https://gcc.gnu.org/ml/gcc-patches/2019-08/m
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
Test case (this is C code converted from a Go program):
extern void exit (int) __attribute ((__noreturn__));
struct s
{
int f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91692
--- Comment #2 from Ian Lance Taylor ---
Thanks for the bug report. The normal case when configuring GCC is to create a
new empty directory and run SRCDIR/configure in that directory, as documented
at https://gcc.gnu.org/install/configure.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91621
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91712
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91700
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91764
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781
--- Comment #1 from Ian Lance Taylor ---
Does this work at SVN revision r275611?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781
--- Comment #2 from Ian Lance Taylor ---
Oh, never mind, this is a new test in r275691, this code has probably never
worked on ppc64be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763
--- Comment #1 from Ian Lance Taylor ---
I can recreate this on sparc-sun-solaris2.11 using gas.2.30. It works using
the native assembler. I'm using the native linker.
It works if I #ifdef out these lines in lto-opts.c:
#if 0
/* If debug in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763
--- Comment #2 from Ian Lance Taylor ---
I see now the fact that we are using exceptions is already being passed. The
problem seems to be that flag_exceptions is set when we read an exception
region from an input function, by lto_init_eh. But b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763
--- Comment #7 from Ian Lance Taylor ---
Thanks!
||ian at airs dot com
Resolution|--- |FIXED
--- Comment #2 from Ian Lance Taylor ---
Should be fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91992
--- Comment #2 from Ian Lance Taylor ---
Created attachment 46996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46996&action=edit
index0-out.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91992
--- Comment #3 from Ian Lance Taylor ---
I don't know what is happening here.
The way this test works is that the file gcc/testsuite/go.test/test/index.go
and gcc/testsuite/go.test/test/index0.go are compiled together, producing a
file index0-ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745
--- Comment #7 from Ian Lance Taylor ---
We are using yet another object file reader because libbacktrace is designed to
run correctly when invoked by a signal handler, so it cannot use ordinary
memory allocation.
libbacktrace is only used when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745
--- Comment #9 from Ian Lance Taylor ---
filetype.awk will be run on a program compiled by the target compiler, so it
should get the correct result.
I agree that the endianness shouldn't matter with regard to the code, although
of course filetyp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #11 from Ian Lance Taylor ---
As far as I know libbacktrace and libgo use the same criteria for whether they
are built or not. Why is libbacktrace not being built for m4-fpu? What is
preventing that build from occurring?
What is th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #17 from Ian Lance Taylor ---
Actually we should just drop the libgo/go/exp directory. I don't know why it's
still there. It should have been dropped years ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #18 from Ian Lance Taylor ---
OK, the SH support patch is committed, and the exp directory has been removed.
Is there anything else to do here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #20 from Ian Lance Taylor ---
This will be in GCC 8.
Backports to GCC 7 are fine with me but I'm not going to do them myself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Ian Lanc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83787
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
501 - 600 of 1633 matches
Mail list logo
