2009/1/9 Sean D'Epagnier geckosena...@gmail.com:
Hi,
I am currently working on adding native fixed-point support to the avr
backend. A lot of stuff is working, but there are a few things left,
one of them is conversions from fixed point to floating point.
I have conversions between all
I've been investigating a code-reordering question to do with g++ strict
alias analysis, and I suspect there is a deficiency in the way
type-based alias analysis works. I realise that's unlikely to be the
case, so I'll try to present a concise demonstration which uses (I
think) well-defined C
On Sat, Jan 10, 2009 at 12:19 PM, Raoul Gough raoulgo...@clara.co.uk wrote:
I've been investigating a code-reordering question to do with g++ strict
alias analysis, and I suspect there is a deficiency in the way type-based
alias analysis works. I realise that's unlikely to be the case, so I'll
On Sat, Jan 10, 2009 at 12:55 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sat, Jan 10, 2009 at 12:19 PM, Raoul Gough raoulgo...@clara.co.uk wrote:
I've been investigating a code-reordering question to do with g++ strict
alias analysis, and I suspect there is a deficiency in the
Hello Dave
On 09.01.09, you wrote:
You can't assume that actually was a stack overflow just because the
stack ended up corrupted.
yes thats the problem, because a assert give this message too.maybe the
program do assert.
maybe theres a way that cygwin print out the assert text earlier
Hi,
It looks like the tests for -frtl-abstract-sequences are either skipped
or xfailed for a long list of platforms:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
unrecognizable insn for -frtl-abstract-sequences
Almost any source file compiled for any of a large number of targets
On Sat, Jan 10, 2009 at 3:33 PM, Laurent GUERBY laur...@guerby.net wrote:
Hi,
It looks like the tests for -frtl-abstract-sequences are either skipped
or xfailed for a long list of platforms:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
unrecognizable insn for -frtl-abstract-sequences
On Sat, 2009-01-10 at 15:56 +0100, Richard Guenther wrote:
On Sat, Jan 10, 2009 at 3:33 PM, Laurent GUERBY laur...@guerby.net wrote:
Hi,
It looks like the tests for -frtl-abstract-sequences are either skipped
or xfailed for a long list of platforms:
L.S.,
I have kept this under wraps for some weeks because I wanted to be sure
all Steering Committee members had a chance to review this request - in
spite of the holiday season.
Now, however, I want to congratulate Daniel Franke and Steve Kargle (who
has been a GNU Fortran maintainer
--- Comment #2 from dcb314 at hotmail dot com 2009-01-10 08:47 ---
(In reply to comment #1)
You can get an error via -pedantic-errors.
Agreed - but switching on that flag opens a whole can of worms.
All I'm interested in is getting this *one* warning changed into
an error, for
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-10 09:04 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00644.html
Ian Taylor's review:
I'm not really comfortable with breaking the building of old version
of glibc just to fix an ice-on-invalid. I'll approve this
Due to revision 143234:
Author: joel
Date: Fri Jan 9 21:12:36 2009 UTC (14 hours, 12 minutes ago)
Log Message:
2009-01-09 Joel Sherrill joel.sherr...@oarcorp.com
* lib/target-supports.exp: Add method to determine if the effective
target is really a ppc405 after applying
On i686-apple-darwin9 the test gcc/testsuite/gcc.dg/graphite/block-3.c
introduced in revision 143159 fails with:
[ibook-dhum] f90/bug% gcc44
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/graphite/block-3.c
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/graphite/block-3.c:6: error: size of
array 'A' is too
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-10 11:48 ---
Subject: Bug 36695
Author: jakub
Date: Sat Jan 10 11:48:06 2009
New Revision: 143244
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143244
Log:
PR c++/36695
* typeck2.c (build_functional_cast):
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-10 11:49 ---
Subject: Bug 38648
Author: jakub
Date: Sat Jan 10 11:49:04 2009
New Revision: 143245
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143245
Log:
PR c++/38648
* typeck.c (cp_build_modify_expr):
--- Comment #1 from dominiq at lps dot ens dot fr 2009-01-10 11:49 ---
I have forgotten to say that the failure occurs in 32 bit mode, but disappears
with -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-10 11:50 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-10 11:51 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #6 from laurent at guerby dot net 2009-01-10 12:41 ---
Jakub, your patch fixes all pr37433.c FAIL, thanks! Test results
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00868.html
This also seem to fix an ICE I did not report but visible here in previous test
results:
+++ This bug was initially created as a clone of Bug #38776 +++
Request For Enhancement
I woukd like the created Makefile to build gcc using a different strategy
(compilation course) for coverage versus the strategy it uses for
profiling. Both build strategies seems to follow the same course of
--- Comment #3 from laurent at guerby dot net 2009-01-10 13:08 ---
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00868.html
Might be related to:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
Looks like the solution has been to disable those tests on a long list of
platforms.
--- Comment #4 from laurent at guerby dot net 2009-01-10 13:10 ---
List of tests with undefined reference to `__gnu_mcount_nc'
FAIL: gcc.dg/20021014-1.c (test for excess errors)
FAIL: gcc.dg/nest.c (test for excess errors)
FAIL: gcc.dg/nested-func-4.c (test for excess errors)
FAIL:
gcc4.3.3 snapshot fail to compile with this message.
ada-lex.l:456: error: unable to find a register to spill in class 'R0_REGS'
ada-lex.l:456: error: this is the insn:
(insn:HI 249 374 275 48 ada-lex.l:451 (set (mem:QI (plus:SI (reg/v/f:SI 12 r12
[
orig:174 value ] [174])
(reg:SI
--- Comment #1 from masaki dot chikama at gmail dot com 2009-01-10 13:27
---
Created an attachment (id=17069)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17069action=view)
cccHZxYV.out
preprocessed file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38793
--- Comment #2 from masaki dot chikama at gmail dot com 2009-01-10 13:29
---
Created an attachment (id=17070)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17070action=view)
test.c
reduced test case for -O2
$ sh4-unknown-linux-gnu-gcc -O2 test.c
test.c: In function 'f2':
--- Comment #2 from laurent at guerby dot net 2009-01-10 13:31 ---
You mean adding:
/* { dg-skip-if unaligned access { arm*-*-* } * } */
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38696
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-10 14:02 ---
Subject: Bug 38695
Author: jakub
Date: Sat Jan 10 14:02:12 2009
New Revision: 143246
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143246
Log:
PR target/38695
* config/arm/arm.c
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-10 14:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from yu19820428 at 163 dot com 2009-01-10 15:28 ---
Of course, it is a weird situation. Nobody use the options like this. However,
it is indeed a problem in 4.2.4. I do not know it has been fixed in 4.3.* or
not, because some other options may have effect on it so that it
--- Comment #6 from amylaar at gcc dot gnu dot org 2009-01-10 16:10 ---
(In reply to comment #5)
Joern, re. comment #4, Richi refers to my patch to enable PRE at -Os, see
[1].
An extension to this patch that we tested on x86 machines, is to disable PRE
for scalar integer
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-10
16:35 ---
Subject: Re: fails to build cross gcc for target
hppa64-hp-hpux11.00 in libstdc++/libmath
On Fri, 09 Jan 2009, bkoz at gcc dot gnu dot org wrote:
Any chance I could get a generated c++config.h
--- Comment #6 from l dot jirkovsky at gmail dot com 2009-01-10 16:42
---
I've tried it with gcc 4.2.4 and it works perfectly, so it have to be caused by
some change between 4.2.4 and 4.3.2.
I'll try to use svn to find out which commit causes this.
--
The following invalid code snippet is accepted in GCC 4.2.0:
===
typedef int foo() {}
===
--
Summary: [4.2/4.3/4.4 regression] Function body accepted in
typedef
Product: gcc
Version: 4.4.0
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38794
--- Comment #7 from l dot jirkovsky at gmail dot com 2009-01-10 16:47
---
I've forgot to post info about gcc 4.2.4:
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.4/configure --prefix=/home/lukas/gcc
--enable-shared --enable-languages=c,c++
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-01-10 16:48
---
The following invalid code snippet is accepted in GCC 4.2.0:
That should be since GCC 4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38794
The following invalid code snippet is triggers an ICE since GCC 4.3.0:
templatetypename... T int foo(int i)
{
return *reinterpret_castT*(i);
}
void bar(int i)
{
fooint(i);
}
bug.cc: In function 'int foo(int)
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38795
The following invalid code is accepted on the trunk:
struct A
{
void operator= (const A) = default;
};
Because the return type is not A, but void the operator=
cannot be the defaulted.
In fact GCC silently
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-01-10
19:57 ---
Jerry,
If I use the following patch to xplor-nih
--- xrmani.f.org2009-01-09 17:48:46.0 -0500
+++ xrmani.f2009-01-10 14:29:42.0 -0500
@@ -363,6 +363,7 @@
END IF
--- Comment #9 from pault at gcc dot gnu dot org 2009-01-10 21:01 ---
Subject: Bug 38665
Author: pault
Date: Sat Jan 10 21:01:14 2009
New Revision: 143248
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143248
Log:
2009-01-10 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #10 from pault at gcc dot gnu dot org 2009-01-10 21:06 ---
Subject: Bug 38657
Author: pault
Date: Sat Jan 10 21:06:27 2009
New Revision: 143249
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143249
Log:
2009-01-10 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #10 from pault at gcc dot gnu dot org 2009-01-10 21:25 ---
Subject: Bug 38665
Author: pault
Date: Sat Jan 10 21:24:54 2009
New Revision: 143250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143250
Log:
2009-01-10 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #2 from sebpop at gmail dot com 2009-01-10 21:32 ---
Subject: Re: FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
Does the attached patch fix the fail?
Thanks,
Sebastian
--- Comment #3 from sebpop at gmail dot com 2009-01-10 21:32 ---
Created an
--- Comment #11 from pault at gcc dot gnu dot org 2009-01-10 21:41 ---
Subject: Bug 38665
Author: pault
Date: Sat Jan 10 21:41:16 2009
New Revision: 143252
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143252
Log:
2009-01-10 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #12 from pault at gcc dot gnu dot org 2009-01-10 21:44 ---
Fixed on trunk and latest 4.3
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
--- Comment #13 from pault at gcc dot gnu dot org 2009-01-10 21:44 ---
Fixed on trunk and latest 4.3
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pault at gcc dot gnu dot org 2009-01-10 21:45 ---
Fixed on trunk and 4.3
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Compiling the following code snippet with -Wall -Wextra -std=gnu++0x
results in a warning for the first line, but not for the second:
==
const int foo();
auto bar() - const int;
==
bug.cc:1: warning: type qualifiers ignored on function
--- Comment #4 from dominiq at lps dot ens dot fr 2009-01-10 22:03 ---
Does the attached patch fix the fail?
With the patch the test compiles (it does with M up to 812) and the Strip
Mining is done for the second nested loops:
for (s_1=0;s_1=1;s_1++) {
for (s_3=0;s_3=1;s_3++) {
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-01-10 22:06
---
I don't know how I can test this file alone without regtesting all gcc (I
tried: make -k check-gcc RUNTESTFLAGS=dg.exp=graphite/block-3.c without
success).
Try make -k check-gcc
1
/Volumes/MacBook/opt/gcc/i686-darwin/gcc/xgcc version 4.4.0 20090110
(experimental) [trunk revision 143247p1] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
The following (IMHO valid) code snippet is rejected on trunk:
==
struct A {};
auto foo() - struct A {}
==
bug.cc:2: error: redefinition of 'struct A'
bug.cc:1: error: previous definition of 'struct A'
bug.cc:2: error: expected initializer
When a namespace declares a function, and then uses another function with the
same name from a different namespace, the using declaration seems to hide the
function declaration. At least, when I define the function body later, the
comiler complains that the function wasn't declared in the
--- Comment #67 from reichelt at gcc dot gnu dot org 2009-01-10 22:37
---
Fixed by Janis' and Manuel's patches.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-10 22:47 ---
This is how it should behave.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rob1weld at aol dot com 2009-01-10 23:59 ---
(In reply to comment #1)
Is this still true in newer GCC releases? Also this was removed in 4.3 and
above.
Yes, on trunk. Searching for dupe before starting a new Bug Report, came here.
We might close this Bug with a
On Jan 10, 2009, at 3:59 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #3 from rob1weld at aol dot com 2009-01-10 23:59
---
(In reply to comment #1)
Is this still true in newer GCC releases? Also this was removed in
4.3 and
above.
Yes, on trunk.
--- Comment #4 from pinskia at gmail dot com 2009-01-11 00:11 ---
Subject: Re: Dist tarball is missing (Bison-generated) java/parse-scan.c
On Jan 10, 2009, at 3:59 PM, rob1weld at aol dot com
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #3 from rob1weld at aol dot com
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-01-11 01:29 ---
*** Bug 38793 has been marked as a duplicate of this bug. ***
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-01-11 01:29 ---
Again, the insn scheduling before reload permutes the insns of
the exit basic block like as:
;; ==
;; -- basic block 5 from 16 to 30 -- before reload
;;
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-11 01:56 ---
Coverage means -fprofile-arcs only while profiling means
-fprofile-generate/-fprofile-use. Coverage is only useful when you are looking
into GCC's sources to see what code is being used and how much.
Coverage is
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-11 02:04 ---
(In reply to comment #2)
(In reply to comment #1)
You can get an error via -pedantic-errors.
Agreed - but switching on that flag opens a whole can of worms.
Yes but then again as you said later on ...
--- Comment #5 from rob1weld at aol dot com 2009-01-11 02:50 ---
Breaks again here:
/usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/gcc_build/./prev-gcc/
-B/usr/local/i386-pc-solaris2.11/bin/ -c -g -O2 -fprofile-use -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes
When I type make -i -k distclean not all files are removed.
Each missed directory contains the config.status file which we would not
want to remain (and use to recreate the current configuration) through
using distclean.
# gmake -i -k distclean
gmake[1]: Entering directory
--- Comment #2 from rob1weld at aol dot com 2009-01-11 04:43 ---
(In reply to comment #1)
Coverage means -fprofile-arcs only while profiling means
-fprofile-generate/-fprofile-use. Coverage is only useful when you are
looking
into GCC's sources to see what code is being used and
--- Comment #11 from rob1weld at aol dot com 2009-01-11 04:50 ---
(In reply to comment #10)
3. There is a -Werror to be fixed. Use: i386.o-warn = -Wno-error
I already mentioned this was really fixed in trunk already.
I re-read this entire thread and still do not see your prior
--- Comment #2 from spop at gcc dot gnu dot org 2009-01-11 06:54 ---
Subject: Bug 38786
Author: spop
Date: Sun Jan 11 06:54:19 2009
New Revision: 143260
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143260
Log:
2009-01-11 Sebastian Pop sebastian@amd.com
PR
--- Comment #3 from spop at gcc dot gnu dot org 2009-01-11 06:55 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from irar at gcc dot gnu dot org 2009-01-11 07:40 ---
Subject: Bug 38529
Author: irar
Date: Sun Jan 11 07:39:47 2009
New Revision: 143262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143262
Log:
Backport from mainline:
2008-12-29 Dorit Nuzman
--- Comment #4 from irar at il dot ibm dot com 2009-01-11 07:48 ---
Fixed on 4.3 branch as well.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #13 from irar at gcc dot gnu dot org 2009-01-11 07:54 ---
Subject: Bug 37194
Author: irar
Date: Sun Jan 11 07:54:40 2009
New Revision: 143263
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143263
Log:
Backport from mainline:
2009-01-08 Ira Rosen
--- Comment #14 from irar at il dot ibm dot com 2009-01-11 07:57 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|REOPENED
73 matches
Mail list logo
