Re: Using inline assembly with specific register indices
Ok about the r convention I wrongfully used, it is assumed for the integer register-file. Correct. I am currently using MIPS + soft-float + some other functionalities in Coprocessor #2 with success (somewhat tested in a functional simulator). About 10-12 special-purpose instructions are implemented in COP2 plus the ctc2,cfc2,... etc instructions that are detailed in the MIPS ISA documents. All added instructions are faithful to the COP2 convention (6-bit opcode + 26 implementation specific bits). OK. I have used Matt Hiller's patch on binutils, for supporting coprocessor register names, which was uploaded at gcc-patch ml circa June 2002. It works, at least for the things I have used it. Actually the patch doesn't correspond exactly to either versions 2.13,2.14 or 2.15 but to some CVS snapshot (I suppose). Correct. CVS as of the day it was submitted. My question on the usage of inline assembly regards omitting writing long jump tables (e.g. with nested switches). This is not usually necessary but it is when dealing with dynamic code generation. I'm not sure what the question is here. Plus: can gcc co-operate with dynamic code generation tools e.g. the GNU lightning? I have also heard of another tool, dcg (if i spell it correctly). I've not done any of this. -eric
RE: Trying to build crosscompiler for Sparc Solaris 8 - SparcSolaris 10 ( others)...
Original Message From: Aaron Gaudio Sent: 05 April 2005 21:05 (CCing this to [EMAIL PROTECTED] due to potential build bugs...) I have already installed binutils 2.15 and gcc 3.4.5 native Solaris 8 verisons in the prefix /vobs/java/gnu and added this directory to my path, so that those are the tools being used for building the cross- compiler environment. Two things to check: 1) Try specifying an absolute rather than relative path to the gcc configure script; I think this has been known to be a source of problems on solaris platforms in the past, but I don't know if it's still relevant now. It can't hurt to try. 2) If what you say above is *literally* correct, then the reason the wrong assembler is being found is because you've added $prefix to your $PATH, when you should have added $prefix/bin! cheers, DaveK -- Can't think of a witty .sigline today
Re: Obsoleting c4x last minute for 4.0
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: Joe Buck wrote: But if it won't even build, then users should be warned. I suppose -- but we have relatively many configurations that probably won't build, at least if you start combining various options, and including langauges beyond just C and C++. I'd be content with a patch that issued a warning, but declaring a port obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. We could put several ports into that category and it shouldn't have the negative stigma that obsolete seems to have. R.
Re: [BUG mm] fixed i386 memcpy inlining buggy
On Tuesday 05 April 2005 19:34, Christophe Saout wrote:
Hi Denis,
the new i386 memcpy macro is a ticking timebomb.
I've been debugging a new mISDN crash, just to find out that a memcpy
was not inlined correctly.
Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed).
This source code:
mISDN_pid_t pid;
[...]
memcpy(st-mgr-pid, pid, sizeof(mISDN_pid_t));
was compiled as:
lea0xffa4(%ebp),%esi %esi is loaded
( add$0x10,%ebx )
( mov%ebx,%eax ) something else
( call 1613 test_stack_protocol+0x83 ) %esi preserved
mov0xffa0(%ebp),%edx
mov0x74(%edx),%edi %edi is loaded
add$0x20,%edi offset in structure added
! mov$0x14,%esi!! %esi overwritten!
mov%esi,%ecx %ecx loaded
repz movsl %ds:(%esi),%es:(%edi)
Apparently the compiled decided that the value 0x14 could be reused
afterwards (which it does for an inlined memset of the same size some
instructions below) and clobbers %esi.
Looking at the macro:
__asm__ __volatile__(
: =D (edi), =S (esi)
: 0 ((long) to),1 ((long) from)
: memory
);
}
if (n = 5*4) {
/* large block: use rep prefix */
int ecx;
__asm__ __volatile__(
rep ; movsl
: =c (ecx)
it seems obvious that the compiled assumes it can reuse %esi and %edi
for something else between the two __asm__ sections. These should
probably be merged.
Oh shit. I was trying to be too clever. I still run with this patch,
so it must be happening very rarely.
Does this one compile ok?
static inline void * __constant_memcpy(void * to, const void * from, size_t n)
{
long esi, edi;
#if 1 /* want to do small copies with non-string ops? */
switch (n) {
case 0: return to;
case 1: *(char*)to = *(char*)from; return to;
case 2: *(short*)to = *(short*)from; return to;
case 4: *(int*)to = *(int*)from; return to;
#if 1 /* including those doable with two moves? */
case 3: *(short*)to = *(short*)from;
*((char*)to+2) = *((char*)from+2); return to;
case 5: *(int*)to = *(int*)from;
*((char*)to+4) = *((char*)from+4); return to;
case 6: *(int*)to = *(int*)from;
*((short*)to+2) = *((short*)from+2); return to;
case 8: *(int*)to = *(int*)from;
*((int*)to+1) = *((int*)from+1); return to;
#endif
}
#else
if (!n) return to;
#endif
{
/* load esi/edi */
__asm__ __volatile__(
: =D (edi), =S (esi)
: 0 ((long) to),1 ((long) from)
: memory
);
}
if (n = 5*4) {
/* large block: use rep prefix */
int ecx;
__asm__ __volatile__(
rep ; movsl
: =c (ecx), =D (edi), =S (esi)
: 0 (n/4), 1 (edi),2 (esi)
: memory
);
} else {
/* small block: don't clobber ecx + smaller code */
if (n = 4*4) __asm__
__volatile__(movsl:=D(edi),=S(esi):0(edi),1(esi):memory);
if (n = 3*4) __asm__
__volatile__(movsl:=D(edi),=S(esi):0(edi),1(esi):memory);
if (n = 2*4) __asm__
__volatile__(movsl:=D(edi),=S(esi):0(edi),1(esi):memory);
if (n = 1*4) __asm__
__volatile__(movsl:=D(edi),=S(esi):0(edi),1(esi):memory);
}
switch (n % 4) {
/* tail */
case 0: return to;
case 1: __asm__
__volatile__(movsb:=D(edi),=S(esi):0(edi),1(esi):memory); return
to;
case 2: __asm__
__volatile__(movsw:=D(edi),=S(esi):0(edi),1(esi):memory); return
to;
default: __asm__
__volatile__(movsw\n\tmovsb:=D(edi),=S(esi):0(edi),1(esi):memory);
return to;
}
}
--
vda
Re: Obsoleting c4x last minute for 4.0
On Wed, 6 Apr 2005, Richard Earnshaw wrote: Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. We could put several ports into that category and it shouldn't have the negative stigma that obsolete seems to have. One possible way of assessing activity would be to say that after 4.1 maintained CPU ports should have test results for mainline regularly sent to gcc-testresults and monitored for regressions, though this rather depends on the willingness of maintainers of embedded ports to do this testing; ports without such testing and regression monitoring could be considered at risk. Only the following ports seem to have had results for 4.1.0-mainline (i.e. mainline since 4.0 branched) sent to gcc-testresults: alpha, arm, hppa, i?86/x86_64, ia64, mips, powerpc, s390, sh, sparc, although cris and mmix are evidently monitored for regressions even though they don't get test results to gcc-testresults. (If test results for a port are so bad that though sent to gcc-testresults they exceed the message size limit, and this remains the case for a prolonged period such as ever since 4.0 branched, that also indicates lack of active maintenance.) -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
RE: [BUG mm] fixed i386 memcpy inlining buggy
Original Message From: Dave Korn Sent: 06 April 2005 12:13 Original Message From: Dave Korn Sent: 06 April 2005 12:06 Me and my big mouth. OK, that one does work. Sorry for the outburst. well, actually, maybe it doesn't after all. What's that uninitialised variable ecx doing there eh? cheers, DaveK -- Can't think of a witty .sigline today
RE: [BUG mm] fixed i386 memcpy inlining buggy
Original Message From: Dave Korn Sent: 06 April 2005 12:53 Original Message From: Dave Korn Sent: 06 April 2005 12:13 Original Message From: Dave Korn Sent: 06 April 2005 12:06 Me and my big mouth. OK, that one does work. Sorry for the outburst. well, actually, maybe it doesn't after all. What's that uninitialised variable ecx doing there eh? Oh, I see, it's there as an output so it can be matched as an input by the 0 constraint. Ok, guess it does. cheers, DaveK -- Can't think of a witty .sigline today
Input and print statements for Front End?
Hi All, I'm developing a front end for a simple programming language as part of a project. I have looked through the GCC Internals Manual, the Toy front end language and Treelang. I can't seem to find any info regarding an input or print statement, so i can read integers(my language only deals with integers) from the stdio and return integer results to stdio. I see that the Toy language has to be compiled with a C program to achieve the above. Is this the best or even only solution? Thanks _ Send an animated 'wink' to someone special - download MSN Messenger, FREE! http://messenger.msn.co.uk/Beta/Default.aspx
Re: gcc4, static array, SSE alignement
On Apr 6, 2005 3:18 AM, James E Wilson [EMAIL PROTECTED] wrote: I would guess a limitation of cygwin binutils support, or perhaps of Windows itself. Binutils, perhaps. Windows certainly not as msvc2k3 icc8.1 don't have such issue with the same code. This seems to work fine on linux. If I compile a simple example using __alignof__, I see that the compiler is assuming 16-byte alignment. If I compile with -S, I see that the compiler is giving them 32-byte alignment (probably for better cache alignment). If I run objdump -x on the a.out file, I see that .bss section has 2**5 (32-byte) alignment. All is as it should be. Sections: Idx Name Size VMA LMA File off Algn 0 .text 0003e754 00401000 00401000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 4634 0044 0044 0003ec00 2**4 CONTENTS, ALLOC, LOAD, DATA 2 .rdata4884 00445000 00445000 00043400 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 8fc0 0044a000 0044a000 2**4 ALLOC 4 .idata1984 00453000 00453000 00047e00 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .stab 00169908 00455000 00455000 00049800 2**2 CONTENTS, READONLY, DEBUGGING, NEVER_LOAD, EXCLUDE 6 .stabstr 001c39e1 005bf000 005bf000 001b3200 2**0 CONTENTS, READONLY, DEBUGGING, NEVER_LOAD, EXCLUDE Gcc the toolchain used to have lots of issues wrt alignement, but i thought they were a thing of the past. As far as i can see, everything is fine regarding section alignements. A real bug report, as per http://gcc.gnu.org/bugs.html would be useful here, so we can check. In particular, a testcase to reproduce the problem, and exactly what you believe is wrong with the output. Yep, but i was testing the water. I mean i have lots of other 16 bytes aligned data (static, extern, const or not and whatnot) in there and the only problematic one is this semi large static. So, because that's the largest, i thought i've crossed some magic size threshold. I'll try to pinpoint the problem a bit better.
Re: gcc4, static array, SSE alignement
On Apr 6, 2005 2:08 PM, tbp [EMAIL PROTECTED] wrote: I'll try to pinpoint the problem a bit better. Alas, since the other day the code using that static array has changed a bit and i can't reproduce the bug. So, after all, it really was gcc's fault. I'll try to dig up the original version.
Re: Input and print statements for Front End?
On Wednesday 06 April 2005 13:00, Harry Goulding wrote: Hi All, I'm developing a front end for a simple programming language as part of a project. I have looked through the GCC Internals Manual, the Toy front end language and Treelang. I can't seem to find any info regarding an input or print statement, so i can read integers(my language only deals with integers) from the stdio and return integer results to stdio. Interfacing with the OS is the resposibility of your language runtime library, not the compiler itself.. You might want to look at how the fortran intrinsic functions an IO routines are handled. Basically the language define IO constructs are turned into a sequence of function calls. Paul
Re: [BUG mm] fixed i386 memcpy inlining buggy
I'm having a little difficulty understanding what this is for. Is it that gcc's builtin memcpy expander generates bad code, or that older versions of gcc generate bad code, or what? gcc generates too much code? Andrew.
HEAD regression: All java tests are failing with an ICE when optimized
HEAD, clean build this morning. i686-linux-gnu. With the libgcj make check, there are many identical failures. These are of the form PR4766.java: In class 'PR4766': PR4766.java: In method 'PR4766.myfunction()': PR4766.java:0: internal compiler error: in hash_scan_set, at postreload-gcse.c:741 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 And the ICE is always in hash_scan_set. I do not believe that this is a Java FE bug. Has anyone else seen this? Andrew.
Re: HEAD regression: All java tests are failing with an ICE when optimized
On Wed, Apr 06, 2005 at 01:56:48PM +0100, Andrew Haley wrote: Has anyone else seen this? Yes. At first I thought it was my patch, but it only happens on i686 and libjava was working fine the day before. Diego.
Re: http://gcc.gnu.org/install/specific.html#*-*-solaris2*
Now I now (and understand) that you changed the mangling of filenames, but where does the g_t come from, and why? Catering to XHTML's stupidity. I mentioned it in: http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#HTML-Xref-Link-Basics viz. One exception: the algorithm for node name expansion prefixes the string `g_t' when the node name begins with a non-letter. This kludge (due to XHTML rules) is not necessary for filenames, and is therefore omitted. Sorry ...
Re: HEAD regression: All java tests are failing with an ICE when optimized
Andrew Haley wrote: HEAD, clean build this morning. i686-linux-gnu. With the libgcj make check, there are many identical failures. These are of the form PR4766.java: In class 'PR4766': PR4766.java: In method 'PR4766.myfunction()': PR4766.java:0: internal compiler error: in hash_scan_set, at postreload-gcse.c:741 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 And the ICE is always in hash_scan_set. I do not believe that this is a Java FE bug. Has anyone else seen this? First off, I didn't when I ran my regular bootstrap + libjava_check cycle. That's because I use --disable-checking. Second, it's most likely caused by Nathan's assertifying patch to gcc/p*.c: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00227.html Note that the #ifdef ENABLE_CHECKING guard in postreload-gcse.c (around line #741) was *misspelt* before: - #ifdef ENABLE_CHEKCING and was thus never being executed before. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
RE: Trying to build crosscompiler for Sparc Solaris 8 - SparcSolaris 10 ( others)...
On Wed, 2005-04-06 at 10:28 +0100, Dave Korn wrote: Original Message From: Aaron Gaudio Sent: 05 April 2005 21:05 (CCing this to [EMAIL PROTECTED] due to potential build bugs...) I have already installed binutils 2.15 and gcc 3.4.5 native Solaris 8 verisons in the prefix /vobs/java/gnu and added this directory to my path, so that those are the tools being used for building the cross- compiler environment. Two things to check: 1) Try specifying an absolute rather than relative path to the gcc configure script; I think this has been known to be a source of problems on solaris platforms in the past, but I don't know if it's still relevant now. It can't hurt to try. 2) If what you say above is *literally* correct, then the reason the wrong assembler is being found is because you've added $prefix to your $PATH, when you should have added $prefix/bin! Thanks for your attention, Dave. I checked the script I'm using to build and I actually am using an absolute path to gcc's configure, despite what I wrote in my original mailnote. As for the prefix... you're right, I should be adding $prefix/bin to my path. I was adding $prefix in my script, but lo, I had already added $prefix/bin to my path in my shell. I'll fix my script, but that won't have any impact on the problems I'm facing. You see, the 'as' being called was in fact the one in $prefix/bin, but the problem is that $prefix is a holding place for binaries with multiple targets. $prefix/bin/as is a Sparc Solaris 8 binary with a Sparc Solaris 8 target (eg --version This assembler was configured for a target of `sparc-sun- solaris2.8'.). However, $prefix/bin/i586-sun-solaris2.10-as is a Sparc Solaris 8 binary with an i586 Solaris 10 target (--version This assembler was configured for a target of `i586-sun-solaris2.10'.). It seems like either Makefile should be using $AS_FOR_TARGET (which would expand to 'i586-sun-solaris2.10-as'), instead of $AS (which is just 'as') OR the .s file being assembled should be using Sparc assembly instructions instead of x86. I assumed the former was the case, and that let me get further in the build, so that's what I've stuck with for now... -- Aaron Gaudio agaudio @ eng.mc.xerox.com 585-422-6876 madcap @ irc://rockhopper.eng.mc.xerox.com OpenPGP fingerprint: 74B3 1018 08EB 1B3F E7C7 B944 11B1 E0C3 949C 8906 Every man is a mob, a chain gang of idiots. - Jonathan Nolan, /Memento Mori/ signature.asc Description: This is a digitally signed message part
Re: Obsoleting c4x last minute for 4.0
Joel Sherrill [EMAIL PROTECTED] wrote: Richard Earnshaw wrote: On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: Joe Buck wrote: But if it won't even build, then users should be warned. I suppose -- but we have relatively many configurations that probably won't build, at least if you start combining various options, and including langauges beyond just C and C++. I'd be content with a patch that issued a warning, but declaring a port obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. We could put several ports into that category and it shouldn't have the negative stigma that obsolete seems to have. The RTEMS community has been interested in the c4x port for a long time but we don't have anyone who can fix things at the level this one is broken. We keep trying it and reporting on it. It gets a little better, then it gets a little worse. I have been reminded by an RTEMS user that the c4x port actually did successfully build C for 3.4. This makes it a recent regression. -- Joel Sherrill, Ph.D. Director of Research Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
3.4.3 on Solaris9, boehm-gc probs.
I've STW for this but can't see others with the same problem. I'm
getting:
[...]
/bin/bash ./libtool --mode=compile /export/home/Scratch/hgs/gcc-build/gcc/xgcc
-B/export/home/Scratch/hgs/gcc-build/gcc/
-B/usr/local/sparc-sun-solaris2.9/bin/ -B/usr/local/sparc-sun-solaris2.9/lib/
-isystem /usr/local/sparc-sun-solaris2.9/include -isystem
/usr/local/sparc-sun-solaris2.9/sys-include -DGC_SOLARIS_THREADS=1
-DGC_SOLARIS_PTHREADS=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1
-DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I.
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/include -O2 -mcpu=v9
-fexceptions -I././targ-include
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/./libc/include -O2 -mcpu=v9 -c
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c
/export/home/Scratch/hgs/gcc-build/gcc/xgcc
-B/export/home/Scratch/hgs/gcc-build/gcc/
-B/usr/local/sparc-sun-solaris2.9/bin/ -B/usr/local/sparc-sun-solaris2.9/lib/
-isystem /usr/local/sparc-sun-solaris2.9/include -isystem
/usr/local/sparc-sun-solaris2.9/sys-include -DGC_SOLARIS_THREADS=1
-DGC_SOLARIS_PTHREADS=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1
-DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I.
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/include -O2 -mcpu=v9 -fexceptions
-I././targ-include -I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/./libc/include
-O2 -mcpu=v9 -c /export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c -fPIC
-DPIC -o .libs/dyn_load.o
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c: In function
`GC_FirstDLOpenedLinkMap':
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:110: error: syntax error before
_DYNAMIC
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error: `Elf32_Dyn'
undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error: (Each
undeclared identifier is reported only once
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error: for each
function it appears in.)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error: `dp'
undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:114: error: syntax error
before '*' token
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:127: error:
`dynStructureAddr' undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:127: error: `_DYNAMIC'
undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:135: error: parse error
before ')' token
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:136: error: `DT_DEBUG'
undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:139: error:
dereferencing pointer to incomplete type
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c: In function
`GC_register_dynamic_libraries':
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:209: error:
dereferencing pointer to incomplete type
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:227: error:
dereferencing pointer to incomplete type
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:229: error:
dereferencing pointer to incomplete type
gmake[3]: *** [dyn_load.lo] Error 1
gmake[3]: Leaving directory
`/export/home/Scratch/hgs/gcc-build/sparc-sun-solaris2.9/boehm-gc'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/export/home/Scratch/hgs/gcc-build/sparc-sun-solaris2.9/boehm-gc'
gmake[1]: *** [all-target-boehm-gc] Error 2
gmake[1]: Leaving directory `/export/home/Scratch/hgs/gcc-build'
gmake: *** [bootstrap-lean] Error 2
You have mail in /var/mail/hgs
bash-2.05$
when using
gcc (GCC) 3.4.1
GNU assembler 2.14 20030612
GNU ld version 2.14 20030612
GNU Make 3.80
ltmain.sh (GNU libtool) 1.5.14 (1.1220.2.195 2005/02/12 12:12:33)
GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9)
and a build script of
quote
#!/bin/bash -x
PATH=/bin:/usr/sbin:/usr/ccs/bin:/etc:/usr/local/bin:/opt/sfw/bin:/usr/openwin/bin
export PATH
CONFIG_SHELL=/bin/bash
export CONFIG_SHELL
BUILDINGVER=3.4.3
BUILD_DIR=/export/home/Scratch/hgs/gcc-build
GCC_SOURCE_DIR=/export/home/Scratch/hgs/gcc-${BUILDINGVER}
# CC=/progs/SUNWspro/bin/cc -xildoff -xarch=v9 options only needed
# for 64 bit...
# CC=/progs/SUNWspro/bin/cc
CC=gcc
export CC
CXX=g++
export CXX
MAKE=/usr/local/bin/gmake
export MAKE
ASOPT=--with-as=/usr/local/bin/as
LDOPT=--with-ld=/usr/local/bin/ld
LANGOPT=--enable-languages=c,c++,f77,java,objc
cd $BUILD_DIR
/bin/rm -rf ./*
${GCC_SOURCE_DIR}/configure $ASOPT $LDOPT $LANGOPTS --disable-nls \
# gmake --jobs=5 bootstrap-lean
gmake bootstrap-lean \
gmake check
/quote
Is there anything I have missed?
Thank you,
Hugh
Re: Obsoleting c4x last minute for 4.0
Richard Earnshaw wrote: On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: Joe Buck wrote: But if it won't even build, then users should be warned. I suppose -- but we have relatively many configurations that probably won't build, at least if you start combining various options, and including langauges beyond just C and C++. I'd be content with a patch that issued a warning, but declaring a port obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. That seems eminently reasonable. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
RE: Trying to build crosscompiler for Sparc Solaris 8 -SparcSolaris 10 ( others)...
Original Message
From: Aaron Gaudio
Sent: 06 April 2005 14:25
Thanks for your attention, Dave. I checked the script I'm using to build
and I actually am using an absolute path to gcc's configure, despite
what I wrote in my original mailnote.
Oh well, so much for that one. This is why you should cut and paste the
real output from builds that go wrong when you're making a bug report,
rather than faking it: you gave me false information about your problem.
This is not very constructive.
As for the prefix... you're right, I should be adding $prefix/bin to my
path. I was adding $prefix in my script, but lo, I had already added
$prefix/bin to my path in my shell. I'll fix my script, but that won't
have any impact on the problems I'm facing. You see, the 'as' being
called was in fact the one in $prefix/bin, but the problem is that
$prefix is a holding place for binaries with multiple targets.
Yes indeed, but that isn't a problem. When you're doing a cross-compile,
the make process is in fact looking out for ${target}-as. If you've
configured gcc for i586-sun-solaris2.10, and there is a
i586-sun-solaris2.10-as in your $PATH, the make process should find it.
It's only after completely failing to find ${target}-as that the make
process will fall back as a last resort to just trying to use the first 'as'
it can find.
$prefix/bin/as is a Sparc Solaris 8 binary with a Sparc Solaris 8 target
(eg --version This assembler was configured for a target of `sparc-sun-
solaris2.8'.). However, $prefix/bin/i586-sun-solaris2.10-as is a Sparc
Solaris 8 binary with an i586 Solaris 10 target (--version This
assembler was configured for a target of `i586-sun-solaris2.10'.).
Well, it *absolutely* should have found and used that one. Assuming you
really did configure gcc for that target, of course.
It seems like either Makefile should be using $AS_FOR_TARGET (which
would expand to 'i586-sun-solaris2.10-as'), instead of $AS (which is
just 'as') OR the .s file being assembled should be using Sparc assembly
instructions instead of x86. I assumed the former was the case, and that
let me get further in the build, so that's what I've stuck with for
now...
No, no, no, you are definitely wrong. Leave the makefile alone: it works
fine for every other kind of cross-compile, there's nothing wrong with it,
gcc 3.4.3 has been out for a while now and people would have noticed if it
was so badly broken!
There is an unbreakable rule when making cross toolchains: you must use
the EXACT same arguments for --prefix and for --target when you configure
gcc as you used when you configured binutils. You appear to have broken
that rule. If the makefile is using $AS instead of $AS_FOR_TARGET, then you
have gotten a bad configure somehow, and autoconf has made you a makefile
suitable for a host-native compiler. Did you try reconfiguring in the same
object directory you had previously used for the sparc-sun-solaris2.8
target?
I think you should blow away your object directory, create a new one,
freshly configure and try again. If it still doesn't work, show me the REAL
configure commands you've been using. Don't post forged output in a bug
report!
BTW, there's a list called the crossgcc mailing list
(http://sources.redhat.com/ml/crossgcc/), which is more suitable to this
sort of problem than the main gcc or gcc-help lists, but since we're here
now, we may as well try and sort this one out here; I'm just letting you
know for future reference.
cheers,
DaveK
--
Can't think of a witty .sigline today
gcc-3.4-20050401 BUG? generates illegal instruction in X11R6.4.2/mkfontscale/freetype macro
Hello, gcc-list! Hello, Melchior! Well, about a year ago, we/you have had problems when building X11 that mkfontscale crashes with an illegal instruction or an segmentation fault on powerpc. Maybe some of you remember. Here is the old mail: [Devel] [BUG] freetype2 CVS/HEAD: crash in FT_Get_Name_Index (ftobjs.c:2407) http://lists.gnu.org/archive/html/freetype-devel/2004-04/msg00051.html I am running into the same problems again (and several others did). Even with a pretty new toolchain: gcc-3.4-20050401 (3.4.4) X11R6.4.2 glibc-2.3.4 binutils-2.15.96 freetype-2.1.9 to reproduce the problem: install freetype-2.1.9 ./configure make make install compile X make World everything fine make install when mkfontscale tries to + ../../../exports/bin/mkfontscale /usr/X11R6/lib/X11/fonts/Type1 make[4]: *** [install] Error 132 (Illegal instruction) I ran into the same problem again and again. This only happens with the Type1 fonts... the others build fine! My host is a embedded PowerPC from Freescale (MPC8540, e500 core, no fpu) I've applied your patch for the macro. (inserting a dummy printf();) But this doesn't fix the problem on my platform. What is the real background that mkfontscale breaks? A compiler error or a bug in freetype? Are there any good news that the problem is really fixed? Well... and how? Any suggestions to track down that problem? Best greets Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Re: [BUG mm] fixed i386 memcpy inlining buggy
On Tuesday 05 April 2005 19:34, Christophe Saout wrote:
the new i386 memcpy macro is a ticking timebomb.
I've been debugging a new mISDN crash, just to find out that a memcpy
was not inlined correctly.
Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed).
Updated patch against 2.6.11 follows. This one, like the original
patch, is run tested too.
This time I took no chances, esi/edi contents are
explicitly propagated from one asm() block to another.
I didn't do it before, not expecting that gcc can be
s incredibly clever. Sorry.
Christophe does this one look/compile ok?
--
vda
--- linux-2.6.11.src/include/asm-i386/string.h.orig Thu Mar 3 09:31:08 2005
+++ linux-2.6.11.src/include/asm-i386/string.h Wed Apr 6 19:08:39 2005
@@ -198,47 +198,80 @@ static inline void * __memcpy(void * to,
int d0, d1, d2;
__asm__ __volatile__(
rep ; movsl\n\t
- testb $2,%b4\n\t
- je 1f\n\t
- movsw\n
- 1:\ttestb $1,%b4\n\t
- je 2f\n\t
- movsb\n
- 2:
+ movl %4,%%ecx\n\t
+ andl $3,%%ecx\n\t
+#if 1 /* want to pay 2 byte penalty for a chance to skip microcoded rep? */
+ jz 1f\n\t
+#endif
+ rep ; movsb\n\t
+ 1:
: =c (d0), =D (d1), =S (d2)
- :0 (n/4), q (n),1 ((long) to),2 ((long) from)
+ : 0 (n/4), g (n), 1 ((long) to), 2 ((long) from)
: memory);
return (to);
}
/*
- * This looks horribly ugly, but the compiler can optimize it totally,
+ * This looks ugly, but the compiler can optimize it totally,
* as the count is constant.
*/
static inline void * __constant_memcpy(void * to, const void * from, size_t n)
{
- if (n = 128)
- return __builtin_memcpy(to, from, n);
-
-#define COMMON(x) \
-__asm__ __volatile__( \
- rep ; movsl \
- x \
- : =c (d0), =D (d1), =S (d2) \
- : 0 (n/4),1 ((long) to),2 ((long) from) \
- : memory);
-{
- int d0, d1, d2;
+ long esi, edi;
+ if (!n) return to;
+#if 1 /* want to do small copies with non-string ops? */
+ switch (n) {
+ case 1: *(char*)to = *(char*)from; return to;
+ case 2: *(short*)to = *(short*)from; return to;
+ case 4: *(int*)to = *(int*)from; return to;
+#if 1 /* including those doable with two moves? */
+ case 3: *(short*)to = *(short*)from;
+ *((char*)to+2) = *((char*)from+2); return to;
+ case 5: *(int*)to = *(int*)from;
+ *((char*)to+4) = *((char*)from+4); return to;
+ case 6: *(int*)to = *(int*)from;
+ *((short*)to+2) = *((short*)from+2); return to;
+ case 8: *(int*)to = *(int*)from;
+ *((int*)to+1) = *((int*)from+1); return to;
+#endif
+ }
+#endif
+ esi = (long) from;
+ edi = (long) to;
+ if (n = 5*4) {
+ /* large block: use rep prefix */
+ int ecx;
+ __asm__ __volatile__(
+ rep ; movsl
+ : =c (ecx), =D (edi), =S (esi)
+ : 0 (n/4), 1 (edi),2 (esi)
+ : memory
+ );
+ } else {
+ /* small block: don't clobber ecx + smaller code */
+ if (n = 4*4) __asm__ __volatile__(movsl
+ :=D(edi),=S(esi):0(edi),1(esi):memory);
+ if (n = 3*4) __asm__ __volatile__(movsl
+ :=D(edi),=S(esi):0(edi),1(esi):memory);
+ if (n = 2*4) __asm__ __volatile__(movsl
+ :=D(edi),=S(esi):0(edi),1(esi):memory);
+ if (n = 1*4) __asm__ __volatile__(movsl
+ :=D(edi),=S(esi):0(edi),1(esi):memory);
+ }
switch (n % 4) {
- case 0: COMMON(); return to;
- case 1: COMMON(\n\tmovsb); return to;
- case 2: COMMON(\n\tmovsw); return to;
- default: COMMON(\n\tmovsw\n\tmovsb); return to;
+ /* tail */
+ case 0: return to;
+ case 1: __asm__ __volatile__(movsb
+ :=D(edi),=S(esi):0(edi),1(esi):memory);
+ return to;
+ case 2: __asm__ __volatile__(movsw
+ :=D(edi),=S(esi):0(edi),1(esi):memory);
+ return to;
+ default: __asm__ __volatile__(movsw\n\tmovsb
+ :=D(edi),=S(esi):0(edi),1(esi):memory);
+ return to;
}
}
-
-#undef COMMON
-}
#define __HAVE_ARCH_MEMCPY
Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF
Toon Moene writes: Toon We (the GNU Fortran folk) are in trouble too: We're awaiting Toon affirmation of the receipt of Thomas Koenig's papers (sent from Germany Toon on the 19th of March). He has quite a few patches to gfortran in the Toon queue and GCC 4.0 (the first GCC release to contain gfortran) is Toon scheduled for the 15th of April. Toon Please help. The FSF has advised that we can accept Thomas's patches while the paperwork catches up. David
Illegal promotion of bool to int....
Greetings. I am running up against an interesting compiler bug whereby a bool is being promoted to an int. I found a Bugzilla entry and a message on the mailing list that I thought was similar to what I am seeing: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15484 http://gcc.gnu.org/ml/gcc/2004-05/msg00752.html Usage of the patch does not help for gcc-3.3 or 3.4 compilers on PPC. I tried a fresh checkout of 4.1.0, but it failed to cross-build for i686-linux hosted and powerpc-linux target. I am building my cross toolchains with 'crosstool'. Here is the output from my compile: powerpc-7450-linux-gnu-g++ -I../common -O2 -Wall -Wno-uninitialized -mtune=7450 -maltivec -g -c ../modify/transform.cpp -o transform.o ../modify/transform.cpp:109: error: prototype for `analysis::analysis(int, resolution, sample_allocator*, float, roi_node*, int)' does not match any in class `analysis' ../common/sample_processing.h:768: error: candidates are: analysis::analysis(const analysis) ../common/sample_processing.h:781: error: analysis::analysis(resolution, sample_allocator*, bool, float, roi_node*) ../modify/transform.cpp:125: error: prototype for `sub_analysis::sub_analysis(resolution, sample_allocator*, int, float, roi_node*)' does not match any in class `sub_analysis' ../modify/analysis_local.h:49: error: candidates are: sub_analysis::sub_analysis(const sub_analysis) ../modify/analysis_local.h:53: error: sub_analysis::sub_analysis(resolution, sample_allocator*, bool, float, roi_node*) ../modify/transform.cpp:309: error: prototype for `void sub_analysis::push(line_buf, int)' does not match any in class `sub_analysis' ../modify/analysis_local.h:56: error: candidate is: virtual void sub_analysis::push(line_buf, bool) make: *** [transform.o] Error 1 Does anyone have some insight on this? Thanks. -Steve
specs file
I as sorry I repeat my appeal, but if really nobody works on Sparc or PowerPC processors and nobody wants to send me 'specs' file from directory /usr/lib/gcc-lib/name_of_compiler/lib/version/specs or similar ??? One more time, thank you for help! Nie dzwon do Londynu... zanim nie sprawdzisz HALO.interia.pl Tutaj: http://link.interia.pl/f1870
Re: Illegal promotion of bool to int....
On Wed, Apr 06, 2005 at 12:14:04PM -0500, [EMAIL PROTECTED] wrote: I am running up against an interesting compiler bug whereby a bool is being promoted to an int. I found a Bugzilla entry and a message on the mailing list that I thought was similar to what I am seeing: ... Does anyone have some insight on this? Thanks. Sorry, it's not possible to help you figure out a bug from such a vague description. A testcase would be needed. If the bug is in code that you cannot publish, you can try to cut it down to a small example that you can reveal.
Re: use of extended asm on ppc for long long data types
Kumar Gala writes: Kumar Is there anyway to specify a long long data type as a constraint to Kumar extended asm for powerpc32. If so, how does one specify the registers Kumar that would have the upper and lower bits The rs6000.md machine description has examples of patterns implementing 64-bit (DImode) operations in 32-bit mode. The constraint is a normal r or b GPR constraint. GCC allocates pairs of consecutive registers to hold the 64-bit value in 32-bit mode. When operating in big-endian, the MSB is in the first register and the LSB is the second register (R+1); in little-endian mode, the two registers are reversed. The PowerPC port defines a special print_operand modifier %L to refer to R+1, e.g., for operand 0, one would write assembly code referring to %0 and %L0. David
Re: Question about #pragma pack(n)
On Tue, 2005-04-05 at 21:20, feng qiu wrote: In c-pragma.c file, #pragma pack(n) set the value of maximum_field_alignment. And in opts.c file,-fpack-struct set flag_pack_struct = 1 . But I don't known the relation between them. Try using grep, as in grep flag_pack_struct *.c and grep maximum_field_alignment *.c. It seems that they relate to the four ariables DECL_ALIGN,DECL_PACKED,TYPE_PACKED,and TYPE_ALIGN in stor-layout.c file,but what is the difference in them?Should I modify this file? If you really want to modify files, and submit a patch, you have to use current mainline sources. This stuff works differently on mainline than it does in the older sources you are looking at. We can't accept a patch based off of an older release. Yes, you are looking in the right place. TYPE_PACKED and maximum_field_alignment are the important ones for this particular problem. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: 3.4.3 on Solaris9, boehm-gc probs.
On Wed, 6 Apr 2005, Eric Botcazou wrote:
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:110: error: syntax
error before _DYNAMIC
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error:
`Elf32_Dyn' undeclared (first use in this function)
Elf32_Dyn is supposed to be defined in /usr/include/sys/link.h:
Grep -C 5 gives me:
quote
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
Elf32_Off d_off;
} d_un;
} Elf32_Dyn;
#if (defined(_LP64) || ((__STDC__ - 0 == 0) (!defined(_NO_LONGLONG
typedef struct {
Elf64_Xword d_tag; /* how to interpret value */
union {
--
unsigned long l_addr; /* address at which object is mapped */
char*l_name;/* full name of loaded object */
#ifdef _LP64
Elf64_Dyn *l_ld; /* dynamic structure of object */
#else
Elf32_Dyn *l_ld; /* dynamic structure of object */
#endif
Link_map * l_next; /* next link object */
Link_map * l_prev; /* previous link object */
char*l_refname; /* filters reference name */
};
/quote
typedef struct {
Elf32_Sword d_tag; /* how to interpret value */
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
Elf32_Off d_off;
} d_un;
} Elf32_Dyn;
Here's what I get with -H:
Sorry? -H applied to what command?
[...]
--
Eric Botcazou
Thank you,
Hugh
Re: 3.4.3 on Solaris9, boehm-gc probs.
Here's what I get with -H: Sorry? -H applied to what command? The GCC command line you pasted. -- Eric Botcazou
re: gcc-3.4-20050401 BUG? generates illegal instruction in X11R6.4.2/mkfontscale/freetypemacro
Clemens Koller wrote: + ../../../exports/bin/mkfontscale /usr/X11R6/lib/X11/fonts/Type1 make[4]: *** [install] Error 132 Can you try to produce a standalone test case that doesn't require building all of X? e.g. can you save the preprocessor output from the mkfontscale compiler run, compile that on a different system, and reproduce the problem, preferably with a single known font file? - Dan
[Bug target/17822] avr: Hard-coded XXX_FOR_TARGET
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-04-06 06:18 --- OK to apply this patch to gcc-4.0, too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17822
[Bug c++/20734] [4.0/4.1 Regression] rejects valid pointer to member
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-06 06:28 --- the file which has led to the test case above compiles ok, too -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20734
[Bug bootstrap/20780] gcc 4.0 from cvs head fails to build
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 06:36 --- (In reply to comment #2) \ /var/tmp//ccDSlyQP.s:774:stfiwx instruction is optional for the PowerPC (not allowed without -force_cpusubtype_ALL option) At this point you need to read: http://gcc.gnu.org/ml/gcc/2005-03/msg01149.html and get a newer cctools so this is invalid. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20780
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 06:38 --- (In reply to comment #7) They don't even bear-out on other x86 platforms -- my older P3 and AMD boxes don't show the same kind of big improvement (they show a small improvements). However, both of my P4s show big improvements. Huh, both of those targets are still x86. So what about on say Power4 or PowerPC 970? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
[Bug target/20781] 64 bit shift by non-constant implemented as libcall on PPC32
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 06:46 --- Hmm on powerpc-darwin on the mainline I get: _foo: addic. r11,r5,-32 subfic r2,r5,31 srwi r0,r4,1 srw r0,r0,r2 blt- cr0,L2 slw r9,r4,r11 li r10,0 mr r3,r9 mr r4,r10 blr L2: slw r9,r3,r5 slw r10,r4,r5 or r9,r0,r9 mr r4,r10 mr r3,r9 blr Which is still bad as we have extra moves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20781
[Bug c++/20145] [4.0/4.1 Regression] template class has virtual functions ... is not suppressed with -isystem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 06:48 --- (In reply to comment #7) The fact that something is in a system header does not in general cause the compiler not to warn about it. G++ does not issue certain pedantic warnings when in a system header, but this is not one of those. Why does the non-template version does not warn then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20145
[Bug libgcj/20750] libgcj needs a --with-java-home configure option
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20750
[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-04-06 06:56 --- Richard, I think we should probably close this one unless we actually get a chip part that has this failing :) ...or at least get some documentation about what the hardware limitation actually is. ;) I was keeping this open (but suspended) so that we could track the fact that gcc doesn't work around this particular problem. But I agree that there's not enough information here to be useful. We can always reopen the PR if someone does provide the docs (although we'd probably just suspend it again, unless someone's actually volunteering to implement the workaround). Richard -- What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309
[Bug libgcj/20775] Crash in libgcj.so on linux alpha
--- Additional Comments From tsv at solvo dot ru 2005-04-06 07:11 --- No, it is UP machine. Yes - it crashes at the same place all the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20775
[Bug bootstrap/20783] New: [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0
I just ran two parallel bootstraps of mainline and 4.0, on a single-processor Athlon XP 2600+. Configuration was with --prefix=$HOME --enable-languages=c,f95 in both cases. The 4.0 build, which finished earlier, used real58m0.437s user25m1.021s sys 1m36.735s The 4.1 build used real67m24.663s user38m19.830s sys 1m41.125s The compiler used for boostrapping was $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050402 (experimental) $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2600+ stepping: 1 cpu MHz : 2083.203 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmovpat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips: 4128.76 -- Summary: [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20783
[Bug target/11787] always call memcpy for block move in mips16
--- Additional Comments From stephane dot mutz at philips dot com 2005-04-06 08:07 --- I understand your point. However, this sometimes results in a significant drop of performance forcing to revert to MIPS2 / MIPS32. This partly spoils the usefulness of MIPS16. I think the option of forcing memcpy calls iso inline in function calls should be left to the developer and not a defacto choice of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11787
[Bug target/17824] Hard-coded AS and LD in c4x.h
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06 08:11 --- Subject: Bug 17824 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-06 08:10:54 Modified files: gcc: ChangeLog gcc/config/c4x : c4x.h Log message: 2005-04-06 Ralf Corsepius [EMAIL PROTECTED] PR target/17824 * config/c4x/c4x.h (ASM_PROG, LD_PROG): Remove. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8163r2=2.8164 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/c4x/c4x.h.diff?cvsroot=gccr1=1.152r2=1.153 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17824
[Bug target/17824] Hard-coded AS and LD in c4x.h
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-04-06 08:15 --- OK to apply this patch to 4.0, too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17824
[Bug libfortran/20108] incorrect run time error on formatted read
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-06 08:45 --- I'm not sure, but I guess this one should go away with Thomas' patches for EOR handling (see PR 20131, comment 5 for a link). -- What|Removed |Added Last reconfirmed|2005-02-21 21:44:19 |2005-04-06 08:45:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20108
[Bug c/20784] New: Impossible to mute warning: imaginary constants are a GCC extension
float complex c = 1.if; // warning: imaginary constants are a GCC extension This warning is generated when -pedantic is specified. This creates problems with perfectly valid standard C99 code such as the following. double complex d = I; No particular placement of __extension__ seems to be able to make this warning go away. -- Summary: Impossible to mute warning: imaginary constants are a GCC extension Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20784
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From gdr at integrable-solutions dot net 2005-04-06 08:59 --- Subject: Re: operator-(const T, const complexT) vs operator-(const complexT, const complexT) pcarlini at suse dot de [EMAIL PROTECTED] writes: | Gaby, what do you think about this issue? In fact, it seems to me that an | implementation strictly following the standard (26.2.6/6), or complex1.patch | here, doesn't not incur in this problem... I think we need more careful analysis and tracking of both C99, C++ and LIA-3. Coming to think about it, Bruce I still own you a reply about the logarithm ; I'll send you all references I have in a separate mail. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug c/20785] New: Pragma STDC CX_LIMITED_RANGE unimplemented
#pragma STDC CX_LIMITED_RANGE off is currently unimplemented, and generates the warning: warning: ignoring #pragma STDC CX_LIMITED_RANGE -- Summary: Pragma STDC CX_LIMITED_RANGE unimplemented Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From pcarlini at suse dot de 2005-04-06 09:17 --- I think we need more careful analysis and tracking of both C99, C++ and LIA-3. Ok, thanks, I will start on such analysis (in particulat wrt LIA-3). A minor issue with complex1.patch is that probably unary operator- is cheaper than a full subtraction, still, at the end, probably something similar will be needed. I should also remark that this is definitely not a regression and that, indeed, the current C++ standard, completely ignores signed zero, NAN, INF, etc... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From pcarlini at suse dot de 2005-04-06 09:27 --- By the way, about the log, now that you mention it, it's really a pity that we cannot enable and use the builtin due to the namespace issues with the clog stream. We should really figure out a way to resolve this annoying issue, humpf! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug fortran/20786] New: Can't use AINT intrinsic with KIND parameter
The following code is valid: $ cat aint_mismatch.f implicit none real(4) r r = aint (r,kind=8) end $ gfortran aint_mismatch.f aint_mismatch.f: In function ‘MAIN__’: aint_mismatch.f:3: internal compiler error: in emit_move_insn, at expr.c:3085 The ICE disappears if kind=4 or if r is a real(8). This should be easy to fix, since other similar intrinsics (such as ANINT) doesn't exhibit such ICE. -- Summary: Can't use AINT intrinsic with KIND parameter Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org OtherBugsDependingO 19292 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20786
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- What|Removed |Added BugsThisDependsOn||20786 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/20279] gfortran: ICE on valid code, in gfc_get_symbol_decl
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-06 09:55 --- This got fixed today. *** This bug has been marked as a duplicate of 15959 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20279
[Bug fortran/15959] ICE and assertion failure in trans-decl.c with character initialization
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-06 09:55 --- *** Bug 20279 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15959
[Bug fortran/20279] gfortran: ICE on valid code, in gfc_get_symbol_decl
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20279
[Bug libstdc++/20787] New: Implement resolution of DR 130 [Ready] in v7-branch
Just an internal reminder. A couple of notes: 1- I'm pretty sure cannot be implemented in v6, but would be happy to be wrong. 2- Maybe a similar fix is needed also for tr1/unordered_*. -- Summary: Implement resolution of DR 130 [Ready] in v7-branch Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: pcarlini at suse dot de ReportedBy: pcarlini at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20787
[Bug libstdc++/20787] Implement resolution of DR 130 [Ready] in v7-branch
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-06 10:50:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20787
[Bug bootstrap/20783] [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0
--- Additional Comments From giovannibajo at libero dot it 2005-04-06 10:51 --- mainline has checking enabled by default. Try bootstrapping it with --disable- checking before comparing numbers. Plus there is a regression we already know of, see: http://gcc.gnu.org/ml/gcc/2005-04/msg00184.html -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20783
[Bug libstdc++/20787] Implement resolution of DR 130 [Ready] in v7-branch
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20787
[Bug c/20784] Impossible to mute warning: imaginary constants are a GCC extension
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-06 11:15 --- *** This bug has been marked as a duplicate of 7263 *** -- What|Removed |Added CC||jsm28 at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20784
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-06 11:15 --- *** Bug 20784 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aaronavay62 at aaronwl dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug c/20785] Pragma STDC CX_LIMITED_RANGE unimplemented
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-06 11:21 --- We know. I'm not sure how much use there is opening PRs for major points listed as Missing at http://gcc.gnu.org/c99status.html unless there are particular subtle points which might be missed in implementation which would be better noted in a PR. Stephen Moshier started a C99 pragma implementation some time ago. I have his code (version of June 2001, not a complete implementation, only does anything with FENV_ACCESS) and at least the testcases might be useful; I'll attach the files to this bug as we may as well use the bug now it's open. -- What|Removed |Added CC||jsm28 at gcc dot gnu dot org OtherBugsDependingO||16989 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-06 11:21:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
[Bug target/17245] [3.3 regression] ICE compiling gsl-1.5 statistics/lag1.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06 11:54 --- Subject: Bug 17245 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-06 11:53:54 Modified files: gcc: ChangeLog gcc/config/sparc: sparc.c Log message: PR target/17245 * config/sparc/sparc.c (legitimate_address_p): Remove 'imm2'. Revert 2004-10-08 patch. Reject TFmode LO_SUM in 32-bit mode. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8167r2=2.8168 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gccr1=1.360r2=1.361 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17245
[Bug target/17245] [3.3 regression] ICE compiling gsl-1.5 statistics/lag1.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06 11:56 --- Subject: Bug 17245 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-06 11:56:34 Modified files: gcc: ChangeLog gcc/config/sparc: sparc.c Log message: PR target/17245 * config/sparc/sparc.c (legitimate_address_p): Remove 'imm2'. Revert 2004-10-08 patch. Reject TFmode LO_SUM in 32-bit mode. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.138r2=2.7592.2.139 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.354.8.2r2=1.354.8.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17245
[Bug target/17245] [3.3 regression] ICE compiling gsl-1.5 statistics/lag1.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06 11:59 --- Subject: Bug 17245 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-04-06 11:59:10 Modified files: gcc: ChangeLog gcc/config/sparc: sparc.c Log message: PR target/17245 * config/sparc/sparc.c (legitimate_address_p): Remove 'imm2'. Revert 2004-10-08 patch. Reject TFmode LO_SUM in 32-bit mode. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.833r2=2.2326.2.834 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.271.4.23r2=1.271.4.24 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17245
[Bug c/20785] Pragma STDC CX_LIMITED_RANGE unimplemented
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-04-06 12:13 --- I opened the PR so I would have a tangible place to point to in a FIXME in some code, saying when this bug is fixed, uncomment this. Perhaps though, for things of this sort, it would be better to point to the status page. However, one can add oneself to the CC list for a bug much easier than he can add himself to the CC list for a webpage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
[Bug fortran/20788] New: Loading libgfortran.so clobbers C redirection of stdin
When using a C main program that has in any way loaded libgfortran.so, redirected C stdin is broken. This is used by the R project http://www.r-project.org to run scripts, and even occurs even if the main (C) program has dlopen-ed a DSO with compiled Fortran code linked against libgfortran.so. There is separate bug that stops GFORTRAN_STDIN_UNIT being set to a negative value to avoid the initialization that causes the problem. -- Summary: Loading libgfortran.so clobbers C redirection of stdin Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ripley at stats dot ox dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20788
[Bug fortran/20788] Loading libgfortran.so clobbers C redirection of stdin
--- Additional Comments From ripley at stats dot ox dot ac dot uk 2005-04-06 12:27 --- Created an attachment (id=8547) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8547action=view) Reproduction details, partial fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20788
[Bug target/20781] 64 bit shift by non-constant implemented as libcall on PPC32
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-06 12:34 --- Subject: Re: 64 bit shift by non-constant implemented as libcall on PPC32 On Wed, 2005-04-06 at 06:46 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 06:46 --- Hmm on powerpc-darwin on the mainline I get: So apparently it's implemented, but not for ppc linux? Weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20781
[Bug target/20781] 64 bit shift by non-constant implemented as libcall on PPC32
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-06 12:35 --- Subject: Re: 64 bit shift by non-constant implemented as libcall on PPC32 On Wed, 2005-04-06 at 06:46 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 06:46 --- Hmm on powerpc-darwin on the mainline I get: Oh, forget it, i was trying an older compiler. Sigh. Damn you PATH e -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20781
[Bug c++/20789] New: segv
-- Summary: segv Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
[Bug c++/20789] segv
--- Additional Comments From igodard at pacbell dot net 2005-04-06 12:37 --- Created an attachment (id=8548) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8548action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
[Bug c++/20789] segv
--- Additional Comments From igodard at pacbell dot net 2005-04-06 12:37 --- Created an attachment (id=8549) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8549action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
[Bug fortran/17229] parser confused by arithmetic if inside an if
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-06 12:38 --- But then, some scientific libraries are using it (I was about to report the same bug when a search pointed to this one). And since it works on any compiler I could find (including g77), I'd change that into a bug (and not enhancement). -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|enhancement |normal Last reconfirmed|2004-11-11 05:26:38 |2005-04-06 12:38:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17229
[Bug AWT/20790] New: libjawt.so must be renamed
libjawt.so needs to be renamed libgcj-jawt.so. Because it is installed in the standard library prefix and has the same name as Sun's AWT Native Interface implementation library, proprietary JVMs pick up libgcj's libjawt.so and not Sun's. We can install a symlink in java-gcj-compat so that applications building against libjawt.so will not see the difference between libgcj-jawt.so and libjawt.so. -- Summary: libjawt.so must be renamed Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: fitzsim at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20790
[Bug fortran/17229] parser confused by arithmetic if inside an if
--- Additional Comments From prthomas at drfccad dot cea dot fr 2005-04-06 13:22 --- Subject: RE: parser confused by arithmetic if inside a n if But then, some scientific libraries are using it (I was about to report the same bug when a search pointed to this one). And since it works on any compiler I could find (including g77), I'd change that into a bug (and not enhancement). Neither Tobi not Andrew said that it is not a bug.. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17229
[Bug other/20791] New: visibilty options don't work
When compiling a source file with -fvisibility=hidden and/or -fvisibility-inlines-hidden I get the following error for each function in the file (happens with C and C++ front-end): C:/DOKUME~1/OSTOEN~2/LOKALE~1/Temp/ccCC.s: Assembler messages: C:/DOKUME~1/OSTOEN~2/LOKALE~1/Temp/ccCC.s:5: Error: unknown pseudo-op: `.hidden' I am using a MinGW32 build of GCC, so I am not quite sure, if thise feature is for MinGW32, but if it won't work for MinGW32, it should be disabled. Here is my specs: Using built-in specs. Target: i686-pc-mingw32 Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc --build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32 --enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld --enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared --disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile --enable-libgcj-mingw-osapi=ansi Thread model: win32 gcc version 4.0.0 20050324 (prerelease) -- Summary: visibilty options don't work Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliverst at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20791
[Bug other/20791] visibilty options don't work
-- What|Removed |Added GCC host triplet||i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20791
[Bug fortran/17229] parser confused by arithmetic if inside an if
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-06 13:52 --- Paul: Before I changed the severity field, it was enhancement. All: I was a patch for this one, I will polish the testcase a bit and post it in a few days. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-04-06 12:38:33 |2005-04-06 13:52:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17229
[Bug other/20792] New: [4.1 Regression] target.opt messages missing from gcc.pot
If gcc.pot is regenerated on mainline, the help information for options moved to .opt files, other than those for the current target, are missing from the generated gcc.pot file. A special version of options.c with the messages for all languages and targets may need generating for the use of exgettext. The same problem applies for lang.opt files on the 4.0 branch - messages for languages which aren't enabled are missing from gcc.pot - though it can be worked around by enabling all languages, if the system used has all the prerequisites for all languages. If there is a safe fix, I think it should be applied to 4.0 branch as well to avoid problems with missing messages there. -- Summary: [4.1 Regression] target.opt messages missing from gcc.pot Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,rsandifo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20792
[Bug target/20726] gcc-4.0.0_beta20050326 failed to build
--- Additional Comments From selecter at spray dot se 2005-04-06 14:01 --- Fixincludes is running on compilation, but I had to patch pthread manually. It's gentoo problem - they do not support gcc-4.0.0 yet. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20726
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Additional Comments From liu_gw at 163 dot com 2005-04-06 14:10 --- (From update of attachment 8546) gcc v3.4.3: gcc/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug tree-optimization/20076] [3.3/3.4 Regression] __builtin_return(__builtin_apply()) inlined incorrectly
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-06 14:18 --- gcc.dg/builtin-apply4.c execution test is failing on mainline on ia64-hpux. gcc-testresults also shows it failing on 4.0 branch on ia64-linux. -- What|Removed |Added CC||jakub at gcc dot gnu dot ||org, jsm28 at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20076
[Bug bootstrap/20783] [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-06 14:21 --- This goes away when --disable-checking is specified for 4.0 and 4.1. Closing as invalid. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20783
[Bug other/20792] [4.1 Regression] target.opt messages missing from gcc.pot
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-04-06 14:28 --- Thanks for the heads-up. Will try to fix this ASAP. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-06 14:28:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20792
[Bug middle-end/20793] New: allocate_initial_values does not adjust register liveness information
When ALLOCATE_INITIAL_VALUE, allocate_initial_values will replace a pseudo with a machine-defined value, but it won't update the register liveness information. This can lead to incorrect global allocations. An incomplete conflict list can be observed compiling execute/pr17377.c at -O2 for sh64-elf. If this leads to an actual execution failure depends on details of if-conversion, the machine description and register allocation, which are subject to change. -- Summary: allocate_initial_values does not adjust register liveness information Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20793
[Bug c/20794] New: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
extern void abort (void);
typedef int T __attribute__((aligned));
struct S { T a[2]; } s;
void *p[2];
int
main (void)
{
p[0] = s.a[0];
p[1] = s.a[1];
if (p[0] == p[1])
abort ();
return 0;
}
is miscompiled on at least i386, x86_64, ppc32 and ppc64, at all optimization
levels. Works correctly in C++.
--
Summary: [4.0/4.1 Regression] Miscompilation with __attribute
((aligned))
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
14:52 ---
I want to say this is a middle-end problem as the trees look ok:
p[0] = s.a[0]{lb: 0 sz: 0};
D.1140 = s.a[1]{lb: 0 sz: 0};
p[1] = D.1140;
D.1141 = p[0];
D.1142 = p[1];
if (D.1141 == D.1142) goto L0; else goto L1;
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-06 14:52:28
date||
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug c++/20795] New: ICE in assign_parms
struct S { union {} a; } __attribute__((aligned));
void check (struct S arg)
{
}
ICEs on x86-64 at any optimization level. Works fine in C.
--
Summary: ICE in assign_parms
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20795
[Bug fortran/17229] parser confused by arithmetic if inside an if
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-06 14:57 --- Patch proposed here: http://gcc.gnu.org/ml/fortran/2005-04/msg00104.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17229
[Bug middle-end/20795] ICE in assign_parms
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 14:57 --- Even though this is only seen with the C++ front-end, I would almost think this is a middle-end problem. -- What|Removed |Added Component|c++ |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20795
[Bug c++/20796] New: -Wunused warns for variable passed to constructor via function-style cast
With -Wunused, this:
struct A { A(int); };
struct S { S(A); };
void f()
{
int i = 0;
S s(A(i));
}
generates a spurious warning:
test.cpp: In function `void f()':
test.cpp:5: warning: unused variable `int i'
(Happens in Debian's 3.3.5-12, 3.4.3-12, 4.0-0pre9)
--
Summary: -Wunused warns for variable passed to constructor via
function-style cast
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: timb at bluearc dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-linux
GCC host triplet: i486-linux
GCC target triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20796
[Bug other/20791] visibilty options don't work
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 15:03 --- Did you build GCC your self? If not, did you get the version of binutils that the person was offering. And yes we have a check while configuring to enable/disabling visiblity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20791
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-06 15:05
---
Doesn't need to be in struct, and the requested alignment must be bigger
than sizeof (int) to reproduce.
extern void abort (void);
typedef int T __attribute__((aligned (8)));
T a[2];
void *p[2];
int
main (void)
{
p[0] = a[0];
p[1] = a[1];
if (p[0] == p[1])
abort ();
return 0;
}
fails as well.
Note that the requested alignment is apparently honored by neither GCC 3.4 and
earlier in C, nor in G++ (3.4 as well as 4.0) for the individual array members,
only the whole array is aligned as if the attribute was present on the array
itself, not on the member type.
So we probably first need to answer whether that layout is correct or if we want
an ABI change here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug middle-end/20793] allocate_initial_values does not adjust register liveness information
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-06 15:09 --- Created an attachment (id=8550) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8550action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20793
[Bug fortran/20786] Can't use AINT intrinsic with KIND parameter
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 15:11 --- Confirmed, the problem is most likely we are missing a fold_convert somewhere converting from double down to float (sorry for using C types but it makes it easier sometimes). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-06 15:11:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20786
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-06 15:13 --- This only happens with -O2. -O is a reasonable workaround for the time being. -- What|Removed |Added Last reconfirmed|2005-03-23 19:29:03 |2005-04-06 15:13:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 15:18 --- (In reply to comment #26) (From update of attachment 8546) gcc v3.4.3: gcc/parser.c I should note this bug is suspended. This is because the standard is unclear at what is the correct behavior. See DR 325 for all the details. -- What|Removed |Added CC||liu_gw at 163 dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug AWT/20790] libjawt.so must be renamed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06 15:19 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-06 15:19:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20790
