--- Comment #12 from t dot artem at mailcity dot com 2006-02-21 04:56
---
This bug may affect real applications performance so I believe it's worth being
resolved for 4.1.0 release. What if one changes severity to critical though
certanly this bug isn't critical?
--
http://gcc.gnu.
--- Comment #24 from sayle at gcc dot gnu dot org 2006-02-21 02:28 ---
Subject: Bug 26361
Author: sayle
Date: Tue Feb 21 02:28:03 2006
New Revision: 111327
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111327
Log:
PR tree-optimization/26361
* tree-vrp.c (extrac
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-21 02:22 ---
I am going to say there are better ways of optimizing this than using the
stack.
the easy way to optimize this in your code is to reserve the required size
before the loop, this is done in GCC also with the VEC alrea
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-21 02:20 ---
Confirmed but only for small sizes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-21 02:19
---
(In reply to comment #9)
> autoconf-2.59
> automake-1.9.6
> binutils-2.16.1
>
> Maybe thats the reason..
I doubt it. Maybe you have a messed up coreutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=263
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |rtl-optimizati
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26317
--- Comment #17 from patchapp at dberlin dot org 2006-02-21 00:32 ---
Subject: Bug number PR debug/2
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/2006-02/msg01635.html
--
http://gcc.gnu.org/bug
The patch which initial supports it is here:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01596.html
I am filing this bug so it does not get lost but I am no longer working on
Darwin bugs any more.
--
Summary: Darwin does not support -fsection-anchors
Product: gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 23:54 ---
No longer working on this, too much troubles are causing to me to fix Darwin
bugs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-20 23:53
---
No longer working on this, too much troubles are causing to me to fix Darwin
bugs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 23:53 ---
No longer working on this, too much troubles are causing to me to fix Darwin
bugs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 23:53 ---
No longer working on this, too much troubles are causing to me to fix Darwin
bugs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 23:53 ---
No longer working on this, too much troubles are causing to me to fix Darwin
bugs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-02-20 23:48
---
I am no longer going to work on this, it is too much hassle for me to get this
fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-20 23:37
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #6 from falk at debian dot org 2006-02-20 23:06 ---
(In reply to comment #5)
> If this is really not feasible or will not work in any useful cases,
> maybe exposing the stack to the user would be a nice thing to have.
> Like
>
> foo()
> {
>int *p = __builtin_stack_top
--- Comment #5 from rguenther at suse dot de 2006-02-20 22:52 ---
Subject: Re: Variable sized storage allocation
should be promoted to stack allocation
> --- Comment #4 from falk at debian dot org 2006-02-20 22:35 ---
> This would be incredibly difficult to detect reliably. B
--- Comment #5 from janis at gcc dot gnu dot org 2006-02-20 22:44 ---
A regression hunt turned up a patch that only affects gfortran, which of course
makes no sense because the test case is written in C. That usually indicates a
Heisenbug, but there are some things I can try.
--
ht
--- Comment #4 from falk at debian dot org 2006-02-20 22:35 ---
This would be incredibly difficult to detect reliably. But the main
problem is, on most operating systems, stack space is limited,
typically to something tiny compared to main memory like 8M, so this
wouldn't really be a goo
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-20 22:34 ---
make it return the largest prime, factors[factors.size()-1] instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-20 22:27 ---
Ok, here's a real example:
template
std::vector makeRBlocksFactor(T number)
{
std::vector factors;
for (T f=2; fhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 22:21 ---
Actually this is all dead code and should be removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
#include
void foo(int n)
{
std::vector v;
for (int i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 22:18 ---
I should note that even right now operator new is not marked with the malloc
attribute which is PR 23383.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26387
--- Comment #1 from aldyh at gcc dot gnu dot org 2006-02-20 22:18 ---
Mine
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at g
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 22:17 ---
Actually this is just dead code, see PR 19831.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26387
void foo(void)
{
int *p = new int;
delete *p;
}
storage allocation should be changed from heap to stack allocation if
possible and of known (low) size. This way allocation can be optimized
away completely in some cases. Such opportunities are often exposed
by inlining of libstdc++ container
--- Comment #3 from parcour at gmail dot com 2006-02-20 22:04 ---
Subject: Re: strdup "implicit declaration" warning when using -ansi
I see. Sorry for a needless bug report. But thank you for your
helpful responses. I expect
I really will need to use -ansi (--> STRICT_ANSI), so I'll
--- Comment #23 from roger at eyesopen dot com 2006-02-20 21:37 ---
Created an attachment (id=10883)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10883&action=view)
really revised patch
Grrr! The previous attachment was identical to the original. Third times a
charm (or I'll ju
--- Comment #22 from roger at eyesopen dot com 2006-02-20 21:33 ---
Created an attachment (id=10882)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10882&action=view)
revised patch
Doh! Although the previous attachment contained the necessary logic, it had
a few typos which will c
--- Comment #21 from roger at eyesopen dot com 2006-02-20 21:07 ---
Created an attachment (id=10881)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10881&action=view)
patch
I believe the following patch should resolve the problem. Bootstrap and
regression test in progress. The is
--- Comment #9 from xtv at tveith dot homelinux dot com 2006-02-20 21:05
---
(In reply to comment #8)
> Do you have any of the following variables set before building GCC:
>
> LD
> DEFAULT_LINKER
> ORIGINAL_LD_FOR_TARGET
> CONFIG_SITE
No:
[EMAIL PROTECTED] ~/gcc/out $ echo $LD
[EMAIL
--- Comment #8 from themis_hv at yahoo dot co dot uk 2006-02-20 20:57
---
Do you have any of the following variables set before building GCC:
LD
DEFAULT_LINKER
ORIGINAL_LD_FOR_TARGET
CONFIG_SITE
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
--- Comment #11 from anlauf at gmx dot de 2006-02-20 20:53 ---
(In reply to comment #10)
> Strange: with gfortran gcc-4.1-20060210+fix x86_64-unknown-linux-gnu
> it compiles and runs fine:
> bash> gfortran gfcbug31.f -Wall -O0 -g -fbounds-check && ./a.out
> In init1: npts = 1
--- Comment #20 from law at redhat dot com 2006-02-20 20:39 ---
Subject: Re: [4.2 regression] bootstrap failure on
Alpha: xgcc runs out of memory compiling libiberty/md5.c
On Mon, 2006-02-20 at 03:11 +, roger at eyesopen dot com wrote:
>
> --- Comment #10 from roger at
--- Comment #19 from law at redhat dot com 2006-02-20 20:38 ---
Subject: Re: [4.2 regression] bootstrap
failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
On Mon, 2006-02-20 at 20:35 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #18 from pin
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-02-20 20:34
---
(In reply to comment #17)
> No, because if it's marked as varying we will not use it to
> refine any other VRP ranges.
But this is an unsigned value which is varrying. [0, +INF] for an unsigned
value is varrying,
--- Comment #17 from law at redhat dot com 2006-02-20 20:32 ---
Subject: Re: [4.2 regression] bootstrap
failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
On Mon, 2006-02-20 at 05:11 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #16 from pin
--- Comment #7 from xtv at tveith dot homelinux dot com 2006-02-20 20:24
---
Hi..
whenever I use --program-prefix, bootstrap fails / otherwise it works just
perfect. To illustrate, this time i used the following configure:
../gcc-4.1.0-20060219/configure --prefix=/home/xtv --program-p
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 20:07 ---
Ok, either use -D_GNU_SOURCE or don't use -ansi. Use -pedantic-errors instead
of -ansi.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26386
--- Comment #13 from eedelman at gcc dot gnu dot org 2006-02-20 20:06
---
Subject: Bug 26201
Author: eedelman
Date: Mon Feb 20 20:06:49 2006
New Revision: 111311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111311
Log:
fortran/
2006-02-20 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 20:06 ---
This is not a GCC bug, strdup is not ISO C.
What is happening is that GCC is defining STRICT_ANSI and glibc says then you
cannot use another thing besides ISO C headers which means no strdup.
--
pinskia at gcc do
test.c -
#include
#include
int main()
{
char *s = strdup( "foo" );
free( s );
return 0;
}
compile in/out -
$ gcc -Wall -ansi test.c
test.c: In function main:
test.c:6: warning: implicit declaration of function strdup
test
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-20 19:54 ---
I just tried to reproduce this with exactly the options you used and I could
not. I then tried with a different prefix of /home/pinskia (my home directory)
and it still worked.
Is there something special with your
--- Comment #7 from mckinlay at redhat dot com 2006-02-20 19:47 ---
*** Bug 26351 has been marked as a duplicate of this bug. ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
---
--- Comment #2 from mckinlay at redhat dot com 2006-02-20 19:47 ---
You must be using a very old GCJ - this was fixed a long time ago.
*** This bug has been marked as a duplicate of 12475 ***
--
mckinlay at redhat dot com changed:
What|Removed |Ad
--- Comment #7 from aoliva at gcc dot gnu dot org 2006-02-20 19:38 ---
I can't really look into it because it's specific to an OS I don't have access
to.The proposed change looks reasonable. Reverting my change will very
likely break the build on well-behaved OSes.
I suppose it mig
--- Comment #2 from fang at csl dot cornell dot edu 2006-02-20 19:37
---
Subject: Re: 4.1 RC1 build failure on nm -P command
(darwin7)
> You don't have the correct nm in your path so this is
> not a bug. GCC requires a full install of cctools 590.12 to be
> install and accessible by
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-20 19:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 19:31 ---
You don't have the correct nm in your path so this is not a bug. GCC requires
a full install of cctools 590.12 to be install and accessible by just invoking
nm/as/etc.
--
pinskia at gcc dot gnu dot org changed:
gcc-4.1 RC1 (20060219) fails to create libstdc++-symbol.explist on
powerpc-apple-darwin7 with the following error message:
nm -P .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
.libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o
.libs/debug.o .libs/debug_lis
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 19:08 ---
Is there a simple testcase?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from eedelman at gcc dot gnu dot org 2006-02-20 18:50
---
(In reply to comment #11)
> (In reply to comment #10)
> > With this fix, trunk is now once again able to compile VASP. Too bad it
> > seems
> > to be a bit late to get into 4.1. Maybe 4.1.1?
> Actually it looks l
--- Comment #57 from aoliva at gcc dot gnu dot org 2006-02-20 18:37 ---
This should have long been closed.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-20 18:36
---
(In reply to comment #10)
> With this fix, trunk is now once again able to compile VASP. Too bad it seems
> to be a bit late to get into 4.1. Maybe 4.1.1?
Actually it looks like it was approved for 4.1 (after RC1 w
--- Comment #10 from jb at gcc dot gnu dot org 2006-02-20 18:34 ---
With this fix, trunk is now once again able to compile VASP. Too bad it seems
to be a bit late to get into 4.1. Maybe 4.1.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 18:22 ---
There is not enough information here to reproduce really and the directions
were not followed at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from janis at gcc dot gnu dot org 2006-02-20 18:12 ---
I got a regression hunt started but lost contact with the system it's running
on; network problem? If I can't get back to that system I'll set up somewhere
else and try again.
The failure also occurs with mainline fr
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc
-B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/libgomp/testsuite/libgomp.c/appendix-a/a.18.1.c
-B/mnt/
gnu/gcc-3.3/objdir/hppa64-hp-hpux11.11/./libgomp/
-I/mnt/gnu/gcc-3.3/objdir/hppa
64-hp-hpux11.11/./libgomp -I/mnt/gnu/gcc-3.3/gcc/libgomp
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25985
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26361
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 17:47 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 17:47 ---
Subject: Bug 25879
Author: pinskia
Date: Mon Feb 20 17:47:34 2006
New Revision: 111308
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111308
Log:
2006-02-20 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #17 from hjl at lucon dot org 2006-02-20 17:46 ---
A testcase patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01391.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-20 17:35 ---
*** Bug 25455 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-20 17:35
---
If make all-gcc works, I am happy so this is a dup of bug 25670.
*** This bug has been marked as a duplicate of 25670 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 17:17 ---
This is really a glibc bug as far as I can tell.
Lets look into what glibc exands the string functions to:
i=__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (data) &&
__builtin_constant_p (s) && (
--- Comment #2 from dorit at il dot ibm dot com 2006-02-20 17:09 ---
Actually there's this patch by rth that seems to fix this ICE; it's from a
while back, I don't think it was fully tested at the time, and I'm not sure it
provides all the missing bits/fixes for SSE support.
=== targhoo
--- Comment #1 from dorit at il dot ibm dot com 2006-02-20 16:45 ---
Looks like the vectorizer detects a strided access in this testcase. Strided
accesses are not entirely supported for SSE right now (work in progress...),
but it is enabled, so currently all strided testcases brake on SS
--- Comment #1 from andrew dot m dot roberts at tesco dot net 2006-02-20
16:41 ---
Created an attachment (id=10880)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10880&action=view)
gcc -v -save-temps -O3 -Wall output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26383
gcc version 4.1.0 20060219 (prerelease) produces spurious warnings when
used with -Wall and -O3 together. Previous released versions haven't had this
behaviour. It appears to be issuing multiple warnings when string functions are
inlined using the __builtin_ versions eg __builtin_strcmp. For exampl
--- Comment #8 from jv244 at cam dot ac dot uk 2006-02-20 16:32 ---
(In reply to comment #7)
> I'm guessing my change was in converting an if () abort () into gcc_assert,
> and
> not directly to blame for whatever's happening here.
Looks like you're right... I must have been reading to
--- Comment #7 from nathan at gcc dot gnu dot org 2006-02-20 16:24 ---
I'm guessing my change was in converting an if () abort () into gcc_assert, and
not directly to blame for whatever's happening here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25218
--- Comment #6 from jv244 at cam dot ac dot uk 2006-02-20 16:13 ---
> #4 0x006714fb in compensate_edge (e=0x2a959776c0, file=0x0) at
> /scratch/vondele/gcc_40_branch/gcc/gcc/reg-stack.c:2795
this assert was last modified by nathan (from svn ann, revision 87244), who
seems to b
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-02-20 16:13
---
*** Bug 20066 has been marked as a duplicate of this bug. ***
--
Bug 19543 depends on bug 20066, which changed state.
Bug 20066 Summary: Ordering of logical constants determines if they're
correctly emitted
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-02-20 16:13
---
This is indeed a dup of 19543 (at least, it's fixed by the same patch).
*** This bug has been marked as a duplicate of 19543 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-02-20
15:25 ---
(In reply to comment #1)
> Confirmed, I think Paul Thomas is looking into this.
Yes, I got sidetracked into it!
Something is awry with the adding of variables to an equivalence segment in
anything other
--- Comment #3 from roger at eyesopen dot com 2006-02-20 15:05 ---
Fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
Status|UNCONFI
--- Comment #2 from sayle at gcc dot gnu dot org 2006-02-20 15:05 ---
Subject: Bug 26236
Author: sayle
Date: Mon Feb 20 15:05:15 2006
New Revision: 111305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111305
Log:
PR middle-end/26236
* doc/c-tree.texi (INTEGER_T
--- Comment #9 from bonzini at gnu dot org 2006-02-20 14:47 ---
Just for the record, this patch also fixed PR12512 in a better way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12730
--- Comment #3 from bonzini at gnu dot org 2006-02-20 14:46 ---
Note for posterity, a better patch for this has been inserted as part as fixing
PR12730, and this patch has been sort of reverted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12512
Hi,
We have found a bug for SuperH when trying for crossjumping and
"-fif-conversion2" for gcc-3.4.4 and gcc-3.4.5.
Following is the simple test case,
//xfs2.c
1. void func (void)
2. {
3.if (foo3())
4. {
5.foo4
--- Comment #4 from pcarlini at suse dot de 2006-02-20 14:24 ---
Suspended, waiting for 342 (now reopened) to reach the final resolution.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|00
--- Comment #5 from ben dot midgley at ultra-datel dot com 2006-02-20
14:21 ---
I believe this is the same problem, if not it is a very similar and likely
related problem. I have nested the data types from the first code into an array
and have a similar message.
$ gcc -v
Using built-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 13:51 ---
Please read:
http://gcc.gnu.org/install/prerequisites.html
GNU tar version 1.12 (or later)
Necessary (only on some platforms) to untar the source code. Many systems' tar
programs will also work, only try GNU tar if
gcc-4.1.0-20060219.tar.bz2 won't untar with Solaris native tar.
x gcc-4.1.0-20060219/gcc/testsuite/gcc.dg/cpp/frame/one.framework/Frameworks, 0
bytes, 0 tape blocks
x
gcc-4.1.0-20060219/gcc/testsuite/gcc.dg/cpp/frame/one.framework/Frameworks/OneSub.framework,
0 bytes, 0 tape blocks
x
gcc-4.1.0-200
--- Comment #5 from themis_hv at yahoo dot co dot uk 2006-02-20 13:12
---
--program-prefix works fine on i686-pc-linux with GCC 4.1.0 RC 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 13:06 ---
If this worked with "20060217" and does not with the RC1, this actually does
not make sense as there have been no configuring changes made between that
time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 12:57 ---
Fixed in 3.4.5 at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 12:52 ---
It did work at least in "4.1.0 20051026".
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from xtv at tveith dot homelinux dot com 2006-02-20 12:33
---
Without --program-prefix it bootstraps fine. So it seems to be a problem with
the configure-machinery.
Shall I close this bug and open a new one regarding configure?
--
http://gcc.gnu.org/bugzilla/show_bu
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
Hello,
gcc 3.4.3 compiles and links the following code successfully:
#include
class X
{};
template
void g (const T & t)
{
std::cout << "Function g was called" << std::endl;
}
template
voidf()
{
T a;
g(a); // <--- Crucial line
}
int
m
--- Comment #3 from pcarlini at suse dot de 2006-02-20 11:15 ---
... but DR 342 should be also taken into account...
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-20 11:01 ---
Obviously with -O2 -m32 -mmmx for 32-bit compiles.
The testcase compiles in GCC 3.2.3 and 3.4.5, so a regression.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
#include
void
foo (__m64 *p)
{
__m64 m;
m = p[0];
m = _mm_srli_pi16(m, 2);
m = _mm_slli_pi16(m, 8);
p[0] = m;
_mm_empty();
}
ICEs with both -O2 -m32 and -O2 -m64, in GCC 4.0.2, 4.1rc1 as well as trunk.
--
Summary: ICE on vector shift RTL simplification
Prod
1 - 100 of 115 matches
Mail list logo
