--- 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
--- 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
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,
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)
{
--- 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
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
--- 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)
--- 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
--- 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
--- 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
--- 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 ();
--- 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
--- 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
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
--- 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
--- 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 --
--- 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
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
--- 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
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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
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
$ 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
--- 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
// 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,
--- 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
--- 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
--- 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
--- 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
$ 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]:
--- 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
--- 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
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
--- 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
--- 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
--
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
--- 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,
--- 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
--- 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
--
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
--
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
--- 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))
--- 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
--- 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
--- 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)
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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.
--
--- 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.
--- 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
--- 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
--- 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
--- 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.
--
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:
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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,
--- 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
--- 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
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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.
--- 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
--- 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
--- 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)
--- 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
--- 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
--- 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
--- 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;
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,
--- 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
--- 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
--
--- 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
--- 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
--- 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
1 - 100 of 111 matches
Mail list logo
