--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-10 07:45 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00117.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34396
--- Comment #7 from ubizjak at gmail dot com 2008-01-10 07:01 ---
(In reply to comment #6)
> Uros, the testcase (gcc.target/i386/cmov7.c) fails on x86 with -fpic/-fPIC.
> Real bug, or skip with pic?
No, but insn RTX costs is slightly increased for -fpic. From ix86_rtx_cost():
--cut he
--- Comment #3 from pcarlini at suse dot de 2008-01-10 02:15 ---
All conforming compilers must reject this, in strict mode. See the 3.4 release
notes for more details: http://gcc.gnu.org/gcc-3.4/changes.html
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #2 from isenbaev at gmail dot com 2008-01-10 01:20 ---
Sorry there was a missprint in a test code, here is a correct example:
template
class A
{
public:
T x;
};
template
class B : public A
{
public:
void clear()
{
x = 0;
}
};
--- Comment #4 from tom at software6 dot net 2008-01-10 01:04 ---
Subject: Re: Unrecognized opcode: `lwsync' when compiling gcc 4.2.2 on a 7457
Great. Thank you. Sorry I missed that in the docs.
-Tom
On 10 Jan 2008 00:59:35 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> w
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-10 00:59 ---
(In reply to comment #2)
> [EMAIL PROTECTED] tvaughan]$ as --version
> GNU assembler 2.13.90.0.18 20030206
This binutils is just too old. You should update it.
>From http://gcc.gnu.org/install/specific.html#powerpc
--- Comment #2 from tom at software6 dot net 2008-01-10 00:54 ---
Subject: Re: Unrecognized opcode: `lwsync' when compiling gcc 4.2.2 on a 7457
[EMAIL PROTECTED] tvaughan]$ rpm -qf `which as`
binutils-2.13.90.0.18-6
[EMAIL PROTECTED] tvaughan]$ as --version
GNU assembler 2.13.90.0.18 2
--- Comment #13 from spop at gcc dot gnu dot org 2008-01-10 00:09 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to
optimize code
For fixing this bug, one option is to disable symbolic propagations,
as in the patchlet that I sent before, and also in the DOM p
--- Comment #8 from jakub at gcc dot gnu dot org 2008-01-10 00:00 ---
Patch which cures this:
--- gcc/tree-inline.c.jj2008-01-04 00:53:03.0 +0100
+++ gcc/tree-inline.c 2008-01-10 00:48:07.0 +0100
@@ -700,7 +700,30 @@ copy_body_r (tree *tp, int *walk_subtree
--- Comment #21 from steven at gcc dot gnu dot org 2008-01-09 22:46 ---
at cse.c:5418:
elt = insert (dest, sets[i].src_elt,
sets[i].dest_hash, GET_MODE (dest));
dest = (reg:DI 66 [ type.0+-4 ])
sets[i].src_elt->exp = (sign_extend:DI (reg:SI 72 [ type ]))
se
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-01-09 22:45 ---
(In reply to comment #7)
> Testing of stuff like kprobes in Linux would be a lot easier if nolinline
> worked reliably. See this thread, for example:
> http://marc.info/?l=linux-kernel&m=119991179332571&w=2
This fu
--- Comment #7 from jkenisto at us dot ibm dot com 2008-01-09 22:35 ---
Testing of stuff like kprobes in Linux would be a lot easier if nolinline
worked reliably. See this thread, for example:
http://marc.info/?l=linux-kernel&m=119991179332571&w=2
BTW, this sort of noinline failure can
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-09 22:17 ---
Yeah. We have to make the binaries where we do. They rely on the
libraries we just built.
I suppose we could try to make a bin64 or whatever.
That sounds like a lot of work.
Maybe we could disable the executables
--- Comment #4 from rguenther at suse dot de 2008-01-09 22:14 ---
Subject: Re: [4.2/4.3 regression] gij is built as 32-bit
binary when building multilib gcc
On Wed, 9 Jan 2008, tromey at gcc dot gnu dot org wrote:
> --- Comment #3 from tromey at gcc dot gnu dot org 2008-01-09 22
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-09 22:03 ---
What should we do here?
I think the problem is that we have a single bindir, but we are
building multiple executables -- one per multilib.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from spop at gcc dot gnu dot org 2008-01-09 21:23 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from spop at gcc dot gnu dot org 2008-01-09 21:23 ---
Subject: Bug 34017
Author: spop
Date: Wed Jan 9 21:22:19 2008
New Revision: 131435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131435
Log:
2008-01-09 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-opt
--- Comment #17 from zadeck at naturalbridge dot com 2008-01-09 20:49
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
ghazi at gcc dot gnu dot org wrote:
> --- Comment #16 from ghazi at gcc dot gnu dot org 2008-01-09 18:42
>
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-09 20:36 ---
Reduced testcase, ICEs on a x86_64 -> hppa-linux cross with -O2.
typedef bool Bool;
struct CString {
CString (const char * =__null);
CString & operator += (const CString &);
};
struct THotKey {
short Key;
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-09 19:44 ---
ISO C99, 6.3.10, paragraph 11 contains:
"If there are sequences of preprocessing tokens within the list of arguments
that would otherwise act as preprocessing directives, the behavior is
undefined."
GCC 3.2.x had:
--- Comment #8 from uweigand at gcc dot gnu dot org 2008-01-09 19:23
---
This is a long-standing problem in gen_reload. This routine fundamentally
assumes that every PLUS expression that describes a legitimate address can
be reloaded into a register without requiring any additional scr
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-09 19:20
---
Subject: Bug 34708
Author: hubicka
Date: Wed Jan 9 19:19:40 2008
New Revision: 131433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131433
Log:
PR tree-optimization/34708
* tree-inline.c
--- Comment #1 from wilson at gcc dot gnu dot org 2008-01-09 19:11 ---
This is the same problem as PR 31684, which is fixed on mainline (pre-release
gcc-4.3) but not on the gcc-4.2 branch.
*** This bug has been marked as a duplicate of 31684 ***
--
wilson at gcc dot gnu dot org chan
--- Comment #8 from wilson at gcc dot gnu dot org 2008-01-09 19:11 ---
*** Bug 34266 has been marked as a duplicate of this bug. ***
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from steven at gcc dot gnu dot org 2008-01-09 19:09 ---
I still haven't been able to reproduce it with a cross and with the original
test case. I'll try the reduced test case. Wish me luck. ;)
--
steven at gcc dot gnu dot org changed:
What|Removed
=c --enable-checking=release --with-gmp=/pkgs/gmp-4.2.2
--with-mpfr=/pkgs/gmp-4.2.2 --enable-gather-detailed-mem-stats
Thread model: posix
gcc version 4.3.0 20080109 (experimental) [trunk revision 131427] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #16 from ghazi at gcc dot gnu dot org 2008-01-09 18:42 ---
Ken - Your testcase (gcc.dg/pr33826.c) fails on i686 with -fpic/-fpic. If I
make the definitions static, it doesn't seem to help. Real bug, or skip with
pic?
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00366.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-09 18:30 ---
What binutils version do you have? It might be that it is just too old and you
need to update it.
To get the version do:
as --version
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34728
This is Yellowdog 3 and Linux 2.4. I've previously built and installed gcc
4.1.1 which has worked well for years. But I've recently had a need to build
and install gdb 6.7.1. But that had problems building (the details now
forgotten). And so as a stab in the dark I am now trying to build and instal
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-01-09 18:25 ---
Uros, the testcase (gcc.target/i386/cmov7.c) fails on x86 with -fpic/-fPIC.
Real bug, or skip with pic?
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00366.html
--
ghazi at gcc dot gnu dot org changed:
--- Comment #1 from janis at gcc dot gnu dot org 2008-01-09 18:20 ---
Despite what the archived test results show, regression hunts using cross
cc1plus on powerpc-linux show that the test starts failing for all tested
powerpc and arm targets (the four listed in the submitter's descriptio
--- Comment #13 from ghazi at gcc dot gnu dot org 2008-01-09 18:13 ---
This testcase has an execution failure on i686-pc-linux-gnu when using
-fpic/-fPIC.
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00366.html
--
ghazi at gcc dot gnu dot org changed:
What|Remove
--- Comment #2 from johill at lanl dot gov 2008-01-09 17:37 ---
Subject: RE: reference data template args appear to be broken in 4.2.1 ?
You conclusion is correct. Sorry about false alarm
> -Original Message-
> From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
> S
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-09 17:19 ---
>x = src.x;
x is not dependent so it has to be found at the time of definition and cannot
be found in the dependent parent class.
--
pinskia at gcc dot gnu dot org changed:
What|R
the following code fails to compile with gcc-3.4.6, gcc-4.1.3 and gcc-4.2.1
test.cpp: In member function `point<3, T>& point<3, T>::operator=(const
point<3, T>&)':
test.cpp:25: error: `x' was not declared in this scope
template
class point
{
};
template
class point<1, T>
{
public:
T x;
the following code fails on all g++ versions I have:
test.cpp:9: error: explicit specialization in non-namespace scope class A
template
class A
{
template
class B
{
};
template<>
class B
{
};
};
but works fine with fictive templ
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-09 16:43 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34651
e-shared
Thread model: win32
gcc version 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)
$ gfortran.exe a.f90 && ./a.exe
7.
I am building with mingw-3.13: if you have older than that, you need to
upgrade; if you have mingw-3.14, then it's a regression and
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-01-09 16:34
---
Will take a look.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-09 16:31 ---
(gdb) up
#1 0x00cf4cf2 in set_value_range (vr=0x7fff3e9f5f70, t=VR_RANGE,
min=0x2adb6c10ea80, max=0x2adb6ed76510, equiv=0x18ac910)
at /space/rguenther/src/svn/trunk/gcc/tree-vrp.c:321
321
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-09 15:53 ---
> D.862 = (integer(kind=4)) t;
> D.863 = _gfortran_selected_int_kind (&D.862);
D.862 is not a gimple register so it should have not a non expression in the
assignment.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-09 15:51 ---
So, what is wrong with
MAIN__ ()
{
integer(kind=4) D.862;
integer(kind=4) D.863;
real(kind=4) res;
real(kind=4) t;
static integer(kind=4) options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options (
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-09 15:58 ---
>(which is unchanged by the patch for PR30142).
I think you mean PR30132, and the original patch for that PR which did:
(gimplify_addr_expr): Create one more extra variable if we have a
temp decl.
Fixed the
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-09 15:57 ---
If I enable the call to decode_statement in decode_statement (parse.c), it
shows:
SUBROUTINE INVENTNAMES()
1
Interner Fehler bei (1):
Symbol changes still pending!
The pending symbol is "@iostat". If one
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-09 15:56 ---
Trying someone else - Eric, any clue about post-increment?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from jakub at gcc dot gnu dot org 2008-01-09 15:55 ---
Actually, marking the edges as EDGE_ABNORMAL in make_edges and clearing that
flag during expand_omp_for time seems to work, so perhaps we can do it that
way. expand_omp happens before going into SSA, so this won't ca
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-09 15:47
---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-09 15:47
---
Subject: Bug 30132
Author: rguenth
Date: Wed Jan 9 15:46:49 2008
New Revision: 131430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131430
Log:
2008-01-09 Richard Guenther <[EMAIL PROTECTED]>
A
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-09 15:36
---
(reg:DI 66 [ type.0+-4 ]) is entered twice in the table. During flushing we
hit:
Breakpoint 5, flush_hash_table ()
at /space/rguenther/src/svn/trunk/gcc/cse.c:1634
1634if (REG_P (p->exp))
(reg:DI
Hello,
Configuration script gcc-4.2.2/gcc/configure returns an error
"/home/unix/gcc-4.2.2/gcc/configure[14029]: assembler: unknown test operator"
when trying to determine assembler version
In binutils-2.18
as --version
returns
"GNU assembler (GNU Binutils) 2.18" (not "GNU assembler 2.18")
In
--- Comment #9 from jakub at gcc dot gnu dot org 2008-01-09 15:05 ---
I've tried to change expand_omp_for_{generic,static_nochunk,static_chunk}
to grok the possibly split edges if profile_arc_flag, but it pretty quickly
gets horribly ugly. Several edges are removed, split or tweaked by
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-09 15:04 ---
IMHO this shouldn't be P1, IMA is too obscure for that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
Any application that uses libgcrypt 1.4.0 (including the parts of "make check"
in libgcrypt) segfaults if libgcrypt was built with gcc 4.3 (svn 131213) and
the CFLAGS setting includes "-O1 [or higher] -mtune=i686 -fomit-frame-pointer"
gdb shows the crash occurs in detect_ia32_gnuc() (defined in sr
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-09 14:45
---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassign
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-09 14:18
---
Subject: Bug 34458
Author: rguenth
Date: Wed Jan 9 14:17:13 2008
New Revision: 131429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131429
Log:
2008-01-09 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-09 14:18
---
Subject: Bug 34458
Author: rguenth
Date: Wed Jan 9 14:17:13 2008
New Revision: 131429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131429
Log:
2008-01-09 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-09 13:49 ---
This is a code generation difference due to a design choice. IMHO this should
not be a P2 regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-09 13:43 ---
Subject: Bug 34679
Author: rguenth
Date: Wed Jan 9 13:43:03 2008
New Revision: 131427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131427
Log:
2008-01-09 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-09 12:45
---
Can we have updated measurements please? Also I don't think this bug should be
P1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-09 12:26 ---
> I think it occurred between 2007-10-13-r129280 and 2007-10-15-r129311 ...
Revision 129309?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-09 12:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-09 12:14 ---
Subject: Bug 34679
Author: rguenth
Date: Wed Jan 9 12:14:01 2008
New Revision: 131425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131425
Log:
2008-01-09 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-09 12:13 ---
I think it occurred between 2007-10-13-r129280 and 2007-10-15-r129311, plus
minus a few days as my tree had probably some patches installed, which might
have caused this.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #1 from lo at meep dot co dot uk 2008-01-09 11:42 ---
In addition, the following code fails with:
try.h: In function int main():
try.h:9: sorry, unimplemented: inlining failed in call to const T&
X::min(const T&, const T&) [with T = int]: function not inlinable
y.cpp:5:
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-09 11:04
---
I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2008-01-09 11:02
---
> It seems that this should work too: bitsize is 8 in this example IIRC, so
> copy_mode would be byte_mode, which is what we need here. Additionally
> using word_mode when we can seems worthwhile too.
OK, thank
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-09 10:38
---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
S
--
pcarlini at suse dot de changed:
What|Removed |Added
Keywords||accepts-invalid
Priority|P3 |P4
http://
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-09 10:35 ---
Caused by the fix for PR32563 btw.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
O
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-09 10:34
---
Subject: Bug 26364
Author: rguenth
Date: Wed Jan 9 10:33:55 2008
New Revision: 131423
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131423
Log:
2008-01-09 Steven Bosscher <[EMAIL PROTECTED]>
P
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-09 10:34 ---
I have a different patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
A
Hi. The below is accepted by GCC and rejected by ICC. It's consistently
rejected if I remove any trace of namespace detail:
namespace detail
{
template
class one;
template
class one;
}
template
class two
{
template
friend class detail::one;
int num;
};
namespace detail
--- Comment #18 from matz at gcc dot gnu dot org 2008-01-09 10:32 ---
It seems that this should work too: bitsize is 8 in this example IIRC, so
copy_mode would be byte_mode, which is what we need here. Additionally using
word_mode when we can seems worthwhile too.
One thing would bothe
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-09 10:11 ---
Further reduced test case:
PROGRAM GAMSANAL
IMPLICIT NONE
character :: tmp
INTEGER IODICT
LOGICAL DICEXIST
INQUIRE(UNIT=IODICT, EXIST=DICEXIST)
end
SUBROUTINE INVENTNAMES()
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2008-01-06 00:36:29 |2008-01-09 09:56:0
--- Comment #37 from rguenther at suse dot de 2008-01-09 09:45 ---
Subject: Re: [4.3 Regression] Fortran FE
generated IL pessimizes middle-end IL and analysis
On Wed, 9 Jan 2008, jaydub66 at gmail dot com wrote:
> --- Comment #36 from jaydub66 at gmail dot com 2008-01-09 09:38 -
--- Comment #36 from jaydub66 at gmail dot com 2008-01-09 09:38 ---
> How does the trunk compare now to the numbers mentioned in comment #16 ?
Compiling with rev. 131414 gives:
-O1 -fstrict-aliasing: 33sec, 438197 kB
-O2: 97sec, 669637 kB
-O3: 50sec
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-09 08:50 ---
So 4.2's jump threading used to mess up the loop (and copy the first iteration)
and cause code size issues so it was removed for 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723
--- Comment #5 from ubizjak at gmail dot com 2008-01-09 08:33 ---
-> PR tree-optimization/34723
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Mileston
This testcase:
--cut here--
char table[256];
int test(void) {
char val = 0;
int i;
for (i = 0; i < 10; i++)
val += table[i];
return val;
}
--cut here--
compiles using gcc-4.2 -O2 to:
test:
movzbl table, %eax
movl$1, %edx
.p2align 4,,7
.L2:
add
--- Comment #4 from ubizjak at gmail dot com 2008-01-09 08:23 ---
The problem with char moves is fixed in current SVN.
The problem with loop header from comment #3 is tree-optimization problem, I'll
open new PR for it.
--
ubizjak at gmail dot com changed:
What|Remove
--- Comment #3 from sebpop at gmail dot com 2008-01-09 08:08 ---
Subject: Re: [4.3 Regression] ICE: tree check: expected integer_type, have
enumeral_type in host_integerp, at tree.c:4949 (predictive commoning)
Patch http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00344.html
--
http:/
Patch http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00344.html
84 matches
Mail list logo
