--- Comment #2 from oliver at linux-kernel dot at 2007-11-23 07:55 ---
(In reply to comment #1)
> a testcase or even the error which you get would be nice. Also you might want
> to try 4.2.2.
I don't have 4.2.2 yet. I could try changing the existing specfile and and
build it, but that
--- Comment #1 from akr at m17n dot org 2007-11-23 07:52 ---
(In reply to comment #0)
> isnan(0.0/0.0) returns false.
> It returns true if -fno-builtin.
I found it is a problem of FPU emulation in Linux kernel.
The problem is caused by FASTFPE.
NWFPE doesn't have the problem.
--
ak
--- Comment #15 from ubizjak at gmail dot com 2007-11-23 07:43 ---
(In reply to comment #13)
> I think the bug can be closed as fixed now.
The problem of redundant stores has been fixed, but the code is far from
optimal. As evident from PR 17236, icc generates:
movl 8(%es
--- Comment #3 from steven at gcc dot gnu dot org 2007-11-23 07:38 ---
Re. comment #3: noticing a failure is not a test case. A test case is a piece
of example code that people can use to hunt this bug. Just mentioning "my
kernel does not boot" is not a test case.
Please read http://g
--- Comment #14 from steven at gcc dot gnu dot org 2007-11-23 07:36 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from ismail at pardus dot org dot tr 2007-11-23 06:02
---
Mainline now looks like :
[~]> cat mul.s
.file "mul.c"
.text
.p2align 4,,15
.globl mul
.type mul, @function
mul:
subl$8, %esp
movl%ebx, (%esp)
m
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-23 05:50 ---
The regression here is an error recovery issue.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-11-23 05:37
---
(In reply to comment #17)
> What about using the copied default SSA_NAME for the function arguments? That
> seems better and you don't need to rename the names.
Actually ignore this, I have not read the inliner c
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-11-23 05:33
---
What about using the copied default SSA_NAME for the function arguments? That
seems better and you don't need to rename the names.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
--- Comment #2 from Ashay dot Jaiswal at kpitcummins dot com 2007-11-23
05:11 ---
(In reply to comment #1)
> We need a testcase to do anything about this.
I have tested on released Linux kernel version 2.6.22.1 and kernel version
2.6.23.1 both hangs while booting, but boots succe
--- Comment #9 from manu at gcc dot gnu dot org 2007-11-23 04:19 ---
@Jakub
BTW, perhaps get_unwidened is more appropriate for this, since it takes into
account the target type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
--- Comment #8 from manu at gcc dot gnu dot org 2007-11-23 04:01 ---
(In reply to comment #5)
> I think 2) is strongly preferrable.
> Will try a patch tomorrow^H^H^H^H^H^H^H^Htoday.
I think so as well. Thanks for taking the bug. Let me know if you need help,
lose interest or don't have
I have two differences pakages name org.math.tool and org.gui.maintennance
contain java files, I want to compile these files to bin folder and create exe
file name Demo.exe, my main class is org.gui.maintenance.BeautifulLife.class
I don't know how to solve this problem, I tryed to solve it but i
--- Comment #2 from scovich at gmail dot com 2007-11-23 02:06 ---
Subject: Re: Scope broken for inherited members inside template class?
On 22 Nov 2007 21:03:11 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The issue comes down to if bar is dependent here and if so
--- Comment #7 from tom dot browder at gmail dot com 2007-11-23 02:05
---
Created an attachment (id=14624)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14624&action=view)
Intermediate file produced by g++-4.3-20071109
--
tom dot browder at gmail dot com changed:
W
--- Comment #6 from tom dot browder at gmail dot com 2007-11-23 02:03
---
Created an attachment (id=14623)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14623&action=view)
Output from running: g++-4.3-20071109 -v -save-temps -c -wconversion
test_conversion.cc
--
tom dot browde
--- Comment #10 from rask at gcc dot gnu dot org 2007-11-23 01:33 ---
I think both branches of "if (reverse)" could use the exact same code, i.e.
this whole reverse/!reverse idea is bogus on fr30. Suppose our output registers
are r1 and r2 and we receive the address in rN. Then, for any
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-11-23 00:19 ---
If you want a real private class use anonymous namespaces, that is what they
are designed for.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34200
--- Comment #7 from mat_geek at yahoo dot com dot au 2007-11-23 00:04
---
The output from the example code is
514: [EMAIL PROTECTED] ~/temp/eg/ $> ./main.exec
int main() in main.cpp at 14
void a() in a.cpp at 24
void A::f() in a.cpp at 13
void b() in b.cpp at 24
void B::f() in b.cpp a
--- Comment #6 from mat_geek at yahoo dot com dot au 2007-11-23 00:02
---
Created an attachment (id=14622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14622&action=view)
Example Code File Makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34200
--- Comment #5 from mat_geek at yahoo dot com dot au 2007-11-23 00:02
---
Created an attachment (id=14621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14621&action=view)
Example Code File Main
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34200
--- Comment #4 from mat_geek at yahoo dot com dot au 2007-11-23 00:02
---
Created an attachment (id=14620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14620&action=view)
Example Code File 3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34200
--- Comment #3 from mat_geek at yahoo dot com dot au 2007-11-23 00:01
---
Created an attachment (id=14619)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14619&action=view)
Example Code File 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34200
--- Comment #2 from mat_geek at yahoo dot com dot au 2007-11-23 00:01
---
Created an attachment (id=14618)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14618&action=view)
Example Code File 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34200
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-22 23:56 ---
One definition rule does not have to be diagnostic according to the C++
standard. To diagnose this, the compiler needs to have all of the
translational units.
--
pinskia at gcc dot gnu dot org changed:
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
I had two c++ files with private classes and other public functions. I linked
them with a third unit of main code (using gcc command line). Now the linker
linked the second compilation unit to the private class in the first
compilation unit not to its privat
--- Comment #6 from jsm28 at gcc dot gnu dot org 2007-11-22 23:12 ---
Subject: Bug 14050
Author: jsm28
Date: Thu Nov 22 23:12:29 2007
New Revision: 130362
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130362
Log:
PR c/14050
* c-decl.c (set_array_declarator_inner
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-22 23:04 ---
See the shorten code in e.g. c-typeck.c's build_binary_op.
I think there are two possible fixes:
1) if shortening (i.e. final_type != result_type) don't convert_and_check
to result_type, but instead convert to result_t
--- Comment #18 from dberlin at gcc dot gnu dot org 2007-11-22 23:02
---
Subject: Re: [4.3 Regression] SCCVN breaks gettext
On 22 Nov 2007 22:51:12 -, matz at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #17 from matz at gcc dot gnu dot org 2007-11-22 22:5
--- Comment #17 from matz at gcc dot gnu dot org 2007-11-22 22:51 ---
We could also save the deletes by using a tick counter, but with that patch
the hash tables will be mostly small anyway, so emptying them should be fast
enough I hope. And of course we won't get as optimal results as
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-22 22:43 ---
(In reply to comment #3)
> IMHO, the explicit casts (static_cast or function-style) should suppress the
> warnings.
That is not the problem. The explicit casts suppress the warnings for the
implicit conversion that occ
--- Comment #5 from mueller at gcc dot gnu dot org 2007-11-22 22:40 ---
*** Bug 32546 has been marked as a duplicate of this bug. ***
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from mueller at gcc dot gnu dot org 2007-11-22 22:40 ---
*** This bug has been marked as a duplicate of 34197 ***
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from mueller at gcc dot gnu dot org 2007-11-22 22:34 ---
thanks for the analysis. I would go for a slightly more verbose version of the
same patch:
--- gcc/tree-vrp.c (revision 130297)
+++ gcc/tree-vrp.c (working copy)
@@ -4339,7 +4339,7 @@ check_array_ref (tre
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-11-22 22:24
---
... Indeed - wrong types in the testcase :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-11-22 22:19
---
Bootstrapped / tested on x86_64, interestingly we manage to miscompile the
testcase at -O0 now :( (but this _must_ be unrelated to this fix!)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-22 22:09 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-22 22:00 ---
Same results on current trunk. Early inlining is already doing it because we
think putchs size (4 insns) when inlined will reduce the compilation units
size by 4 insns (the out-of-line copy of putch).
putchs IL bef
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-22 21:58 ---
Subject: Bug 33947
Author: jakub
Date: Thu Nov 22 21:58:07 2007
New Revision: 130359
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130359
Log:
PR target/33947
* config/arm/arm.c (arm_init_tls_
--- Comment #3 from fang at csl dot cornell dot edu 2007-11-22 21:52
---
I'm having some issues with this as well (same snapshot):
some more tests:
void f(const unsigned char b)
{
unsigned char c = static_cast(b & 0xff);
unsigned char d = (unsigned char)(b & 0xff);
char e = static_
Found by James Van Buskirk at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c8dd08d6da052499/
The following program gives an ICE in transfer; one may argue whether it is
valid or not, but I would expect that it works on all systems.
The crash occurs in:
==28354==at 0x
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-11-22 21:45
---
Thus, fixed in 4.3, wontfix for earlier releases.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from tom dot browder at gmail dot com 2007-11-22 21:37
---
Created an attachment (id=14617)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14617&action=view)
Intermediate file produced by g++-4.3-20071109
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
--- Comment #1 from tom dot browder at gmail dot com 2007-11-22 21:35
---
Created an attachment (id=14616)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14616&action=view)
Output from running: g++-4.3-20071109 -v -save-temps -c test_conversion.cc
--
http://gcc.gnu.org/bugzill
Consider the following code:
f.cc ==>
void f(const unsigned char b)
{
unsigned char c = static_cast(b & 0xff);
}
<== f.cc
Compile with g++ 4.1.2:
$ g++-4.3-20071109 -c f.cc -Wconversion
$
Note no warnings.
Compile with g++ 4.3-20071109:
$ g++-4.3-20071109 -c f.cc -Wconversion
f.cc: In fu
--- Comment #27 from sabre at nondot dot org 2007-11-22 21:14 ---
sounds fine to me, thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-22 21:03 ---
The issue comes down to if bar is dependent here and if so is baz's base.
The namelookup rules for being dependent are weird and hard to understand
really and actually changes namelookup in some cases so we have to
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-11-22 20:54
---
Created an attachment (id=14615)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14615&action=view)
prototype patch
Patch clearing the optimistic tables before every iteration and doing a
fallback
lookup on th
Answering my own question:
The `-finline-limit=N' option allows you to adjust the inline
threshold. The documentation says the default is 600. A value of <= 35
ensured that my 116 byte function was not inlined, which suggests that
a more reasonable default value on the AVR might be around 20.
I st
As Shaun Jackman wrote:
> With GCC r130284 --target=avr, a 116 byte static function that is
> called twice is inlined even with -Os, effectively doubling the
> function's footprint.
Sorry, but that's really off-topic for avr-libc-dev. Use
<[EMAIL PROTECTED]> instead, please.
I've already filed
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-22 20:36 ---
a testcase or even the error which you get would be nice. Also you might want
to try 4.2.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-22 20:35 ---
We need a testcase to do anything about this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from heinzl at gsse dot at 2007-11-22 20:32 ---
Subject: Re: xgcc: Internal error: Segmentation fault (program cc1plus)
> --- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-22
> 20:29 ---
> how are you invoking make?
just a simple
./make
--
http:/
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-22 20:29 ---
how are you invoking make?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
With GCC r130284 --target=avr, a 116 byte static function that is
called twice is inlined even with -Os, effectively doubling the
function's footprint. I'd argue a function this large shouldn't even
be inlined with -O2. What is the size cutoff for inlining functions?
Can I modify it? If a code snip
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-11-22 19:38
---
> Please notice that when using both -m64 -mptr64 this internal error does not
> occur.
Right, -mptr64 should *never* be used. Just use -m64 as documented.
--
ebotcazou at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-22 19:34 ---
Indeed. EXPR_LOCUS no longer is NULL if there is no location, but one has
to use EXPR_HAS_LOCATION instead. Like
Index: tree-vrp.c
===
--- tree-vrp.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-22 19:28 ---
The expression warned about is
call_5(D)->ret[5]
and I suspect the mapped locations make the location information wrong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from patchapp at dberlin dot org 2007-11-22 19:03 ---
Subject: Bug number PR34187
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01165.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from patchapp at dberlin dot org 2007-11-22 19:03 ---
Subject: Bug number PR33541
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01166.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from patchapp at dberlin dot org 2007-11-22 19:02 ---
Subject: Bug number PR c/23722
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01159.html
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from patchapp at dberlin dot org 2007-11-22 19:01 ---
Subject: Bug number PR34079
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01109.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #7 from kargl at gcc dot gnu dot org 2007-11-22 19:00 ---
(In reply to comment #6)
> Created an attachment (id=14609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14609&action=view) [edit]
> Patch (reverted Rev 117584) plus test case
>
> Initial implementation by reve
--- Comment #21 from patchapp at dberlin dot org 2007-11-22 19:00 ---
Subject: Bug number PR16350
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00362.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:55 ---
Added assembly files from testbd.f for i386-redhat-linux and
i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:54 ---
Created an attachment (id=14614)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14614&action=view)
assembly file generated from testbd.f on i386-redhat-linux (Fedora 8)
--
http://gcc.gnu.org/bugzi
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:53 ---
Created an attachment (id=14613)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14613&action=view)
assembly file generated from testbd.f on i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #1 from marcus at jet dot franken dot de 2007-11-22 18:48
---
Created an attachment (id=14612)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14612&action=view)
relay16.i
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34197
LANG=C /home/marcus/projects/gcc/BIN/bin/gcc -c -O2 -Wall -g -o xx.o
relay16.i -m32
relay16.i: In function 'f':
cc1: warning: array subscript is above array bounds
-m32 seems necessary
--
Summary: array overflow warning without line number
Product: gcc
Versio
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:47 ---
As requested by Mike Stump, i've uploaded the assembly files generated with -S
for the testsub.f source file of blockdata_test for both i686-apple-darwin9
(which fails to pass) and i386-redhat-linux (which
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:45 ---
Created an attachment (id=14611)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14611&action=view)
assembly file generated from testsub.f on i386-redhat-linux (Fedora 8)
--
http://gcc.gnu.org/bugz
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:42 ---
Created an attachment (id=14610)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14610&action=view)
assembly file generated from testsub.f on i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #6 from burnus at gcc dot gnu dot org 2007-11-22 18:41 ---
Created an attachment (id=14609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14609&action=view)
Patch (reverted Rev 117584) plus test case
Initial implementation by reverting Rev. 117584 as suggested by Steve
--- Comment #5 from burnus at gcc dot gnu dot org 2007-11-22 18:05 ---
Hmm, this does not seem to be easily possible in MPFR.
http://websympa.loria.fr/wwsympa/arc/mpfr/2007-11/msg00026.html
Possible implementation (as of 2005) by Tobias Schlüter:
http://gcc.gnu.org/ml/fortran/2005-0
--- Comment #33 from stsp at users dot sourceforge dot net 2007-11-22
17:27 ---
> For -O0 expecting
> int i = 1;
> asm ("" :: "i" (i));
> to work is certainly bad assumption
Btw, even the
static const int i = 1;
asm ("" :: "i" (i));
doesn't work with both -O0 and -O1. :(
--
http://
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-22 17:08 ---
Regarding the range check: We need to disable the check for denormal numbers;
as overflow etc. cannot occur, this boils down to check only for NaN.
Regarding the result, I think we have a problem with MPFR. The foll
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-22 17:04 ---
The remaining difference is register allocation issue:
time ./pr23305-vanilla; time ./pr23305-fixed
real0m4.030s
user0m4.028s
sys 0m0.002s
real0m1.593s
user0m1.592s
sys 0m0.001s
with hand-e
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-22 16:41 ---
On x86_64-linux -m64 with -O2 gcc doesn't hoist movabsq insns out of the loops,
which can give some performance back:
time ./pr23305-slow
real0m4.028s
user0m4.023s
sys 0m0.003s
time ./pr23305-slow2
real
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-22 16:27 ---
Seemingly the problem was introduced by the following patch, which fixed
another NEAREST problem.
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00249.html
http://gcc.gnu.org/viewcvs?view=rev&revision=117584
2006-10-09 S
#include
template class AutoPtr {
_Tp* _M_ptr;
public:
explicit AutoPtr(_Tp* __p = 0) : _M_ptr(__p) {}
~AutoPtr() { delete _M_ptr; }
_Tp* operator->() const {
return _M_ptr;
}
};
struct A {
virtual ~A();
virtual A * unserialise(const std::string &s) const = 0;
};
A *
--- Comment #20 from tbm at cyrius dot com 2007-11-22 16:12 ---
The failure is gone.
--
tbm at cyrius dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-22 16:11 ---
I believe there is indeed a bug in gfortran. The standard says that the "the
nearest different machine-representable number" is returned.
However, gfortran returns a number which is not representable (denormal or
sma
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-22 16:11 ---
On the trunk there is no difference between -O2 and -O2 -finline-functions
(the latter is perhaps 1% better), both are as bad as 4.1/4.2 with -O2
-finline-functions. Compiling with -O2 -fno-inline-small-functions give
--- Comment #19 from rguenther at suse dot de 2007-11-22 16:09 ---
Subject: Re: [4.3 Regression] ICE verify_ssa
failed (missing definition for SSA_NAME)
On Thu, 22 Nov 2007, tbm at cyrius dot com wrote:
> --- Comment #18 from tbm at cyrius dot com 2007-11-22 15:58 ---
> (In
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-22 16:01 ---
Actually the refined patch at
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02550.html should be more
up-to-date.
Still the idea of an alias oracle needs to be done elsewhere. We'll be working
on it.
--
rguenth
--- Comment #9 from markus dot heigl at fme dot fujitsu dot com 2007-11-22
15:59 ---
Seems to work for this testcase.
I think the else path of if (reverse) should also be changed in the same way.
Do you agree?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
--- Comment #18 from tbm at cyrius dot com 2007-11-22 15:58 ---
(In reply to comment #17)
> neither with the original nor with the reduced testcase. Martin, can you
> confirm that this is fixed?
Works for me with 20071116 too.
I just checked again and the problem is there with 2007102
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-22 15:53 ---
*** Bug 34194 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-22 15:53 ---
*** This bug has been marked as a duplicate of 34192 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from jakub at gcc dot gnu dot org 2007-11-22 15:52 ---
Or alternatively make sure to gimplify all inputs which allow reg or mem
first, then gimplify those that don't allow either, which for -O0 should
hopefully mean all such expressions stay in the same basic block as the
--- Comment #31 from jakub at gcc dot gnu dot org 2007-11-22 15:41 ---
Could we perhaps for !optimize allow in ASM input operands arbitrary
tree expressions if TREE_CONSTANT for operands which !allows_mem &&
!allows_reg?
Then we'd just need to make sure the few -O0 passes are able to cop
--- Comment #13 from dberlin at gcc dot gnu dot org 2007-11-22 15:35
---
Subject: Re: [4.3 Regression] SCCVN breaks gettext
On 22 Nov 2007 14:03:35 -, matz at suse dot de
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #9 from matz at suse dot de 2007-11-22 14:03 ---
> Subje
--- Comment #5 from doko at gcc dot gnu dot org 2007-11-22 15:34 ---
Subject: Bug 34130
Author: doko
Date: Thu Nov 22 15:34:03 2007
New Revision: 130352
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130352
Log:
2007-11-22 Matthias Klose <[EMAIL PROTECTED]>
Backport f
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-11-22 15:32
---
I cannot reproduce this with
# g++ -c -O3 t.ii -v
Using built-in specs.
Target: ia64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/sh
The following loop does not get vectorized
on powerpc64-linux, r130275, GCC 4.3.0:
#define M 10
struct S
{
float x;
float y;
} pS[100];
float a[1000];
float b[1000];
void
foo (int n)
{
int i, j;
for (i = 0; i < n; i++)
{
pS[i].x = 0;
pS[i].y = 0;
for (j = 0; j <
--- Comment #16 from rguenther at suse dot de 2007-11-22 15:24 ---
Subject: Re: [4.3 Regression] ICE verify_ssa
failed (missing definition for SSA_NAME)
On Thu, 22 Nov 2007, dorit at gcc dot gnu dot org wrote:
> --- Comment #15 from dorit at gcc dot gnu dot org 2007-11-22 15:17
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:22 ---
closed, given recent feedback
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-22 15:19 ---
On the simplified:
extern int s;
void
foo (int *x, int y, int z)
{
int m, n;
int o;
int p = x[0];
o = s;
for (m = 0; m < s; m++)
for (n = 0; n < s; n++)
{
if (x[n] != p)
continue;
--- Comment #15 from dorit at gcc dot gnu dot org 2007-11-22 15:17 ---
(In reply to comment #12)
...
> > Richard, is this related to the issue you reported in
> > http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01127.html
> > (looks like the same error)?
...
> Yes, these are likely similar
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:14 ---
(In reply to comment #13)
> Dorit, can you please take a look again?
I will not be able to look into this in the next couple of weeks, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
1 - 100 of 160 matches
Mail list logo
