[Bug c++/24513] [gomp] Parsing problems with OpenMP directives inside member functions
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-10-25 06:09 --- Would it be possible to add gomp-branch or something similar to the reported against field in bugzilla? -- martin at mpa-garching dot mpg dot de changed: What|Removed |Added Keywords||openmp, rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24513
[Bug c++/24512] [gomp] Bogus error message about redeclared variables
-- 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 | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 07:06:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24512
[Bug fortran/21625] [4.0 only] Nested derived type pointer component not initialized on ALLOCATE
--- Comment #12 from cvs-commit at gcc dot gnu dot org 2005-10-25 08:04 --- Subject: Bug 21625 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-25 08:04:09 Modified files: gcc/fortran: ChangeLog trans-array.c trans-array.h trans-expr.c trans-intrinsic.c trans-types.c Log message: fortran/ 2005-10-25 Richard Henderson [EMAIL PROTECTED] PR fortran/21625 * trans-array.c (gfc_conv_descriptor_data_get): Rename from gfc_conv_descriptor_data. Cast the result to the DATAPTR type. (gfc_conv_descriptor_data_set, gfc_conv_descriptor_data_addr): New. (gfc_trans_allocate_array_storage): Use them. (gfc_array_allocate, gfc_array_deallocate): Likewise. (gfc_trans_dummy_array_bias, gfc_conv_expr_descriptor): Likewise. (gfc_trans_deferred_array): Likewise. * trans-expr.c (gfc_conv_function_call): Likewise. (gfc_trans_subcomponent_assign): Likewise. (gfc_trans_pointer_assignment): Likewise. * trans-intrinsic.c (gfc_conv_allocated): Likewise. * trans-types.c (gfc_array_descriptor_base): New. (gfc_get_element_type): Use GFC_TYPE_ARRAY_DATAPTR_TYPE. (gfc_get_array_descriptor_base): Break out from ... (gfc_get_array_type_bounds): ... here. Create type variants. * trans-array.h (gfc_conv_descriptor_data_get): Declare. (gfc_conv_descriptor_data_set, gfc_conv_descriptor_data_addr): Declare. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.140r2=1.335.2.141 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.39.2.8r2=1.39.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.7.18.2r2=1.7.18.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.38.2.10r2=1.38.2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-intrinsic.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.43.10.6r2=1.43.10.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.37.10.8r2=1.37.10.9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21625
[Bug fortran/21625] [4.0 only] Nested derived type pointer component not initialized on ALLOCATE
--- Comment #13 from eedelman at gcc dot gnu dot org 2005-10-25 08:07 --- With Richard Henderson's patch, things should now work on 4.0 too. Thus, I declare this bug fixed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21625
[Bug c/24514] New: ICE on bootstrap
bootstrapping gives ICE in c-parser.o for gcc-4.1-20051022 stage1/xgcc -Bstage1/ -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmiss ing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/raid/tecosi m/it/devel/projects/develtools/src/gcc-4.1-20051022/gcc -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051022/gcc/. -I/raid/tecosim/it/devel/projects/develtool s/src/gcc-4.1-20051022/gcc/../include -I./../intl -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051022/gcc/../libcpp/include -I/appl/shared/gnu/IRIX64/mips-sg i-irix6.5/include -I/appl/shared/gnu/IRIX64/mips-sgi-irix6.5/include /raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051022/gcc/c-parser.c -o c-parser.o xgcc: Internal error: Trace/BPT/RangeErr/DivZero/Ovflow trap (program cc1) configured with the following configure parameters: configure --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install --with-gnu-as --with-as=/SCRATCH/gcc- build/IRIX64/mips-sgi-irix6.5/install/bin/as --with-gnu-ld --with-ld=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld --disable-shared --enable-threads=posix --en able-languages=c,ada,c++,fortran,objc,obj-c++ --with-gmp=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 --with-mpfr=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 using binutils 2.16.1 bootstrapping compiler gcc 4.0.2 -- Summary: ICE on bootstrap Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: r dot emrich at de dot tecosim dot com GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2005-10-25 09:26 --- OK, confirmed with a pristine tree on i686. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-10-24 21:05:07 |2005-10-25 09:26:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug c++/24513] [gomp] Parsing problems with OpenMP directives inside member functions
--- Comment #2 from jakub at gcc dot gnu dot org 2005-10-25 09:31 --- openmp keyword is enough. -- 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 | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||10/msg01477.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-10-25 09:31:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24513
[Bug c++/24515] New: internal compiler error: in write_builtin_type, at cp/mangle.c:1784
command:
gcc -g -Wall vector_bug.cc -lstdc++
results in error message:
vector_bug.cc:5: internal compiler error:
in write_builtin_type, at cp/mangle.c:1784
Please submit a full bug report,
with preprocessed source if appropriate.
preprocessed source:
// /usr/libexec/gcc/x86_64-redhat-linux/4.0.1/cc1plus -quiet -D_GNU_SOURCE
vector_bug.cc -quiet -dumpbase vector_bug.cc -mtune=k8 -auxbase vector_bug -g
-Wall -o - -frandom-seed=0
# 1 vector_bug.cc
# 1 /home/ka/q/sse//
# 1 built-in
# 1 command line
# 1 vector_bug.cc
typedef float v4sf __attribute__ ((vector_size (16)));
typedef float v4sf_m_a __attribute__ ((may_alias, vector_size (16)));
class V4sf
{
v4sf _v;
public:
V4sf() {}
void set4(v4sf_m_a f) {
_v = f;
asm (shufps %2,%0,%1 : =x (_v) : x (_v), n (0));
}
};
float x = 1.0001;
int main(int argc, char *argv[])
{
V4sf X;
X.set4(x);
return 0;
}
--
Summary: internal compiler error: in write_builtin_type, at
cp/mangle.c:1784
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: annabellesgarden at yahoo dot de
GCC build triplet: gcc -g -Wall vector_bug.cc -lstdc++
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24515
[Bug c++/24515] internal compiler error: in write_builtin_type, at cp/mangle.c:1784
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-25 10:31 --- Fixed in 4.0.2 (at least). ./cc1plus -quiet -o /dev/null -Wall /tmp/t.C /tmp/t.C: In function int main(int, char**): /tmp/t.C:22: error: no matching function for call to V4sf::set4(float) /tmp/t.C:9: note: candidates are: void V4sf::set4(float __vector__) verified on both x86_64 and i686. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|gcc -g -Wall vector_bug.cc | |-lstdc++| Known to work||4.0.2 Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24515
[Bug c++/24513] [gomp] Parsing problems with OpenMP directives inside member functions
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-10-25 11:26
---
This patch appears to work very well, thanks!
However, later in my code I run into a problem of the following sort:
The (patched) compiler rejects the following code
void bar (int *p)
{
#pragma omp parallel for
for (int m=0; m1000; ++m)
{
switch(p[m])
{
case 1:
p[m]=2;
break;
}
}
}
~/tmpg++ -fopenmp -c test.cc
test.cc: In function 'void bar(int*)':
test.cc:10: error: break statement used with OpenMP for loop
Is this really ill-formed code? It is accepted by all other compilers I tested.
I can open another bug report for this, but I'd like to make sure first that
this is not a consequence of the proposed patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24513
[Bug c++/24513] [gomp] Parsing problems with OpenMP directives inside member functions
--- Comment #4 from jakub at gcc dot gnu dot org 2005-10-25 11:34 --- That's unrelated. Please file a different bug (and make sure it has openmp keyword). Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24513
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #21 from hidden_peak at mail dot ru 2005-10-25 11:46 --- May be is not gcc bug, but ld: the sample work with GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux, work with warnings with GNU ld version 2.15.94.0.2.2 20041220 (SuSE Linux) and don't work with ld 2.16.x (all with gcc 3.4.4). -- hidden_peak at mail dot ru changed: What|Removed |Added CC||hidden_peak at mail dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/24516] New: [openmp] Incorrect error for break statement in OpenMP loop
The current gomp branch (including Jakub Jelinek's proposed patch for
PR24513, rejects the following code:
void bar (int *p)
{
#pragma omp parallel for
for (int m=0; m1000; ++m)
{
switch(p[m])
{
case 1:
p[m]=2;
break;
}
}
}
~/tmpg++ -fopenmp -v -c test.cc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/gompcc/configure --quiet --prefix=/scratch/ugccgomp
--enable-languages=c++,f95 --with-gmp=/afs/mpa/data/martin/mygmp
--disable-checking
Thread model: posix
gcc version 4.1.0-gomp-20050608-branch 20051023 (experimental) (merged
20051023)
/scratch/ugccgomp/libexec/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/cc1plus
-quiet -v -D_GNU_SOURCE test.cc -quiet -dumpbase test.cc -mtune=pentiumpro
-auxbase test -version -fopenmp -o /tmp/ccxFI9tu.s
ignoring nonexistent directory
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-gomp-20050608-branch
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-gomp-20050608-branch/i686-pc-linux-gnu
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-gomp-20050608-branch/backward
/usr/local/include
/scratch/ugccgomp/include
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/include
/usr/include
End of search list.
GNU C++ version 4.1.0-gomp-20050608-branch 20051023 (experimental) (merged
20051023) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0-gomp-20050608-branch 20051023
(experimental) (merged 20051023).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f20b28a8e8738447b8a8d4419521a6c9
test.cc: In function 'void bar(int*)':
test.cc:10: error: break statement used with OpenMP for loop
--
Summary: [openmp] Incorrect error for break statement in OpenMP
loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24516
[Bug c/24517] New: casting problem
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
#include stdio.h
unsigned char mem[] = 1234567890;
unsigned char *memptr= mem;
unsigned char cc;
unsigned long donothing(unsigned long a, short c)
{ return(a);
}
int main(void)
{
*memptr++ = (unsigned char)donothing(*memptr, 0);
if ('1'==mem[0]) puts(Good compiler);
else puts(Bad compiler);
// now the same via cc
mem[0] = '1';
memptr = mem;
cc = (unsigned char)donothing(*memptr, 0);
*memptr++ = cc;
if ('1'==mem[0]) puts(Good compiler);
else puts(Bad compiler);
}
--
Summary: casting problem
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Wojciech dot Skaba at teleadreson dot com dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24517
[Bug c/24517] casting problem
--- Comment #1 from falk at debian dot org 2005-10-25 12:40 --- (In reply to comment #0) *memptr++ = (unsigned char)donothing(*memptr, 0); This expression modifies memptr after accessing it for something other than determining the new value without an intervening sequence point. The behavior is thus undefined (C99 6.5/2). With -Wall, you even get a warning about this. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24517
[Bug fortran/24518] New: Intrinsic MOD incorrect for large arg1/arg2 and slow.
This: real*8 :: x = 10.0e9 do i = 10, 22 x = 10d0 * x print '(a,i2,a,g14.8)', mod (10**,i,, 1.7_8) = ,mod (x, 1.7_8) end do end does this with cvs gfortran mod (10**10, 1.7_8) = 1.326 mod (10**11, 1.7_8) = 1.1000261 mod (10**12, 1.7_8) = 0.80026150 mod (10**13, 1.7_8) = 1.2026138 mod (10**14, 1.7_8) = 0.12609863 mod (10**15, 1.7_8) = 1.2607422 mod (10**16, 1.7_8) = 5.8125000 mod (10**17, 1.7_8) = -50.687500 mod (10**18, 1.7_8) = 364.0 mod (10**19, 1.7_8) = -.7000E+20 mod (10**20, 1.7_8) = -.7000E+21 mod (10**21, 1.7_8) = -.7000E+22 mod (10**22, 1.7_8) = -.7000E+23 and this with a leading commercial brand: mod (10**10, 1.7_8) = 1.326 mod (10**11, 1.7_8) = 1.1000261 mod (10**12, 1.7_8) = 0.80026123 mod (10**13, 1.7_8) = 1.2026123 mod (10**14, 1.7_8) = 0.12612289 mod (10**15, 1.7_8) = 1.2612289 mod (10**16, 1.7_8) = 0.71228947 mod (10**17, 1.7_8) = 0.32289470 mod (10**18, 1.7_8) = 1.5289470 mod (10**19, 1.7_8) = 1.6894697 mod (10**20, 1.7_8) = 1.5946971 mod (10**21, 1.7_8) = 0.64697063 mod (10**22, 1.7_8) = 0.86970625 gfortran loses it at around 10**16 and starts producing values larger than the second argument. Whilst, to some degree, one deserves to be hit on the nose for trying to calculate mod for these values, a slightly less deviant behaviour might be better. As noted in the list http://gcc.gnu.org/ml/fortran/2005-10/msg00482.html, this leading brand is about twice as fast in calulating mod, as gfortran, in spite of its apparently using 64 bit arithmetic. -- Summary: Intrinsic MOD incorrect for large arg1/arg2 and slow. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot richard dot thomas at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug fortran/24519] New: gfortran slow because of incomplete dependency checking
This PR is concerned with gfortran's performance relative to commercial compilers in respect of Polyhedron's TEST_FPU.F90. Baseline(test_fpu.f90 out of the box): gfortran 20050903 -fmax-stack-var-size=100 -O2 Benchmark running, hopefully as only ACTIVE task Test1 - Gauss 2000 (101x101) inverts 34.6 sec Err= 0.002 Test2 - Crout 2000 (101x101) inverts 8.4 sec Err= 0.001 Test3 - Crout 2 (1001x1001) inverts 11.0 sec Err= 0.001 Test4 - Lapack 2 (1001x1001) inverts 8.1 sec Err= 0.273 total = 62.1 sec Digital DF6.0 using /fast Benchmark running, hopefully as only ACTIVE task Test1 - Gauss 2000 (101x101) inverts 5.1 sec Err= 0.003 Test2 - Crout 2000 (101x101) inverts 5.4 sec Err= 0.012 Test3 - Crout 2 (1001x1001) inverts 10.6 sec Err= 0.063 Test4 - Lapack 2 (1001x1001) inverts 7.5 sec Err= 0.297 total = 28.6 sec gfortran is doing OK but for Test1, where there is a factor of nearly 7 between them. The offending lines in the source are: lines 115-120 temp = b(:,k) DO j = 1, n c = b(k,j)*d b(:,j) = b(:,j)-temp*c b(k,j) = c END DO Repeating these nearly doubles the execution time of Test1. Modifying the code to: zb = b ! A copy of b.. temp = b(:,k) DO j = 1, n c = b(k,j)*d b(:,j) = zb(:,j)-temp*c ! ..to be used here. b(k,j) = c END DO Test1 - Gauss 2000 (101x101) inverts 12.0 sec Err= 0.003 Test2 - Crout 2000 (101x101) inverts 8.4 sec Err= 0.001 Test3 - Crout 2 (1001x1001) inverts 11.0 sec Err= 0.001 Test4 - Lapack 2 (1001x1001) inverts 8.3 sec Err= 0.273 total = 39.7 sec which gains us nearly a factor of three and looks much more respectable. The reason is evident from dumping the code. This bit of code is converted into (loosely): temp = b(:,k) DO j = 1, n c = b(k,j)*d allocate (atmp6(size(b,1))) atmp6(:) = b(:,j)-temp*c b(:,j) = atmp6(:) deallocate(atmp6) b(k,j) = c END DO If I reproduce this with an already allocated temporary, the time for Test1 drops to 11.6s. It seems to me that it is the repeated calls to _gfc_internal_malloc and _gfc_internal_free that are responsible for 23s of execution time in the original version of the test. This is confirmed by making this previous explicitly so, whereupon the execution time for Test1 goes up to 35.7s. Finally, the best performance of all is obtained if the vector expression is made F77-like temp = b(:,k) DO j = 1, n c = b(k,j)*d do p = 1, n b(p,j) = b(p,j)-temp(p)*c end do b(k,j) = c END DO whereupon gfortran turns in a very healthy 6.7s. My conclusion of all this is that there is some room for some optimization of the scalarizer (by having gfc_conv_resolve_dependencies recognise that this is an element by element replacement?). -- Summary: gfortran slow because of incomplete dependency checking Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot richard dot thomas at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24519
[Bug fortran/24520] New: Temporary constant array descriptors being declared at wrong binding level.
Posted in: http://gcc.gnu.org/ml/fortran/2005-10/msg00443.html
I have been investigating the relatively poor performance of gfortran for
some of the Polyhedron Benchmark Tests (www.polyhedron.com).
I already discussed a couple of days ago how test_fpu.f90 exposed some
weakness in the dependency analysis. I am developing a patch will do
somewhat more than the draft patch discussed there.
As posted on the Wiki (http://gcc.gnu.org/wiki/GFortranResults), two real
offenders are induct.f90 and kepler.f90 (I have confirmed this in an ifc/gfc
comparison that I will post tonight or tomorrow.). As mentioned there,
profiling indicates that the intrinsic dot_product is taking 50% of the
time. Subsequently I have confirmed this by the simple expedient of adding
a repeat copy of the section of code that calls dot_product. The difference
is of the same order as the difference between gfc and DF6.0 execution
times.
It turns out that gfc is slow because it is making temporary array
descriptors for the actual arguments of dot_product. Since these are only
of length 13, the temporary making slugs down gfc a lot. This can be
confirmed as follows:
real, dimension(12) :: x, y
real:: z
do i = 1, 1000
z = dot_product(x,y)
end do
end
takes 0.15s under DF6.0 and 45.5s for gfc!
When rewritten as
real, dimension(:), pointer :: x, y
real:: z
allocate (x(12), y(12))
do i = 1, 1000
z = dot_product (x,y)
end do
end
the time increases slightly for DF6.0, to 0.27s. gfc now comes in with a
creditable 0.39s.
The code within the loop for both versions appears below. Apparently the
allocation of the descriptor structures and the assignments to them cause
the enormous slow-down.
I think that the lesson is that constant array references need to be taken
out of loops or their use should automatically generate a pointer. I rather
like the latter because I suspect it to be more easily implementable.
Paul Thomas
Non_pointer version
if (i = 1000)
{
while (1)
{
{
logical4 D.573;
{
struct array1_real4 parm.1;
struct array1_real4 parm.0;
parm.0.dtype = 281;
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 12;
parm.0.dim[0].stride = 1;
parm.0.data = (void *) (real4[0:] *) x[0];
parm.0.offset = 0;
parm.1.dtype = 281;
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 12;
parm.1.dim[0].stride = 1;
parm.1.data = (void *) (real4[0:] *) y[0];
parm.1.offset = 0;
z = _gfortran_dot_product_r4 (parm.0, parm.1);
}
L.1:;
D.573 = i == 1000;
i = i + 1;
if (D.573) goto L.2; else (void) 0;
}
}
}
else
{
(void) 0;
}
L.2:;
and for the pointer version
if (i = 1000)
{
while (1)
{
{
logical4 D.573;
z = _gfortran_dot_product_r4 (x, y);
L.1:;
D.573 = i == 1000;
i = i + 1;
if (D.573) goto L.2; else (void) 0;
}
}
}
else
{
(void) 0;
}
L.2:;
--
Summary: Temporary constant array descriptors being declared at
wrong binding level.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paul dot richard dot thomas at cea dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24520
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Comment #11 from cvs-commit at gcc dot gnu dot org 2005-10-25 13:44 --- Subject: Bug 22290 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-25 13:44:46 Modified files: gcc/testsuite : ChangeLog gcc/fortran: ChangeLog trans-decl.c trans-stmt.c Added files: gcc/testsuite/gfortran.dg: assign_5.f90 assign_6.f Log message: 2005-10-25 Feng Wang [EMAIL PROTECTED] PR fortran/22290 * trans-decl.c (gfc_add_assign_aux_vars): New function. Add two auxiliary variables. (gfc_get_symbol_decl): Use it when a variable, including dummy argument, is assigned a label. (gfc_trans_assign_aux_var): New function. Set initial value of the auxiliary variable explicitly. (gfc_trans_deferred_vars): Use it. * trans-stmt.c (gfc_conv_label_variable): Handle dummy argument. 2005-10-25 Feng Wang [EMAIL PROTECTED] PR fortran/22290 * gfortran.dg/assign_5.f90: New test. * gfortran.dg/assign_6.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.488r2=1.5084.2.489 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_5.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_6.f.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.141r2=1.335.2.142 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.54.2.6r2=1.54.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.24.6.10r2=1.24.6.11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/24520] Temporary constant array descriptors being declared at wrong binding level.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24520
[Bug fortran/24519] gfortran slow because of incomplete dependency checking
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 13:47 --- Confirmed, I saw this while working on another bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-10-25 13:47:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24519
[Bug c/24521] New: internal compiler error (segmentation fault) when compiling xorg-x11 6.8.2
this is the output i get: including in doc/man/misc... making all in ./include... making all in include/bitmaps... making all in include/extensions... making all in include/fonts... making all in include/GL... making all in include/DPS... making all in ./config... making all in config/cf... making all in config/imake... making all in config/makedepend... making all in config/util... rman.c: In function 'main': rman.c:4894: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugs.gentoo.org/ for instructions. Preprocessed source stored into /var/tmp/portage/xorg-x11-6.8.2-r4/temp/cc5F7DsV.out file, please attach this to your bugreport. make[4]: *** [rman.o] Error 1 it should be noted, that this is a 32bit chroot from linux x86_64. gcc -v: Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.0.2-r1/work/gcc-4.0.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.0.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.0.2 (Gentoo 4.0.2-r1, pie-8.7.8) -- Summary: internal compiler error (segmentation fault) when compiling xorg-x11 6.8.2 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: blocker Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: redeeman at metanurb dot dk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24521
[Bug fortran/24519] gfortran slow because of incomplete dependency checking
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 13:55 --- Woops wrong button. One more testcase which looks like will show up in SPEC 2k5: temp = # c = # DO j = 1, n b(array) = b(array)-temp*c END DO We have a couple of temps here, two for array and then one for the assignment. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24519
[Bug c/24521] internal compiler error (segmentation fault) when compiling xorg-x11 6.8.2
--- Comment #1 from redeeman at metanurb dot dk 2005-10-25 13:56 --- Created an attachment (id=10054) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10054action=view) cc5F7DsV.out this is the output thing it talks about in the error message -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24521
[Bug middle-end/24521] internal compiler error (segmentation fault) when compiling xorg-x11 6.8.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 13:56 --- Did you read: See URL:http://bugs.gentoo.org/ for instructions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24521
[Bug middle-end/24521] internal compiler error (segmentation fault) when compiling xorg-x11 6.8.2
--- Comment #3 from redeeman at metanurb dot dk 2005-10-25 14:03 --- bugs.gentoo.org is just a bugzilla - but i figure this is not a gentoo problem. i guy told me to report it to gcc's bugzilla. so i did. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24521
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Comment #12 from cvs-commit at gcc dot gnu dot org 2005-10-25 14:06 --- Subject: Bug 22290 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-25 14:06:23 Modified files: gcc/testsuite : ChangeLog gcc/fortran: ChangeLog trans-decl.c trans-stmt.c Added files: gcc/testsuite/gfortran.dg: assign_5.f90 assign_6.f Log message: 2005-10-25 Feng Wang [EMAIL PROTECTED] PR fortran/22290 * trans-decl.c (gfc_add_assign_aux_vars): New function. Add two auxiliary variables. (gfc_get_symbol_decl): Use it when a variable, including dummy argument, is assigned a label. (gfc_trans_assign_aux_var): New function. Set initial value of the auxiliary variable explicitly. (gfc_trans_deferred_vars): Use it. * trans-stmt.c (gfc_conv_label_variable): Handle dummy argument. 2005-10-25 Feng Wang [EMAIL PROTECTED] PR fortran/22290 * gfortran.dg/assign_5.f90: New test. * gfortran.dg/assign_6.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6250r2=1.6251 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_5.f90.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_6.f.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.598r2=1.599 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gccr1=1.72r2=1.73 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gccr1=1.42r2=1.43 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Comment #13 from fengwang at gcc dot gnu dot org 2005-10-25 14:09 --- Fixed. -- fengwang at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug middle-end/24521] internal compiler error (segmentation fault) when compiling xorg-x11 6.8.2
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-25 14:16 --- This works for me, so it has to be a patch which gentoo adds. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24521
[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 14:37 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-10-25 14:37:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug fortran/24520] Temporary constant array descriptors being declared at wrong binding level.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 14:39 --- Confirmed (note IE sucks). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 14:39:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24520
[Bug middle-end/24521] internal compiler error (segmentation fault) when compiling xorg-x11 6.8.2
--- Comment #5 from redeeman at metanurb dot dk 2005-10-25 14:40 --- hmm ok.. do you think it could be because it is a 32bit chroot within a 64bit install? anyway, i will try a vanilla gcc 4.0.2, and get back to you later today or tomorow perhaps (more likely) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24521
[Bug fortran/18157] ice-on-valid code, pointer to user-defined type, fold-struct.c
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-25 14:59 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01489.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||10/msg01489.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18157
[Bug libfortran/24489] read_block wrong execution order
-- 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=24489
[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17574
[Bug c++/100] confusing name lookup diagnostic
-- 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=100
[Bug tree-optimization/23911] Failure to propagate constants from a const initializer for _Complex
-- 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=23911
[Bug libgcj/24147] [gcc 4.0 only] Deadlock in java.net.URLClassLoader
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24147
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug swing/17362] Scrollbars in JScrollPane appear only if the Container containing JScrollPane is revalidated
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |0.19 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17362
[Bug preprocessor/15067] [3.4/4.0 Regression] Minor glitch in the source of cpp.
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-25 15:05 --- Subject: Bug 15067 CVSROOT:/cvs/gcc Module name:gcc Branch: csl-arm-branch Changes by: [EMAIL PROTECTED] 2005-10-25 15:05:37 Modified files: gcc: ChangeLog ChangeLog.csl-arm cppinit.c Log message: 2005-10-25 Paul Brook [EMAIL PROTECTED] Backport form gcc-3_4-branch 2004-04-22 Per Bothner [EMAIL PROTECTED] * cppinit.c (cpp_read_main_file): Return NULL rather than false. Fixes PR preprocessor/15067. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=csl-arm-branchr1=2.1568.2.99r2=2.1568.2.100 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.csl-arm.diff?cvsroot=gcconly_with_tag=csl-arm-branchr1=1.1.2.150r2=1.1.2.151 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cppinit.c.diff?cvsroot=gcconly_with_tag=csl-arm-branchr1=1.296.4.4r2=1.296.4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15067
[Bug c++/24516] [gomp] Incorrect error for break statement in OpenMP loop
-- 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 | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 15:11:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24516
[Bug tree-optimization/24483] [4.1 Regression] ICE in ivopts
--- Comment #1 from steven at gcc dot gnu dot org 2005-10-25 15:30 ---
Backtrace:
Breakpoint 1, fancy_abort (file=0xb1cc18
../../mainline/gcc/tree-ssa-loop-ivopts.c,
line=2948, function=0xb1d0bb aff_combination_to_tree) at diagnostic.c:590
590 internal_error (in %s, at %s:%d, function, trim_filename (file),
line);
(gdb) up
#1 0x0056db37 in aff_combination_to_tree (comb=0x7fbfffec30)
at tree-ssa-loop-ivopts.c:2948
2948 gcc_assert (comb-n == MAX_AFF_ELTS || comb-rest == NULL_TREE);
(gdb) p *comb
$17 = {type = 0x2a9589e580, mask = 4294967295, offset = 0, n = 2, elts =
{0x2a95a8f680,
0x2a95a639a0, 0x2a95a6d8c0, 0x2a95a6d850, 0x2a95a6d850, 0x2a95a6d8c0,
0x2a95a6d930,
0x2a95a6d9a0}, coefs = {1, 1, 0, 0, 1, 1, 1, 1}, rest = 0x2a95a8f700}
(gdb) call debug_generic_expr (comb-elts[0])
(unsigned intD.3) -j9D.1618_41
(gdb) call debug_generic_expr (comb-elts[1])
ivtmp.30D.1722_4
(gdb) call debug_generic_expr (comb-elts[2])
j6D.1615_65
(gdb) call debug_generic_expr (comb-elts[3])
j5D.1614_64
(gdb) call debug_generic_expr (comb-elts[4])
j5D.1614_64
(gdb) call debug_generic_expr (comb-elts[5])
j6D.1615_65
(gdb) call debug_generic_expr (comb-elts[6])
j7D.1616_66
(gdb) call debug_generic_expr (comb-elts[7])
j8D.1617_67
(gdb) call debug_generic_expr (comb-rest)
(unsigned intD.3) j9D.1618_41
(gdb)
Why do we have (comb-n == 2) when we have 8 elts?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-10-25 15:30:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24483
[Bug middle-end/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2005-10-25 15:33
---
Jan,
Can you please check if -fno-tree-ter makes the bug go away? We've
chatted recently with Jakub concerning bug in argument saving in nested
call and -maccumulate-outgoing-args. I was under impression that we
should no longer produce the nested calls out of ter but aparently it is
still being done (that results in inferrior code quality too as we can't
generated nested calls very sanely)
Would that be an acceptable fix (not rematerializing nested calls)?
Also can you also, please, point me closer to place in .optimized dump
where the misscompilation happens?
L12:;
- temp.456 = d[3]{lb: 1 sz: 4};
- t1.427 = system__arith_64__Oconcat (temp.433, temp.456);
- temp.460 = d[4]{lb: 1 sz: 4};
- D.712 = system__arith_64__Orem (t1.427, zlo);
- D.713 = system__arith_64__lo (D.712);
- t2.450 = system__arith_64__Oconcat (D.713, temp.460);
- D.715 = system__arith_64__Odivide (t2.450, zlo);
- D.716 = system__arith_64__lo (D.715);
- D.717 = system__arith_64__Odivide (t1.427, zlo);
- D.718 = system__arith_64__lo (D.717);
- qu = system__arith_64__Oconcat (D.718, D.716);
+ t1.427 = system__arith_64__Oconcat (temp.433, d[3]{lb: 1 sz: 4});
+ t2.450 = system__arith_64__Oconcat (system__arith_64__lo
(system__arith_64__Orem (t1.427, zlo)), d[4]{lb: 1 sz: 4});
+ qu = system__arith_64__Oconcat (system__arith_64__lo
(system__arith_64__Odivide (t1.427, zlo)), system__arith_64__lo
(system__arith_64__Odivide (t2.450, zlo)));
ru = system__arith_64__Orem (t2.450, zlo);
goto bb 37 (L50);
-: -O1 -fno-tree-ter
+: -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #74 from mueller at kde dot org 2005-10-25 15:41 --- yes, well one reason for it is that several libs (e.g. libgcc2) already use push/pop visibility macros and it doesn't seem to harm. furthermore I manually added push/pop macros to libstdc++ headers on a debian system (which is broken regarding visibility support) and it made my testcase pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #75 from pcarlini at suse dot de 2005-10-25 15:44 --- (In reply to comment #74) furthermore I manually added push/pop macros to libstdc++ headers on a debian system (which is broken regarding visibility support) and it made my testcase pass. To be clear: I have nothing against adding those push/pop missing the middle-end fixes. But I want to be 100% sure that nothing breaks. Thus my plan: I will update the patch doing that for mainline and ask Roger (the most qualified person, apparently) before committing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug tree-optimization/24483] [4.1 Regression] ICE in ivopts
--- Comment #2 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2005-10-25 15:56 ---
Subject: Re: [4.1 Regression] ICE in ivopts
Hello,
Breakpoint 1, fancy_abort (file=0xb1cc18
../../mainline/gcc/tree-ssa-loop-ivopts.c,
line=2948, function=0xb1d0bb aff_combination_to_tree) at
diagnostic.c:590
590 internal_error (in %s, at %s:%d, function, trim_filename (file),
line);
(gdb) up
#1 0x0056db37 in aff_combination_to_tree (comb=0x7fbfffec30)
at tree-ssa-loop-ivopts.c:2948
2948 gcc_assert (comb-n == MAX_AFF_ELTS || comb-rest == NULL_TREE);
(gdb) p *comb
$17 = {type = 0x2a9589e580, mask = 4294967295, offset = 0, n = 2, elts =
{0x2a95a8f680,
0x2a95a639a0, 0x2a95a6d8c0, 0x2a95a6d850, 0x2a95a6d850, 0x2a95a6d8c0,
0x2a95a6d930,
0x2a95a6d9a0}, coefs = {1, 1, 0, 0, 1, 1, 1, 1}, rest = 0x2a95a8f700}
(gdb) call debug_generic_expr (comb-elts[0])
(unsigned intD.3) -j9D.1618_41
(gdb) call debug_generic_expr (comb-elts[1])
ivtmp.30D.1722_4
(gdb) call debug_generic_expr (comb-elts[2])
j6D.1615_65
(gdb) call debug_generic_expr (comb-elts[3])
j5D.1614_64
(gdb) call debug_generic_expr (comb-elts[4])
j5D.1614_64
(gdb) call debug_generic_expr (comb-elts[5])
j6D.1615_65
(gdb) call debug_generic_expr (comb-elts[6])
j7D.1616_66
(gdb) call debug_generic_expr (comb-elts[7])
j8D.1617_67
(gdb) call debug_generic_expr (comb-rest)
(unsigned intD.3) j9D.1618_41
(gdb)
Why do we have (comb-n == 2) when we have 8 elts?
that's not necessarily a bug, # of elements in the combination may get
changed due to arithmetical operations with it, and the old elements
are not zeroed. But once comb-n MAX_AFF_ELTS, comb-rest should be
moved to the available slot in elts, which apparently some function
fails to do. I will have a look.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24483
[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-25 16:24 --- Jakub, ping! Are you going to post your patch from comment #4?? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
[Bug c++/24522] New: htonl in optimized template function generates compiler warning
Overview Description: More detailed expansion of summary.
When compiling template functions in g++ 4.0.2 (Debian 4.0.2-2) (Debian
testing/unstable) with -O2 and -Wall, the compiler generates a warning about a
statement with no effect. This seems to be due to the inlining with __v; as a
statement, but the warning does not occur in non-template functions or with
other compiler versions tried (3.4).
Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the
bug. Include any special setup steps.
1) Create the following .cc file (as test.cc):
#include netinet/in.h
templatetypename S
void serialize(const uint32_t* pitem, const S item) {
uint32_t t2 = htonl(item);
}
2) Compile test.cc
$ g++ -O2 -Wall -c -o test.o test.cc
Actual Results: What the application did after performing the above steps.
g++ generated a warning that the htonl statement has no effect.
$ g++ -O2 -Wall -c -o test.o test.cc
test.cc: In function 'void serialize(const uint32_t*, const S)':
test.cc:5: warning: statement has no effect
Expected Results: What the application should have done, were the bug not
present.
test.o should have been created without warning
Build Date Platform: Date and platform of the build that you first
encountered the bug in.
Release: 4.0.2 (Debian 4.0.2-2) (Debian testing/unstable)
configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib
--libexecdir=/usr/lib--without-included-gettext --enable-threads=posix
--enable-nls --program-suffix=-4.0 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu--enable-libstdcxx-debug
--enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu
Environment:
System: Linux killian.ucsd.edu 2.6.12.20051019-ck1 #1 SMP Wed Oct 19 09:24:47
PDT 2005 i686 GNU/Linux
Architecture: i686
Additional Builds and Platforms: Whether or not the bug takes place on
other platforms (or browsers, if applicable).
- Also Occurs On
Unknown
- Doesn't Occur On
g++ version 3.4.4 20050721 (Red Hat 3.4.4-2)
Or without -O2, -Wall, or outside of a template function.
--
Summary: htonl in optimized template function generates compiler
warning
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ckillian at cs dot ucsd dot edu
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
[Bug c++/24522] htonl in optimized template function generates compiler warning
--- Comment #1 from ckillian at cs dot ucsd dot edu 2005-10-25 16:26 --- Created an attachment (id=10055) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10055action=view) The test.cc file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
[Bug c++/24522] htonl in optimized template function generates compiler warning
--- Comment #2 from ckillian at cs dot ucsd dot edu 2005-10-25 16:26 --- Created an attachment (id=10056) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10056action=view) preprocessor output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
[Bug c++/24522] htonl in optimized template function generates compiler warning
--- Comment #3 from ian at airs dot com 2005-10-25 16:36 ---
I believe this winds up being a duplicate of PR c++/8057, which is fixed on
mainline. With the test case in the PR, I see the warning with 4.0, but I do
not see the warning on mainline.
Note that this slightly modified test case:
#include netinet/in.h
templatetypename S
void serialize(const uint32_t* pitem, const S item) {
uint32_t t2 = htonl(item);
}
template void serializeint (const uint32_t*, const int);
issues a warning on both 4.0 and mainline:
foo.cc: In function void serialize(const uint32_t*, const S) [with S = int]:
foo.cc:8: instantiated from here
foo.cc:5: warning: unused variable t2
--
ian at airs dot com changed:
What|Removed |Added
CC||ian at airs dot com
Known to work||4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
[Bug c++/24522] htonl in optimized template function generates compiler warning
--- Comment #4 from ckillian at cs dot ucsd dot edu 2005-10-25 17:09
---
(In reply to comment #3)
I believe this winds up being a duplicate of PR c++/8057, which is fixed on
mainline. With the test case in the PR, I see the warning with 4.0, but I do
not see the warning on mainline.
Note that this slightly modified test case:
#include netinet/in.h
templatetypename S
void serialize(const uint32_t* pitem, const S item) {
uint32_t t2 = htonl(item);
}
template void serializeint (const uint32_t*, const int);
issues a warning on both 4.0 and mainline:
foo.cc: In function void serialize(const uint32_t*, const S) [with S =
int]:
foo.cc:8: instantiated from here
foo.cc:5: warning: unused variable t2
The unused variable warning of course is behavior as expected for this small
sample. My original statement that the sample should compile without warning
should seems not to be correct. That could be corrected by using the variable,
for example by printing it. The motivating example appended the bytes of t2 to
a std::string which was passed in by reference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
[Bug c++/24522] htonl in optimized template function generates compiler warning
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-25 17:51 ---
Here is a reduced testcase:
template int
void f(int i)
{
int i1 = (__extension__ ({int i2 = i; i2;}));
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Known to work|4.1.0 |4.1.0 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
[Bug c++/24522] [4.0 Regression] htonl in optimized template function generates compiler warning
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-25 17:59 --- (In reply to comment #3) I believe this winds up being a duplicate of PR c++/8057, which is fixed on mainline. With the test case in the PR, I see the warning with 4.0, but I do not see the warning on mainline. I don't think this is a duplicate of PR 8057 because my reduced testcase worked in 3.4.5. I think this was introduced by one of the C++ patches between 4.0.1 and 4.0.2 Or without -O2, -Wall, or outside of a template function. the without -O2, is because the headers change, which is why my simplified example shows the issue at every optimization level. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i486-pc-linux-gnu | GCC host triplet|i486-pc-linux-gnu | GCC target triplet|i486-pc-linux-gnu | Known to fail||4.0.3 Known to work|4.1.0 3.4.0 |4.1.0 3.4.0 3.4.5 Last reconfirmed|-00-00 00:00:00 |2005-10-25 17:59:02 date|| Summary|htonl in optimized template |[4.0 Regression] htonl in |function generates compiler |optimized template function |warning |generates compiler warning Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
[Bug fortran/24524] New: Fortran dependency checking should reverse loops
program testcase_fold real, dimension(:), pointer :: mystruct mystruct(1:3) = mystruct(2:4) END Program testcase_fold That loop should be transvered in reverse oder so that we don't need a temporary array. -- Summary: Fortran dependency checking should reverse loops Product: gcc Version: unknown Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24524
[Bug fortran/24519] gfortran slow because of incomplete dependency checking
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 18:14 --- Another issue is that we should be able to reverse the loop too, see PR 24524 for a testcase for that (which I got the idea from Tobias in the email about my patch which fixes a related bug to temporary arrays). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24519
[Bug testsuite/24477] [4.1 Regression] g++.old-deja/g++.abi/vtable2.C (test for excess errors) fails
-- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-21 20:19:16 |2005-10-25 18:57:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24477
[Bug middle-end/24295] [4.1 Regression] Xorg broken, #pragma weak foo = bar no longer causes bar to be referenced
--- Comment #22 from cvs-commit at gcc dot gnu dot org 2005-10-25 18:59 --- Subject: Bug 24295 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-25 18:59:21 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.abi: vtable2.C Log message: PR middle-end/24295, PR testsuite/24477 * g++.old-deja/g++.abi/vtable2.C: Require alias for now. Will be removed when weakref hits the tree. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6252r2=1.6253 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C.diff?cvsroot=gccr1=1.8r2=1.9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24295
[Bug testsuite/24477] [4.1 Regression] g++.old-deja/g++.abi/vtable2.C (test for excess errors) fails
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-25 18:59 --- Subject: Bug 24477 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-25 18:59:21 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.abi: vtable2.C Log message: PR middle-end/24295, PR testsuite/24477 * g++.old-deja/g++.abi/vtable2.C: Require alias for now. Will be removed when weakref hits the tree. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6252r2=1.6253 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C.diff?cvsroot=gccr1=1.8r2=1.9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24477
[Bug testsuite/24477] [4.1 Regression] g++.old-deja/g++.abi/vtable2.C (test for excess errors) fails
--- Comment #3 from aoliva at gcc dot gnu dot org 2005-10-25 18:59 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24477
[Bug testsuite/20360] 20021014-1.c fails on account of unsupported build option
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Component|target |testsuite GCC build triplet|i686-pc-cygwin | GCC host triplet|i686-pc-cygwin | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20360
[Bug bootstrap/20437] bootstrap --enable-maintainer-mode broken
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 19:18 --- I don't think --enable-maintainer-mode will ever work until the top level directory is changed to 2.53 autoconf. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 19:18:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20437
[Bug libstdc++/20448] locale testsuite fails when GCC is configured with --disable-nls
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 19:18:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
[Bug c++/24525] New: g++ fails to warn when converting UDT through double to int
g++-4.0.0 compiles the following code without warning, with both -Wconversion
and -Wall turned on. Since it is converting the UDT into a double, then
converting the double to an int, I believe it should warn exactly as it does in
the case when the commented-out line is used in place of the direct assignment.
monsterd07 g++ -Wall test.C
monsterd07 ./a.out
monsterd07 g++ --version
g++ (GCC) 3.3.4 (pre 3.3.5 20040809)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(test.C)
#include assert.h
struct T {
explicit T(int i): mV(i) {}
operator double() const {
return mV;
}
int mV;
};
int main() {
T t(5);
int y = t;
// int y = double(t);
assert(y == 5);
}
--
Summary: g++ fails to warn when converting UDT through double to
int
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: georgeh at rentec dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24525
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-25 19:19 --- Can you try this again, I think these are all fixed now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug middle-end/20937] BLK ptr's losing original ptr's static-constant readonly attribute.
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-25 19:22 ---
(In reply to comment #6)
- For some reason, GCC is casting char to int prior to returning their
value as a char, which
although works, is a fairly gross mis-optimization? (which should also
likely be considred a bug).
That is an ABI issue. Also it is most likely not able to change as some people
still use KR C where
f()
{
return 1;
}
Is still valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20937
[Bug c++/24525] g++ fails to warn when converting UDT through double to int
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 19:26 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-10-25 19:26:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24525
[Bug java/21070] [4.1 Regression]: java compiler generates wrong code on ia64
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-25 19:39 --- Is this now fixed? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21070
[Bug other/21071] libtool doesn't use just built libunwind
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 19:40 --- Is this a bug in libtool, can you report to them and then please suspend this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21071
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 19:44 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 19:44:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug middle-end/21190] [4.1 Regression] g-spitbo.adb:274: error: unrecognizable insn
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 19:45 --- I think this working again, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21190
[Bug fortran/21253] Bounds Check
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-25 19:45 --- We need a testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21253
[Bug target/21408] DAZ related macros are improperly guarded in pmmintrin.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 19:46 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|x86*| GCC target triplet||i?86-*-* x86_64-*-* Last reconfirmed|-00-00 00:00:00 |2005-10-25 19:46:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21408
[Bug c/21664] array-of-empty-structure extension not properly defined
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 19:47 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 19:47:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21664
[Bug middle-end/21781] real.c incorrectly values zero with a large exponent
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 19:49 --- Confirmed, testcase which shows this is also a rejects valid: int f[.0e2 == 0?1:-1]; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid, wrong-code Last reconfirmed|-00-00 00:00:00 |2005-10-25 19:49:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21781
[Bug fortran/24526] New: variables from modules not visible in gdb
$ cat module.f90 module foo real :: a end module foo program main use foo, only : a a = 42. print *,a end program main $ gfortran -g module.f90 $ gdb ./a.out GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) b module.f90:7 Breakpoint 1 at 0x80485e4: file module.f90, line 7. (gdb) r Starting program: /home/ig25/Krempel/Gdb/a.out Breakpoint 1, MAIN__ () at module.f90:7 7 a = 42. Current language: auto; currently fortran (gdb) p a No symbol a in current context. (gdb) $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1/configure --prefix=/home/ig25 --enable-languages=c,fortran : (reconfigured) ../gcc-4.1/configure --prefix=/home/ig25 --enable-languages=c,fortran --no-create --no-recursion Thread model: posix gcc version 4.1.0 20051011 (experimental) $ gdb --version GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux. -- Summary: variables from modules not visible in gdb Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24526
[Bug middle-end/21190] [4.1 Regression] g-spitbo.adb:274: error: unrecognizable insn
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-10-25 19:52 --- Subject: Re: [4.1 Regression] g-spitbo.adb:274: error: unrecognizable insn --- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 19:45 --- I think this working again, right? Right, this bug should be closed. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21190
[Bug c++/21802] Two-stage name lookup fails for operations
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 19:53 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||2.95.3 3.0.4 3.2.3 3.3.3 ||3.4.0 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-10-25 19:53:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802
[Bug middle-end/21190] [4.1 Regression] g-spitbo.adb:274: error: unrecognizable insn
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-25 19:57 --- Fixed so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||build, ice-on-valid-code Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21190
[Bug fortran/24527] New: derived types not displayed correctly
This may be a gdb bug, but anyway... cat type.f90 program main type foo real :: a integer :: b end type foo type(foo) :: q q = foo(3.14, 42) print *,q end program main $ gfortran -g type.f90 $ gdb ./a.out GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) b type.f90:7 Breakpoint 1 at 0x8048624: file type.f90, line 7. (gdb) r Starting program: /home/ig25/Krempel/Gdb/a.out Breakpoint 1, MAIN__ () at type.f90:7 7 q = foo(3.14, 42) Current language: auto; currently fortran (gdb) p q $1 = Invalid F77 type code 3 in symbol table. (gdb) q The program is running. Exit anyway? (y or n) y -- Summary: derived types not displayed correctly Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24527
[Bug rtl-optimization/22031] Poor code from unrolled simple loop
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 20:06 --- The second testcase works on x86_64 with -O2 -fschedule-insns -funroll-loops -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Component|tree-optimization |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22031
[Bug libfortran/22097] libgfortran build failure on mips-sgi-irix6.5
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|2005-10-23 13:15:20 |2005-10-25 20:09:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug target/22209] [4.1 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 20:11 --- The easiest way to make this go away, is to make TImode not a workable mode on mips64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug rtl-optimization/22239] [4.0 Regression] i-cobol.adb:482: error: unrecognizable insn
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-25 20:12 --- Fixed so closing as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|4.0.3 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22239
[Bug bootstrap/22408] make install fails after --enable-bootstrap=lean enabled bootstrap
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 20:13 --- Can you try this again, I think this has been fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22408
[Bug target/23359] [4.1 regression] Many Solaris 10/x86 testsuite failures with native as: use of .word
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 20:15:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23359
[Bug ada/23487] Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 20:16:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Component|rtl-optimization|target Keywords||missed-optimization Summary|bigger version of mov + cmp |[4.1 Regression]bigger |produced|version of mov + cmp ||produced Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
[Bug c++/23587] Missing warning: comparison is always false due to limited range of data type
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 20:23 --- We do have an inconstaincy here, with -W, I get a warning for all 6 of them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |c++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 20:23:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23587
[Bug c/23587] Missing warning: comparison is always false due to limited range of data type
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 20:24 --- t.c: In function void c(unsigned int): t.c:17: warning: comparison of unsigned expression 0 is always false t.c: In function void d(long unsigned int): t.c:23: warning: comparison of unsigned expression 0 is always false t.c: In function void e(long long unsigned int): t.c:29: warning: comparison of unsigned expression 0 is always false -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23587
[Bug rtl-optimization/23726] Missed optimizations for divmod
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 20:32:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23726
[Bug target/23740] attiny13 and attiny2313 are not fully supported
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 20:34:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23740
[Bug libfortran/23770] unaligned buffers in i/o library force use of memcpy()
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-25 20:34 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-25 20:34:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23770
[Bug ada/23788] s-taprop.adb:69:06: warning: cannot depend on Interrupt_Operations (wrong categorization)
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-25 20:35 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23788
[Bug libgcj/17021] libgcj verifier resolves classes too eagerly
--- Comment #14 from mckinlay at redhat dot com 2005-10-25 20:36 --- Robert, thanks very much for working on this. Examining the behaviour of Sun's verifier a bit more shows that it does attempt to resolve classes where type compatibility can not be proven by a simple string comparison, so I think that your approach is correct. I have one pedantic concern about the implementation of _Jv_equalUtf8Const_classnames: Say we're comparing a class called Lfoo and one called fool, and fool is given in the bytecode form while Lfoo is in the regular form. So, _Jv_equalUtf8Const_classnames would end up comparing the strings Lfoo and Lfool;. Whats to stop it falsely returning true in this case? Also, how about a more concise name for this function: _Jv_equalUtf8Classnames? It will also need a ChangeLog entry, of course - other than these issues, this patch looks pretty good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021
[Bug c/24528] New: [ARM EB] strcpy() of small string constant produces wrong instructions
Given the following c code from sysvinit's init.c: if (ch-action == SYSINIT) strcpy(ch-rlevel, #); gcc is producing the correct set of instructions for little endian arm, but incorrect set of instructions for big endian arm. That line when compiled with -mlittle-endian (correct): ldr r1, [r5, #40] cmp r1, #13 moveq r3, #35 moveq r2, #0 streqb r3, [r5, #28] streqb r2, [r5, #29] That line when compiled with -mbig-endian (wrong): ldr r1, [r5, #40] cmp r1, #13 moveq r3, #0 streqb r3, [r5, #29] streqb r3, [r5, #28] This results in ch-rlevel[0] set to zero instead of '#'. Offsets/enums are correct (40 for action, 28 for start of rlevel, and 13 for SYSINIT). I can post entire preprocessed and compiled output if needed. compile line is: arm-linux-gcc -c -mlong-calls -fPIC -mbig-endian -Wall -O2 -D_GNU_SOURCE init.c gcc version 3.3.6 -- Summary: [ARM EB] strcpy() of small string constant produces wrong instructions Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: djohnson+gcc at sw dot starentnetworks dot com GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: arm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24528
[Bug c/24529] New: arm_print_operand, at config/arm/arm.c:9869
While compiling ntp-4.2.0 from an i86 host for arm, I received the following error. The host OS was recent linux (2.6.12 from a Fedora Core 3 base), but the GCC in question was a cross-compile environment aimed at an ARM720T. The file in question was 'a_md5encrypt.c' from the ntp-4.2.0 distribution. I built the tools using a 'buildroot' http://buildroot.uclibc.org/ . The tools have been working well until this. I don't have the time to isolate out the error to a minimal set of code, but I felt I should at least set the warning messages into your bug system, since the compiler asked me nicely. a_md5encrypt.c: In function 'addr2refid': a_md5encrypt.c:104: internal compiler error: in arm_print_operand, at config/arm/arm.c:9869 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: arm_print_operand, at config/arm/arm.c:9869 Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brian at bulkowski dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24529
[Bug middle-end/17886] variable rotate and long long rotate should be better optimized
--- Comment #22 from cvs-commit at gcc dot gnu dot org 2005-10-25 21:38 --- Subject: Bug 17886 CVSROOT:/cvs/gcc Module name:gcc Branch: apple-local-200502-branch Changes by: [EMAIL PROTECTED]2005-10-25 21:38:27 Modified files: gcc: ChangeLog.apple-ppc expmed.c optabs.c gcc/config/i386: i386.md Log message: 2005-10-25 Eric Christopher [EMAIL PROTECTED] Import from mainline: 2005-09-28 Mark Mitchell [EMAIL PROTECTED] PR 17886 * expmed.c (expand_shift): Move logic to reverse rotation direction when rotating by constants ... * optabs.c (expand_binop): ... here. * config/i386/i386.md (rotrdi3): Handle 32-bit mode. (ix86_rotrdi3): New pattern. (rotldi3): Handle 32-bit mode. (ix86_rotldi3): New pattern. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.apple-ppc.diff?cvsroot=gcconly_with_tag=apple-local-200502-branchr1=1.1.4.200r2=1.1.4.201 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expmed.c.diff?cvsroot=gcconly_with_tag=apple-local-200502-branchr1=1.223.2.2r2=1.223.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optabs.c.diff?cvsroot=gcconly_with_tag=apple-local-200502-branchr1=1.260r2=1.260.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcconly_with_tag=apple-local-200502-branchr1=1.618.2.10r2=1.618.2.11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
[Bug libstdc++/24530] New: throw catch clause does not accept string
testcase: t.cpp
#include iostream
#include string
using namespace std;
void func_1( )
{
string aCvla=func1;
throw aCvla;
}
void func_2 ()
{
char aCvla[6];
strcpy (aCvla, func2);
throw aCvla;
}
int main()
{
try {
func_1();
} catch ( string aCA ) {
cout aCA endl;
}
try {
func_2();
} catch ( char * aCA ) {
cout aCA endl;
}
}
Invocations
g++ t.cpp
./a.out
expected output:
func1
func2
Actual output:
func1
garbage
--
Summary: throw catch clause does not accept string
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alienforever at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24530
