--- Comment #12 from ian at airs dot com 2006-05-01 04:51 ---
Can somebody please add a small standalone test case showing the problem here?
Thanks.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #14 from ian at airs dot com 2006-05-02 03:40 ---
Created an attachment (id=11354)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11354&action=view)
Possible patch
I've attached a possible patch for this issue. It adds a new attribute
"preserve_stack
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
--- Comment #7 from ian at airs dot com 2006-05-11 22:55 ---
PR 20589 seems to be about an unnamed enum.
This enum in this test case is not unnamed. It is local to a function, but has
a name.
This may be related to 20589, but I don't think it is the same issue.
--
--- Comment #8 from ian at airs dot com 2006-05-15 05:41 ---
Steven: what's your patch? It seems to me that this fixes the problem in
mainline:
Index: tree-ssa-loop-niter.c
===
--- tree-ssa-loop-niter.c (rev
--- Comment #7 from ian at airs dot com 2006-05-18 06:33 ---
Created an attachment (id=11484)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11484&action=view)
Patch
I'm testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27622
"nan"
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
--- Comment #10 from ian at airs dot com 2006-06-06 04:11 ---
In C90 strtod does not say anything specifically about "inf", etc. However, it
does say:
In other than the "C" locale, additional implementation-defined subject
sequence forms may be accepted.
In any c
--- Comment #8 from ian at airs dot com 2006-06-06 15:42 ---
As I mentioned in the original submission, I'm pretty sure it is caused by
RTH's patch for PR 23190.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
--- Comment #12 from ian at airs dot com 2006-06-06 22:18 ---
At this web page:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm
I see this:
"The formatted input functions shall support the additional conversion
specifications specified in C99 subclause 7.1
--- Comment #4 from ian at airs dot com 2006-06-27 06:05 ---
With my current version of the lower-subreg patch, I get this with -O2
-momit-leaf-frame-pointer:
f:
movl16(%esp), %eax
movl4(%esp), %ecx
movl8(%esp), %edx
shrl$16, %eax
--- Comment #1 from ian at airs dot com 2006-07-10 16:27 ---
This is not a bug in the compiler. The ".set reorder" directive tells the
assembler that it should reorder instructions into branch delay slots when
possible. The compiler just copies the ".set reorder" d
nu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38468
--- Comment #16 from ian at airs dot com 2009-01-04 04:21 ---
I'm not working on this, sorry.
--
ian at airs dot com changed:
What|Removed |Added
AssignedT
--- Comment #7 from ian at airs dot com 2009-01-07 02:41 ---
Probably related to this, we get a bad warning for
extern void** foo();
const void** bar() { return (const void **) foo(); }
foo.cc:2: warning: cast from type void** to type const void** casts away
constness
I don'
--- Comment #9 from ian at airs dot com 2009-01-07 14:27 ---
How is it unsafe? All the const qualifier on a pointer means is that the
memory will not be changed through that pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35711
--- Comment #11 from ian at airs dot com 2009-01-07 15:41 ---
Oh yeah, sorry for the noise.
In any case, the warning message is wrong, as the cast does not "cast away
constness".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35711
ion: 4.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
--- Comment #3 from ian at airs dot com 2009-05-08 22:19 ---
Yeah, in C you can define a struct type in a type cast and then use it later.
Cool stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
--- Comment #1 from ian at airs dot com 2009-05-11 20:53 ---
I have posted a patch here:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00587.html
The patch is to CLooG.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #3 from ian at airs dot com 2009-05-12 01:30 ---
The bootstrap problem has been fixed by adding a #pragma. When and if the
CLooG header files are made -Wc++-compat compatible, that #pragma should be
removed.
--
ian at airs dot com changed:
What|Removed
--- Comment #4 from ian at airs dot com 2009-05-12 01:31 ---
Suspending until CLooG is fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status
--- Comment #6 from ian at airs dot com 2009-05-25 18:32 ---
With unscoped enums the similar code works because cp_build_binary_op applies
the default integral promotions to the enums, and winds up comparing two int
values. The promotions are not applied to scoped enums because
--- Comment #14 from ian at airs dot com 2009-05-30 16:03 ---
gcc is a free software project driven largely by volunteers. Interest in
fixing accepts-invalid bugs is generally low; people are generally more
interested in rejects-valid bugs, or in better optimizations, or in avoiding
FIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40317
: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40325
--- Comment #3 from ian at airs dot com 2009-06-10 22:48 ---
Fixed. Thanks for the bug report.
--
ian at airs dot com changed:
What|Removed |Added
Status
--- Comment #2 from ian at airs dot com 2009-06-12 17:57 ---
Fixed.
The update to the docs in the patch you mention explain why this new warning is
appropriate for -Wcast-qual. Let me know if you see how to make the docs
clearer.
http://gcc.gnu.org/viewcvs/trunk/gcc/doc/invoke.texi
--- Comment #3 from ian at airs dot com 2009-06-12 21:07 ---
-Wc++-compat now warns about alternative representations for operators and
punctuators such as "and". The other issues have not yet been addressed.
--
ian at airs dot com changed:
What
--- Comment #6 from ian at airs dot com 2009-06-20 05:10 ---
I added the warning to -Wall because it seemed to me to be a dubious usage
which was easily fixed. However, we can take it out of -Wall. I will ask for
opinions on g...@.
--
ian at airs dot com changed:
What
: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40563
nu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40564
--- Comment #2 from ian at airs dot com 2009-07-04 22:58 ---
Thanks for the bug report. Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status
--- Comment #4 from ian at airs dot com 2009-07-14 22:23 ---
Manu, I agree that these warnings are in some sense technically correct but
they are not useful. They can't point to any actual bug. I guess would be
that if every input to the expression has the size of the target o
--- Comment #9 from ian at airs dot com 2009-07-15 14:00 ---
Sure, it can wrap, but -Wconversion is not for wrapping warnings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #3 from ian at airs dot com 2009-07-25 06:33 ---
Fixed. Sorry about that.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #14 from ian at airs dot com 2005-11-04 16:09 ---
gcc is free to copy non-volatile variables. It does this in many places and
for many reasons, particularly in the new SSA optimizers in 4.0 and later. I
don't know the details of where it decided to copy the regist
--- Comment #8 from ian at airs dot com 2005-11-04 23:27 ---
No, doing the add in v4hi mode is not the same as doing the add in v8qi mode.
The carry bits will be handled differently.
It's also rather odd that register 81 changed from V4HImode to V8QImode.
Normally a pseudo-reg
--- Comment #9 from ian at airs dot com 2005-11-05 01:00 ---
Created an attachment (id=10151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10151&action=view)
Proposed patch
This patch fixes the problem. I'm running tests now.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #12 from ian at airs dot com 2005-11-06 06:41 ---
Fixed for 4.0.3 and 4.1.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #19 from ian at airs dot com 2005-11-07 02:26 ---
Created an attachment (id=10160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10160&action=view)
Patch
I'm testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
--- Comment #20 from ian at airs dot com 2005-11-07 18:41 ---
By the way, Richard, I just want to note that while this is obviously a
compiler bug, it is only being triggered for the original test case because of
the uninitialized variable i in sha1_update:
void sha1_update
--- Comment #24 from ian at airs dot com 2005-11-07 18:58 ---
Fixed on 4.0 branch and on mainline.
The 3.4 branch breaks in a slightly different way. I'm not going to worry
about it since you can only create this problem by building implausible
addresses that include offsets of
--- Comment #4 from ian at airs dot com 2005-11-09 06:08 ---
Not a bug.
--
ian at airs dot com changed:
What|Removed |Added
Status|WAITING
--- Comment #15 from ian at airs dot com 2005-11-16 01:09 ---
Does it bother us that legal ISO C programs are not permitted to say &a[-1]?
You are permitted to take the address of the element immediately after the
array, but you aren't permitted to take the address of th
--- Comment #5 from ian at airs dot com 2005-11-18 20:13 ---
Created an attachment (id=10277)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10277&action=view)
Patch
This patch appears to fix the problem.
However, I am about to leave for the weekend, and won't b
--- Comment #11 from ian at airs dot com 2005-11-21 05:45 ---
Fixed on mainline and 4.1 branch.
--
ian at airs dot com changed:
What|Removed |Added
Status
--- Comment #9 from ian at airs dot com 2005-11-30 04:06 ---
This is documented behaviour.
The -g option enables the -fworking-directory option, as described in the
documentation of -fworking-directory. It is the -fworking-directory option
which is printing the directory name.
If you
--- Comment #10 from ian at airs dot com 2005-12-14 01:25 ---
Subject: Re: RFA: fix bootstrap/25397 part 2 (Was: Re: Bootstrap failed)
Joern RENNECKE <[EMAIL PROTECTED]> writes:
> pinskia at gcc dot gnu dot org wrote:
>
> > /* Compile with -O2 -m32 -fPIC */
>
--- Comment #3 from ian at airs dot com 2006-01-06 19:05 ---
I think this is a bug in simplify_expand_binop (adding Richard Sandiford to the
CC since he introduced that function). Currently when simplify_expand_binop is
given two constants, it calls simplify_gen_binary. When the
--- Comment #4 from ian at airs dot com 2006-01-06 19:06 ---
Created an attachment (id=10590)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10590&action=view)
Sample untested patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25662
--- Comment #8 from ian at airs dot com 2006-01-15 05:28 ---
My patch doesn't help for func2, at least on x86, because at the RTL level we
see stores to memory, and my patch doesn't attempt to handle that because of
all the aliasing issues between the then-block and the else-
--- Comment #9 from ian at airs dot com 2006-01-15 06:27 ---
Upon further reflection, I don't think this is amenable to a good fix using
conditional moves. func2 doesn't read from a. Using conditional moves will
require adding reads from a. It's not obvious that
--- Comment #2 from ian at airs dot com 2006-01-15 17:07 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
CC
--- Comment #2 from ian at airs dot com 2006-01-18 17:04 ---
I just reconfirmed that I don't see any problems running the libjava testsuite
on i686-pc-linux-gnu. And I don't have access to any x86_64 systems. So I
can't recreate this problem myself.
The backtrace sugg
--- Comment #3 from ian at airs dot com 2006-01-18 17:39 ---
Building a cross-compiler did not shed any light on the problem.
Can anybody provide more information about what is going wrong?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
--- Comment #4 from ian at airs dot com 2006-07-21 18:05 ---
Please send e-mail to [EMAIL PROTECTED] first. When that process is
complete, send the patch to [EMAIL PROTECTED]
Thanks!
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #10 from ian at airs dot com 2006-07-23 17:35 ---
I believe that patch is responsible because this behaviour does not happen in
gcc 4.0.1, and it does happen in gcc 4.0.2, and that was the obvious change. I
admit that I haven't actually tried reverting that specific
--- Comment #9 from ian at airs dot com 2006-07-29 05:21 ---
It is safest to avoid posting the patch to a gcc mailing list before the
copyright assignment is signed. It protects us in the (hopefully unlikely)
case that the copyright assignment never does get signed. Otherwise we have
--- Comment #5 from ian at airs dot com 2006-08-07 17:14 ---
Insofar as I understand this issue, it seems that C99 and the C++ standard
specify different results for the square root of (-1, -0).
If that is correct, then we can decide that we want libstdc++ to follow C99
rather than the
ot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
--- Comment #2 from ian at airs dot com 2006-08-18 06:32 ---
Unfortunately I do not currently have a valid copyright assignment with the
FSF. I think my one word change is fine, but I don't feel comfortable moving a
function around (although I agree that is the right app
--- Comment #7 from ian at airs dot com 2006-08-18 15:58 ---
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
--- Comment #4 from ian at airs dot com 2006-08-24 06:20 ---
Where did you get your list of symbol names and demangled strings?
As Andrew has pointed out, there seem to be a few different issues here:
different spacing, different qualifier order, different handling of floating
point
--- Comment #6 from ian at airs dot com 2006-08-26 18:54 ---
OK, so that's where you got your symbols, but where did you get your list of
demangled strings? Did you just compare directly to the source code? Or are
you using some other demangler?
--
http://gcc.gnu.org/bug
--- Comment #7 from ian at airs dot com 2006-08-26 19:04 ---
I am testing a patch to the demangler to correctly handle _Z1fM1AKiPKS1_.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #4 from ian at airs dot com 2006-08-27 06:44 ---
I disagree. It is always useful to optionally warn about meaningless code. It
can be a way to find a real bug in the program. It is not conceptually
different from existing warnings like -Wredundant-decls. The code works
--- Comment #9 from ian at airs dot com 2006-08-27 21:44 ---
I'm going to close this PR since I just fixed the only real problem that I see
here. If you see other problems with the demangler, please open a separate PR
for each problem.
Thanks for reporting the bug.
--
ian at
--- Comment #11 from ian at airs dot com 2006-08-27 23:23 ---
I'll take this.
--
ian at airs dot com changed:
What|Removed |Added
AssignedTo|unassigned a
--- Comment #14 from ian at airs dot com 2006-08-28 00:02 ---
Fixed in mainline and 4.1 branch.
As far as I can see, the ICE reporting a "Broken pipe" error can only happen if
the gcc driver itself is invoked with SIGPIPE blocked. That is not the normal
case.
--
ian at ai
--- Comment #3 from ian at airs dot com 2006-09-13 06:36 ---
When I run the demangler on
_ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE
I get
void jmain::main(JArray*)
The relevant patch went in on 2005-12-10 to libiberty/cp-demangle.c. Can you
confirm that you have that
--- Comment #5 from ian at airs dot com 2006-09-13 07:23 ---
OK, with -s java I get
jmain.main(java.lang.String[])void
I misunderstood Daniel's report. Sorry about that.
The fact that the function's return type is printed at the end is deliberate.
This is because -s
dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29077
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29175
--- Comment #2 from ian at airs dot com 2006-09-22 13:55 ---
Fixed on mainline. I haven't tested the 4.1 branch yet.
--
ian at airs dot com changed:
What|Removed |
o __thread array with -fPIC -O2 on
x86
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian a
--- Comment #2 from ian at airs dot com 2006-10-02 23:52 ---
I believe this is happening because if the format is unrecognized, the
test-demangle program does not go on to see that the --no-params option was
used. When --no-params is used, it needs to skip an additional line.
I see no
--- Comment #19 from ian at airs dot com 2006-10-03 16:03 ---
Mike suggests: "it would appear that it is unsafe to reorder writes of
otherwise non-conflicting types past each other as type based analysis alone
isn't enough to ensure they don't conflict."
That
--- Comment #21 from ian at airs dot com 2006-10-03 23:44 ---
In C a general allocation function should work with a char array. A specific
allocation function should use a union. I don't think there are many existing
exceptions to these guidelines.
I think that code like that
--
ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
--- Comment #3 from ian at airs dot com 2007-02-02 05:41 ---
Should be fixed by this patch:
2007-02-01 Ian Lance Taylor <[EMAIL PROTECTED]>
* lower-subreg.c (simplify_gen_subreg_concatn): If we ask for the
high part of a paradoxical subreg, return a constan
--- Comment #1 from ian at airs dot com 2007-02-11 16:55 ---
This works for me on sparc-sun-solaris2.10 at svn revision 121803. I don't
have access to a SPARC GNU/Linux system. Which exact sources are you building?
Do you have any local patches? How did you run conf
--- Comment #4 from ian at airs dot com 2007-02-12 18:45 ---
Tom Tromey helped me recreate this with a cross-compiler.
I'm currently testing this patch:
Index: lower-subreg.c
===
--- lower-subreg.c (revision 1
--
ian at airs dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ian at airs dot com
|dot org
--- Comment #6 from ian at airs dot com 2007-02-13 22:22 ---
Fixed. Thanks for reporting it.
--
ian at airs dot com changed:
What|Removed |Added
Status
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30794
--- Comment #5 from ian at airs dot com 2007-02-16 00:38 ---
I believe this is also related to the failure of gcc.c-torture/execute/simd-1.c
on i686-pc-linux-gnu at -O1 and above.
I think the problem is that we fail to add a REG_EQUIV note here in
local-alloc.c:
if
--- Comment #4 from ian at airs dot com 2007-02-21 16:12 ---
I'm testing a patch.
--
ian at airs dot com changed:
What|Removed |Added
AssignedTo|unassign
--- Comment #6 from ian at airs dot com 2007-02-22 16:00 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from ian at airs dot com 2007-02-28 02:24 ---
The problem is that the bitset_c insn comes before the iorsi3 insn in the MD
files. It matches the ior:SI insn with one added clobber. Unfortunately, the
added clobber is of a hard reg, and so this is rejected by
--- Comment #5 from ian at airs dot com 2007-03-05 00:42 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 122538)
+++ tree-vrp.c (working copy)
@@ -1137,13 +1137,14 @@ extract_range_from_a
--- Comment #7 from ian at airs dot com 2007-03-05 19:55 ---
Fixed on mainline.
--
ian at airs dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from ian at airs dot com 2007-03-11 20:39 ---
I am testing this patch.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 122820)
+++ gcc/tree-vrp.c (working copy)
@@ -2142,13 +2142,11
--- Comment #6 from ian at airs dot com 2007-03-11 20:46 ---
Can you see if the patch I committed this morning fixes this problem?
2007-03-11 Ian Lance Taylor <[EMAIL PROTECTED]>
* tree-vrp.c (vrp_int_const_binop): Handle PLUS_EXPR and
the *_DIV_EXPR codes cor
--- Comment #4 from ian at airs dot com 2007-03-12 17:08 ---
First test case:
int f(int a)
{
if (a < 0)
a = -a;
return a < 0;
}
As far as I can tell the behaviour of this test case in VRP is unchanged by the
patch in this PR. And the code is still fully optimized.
--- Comment #5 from ian at airs dot com 2007-03-12 17:21 ---
Unfortunately my patch in comment #1 doesn't handle this test case correctly:
extern void abort (void);
void
foo (int a)
{
if (a <= (int) 0x8001)
{
a = - a;
if (a > 0)
abort ();
}
--- Comment #4 from ian at airs dot com 2007-03-21 14:39 ---
With current mainline, I get no warning for this:
struct Foo { int i; } __attribute__ ((deprecated));
void foo() { Foo f; }
but I do get a warning for this:
struct Foo { int i; } __attribute__ ((deprecated));
void foo
--- Comment #4 from ian at airs dot com 2007-03-26 17:57 ---
I'm continuing to look into the best way to avoid the compiler crash. I want
to note that this code is being clobbered by undefined signed overflow.
Computing (19780211 + [-128,127]) * 43321879 is always going to ove
--- Comment #5 from ian at airs dot com 2007-03-26 18:27 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 123218)
+++ tree-vrp.c (working copy)
@@ -1982,10 +19
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367
1 - 100 of 1633 matches
Mail list logo
