Daniel Jacobowitz [EMAIL PROTECTED] writes:
| On Sun, Nov 20, 2005 at 05:02:11AM +0100, Gabriel Dos Reis wrote:
| svk depotmap --list shows:
|
| Depot Path
|
| //
It looks kike that patch contains a typo
The entry for nonmemory_operand has an extra bogus false
The following patch more than likely fixes the fallout I've just kicked of
a x86_64 bootstrap to find out
Index: gensupport.c
===
On Sat, 19 Nov 2005, Steve Kargl wrote:
On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
I believe if the file is in a cvs repository and the copy
in your local tree was not obtained via a checkout, cvs
will replace the local file with whatever is in the repository.
No, it'll
Graham Stott wrote:
It looks kike that patch contains a typo
The entry for nonmemory_operand has an extra bogus false
I'm sorry. The patch has been in my powerpc-apple-darwin8.2.0 tree for
months but rs6000 does not use nonmemory_operand. Thanks for fixing it.
Paolo
Hans-Peter Nilsson [EMAIL PROTECTED] writes:
On Sat, 19 Nov 2005, Steve Kargl wrote:
On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
I believe if the file is in a cvs repository and the copy
in your local tree was not obtained via a checkout, cvs
will replace the local file with
On Sun, 20 Nov 2005, Andreas Schwab wrote:
Hans-Peter Nilsson [EMAIL PROTECTED] writes:
On Sat, 19 Nov 2005, Steve Kargl wrote:
On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
I believe if the file is in a cvs repository and the copy
in your local tree was not obtained via a
Hans-Peter Nilsson [EMAIL PROTECTED] writes:
I've never seen this, always the collision message, so I guess
it's version-dependent.
It appears to work only with a local repository.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409
On Thursday 17 November 2005 23:35, Jim Wilson wrote:
I've checked in a patch to fix the comment typo.
Thanks,
What do you thing about adding an assert? Something similar to the attached
patch.
Rafael
Index: gcc/function.c
===
Hi,
I am working on some optimizations on the CFG. Can someone please give
me some info on the following -
1. For an gimple expression node, how do we determine the return type?
2. How do we create a temporary variable, and add it to the list of
variables defined in the current function
Hello Everyone,
I am interested in knowing more about the vectorizer in GCC. Does
anyone have or know of any statistics about the percentage of loops
that can be vectorized in some benchmarks like MediaBench, SPEC2K and
so forth?
Thanking You,
Yours Sincerely,
Balaji V. Iyer.
1
# of expected failures 97
# of untested testcases 28
# of unsupported tests 234
/werkstatt/georg/build/gcc/xgcc version 4.2.0 20051120 (experimental)
...
.../src/gcc/gcc/testsuite/ada/acats/run_acats: line 11:
type: gnatmake: not found
# svn up
svn: Checksum mismatch for 'gcc/.svn/text-base/ChangeLog.svn-base';
expected: 'ce91f24c15d533874dc494b8fc6b0fde', actual:
'dfd84c36479cfdcd0b6576ecab266817'
U gcc/DATESTAMP
U gcc/tree-gimple.c
U gcc/tree-gimple.h
Thanks for some help.
signature.asc
Description: OpenPGP digital
Hi,
I have a question about having multiple insns for one operation. Take
m68k port for example. It has many SImode move insns like so:
(define_insn pushexthisi_const
[(set (match_operand:SI 0 push_operand =m)
(match_operand:SI 1 const_int_operand J))]
(define_insn
[(set
Hi Everyone,
int
main ()
{
int *p;
int i;
p = (int *) malloc (400 * sizeof (int));
for (i = 0; i 512; i++)
{
p[i] = i;
printf (p[%d]: %d\n, i, p[i]);
}
return 0;
}
The following code should terminate with Segmentation fault, right ?
But when I
Hi Everyone,
int
main ()
{
int *p;
int i;
p = (int *) malloc (400 * sizeof (int));
for (i = 0; i 512; i++)
{
p[i] = i;
printf (p[%d]: %d\n, i, p[i]);
}
return 0;
}
The following code should terminate with Segmentation fault,
Second you are invoking undefined behavior by accessing passed the array
bounds (or allocated
bounds by malloc).
I didnt get your point. I am allocating space only for 400 inregers
then as soon as in the loop if it crosses the value of 400 , it should
have given a segementation
On 11/20/05, Andrew Pinski [EMAIL PROTECTED] wrote:
Second you are invoking undefined behavior by accessing passed the array
bounds (or allocated
bounds by malloc).
I didnt get your point. I am allocating space only for 400 inregers
then as soon as in the loop if it crosses the
On 11/20/05, Andrew Pinski [EMAIL PROTECTED] wrote:
Hi Everyone,
int
main ()
{
int *p;
int i;
p = (int *) malloc (400 * sizeof (int));
for (i = 0; i 512; i++)
{
p[i] = i;
printf (p[%d]: %d\n, i, p[i]);
}
return 0;
Since this is a Subversion problem, and not a GCC problem, it would
probably be best to ask this question on [EMAIL PROTECTED]
(I don't know the answer; I don't see anything in the FAQ or in the
book. So I think this is an excellent question to ask.)
Running make check stops in the Ada ACATS part,
where it doesn't find the newly created binaries
after a successful make bootstrap. (And after turning
the computer off, going to sleep, turning it on and
*not* again adding the different GNAT installation to
PATH that was used for
Running the testsuite I get the following ICE on the 4.1 branch:
Executing on host: /abuild/aj/gcc/gcc/xgcc -B/abuild/aj/gcc/gcc/
/aj-cvs/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20051113-1
.c -w -O0 -fno-show-column -lm -m64 -o
Running the testsuite, I see the following ICE:
Executing on host: /abuild/aj/gcc/gcc/xgcc -B/abuild/aj/gcc/gcc/
/aj-cvs/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vect/pr22506.c
-O2 -ftr
ee-vectorize -maltivec -ftree-vectorizer-verbose=4 -fdump-tree-vect-stats
-fno-show-column -S
Hi all,
int
main ()
{
int *p;
int i;
p = (int *) malloc (400 * sizeof (int));
for (i = 0; i 512; i++)
{
p[i] = i;
printf (p[%d]: %d\n, i, p[i]);
}
return 0;
}
The following code should terminate with Segmentation fault, right ?
But when I tried, it works even beyond the limits of
Running the GCC testsuite I see the following ICE:
Executing on host: /abuild/aj/gcc/gcc/xgcc -B/abuild/aj/gcc/gcc/
/aj-cvs/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vmx/3c-01a.c -O1
-malt
ivec -mabi=altivec -std=gnu99 -fno-show-column -S -m64 -o 3c-01a.s(timeout
= 300)
Running the GCC testsuite I see the following ICE:
Executing on host: /abuild/aj/gcc/gcc/xgcc -B/abuild/aj/gcc/gcc/
/aj-cvs/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vmx/gcc-bug-b.c
-O1 -m
altivec -mabi=altivec -std=gnu99 -fno-show-column -S -m64 -o gcc-bug-b.s
(timeout = 300)
Running the GCC testsuite I get the following ICE:
Executing on host: /abuild/aj/gcc/gcc/xgcc -B/abuild/aj/gcc/gcc/
/aj-cvs/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.target/powerpc/altivec-const
s.c -maltivec -mabi=altivec -O2 -fno-show-column -lm -m64 -o
./altivec-consts.exe
Running the GCC treelang testsuite, I see the following ICE:
Executing on host: /abuild/aj/gcc/gcc/xgcc -B/abuild/aj/gcc/gcc/
/aj-cvs/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/treelang/compile/badreturn.tree
-S -m64 -o badreturn.s(timeout = 300)
--- Comment #33 from schwab at gcc dot gnu dot org 2005-11-20 10:43 ---
Subject: Bug 24757
Author: schwab
Date: Sun Nov 20 10:43:43 2005
New Revision: 107246
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107246
Log:
PR target/24757
* config/ia64/ia64.c
--- Comment #34 from schwab at gcc dot gnu dot org 2005-11-20 10:44 ---
Subject: Bug 24757
Author: schwab
Date: Sun Nov 20 10:44:27 2005
New Revision: 107247
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107247
Log:
PR target/24757
* config/ia64/ia64.c
--- Comment #35 from schwab at suse dot de 2005-11-20 10:45 ---
Fixed.
--
schwab at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
#include stdint.h
#include stdio.h
void test (int c)
{
uint8_t a[4] = {0, 1, 2, 3};
uint_least32_t b;
b = (uint_least32_t) 0xff00;
b |= (uint_least32_t) a[3];
b = (uint_least32_t) 0x00ff;
b |= (uint_least32_t) (a[2] 8);
b = (uint_least32_t) 0xff00;
b
--- Comment #11 from martin at mpa-garching dot mpg dot de 2005-11-20
12:10 ---
(In reply to comment #4)
I reran the test with the current gfortran. This is what I get:
~/tmpgfortran -Wunused -W -v -c -O2 bla.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
--- Comment #9 from ayers at gcc dot gnu dot org 2005-11-20 12:49 ---
Subject: Bug 19024
Author: ayers
Date: Sun Nov 20 12:49:41 2005
New Revision: 107251
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107251
Log:
2005-11-20 David Ayers [EMAIL PROTECTED]
PR
gfortran scan() intrinsic yields incorrect results, see code snippet below
[EMAIL PROTECTED]:~/src/F90/bugs cat scanbug.f90
program scanbug
character(len=10) :: numset='0123456789'
print *, scan('0123456789', '9')
print *, scan(numset, '9')
end program scanbug
[EMAIL
--- Comment #6 from rep dot nop at aon dot at 2005-11-20 13:26 ---
Created an attachment (id=10300)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10300action=view)
Add newline to replacement fixup for string.h
I wouldn't generally add a newline in the replace command but adjust
--- Comment #1 from falk at debian dot org 2005-11-20 13:33 ---
There is no correct output when you use a variable uninitialized. It's
undefined behavior. Printing any number, or crashing, would be completely
valid behaviors as far as gcc is concerned.
--
falk at debian dot org
--- Comment #2 from pcarlini at suse dot de 2005-11-20 13:37 ---
(In reply to comment #1)
There is no correct output when you use a variable uninitialized. It's
undefined behavior. Printing any number, or crashing, would be completely
valid behaviors as far as gcc is concerned.
--- Comment #3 from s_a_white at email dot com 2005-11-20 14:15 ---
Sorry the summary may not be 100% correct, but it is related to the variable
never being directly assigned.
I do understand that using (i.e. assigning from an unintialised variable) will
give you random junk, etc.
--- Comment #4 from falk at debian dot org 2005-11-20 14:35 ---
I already explained this. Using an uninitialized variable invokes undefined
behavior. This means that producing random junk, executing random if
statements,
executing random if statements 17 times, formatting your hard
--- Comment #8 from jb at gcc dot gnu dot org 2005-11-20 14:46 ---
The above commit to trunk and 4.1 should fix this issue.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
ICE on invalid code, nullify member of unknown derived type.
$ cat invalid_nullify.F
program ice_on_invalid_nullify
implicit none
TYPE (nonexisting_type1), TARGET :: t1
nullify(t1%something)
end program
$ gfortran-4.1-HEAD invalid_nullify.F
In file
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-20 15:18 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-20 15:18 ---
Mark as a dup of bug 22266.
*** This bug has been marked as a duplicate of 22266 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-20 15:18 ---
*** Bug 24956 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rep dot nop at aon dot at 2005-11-20 15:40 ---
Known to work: 3.4.5 (g77)
Known to fail: 4.0.2 (gfortran)
--
rep dot nop at aon dot at changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-20 15:49 ---
Confirmed:
In file t.f:3
TYPE (nonexisting_type1), TARGET :: t1
1
Error: Derived type 'nonexisting_type1' at (1) is being used before it is
defined
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 15:51 ---
I think this is a dup of bug 24787 but I don't know for sure as I don't have a
build of gfortran after the patch was applied.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 15:59 ---
It start to fail before 2005.
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00501.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-20 16:00 ---
It passed on 20051107:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00305.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24954
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-20 16:07
---
If -Os works and the rest of the optimization levels work, then this is a
middle-end issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The testsuite program gcc.c-torture/execute/nestfunc-3.c crashes with a bus
error on i686-apple-darwin8. Tried it with gcc-3.4.4, gcc-4.0.2 and
gcc-4.1-20051112.
--
Summary: Trampolines fail on i686-apple-darwin
Product: gcc
Version: 4.1.0
Status:
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-20 16:25 ---
kargl[203] cat a.f90
program scanbug
character(len=10) :: numset='0123456789'
print *, scan('0123456789', '9')
print *, scan(numset, '9')
end program scanbug
kargl[204] gfc41 -o z a.f90
kargl[205] ./z
Version information:
[EMAIL PROTECTED] ~ $ g++ -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs
Configured with: /var/tmp/portage/gcc-3.3.6/work/gcc-3.3.6/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.6
--- Comment #2 from gcc at microbizz dot nl 2005-11-20 16:30 ---
Subject: Re: nonlocal goto's fail on i?86-darwin
Note that the test case doesn't fail for non-pic code (--no-pic
-read_only_relocs suppress). Tried that with gcc-3.4.4, gcc-4.0.2 and
gcc-4.1.0-20051112 on
I get the following error:
g++ bug.cc
bug.cc: In member function bool MyClassT::SomeMethod():
bug.cc:17: error: n was not declared in this scope
with this simple code:
#include stdio.h
templateclass T
class BaseClass {
protected:
int n;
};
templateclass T
class MyClass : public
There is no way to specify a constraint for an operand of an asm statement that
may only be a destination operand (ie. the first operand of the st insn). If
you try to use the m constraint together with the %P operand modifier you can
get invalid asm code when %P expands to a register instead of
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 17:14 ---
Please read http://gcc.gnu.org/gcc-3.4/changes.html
.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
FAIL: gcc.target/ia64/20030811-1.c (test for excess errors)
has appeared on mainline for ia64-hp-hpux11.23 -milp32, with the move of that
test from gcc.dg which also enabled it for HP-UX (previously only enabled for
ia64-linux). Messages are all of form
--- Comment #7 from bauhaus at futureapps dot de 2005-11-20 17:56 ---
PR 23400
* inclhack.def: Add newline to the replace text for string.h.
* fixincl.x: Regenerate.
Similarly, removing \n from last line of the string.h
in the fixincludes source directory
FAIL: gcc.dg/vect/vect-62.c scan-tree-dump-times not vectorized: redundant
loop. no profit to vectorize. 1
appeared on mainline on i686-pc-linux-gnu and ia64-hp-hpux11.23 (both -milp32
and -mlp64) between 20051118 (revision 107161) and 20051119 (revision 107213).
This test previously PASSed in
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-20 18:14 ---
I am retesting the patch and will apply after a bootstrap/test is finished.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rth at gcc dot gnu dot org 2005-11-20 19:04 ---
Subject: Bug 24665
Author: rth
Date: Sun Nov 20 19:03:53 2005
New Revision: 107259
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107259
Log:
PR tree-opt/24665
* tree-gimple.c (is_gimple_id):
--- Comment #8 from rth at gcc dot gnu dot org 2005-11-20 19:05 ---
Subject: Bug 24665
Author: rth
Date: Sun Nov 20 19:05:43 2005
New Revision: 107260
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107260
Log:
PR tree-opt/24665
* tree-gimple.c (is_gimple_id):
--- Comment #9 from rth at gcc dot gnu dot org 2005-11-20 19:06 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from nathan at gcc dot gnu dot org 2005-11-20 19:18 ---
I'll have a look tomorrow
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from nathan at gcc dot gnu dot org 2005-11-20 19:29 ---
I've come to the conclusion that my 21166 patch was overzealous. What I now
think is that packing a decl always changes its type except for one case
described below. Even when the field's placment happens to work
--- Comment #6 from rth at gcc dot gnu dot org 2005-11-20 19:32 ---
Patch is approved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
source code:
double precision d
integer i
d=0.
i=0
write(0,*) i
write(0,*) d
end
Platrofrm: Powerpc G5 running darwin 10.4.3.
Runtime error: Illegal instuction after writing the integer.
Compilation command:
/usr/local/usr/bin/gfortran-4.0 -v
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #7 from rep dot nop at aon dot at 2005-11-20 20:13 ---
updated patch:
http://gcc.gnu.org/ml/fortran/2005-11/msg00551.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21302
Hi,
I have attached a cpp file that (I believe) should compile (and does on
Borland c++). It is the copy at the end that causes a problem - the
while loop is simply doing the same as what the copy should do (just to
show I did the operator properly). Copy works for other cases (ints,
floats,
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #1 from gcc at microbizz dot nl 2005-11-20 21:17 ---
Subject: Trampolines fail on i686-apple-darwin
Note the gcc.c-torture/execute/nestfunc-5.c fails also (with a bus
error).
Adriaan van Os
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
--- Comment #8 from jb at gcc dot gnu dot org 2005-11-20 21:39 ---
rth committed a fix to trunk and 4.1:
http://gcc.gnu.org/ml/fortran/2005-11/msg00548.html
It should now work again on all supported platforms.
Unless new problems are reported I'll close this in a few days.
--
--- Comment #2 from phython at gcc dot gnu dot org 2005-11-20 22:18 ---
This testcase fails when we don't have optabs for REDUC trees.
--
phython at gcc dot gnu dot org changed:
What|Removed |Added
I use
$ ~/gcc/bin/gcc --version
gcc (GCC) 4.2.0 20051119 (experimental)
on the routine
double precision function abssqr (a)
implicit none
double precision, intent(in) :: a
abssqr = abs(a) ** 2
end function abssqr
with
$ ~/gcc/bin/gfortran -Wall -O3 -ffast-math -S abssqr.f90
which
ÐÏࡱ
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 00:40 ---
This comes down to the tree-combiner.
Take the following C functions:
double fabs(double);
double f(double a)
{
return fabs(a)*fabs(a);
}
double f1(double *a)
{
return fabs(*a)*fabs(*a);
}
double f2(double *a)
--- Comment #3 from rth at gcc dot gnu dot org 2005-11-21 00:51 ---
Subject: Bug 24931
Author: rth
Date: Mon Nov 21 00:51:39 2005
New Revision: 107271
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107271
Log:
PR 24931
* tree-sra.c (struct sra_elt): Add
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 00:52 ---
Confirmed, I saw this too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rth at gcc dot gnu dot org 2005-11-21 00:56 ---
Subject: Bug 24931
Author: rth
Date: Mon Nov 21 00:55:57 2005
New Revision: 107272
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107272
Log:
PR 24931
* tree-sra.c (struct sra_elt): Add
The enclosed source file contains errors. The errors are detected, but are
attributed to the wrong source file. The relevant lines of the source files
are:
# 1
/Users/eschnett/Cvanilla/arrangements/AEIThorns/Exact/src/include/Scalar_CalcTmunu_temps.inc
c
c temporary variables for code in
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-21 00:58
---
Created an attachment (id=10302)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10302action=view)
Failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24965
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1, 4.2 Regression] m68k |[4.1/4.2 Regression] m68k
|build failure: ICE: in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24859
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|make[7]: rc: Command not|[4.1/4.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-21 01:36 ---
Do you have an example of where the params get in the way?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from pedro dot lamarao at mndfck dot org 2005-11-21 01:41
---
The following patch implements the suggested solution.
Is it correct?
I don't have access to any version of Solaris to check.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 01:42 ---
Fails:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00998.html
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00840.html
Hmm, this has failed since the testcase was added, I have to manually check if
it is a
--- Comment #30 from pedro dot lamarao at mndfck dot org 2005-11-21 01:42
---
Created an attachment (id=10303)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10303action=view)
Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8
--
I use
$ ~/gcc/bin/gfortran --version
GNU Fortran 95 (GCC) 4.2.0 20051119 (experimental)
and receive for the attached source file, after several warnings, the error
/Users/eschnett/Cvanilla/arrangements/AEIDevelopment/Weyl/src/w_extract_multipoles.F90:370:
internal compiler error: Bus error
I
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-21 01:52
---
Created an attachment (id=10304)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10304action=view)
Failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24966
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-21 01:53 ---
Confirmed, does not look like a regression though you can never tell.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from schnetter at aei dot mpg dot de 2005-11-21 01:53
---
I forgot to mention my command line arguments:
/Users/eschnett/gcc/bin/gfortran -mlongcall -ftrapv -fwrapv -g3 -Wall -Wshadow
-Wsurprising -c -o $current_wd/w_extract_multipoles.F90.o
--- Comment #3 from schnetter at aei dot mpg dot de 2005-11-21 01:54
---
Created an attachment (id=10305)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10305action=view)
Complete screen output, i.e., all warnings before the error
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 02:02 ---
The bug in combine.c has been there since 1.1 of the file but I don't know if
this is a latent bug which was just exposed or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24952
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 02:05 ---
Confirmed, only with treelang code this can happen.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dje at gcc dot gnu dot org 2005-11-21 02:08 ---
This one is nonsense. We do not have a language type for Treelang. So what?
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at gcc dot gnu dot org 2005-11-21 02:09 ---
(In reply to comment #5)
I've made a small amount of headway on this.
Labels L22 and L21 were (when created) the addresses of objects in the code.
However, they are deleted (presumably as unreachable), but the
--- Comment #1 from dje at gcc dot gnu dot org 2005-11-21 02:09 ---
We just need to check that we have enough elts in the VEC.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 140 matches
Mail list logo
