--- Comment #14 from ubizjak at gmail dot com 2007-05-17 07:45 ---
Altivec PPC has int->float cvt insn and provides signed/unsigned vec_unpack
v8hi insn. It should be trivial to implement short->float and unsigned
short->float conversions by providing vec_unpacks_float_lo_v8hi,
vec_unpac
--- Comment #1 from lloyd at randombit dot net 2007-05-17 07:36 ---
Created an attachment (id=13567)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13567&action=view)
A short testcase for bug 31966
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
$ gcc-4.2.0 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2.0/configure --enable-languages=c,c++,objc,obj-c++
--program-suffix=-4.2.0
Thread model: posix
gcc version 4.2.0
$ gcc-4.2.0 divop.c -o divop
$ ./divop
3CBA83
$ gcc-4.2.0 -ftree-vectorize -O2
--- Comment #13 from uros at gcc dot gnu dot org 2007-05-17 07:31 ---
Subject: Bug 24659
Author: uros
Date: Thu May 17 06:31:05 2007
New Revision: 124784
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124784
Log:
PR tree-optimization/24659
* optabs.h (enum optab_
--- Comment #7 from s__nakayama at infoseek dot jp 2007-05-17 06:04 ---
Fixed already in 4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29927
--- 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 #4 from jvdelisle at gcc dot gnu dot org 2007-05-17 04:00
---
The patch in comment #3 is incorrect. I have the correct patch coming and will
post to list for approval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
--- Comment #2 from danglin at gcc dot gnu dot org 2007-05-17 03:55 ---
Test case also fails to compile on hppa64-hp-hpux11.11. Compiler
hangs in cse1 pass, apparently doing garbage collection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #2 from price at ifa dot hawaii dot edu 2007-05-17 03:19
---
This is also a problem on my amd64 Gentoo laptop, using gcc version Gentoo
4.1.1-r3.
I searched the binutils Bugzilla, but could not find a bug filed for this
problem.
Because the problem disappears when optimisa
--- Comment #49 from manu at gcc dot gnu dot org 2007-05-17 02:52 ---
(In reply to comment #48)
> Created an attachment (id=13561)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13561&action=view) [edit]
> patch for testsuite infrastructure
>
> This patch overrides dg-error and dg-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 02:42 ---
It was added with:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00979.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31965
The macro _INTEGRAL_MAX_BITS is a defined as a builtin macro with an incorrect
value on mingw32. This Microsoft C specific macro is supposed to report "the
maximum size (in bits) for an integral type". In GCC's case this would be 64,
the size of a long long, not 32 as it currently defines the mac
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-17 01:49
---
I think we have an off by one when setting mask. I want to do some testing and
double check on all this. Here is a patch:
Index: ishftc.c
===
***
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-17 01:30
---
$ gfc shifter.f90
$ ./a.out
32
2
1
1
$ ifort shifter.f90
$ ./a.out
32
2
2
2
$
--
jvdelisle at gcc dot gnu dot org change
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-17
01:30 ---
Subject: Re: FAIL: gfortran.dg/integer_exponentiation_3.F90 at -O0 and above
> All I have access to is hppa2.0w-hp-hpux11.23, do you think it would be
> triggered there also?
Probably, since HP has pretty
--- Comment #1 from kargl at gcc dot gnu dot org 2007-05-17 00:51 ---
What output were you expecting?
write(*,*) ishftc(aint,1)
write(*,*) ishftc(aint,1,32)
write(*,*) ishftc(aint,1,BIT_SIZE(aint))
All three of these statements are shifting the 32-bit representation of
of 1 to l
--- Comment #77 from mark at codesourcery dot com 2007-05-17 00:41 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> I don't believe that the C++ standards writers really meant to eliminate
> TBAA.
--- Comment #1 from patchapp at dberlin dot org 2007-05-17 00:05 ---
Subject: Bug number PR c++/31745
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-05/msg01091.html
--
http://gcc.gnu.org/bugzil
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:49 ---
sqrt is part of glibc so report it there.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:45 ---
*** Bug 31958 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:45 ---
*** This bug has been marked as a duplicate of 31955 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
If the third argument of ishftc equals BIT_SIZE of the first argument, the
result shall be the same as if the last argument was omitted.
program main
implicit none
integer aint
aint=1
write(*,*) BIT_SIZE(aint)
write(*,*) ishftc(aint,1)
write(*,*) ishftc(aint,1,32)
write(*,*) ishft
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 23:16 ---
This is not a bug, local classes cannot be template arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31951
--- Comment #9 from dtemirbulatov at gmail dot com 2007-05-16 22:47 ---
This patch fixes both testcases
--- gcc/varasm.c.orig 2007-05-16 21:32:11.0 +0400
+++ gcc/varasm.c2007-05-16 21:36:14.0 +0400
@@ -5762,12 +5762,14 @@ categorize_decl_for_section (tree decl,
--- Comment #15 from dannysmith at users dot sourceforge dot net
2007-05-16 21:34 ---
(In reply to comment #13)
> Subject: Re: Compile errors with multiple inheritance where
> the stdcall attribute is applied to virtual functions.
>
> rridge at csclub dot uwaterloo dot ca wrote:
> >
--- Comment #2 from waldemar dot rachwal at googlemail dot com 2007-05-16
21:13 ---
Subject: Re: Premature hiding of symbols makes a copy constructor shooting at
its own foot
Hey,
Maybe I don't catch your "process", but #31961 and #31960 both refer
to the same (identical) text of mine
--- Comment #6 from daney at gcc dot gnu dot org 2007-05-16 21:10 ---
Marking as FIXED as it now works for me *if* I use a current native GCC to
build the cross compiler.
I am prepering a documentation patch that explains my interpretation of the
requirements.
--
daney at gcc dot gn
--- Comment #2 from fang at csl dot cornell dot edu 2007-05-16 20:56
---
I concur. If you want to forcibly delay the dependence on the complete type
until instantiation time, you could use a nested typedef in the class template,
like:
class NonDependent;
template
struct foo {
type
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 20:55 ---
This fixes it and much more besides. It needs commenting and tidying up.
Paul
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (révi
--- Comment #1 from fang at csl dot cornell dot edu 2007-05-16 20:46
---
Poor man's workaround: -Wshadow -Werror
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--
--- Comment #3 from dorit at il dot ibm dot com 2007-05-16 20:45 ---
(In reply to comment #2)
> Here is what happens in the three loops that don't get vectorized:
> (1) the loop in testvectdp2:
...
> so the vectorizer is ok, except that in this case D.1437_32 doesn't seem to >
> be use
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-16 20:07 ---
*** Bug 31962 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 20:07 ---
*** This bug has been marked as a duplicate of 31950 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pbrook at gcc dot gnu dot org 2007-05-16 20:05 ---
Fixed.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01010.html
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:47 ---
*** This bug has been marked as a duplicate of 31960 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:47 ---
*** Bug 31961 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31960
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 19:43 ---
> When I compile with "--enable-checking=?" the "checking" is performed on
> stages 2,3 and the libraries - it is NOT performed on stage 1.
I filed a bug about this while back and it was fixed, see PR 29544.
--
This bug report is listed for the HTB i686-pc-linux-gnu but actually affects
ALL platforms.
The reason I chose to put this under the "Component" choice "driver" is because
there is no choice for "documentation" and it does involve renaming one of the
compiler command line options.
---
When I com
--- Comment #1 from dcb314 at hotmail dot com 2007-05-16 19:34 ---
Created an attachment (id=13565)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13565&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31962
I just tried to compile Suse Linux package icecream-0.7.14a-5 with the GNU C
compiler version 4.3 snapshot 20070511
The compiler said
minilzo.c: In function '_lzo_config_check':
minilzo.c:2162: internal compiler error: tree check: expected tree that
contains 'decl common' structure, have 'struct
When I create an object using copy constructor syntax, giving it other object
of that type and (crucial) the same name as the object just being
constructed... the compiler treats that "other" object as the object being
constructed(!) Similar effects I get with the builtin data types.
Below is the
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-16 18:23 ---
I don't think this is a bug. C0 is not dependent so it has to be complete when
the new is parsed in the template.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31954
When I create an object using copy constructor syntax, giving it other object
of that type and (crucial) the same name as the object just being
constructed... the compiler treats that "other" object as the object being
constructed(!) Similar effects I get with the builtin data types.
Below is the
--- 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.
If we rea
--- Comment #75 from rguenth at gcc dot gnu dot org 2007-05-16 17:08
---
In the chance of endlessly repeating myself here (;)) - what comment #73 boils
down to is that we may not prune alias sets of stores based on TBAA results.
In fact, we need to realize that C++ object lifetime rules
--- Comment #1 from tbm at cyrius dot com 2007-05-16 16:58 ---
struct btree_priv *area;
typedef struct bt_node_t
{
int next;
int used;
}
bt_leaf_t;
typedef union bt_page_t
{
bt_leaf_t leaf;
}
bt_page_t;
static inline bt_page_t *
vbt_deref (struct btree_priv *bt)
{
}
static inline b
4.3 ICEs during error recovery. This doesn't happen with 4.2.
(sid)24008:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 -Werror
btree.c
cc1: warnings being treated as errors
btree.c: In function 'bt_deref':
btree.c:20: error: passing argument 1 of 'vbt_deref' discards qualifiers from
--- Comment #4 from tbm at cyrius dot com 2007-05-16 16:39 ---
CCing Richi in case he didn't see the comment saying that his patch works.
--
tbm at cyrius dot com changed:
What|Removed |Added
I hesitate to report this because it seems so obvious I must be wrong:
gcc-4.2.0/INSTALL only contains the README file (which says to look in
index.html). In previous tarballs, INSTALL contained the config/build/etc.
instructions as HTML files.
I haven't seen anything that would suggest that it i
$ configure --enable-languages=c,c++ --with-ld=/bin/ld --with-as=/bin/as
$ make
leads to:
In file included from
.../obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/cctype:50,
from
.../gcc-4.2.0/libstdc++-v3/include/precompiled/stdc++.h:38:
.../obj/powerpc-ibm-aix5.2.0.0/libstdc++
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2007-05-16 16:07
---
Your patch seems to fix the failure for both reduced test cases
as well as the original code. Thanks for the prompt response!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-16 16:03 ---
Magically fixed itself.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The C++ standard, clauses 3.3.2 paragraph 4, and 6.4 paragraph 3, states that
names declared in the condition of `while', `if', `for' and `switch'
statements, may not be redeclared in any of the outermost controlled blocks.
This does work for `while' statements, however it does not work with `if',
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:46
---
All I have access to is hppa2.0w-hp-hpux11.23, do you think it would be
triggered there also?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31833
I hesitate to report this because it seems so obvious I must be wrong:
gcc-4.2.0/INSTALL only contains the README file (which says to look in
index.html). In previous tarballs, INSTALL contained the config/build/etc.
instructions as HTML files.
I haven't seen anything that would suggest that it i
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 15:43 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-16 15:41 ---
Confirmed.
Index: tree-ssa-alias-warnings.c
===
--- tree-ssa-alias-warnings.c (revision 124763)
+++ tree-ssa-alias-warnings.c (working copy)
@@ -63
--- Comment #74 from rguenth at gcc dot gnu dot org 2007-05-16 15:36
---
Note that another solution to this whole problem is to record conflicts for
all stored-to types that we cannot disambiguate by points-to analysis. This
also solves the reading of the standard that allows
int i
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:34
---
On mainline, we currently require GMP >= 4.1, for which this transformation is
safe (the mpz_get_ui inline function in gmp.h was corrected to avoid this
warning). Thus, simply removing these lines should work fine
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-16 15:24 ---
You are accessing memory of type structC via a pointer of type structB * which
violates C aliasing rules.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
The following code works on gcc-4.1.2, but is rejected with gcc-4.2.0:
class ABC0
{
public:
virtual ~ABC0() = 0;
virtual int something() = 0;
};
inline ABC0::~ABC0()
{ }
struct C0;
struct ABC1 : public ABC0
{
explicit ABC1()
: ABC0()
{ }
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--- Comment #1 from tbm at cyrius dot com 2007-05-16 15:04 ---
Reduced testcase:
struct WView
{
int hexedit_mode:1;
};
toggle_hexedit_mode (struct WView *view)
{
if (view->hexedit_mode)
{
}
else
{
view->hexedit_mode = !view->hexedit_mode;
}
}
--
http://g
--- Comment #73 from rguenth at gcc dot gnu dot org 2007-05-16 15:02
---
For the following testcase, loop store motion re-orders the writes to *l and *f
at -O2. (Note as is, the testcase is only valid for n == 1)
inline void* operator new(unsigned long, void* __p) throw() { return __p
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-05-16 15:01
---
Fixed on mainline and 4.2.1
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #72 from rguenth at gcc dot gnu dot org 2007-05-16 14:49
---
inline void* operator new(unsigned long, void* __p) throw() { return __p; }
extern void bar();
float foo(double *p)
{
long *l = (long *)p;
*l = 1;
float *f = new (p) float;
*f = 0.0;
bar ();
return *f
This worked with 4.3.0 20070422 but fails now with 20070515:
(sid)23934:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 mc-view.i
view.c: In function 'toggle_hexedit_mode':
view.c:2045: internal compiler error: in set_value_range, at tree-vrp.c:305
Please submit a full bug report,
with
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-05-16 14:36
---
Subject: Bug 31725
Author: fxcoudert
Date: Wed May 16 13:36:03 2007
New Revision: 124769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124769
Log:
PR fortran/31725
* trans-expr.c (gfc_co
--- Comment #1 from patrick dot olinet at gmail dot com 2007-05-16 14:23
---
Notice that this bug prevents loading and running java bytecode from a native
code binary compiled with gcj. I guess it relies on libffi to call the methods
of the bytecode.
This java problem is what I've enc
According to the C++ standard, clause 3.3.2, paragraph 2, sentence 3, the
following program should be invalid:
int
foo (int bar)
try
{
return 0;
}
catch (...)
{
int bar = 0; // invalid
return 1;
}
Specifically, `bar' may not be redeclared in the outermost block of a handler
in a function tr
--- Comment #23 from manu at gcc dot gnu dot org 2007-05-16 14:03 ---
Hi Naimu, I am not speaking in the name of the GCC community but I would like
to prevent your frustration. You exposed your point clearly. People that have a
deep knowledge of C++ and g++ don't agree with you. Repeatin
--- Comment #5 from ian dot rogers at manchester dot ac dot uk 2007-05-16
14:01 ---
For the following code given in [1] GCC produces identical multiplication by
constant code [2]. I think as 0x0 is one of the parameters in this bug
the fact we generate identical multiplication c
2nd call to partial_sort gives 'no match...' error, but 1st is OK.
Doesn't seem right.
#include
#include
template
struct Sort_Func2 {
vector_t const& mag;
Sort_Func2 (vector_t const& _mag) : mag (_mag) {}
bool operator() (int a, int b) const { return mag [a] < mag [b]; }
};
template
vo
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2007-05-16 13:35
---
Reduced test case. Both tests also fail with current mainline (revision
124767M).
struct B {
~B();
};
struct A {
B* b;
virtual ~A() { delete[] b; }
};
A Op(void);
int main()
{
A a(Op());
return 0;
With mainline as of a couple of days ago:
| gcc version 4.3.0 20070514 (experimental)
g++ -O2 -Wstrict-aliasing=3 -c t.cc
gives me this error:
| t.cc: In function int main():
| t.cc:11: internal compiler error: tree check: expected tree that contains
decl common structure, have struct_field_
--- Comment #71 from rguenth at gcc dot gnu dot org 2007-05-16 13:05
---
But it doesn't fix the POOMA miscompilations if I change its Pool allocator to
use placement new instead of this
// Release a block to the pool.
inline void free(void *b)
{
// Record a free.
ou
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-05-16 13:02
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENE
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-05-16 12:57
---
Subject: Bug 26998
Author: rguenth
Date: Wed May 16 11:57:09 2007
New Revision: 124767
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124767
Log:
2007-05-16 Richard Guenther <[EMAIL PROTECTED]>
Hello all,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problem while executing the following C program.
-
Hello all,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problem while executing the following C++ program.
-
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |middle-end
Keywords||ice-on-valid-c
--- Comment #2 from tbm at cyrius dot com 2007-05-16 11:29 ---
Note that the testcases from PR30509 work fine with 4.2, so this appears to
be a different bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
--- Comment #1 from tbm at cyrius dot com 2007-05-16 11:26 ---
Created an attachment (id=13564)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13564&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
I'm getting the following ICE with gcc 4.2.0 RC3. It compiles fine
with gcc 4.1 and 4.3 20070515.
(sid)23889:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
freehdl-vital_timing.cc
freehdl-vital_timing.cc: In function 'array_type delay(const
array_type&)':
freehdl-vital_timing.cc:38: i
--- Comment #1 from aurelien at aurel32 dot net 2007-05-16 11:08 ---
The problem is also present in gcc HEAD (SVN from today) built as a
cross-compiler on x86_64-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #70 from rguenth at gcc dot gnu dot org 2007-05-16 10:57
---
The last patch looks good sofar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-16 10:23 ---
/home/tbm/src/digikam-0.9.1/./digikam/libs/widgets/metadata/iptcwidget.cpp:159:
error: request for member 'c_str' in '
?
so there seems to be an error. Of course we probably ICE during error
reporting
which may co
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-05-16 10:20
---
Reopen, because this happens on the 4.1 branch as well with -O2 -ftrapv
void f1(int);
void f2(int x)
{
if (x != -2147483647 - 1)
f1(-x);
}
--
rguenth at gcc dot gnu dot org changed:
Wha
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-16 10:18 ---
Confirmed. A regression with -O2 -ftrapv.
Program received signal SIGSEGV, Segmentation fault.
0x00830f6e in compare_values (val1=0x0, val2=0x2ac511f0e9f0)
at /space//rguenther/src/svn/gcc-4_1-branch/gc
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-05-16 10:18
---
*** Bug 31940 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 09:50 ---
Over to you, Daniel - I was smiling when I mentioned using the time for
something else; there was no need to apologise.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
The vectorizer is too restricted in the way it decides by how many iterations
to peel a loop in order to align a certain memory reference in a loop. It
considers only the first (potentially) misaligned store it encounters in the
loop. For this reason the testcases vect-multitypes-1.c, vect-multityp
Since the following patch:
2007-04-22 Uros Bizjak <[EMAIL PROTECTED]>
PR tree-optimization/24659
GCC supports vectorization of float<-->double conversions. These can also be
modelled for the spu target by implementing the following patterns:
vec_pack_trunc_v2df
vec_unpacks_lo_v4sf
vec_
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-16 09:15 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 09:14 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-16 09:13 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-16 09:11 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pault at gcc dot gnu dot org 2007-05-16 09:10 ---
Fixed on trunk
Paul and Brooks
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from raf2 at msux dot cjb dot net 2007-05-16 08:50 ---
Mmm... maybe I haven't explained correctly.
If you contract someone to build stairs and later he says: "As long as you
don't touch this step, everything's ok" you tell him some nasty things.
The users of our g++ pro
99 matches
Mail list logo