--- Comment #3 from irar at il dot ibm dot com 2006-09-19 07:10 ---
t.c:20: note: not vectorized: mixed data-types
t.c:20: note: can't determine vectorization factor.
Removing flags[i] = true;
Multiple data-types vectorization is already supported in the autovect branch,
and the
--- Comment #7 from irar at il dot ibm dot com 2006-09-19 07:29 ---
Even though vectorization of strided accesses is already implemented in the
autovect branch (and will be committed to the mainline 4.3), this case contains
a store with a gap (store to a[i] without a store to a[i-1]),
--- Comment #8 from micis at gmx dot de 2006-09-19 08:17 ---
The patch in comment #5 fixes the testcases but a make bootstrap ; make check
(with only C/C++) results in two new regressions:
WARNING: program timed out.
FAIL: g++.dg/opt/pr24665.C (test for excess errors)
FAIL:
--- Comment #2 from charlet at gcc dot gnu dot org 2006-09-19 08:47 ---
gprmake was a beta tool never documented, which probably should not have been
put
in the first place, so instead I'll likely remove it at some point, since in
any
case, gprmake does not really belong in the ada
The following program should return 1 when executed:
struct A {
virtual int f() {return 1;}
};
struct B : virtual A {
virtual int f() {return 0;}
};
struct C : B , virtual A {
using A::f;
};
int
main () {
C c;
return c.f () + c.C::f ();
}
It actually returns 2.
The C++ standard
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 09:41 ---
This is a dup of bug 11750, it was not hard to find that bug.
Anyways the problem here is that we still use mostly the old ARM style using
semantics instead of the standard defined ones.
*** This bug has been
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-19 09:41 ---
*** Bug 29136 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
class A
{
public:
int i;
class A1
{
int j;
};
};
class B : private A
{
public:
A::i;
A::A1;
};
void
f ()
{
B b;
b.i = 1;
B::A1 a1;
}
The above program does not compile with the following messages:
t.cpp:15: error: declaration does not declare anything
t.cpp: In function
--- Comment #9 from pault at gcc dot gnu dot org 2006-09-19 11:05 ---
Subject: Bug 29101
Author: pault
Date: Tue Sep 19 11:04:55 2006
New Revision: 117053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117053
Log:
2006-09-19 Paul Thomas [EMAIL PROTECTED]
Steven
--- Comment #2 from joseph at codesourcery dot com 2006-09-19 11:10 ---
Subject: Re: New: Strictly conforming code rejected
On Mon, 18 Sep 2006, neil at gcc dot gnu dot org wrote:
Compile the following with -std=c99 -pedantic-errors
void f(unsigned int [*]);
foo.c:1: error:
--- Comment #5 from schwab at suse dot de 2006-09-19 11:19 ---
Doesn't change anything either. I don't think this function is ever called
anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29127
--- Comment #10 from pault at gcc dot gnu dot org 2006-09-19 11:24 ---
Subject: Bug 29101
Author: pault
Date: Tue Sep 19 11:24:44 2006
New Revision: 117054
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117054
Log:
2006-09-19 Paul Thomas [EMAIL PROTECTED]
Steven
--- Comment #11 from pault at gcc dot gnu dot org 2006-09-19 11:26 ---
Thanks to Steven's intervention, I can declare this bug well and truly closed.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from uros at kss-loka dot si 2006-09-19 11:31 ---
Fixed everywhere.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|ASSIGNED
Output of gcc -v:
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../../source/gcc-4.1.1/configure --enable-threads=posix
--enable-languages=c,c++ --disable-win32-registry
Thread model: posix
gcc version 4.1.1
I wrote a Vector class that I wanted to optimize by using some inline
--- Comment #1 from jespdj at hotmail dot com 2006-09-19 11:33 ---
Created an attachment (id=12294)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12294action=view)
Source code that demonstrates the bug
This is the source code that demonstrates bug 29139.
--
--- Comment #2 from jespdj at hotmail dot com 2006-09-19 11:34 ---
Created an attachment (id=12295)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12295action=view)
Precompiled source (*.ii)
Precompiled code for gccbug.cpp of bug 29139.
--
--- Comment #12 from paulthomas2 at wanadoo dot fr 2006-09-19 11:56 ---
Subject: Re: Memory leak in gfortran
steven at gcc dot gnu dot org wrote:
--- Comment #8 from steven at gcc dot gnu dot org 2006-09-18 22:35 ---
Not fixed just yet.
Steven, I put it to rights this
--- Comment #3 from msimonides at power dot com dot pl 2006-09-19 12:11
---
That's the solution we have applied.
I've recompiled gnat-gpl-3.4.6 with your patch and it works as expected.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28716
Hello,
I'm using gcc-4.1.1, built into an EABI tool chain with glibc-2.4 and
binutils-2.16.92.
I have a Fixed-to-Float transition program shown as below. But it can only work
with -O1 option. -O2/-O3/-Os are all failed.
% cat CTL_Math.c
typedef float CTLFLOAT;
typedef int CTLFIXED;
typedef int
--- Comment #1 from mingqiao dot wu at gmail dot com 2006-09-19 12:26
---
Created an attachment (id=12296)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12296action=view)
compare the disassembly result clearly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29140
--- Comment #3 from neil at daikokuya dot co dot uk 2006-09-19 13:04
---
Subject: Re: [4.2 Regression] Strictly conforming code rejected
joseph at codesourcery dot com wrote:-
foo.c:1: error: '[*]' not allowed in other than a declaration
As the diagnostic indicates, unsigned
--- Comment #7 from pluto at agmk dot net 2006-09-19 13:08 ---
and one more misscompiled program - gzip-1.3.5.
this time 4.1.2 with -O2 -fwrapv produces wrong code.
$ dd if=/dev/zero of=foo count=10
$ gzip foo
$ gzip -d foo.gz
$ gzip: foo.gz: invalid compressed data--format violated
--- Comment #15 from pbrook at gcc dot gnu dot org 2006-09-19 13:18 ---
Subject: Bug 28516
Author: pbrook
Date: Tue Sep 19 13:18:27 2006
New Revision: 117055
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117055
Log:
2006-09-19 Paul Brook [EMAIL PROTECTED]
PR
--- Comment #16 from pbrook at gcc dot gnu dot org 2006-09-19 13:19 ---
Subject: Bug 28516
Author: pbrook
Date: Tue Sep 19 13:19:24 2006
New Revision: 117056
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117056
Log:
2006-09-19 Paul Brook [EMAIL PROTECTED]
PR
--- Comment #17 from pbrook at gcc dot gnu dot org 2006-09-19 13:26 ---
Fixed.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from joerg dot diederich at graffiti dot net 2006-09-19
13:28 ---
Created an attachment (id=12297)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12297action=view)
example source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29141
Contruction of global static objects fails while using flash adresses over
0x, e.g. for bootloader purposes. avr mcu hangs completly before main or
even the called constructor itself.
minimal gcc call:
avr-c++ -c -mmcu=at90can128 -I. -I. -g -O0 -Wall -Wextra -Wshadow
-Wpointer-arith
--- Comment #2 from joerg dot diederich at graffiti dot net 2006-09-19
13:36 ---
thanks to joerg wunsch, additional information is already available.
#ifdef L_ctors
.section .init6,ax,@progbits
.global __do_global_ctors
__do_global_ctors:
ldi r17,
--- Comment #4 from tbm at cyrius dot com 2006-09-19 14:36 ---
(In reply to comment #3)
This is partly a compiler problem, and partly a binutils problem. This bug
exists to document the fact that gcc/gas don't handle dependency violation
issues correctly in all instances.
I don't
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-19 14:42 ---
You are violating C aliasing rules here (try -Wstrict-aliasing):
return *(CTLFLOAT*)bits;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
4.2.0 20060919 (experimental)
--
Summary: gfortran - incorrectly flags error on allocatable
variable in TYPE declaration
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
void f(int,int);
void f(int,int,int);
void
g ()
{
(f)(1,2,3);
}
gives:
t.cpp: In function void g():
t.cpp:7: error: address of overloaded function with no contextual type
information
The C++ standard clause 13.3.1.1 says that '(f)(...)' is the same as
'(f)(...)',
but the latter works and
Four ways of coding a conditional assignment yields 1 conditional move using
gcc 3.4.5 20051201 (Red Hat 3.4.5-2). gcc 4.0.2 20051130 (Red Hat 4.0.2-14.EL4)
produces none. IMHO, four cmov's should have been produced. I further expect
all four functions to generates the exact same code.
All
In the test case below, GCC doesn't observe a non-restrict-qualified
pointer being based on a restrict-qualified pointer. On i686-pc-linux-gnu,
this program aborts when compiled with
-O2 -msse -ftree-vectorize
because the loop in function with_restrict is vectorized based on an unsafe
alias
--- Comment #19 from sje at gcc dot gnu dot org 2006-09-19 16:09 ---
Subject: Bug 28490
Author: sje
Date: Tue Sep 19 16:09:48 2006
New Revision: 117057
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117057
Log:
PR 28490
* config/ia64/ia64.c
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2006-09-19
16:11 ---
Steve has checked in the changes to config/unwind_ipinfo.m4, so I believe all
we need
now is...
Index: libjava/configure.ac
===
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 16:41 ---
This is an extension to both Fortran 90 and Fortran 95. It is part of Fortran
2003 though.
Anyways this is a dup of bug 20541.
*** This bug has been marked as a duplicate of 20541 ***
--
pinskia at gcc dot
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-09-19 16:41
---
*** Bug 29142 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-19 16:43 ---
Actually restrict is weird and you might be violating one of the rules for
restrict, I always forget those rules and don't really understand them that
well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
--- Comment #11 from falk at debian dot org 2006-09-19 17:38 ---
No feedback for a long time, let's just close it.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #4 from laurent at guerby dot net 2006-09-19 19:38 ---
Patch posted.
--
laurent at guerby dot net changed:
What|Removed |Added
URL|
--- Comment #12 from eweddington at cso dot atmel dot com 2006-09-19 19:41
---
(In reply to comment #11)
I just realized that the patch posted here had just posted had a = where
should have been a for two comparisons. The patch on [EMAIL PROTECTED]
is already correct.
Bjoern,
--- Comment #5 from laurent at guerby dot net 2006-09-19 19:44 ---
With gcc version 4.2.0 20060915 (experimental)
$ gcc -c -gnat05 ada_3d-file_io-step_reader.adb
ada_3d-file_io-step_reader.ads:84:04: this instantiation requires
Ada_3d.System.Containers.Single_List (body)
--- Comment #2 from laurent at guerby dot net 2006-09-19 20:00 ---
Confirmed with gcc version 4.2.0 20060915 (experimental
I think your analysis is correct, the compiler should issue an error on the
first line. If it's not correct, I don't see how the compiler could generate a
call to
--- Comment #13 from bjoern dot m dot haase at web dot de 2006-09-19 20:16
---
Hello Eric,
IIRC, the bug never was really resolved. The true place to fix the issue was,
IMO, the most dreaded source file of the entire GCC source tree: reload.
My now quite old patch tried to fix the
--- Comment #14 from eweddington at cso dot atmel dot com 2006-09-19 20:25
---
Thanks, Bjoern, for responding in detail.
If this bug cannot be reproduced, can we go ahead and close this bug report?
Eric
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
--- Comment #9 from steven at gcc dot gnu dot org 2006-09-19 21:22 ---
Subject: Bug 21299
Author: steven
Date: Tue Sep 19 21:22:31 2006
New Revision: 117061
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117061
Log:
PR rtl-optimization/21299
* reload1.c (reload):
--- Comment #10 from steven at gcc dot gnu dot org 2006-09-19 21:23 ---
Fixed on trunk for GCC 4.2.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from sayle at gcc dot gnu dot org 2006-09-19 21:25 ---
Subject: Bug 4520
Author: sayle
Date: Tue Sep 19 21:25:28 2006
New Revision: 117062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117062
Log:
PR middle-end/4520
Backport from mainline
--- Comment #3 from de at cs dot brown dot edu 2006-09-19 21:49 ---
Subject: Re: internal compiler error at cfgexpand.c:515
It seems to still be a problem with 4.1.1 (released 20060511). Maybe
this is a slightly different problem?
If not, what version has fixed this? Or, how can I
--- Comment #3 from laurent at guerby dot net 2006-09-19 21:52 ---
Note: confirmed by an Ada 2005 expert, and this has been fixed by AdaCore so
the patch will probably land in the FSF tree soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28394
--- Comment #23 from eweddington at cso dot atmel dot com 2006-09-19 21:54
---
(In reply to comment #20)
I suggest that this change should be accompanied by another indication in
the output that tells the ELF/DWARF-2 consumer about the changed pointer
size. Otherwise the consumer
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.1 4.0.3
Known to work||4.1.2
--- Comment #24 from dberlin at gcc dot gnu dot org 2006-09-20 00:00
---
You guys should be aware that dwarf2/3 has a field in the header of each dwarf
compilation unit labeled address size that tells what the address size for
that compilation unit is.
If this is set to 4, you should
--- Comment #3 from mingqiao dot wu at gmail dot com 2006-09-20 01:22
---
(In reply to comment #2)
You are violating C aliasing rules here (try -Wstrict-aliasing):
return *(CTLFLOAT*)bits;
Yes, -O2 turns on -fstrict-aliasing, and I saw many warnings like warning:
dereferencing
--- Comment #5 from patchapp at dberlin dot org 2006-09-20 02:45 ---
Subject: Bug number PR19260
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/2006-09/msg00854.html
--
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-20
03:16 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
The patch which I am thinking might had caused this is:
2006-09-13 Andreas Krebbel [EMAIL PROTECTED]
*
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-20
03:19 ---
Subject: Re: Timeouts in libstdc++, libjava and libgomp testsuites
Does hppa-linux-gnu use dwarf2 eh info?
It uses the dwarf2 unwind info. So, does hpux which doesn't appear
affected. The same
--- Comment #25 from eweddington at cso dot atmel dot com 2006-09-20 03:38
---
(In reply to comment #24)
i'm not sure why you think you need an
extra note.
Because we weren't aware of the information that you thoughtfully laid out and
put in this bug report? :-)
Thank you very much
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-20 03:48
---
I think this is fixed. If I increase the size of the parameter I get the
expected error message.
program kk
implicit none
integer, parameter :: N=65535, M=N/2-1
real, dimension(N,N):: input
call
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-20 04:40 ---
http://gcc.gnu.org/viewcvs?view=revrevision=116942
This is why I mentioned some of the libstdc++ changes should not be going in.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-20 04:47
---
Confirmed
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mingqiao dot wu at gmail dot com 2006-09-20 04:48
---
After checking gcc manual, I found union can be used to do this conversion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29140
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-20 04:49 ---
(In reply to comment #4)
After checking gcc manual, I found union can be used to do this conversion.
You can also use memcpy which is slightly more portable.
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-20 04:56 ---
[EMAIL PROTECTED] ~]$ ~/gcc-4.1/bin/gcc t.i -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/pinskia/src/gcc/gcc-4.1/gcc/configure
--prefix=/home/pinskia/gcc-4.1/
Thread model: posix
gcc
--
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
--
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
DW_FORM_ref_addr uses address size in DWARF2, but uses offset size in DWARF3.
The current linker can only handle DWARF2 info. It looks like gcc generates
DWARF3 DW_FORM_ref_addr while marking debug info as DWARF2. See
http://sourceware.org/bugzilla/show_bug.cgi?id=3191
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 05:48 ---
http://www.sourceware.org/ml/gdb/2001-06/msg00111.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29146
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-20 05:51 ---
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00030.html
Hmm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29146
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-20 05:56 ---
(In reply to comment #0)
DW_FORM_ref_addr uses address size in DWARF2, but uses offset size in DWARF3.
The current linker can only handle DWARF2 info. It looks like gcc generates
DWARF3 DW_FORM_ref_addr while
73 matches
Mail list logo
