--- Comment #14 from dfranke at gcc dot gnu dot org 2007-07-26 06:57
---
> case FL_UNKNOWN:
>+ if (sym->attr.access == ACCESS_PUBLIC)
>+ break;
> if (gfc_add_flavor (&sym->attr, FL_VARIABLE,
> sym->name, NULL) == FAILURE)
>return MAT
--- Comment #12 from leo at marco dot de 2007-07-26 06:33 ---
Subject: Re: [4.2 Regression] building a crosscompiler
for arm-elf fails because of an error in cirrus.md
pbrook at gcc dot gnu dot org wrote:
> --- Comment #11 from pbrook at gcc dot gnu dot org 2007-07-25 15:47
> --
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu dot
|
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-07-26 05:35
---
This fixes the infinite recursive loop and fixes a segfault I was getting on
the original test case. The test case in comment #8 is something different.
Index: resolve.c
=
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-07-26 04:56
---
I will prepare a submittal to the list. Regression tested OK too.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-07-26 04:54
---
This test case appears to execute correctly:
module gfcbug68
implicit none
public :: write
contains
function foo (i)
integer, intent(in) :: i
integer foo
write (*,*) i
foo = i
end fun
Dear working group,
Although it looks quite simple, I found the code which implicitly
converts a const char* to char*:
char* str = "Helloworld";
*str = 'a';
It can be legally compiled, and certainly produces an error when
running.
I'm not certain whether it's actually a bug or not.
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-07-26 04:02
---
The following seems to allow the test case to compile without error:
Index: primary.c
===
--- primary.c (revision 126937)
+++ primary.c (workin
--- Comment #5 from cnstar9988 at gmail dot com 2007-07-26 02:29 ---
Why the behavior on both platform is not the same?
same code, same release of GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-26 01:23 ---
I am just going to close this as being fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from dtemirbulatov at gmail dot com 2007-07-26 01:16 ---
this issue could not be reproduced on the mainline after dataflow-branch merge
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
--- Comment #20 from dannysmith at users dot sourceforge dot net
2007-07-26 00:34 ---
(In reply to comment #18)
>
> Under mingw, gfortran has some trouble. I am still experimenting and testing
> on mingw which I just got installed on my test machine here. I should be able
> to finish
--- Comment #8 from kristerw at gcc dot gnu dot org 2007-07-26 00:01
---
Fixed on trunk for NetBSD 2.x, 3.x, and 4.x.
--
kristerw at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-25 23:57 ---
Confirmed.
Volker's suggestion is the correct fix. I have a patch
and test case. I'm regression testing I as I type.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #7 from kristerw at gcc dot gnu dot org 2007-07-25 23:51
---
Subject: Bug 30058
Author: kristerw
Date: Wed Jul 25 23:51:47 2007
New Revision: 126937
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126937
Log:
2007-07-24 Krister Walfridsson <[EMAIL PROTECTED]>
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2007-07-25 23:35
---
Regarding my comment #18 on cygwin. There should be no dollar signs in the
device name.
Thus: /dev/conout and /dev/conin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
23:34 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> > So the aliasing set of bitset<5> is 88 and the store for
> > b.D.57473.D.57333._M_w
> > is done in aliasing set 10. Someone has t
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-07-25 23:00
---
More info for everyone.
Under Cygwin, reading and writing from/to /dev/conin$ and /dev/conout$
respectively works fine with gfortran now. (Thanks David Korn for info)
I think this is sufficient for Cygwin.
Und
--- Comment #4 from sje at cup dot hp dot com 2007-07-25 22:56 ---
The test case is still not working for me on IA64 HP-UX. I also still see
gfortran.dg/c_kind_params.f90 failing at all optimization levels.
c_char_tests.f03 also fails
--
sje at cup dot hp dot com changed:
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-25 22:40 ---
Subject: Re: New: [4.2/4.3 regression] compile time and memory regression
Points-to memory with these is almost nothing, so don't look at meef.
It looks like size goes up for each function and is not fully
recovere
Points-to memory with these is almost nothing, so don't look at meef.
It looks like size goes up for each function and is not fully
recovered by the time we start the next.
On 25 Jul 2007 22:25:22 -, debian-gcc at lists dot debian dot org
<[EMAIL PROTECTED]> wrote:
[forwarded from http://bug
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-07-25 22:38
---
Dominique,
Maybe you could try to delete the conditional defines that redefine isfinite so
that the native calls are used and see if the problem goes away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=328
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-07-25
22:28 ---
preprocessed sources at
http://people.debian.org/~doko/tmp/pr32900-sources.tar.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32900
[forwarded from http://bugs.debian.org/431608]
c++ source files generated with sip-qt take much longer (4.2) and much more
memory (4.3) to build, than building with 4.1:
4.1 200707180m58.881s about 400mb
4.2.1 release 86m13.933s about 400mb
4.3 20070720 14m51.718s about 1.5gb
built on
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32899
Mainline produces a bad diagnostic for the following code snippet:
===
subroutine FOO
logical I
I = I .eq. I
end subroutine
===
ePR22503.f:3.13:
I = I .eq. I
--- Comment #4 from boz283 at ece dot northwestern dot edu 2007-07-25
22:15 ---
How can i check to see if the pthreads library is being linked correctly or
find out if the problem is caused by TLS?
Thanks
Berkin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32896
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-25 22:09 ---
One should think, this code whould pick it up?!
/* Reject namelist arrays that are not constant shape. */
for (nl = sym->namelist; nl; nl = nl->next)
{
if (is_non_constant_shape_array (nl->sym))
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
22:07 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> So the aliasing set of bitset<5> is 88 and the store for
> b.D.57473.D.57333._M_w
> is done in aliasing set 10. Someone has to debu
The following invalid code snippet is accepted since GCC 4.2.0:
=
namespace N { }
int N::i;
=
--
Summary: [4.2/4.3 regression] Definition of variable N::i outside
namespace N not rejected
Product: gcc
Version:
--- Comment #15 from pcarlini at suse dot de 2007-07-25 21:56 ---
By the way, s390x-linux apparently is also affected...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-07-25 21:58
---
;; b.D.57473.D.57333._M_w = 7
(insn 5 4 6
/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bitset:572 (set
(reg:SI 94)
(const_int 7 [0x7])) -1 (nil))
(insn 6 5 0
/home/dave/gnu/gcc-4.3/objdir/
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
21:53 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> Can you attach the dump of -fdump-rtl-expand-details ?
Attached.
Dave
--- Comment #14 from dave at hiauly1 dot hia dot nrc do
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-25 21:49
---
Can you attach the dump of -fdump-rtl-expand-details ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org
The following testcase:
---
volatile int g[32];
long long gll;
double gd;
#define MULTI(X) \
X( 1), X( 2), X( 3), X( 4), X( 5), X( 6), X( 7), X( 8), X( 9), X(10), \
X(11), X(12), X(13), X(14), X(15), X(16), X(
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-07-25 21:36
---
So we have:
(insn 6 5 7 2
/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bitset:572 (set
(mem/s/c:SI (plus:SI (reg/f:SI 3 %r3)
(const_int 8 [0x8])) [10 b.D.57473.D.57333._M_w+0 S4 A64
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-25 21:32 ---
Or TLS not working with your version of glibc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32896
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-25 21:31 ---
This is most likely a glibc issue rather than a GCC one. What is going on is
the pthreads library is not being linked in correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
21:31 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
The appears to be a problem with the sched passes. If I compile with
-fno-schedule-insns and -fno-schedule-insns2, the test doesn't fau
--- Comment #1 from boz283 at ece dot northwestern dot edu 2007-07-25
21:28 ---
Created an attachment (id=13976)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13976&action=view)
Intermediate file for the program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32896
I have been able to compile and run the application correctly with -fopenmp
flag, but when I also add -static flag I can compile the application. However
while running it i get a segmentation fault error.
I have used gdb to see where the program crashes, and it seems to be somewhere
in openmp hea
--- Comment #4 from tjk at tksoft dot com 2007-07-25 21:24 ---
I got the same problem using sed 3.02 to build. Upgrading to sed 4.1.5
fixed the problem.
The fixincl program runs sed scripts for glibc pthread checks which fail on sed
3.02, but succeed on sed 4.1.5.
What happens is that
void test(void)
{
struct
{
int a, b, c, d, e, f;
} x;
x.d = 5;
asm volatile("in r28, 0x2F" : : : "r28");
x.d = 6;
}
$ avr-gcc.exe -v
Using built-in specs.
Target: avr
Configured with: ../gcc-4.1.1/configure
--prefix=/c/WinAVR --target=avr
--enable-languages=c,c++ -
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-25 20:45 ---
> Andrew, makes sense to you?
I think my patch only checks PREFERRED_STACK_BOUNDARY and not STACK_BOUNDARY
which is why it does not work but I have not looked into it at all.
--
pinskia at gcc dot gnu dot org cha
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-25 20:43 ---
thanks a lot for checking both patches!
> With this patch zlib appears to compile successfully. The loop is
> vectorized with an "alignment of access forced using peeling" note and linked
> apps no longer segfault.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |target
http:
There's no code to attach, as this failure is simply for a gcc-4.2.1 build,
using binutils-2.17 and initiated with gcc-3.3.6; to be specific:
CC=gcc336 CFLAGS="-O2 -g -mpa-risc-2-0" /usr/local/src/gcc-4.2.1/configure \
--host=hppa64-hp-hpux11.11 --with-local-prefix=/usr/local/64bit \
--with-mpfr=/u
--- Comment #22 from dirtyepic at gentoo dot org 2007-07-25 20:24 ---
(In reply to comment #17)
> Lets open a separate PR for this one
This is now PR 32893.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
--- Comment #8 from sje at gcc dot gnu dot org 2007-07-25 20:24 ---
Subject: Bug 32218
Author: sje
Date: Wed Jul 25 20:24:15 2007
New Revision: 126931
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126931
Log:
PR target/32218
* tree-vect-patterns.c (vect_pattern_
(In reply to comment #17)
> This looks like an unrelated problem - the vectorizer does not perform loop
> peeling here so it's not an issue of natural alignment. Lets open a separate
> PR
> for this one, unless there's already one open. In the meantime, would you
> please try this patch?:
>
> Ind
--- Comment #6 from andreast at gcc dot gnu dot org 2007-07-25 20:11
---
Fine with me, thanks and sorry for the delay. Pls ci.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
--- Comment #4 from greened at obbligato dot org 2007-07-25 19:47 ---
It is also broken on trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
--- Comment #3 from steven at gcc dot gnu dot org 2007-07-25 19:44 ---
This may be fixed now by my cfglayout work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18146
--- Comment #7 from steven at gcc dot gnu dot org 2007-07-25 19:43 ---
This may actually have been fixed by my cfglayout work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-25 19:01 ---
Fixed on the trunk by the dataflow merge.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-25 18:58 ---
This is now fixed with the new DSE on the trunk which came in with the dataflow
merge (which was really a rewrite of flow.c :) )
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from danglin at gcc dot gnu dot org 2007-07-25 18:56
---
Fixed by dataflow merge on hppa.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from danglin at gcc dot gnu dot org 2007-07-25 18:49
---
Subject: Bug 31500
Author: danglin
Date: Wed Jul 25 18:49:13 2007
New Revision: 126924
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126924
Log:
PR rtl-optimization/31500
* gcc.dg/Warray-b
--- Comment #18 from zadeck at naturalbridge dot com 2007-07-25 18:41
---
i am testing a patch.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
A
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-25 18:09 ---
> I think that, by extension, components with private components must be illegal
> too.
Which means checking over several levels. For the following program, g95 gives
an error. (NAG f95, ifort don't.)
> I'll have a
--- Comment #2 from eweddington at cso dot atmel dot com 2007-07-25 17:57
---
The AVR test results for a 4.2.1 prerelease still shows failure on -O0 only:
http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00335.html
However the results for a 4.3 snapshot shows failure on all -O settings
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-25 17:57 ---
Paul, thanks for the tip.
I'll have a look.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last r
--- Comment #3 from eweddington at cso dot atmel dot com 2007-07-25 17:42
---
Confirmed for 4.2.1 on mingw host.
test.cpp: In function 'T* rom(const T&) [with T = uint8_t]':
test.cpp:21: instantiated from here
test.cpp:10: internal compiler error: Segmentation fault
--
eweddingto
--- Comment #2 from eweddington at cso dot atmel dot com 2007-07-25 17:29
---
Confirmed on 4.2.1.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-25 17:15 ---
> This fixes the PR but is not regtested:
Patch looks OK and regtests on x86-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
--- Comment #5 from eweddington at cso dot atmel dot com 2007-07-25 17:05
---
Patch to document AVR progmem attribute:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01832.html
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-25 16:56 ---
I should be committing a fix for this issue soon.
*** This bug has been marked as a duplicate of 32527 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-07-25 16:56 ---
*** Bug 32892 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
--- Comment #7 from sje at cup dot hp dot com 2007-07-25 16:52 ---
Carolyn has checked in a patch to var-tracking.c and I can bootstrap IA64 Linux
so I am going to close this out as fixed. The patch that fixed this was:
2007-07-18 Caroline Tice <[EMAIL PROTECTED]>
* var-trac
--- Comment #2 from sje at cup dot hp dot com 2007-07-25 16:49 ---
Yes, that patch (now in the main line) seems to have fixed the problem. The
failures have gone away so I will close this defect.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #7 from sje at cup dot hp dot com 2007-07-25 16:20 ---
Well, that was silly. I couldn't reproduce the problem because I had a patch
in my local tree. Here is the patch I created, I will submit it to
gcc-patches.
Basically, get_vectype_for_scalar_type can return a NULL_TREE
Executing on host:
/home/dave/gcc-4.3/objdir/gcc/testsuite/gfortran/../../gfortr
an -B/home/dave/gcc-4.3/objdir/gcc/testsuite/gfortran/../../ -w "-O" -c -o
/home/dave/gcc-4.3/objdir/gcc/testsuite/gfortran/pr32417.o
/home/dave/gcc-4.3/gc
c/gcc/testsuite/gfortran.fortran-torture/compile/pr32417.
--- Comment #11 from pbrook at gcc dot gnu dot org 2007-07-25 15:47 ---
Should be fixed now.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #36 from danglin at gcc dot gnu dot org 2007-07-25 15:36
---
Fixed on hppa by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from danglin at gcc dot gnu dot org 2007-07-25 15:32
---
Subject: Bug 31836
Author: danglin
Date: Wed Jul 25 15:32:33 2007
New Revision: 126914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126914
Log:
PR libstdc++/31836
* config/locale/generic/
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-25 15:30 ---
This fixes the PR but is not regtested:
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(révision 126835)
--- gcc/fortran/trans-expr.
--- Comment #5 from vda dot linux at googlemail dot com 2007-07-25 15:22
---
Forgot to mention:
* generator tests signed and unsigned divisions and modulus, both const / x and
x / const, and also tests u = a / b; v = a % b; construct.
* you need to filter gen_test output to weed out d
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-25 15:17
---
Created an attachment (id=13975)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13975&action=view)
Test program generator
Test program was generated using gen_test.c
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from vda dot linux at googlemail dot com 2007-07-25 15:09
---
Created an attachment (id=13974)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13974&action=view)
Auto-generated test program with 15000 constant divs/mods
Test program, bzipped.
Build with
gcc -fomit-f
--- Comment #2 from vda dot linux at googlemail dot com 2007-07-25 15:05
---
Created an attachment (id=13973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13973&action=view)
Fix: adjust div cost for -Os on i386
Patch was tested with 4.2.1, I guess it will apply to other version
--- Comment #7 from pcarlini at suse dot de 2007-07-25 14:46 ---
Cannot be reproduced anymore.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-25 13:48 ---
With -fstrict-aliasing we claim the conversion is neccessary because the
pointed
to alias sets of the two pointers are different. For -fno-strict-aliasing the
frontend later says via the langhook that the two struct
--- Comment #3 from jbuehler at spirentcom dot com 2007-07-25 13:28 ---
I would appreciate a fix for this because the code being compiled is the GHC
compiler itself. I have to compile GHC for hppa without optimization because I
have been unable to find a compiler options workaround for
--- Comment #2 from jbuehler at spirentcom dot com 2007-07-25 13:22 ---
The same bug is present in the following versions of gcc for
sparc-sun-solaris2.9:
2.95.3
2.95
3.0.2
3.0.4
3.1.1
3.2.3
3.3.6
3.4.6
4.0.1
4.0.4
4.1.2
4.2.0
Use registers l1, l2, l3, l4 in the sample code to demonstr
--- Comment #1 from jbuehler at spirentcom dot com 2007-07-25 13:09 ---
This bug is also present in 4.0.1 for powerpc-ibm-aix5.2.0.0. Change the
registers in the problematic code to r14, r15, r16, r17 -- one of the registers
is not set by the optimized routine, but is by the non-optimiz
--- Comment #6 from dir at lanl dot gov 2007-07-25 12:56 ---
I did the build with "--with-ecj-jar=/Users/dir/gfortran/gcc/ecj.jar" and there
is no visible ecj anywhere on my machine. ecj1 is in
./java/libexec/gcc/powerpc-apple-darwin8.10.0/4.3.0/. With "ecj1 -help", ecj1
sits using nearl
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-25 12:50 ---
break build2_stat if code == INIT_EXPR && !useless_type_conversion_p
(arg0->common.type, arg1->common.type)
and you reach the offending tree build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-25 11:46 ---
Created an attachment (id=13972)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13972&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
In 4.2 with -O2 we use 1.5GB compiling the testcase while with 4.1 we only
needed
360MB. Using -fno-tree-pre fixes the memory regression.
Some recent 4.3 ICEs for me on the testcase (you need -O2 -fpermissive) with
/usr/include/boost/regex/v4/basic_regex_creator.hpp:515: internal compiler
error:
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-25 11:39 ---
Reminder: If implemented, change the PACK library function to print out the
size of LHS/RHS array (cf. PR 30814 & PR 32890).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
This is a follow up to PR 30814 (which implemented a run-time check).
The following test case should rise a compile-time error:
NAG f95:
Error: a.f90, line 3: Different vector lengths (19 and 30)
ifort:
Error: a.f90, line 3: The shapes of the array expressions do not
conform. [NEIGHBRS]
sun
--- Comment #21 from dorit at gcc dot gnu dot org 2007-07-25 11:11 ---
> Of course after my patch for PR 16660, the patch here should be
> changed to just return true always.
In this case, Ryan, could you please also try to see if Andrew's patch
(http://gcc.gnu.org/ml/gcc-patches/2007-0
--- Comment #4 from cnstar9988 at gmail dot com 2007-07-25 09:13 ---
I download GCC from ftp.gnu.org, 4.2.1 release.
gcc -O3 -Wall test.c
can gernerate warning on gcc-4.2.1 on x86
but no warning on gcc-4.2.1/x64. even -m32 or -m64.
I only think the behavior on both platform is the sam
--- Comment #20 from pinskia at gmail dot com 2007-07-25 09:12 ---
Subject: Re: wrong alignment or incorrect address computation in vectorized
code on Pentium 4 SSE
On 25 Jul 2007 08:40:09 -, dorit at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote
> In the meantime, would you please
On 25 Jul 2007 08:40:09 -, dorit at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote
In the meantime, would you please try this patch?:
Of course after my patch for PR 16660, the patch here should be
changed to just return true always.
Thanks,
Andrew Pinski
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-25 09:09 ---
(In reply to comment #2)
> why gcc show warnings on x86.
I am saying this does not warn in a normal FSF GCC release. So what warning do
you expect? A warning for a zero sized memset? Well the FSF GCC does not war
--- Comment #19 from dorit at gcc dot gnu dot org 2007-07-25 08:52 ---
problem fixed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
1 - 100 of 108 matches
Mail list logo
