The attached program generates the expected output when compiled and run with
any of the gcc 3.x, gcc 4.0/4.1/4.2/4.3 compilers, but not with gcc 4.4. The
details are as follows:
* gcc version and configuration (built from unmodified GNU sources):
~/gcc-4.4.0/bin/gcc -v
Using built-in specs.
Targe
--- Comment #1 from bart dot vanassche at gmail dot com 2009-07-18 07:55
---
Created an attachment (id=18216)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18216&action=view)
Test case source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40795
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-18 08:55 ---
LIBRARY_PATH is not used by the linker.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-18 08:59 ---
But it doens't know it looks for a template function. It should display the
candidate list from which you can see what happens.
This is how name-lookup and overload resolution works...
--
rguenth at gcc dot gnu
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-18 09:15 ---
asm("movw %4, %%fs\n"
"movl %%esp, %0\n"
"pushw %%fs\n"
"movl %%esp, %1\n"
"popw %%fs\n"
"movl %%esp, %2\n"
"movw %%fs, %3\n"
: "=m" (sp1), "=m" (sp2), "=m" (sp3), "=m" (fs
--- Comment #3 from bart dot vanassche at gmail dot com 2009-07-18 09:28
---
Created an attachment (id=18217)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18217&action=view)
Test case source code
Added "esp" to constraint list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from bart dot vanassche at gmail dot com 2009-07-18 09:29
---
Same result with "esp" added to constraint list.
--
bart dot vanassche at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from jonathan dot sd24 at yahoo dot de 2009-07-18 10:02
---
When I explicitly specify the template-arguments g++ should know it.
And there was no candidate-list.
For example:
template
void staticPrint()
{
cout << t << endl;
}
Now I call:
staticPrint();
I get:
"no matc
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-18 10:07 ---
Use register input/output constraints. You can't take away esp from the
compiler.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
The attached code produces an error at runtime:
System:
Linux 2.6.27-gentoo-r8 x86_64 AMD Turion(tm) 64 Mobile Technology ML-32
AuthenticAMD GNU/Linux
$ gfortran bug.f90 -o bug
$ ./bug
*** glibc detected *** ./bug: double free or corruption (fasttop):
0x00603fb0 ***
=== Backtrace: =
--- Comment #13 from reichelt at gcc dot gnu dot org 2009-07-18 10:54
---
The objc++ isn't fixed yet, but this is not a regression.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-18 11:16 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-18 11:16 ---
Subject: Bug 40787
Author: rguenth
Date: Sat Jul 18 11:16:07 2009
New Revision: 149770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149770
Log:
2009-07-18 Richard Guenther
PR c/40787
*
--- Comment #6 from reichelt at gcc dot gnu dot org 2009-07-18 11:26
---
GCC's history with this code is:
* GCC 2.95.3 rejects
* GCC 3.0 - 3.2.3 accepts
* GCC 3.3 - 3.3.6 rejects
* GCC 3.4.0 - 4.3.x crashes
* GCC 4.4.0 - trunk accepts
Without the template, only GC
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-18 11:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from jason at gcc dot gnu dot org 2009-07-18 11:37 ---
But 'this' is local to the function as well, so I think the wording about
'this' can be interpreted in the light of the local variable wording to mean
that the testcase is ill-formed.
If, however, implementations agre
--- Comment #23 from david dot kirkby at onetel dot net 2009-07-18 14:36
---
(In reply to comment #22)
> (In reply to comment #20)
> > buf[n] = 6;
> > memset (buf+n, 0, i + j);
> > if (buf[0] != 6)
>
> It looks like you forgot to replace the second buf[0] by buf[n].
>
Sor
-optspace
Thread model: single
gcc version 4.5.0 20090718 (experimental) [trunk revision 149772] (GCC)
r...@ryan:~/gcc/trunk/gcc/sh4-build/gcc$ ./xgcc -B. -O ~/ice.i -c
/home/ryan/ice.i: In function 'ar5212GetTargetPowers':
/home/ryan/ice.i:56:1: internal compiler error: in df_refs_ver
--- Comment #1 from rmansfield at qnx dot com 2009-07-18 14:43 ---
Created an attachment (id=18218)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18218&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797
--- Comment #24 from david dot kirkby at onetel dot net 2009-07-18 14:44
---
I should have added, the core dumps were observed on gcc versions
3.4.3
4.2.4
4.4.0
4.4.1 20090715 (prerelease)
on the Sun T5240 with it's T2+ processors.
The success on the Sun Blade 2000 was only tried w
On Linux/x86-64, revision 149750:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00631.html
caused:
FAIL: gcc.dg/tree-ssa/loop-2.c scan-tree-dump-times optimized "99" 0
--
Summary: [4.5 Regression] Revision 149750 failed gcc.dg/tree-
ssa/loop-2.c
Product: g
Revision 149762 gave:
g++ -c -o AttributeListImpl.o -DSPEC_CPU -DNDEBUG -DAPP_NO_THREADS
-DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl
-Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
-DPROJ_XMLUTIL -DPRO
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-18 15:19 ---
Just a bogus pattern. I'll fix it up.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-18 15:29 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-18 15:29 ---
Subject: Bug 40798
Author: rguenth
Date: Sat Jul 18 15:29:21 2009
New Revision: 149774
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149774
Log:
2009-07-18 Richard Guenther
PR testsuite/40798
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-18 15:55 ---
Please attach preprocessed source as it seems to work for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40799
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-18 16:12 ---
Created an attachment (id=18219)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18219&action=view)
A testcase
It failed to compile at -O0, -O1, -O2, -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4079
--- Comment #3 from hjl dot tools at gmail dot com 2009-07-18 16:30 ---
Revision 149750 is the cause. Gcc is configured with
../src-trunk/configure --prefix=/export/gnu/import/svn/gcc-test/usr
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-langua
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-18 16:58 ---
Confirmed.
namespace Bar {
typedef int A;
};
class CollectionDeleteGuard {
public:
CollectionDeleteGuard(int);
};
CollectionDeleteGuard::CollectionDeleteGuard(int)
{
using Bar::A;
}
--
rguenth at gcc d
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-18 17:51 ---
I have a patch. But it looks like a possible can of worms ... :/
Well. In the end the plan is still to handle cloning by the cloning
infrastructure ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40799
gmake[3]: Entering directory `/usr/home/kargl/gcc/obj4x/libcpp'
source='../../gcc4x/libcpp/charset.c' object='charset.o' libtool=no
DEPDIR=.deps /bin/sh ../../gcc4x/libcpp/../depcomp gcc -I../../gcc4x/libcpp
-I. -I../../gcc4x/libcpp/../include -I./../intl -I../../gcc4x/libcpp/include
-g -fkeep-i
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
--- Comment #1 from kargl at gcc dot gnu dot org 2009-07-18 18:00 ---
This is caused by revision 149763
REMOVE:kargl[252] svn merge -r149763:149762 .
allows bootstrap to proceed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
--- Comment #2 from kargl at gcc dot gnu dot org 2009-07-18 18:09 ---
Note, I configure my build with
../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
The attached Fortran source fails to compile with the error message mentioned
in the summary.
Revision (4.5.0 experimental): 149775
Compile flags:
-g -c -O3 -ffast-math -fdefault-real-8 -fdefault-double-8
--
Summary: internal compiler error: in
vect_get_vec_def_
--- Comment #1 from toon at moene dot org 2009-07-18 18:28 ---
Created an attachment (id=18220)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18220&action=view)
Source code that elicits the error.
Not reduced (sorry).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40801
--- Comment #3 from jlquinn at optonline dot net 2009-07-18 18:52 ---
(In reply to comment #2)
> Note, I configure my build with
>
> ../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran
I can't reproduce the problem on my system. Can you recreate the bug? Then
attach l
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-18 19:15 ---
ODULE YOMPHY0
REAL :: ECMNP
REAL :: SCO
REAL :: USDMLT
END MODULE YOMPHY0
SUBROUTINE ACCONV ( KIDIA,KFDIA,KLON,KTDIA,KLEV,&
&CDLOCK)
USE YOMPHY0 , ONLY : ECMNP,SCO ,USDMLT
REAL :: PAPHIF
--- Comment #4 from kargl at gcc dot gnu dot org 2009-07-18 19:30 ---
Build fails also on x86_64-unknown-freebsd8.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
--- Comment #5 from kargl at gcc dot gnu dot org 2009-07-18 19:31 ---
Created an attachment (id=18221)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18221&action=view)
libcpp/Makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
--- Comment #6 from kargl at gcc dot gnu dot org 2009-07-18 19:31 ---
Created an attachment (id=18222)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18222&action=view)
libcpp/config.cache
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
--- Comment #7 from kargl at gcc dot gnu dot org 2009-07-18 19:32 ---
Created an attachment (id=18223)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18223&action=view)
libcpp/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
--- Comment #25 from david dot kirkby at onetel dot net 2009-07-18 19:33
---
(In reply to comment #24)
> I should have added, the core dumps were observed on gcc versions
>
> 3.4.3
> 4.2.4
> 4.4.0
> 4.4.1 20090715 (prerelease)
>
> on the Sun T5240 with it's T2+ processors.
>
> The
--- Comment #4 from wilson at gcc dot gnu dot org 2009-07-18 20:05 ---
> build/genmodes -h> tmp-modes.h
> /bin/sh: line 1: build/genmodes: No such file or directory
> make: *** [s-modes-h] Error 127
This is the error you can get when a program interpreter does not exist. More
recent l
--- Comment #8 from danglin at gcc dot gnu dot org 2009-07-18 20:09 ---
Also seen on hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from kargl at gcc dot gnu dot org 2009-07-18 20:11 ---
Created an attachment (id=18224)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18224&action=view)
Tail end of build log
Note the portion of the log that read
checking whether gcc supports -pedantic -Wno-long-lo
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-18 20:29 ---
> make: *** [s-modes-h] Error 127
it looks it segfaults. What is your host compiler version?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40706
--- Comment #2 from philippe at fornux dot com 2009-07-18 22:32 ---
Well if I set 'export GCC_EXEC_PATH=$HOME/lib' it works correctly.
Nevertheless perhaps LIBRARY_PATH should be passed to the linker if GCC is
responsible for the linkage.
--
philippe at fornux dot com changed:
--- Comment #4 from paolo at gcc dot gnu dot org 2009-07-18 22:58 ---
Subject: Bug 40712
Author: paolo
Date: Sat Jul 18 22:58:10 2009
New Revision: 149782
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149782
Log:
2009-07-18 Paolo Carlini
PR libstdc++/40712
*
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-18 23:05 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
This isn't new, I thought it might be a temporary problem, but it has lasted a
couple weeks. Latest SVN trunk (149763 or newer)
1.make[3]: Entering directory
`/home/peter/mount/GCC/gcc-trunk/build-win-149763-20090717/x86_64-w64-mingw32/libstdc++-v3'
2.Making all in include
3.make[4]: Entering dire
--- Comment #1 from xenofears at gmail dot com 2009-07-19 03:55 ---
That should say **WIN64 HOST**. My Apologies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40802
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-07-19 04:53 ---
A bit smaller test case:
typedef struct str { short x, y;} S;
static short
bar (short ch, short sl, short sr, short tl, short tr)
{
return 0;
}
void
foo (short ch, S *pi, short nc, S *po)
{
short clo, chi, lo,
--- Comment #10 from jlquinn at optonline dot net 2009-07-19 05:09 ---
(In reply to comment #9)
> Looks like the configure is broken.
One thing I can see from the log is that configure is acting as if
ENABLE_BUILD_WITH_CXX is enabled. Can you try the following patch on
libcpp/configure
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2009-07-19 05:30 ---
Subject: Re: libcpp breaks bootstrap
On Sun, Jul 19, 2009 at 05:09:31AM -, jlquinn at optonline dot net wrote:
>
>
> --- Comment #10 from jlquinn at optonline dot net 2009-07-19 05:09
Feel free to disregard as this was a buildworld error of freeBSD 7.2 it may
mean nothing or most likely should be directed to the owner of s_fma.c or
is a stupid user error on my part.
The machine is a ibm quad xeon x366, 32GB RAM.
cc -m32 -march=nocona -mfancy-math-387 -DCOMPAT_32BIT -ipre
56 matches
Mail list logo
