The following program is presumably invalid (I have not checked the standard).
ifort and sunf95 reject it with:
warning #6755: A COMMON block data object may not have the SAVE attribute.
ERROR: Object I2 has the SAVE attribute, so it must not be equivalenced to an
object in a common block.
Ad
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-19 10:12
---
Subject: Bug 39207
Author: rguenth
Date: Thu Feb 19 10:12:25 2009
New Revision: 144292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144292
Log:
2009-02-19 Richard Guenther rguent...@suse.de
PR
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-02-19 10:13
---
Fixed on the trunk as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from uros at gcc dot gnu dot org 2009-02-19 10:51 ---
Subject: Bug 39228
Author: uros
Date: Thu Feb 19 10:51:04 2009
New Revision: 144293
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144293
Log:
PR target/39228
* config/i386/i386.md (isinfxf2):
extern void abort (void);
__attribute__ ((noinline))
static int foo1 (int x)
{
return x;
}
__attribute__ ((noinline))
unsigned int bar1 (int x)
{
return foo1 (x + 6);
}
unsigned long l1 = (unsigned int) -4;
__attribute__ ((noinline))
static short int foo2 (int x)
{
return x;
}
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-19 11:16 ---
Ah, it is a regression from 3.4.x.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
ICEs with -O[123s], likely due to the VIEW_CONVERT_EXPR we construct from
*((int*)f) after inlining.
struct FTprocCompressor {
float * _amp;
float * _env;
float * _as;
};
static inline int f_round(float f)
{
return *((int*)f) - 0x4b40;
}
void process (struct FTprocCompressor
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
--- Comment #5 from francois at b-powers dot be 2009-02-19 13:10 ---
Any update on this bug ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38479
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-19 13:16 ---
Reduced testcase:
static inline int
foo (float f)
{
return *((int *) f) - 1;
}
float
bar (float x, float y, float *z)
{
float c = y 0.002f ? 0.002f : y;
float d = x c ? c : x;
return z[foo (c)] + z[foo (d *
With -O0 the following is accepted, with -O1 it is rejected with
Parser.3.ii: In member function void RepPtrStore_Tp, _Bt::_assign(_Tp*)
[with _Tp = YStatement, _Bt = YCode]:
Parser.3.ii:11: instantiated from RepPtrStore_Tp, _Bt::~RepPtrStore()
[with _Tp = YStatement, _Bt = YCode]
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-19 13:40 ---
Created an attachment (id=17329)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17329action=view)
original testcase
Original testcase from Yast YCP. Requires -std=c++0x.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
--- Comment #2 from ixt at nm dot ru 2009-02-19 13:44 ---
Testing sample with gcc-4.3.3 (released after 2009-01-02 12:06) also fail:
sergeyhost:/tmp$ cat ./main.c
#include mmintrin.h
void foo()
{
_mm_srli_pi16(_mm_setzero_si64(), 8);
}
sergeyhost:/tmp$
sergeyhost:/tmp$
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-19 13:46 ---
Randomly poking around the tree shows
Index: cp/ChangeLog
===
--- cp/ChangeLog(revision 138149)
+++ cp/ChangeLog(revision 138150)
@@
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-19 13:50 ---
The error is that RepPtrStoreYStatement,YCode::assign is instantiated at all
in face of extern template class RepPtrStoreYStatement,YCode;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-02-19 13:56 ---
Subject: Bug 38483
Author: jsm28
Date: Thu Feb 19 13:56:00 2009
New Revision: 144296
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144296
Log:
PR c/38483
* builtins.c (gimplify_va_arg_expr):
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-02-19 13:56 ---
Fixed for 4.4.0.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-19 14:19 ---
This fixes it for me:
Index: decl2.c
===
--- decl2.c (revision 144292)
+++ decl2.c (working copy)
@@ -3755,7 +3755,8 @@ bool
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-19 14:30 ---
Or rather we don't want template instantiation (and errors from it) to differ
from optimized to non-optimized build. So,
Index: cp/pt.c
===
---
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-19 14:51 ---
Note that in the original testcase YStatement is incomplete, but properly
derives from Rep in the TU with the explicit instantiation of
RepPtrStoreYStatement,YCode.
Instead of not instantiating so much we could
--- Comment #7 from danglin at gcc dot gnu dot org 2009-02-19 14:52 ---
Reconfirmed with trunk revision 144268.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from danglin at gcc dot gnu dot org 2009-02-19 14:58 ---
Confirmed with:
-bash-3.2$ ../../xgcc -B../../ -v
Reading specs from ../../specs
Target: arm-none-linux-gnueabi
Configured with: ../gcc/configure --host=arm-none-linux-gnueabi
--target=arm-none-linux-gnueabi
--- Comment #7 from hubicka at ucw dot cz 2009-02-19 14:59 ---
Subject: Re: [4.4 Regression] Inconsistent reject / accept of code
Index: cp/pt.c
===
--- cp/pt.c (revision 144292)
+++ cp/pt.c (working copy)
@@
I create this simple program:
#include iostream
#include locale
#include clocale
#include cstdio
using namespace std;
int main()
{
locale loc(ru_RU.UTF-8);
cout.imbue(loc);
cout 1234.56 std::endl;
setlocale(LC_NUMERIC, ru_RU.UTF-8);
printf(%'.2f\n, 1234.56);
return
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-19 15:20 ---
Note that the patch only affects extern explicit template instantiations.
/* Check to see whether we know that this template will be
instantiated in some other file, as with extern template
extension.
--- Comment #4 from hjl at gcc dot gnu dot org 2009-02-19 15:22 ---
Subject: Bug 39188
Author: hjl
Date: Thu Feb 19 15:22:28 2009
New Revision: 144297
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144297
Log:
gcc/
2009-02-19 H.J. Lu hongjiu...@intel.com
PR c++/39188
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-19 15:37 ---
I now asked at c.l.f but so far there was no direct pointer to the standard.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/695d799c2e81b1b3
I think (in line with the replies in c.l.f) that
--- Comment #9 from hubicka at ucw dot cz 2009-02-19 15:40 ---
Subject: Re: [4.4 Regression] Inconsistent reject / accept of code
/* Check to see whether we know that this template will be
instantiated in some other file, as with extern template
extension. */
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-19 15:44 ---
It is caused by revision 138804:
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00363.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Various cleanup and other exception related tests fail:
FAIL: gcc.dg/cleanup-10.c execution test
FAIL: gcc.dg/cleanup-11.c execution test
FAIL: gcc.dg/cleanup-8.c execution test
FAIL: gcc.dg/cleanup-9.c execution test
FAIL: g++.dg/ext/cleanup-10.C execution test
FAIL: g++.dg/ext/cleanup-11.C
--- Comment #1 from danglin at gcc dot gnu dot org 2009-02-19 16:06 ---
(gdb) p i
$6 = 4
(gdb) p/x mask
$8 = 0x4ff0
(gdb) p/x ((phase1_vrs *)context)-core.r
$11 = {0x0, 0x0, 0xe, 0x817, 0x0, 0x0, 0xbee108d4, 0x0, 0x0, 0x861c, 0x0,
0x84bc, 0x0, 0x1c, 0x0, 0x40025000}
R_SP is 13. So,
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/memcpy-1.c -O2
-fdump-tree-
optimized -S -o memcpy-1.s(timeout = 300)
PASS: gcc.dg/memcpy-1.c (test for excess errors)
FAIL: gcc.dg/memcpy-1.c
--- Comment #10 from mark at codesourcery dot com 2009-02-19 16:41 ---
Subject: Re: [4.4 Regression] Inconsistent reject / accept
of code
rguenth at gcc dot gnu dot org wrote:
The ultimate question is of course if the standard allows (or even requires)
an error here.
The (someone
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c -O
-Wuninitiali
zed -S -o uninit-13.s(timeout = 300)
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-13.c: In function 'foo':
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c -O2
-f
reorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -lm -o
/home/dave/g
nu/gcc/objdir/gcc/testsuite/gcc/bb-reorg.x02
--- Comment #1 from dominiq at lps dot ens dot fr 2009-02-19 16:52 ---
Fails also on powerpc-apple-darwin* since at least revision 132577, see for
instance:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01742.html
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01095.html
The test
--- Comment #11 from rguenther at suse dot de 2009-02-19 16:54 ---
Subject: Re: [4.4 Regression] Inconsistent reject / accept
of code
On Thu, 19 Feb 2009, mark at codesourcery dot com wrote:
--- Comment #10 from mark at codesourcery dot com 2009-02-19 16:41
---
Subject:
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/vect/vect-complex-1.c
-ftre
e-vectorize -fno-vect-cost-model -mfpu=neon -mfloat-abi=softfp -O2
-fdump-tree-v
ect-details -S -o vect-complex-1.s(timeout = 300)
--
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
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19
17:19 ---
Subject: Re: New: FAIL:
gcc.dg/vect/vect-complex-1.c
Attached vect-complex-1.c.101t.vect.
Dave
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19
17:19 ---
Created
--- Comment #3 from danglin at gcc dot gnu dot org 2009-02-19 17:37 ---
gcc.dg/vect/slp-7.c has a similar failure:
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/vect/slp-7.c
-ftree-vectori
ze
--- Comment #12 from jason at gcc dot gnu dot org 2009-02-19 17:39 ---
(In reply to comment #10)
What that means is that we *must not* implicitly instantiate things
declared extern template unless they are DECL_DECLARED_INLINE_P. As a
consequence, at -O3, we cannot implicitly
Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/home
/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/testsui
te/g++.dg/ipa/iinline-1.C -nostdinc++
-I/home/dave/gnu/gcc/objdir/arm-none-linu
x-gnueabi/libstdc++-v3/include/arm-none-linux-gnueabi
Multiplying an unsigned char by 64U produces bigger slower code than necessary.
avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 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
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-19
18:19 ---
Subject: Re: New: FAIL:
g++.dg/ipa/iinline-1.C scan-ipa-dump inline
String::funcOne[^\n]*inline copy in int main
Attached iinline-1.C.042i.inline.
Dave
--- Comment #2 from dave at
Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/home
/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/testsui
te/g++.dg/tree-ssa/new1.C -nostdinc++
-I/home/dave/gnu/gcc/objdir/arm-none-linu
x-gnueabi/libstdc++-v3/include/arm-none-linux-gnueabi
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-19 19:57 ---
*** Bug 39210 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2009-02-19 19:57 ---
Indeed the same issue.
*** This bug has been marked as a duplicate of 36439 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
In the Linux kernel, we use assembly constructs (asm volatile) which trap or
otherwise terminate execution. gcc doesn't know about this, so it doesn't
terminate its flow analysis. These assembly constructs are more complex than a
simple __builtin_trap(); will permit -- we have tried using
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||hjl dot tools at gmail dot
|
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-19 20:51 ---
So __builtin_not_reached is just __builtin_trap which doesn't generate
any insn. It shouldn't be too hard to implement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
--- Comment #1 from joseph at codesourcery dot com 2009-02-19 21:11 ---
Subject: Re: New: FAIL: gcc.dg/tree-prof/bb-reorg.c
compilation, -fprofile-use -D_PROFILE_USE
The ARM constant pool code needs to handle a
NOTE_INSN_SWITCH_TEXT_SECTIONS note in some way as indicating insns on
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-19 21:15 ---
Subject: Bug 39175
Author: jakub
Date: Thu Feb 19 21:15:12 2009
New Revision: 144305
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144305
Log:
PR target/39175
* c-common.c
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-19 21:16 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #3 from aran at 100acres dot us 2009-02-19 21:46 ---
Created an attachment (id=17333)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17333action=view)
Removes gcc's version of both stddef.h and sys/types.h
This patch removes gcc's version of stddef.h and the fixed
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-19 21:50 ---
Why again is __builtin_trap not useful for this purpose? You mention about
assembly constructs but why not instead implement those as builtins instead
of providing something which really can be abused?
--
--- Comment #3 from hpa at zytor dot com 2009-02-19 21:58 ---
Two reasons:
1. We have no control over what instruction __builtin_trap() will generate.
2. We require the address of the faulting instruction.
In particular, we currently have a construct which looks like:
#ifdef
--- Comment #2 from ubizjak at gmail dot com 2009-02-19 22:13 ---
Just add -fomit-frame-pointer to dg-options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38164
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-19 22:14 ---
Still you can make a builtin that does that. Even if it is a target builtin.
I think of having a target builtin is better than creating a generic
__builtin_not_reached.
--
--- Comment #5 from hpa at zytor dot com 2009-02-19 22:21 ---
Let me respectfully disagree, and explain why.
*You* can just create a builtin, but for us (the Linux kernel community) we
stare a multi-year pipeline in the face whenever we have to request a gcc
change. This feature would
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-19 22:29 ---
Glan found the relevant part (see link above for more):
In 5.5.2.1: Data objects associated with an entity in a common
block are considered to be in that common block.
* * *
BIND(C) in equivalence is
--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-19 23:02 ---
Wouldn't be a special noreturn clobber in inline asm better suited for this
then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
--- Comment #4 from rob1weld at aol dot com 2009-02-20 00:57 ---
(In reply to comment #3)
Even though I ./configured using --with-gnu-ld --with-ld=/usr/local/bin/ld
the scripts seemed to have decided to use the gcc-used-for-build's choice
of 'ld' instead of the main ./configure
--- Comment #3 from rob1weld at aol dot com 2009-02-20 01:02 ---
A workaround is to copy '../gcc_trunk/libjava/classpath/mkinstalldirs'
into the same directory as 'copy-vmresources.sh' so it can find it.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39161
--- Comment #10 from rob1weld at aol dot com 2009-02-20 01:13 ---
(In reply to comment #9)
(In reply to comment #8)
using Sun's Linker (and GNU assembler version 2.19).
After this patch is tested, approved, applied to trunk, and re-tested, then
this Bug will be fixed.
Adding
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-20 01:21 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00937.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-20 01:58 ---
The updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00939.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from regehr at cs dot utah dot edu 2009-02-20 03:32 ---
Created an attachment (id=17334)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17334action=view)
failure-inducing C program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39232
--- Comment #3 from regehr at cs dot utah dot edu 2009-02-20 03:44 ---
Created an attachment (id=17335)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17335action=view)
diff between broken and working assembly
This is a diff between the attachment compiled at -O0 and the same
--- Comment #7 from hpa at zytor dot com 2009-02-20 04:34 ---
A noreturn clobber would work just as well, obviously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
This is my first report at gcc Bugzilla...
I tried to compile a fortran program that invokes QD library (multiprecision
arithmetic, available at
http://www.cs.berkeley.edu/~yozo/software/qd-2.3.7.tar.gz). When I use Intel
compiler suite, everything is fine. If I switch to gcc (the performance of
--- Comment #8 from jason at gcc dot gnu dot org 2009-02-20 05:32 ---
Subject: Bug 39225
Author: jason
Date: Fri Feb 20 05:32:40 2009
New Revision: 144314
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144314
Log:
PR c++/39225
* decl.c (grokdeclarator): Handle
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-20 05:33 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-20 05:34 ---
New patch at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01309.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-20 05:35 ---
Er, not that one, this one:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00882.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-20 05:37
---
I think 4.3 branch is still broken.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2009-02-20 05:38 ---
Yes, i is bound to this-i, which I believe is perfectly valid. The
section of the standard that says that default arguments can't refer to this
means that default arguments of member functions can't refer to their
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-20 07:00 ---
Thanks for the report. However, GCC/gfortran 4.1.0 is quite old. (GCC 4.0.0 was
the first version which contained gfortran, which was at that time very buggy.
Version 4.1.x was quite usable, but still contained a few
79 matches
Mail list logo
