--- Comment #45 from pinskia at gcc dot gnu dot org 2007-01-06 06:41
---
(In reply to comment #44)
> gfortran -c -O3 -ftree-vectorize -ffast-math -march=opteron -fopenmp
> mc_coordinates.f90
> mc_coordinates.f90: In function check_for_overlap:
> mc_coordinates.f90:192: internal compil
--- Comment #44 from jv244 at cam dot ac dot uk 2007-01-06 06:30 ---
Current gcc ICEs again on CP2K:
gfortran -c -O3 -ftree-vectorize -ffast-math -march=opteron -fopenmp
mc_coordinates.f90
mc_coordinates.f90: In function check_for_overlap:
mc_coordinates.f90:192: internal compiler e
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-06 05:28 ---
*** Bug 30390 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-06 05:28 ---
Sun's compiler is incorrect.
*** This bug has been marked as a duplicate of 24629 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-01-06 05:26
---
Typo on my part:
They are:
-O3
-O2
-O1
-O0
In that order. I apologize
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30388
--- Comment #8 from chat95 at mac dot com 2007-01-06 05:08 ---
Using -O3 -ffast-math in both cases:
Using -O3 -ffast-math in both cases:
Using -O1 -ffast-math in both cases:
Using -O1 -ffast-math in both cases:
what's the difference between theset two?
--
http://gcc.gnu.org/bug
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-01-06 05:05
---
According to gprof, not unexpected, 97% of time is in the jacoobi routine.
This might warrant further study by the optimizer experts. Certainly not by
me. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-06 04:44
---
With my system: x86-64 Linux
Using -O3 -ffast-math in both cases:
g77: MFLOPS: 893.198364
gfortran: MFLOPS: 895.7278
Using -O3 -ffast-math in both cases:
g77: MFLOPS: 930.39801
gfortran:
class R{};
class B{
friend class R;// ok.
};
template class A{
friend class T; // error???
};
when using g++(3.3.3 or 4.1) to compile above code, it reports:
error: using template type parameter 'T' after 'class'
error: friend declaration does not name a class or function
Pls note
--- Comment #5 from brooks at gcc dot gnu dot org 2007-01-06 02:36 ---
Created an attachment (id=12863)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12863&action=view)
Original source file (extracted from archive)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30388
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-01-06 02:13
---
Could you please post a gzipped version of the test case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30388
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-06 02:11
---
I can see where one could interpret the word 'result' to mean an action as
opposed to a value returned. In that sense, its not an error to return an
error.
Still I think it would be best to do the natural thing
According to the Fortran 95 standard, the result of ACHAR(I) for I not in the
range of 0 to 127 is "processor-dependent". This implies that it _has_ a
result, and thus that it is legal code. However, consider the following
result:
-
--- Comment #5 from lmillward at gcc dot gnu dot org 2007-01-06 01:09
---
Fixed in 4.3.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #4 from lmillward at gcc dot gnu dot org 2007-01-06 01:06
---
Subject: Bug 19439
Author: lmillward
Date: Sat Jan 6 01:06:04 2007
New Revision: 120520
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120520
Log:
PR c++/19439
* class.c (add_method): Don't
--- Comment #3 from chat95 at mac dot com 2007-01-06 00:38 ---
% gfortran42 -o himenobmtxp_m.gfortran42 -O2 -ffast-math -finline-functions
-fomit-frame-pointer -funroll-loops -fexpensive-optimizations himenobmtxp_m.f
% ./himenobmtxp_m.gfortran42
mimax= 257 mjmax= 129
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-06 00:33 ---
What happens if you use -O2 instead of -O ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30388
--- Comment #1 from chat95 at mac dot com 2007-01-06 00:32 ---
My CPU is :
Jan 6 06:59:54 debussy kernel: ACPI APIC Table:
Jan 6 06:59:54 debussy kernel: Timecounter "i8254" frequency 1193182 Hz
quality 0
Jan 6 06:59:54 debussy kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz
(2400.10
1. download http://accc.riken.jp/HPC/HimenoBMT/Load_module/himenoBMTxp_m.lzh
% wget http://accc.riken.jp/HPC/HimenoBMT/Load_module/himenoBMTxp_m.lzh
2. extract with lha
% lha x himenoBMTxp_m.lzh
himenobmtxp_m.f - Melted : o
3. apply following patch:
--- himenobmtxp_m.f~Mon Jan 7 13:54:48 2
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-06 00:26 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-06 00:26 ---
Subject: Bug 30385
Author: pinskia
Date: Sat Jan 6 00:26:24 2007
New Revision: 120519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120519
Log:
2007-01-05 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-01-06 00:14
---
Subject: Bug 30162
Author: jvdelisle
Date: Sat Jan 6 00:14:38 2007
New Revision: 120512
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120512
Log:
2007-01-05 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-05 23:57 ---
The only problem with spu-elf right now with respect of fortran compiler is
that the spu compiler says it supports TI mode but libgcc does not fully
support TI mode, this will get fixed but later.
--
http://gcc.
--- Comment #17 from patchapp at dberlin dot org 2007-01-05 23:40 ---
Subject: Bug number PR7651
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-01/msg00440.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-01-05 22:48 ---
Fixed for 4.1.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-05 22:47 ---
Subject: Bug 30212
Author: rguenth
Date: Fri Jan 5 22:47:47 2007
New Revision: 120507
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120507
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #4 from Michael dot McElroy at schange dot com 2007-01-05
22:10 ---
Get the same error doing a X86 to X86_64 cross compile building gcc 4.1 and
glibc 2.3.6 (crosstool 0.43). If I downgrade to gcc 3.4.5 and glibc 2.3.2, get
the sam segmentation fault on a different file in th
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-05 22:08 ---
static std::auto_ptr throw_exception(GError* gobject)
__attribute__((__noreturn__));
This is not a GCC bug because the function is marked as noreturn.
--
pinskia at gcc dot gnu dot org changed:
Wh
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-05 22:06 ---
Are you sure that _ZN4Glib5Error15throw_exceptionEP7_GError
(Glib::Error::throw_exception(_GError*) ) does not always throw an exception
and is marked as noreturn? If that is the case then this is not a bug.
--
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-05 21:57 ---
Subject: Bug 19978
Author: manu
Date: Fri Jan 5 21:57:01 2007
New Revision: 120505
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120505
Log:
2007-01-05 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c/
--- Comment #2 from matt dot hoosier at gmail dot com 2007-01-05 21:54
---
Test case is posted at http://www.cis.ksu.edu/~matt/pub/gcc_bug_30387.ii (~2
MB).
Apologies for the large post, but the code generation bug wasn't triggered when
all the imported types were stubbed out.
--
--- Comment #1 from matt dot hoosier at gmail dot com 2007-01-05 21:47
---
The GCC version in question here is the stock g++ shipped with Ubuntu edgy, but
the bug has been observed on other (3.4.4 and 4.1.1) builds too.
The test program (see attachment) is compiled with:
g++ -Wall -
When compiling the following conditional:
if (gerror)
{
printf ("%s%d: Error %s\n", __FILE__, __LINE__, gerror->message);
std::auto_ptr e (Glib::Error::throw_exception (gerror));
printf ("If reached, code generation worked.\n");
}
else
{
printf ("%s:%d: No error\n
--- Comment #13 from patchapp at dberlin dot org 2007-01-05 21:25 ---
Subject: Bug number PR29649
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-01/msg00431.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from gdr at integrable-solutions dot net 2007-01-05 21:11
---
Subject: Re: wrong result
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| > anther, consider an example definite[2] of 'offsetof', if you think
| > that is undefined, it's almost impossible to
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-01-05 21:10
---
Fixed on the 4.1 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from gdr at integrable-solutions dot net 2007-01-05 21:09
---
Subject: Re: [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant
folding
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
[...]
| That is most explict thing about overflow and groupp
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-01-05 21:09
---
Subject: Bug 27826
Author: rguenth
Date: Fri Jan 5 21:08:47 2007
New Revision: 120499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120499
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #8 from gdr at integrable-solutions dot net 2007-01-05 21:06
---
Subject: Re: [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant
folding
"jakub at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Do the parenthesis matter in C?
Yes, see paragraphes 11 dowwa
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-01-05 21:04
---
Subject: Bug 27826
Author: rguenth
Date: Fri Jan 5 21:04:23 2007
New Revision: 120498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120498
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-05 20:59
---
Subject: Bug 27826
Author: rguenth
Date: Fri Jan 5 20:59:15 2007
New Revision: 120497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120497
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
Every test that includes stdbool.h starting failing as of bootstraps on the
trunk this morning. Note the following find for stdbool.h:
yesterday:
dev-zero:{root}# find ../gcc_20070104 -name stdbool.h
../gcc_20070104/gcc/include/stdbool.h
../gcc_20070104/stage1-gcc/include/stdbool.h
../gcc_2007010
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-05 20:32 ---
>From C99, 5.1.2.3/14:
14 EXAMPLE 6 To illustrate the grouping behavior of expressions, in the
following fragment
int a, b;
/* ... */
a = a + 32760 + b + 5;
the expression statement behaves exactly the same as
a = ((
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-05 20:14 ---
Not a GCC bug but an aspell bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-05 20:13 ---
> anther, consider an example definite[2] of 'offsetof', if you think
> that is undefined, it's almost impossible to give a definite of
> offsetof.
> #define offsetof(TYPE,MEMBER) ((size_t)&((TYPE*)0)->MEMBER)
Th
--- Comment #3 from fang at csl dot cornell dot edu 2007-01-05 20:11
---
I've checked out the latest aspell-0.60.5 and found the same thing using a 4.2
prerelease with -O3. This is not gcc's problem, as this can (and should) be
easily fixed in their source with an additional explicit t
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-05 19:58 ---
(In reply to comment #5)
> Do the parenthesis matter in C? They do matter in say Fortran, but in C I
> think
> (a - 20) + (b - 20) can be evaluated as (a + b) + (-20 + -20) or a - 20 - 20 +
> b
> etc.
In fact, a-20
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-01-05 19:45
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-05 19:44
---
Subject: Bug 27369
Author: rguenth
Date: Fri Jan 5 19:44:10 2007
New Revision: 120495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120495
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-05 19:44 ---
Subject: Bug 25795
Author: rguenth
Date: Fri Jan 5 19:44:10 2007
New Revision: 120495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120495
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
Ba
--- Comment #5 from jakub at gcc dot gnu dot org 2007-01-05 19:06 ---
Do the parenthesis matter in C? They do matter in say Fortran, but in C I
think
(a - 20) + (b - 20) can be evaluated as (a + b) + (-20 + -20) or a - 20 - 20 +
b
etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2007-01-05 19:03
---
> I know Richard's busy (he's getting ready to submit a big batch of
> changes), so if you feel like trying the backport you might want to give
> it a go. Otherwise, I'm sure Richard will get to it in the relati
--- Comment #6 from gkvoykov at yahoo dot com 2007-01-05 18:53 ---
With GCC 4.1.0, using 'djgpp' binaries under Windows XP, the problem 'bug
10277' is absent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10277
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-05 18:39 ---
SPU has vectorizable conversion also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from mark at codesourcery dot com 2007-01-05 18:37 ---
Subject: Re: [4.0/4.1 regression] internal consistency
failure
ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-01-05 18:33
> ---
>> Do you mean positiv
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-01-05 18:33
---
> Do you mean positive cascading effects, in that bugs go away, or
> negative, in that new bugs show up?
Positive cascading effects if the set of patch is backported to the branch.
> Do you think that backporti
--- Comment #4 from stuart at apple dot com 2007-01-05 18:30 ---
I ran the testcase through ICC, and it unrolled the loops without vectorizing
them. However, making the loops indefinite gets us the desired, vectorized
result. Here is the modified, indefinite loop version of the testcas
--- Comment #3 from stuart at apple dot com 2007-01-05 18:27 ---
Created an attachment (id=12862)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12862&action=view)
vectorized assembly output from ICC v9.1
Generated from the "indefinite loop" variant of the testcase on OS X 10.4.7,
--- Comment #17 from mark at codesourcery dot com 2007-01-05 18:13 ---
Subject: Re: [4.0/4.1 regression] internal consistency
failure
ebotcazou at gcc dot gnu dot org wrote:
> Thanks Mark. It seems that a whole new class of internal consistency failures
> due to the mishandling of R
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2007-01-05 18:10
---
> Eric asked me to weigh in here. My only concern about a backport is Comment
> #9, which suggests that the patch didn't work. I'm assuming that since we're
> all talking about backporting it, that comment was
--- Comment #4 from joseph at codesourcery dot com 2007-01-05 17:52 ---
Subject: Re: Build failure in libgcc2 powitf2 with ICE in
gen_reg_rtx
On Fri, 5 Jan 2007, rask at sygehus dot dk wrote:
> The option -specs=ldblspecs is added by gcc/config/rs6000/t-ppccomm when
> compiling libgc
--- Comment #15 from mmitchel at gcc dot gnu dot org 2007-01-05 17:39
---
Eric asked me to weigh in here. My only concern about a backport is Comment
#9, which suggests that the patch didn't work. I'm assuming that since we're
all talking about backporting it, that comment was mistake
--- Comment #3 from rask at sygehus dot dk 2007-01-05 17:29 ---
Created an attachment (id=12861)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12861&action=view)
patch in testing to fix typo
The option -specs=ldblspecs is added by gcc/config/rs6000/t-ppccomm when
compiling libgcc2
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-05 17:08 ---
Mine for now as I am going to apply the testcase:
static void g(int t)
{
int a;
while (a < f())
;
}
void h(int t)
{
g(t);
}
-
Which was fixed by:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00359.html
--- Comment #9 from jakub at gcc dot gnu dot org 2007-01-05 16:54 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jakub at gcc dot gnu dot org 2007-01-05 16:53 ---
Subject: Bug 30382
Author: jakub
Date: Fri Jan 5 16:53:27 2007
New Revision: 120490
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120490
Log:
PR c++/30382
Backported from mainline:
20
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-05 16:51 ---
(In reply to comment #4)
> I guess we could try to provide a graceful degradation for such systems... The
> use of dup() can probably be avoided if dup() isn't available, without too
> much
> degradation in the libr
--- Comment #2 from hartmann at physik dot uni-kl dot de 2007-01-05 16:42
---
ok.
the trick with the "include" which provides additional 7 chars confused me. but
the issue remains: I'm not able to produce an position independent gcc for
mingw without hacking cppdefaults.c. The reason fo
#x27;s
trunk on i386-darwin. The command-line generating this error is:
/tmp/gfortran-20070105/ibin/./prev-gcc/xgcc
-B/tmp/gfortran-20070105/ibin/./prev-gcc/
-B/usr/local/gfortran/i386-apple-darwin8.8.1/bin/ -c -DHAVE_CONFIG_H -O2 -g
-fomit-frame-pointer -I. -I../../gcc/libiberty/../include -W
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-01-05 16:30 ---
It seems to be IVOPTs rewriting introduces the trees. Testcase:
extern void op( int, int);
void foo(int f0, int f1, int e0, int e1)
{
for (int i1 = f1; i1 <= e1; ++i1)
for (int i0 = f0; i0 <= e0; ++i0)
--- Comment #5 from jakub at gcc dot gnu dot org 2007-01-05 16:16 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #7 from jakub at gcc dot gnu dot org 2007-01-05 15:55 ---
Subject: Bug 25993
Author: jakub
Date: Fri Jan 5 15:55:45 2007
New Revision: 120489
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120489
Log:
Backported from mainline
2006-09-17 Steven Bossc
--- Comment #4 from jakub at gcc dot gnu dot org 2007-01-05 15:53 ---
Subject: Bug 30360
Author: jakub
Date: Fri Jan 5 15:53:31 2007
New Revision: 120488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120488
Log:
PR c/30360
* libgcc2.c (__divdc3): Compare c and
--- Comment #3 from jakub at gcc dot gnu dot org 2007-01-05 15:50 ---
Subject: Bug 30360
Author: jakub
Date: Fri Jan 5 15:50:25 2007
New Revision: 120487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120487
Log:
PR c/30360
* libgcc2.c (__divdc3): Compare c and
--- Comment #2 from jakub at gcc dot gnu dot org 2007-01-05 15:49 ---
Subject: Bug 30360
Author: jakub
Date: Fri Jan 5 15:49:05 2007
New Revision: 120486
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120486
Log:
PR c/30360
* libgcc2.c (__divdc3): Compare c and
--- Comment #1 from dcb314 at hotmail dot com 2007-01-05 15:31 ---
Created an attachment (id=12860)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12860&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30383
I just tried to compile package libhugetlbfs-1.0.1-200612221420
with the GNU C compiler version 4.2 snapshot 20061230
The compiler said
/usr/include/bits/string3.h: In function 'jumpfunc':
/usr/include/bits/string3.h:51: internal compiler error: in ix86_expand_movmem,
at config/i386/i386.c:13608
--- Comment #7 from jakub at gcc dot gnu dot org 2007-01-05 14:56 ---
Created an attachment (id=12859)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12859&action=view)
gcc41-pr30382.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30382
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-05 14:45 ---
Subject: Bug 27998
Author: pault
Date: Fri Jan 5 14:45:20 2007
New Revision: 120485
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120485
Log:
2007-01-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #9 from pault at gcc dot gnu dot org 2007-01-05 14:45 ---
Subject: Bug 23232
Author: pault
Date: Fri Jan 5 14:45:20 2007
New Revision: 120485
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120485
Log:
2007-01-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-05 14:45 ---
Subject: Bug 27996
Author: pault
Date: Fri Jan 5 14:45:20 2007
New Revision: 120485
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120485
Log:
2007-01-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-01-05 14:30
---
Mine (patch posted).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--- Comment #6 from jakub at gcc dot gnu dot org 2007-01-05 14:18 ---
http://gcc.gnu.org/viewcvs?view=rev&revision=115086
Hope it is enough to put in just the 4 lines...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30382
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-01-05 14:15
---
Is this still a bug, with the new patches for optimizing calls to memcpy?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-05 14:12
---
ping: Would you have either an example where this limit is encountered?
Wouldn't 4.3 be ideal for that work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-01-05 14:06
---
This bug has been open for more that one year without any update, without
general agreement on wether we have a bug or a testcase exhibiting incorrect or
suboptimal behaviour.
Closing.
--
fxcoudert at gcc do
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-01-05 14:03
---
(In reply to comment #11)
> A draft patch was posted (quite a while ago) by FX:
> http://gcc.gnu.org/ml/fortran/2006-11/msg00634.html
I'd add that it's easy to separate the coredump part of the patch (handling o
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-05 14:02
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-01-05 14:00
---
Subject: Bug 28116
Author: rguenth
Date: Fri Jan 5 14:00:46 2007
New Revision: 120482
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120482
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-05 13:59
---
Various cygwin testresults posted to the gcc-testresults mailing-list show no
failure of these tests. Closing accordingly.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-05 13:57
---
Subject: Bug 28116
Author: rguenth
Date: Fri Jan 5 13:56:54 2007
New Revision: 120481
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120481
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-01-05 13:53
---
Subject: Bug 28116
Author: rguenth
Date: Fri Jan 5 13:53:45 2007
New Revision: 120480
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120480
Log:
2007-01-05 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-01-05 13:47
---
> Sorry, I have mistakenly bootstrapped this with the default checking
> (i.e. --enable-checking=release).
Richard's log is actually --enable-checking=release. With tree checking
=== g++ tests =
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-01-05 13:46
---
So the proposed patch (for all branches) is:
Index: tree.c
===
*** tree.c (revision 120477)
--- tree.c (working copy)
*** get_n
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-05 13:45
---
And we get that because for the COMPONENT_REF
D.1741.typeD.1734
we have
unit size
align 16 symtab 0 alias set -1 precision 16 min max >
arg 0
arg 1 unit size
align 3
--- Comment #4 from jakub at gcc dot gnu dot org 2007-01-05 13:44 ---
Sorry, I have mistakenly bootstrapped this with the default checking
(i.e. --enable-checking=release).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-01-05 13:17
---
> === g++ tests ===
>
>
> Running target unix
> FAIL: g++.dg/parse/enum3.C (test for errors, line 3)
> FAIL: g++.dg/parse/enum3.C (test for excess errors)
> FAIL: g++.old-deja/g++.bugs/900405_01
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-01-05 13:06
---
But of course at least after SRA we miss a NOP_EXPR on the initialization:
intD.2 SR.40D.1798;
short intD.12 SR.39D.1797;
short intD.12 test$typeD.1796;
short intD.12 D.1745;
short intD.12 D.1744;
SR.
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-05 13:01
---
Reconfirmed. The problem still exists.
#1 0x0844d296 in copy_to_mode_reg (mode=SImode, x=0xb7c8b1a0)
at /home/richard/src/gcc-4_1-branch/gcc/explow.c:577
577 gcc_assert (GET_MODE (x) == mode || GET_MOD
1 - 100 of 113 matches
Mail list logo
