[Bug fortran/30902] gfortran produces wrong result with code using generic interface block
--- Comment #3 from pault at gcc dot gnu dot org 2007-02-21 08:51 --- (In reply to comment #2) (In reply to comment #0) By the way, NAG f95 detects the interface/procedure mismatch also for the original program as the interface and the subroutines are in the same file. This same-file error detection is also planed for gfortran. K'aro Deji, Or, more succinctly, the array in the interface is assumed shape, dimension (:), whereas you have an automatic array in the subroutine. Change to SUBROUTINE adsorb2(te, gam, adsor, scl, dqdt, dime, mode) IMPLICIT NONE INTEGER, INTENT(IN) :: mode, dime REAL, INTENT(IN), DIMENSION(:) :: gam, te REAL, INTENT(OUT), DIMENSION(:) :: adsor REAL, DIMENSION(:), OPTIONAL:: dqdt, scl REAL, DIMENSION(dime) :: kstar, param REAL :: rhog, rgasv and your program will work fine. As Tobias says, we will be adding the means to diagnose this, just as soon as yours truly gets some time:) I would strongly recommend that your regroup your subroutiens and the interface into a module, thusly: module adsorbers interface adsorb module procedure adsorb, adsorb2 end interface adsorb contains SUBROUTINE adsorb2(te, gam, adsor, scl, dqdt, dime, mode) IMPLICIT NONE INTEGER, INTENT(IN) :: mode, dime REAL, INTENT(IN), DIMENSION(:) :: gam, te REAL, INTENT(OUT), DIMENSION(:) :: adsor REAL, DIMENSION(:), OPTIONAL:: dqdt, scl REAL, DIMENSION(dime) :: kstar, param REAL :: rhog, rgasv REAL, PARAMETER :: as = 1.7E4, mi = 2.84E-7, ko = 7.54E-9, re = 0.4734 rhog = 1650.0 rgasv = 0.461510E+03 kstar = ko * exp(2697.2 / te) param = kstar * gam * rgasv * te adsor = rhog * as * mi * (param / (1.0 + param))**re if (mode == 2) return scl = re * adsor / ((1.0 + param) * gam) if (mode == 1) return dqdt = re * adsor * (te-2697.2) / ((1.0 + param)*te*te) RETURN END SUBROUTINE adsorb2 SUBROUTINE adsorb(te, gam, adsor, scl, dqdt, dime, mode) IMPLICIT NONE INTEGER, INTENT(IN) :: mode, dime REAL, INTENT(IN) :: gam, te REAL, INTENT(OUT) :: adsor REAL, OPTIONAL:: dqdt, scl REAL :: kstar, param REAL :: rhog, rgasv REAL, PARAMETER :: as = 1.7E4, mi = 2.84E-7, ko = 7.54E-9, re = 0.4734 rhog = 1650.0 rgasv = 0.461510E+03 kstar = ko * exp(2697.2 / te) param = kstar * gam * rgasv * te adsor = rhog * as * mi * (param / (1.0 + param))**re if (mode == 2) return scl = re * adsor / ((1.0 + param) * gam) if (mode == 1) return dqdt = re * adsor * (te-2697.2) / ((1.0 + param)*te*te) RETURN END SUBROUTINE adsorb end module adsorbers PROGRAM adsorb_test use adsorbers IMPLICIT NONE REAL, DIMENSION(10) :: tsl, gamm, adwat, wsc INTEGER :: dime, mode, ns, k REAL:: gams, ts, adwatg ns = 10 do k = 1,ns tsl(k) = 180.0 gamm(k) = 1.50E-6 enddo gams = gamm(1) ts = tsl(1) call adsorb(ts, gams, adwatg, dime = 1, mode = 2) call adsorb(tsl, gamm, adwat, wsc, dime = ns, mode = 1) do k = 1,ns write(*,*) tsl(k), gamm(k), adwat(k) enddo write (*,*) - write(*,*) ts, gams, adwatg stop END PROGRAM adsorb_test Odabo Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30902
[Bug middle-end/30143] [4.2 only] OpenMP can produce invalid gimple
--- Comment #12 from jakub at gcc dot gnu dot org 2007-02-21 09:12 --- Subject: Bug 30143 Author: jakub Date: Wed Feb 21 09:12:14 2007 New Revision: 122192 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122192 Log: Backported from mainline 2006-12-20 Andrew Pinski [EMAIL PROTECTED] PR middle-end/30143 * omp-low.c (init_tmp_var): New function. (save_tmp_var): New function. (lower_omp_1): Use them for VAR_DECL. * gcc.dg/gomp/complex-1.c: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/gomp/complex-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/omp-low.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30143
[Bug middle-end/30904] New: [dataflow] No longer optimizes shifts with large count
extern void link_error (const char *);
extern int ones;
void foo(int);
void kernel ()
{
struct { unsigned int a : 7; } s;
s.a = ones;
if (s.a 8)
link_error (foo);
if (s.a 9)
link_error (foo);
}
mainline optimizes this to an empty function with -O2, dataflow branch
retains the s.a 9 check.
--
Summary: [dataflow] No longer optimizes shifts with large count
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug middle-end/30905] New: [dataflow] Fails to cross-jump
static int a[30];
static int b[30];
int gen_int(int);
void kernel ()
{
int i;
i = gen_int (1);
if (i != 0)
{
a[0] = a[0] + (a[0] 3);
b[0] = b[0] + (b[0] | 3);
}
else
{
a[0] = a[0] + (a[0] 3);
b[0] = b[0] + (b[0] | 3);
}
if (i != 1)
{
a[1] = a[1] + (a[1] 3);
b[1] = b[1] + (b[1] | 3);
}
else
{
a[1] = a[1] + (a[1] 3);
b[1] = b[1] + (b[1] | 3);
}
}
is optimized by mainline to straight line code without compares and jumps at
-O2. dataflow branch retains the comparisons with i and the duplicate
instructions.
--
Summary: [dataflow] Fails to cross-jump
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug c++/30822] wrong choice of overloaded template functions in recursive call
--- Comment #4 from Zarathustra at gentlemansclub dot de 2007-02-21 10:16
---
Now the code was also compiled with 4.3.0 and produced the same error message.
I can make the actual failure more specific: The following code compiles fine:
templatetemplatetypename class TOperator,typename TElement
void for_all_5(TElement elem, cons_end tail);
templatetemplatetypename class TOperator,typename TElement, typename TTail
void for_all_5(TElement elem, TTail tail)
{
TOperatorTElement()(elem);
for_all_5TOperator(tail.elem,tail.tail);
}
templatetemplatetypename class TOperator,typename TElement
void for_all_5(TElement elem, cons_end tail)
{
TOperatorTElement()(elem);
}
// -- snip -- //
in main:
for_all_5op(list.elem,list.tail);
The difference is the forward declaration of the second for_all method.
From my understanding of the standard it is not necessary to do the forward
declaration since by 14.6.4/1 declarations which are visible at the point of
instantiation are to be considered and by 14.6.4.1/1 the point of
instantiation of all template functions is at the definition of the main
function.
--
Zarathustra at gentlemansclub dot de changed:
What|Removed |Added
Version|4.1.2 |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30822
[Bug middle-end/30907] New: [dataflow] Bad interaction with addressing mode selection and regalloc
int bar (void);
void foo (int *);
static int s[10];
void foobar (int i1, int i2, int i3, int i4, int i5, int i6)
{
int a[100];
int i, i7;
i7 = bar ();
bar ();
for (i = 0; i 100; i++)
a[i] = s[i1] + s[i2] + s[i3] + s[i4] + s[i5] + s[i6] + s[i7];
foo (a[0]);
return;
}
If you compare mainline to dataflow branch at -O2 you can see
--- t.i.trunk 2007-02-21 11:31:09.663252586 +0100
+++ t.i.df 2007-02-21 11:31:10.548064364 +0100
@@ -37,7 +37,6 @@
movls(,%rbx,4), %edx
addls(,%rcx,4), %edx
movslq %r12d,%r12
- leaq16(%rsp), %rdi
addls(,%r13,4), %edx
addls(,%r14,4), %edx
addls(,%r15,4), %edx
@@ -46,10 +45,11 @@
addls(,%r12,4), %edx
.p2align 4,,7
.L2:
- movl%edx, (%rdi,%rax,4)
+ movl%edx, 16(%rsp,%rax,4)
addq$1, %rax
cmpq$100, %rax
jne .L2
+ leaq16(%rsp), %rdi
callfoo
addq$424, %rsp
popq%rbx
that is, we are choosing a more expensive addressing mode in the loop not
noticing that 16(%rsp) can be (G)CSEd. This makes the above loop run
33% slower on x86_64.
--
Summary: [dataflow] Bad interaction with addressing mode
selection and regalloc
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
[Bug fortran/30870] GENERIC non-INTRINSIC procedure rejected as actual argument
--- Comment #2 from pault at gcc dot gnu dot org 2007-02-21 10:47 ---
This fixes it:
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 122101)
--- gcc/fortran/resolve.c (working copy)
*** resolve_actual_arglist (gfc_actual_argli
*** 924,932
if (sym-attr.generic)
{
! gfc_error (GENERIC non-INTRINSIC procedure '%s' is not
!allowed as an actual argument at %L, sym-name,
!e-where);
}
/* If the symbol is the function that names the current (or
--- 924,943
if (sym-attr.generic)
{
! gfc_interface *p;
! for (p = sym-generic; p; p = p-next)
! if (strcmp (sym-name, p-sym-name) == 0)
! {
! e-symtree = gfc_find_symtree
! (p-sym-ns-sym_root, sym-name);
! sym = p-sym;
! break;
! }
!
! if (p == NULL || e-symtree == NULL)
! gfc_error (GENERIC non-INTRINSIC procedure '%s' is not
! allowed as an actual argument at %L, sym-name,
! e-where);
}
/* If the symbol is the function that names the current (or
It needs commenting to the effect that a generic that is also a specific is OK.
I'd be more than happy if somebody would regtest/submit/commit this one - I
cannot for some weeks.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30870
[Bug debug/30898] [4.3 regression] ICE with anonymous union and -g
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-21 11:02 --- Works for me - maybe related to the fixed PR29558. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30898
[Bug fortran/30873] ENTRY without explict RESULT does not work for recursive functions
--- Comment #2 from pault at gcc dot gnu dot org 2007-02-21 11:02 ---
Removing the error call
if (proc-attr.recursive result == NULL)
{
gfc_error (RESULT attribute required in ENTRY statement at %C);
return MATCH_ERROR;
}
at decl.c:3032 fixes the problem.
I guess that there is a testsuite case for this? I have not regtested it.
This looks to me as if it is a mis-interpretation or simplification of the
standard - it had better be checked.
As with others, if anybody wants to run with this, be my guest.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30873
[Bug debug/30898] [4.3 regression] ICE with anonymous union and -g
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-21 11:03 --- Confirmed. 32bits only. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||i?86-*-* Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-02-21 11:03:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30898
[Bug debug/30898] [4.3 regression] ICE with anonymous union and -g
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-21 11:06 --- Another subreg lowering issue. We have #1 0x0078510e in mem_loc_descriptor (rtl=0x2b5aa76fc0c0, mode=DImode) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:9010 9010 gcc_unreachable (); (gdb) call debug_rtx (rtl) (concatn/v:DI [ (reg:SI 61 [ D.2102 ]) (reg:SI 0 ax [orig:62 D.2102+4 ] [62]) ]) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||ian at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30898
[Bug c++/30901] [4.1 Regression] internal compiler error: in is_ancestor, at cp/name-lookup.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-21 11:12 --- *** This bug has been marked as a duplicate of 27102 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-invalid-code Known to fail||4.1.2 4.0.4 Known to work||4.2.0 4.3.0 3.4.6 Resolution||DUPLICATE Summary|internal compiler error: in |[4.1 Regression] internal |is_ancestor, at cp/name-|compiler error: in |lookup.c|is_ancestor, at cp/name- ||lookup.c Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30901
[Bug c++/27102] [4.0/4.1 regression] ICE with invalid class name in function template
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-02-21 11:12 --- *** Bug 30901 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||grizlyk1 at yandex dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c/30908] New: -Os inlines functions that are called more than once (optimization regression)
This has been observed for the AVR target, but could perhaps also apply to other targets. Recent versions of GCC (4.1.1 and 4.3.0 trunk are confirmed) tend to inline static functions with -Os even when they are being called more than once, thus resulting in larger code than necessary. This violates the objective of -Os to only apply those additional optimizations from level 2 that will not increase the code size. GCC 3.x versions did not do this, so it's an optimization regression. Compiling the attached simple code snippet (which is completely independent of the AVR target) with -Os, and either with or without -DNOINLINE yields: ... /* function main size 17 (13) */ ... /* function main size 31 (27) */ ... -- Summary: -Os inlines functions that are called more than once (optimization regression) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j at uriah dot heep dot sax dot de GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug c/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-02-21 11:50 --- Created an attachment (id=13082) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13082action=view) Sample code snippet that can be used to demonstrate the problem. avr-gcc -DNOINLINE -Os -S bar.c avr-gcc -Os -S bar.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #11 from P dot Schaffnit at access dot rwth-aachen dot de 2007-02-21 11:58 --- Hi! I don't seem to be able to apply this patch to '122195' sources: did it get out of synch, or is it plain clumsiness on my part? I get: Hunk #2 FAILED at 3151. 1 out of 2 hunks FAILED -- saving rejects to file gcc/fortran/trans-decl.c.rej patching file gcc/fortran/options.c This is probably very clear when one knows what it's all about, but unfortunately that's not the case for me... Thanks! Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug tree-optimization/30858] [4.3 Regression] ice for legal code with -O2 -ftree-vectorize
--- Comment #7 from dcb314 at hotmail dot com 2007-02-21 12:17 --- (In reply to comment #6) proposed patches - http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01734.html would you mind giving these patches a try? (to see what's the next ICE...?) If the patches have been applied to gcc mainstream, then they will appear in the next 4.3 snapshot, due 23 Feb, and so I will test them then. Is this acceptable ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30858
[Bug c++/30909] New: public member of template class not visible in derived template class
on SuSe linux 10.0
~/wurschtel/cpp uname -a
Linux djebe 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 i686 i686 i386
GNU/Linux
with gcc version 4.0.2 (but also with 4.1.2)
when running make on the following files
A.h:
//const int NUM_BYTES = 5;
templateint NUM_BYTES
class A
{
public:
int mBytes[NUM_BYTES];
};
-
B.h:
#include A.h
templateint NUM_BYTES
class B : public ANUM_BYTES
{
public:
int blee() {
mBytes[0]++;
return mBytes[0];
};
};
-
x.cpp:
#include A.h
templateint NUM_BYTES
class B : public ANUM_BYTES
{
public:
int blee() {
mBytes[0]++;
return mBytes[0];
};
};
-
makefie:
#include A.h
templateint NUM_BYTES
class B : public ANUM_BYTES
{
public:
int blee() {
mBytes[0]++;
return mBytes[0];
};
};
-
I get compile errors:
~/wurschtel/cpp make
rm -f x
g++ -ansi -pedantic -Wall -o x x.cpp
B.h: In member function â#128;#152;int BNUM_BYTES::blee()â#128;#153;:
B.h:9: error: â#128;#152;mBytesâ#128;#153; was not declared in this scope
make: *** [x] Error 1
---
when the templates are changed to classes and the template parameter is
declared as constant everything compiles and runs ok.
On older linux running g++ version 2.95.2 everything compiles and runs ok.
Sorry if this report is duplicate, i filed it yesterday along with 30893 but
cannot find it today so I assume commit failed.
--
Summary: public member of template class not visible in derived
template class
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sl at datamyway dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30909
[Bug c++/30909] public member of template class not visible in derived template class
--- Comment #1 from sl at datamyway dot de 2007-02-21 12:27 ---
Sorry for my cutpaste, the files really are:
A.h:
//const int NUM_BYTES = 5;
templateint NUM_BYTES
class A
{
public:
int mBytes[NUM_BYTES];
};
B.h:
#include A.h
templateint NUM_BYTES
class B : public ANUM_BYTES
{
public:
int blee() {
mBytes[0]++;
return mBytes[0];
};
};
x.cpp:
#include iostream
using namespace std;
#include B.h
int main (int argc, char* argv[])
{
B4 *b = new B4;
b-blee();
cout b-blee() endl;
}
---
makefile:
.SUFFIXES:
all: x
% :: %.cpp
rm -f $@
g++ -ansi -pedantic -Wall -o $@ $^
% :: %.c
rm -f $@
g++ -o $@ $^ -lgmp -lpq
%.o :: %.cpp %.hpp
rm -f $@
g++ -c $ -g
%.o :: %.c
rm -f $@
g++ -c $ -g
---
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30909
bug report
I'm sending this mail to report a bug during the compilation of a Fortran program. The information needed are: Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5367) After the followin command line: g77 NEWdistr_A_noCorrezione.f it shows this message: NEWdistr_A_noCorrezione.f: In program `doppioni': In file included from NEWdistr_A_noCorrezione.f:0: NEWdistr_A_noCorrezione.f:806: internal compiler error: in instantiate_virtual_regs_lossage, at function.c:3746 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This is it. I don't know if you need a copy of the program NEWdistr_A_noCorrezione.f. I attach it Thank you very much NEWdistr_A_noCorrezione.f Description: Binary data
[Bug c/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-21 12:33 --- This is not a bug with inlining but at most with the cost function(s). Use -fdump-ipa-inline to follow the reasoning: Deciding on inlining. Starting with 10 insns. Inlining always_inline functions: Deciding on smaller functions: Deciding on functions called once: Inlined 2 calls, eliminated 1 functions, 10 insns turned to 10 insns. so it believes code size is unchanged by inlining the function twice and removing the now unneeded out-of-line copy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug c/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-21 12:35 --- And indeed, for x86_64 we have [EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc ./xgcc -B. -Os -fdump-ipa-inline t.i -c [EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc size t.o textdata bss dec hex filename 94 0 0 94 5e t.o [EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc ./xgcc -B. -Os -fdump-ipa-inline t.i -c -fno-inline [EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc size t.o textdata bss dec hex filename 123 0 0 123 7b t.o so with inlining the function twice text size is smaller than without inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug fortran/30910] New: Gfortran: ES format not quite right...
When printing using ES-format descriptor with zero decimal places (e.g. ES6.0) get zero answer. Sample code below, compiled as gfortran test.f90, using version 4.3.0 20070221 (experimental) on suse 9 linux box (64-bit). - program esformat !This should print as 1.E-01 write(6,'(es6.0)') 1.0e-1 end program esformat - -- Summary: Gfortran: ES format not quite right... Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pmason at ricardo dot com GCC build triplet: 4.3.0 20070221 (experimental) GCC host triplet: suse9 x86_64 GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug c++/30909] public member of template class not visible in derived template class
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-21 12:54 --- Read about two-stage name lookup. Use this-mBytes. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30909
[Bug c/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-02-21 12:58 --- (In reply to comment #2) so it believes code size is unchanged by inlining the function twice and removing the now unneeded out-of-line copy. So does that mean some cost factor needs to be tuned in the AVR target backend? (In reply to comment #3) And indeed, for x86_64 we have so with inlining the function twice text size is smaller than without inlining. Which is not surprising for an i386-alike CPU. :-) I guess the major saving here is probably because it does not have to setup stack frames, while on the AVR target, stack frames are already omitted when not needed, so saving a function call doesn't save that much there. Also, the AVR target passes function arguments in registers. I guess targets like sparc64 would be better for comparision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug middle-end/30904] [dataflow] No longer optimizes shifts with large count
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2007-02-21 13:30 --- Confirmed, same problem on alphaev56-unknown-linux-gnu. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|x86_64-*-* | Last reconfirmed|-00-00 00:00:00 |2007-02-21 13:30:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug libgcj/30886] Memory collection deadlock
--- Comment #2 from aph at gcc dot gnu dot org 2007-02-21 13:38 --- I don't understand what this is supposed to be testing. Can you please explain what your expected behaviour is? -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30886
[Bug fortran/30873] ENTRY without explict RESULT does not work for recursive functions
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-21 13:53 ---
Removing the error call
if (proc-attr.recursive result == NULL)
{
gfc_error (RESULT attribute required in ENTRY statement at %C);
return MATCH_ERROR;
}
at decl.c:3032 fixes the problem.
This is a very old check. I could trace it back to:
r69825: * gcc/fortran: New front end.
I just checked the current g95 source code and it also doesn't contain this
error anymore.
I guess that there is a testsuite case for this? I have not regtested it.
This looks to me as if it is a mis-interpretation or simplification of the
standard - it had better be checked.
I just comment it and run a make check-gfortran, which succeeded.
Maybe one should re-read the ENTRY section of the standard and try to come up
with something which is not covered, but I think this patch has no unwanted
side effects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30873
[Bug tree-optimization/30911] New: VRP fails to eliminate range checks in Ada code
All of the range checks can in theory be eliminated, except for the first one (a call to __gnat_rcheck_04, unlike the others which are calls to __gnat_rcheck_04), but they are not: $ gcc -c -O2 -fdump-tree-all j.ads $ grep __gnat_rcheck_12 j.ads.118t.final_cleanup __gnat_rcheck_12 (join_equal.adb, 14); __gnat_rcheck_12 (join_equal.adb, 14); __gnat_rcheck_12 (join_equal.adb, 29); __gnat_rcheck_12 (join_equal.adb, 29); __gnat_rcheck_12 (join_equal.adb, 39); __gnat_rcheck_12 (join_equal.adb, 39); -- Summary: VRP fails to eliminate range checks in Ada code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: baldrick at gcc dot gnu dot org GCC host triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug c/30912] New: Can't build gcc on Sun Solaris
$ uname -a SunOS sun 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-5_10 $ $CC -V cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11 $ gmake --version GNU Make 3.80 $ gmake -k gmake[1]: Entering directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2' gmake[2]: Entering directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/zlib' true AR_FLAGS=rc CC_FOR_BUILD=/usr/ucb/cc CFLAGS=-g CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD=-g CFLAGS_FOR_TARGET=-O2 -g INSTALL=/usr/local/bin/install -c INSTALL_DATA=/usr/local/bin/install -c -m 644 INSTALL_PROGRAM=/usr/local/bin/install -c INSTALL_SCRIPT=/usr/local/bin/install -c LDFLAGS= LIBCFLAGS=-g LIBCFLAGS_FOR_TARGET=-O2 -g MAKE=gmake MAKEINFO=/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/missing makeinfo --split-size=500 --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh EXPECT=expect RUNTEST=runtest RUNTESTFLAGS= exec_prefix=/usr/home/pirschel/software infodir=/usr/home/pirschel/software/info libdir=/usr/home/pirschel/software/lib prefix=/usr/home/pirschel/software tooldir=/usr/home/pirschel/software/sparc-sun-solaris2.8 AR=ar AS=as CC=/usr/ucb/cc CXX=c++ LD=ld LIBCFLAGS=-g NM=nm PICFLAG= RANLIB=ranlib DESTDIR= DO=all multi-do # gmake gmake[2]: Leaving directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/zlib' gmake[2]: Entering directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/libiberty' gmake[3]: Entering directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/libiberty/testsuite' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/libiberty/testsuite' gmake[2]: Leaving directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/libiberty' gmake[2]: Entering directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/fastjar' gmake AR_FLAGS=rc CC_FOR_BUILD=/usr/ucb/cc CFLAGS=-g CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD=-g CFLAGS_FOR_TARGET=-O2 -g INSTALL=/usr/local/bin/install -c INSTALL_DATA=/usr/local/bin/install -c -m 644 INSTALL_PROGRAM=/usr/local/bin/install -c INSTALL_SCRIPT=/usr/local/bin/install -c JC1FLAGS= LDFLAGS= LIBCFLAGS=-g LIBCFLAGS_FOR_TARGET=-O2 -g MAKE=gmake MAKEINFO=/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/missing makeinfo --split-size=500 --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh exec_prefix=/usr/home/pirschel/software infodir=/usr/home/pirschel/software/info libdir=/usr/home/pirschel/software/lib prefix=/usr/home/pirschel/software AR=ar AS=as CC=/usr/ucb/cc CXX=c++ LD=ld LIBCFLAGS=-g NM=nm PICFLAG= RANLIB=ranlib DESTDIR= all-am gmake[3]: Entering directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/fastjar' restore=: backupdir=.am$$ \ rm -rf $backupdir mkdir $backupdir \ for f in fastjar.info fastjar.info-[0-9] fastjar.info-[0-9][0-9] fastjar.i[0-9] fastjar.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ if /export/home0/sun_home/pirschel/tmp/gcc-4.1.2/missing makeinfo --split-size=500 --split-size=500 -I ../.././fastjar/../gcc/doc/include -I ../.././fastjar \ -o fastjar.info `test -f 'fastjar.texi' || echo '../.././fastjar/'`fastjar.texi; \ then \ rc=0; \ else \ rc=$?; \ $restore $backupdir/* `echo ./fastjar.info | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. gmake[3]: *** [fastjar.info] Error 1 perl ../.././fastjar/../contrib/texi2pod.pl -D fastjar ../.././fastjar/fastjar.texi fastjar.pod (pod2man --center=GNU --release=gcc-4.1.2 --section=1 fastjar.pod fastjar.1.T$$ \ mv -f fastjar.1.T$$ fastjar.1) || \ (rm -f fastjar.1.T$$ exit 1) /bin/sh: pod2man: not found gmake[3]: [fastjar.1] Error 1 (ignored) perl ../.././fastjar/../contrib/texi2pod.pl -D grepjar ../.././fastjar/fastjar.texi grepjar.pod (pod2man --center=GNU --release=gcc-4.1.2 --section=1 grepjar.pod grepjar.1.T$$ \ mv -f grepjar.1.T$$ grepjar.1) || \ (rm -f grepjar.1.T$$ exit 1) /bin/sh: pod2man: not found gmake[3]: [grepjar.1] Error 1 (ignored) gmake[3]: Target `all-am' not remade because of errors. rm fastjar.pod grepjar.pod gmake[3]: Leaving directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/fastjar' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/export/home0/sun_home/pirschel/tmp/gcc-4.1.2/host-sparc-sun-solaris2.8/fastjar' gmake[1]: *** [all-fastjar] Error 2 gmake[2]: Entering
[Bug middle-end/30364] [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant folding
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-02-21 14:24 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-21 14:24:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug tree-optimization/30913] New: SRA bugs with anon bitfields
// gcc -O2 -Wall -S uninit-anon-bitfield.c
struct foo {
unsigned int a:16;
unsigned int b:11;
unsigned int :5;
};
extern struct foo bar;
void foo(int a, int b)
{
struct foo tmp;
tmp.a = a;
tmp.b = b;
bar = tmp;
}
warns while it should not, the anon bitfield is just a padding, can't be
assigned to. There is no warning with -fno-tree-sra.
The bug is in SRA IMHO, when scalarizing a struct assignment, it should
certainly
ignore the anon bitfields (TREE_CODE (x-element) == FIELD_DECL DECL_NAME
(x-element) == NULL TREE_CODE (TREE_TYPE (x-element)) == BIT_FIELD_TYPE
?).
Both in generate_element_copy, generate_copy_inout and perhaps in other places
as well. Or not instantiate the anon bitfields at all.
There is another bug, e.g. for
struct foo {
unsigned int a:16;
unsigned int b:11;
unsigned int :5;
};
extern struct foo bar;
void foo(struct foo a)
{
struct foo tmp;
tmp = a;
bar = tmp;
}
SRA certainly should not have decided to use element copies at all, that makes
many times worse code.
--
Summary: SRA bugs with anon bitfields
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30913
[Bug fortran/30910] Gfortran: ES format not quite right...
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-02-21 14:32 --- I wil investigate this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-21 14:32:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug c/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-02-21 14:35 --- Unfortunately(?) the cost metrics for inlining are completely target independent at the moment. Can you check whether adjusting --param inline-call-cost will fix it for you? At the moment this is artificially high (16) and it may be a good candidate for a target specific default value. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug c/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #6 from j at uriah dot heep dot sax dot de 2007-02-21 14:46 --- (In reply to comment #5) Unfortunately(?) the cost metrics for inlining are completely target independent at the moment. Can you check whether adjusting --param inline-call-cost will fix it for you? Only if I change it to 0, I get a different picture: ---8--- Deciding on inlining. Starting with 8 insns. Inlining always_inline functions: Deciding on smaller functions: Considering inline candidate wait. Considering wait with 4 insns to be inlined into main Estimated growth after inlined into all callees is +2 insns. Estimated badness is 4, frequency 100.00. Inlined into main which now has 7 insns,net change of +3 insns. Considering wait with 4 insns to be inlined into main Estimated growth after inlined into all callees is -1 insns. Estimated badness is 1, frequency 100.00. Inlined into main which now has 10 insns,net change of -1 insns. Deciding on functions called once: Inlined 2 calls, eliminated 1 functions, 8 insns turned to 10 insns. ... ---8--- So it inlines them still, even though it knows the resulting code will grow. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-21 14:51 --- This is a regression. With 4.1.2 20070115 (prerelease) (SUSE Linux) I get 1.E-01, but with today's 4.2 and 4.3 I get 0.E+00. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to fail||4.3.0 4.2.0 Known to work||4.1.2 Summary|Gfortran: ES format not |[Regression 4.2, 4.3] |quite right... |Gfortran: ES format not ||quite right... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug bootstrap/30914] New: Bootstrap fails on HP-UX
$ uname -a HP-UX hp-ux B.11.11 U 9000/785 2014286724 unlimited-user license $ gmake --version GNU Make 3.80 $ gmake bootstrap [...] Bootstrapping the compiler gmake[1]: Entering directory `/home/pirschel/tmp/gcc-4.1.2/gcc' gmake[1]: *** No rule to make target `bootstrap'. Stop. gmake[1]: Leaving directory `/home/pirschel/tmp/gcc-4.1.2/gcc' gmake: *** [bootstrap] Error 2 -- Summary: Bootstrap fails on HP-UX Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: info at icomsoftware dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30914
[Bug middle-end/30761] [4.1/4.2/4.3 regression] Error: unsupported relocation against sfp
--- Comment #4 from uweigand at gcc dot gnu dot org 2007-02-21 15:05 --- Subject: Bug 30761 Author: uweigand Date: Wed Feb 21 15:05:01 2007 New Revision: 122199 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122199 Log: PR middle-end/30761 * reload1.c (eliminate_regs_in_insn): In the single_set special case, attempt to re-recognize the insn before falling back to having reload fix it up. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-21 15:10 --- Even on powerpc, it lowers in size also: no inline: __TEXT __DATA __OBJC others dec hex 84 0 0 0 84 54 With inline: __TEXT __DATA __OBJC others dec hex 52 0 0 0 52 34 So really this is a target specific issue I think. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug bootstrap/30915] New: [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
Hi, Platform: Gentoo Linux: $ uname -a Linux hertz 2.6.17-gentoo-r4 #1 SMP Thu Aug 24 16:20:25 BST 2006 x86_64 AMD Opteron(tm) Processor 844 AuthenticAMD GNU/Linux Toolchain: $ /lib/libc.so.6 GNU C Library development release version 2.4, by Roland McGrath et al. Copyright (C) 2006 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. Compiled by GNU CC version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9). Compiled on a Linux 2.6.17 system on 2007-02-01. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 1.19 GNU Libidn by Simon Josefsson GNU libio by Per Bothner NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B Thread-local storage support included. For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. $ gcc --version gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9) Copyright (C) 2006 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. $ make --version GNU Make 3.81 Copyright (C) 2006 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. This program built for x86_64-pc-linux-gnu Configured with: ../trunk/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu --prefix=/usr/local/gcc-svn --enable-languages=c,c++,fortran --disable-multilib cvs checkout on 2007-02-21 09:24 GMT Source is in /MHz/roger/src/gcc-svn/trunk Build directory is /MHz/roger/src/gcc-svn/build_hertz (initially empty). Bootstrap proceeds fine until near the finish, in building libstdc++, I get this (sorry about the long paste, but it is the complete last command): /MHz/roger/src/gcc-svn/build_hertz/./gcc/xgcc -shared-libgcc -B/MHz/roger/src/gcc-svn/build_hertz/./gcc -nostdinc++ -L/MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/gcc-svn/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-svn/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include -I/MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/MHz/roger/src/gcc-svn/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../trunk/libstdc++-v3/src/compatibility.cc -fPIC -DPIC -o .libs/compatibility.o In file included from /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/c++locale.h:48, from /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/iosfwd:45, from /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:70, from /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:46, from /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/string:47, from ../../../../trunk/libstdc++-v3/src/compatibility.cc:49: /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:103: error: '::clearerr' has not been declared /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:104: error: '::fclose' has not been declared /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:105: error: '::feof' has not been declared /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:106: error: '::ferror' has not been declared /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:107: error: '::fflush' has not been declared /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:108: error: '::fgetc' has not been declared /MHz/roger/src/gcc-svn/build_hertz/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:109: error: '::fgetpos' has
[Bug c++/30332] [4.1/4.2/4.3 regression] bit-field: optimization BUG?
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-21 15:12 ---
With 4.1.3 for C we have, even without optimizing
./xgcc -B. -o t t.c -Wall
t.c: In function 'main':
t.c:13: warning: format '%llx' expects type 'long long unsigned int', but
argument 2 has type 'long unsigned int:33'
./t
9
For C++ we for all optimizations get
./t
20009
The difference after gimplification is
main ()
{
unnamed type D.2220;
int D.2221;
struct S x;
unnamed type z;
x.a = 8589934591;
D.2220 = x.a;
z = D.2220 + 10;
printf (%llx\n[0], z);
D.2221 = 0;
return D.2221;
}
vs.
int main() ()
{
long long unsigned int D.2823;
int D.2824;
{
struct S x;
long long unsigned int z;
x.a = 8589934591;
D.2823 = x.a;
z = D.2823 + 10;
printf (%llx\n[0], z);
D.2824 = 0;
return D.2824;
}
D.2824 = 0;
return D.2824;
}
i.e. typeof(+x.a) yields a different result for C and C++. For C we leave
bitfield types bigger than int alone and don't promote them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30332
[Bug fortran/30902] gfortran produces wrong result with code using generic interface block
--- Comment #4 from deji_aking at yahoo dot ca 2007-02-21 15:13 --- (In reply to comment #3) (In reply to comment #2) (In reply to comment #0) By the way, NAG f95 detects the interface/procedure mismatch also for the original program as the interface and the subroutines are in the same file. This same-file error detection is also planed for gfortran. K'aro Deji, Or, more succinctly, the array in the interface is assumed shape, dimension (:), whereas you have an automatic array in the subroutine. Change to Effecting the change Paul suggested fixed it for me, Thanks all. The interface and the subroutine are in different files in the original code. Deji -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30902
[Bug tree-optimization/30708] [4.1 Regression] Aliasing miscompilation
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30708
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #1 from baldrick at gcc dot gnu dot org 2007-02-21 15:17 --- I've tried and failed to attach the source code (bugzilla problem), so here it is inline (you can extract it using gnatchop): with Join_Equal; with JS; procedure J is new Join_Equal ( Source_Type = JS.S, Equal = JS.E, Target_Type = JS.T, Move= JS.M ); package JS is type S is range 0 .. 100; type T is range 10 .. 20; function E (L, R : S) return Boolean; procedure M ( First, Last : S; Destination : T ); end JS; generic type Source_Type is (); with function Equal (Left, Right : Source_Type) return Boolean; type Target_Type is (); with procedure Move ( First, Last : Source_Type; Destination : Target_Type ); procedure Join_Equal ( Source_First : in Source_Type; Source_Last : in out Source_Type; -- returns last read Target_First : in Target_Type; Target_Last :out Target_Type -- returns last written ); pragma Pure (Join_Equal); procedure Join_Equal ( Source_First : in Source_Type; Source_Last : in out Source_Type; Target_First : in Target_Type; Target_Last :out Target_Type ) is Source : Source_Type := Source_First; Target : Target_Type := Target_First; begin if Source_Last Source_First then if Target_First = Target_Type'First then raise Constraint_Error; end if; Target_Last := Target_Type'Pred (Target_First); return; end if; loop declare Start : constant Source_Type := Source; Prev : Source_Type := Source; begin loop if Source = Source_Last then Move (Start, Source, Target); Target_Last := Target; return; end if; Source := Source_Type'Succ (Source); exit when not Equal (Prev, Source); Prev := Source; end loop; Move (Start, Prev, Target); if Target = Target_Type'Last then Source_Last := Prev; Target_Last := Target; return; end if; Target := Target_Type'Succ (Target); end; end loop; end Join_Equal; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30913] SRA bugs with anon bitfields
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-21 15:18 --- SRA certainly should not have decided to use element copies at all, that makes many times worse code. That is really unrelated to unanonymous bitfields and is a different bug and has been filled already (I forgot the number but I filled it). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30913
[Bug c++/30850] [4.1/4.2/4.3 regression] ICE with invalid asm statement
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-21 15:22 --- Confirmed. Starting with 4.0.0 there are random segfaults on diagnostics. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.6 Known to work||3.3.6 Last reconfirmed|-00-00 00:00:00 |2007-02-21 15:22:46 date|| Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30850
[Bug c++/30818] [4.1/4.2/4.3 Regression] templates and typedefs cause function prototype not to match
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30818
[Bug middle-end/30774] [4.1 regression] ld: fatal: too many symbols require `small' PIC references
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30774
[Bug middle-end/30907] [dataflow] Bad interaction with addressing mode selection and regalloc
--- Comment #1 from steven at gcc dot gnu dot org 2007-02-21 15:53 --- On i686, this happens too, due to fwprop1: In insn 47, replacing (mem/s:SI (plus:SI (plus:SI (mult:SI (reg:SI 75 [ ivtmp.37 ]) (const_int 4 [0x4])) (reg/f:SI 91)) (const_int -4 [0xfffc])) [3 a S4 A8]) with (mem/s:SI (plus:SI (plus:SI (mult:SI (reg:SI 75 [ ivtmp.37 ]) (const_int 4 [0x4])) (reg/f:SI 20 frame)) (const_int -404 [0xfe6c])) [3 a S4 A8]) defering rescan insn with uid = 47. This results in different code between trunk and the df-branch: -- trunk ++ df-branch @@ -12,7 +12,6 @@ movl%eax, %ebx callbar movl12(%ebp), %eax - leal-404(%ebp), %ecx movls(,%eax,4), %edx movl8(%ebp), %eax addls(,%eax,4), %edx @@ -28,11 +27,12 @@ addls(,%ebx,4), %edx .p2align 4,,7 .L2: - movl%edx, -4(%ecx,%eax,4) + movl%edx, -408(%ebp,%eax,4) addl$1, %eax cmpl$101, %eax jne .L2 - movl%ecx, (%esp) + leal-404(%ebp), %eax + movl%eax, (%esp) callfoo addl$404, %esp popl%ebx -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-21 15:53:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
[Bug middle-end/30904] [dataflow] No longer optimizes shifts with large count
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-21 15:58 --- Problem here is combine. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Last reconfirmed|2007-02-21 13:30:59 |2007-02-21 15:58:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug middle-end/30907] [dataflow] Bad interaction with addressing mode selection and regalloc
--- Comment #2 from bonzini at gnu dot org 2007-02-21 16:01 --- fwprop has some tricks to avoid propagating within loops before unrolling. The interesting point is why they trigger differently in mainline vs. dataflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
[Bug middle-end/30904] [dataflow] No longer optimizes shifts with large count
--- Comment #3 from bonzini at gnu dot org 2007-02-21 16:03 ---
This unrelated patch fixes a very similar case for powerpc
unpatched:
or r0,r3,r28
rlwinm r0,r0,0,0xff
cmpwi cr7,r0,0
beq- cr7,L4929
patched: (r3 and r28 are both extended from QImode)
or. r0,r3,r28
beq- cr0,L4929
With some luck, it does the same for this testcase too? It would be nice to
examine why though. :-)
Sorry for the lack of professionality exhibited in this comment...
Index: combine.c
===
--- combine.c (revision 122195)
+++ combine.c (working copy)
@@ -1016,6 +1016,7 @@ combine_instructions (rtx f, unsigned in
#endif
rtx links, nextlinks;
rtx first;
+ basic_block prev_basic_block;
int new_direct_jump_p = 0;
@@ -1057,15 +1058,20 @@ combine_instructions (rtx f, unsigned in
for what bits are known to be set. */
label_tick = label_tick_ebb_start = 1;
+ prev_basic_block = NULL;
setup_incoming_promotions (first);
-
create_log_links ();
+
FOR_EACH_BB (this_basic_block)
{
last_call_luid = 0;
mem_last_set = -1;
label_tick++;
+ if (!single_pred_p (this_basic_block)
+ || single_pred (this_basic_block) != prev_basic_block)
+ label_tick_ebb_start = label_tick;
+
FOR_BB_INSNS (this_basic_block, insn)
if (INSN_P (insn) BLOCK_FOR_INSN (insn))
{
@@ -1090,8 +1096,8 @@ combine_instructions (rtx f, unsigned in
fprintf(dump_file, insn_cost %d: %d\n,
INSN_UID (insn), INSN_COST (insn));
}
- else if (LABEL_P (insn))
- label_tick_ebb_start = label_tick;
+
+ prev_basic_block = this_basic_block;
}
nonzero_sign_valid = 1;
@@ -1099,6 +1105,8 @@ combine_instructions (rtx f, unsigned in
/* Now scan all the insns in forward order. */
label_tick = label_tick_ebb_start = 1;
+ prev_basic_block = NULL;
+
init_reg_last ();
setup_incoming_promotions (first);
@@ -1107,6 +1115,10 @@ combine_instructions (rtx f, unsigned in
last_call_luid = 0;
mem_last_set = -1;
label_tick++;
+ if (!single_pred_p (this_basic_block)
+ || single_pred (this_basic_block) != prev_basic_block)
+label_tick_ebb_start = label_tick;
+
for (insn = BB_HEAD (this_basic_block);
insn != NEXT_INSN (BB_END (this_basic_block));
insn = next ? next : NEXT_INSN (insn))
@@ -1253,9 +1265,9 @@ combine_instructions (rtx f, unsigned in
retry:
;
}
- else if (LABEL_P (insn))
- label_tick_ebb_start = label_tick;
}
+
+ prev_basic_block = this_basic_block;
}
clear_log_links ();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug middle-end/30904] [dataflow] No longer optimizes shifts with large count
--- Comment #4 from bonzini at gnu dot org 2007-02-21 16:05 --- It doesn't, but I confirm that the bug is target independent. A way to fix it would be to do the transform in VRP, but I'll look at combine if time permits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug middle-end/30904] [dataflow] No longer optimizes shifts with large count
--- Comment #5 from bonzini at gnu dot org 2007-02-21 16:11 --- The first one is in the same EBB as the assignment. The second one isn't and combine screws up. This is because of the way combine treats regs with one def that dominates all uses, I talked to zadeck yesterday about that on IRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug debug/30898] [4.3 regression] ICE with anonymous union and -g
--- Comment #4 from ian at airs dot com 2007-02-21 16:12 --- I'm testing a patch. -- ian at airs dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ian at airs dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-02-21 11:03:36 |2007-02-21 16:12:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30898
[Bug middle-end/30904] [dataflow] No longer optimizes shifts with large count
--- Comment #6 from bonzini at gnu dot org 2007-02-21 16:23 --- Created an attachment (id=13083) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13083action=view) patch to fix the bug The logic in trunk's combine with respect to uninitialized variables is correct. We have to look at DF_LR_IN for the entry basic block to find variables that are not used uninitialized. In fact, the name of DF_UR_IN is misleading, as it computes *initialized* registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug c/30916] New: Wrong �float� rather than �double� due to prototype warning
The following code:
void func (float a);
void
func (float a)
{
}
int
main (void)
{
func (3.0f);
return 0;
}
Compiled with: gcc -Wconversion bug.c
produces:
bug.c: In function main:
bug.c:10: warning: passing argument 1 of func as float rather than double
due to prototype
I was not expecting this.
When looking at the code in c-typeck.c at line 2473.
I see:
/* Warn if any argument is passed as `float',
since without a prototype it would be `double'. */
if (formal_prec == TYPE_PRECISION (float_type_node)
type != dfloat32_type_node)
Should the dfloat32_type_node be changed into float_type_node?
When I change this no warning is produced anymore.
--
Summary: Wrong float rather than double due to prototype
warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hermantenbrugge at home dot nl
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30916
[Bug fortran/30876] Array valued recursive function rejected
--- Comment #2 from pault at gcc dot gnu dot org 2007-02-21 16:33 --- fortcom: Warning: dtgv.f90, line 9: Recursive array-valued function without result variable ambiguous [TEST] Goes right to the nub of it. Within test, is an r-value expression that contains a reference to test (int_expr) a reference to the function result array or a recursive call to test? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug fortran/30876] Array valued recursive function rejected
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-21 17:03 --- Paul, fortcom: Warning: dtgv.f90, line 9: Recursive array-valued function without result variable ambiguous [TEST] Goes right to the nub of it. Within test, is an r-value expression that contains a reference to test (int_expr) a reference to the function result array or a recursive call to test? Well, it is easy: 12.5.2.1 Function subprogram If RESULT is not specified, the result variable is function- name and all occurrences of the function name in execution-part statements are references to the result variable. See also: http://gcc.gnu.org/ml/fortran/2006-05/msg00342.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-21 17:03:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #8 from j at uriah dot heep dot sax dot de 2007-02-21 17:18 --- (In reply to comment #7) So really this is a target specific issue I think. The only question then is whether the current architecture allows for tuning the costs in the target-specific files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #9 from hubicka at gcc dot gnu dot org 2007-02-21 17:26 --- The main problem here is that inliner really don't have enough of detailed information. In general inlining improves optimization and often leads to smaller code when inlining such a trivial function ARM or not. Clearly the outcome depends on function, on the context it is called in and on the target platform and on the other optimizations enabled but basically only function body in very rought way is considered when making inlining decisions. I don't see that adding a hook to provide target specific tuning for size estimates at this level is going to be useful enough to justify maintenance cost of such code. Sadly inlining heuristics is one of the most important and least informed parts of optimization queue. Honza PS: In your testcase x86-64 will pass in register and won't need stack frame either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug c/30912] Can't build gcc on Sun Solaris
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-02-21 17:38 --- Please post the configure line. $ gmake -k Do not use -k. /bin/sh: pod2man: not found Do not use /bin/sh. Please retry after reading the build instructions available at: http://gcc.gnu.org/install http://gcc.gnu.org/install/specific.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30912
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #10 from steven at gcc dot gnu dot org 2007-02-21 17:42 --- So, ehm... What do the asm dumps for AVR look like? Can you attach them, so we know what we're talking about here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-21 17:55 --- Bonus points if you can reduce this to a C test case ;-) Starting with the gimple dumps, this is usually not hard to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-02-21 18:01 --- Bonus points if you can reduce this to a C test case ;-) Starting with the gimple dumps, this is usually not hard to do. Not everything is in the dumps, in particular you don't have subtypes in C. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug c++/30917] New: ICE with friend in local class (to a function)
Testcase:
unsigned count() {
class QGListIterator {
friend class QGList;
QGListIterator( const QGList );
};
}
I think this is valid code.
--
Summary: ICE with friend in local class (to a function)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
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=30917
[Bug c++/30917] ICE with friend in local class (to a function)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-21 18:24 --- The ICE: t2.cc: In function 'unsigned int count()': t2.cc:4: internal compiler error: in lookup_name_real, at cp/name-lookup.c:4014 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30917
[Bug fortran/30876] Array valued recursive function rejected
--- Comment #4 from pault at gcc dot gnu dot org 2007-02-21 18:52 --- Tobias, Well, it is easy: 12.5.2.1 Function subprogram If RESULT is not specified, the result variable is function- name and all occurrences of the function name in execution-part statements are references to the result variable. A! OK, thanks - I can feel a patch coming on. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug fortran/30865] optional argument passed on to size(...,dim=)
--- Comment #7 from kargl at gcc dot gnu dot org 2007-02-21 19:02 --- (In reply to comment #4) Created an attachment (id=13073) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13073action=view) [edit] Fix for the problem Paul, I tried to apply your patch, but it is rejected. Is your code up-to-date? In particular, Sandra'a recent CALL_EXPR patch caused a lot of code churn in trans-*.c files. steve -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30865
[Bug tree-optimization/30858] [4.3 Regression] ice for legal code with -O2 -ftree-vectorize
--- Comment #8 from dorit at il dot ibm dot com 2007-02-21 19:31 --- Is this acceptable ? sure, thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30858
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #11 from j at uriah dot heep dot sax dot de 2007-02-21 19:32 --- (In reply to comment #9) I don't see that adding a hook to provide target specific tuning for size estimates at this level is going to be useful enough to justify maintenance cost of such code. Sadly inlining heuristics is one of the most important and least informed parts of optimization queue. Well, for the AVR, it's rare you could see a size benefit for almost any function that is called more than once. As most AVR users are concerned about size (rather than speed), it would probably even make sense to allow for a backend flag that tells the middle-end to never try inlining unless it is really only called once. (In reply to comment #10) So, ehm... What do the asm dumps for AVR look like? Can you attach them, so we know what we're talking about here? Yes, will do. Arguably, it's only very few instructions for this fairly simple test case, but I've been trying to construct a simplified case that is even completely target independent (so all the GCC folks who don't know the AVR don't have to care for things like AVR inline assembly statements or such). In real-world code, I've seen more pessimistic results out of this kind of inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #12 from j at uriah dot heep dot sax dot de 2007-02-21 19:32 --- Created an attachment (id=13084) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13084action=view) Compilation result with inlined functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #13 from j at uriah dot heep dot sax dot de 2007-02-21 19:33 --- Created an attachment (id=13085) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13085action=view) Compilation result with inlining disabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-02-21 19:37 --- The AVR back-end really needs improvement: ldi r18,lo8(1) ldi r19,hi8(1) .L3: std Y+2,r19 std Y+1,r18 ldi r24,lo8(99) ldi r25,hi8(99) here r25 and r19 are the same, 0. Other than that, we need to estatimate the cost of adding/subtracting/comparing of integers WORD_SIZE better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug c/28706] [4.1 Regression] Compile failure with --combine and explicitly aligned structures
--- Comment #4 from ddrake at brontes3d dot com 2007-02-21 19:50 ---
Created an attachment (id=13086)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13086action=view)
backported to gcc 4.1.2
Is there any chance of this fix appearing in a release before 4.3.0? I have
backported it to 4.1.2 successfully. There was a trivial reject (indentation
changes only) and also I had to add { } around the contents of the 2nd hunk in
c-typeck.c
Let me know if I can help further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28706
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- Comment #15 from j at uriah dot heep dot sax dot de 2007-02-21 19:51 --- (In reply to comment #14) The AVR back-end really needs improvement: Oh, I certainly wouldn't deny that. :-) Yes, the tendency to handle far too many items as 16 bits (the sizeof(int) on that machine) when 8 bits would suffice is one of the major issues the AVR-GCC users have with the compiler. If we could really find someone to improve that, we'd probably even catch up with the rather famous IAR compiler (that right now generates about 10...20 % tighter code, at a price of some four-digit USDs per license...). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug c++/29939] Add rvalue references (C++0x)
--- Comment #5 from hhinnant at apple dot com 2007-02-21 20:17 --- Russell Yanofsky has submitted a patch implementing N2118: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01760.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
[Bug c++/29939] Add rvalue references (C++0x)
--- Comment #6 from fang at csl dot cornell dot edu 2007-02-21 20:26 --- Subject: Re: Add rvalue references (C++0x) --- Comment #5 from hhinnant at apple dot com 2007-02-21 20:17 --- Russell Yanofsky has submitted a patch implementing N2118: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01760.html Thanks for the update. *excitement* But shouldn't the patch be dated 2007-02-20? or is it really 2006-02-20? :) Fang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
[Bug tree-optimization/30558] ICE with OpenMP and exceptions
--- Comment #6 from supermar at gmx dot de 2007-02-21 20:31 --- Just to note: I can confirm the bug for x86-architecture as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug rtl-optimization/30643] [4.1/4.2/4.3 Regression] CSE regression
--- Comment #3 from jakub at gcc dot gnu dot org 2007-02-21 20:49 --- 4.1.2 behaves the same way as 4.2/4.3, the PR27363 patch that caused this is got committed even there, see http://gcc.gnu.org/viewcvs?root=gccview=revrev=115620 Reverting that patch on gcc-4_1-branch restores the previous behavior. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 4.2.0 4.3.0 Known to work||4.1.1 Summary|[4.2/4.3 Regression] CSE|[4.1/4.2/4.3 Regression] CSE |regression |regression Target Milestone|4.2.0 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug middle-end/30905] [dataflow] Fails to cross-jump
--- Comment #1 from steven at gcc dot gnu dot org 2007-02-21 20:59 --- Confirmed, we almost never do cross-jumping on the dataflow-branch anymore: only after regmove. -- 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 |2007-02-21 20:59:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug fortran/30877] overloading operator(*) for intrinsic type (complex) fails
--- Comment #2 from pault at gcc dot gnu dot org 2007-02-21 21:14 --- (In reply to comment #1) MODULE PROCEDURE F1 interface.c:567 is where it all starts. The types that cannot be over-ridden are to be found there. If complex is excluded from product, we run into a problem with the test for the shape of the two operands. Making them the same, pro temp, permits the code to compile and run. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877
[Bug libfortran/30918] New: Failure to skip commented out NAMELIST
Hi, when reading a namelist from a file, gfortran does not skip a commented out entry as in !REPORT use = 'ignore' /! Commented out, ignore this one! ! REPORT type = 'SYNOP' use = 'active' max_proc = 20 / The attached program demonstrates that gfortran reads the first entry although it should be skipped. -- Summary: Failure to skip commented out NAMELIST Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- Comment #1 from anlauf at gmx dot de 2007-02-21 21:47 --- Created an attachment (id=13087) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13087action=view) Read loop for namelist file with multiple entries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- Comment #2 from anlauf at gmx dot de 2007-02-21 21:47 --- Created an attachment (id=13088) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13088action=view) The namelist file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug middle-end/30095] ICE in lhd_set_decl_assembler_name, at langhooks.c:165 with -O0
--- Comment #4 from anlauf at gmx dot de 2007-02-21 21:57 --- I cannot reproduce this one any longer on a current 4.3. Has this one been fixed, or did it get hidden behind something else? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30095
[Bug target/15267] libgcc_s.so.1 fails to link on Solaris 8/SPARC with GNU as 2.14.91
--- Comment #9 from fcusack at fcusack dot com 2007-02-21 22:08 --- seen this with S10 and gcc-3.4.6 as well. For some reason I didn't see this with gcc-3.4.5 and perhaps earlier versions. Workaround for me is to set LIBGCC2_DEBUG_CFLAGS (in gcc/Makefile.in) to -gstabs instead of -g. -- fcusack at fcusack dot com changed: What|Removed |Added CC||fcusack at fcusack dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15267
[Bug middle-end/30905] [dataflow] Fails to cross-jump
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-21 22:09 --- On the trunk, *and* on the dataflow branch, we crossjump the code starting with if (i != 1) on the first cleanup_cfg iteration when it's called from rest_of_handle_stack_adjustments. Trunk then goes on to crossjump the other blocks, but the df-branch stops because there is a set to the CC-reg in the way. That set has a REG_UNUSED flag on it. What probably happens, is that flow on the trunk does some dce in the liveness update, and the df-branch does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug middle-end/30095] ICE in lhd_set_decl_assembler_name, at langhooks.c:165 with -O0
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-21 22:29 --- I can still reproduce it on powerpc-linux-gnu 4.3.0 20070220 so the bug is still there for sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30095
[Bug middle-end/30095] ICE in lhd_set_decl_assembler_name, at langhooks.c:165 with -O0
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-21 22:35 --- ;; __builtin_memcpy ((char[0:][1:1] *) D.992, C.966, 4) (insn 39 38 40 (set (reg:SI 134) (high:SI (symbol_ref:SI (*.LANCHOR0) [flags 0x182]))) -1 (nil) (nil)) (insn 40 39 41 (set (reg/f:SI 133) (lo_sum:SI (reg:SI 134) (symbol_ref:SI (*.LANCHOR0) [flags 0x182]))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:SI (*.LANCHOR0) [flags 0x182]) (nil))) (insn 41 40 42 (set (reg:SI 135) (mem/c/i:SI (reg/f:SI 133) [0 C.966+0 S4])) -1 (nil) (nil)) (insn 42 41 0 (set (mem:SI (reg:SI 120 [ D.992 ]) [0 S4 A8]) (reg:SI 135)) -1 (nil) (nil)) Hmm, the expansion of __builtin_memcpy just created an integer load. I think the memcpy improvements for x86 hide the issue there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30095
[Bug ada/18819] [4.2/4.3 regression] ACATS cdd2a02 fail at runtime
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2007-02-21 22:58 --- Subject: Bug 18819 Author: ebotcazou Date: Wed Feb 21 22:58:44 2007 New Revision: 122208 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122208 Log: PR ada/18819 * sem_ch3.adb (Create_Constrained_Components): for a subtype of an untagged derived type, add hidden components to keep discriminant layout consistent, when a given discriminant of the derived type constraints several discriminants of the parent type. Added: trunk/gcc/testsuite/gnat.dg/derived_aggregate.adb Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch3.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/18819] [4.2/4.3 regression] ACATS cdd2a02 fail at runtime
--- Comment #36 from ebotcazou at gcc dot gnu dot org 2007-02-21 23:00 --- Subject: Bug 18819 Author: ebotcazou Date: Wed Feb 21 23:00:01 2007 New Revision: 122209 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122209 Log: PR ada/18819 * sem_ch3.adb (Create_Constrained_Components): for a subtype of an untagged derived type, add hidden components to keep discriminant layout consistent, when a given discriminant of the derived type constraints several discriminants of the parent type. Added: branches/gcc-4_2-branch/gcc/testsuite/gnat.dg/derived_aggregate.adb Modified: branches/gcc-4_2-branch/gcc/ada/ChangeLog branches/gcc-4_2-branch/gcc/ada/sem_ch3.adb branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/18819] [4.2/4.3 regression] ACATS cdd2a02 fail at runtime
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2007-02-21 23:04 --- At long last. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||02/msg01786.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #14 from pluto at agmk dot net 2007-02-22 00:13 ---
(In reply to comment #12)
Already posted as http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00885.html,
with no response.
this patch doesn't cover one situation:
struct D;
struct C {
virtual void f() = 0;
protected: // or private
friend class D;
~C();
};
in such case compiler should generate warning, because class D
can delete derived object through the pointer to class C.
--
pluto at agmk dot net changed:
What|Removed |Added
CC||pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug target/30919] New: [4.1 regression] unable to find a register to spill in class 'CREG'
seen with the final 4.1.2 release; taken from the OOo 2.1 sources, which built
fine with previous 4.1 versions.
test case fails with -O0, works with -O1 and -O2
Matthias
In function 'void callVirtualMethod(void*, sal_uInt32, void*,
typelib_TypeDescription*, bool, sal_uInt64*, sal_uInt32, sal_uInt64*,
sal_uInt32, double*, sal_uInt32)':
/home/doko/gcj/openoffice.org-2.1/ooo-build/build/current/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:198:
error: unable to find a register to spill in class 'CREG'
/home/doko/gcj/openoffice.org-2.1/ooo-build/build/current/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:198:
error: this is the insn:
(insn 68 67 71 6 (parallel [
(set (reg:DI 0 ax [orig:136 D.31215 ] [136])
(const_int 0 [0x0]))
(set (reg/f:DI 40 r11 [orig:134 stack ] [134])
(plus:DI (reg/f:DI 40 r11 [orig:134 stack ] [134])
(reg:DI 0 ax [orig:136 D.31215 ] [136])))
(set (reg/f:DI 39 r10 [orig:135 pStack ] [135])
(plus:DI (reg/f:DI 39 r10 [orig:135 pStack ] [135])
(reg:DI 0 ax [orig:136 D.31215 ] [136])))
(set (mem:BLK (reg/f:DI 40 r11 [orig:134 stack ] [134]) [0 A64])
(mem:BLK (reg/f:DI 39 r10 [orig:135 pStack ] [135]) [0 A64]))
(use (reg:DI 0 ax [orig:136 D.31215 ] [136]))
(use (reg:SI 19 dirflag))
]) 707 {*rep_movqi_rex64} (nil)
(expr_list:REG_UNUSED (reg/f:DI 39 r10 [orig:135 pStack ] [135])
(expr_list:REG_UNUSED (reg/f:DI 40 r11 [orig:134 stack ] [134])
(expr_list:REG_UNUSED (reg:DI 0 ax [orig:136 D.31215 ] [136])
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_UNUSED (reg/f:DI 39 r10 [orig:135 pStack ]
[135])
(expr_list:REG_UNUSED (reg/f:DI 40 r11 [orig:134 stack
] [134])
(expr_list:REG_UNUSED (reg:DI 0 ax [orig:136
D.31215 ] [136])
(nil)
/home/doko/gcj/openoffice.org-2.1/ooo-build/build/current/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:198:
confused by earlier errors, bailing out
--
Summary: [4.1 regression] unable to find a register to spill in
class 'CREG'
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30919
[Bug target/30919] [4.1 regression] unable to find a register to spill in class 'CREG'
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-02-22 00:35 --- Created an attachment (id=13089) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13089action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30919
[Bug tree-optimization/30858] [4.3 Regression] ice for legal code with -O2 -ftree-vectorize
--- Comment #9 from patchapp at dberlin dot org 2007-02-22 01:01 --- Subject: Bug number PR30858 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01774.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30858
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #15 from ben at decadent dot org dot uk 2007-02-22 01:10 --- Pawel: Yes, any friend class or function can call a protected or private destructor wrongly. So can members of the class - in fact, even pure virtual members can, since they may still have definitions! The current implementation warns whenever any function might be able to call a non-virtual destructor in a polymorphic class; this results in many false positives. False warnings result in programmers disabling the warning, or paying less attention to warnings, or (in this case) introducing a virtual destructor for no good reason. That is why I consider the behaviour a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-02-22 01:23 --- Curious. I will exzmine this on the weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-02-22 01:26 --- I fixed one similar to this not too long ago with E format. I will dig that up while I am at it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
