Re: GCC 4.1.1 Released
Mark Mitchell wrote: GCC 4.1.1 has been released. This release is a bug-fix release for problems in GCC 4.0.2. GCC 4.1.1 contains changes to correct regressions from previous releases, but no new features. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in the gcc/gcc-4.1.1 subdirectory. If you encounter any difficulties using GCC 4.1.1, please do not send them directly to me. Instead, please http://gcc.gnu.org/ for information about getting help and filing problem reports. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Im confused.
Re: Segment registers support for i386
You won't be able to. You're going to need to write your own code that, during the conversion of the tree to RTL, creates RTL expressions which indicate that the memory references use segment registers. This probably won't be easy since there are a lot of contexts where your far pointer can be used. I suspect this is where you're going to give up on your project, but if you do then RTL expressions you'll need to create should probably look like: (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var))) After getting GCC to generate expressions like these, then it's a realtively simple case of modifying ix86_decompose_address() to handle the unspec. You might also need to change other backend code for handling addresses. Ross Ridge Thanks for your precisions. -- Rémy SaissyJabberID: [EMAIL PROTECTED] Web: http://remysaissy.free.fr L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années, mais celui qui a le plus senti la vie. J.-J. Rousseau, Emile.
Gosh, GCC 3.4.6 does so exist...
Dear List, do you all remember this? Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html if your memory needs to be jogged. two months and a few hours on... has anything changed? Is Gabriel Dos Reis still looking into this, or has he been hit by a bus? Bernard Leak -- Thinking of making this message a monthly cron job
[wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
On 26 May 2006 11:10, Bernard Leak wrote: Dear List, do you all remember this? Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html if your memory needs to be jogged. two months and a few hours on... has anything changed? Is Gabriel Dos Reis still looking into this, or has he been hit by a bus? Guess he must have been[*], it really only needed a few minutes to fix. Suppose we could all demand Gaby be removed from RMship of the closed extinct and dead as a dodo 3.4 series but what would be the point? Anyway, how does this look to everyone? 2006-05-26 Dave Korn [EMAIL PROTECTED] * htdocs/index.html: Updated for 3.4.6 release and series closure. * htdocs/gcc-3.4/changes.html: Likewise. * htdocs/gcc-3.4/index.html: Likewise. cheers, DaveK [*] - Or just possibly a hippo fell out of the sky and landed on him. Unlikely, but it could happen. -- Can't think of a witty .sigline today release-346-web.diff Description: Binary data
Re: [wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
Dave, don't forget to send a mail to gcc-announce. No announce has been sent yet: http://gcc.gnu.org/ml/gcc-announce/2006/ http://gcc.gnu.org/ml/gcc-announce/2005/ Cheers, Manuel. On 26/05/06, Dave Korn [EMAIL PROTECTED] wrote: On 26 May 2006 11:10, Bernard Leak wrote: Dear List, do you all remember this? Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html if your memory needs to be jogged. two months and a few hours on... has anything changed? Is Gabriel Dos Reis still looking into this, or has he been hit by a bus? Guess he must have been[*], it really only needed a few minutes to fix. Suppose we could all demand Gaby be removed from RMship of the closed extinct and dead as a dodo 3.4 series but what would be the point? Anyway, how does this look to everyone? 2006-05-26 Dave Korn [EMAIL PROTECTED] * htdocs/index.html: Updated for 3.4.6 release and series closure. * htdocs/gcc-3.4/changes.html: Likewise. * htdocs/gcc-3.4/index.html: Likewise. cheers, DaveK [*] - Or just possibly a hippo fell out of the sky and landed on him. Unlikely, but it could happen. -- Can't think of a witty .sigline today
RE: [wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
On 26 May 2006 12:16, Manuel López-Ibáñez wrote: Dave, don't forget to send a mail to gcc-announce. No announce has been sent yet: http://gcc.gnu.org/ml/gcc-announce/2006/ http://gcc.gnu.org/ml/gcc-announce/2005/ Cheers, Manuel. Don't know if I have the authority to do that. Anyone can offer up a patch, but I am not the RM and don't suppose it would accept mails from me. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC 4.1.1 Released
Roberto Bagnara wrote: Mark Mitchell wrote: GCC 4.1.1 has been released. This release is a bug-fix release for problems in GCC 4.0.2. GCC [...] Do you mean a bug-fix release for problems in GCC 4.1.0? Yup. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
reload bug in 3.4.6
I've got a bug with gcc-3.4.6 (also with 3.3.2, 3.3.6, probably
anything inbetween), target sh-elf. Unfortunately, the test case is
huge, convoluted and proprietary, so I can't send it for now.
When reloading insn 2780:
Breakpoint 3, reload_as_needed (live_known=1)
at ../../gcc-3.4.6/gcc/reload1.c:3802
(gdb) p insn
$3 = (rtx) 0x2b202910
(gdb) call debug_rtx (insn)
(insn:HI 2780 2777 2782 1 (set (reg/f:SI 1726)
(plus:SI (reg/f:SI 1706)
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
(gdb) call debug_rtx (reg_equiv_memory_loc [1726])
(mem:SI (plus:SI (reg/f:SI 14 r14)
(const_int 156 [0x9c])) [16 S4 A32])
After calling ``eliminate_regs_in_insn()'':
(gdb) call debug_rtx (insn)
(insn:HI 2780 2777 2782 1 (set (reg/f:SI 1726)
(plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
After calling ``find_reloads()'' and ``choose_reload_regs()'':
(gdb) call debug_reload ()
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
reload_out (SI) = (mem:SI (plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 32 [0x20])) [16 S4 A32])
GENERAL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
reload_out_reg: (reg/f:SI 1726)
reload_reg_rtx: (reg:SI 3 r3)
(gdb) call debug_rtx (insn)
(insn:HI 2780 2777 2782 1 (set (mem:SI (plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 32 [0x20])) [16 S4 A32])
(plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
After calling ``emit_reload_insns()'' the relevant insns are:
(insn 22940 2777 22941 1 (set (reg:SI 3 r3)
(const_int 124 [0x7c])) -1 (nil)
(nil))
(insn 22941 22940 2780 1 (set (reg:SI 3 r3)
(plus:SI (reg:SI 3 r3)
(reg/f:SI 14 r14))) 23 {*addsi3_compact} (nil)
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(nil)))
(insn:HI 2780 22941 22942 1 (set (mem:SI (plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 32 [0x20])) [16 S4 A32])
(plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
(insn 22942 2780 2782 1 (set (mem:SI (plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 32 [0x20])) [16 S4 A32])
(reg:SI 3 r3)) -1 (nil)
(nil))
So far so good. Note that in insn 22942, r3 is saved in [r14 + 156].
However, after calling ``subst_reloads()'', the insns become:
(insn 22940 2777 22941 1 (set (reg:SI 3 r3)
(const_int 124 [0x7c])) -1 (nil)
(nil))
(insn 22941 22940 2780 1 (set (reg:SI 3 r3)
(plus:SI (reg:SI 3 r3)
(reg/f:SI 14 r14))) 23 {*addsi3_compact} (nil)
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(nil)))
(insn:HI 2780 22941 22942 1 (set (reg:SI 3 r3)
(plus:SI (reg:SI 3 r3)
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
(insn 22942 2780 2782 1 (set (mem:SI (plus:SI (reg:SI 3 r3)
(const_int 32 [0x20])) [16 S4 A32])
(reg:SI 3 r3)) -1 (nil)
(nil))
Now r3 is stored at [r14 + 160], which is incorrect. The reason is
that when substituting the reload register into insn 2780, the insn
22942 is modified also, because they share the following rtx: (plus:SI
(reg/f:SI 14 r14) (const_int 124 [0x7c])). Since insn 2780 modifies
r3, r3 is no longer equal to ``r14 + 124'' at insn 22942, which
results in incorrect store.
I'd appreciate any suggestions for fixing this.
~velco
IA-64 speculation patches have bad impact on ARM
Hi Maxim and Vlad,
I just tracked an ICE while building glibc for ARM to this patch,
which introduced --param max-sched-extend-regions-iters with a default
of two:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html
The testcase is attached; an arm-linux-gnueabi compiler should be able to
reproduce it with -p -O2. The failure is inability to find two consecutive
registers to hold a DImode value. The cause is roughly like this:
DImode add;
if (({complicated asm with many local register variables}))
return 0;
The register variables get lifted out of the if statement and moved before
the add, thus occupying basically all available hard registers.
If it were just that, I might try to cobble around it in glibc. But there's
actually another layer:
if (DImode compare)
{
DImode add;
if (({complicated asm with many local register variables}))
return 0;
...
}
The register variables and their initializations get hoisted all the way out
of the first if. On ia64, with a million execution units to spare and a
fat pipeline, this may make sense. On targets with a simpler execution
model, though, it's pretty awful. If the condition (which we have no
information on the likelihood of) is false, we've added lots of cycles for
no gain. It's not like the scheduler was filling holes; the initializations
were scheduled as early as possible because they had no dependencies.
With the parameter turned back down to one, the testcase compiles, and the
code looks sensible again. No, I wasn't able to work out why profiling was
necessary to trigger this problem; I suspect it makes some register
unavailable, but I'm not sure which. I didn't look into that further.
What's your opinion? We could easily change the default of the parameter
for ARM, but I assume there are other affected targets. I don't know if we
need the extended region scheduling to be smarter, or if it should simply be
turned off for some targets.
--
Daniel Jacobowitz
CodeSourcery
typedef union
{
struct
{
int __lock;
unsigned int __futex;
__extension__ unsigned long long int __total_seq;
__extension__ unsigned long long int __wakeup_seq;
} __data;
}
pthread_cond_t;
__pthread_cond_signal (cond)
pthread_cond_t *cond;
{
if (cond-__data.__total_seq cond-__data.__wakeup_seq)
{
++cond-__data.__wakeup_seq;
if (!__builtin_expect (({
do { } while (0);
long int __ret;
__ret = ({
register int _a1 asm (r0), _nr asm (r7);
register int _v2 asm (v2) = (int)(((4 24) | 1));
register int _v1 asm (v1) = (int)((cond-__data.__lock));
register int _a4 asm (a4) = (int)((1));
register int _a3 asm (a3) = (int)((1));
register int _a2 asm (a2) = (int)(5);
_a1 = (int) ((cond-__data.__futex));
_nr = ((0 + 240));
asm volatile (swi 0x0 @ syscall SYS_ify(futex)
: =r (_a1)
: r (_nr), r (_a1), r (_a2),
r (_a3), r (_a4), r (_v1), r (_v2)
: memory);
_a1;});
__ret;}), 0))
return 0;
}
}
RE: reload bug in 3.4.6
On 26 May 2006 16:23, Momchil Velikov wrote: Now r3 is stored at [r14 + 160], which is incorrect. The reason is that when substituting the reload register into insn 2780, the insn 22942 is modified also, because they share the following rtx: (plus:SI (reg/f:SI 14 r14) (const_int 124 [0x7c])). Since insn 2780 modifies r3, r3 is no longer equal to ``r14 + 124'' at insn 22942, which results in incorrect store. I'd appreciate any suggestions for fixing this. Unsharing the rtx sounds like the right thing to do to me; the internals docs Structure sharing assumptions says things like * No RTL object appears in more than one place in the RTL structure except as described above. Many passes of the compiler rely on this by assuming that they can modify RTL objects in place without unwanted side-effects on other insns. and by the time we're in reload that should definitely be the case for a complex binary operator. How did they get to be shared in the first place? That's probably the underlying cause of the bug. cheers, DaveK -- Can't think of a witty .sigline today
gcc binary for fc1
I am trying to compile the source for gcc, but do not yet have gcc. I am on a fc1 machine and have been googling for hours at the clients site, trying to find out what I need and where to get it. can anyone help me in figuring out how to get a compiler onto a fc1 machine with _no_compiler? thanks in advance, -JP
RE: gcc binary for fc1
On 26 May 2006 15:48, Dude VanWinkle wrote: I am trying to compile the source for gcc, but do not yet have gcc. I am on a fc1 machine and have been googling for hours at the clients site, trying to find out what I need and where to get it. can anyone help me in figuring out how to get a compiler onto a fc1 machine with _no_compiler? Well, yes, that's easy; first you need to get a compiler onto it, and then you can build a compiler with it :) So, given that FC1 is a linux distribution, perhaps you can download a binary rpm for it, and then build your own version of the compiler with that? Or, just for kicks, you could take a different machine that already has a compiler, and build a cross-compiled gcc for the fc1 box. cheers, DaveK -- Can't think of a witty .sigline today
Cygwin c++ vs windows or unix socket layer
Hi all, I've stumbled across a small problem. As you may know, cygwin attempts to give the user a free choice of using the winsock API, with SOCKETs being handles not fds, and ioctlsocket and closesocket and so on, or using the posix sockets API, and having sockets being fds just like any other file, using the same ioctl and close functions, etc. etc. This doesn't work well in C++ at the moment, because of a clash between headers; winsock defines gethostname to take an int as the second argument, while cygwin's unistd.h defines it as taking an unsigned int. Normally the solution to this would be to only use one or the other kind of socket library and not attempt to mix the two in one program. Unfortunately, if you include any of the C++ i/o stream related headers, that includes c++io.h, which includes gthr.h and hence gthr-default.h; and gthr-default.h unconditionally #includes unistd.h. (Note that gthr-posix.h could cause the same problem, if you've explicitly requested posix threads by defining _GLIBCXX__PTHREADS). So the upshot is that if you use C++ i/o streams you get unistd.h included and that defines the posix version of gethostname and then you can't include (or use) the winsock stuff instead; i.e. cygwin's c++ compiler does not currently support allowing the choice of socket library. There's no problem in C, because you're not forced to include the gthreads headers to support standard library functions; it's just that the C++ i/o classes need to know about mutex functionality in order to be threadsafe. A patch like this makes it work for me, and I was wondering if anyone else has had this problem and if I should include it in the next release of cygwin gcc when it comes out. According to the svn logs, the reason gthr-default/posix.h needs to include unistd is solely to get the feature test macros; although posix expects them to be available /through/ unistd.h I think we're still ok by having it as a separate subinclude file and that does give us the advantage of being able to pull them in without all the hundreds and thousands of random unrelated stuff that the full unistd.h has. I've Cc'd the gcc list because, although this is primarily a cygwin issue, and an artifact of the way we try to support two clashing environments, a) someone might know some more important reason why gthr-default really does need the unistd function prototypes, or b) others might also feel that implicitly including unistd.h and thus pulling in a bunch of network/socket related symbols into every C++ io stream-related header file is a bit overly namespace-polluting. c) something else, that I haven't thought of :) --- gthr-default.h 2006-05-26 16:59:57.917146100 +0100 +++ gthr-default.h.new 2006-05-26 17:00:26.307771100 +0100 @@ -41,7 +41,11 @@ Software Foundation, 59 Temple Place - S #endif #include pthread.h +#ifdef __CYGWIN__ +#include features.h +#else #include unistd.h +#endif typedef pthread_key_t __gthread_key_t; typedef pthread_once_t __gthread_once_t; [EMAIL PROTECTED] /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin/bits cheers, DaveK -- Can't think of a witty .sigline today
make install-info no longer works
Has anyone seen http://sources.redhat.com/bugzilla/show_bug.cgi?id=2701 It looks like the result of merging of intl from gcc. It doesn't work for me in gcc either: make[2]: Leaving directory `/export/build/gnu/gcc/build-i686-linux/intl' Doing install-info in intl make[2]: Entering directory `/export/build/gnu/gcc/build-i686-linux/intl' make[2]: *** No rule to make target `install-info'. Stop. make[2]: Leaving directory `/export/build/gnu/gcc/build-i686-linux/intl' make[1]: *** [install-info-intl] Error 1 make[1]: Leaving directory `/export/build/gnu/gcc/build-i686-linux' make: *** [do-install-info] Error 2 [EMAIL PROTECTED] build-i686-linux]$ H.J.
The Linux binutils 2.17.50.0.2 is released
This is the beta release of binutils 2.17.50.0.2 for Linux, which is based on binutils 2006 0526 in CVS on sources.redhat.com plus various changes. It is purely for Linux. The new x86_64 assembler no longer accepts monitor %eax,%ecx,%edx You should use monitor %rax,%ecx,%edx or monitor which works with both old and new x86_64 assemblers. They should generate the same opcode. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.17.50.0.2 to [EMAIL PROTECTED] and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.17.50.0.1: 1. Update from binutils 2006 0526. 2. Change the x86-64 maximum page size to 2MB. 3. Support --enable-targets=all for 64bit target and host (PR 1485). 4. Properly update CIE/FDE length and align section for .eh_frame section (PR 2655/2657). 5. Properly handle removed ELF section symbols. 6. Fix an ELF linker regression introduced on 2006-04-21. 7. Fix an segfault in PPC ELF linker (PR 2658). 8. Speed up the ELF linker by caching the result of kept section check. 9. Properly create stabs section for ELF. 10. Preserve ELF program header when copying ELF files. 11. Properly handle ELF SHN_LOPROC/SHN_HIOS when checking section index (PR 2607). 12. Misc mips updates. 13. Misc arm updates. 14. Misc xtensa updates. 15. Fix an alpha assembler warning (PR 2598). 16. Fix assembler buffer overflow. 17. Properly disassemble sgdt/sidt for x86-64. Changes from binutils 2.16.91.0.7: 1. Update from binutils 2006 0427. 2. Fix an objcopy regression (PR 2593). 3. Reduce ar memory usage (PR 2467). 4. Allow application specific ELF sections (PR 2537). 5. Fix an i386 TLS linker bug (PR 2513). 6. Speed up ia64 linker by 1300X in some cases (PR 2442). 7. Check illegal immediate register operand in i386 assembler (PR 2533). 8. Fix a strings bug (PR 2584). 9. Better handle corrupted ELF files (PR 2257). 10. Fix a MIPS linker bug (PR 2267). Changes from binutils 2.16.91.0.6: 1. Update from binutils 2006 0317. 2. Support Intel Merom New Instructions in assembler/disassembler. 3. Support Intel new instructions in Montecito. 4. Fix linker --as-needed (PR 2434). 5. Fix linker -s regression (PR 2462). 6. Fix REP prefix for string instructions in x86 disassembler (PR 2428). 7. Fix the weak undefined symbols in PIE (PR 2218). 8. Fix 2 DWARF reader bugs (PRs 2443, 2338). 9. Improve ELF linker error message (PR 2322). 10. Avoid abort with dynamic symbols in 64K sections (PR 2411). 11. Handle mismatched symbol types for executables (PR 2404). 12. Avoid a linker linkonce regression (PR 2342). Changes from binutils 2.16.91.0.5: 1. Update from binutils 2006 0212. 2. Correct Linux linker search order for DT_NEEDED entries (PR 2290). 3. Fix the x86-64 disassembler for control/debug register moves. 4. Properly handle ELF strip/objcopy with unmodified program header (PR 2258). 5. Improve ELF linker error handling when there are not enough room for program headers (PR 2322). 6. Properly handle weak undefined symbols in PIE (PR 2218). 7. Support new i386/x86-64 TLS relocations. 8. Fix addr2line for linux kernel (PR 2096). 9. Fix an assembler memory leak with --statistics. 10. Avoid an ia64 assembler regression (PR 2117). Changes from binutils 2.16.91.0.4: 1. Update from binutils 2005 1219. 2. Fix a MIPS linker regression (PR 1932). 3. Fix an objcopy bug for ia64 (PR 1991). 4. Fix a linker crash on bad input (PR 2008). 5. Fix 64bit monitor and mwait (PR 1874). Changes from binutils 2.16.91.0.3: 1. Update from binutils 2005 . 2. Fix ELF orphan section handling (PR 1467) 3. Fix ELF section attribute handleing (PR 1487). 4. Fix IA64 unwind info dump for relocatable files. (PR 1436). 5. Add DWARF info dump to objdump. 6. Fix SHF_LINK_ORDER handling (PR 1321). 7. Don't allow
[Bug target/27767] Problem: gcc 4.0.3 on Unix_SV
--- Comment #2 from mirko dot bruzzone at primeur dot com 2006-05-26 07:33 --- (In reply to comment #1) Good morning, I tried to compile the gcc version 4.0.3 on this platform: UNIX_SV ulisse 4.0 3.0 3425/3482/3485 Pentium III(TM)-ISA/PCI On the system there is an old gcc and its version is: 2.7.2.3 I had a problem when I compiled this source: c-pragma.c In file included from /usr1/bruzzonem/gcc-4.0.3/gcc/c-pragma.c:707: gt-c-pragma.h:46: parse error before `__attribute__' Could you help me to understand this error? Best regards, Mirko Bruzzone (In reply to comment #1) On the system there is an old gcc and its version is: 2.7.2.3 Ick. What is Unix_SV? Is it a product of SCO? Because I don't know how much support if it is old. Second there is not enough info here on what is going on. How did you configure and invoke make? Unix_SV is NCR I executed this command: uname -a and the information are: UNIX_SV ulisse 4.0 3.0 3425/3482/3485 Pentium III(TM)-ISA/PCI Of course, I executed in the farmer ./configure and in the latter make. So, I don't have any other information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27767
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #6 from bonzini at gnu dot org 2006-05-26 07:46 ---
There are indeed differences in the generated code.
aj_f_times2 is equal without and with the patch.
aj_d_times2 has this (left = old, right = patched):
movsd %xmm0, -40(%rbp) | movsd %xmm0, -32(%rbp)
movq-40(%rbp), %rax | movsd %xmm1, -24(%rbp)
movsd %xmm1, -40(%rbp)
movq-40(%rbp), %rdx
movq%rax, -32(%rbp)
movq%rdx, -24(%rbp)
This is just better code.
The miscompiled function is aj_ld_times2, which is like this (some code moved
for clarity):
fldt16(%rbp) fldt16(%rbp)
fadd%st(0), %stfadd%st(0), %st
fstpt -48(%rbp) fstpt -48(%rbp)
So far so good.
movq-32(%rbp), %raxmovq-32(%rbp), %rax
movl-24(%rbp), %edxmovl-24(%rbp), %edx
movq%rax, -32(%rbp)movq%rax, -32(%rbp)
movl%edx, -24(%rbp)movl%edx, -24(%rbp)
Useless, and also accessing uninitialized memory, but this is -O0.
fldt32(%rbp) fldt32(%rbp)
fadd%st(0), %stfadd%st(0), %st
fstpt -32(%rbp) fstpt -32(%rbp)
Also good.
movq-48(%rbp), %raxmovq-48(%rbp), %rax
movl-40(%rbp), %edxmovl-40(%rbp), %edx
movq%rax, -48(%rbp)movq%rax, -48(%rbp)
movl%edx, -40(%rbp)movl%edx, -40(%rbp)
Useless.
movq-48(%rbp), %raxmovq-48(%rbp), %rax
movl-40(%rbp), %edxmovl-40(%rbp), %edx
movq-32(%rbp), %rcxmovq-32(%rbp), %rcx
movl-24(%rbp), %ebxmovl-24(%rbp), %ebx
These are -O0 stupidities.
flds.LC0(%rip)
fstp%st(0)
fstp%st(1)
I don't have a clue what this is for. What is .LC0? The only thing I'm sure
about, is that this causes a stack underflow...
movq%rax, -64(%rbp)movq%rax, -64(%rbp)
movl%edx, -56(%rbp)movl%edx, -56(%rbp)
fldt-64(%rbp) fldt-64(%rbp)
movq%rcx, -64(%rbp)movq%rcx, -64(%rbp)
movl%ebx, -56(%rbp)movl%ebx, -56(%rbp)
fldt-64(%rbp) fldt-64(%rbp)
flds.LC0(%rip)
fstp%st(0)
fstp%st(1)
... the bug is that it is moved afterwards, after the result was loaded on the
stack, and the underflowing fstp clobbers the return value.
The wrong instruction is produced by a (clobber (reg/i:XC 8 st)). The patched
GCC moves the clobber later. The RTL produced by the patched GCC is sane until
flow2, and the messed up by the stack register conversion pass:
(insn 41 57 58 3 (set (reg:XF 10 st(2) [orig:66 result ] [66])
(mem/c:XF (plus:DI (reg/f:DI 6 bp)
(const_int -64 [0xffc0])) [0 S16 A8])) 99
{*movxf_integer} (nil)
(nil))
...
(insn 43 59 25 3 (set (reg:XF 11 st(3) [orig:67 result+16 ] [67])
(mem/c:XF (plus:DI (reg/f:DI 6 bp)
(const_int -64 [0xffc0])) [0 S16 A8])) 99
{*movxf_integer} (nil)
(nil))
(note 25 43 28 3 NOTE_INSN_FUNCTION_END)
(insn 28 25 29 3 (clobber (reg/i:XC 8 st)) -1 (nil)
(nil))
(insn 29 28 30 3 (set (reg:XF 8 st [ result ])
(reg:XF 10 st(2) [orig:66 result ] [66])) 99 {*movxf_integer} (nil)
(nil))
(insn 30 29 35 3 (set (reg:XF 9 st(1) [+16 ])
(reg:XF 11 st(3) [orig:67 result+16 ] [67])) 99 {*movxf_integer}
(nil)
(nil))
(insn 35 30 64 3 (use (reg/i:XC 8 st)) -1 (nil)
(nil))
Latent bug in stack, CCing sayle.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC||sayle at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug c++/27771] New: inlined return not optimized, overfullfills ABI calling convention
I know that the ABI calling convention require that function results are returned as integers, even if the function result is known as (short)byte-value. But if a function with its return is inlined, i can't see any reason to (over)fullfill this convention. At least with optimizing compilation the high-byte-treatement should be omitted. The waste of space and time hits especialy hard in small functions, as just return an ojects property. Unfortunately the superfluous technical overhead must, at least for microcontroler-targets influence design decisions, e.g. inline function versus #define macro, which should be taken on logical facts. This problem is not specific for c++, it also hits C, in any optimazion-level. Excuse me, I couln't find a related bug, but I'm not shure if there is one, though. -- Summary: inlined return not optimized, overfullfills ABI calling convention Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: familie dot glaser at web dot de GCC host triplet: WIN GCC target triplet: AVR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-26 08:31 --- (In reply to comment #18) This patch is beyond my current understanding, so someone else needs to look at it. I think our best chance here is to find the exact patch that broke it. You said it's between r113373 and r113396. The revisions that could have introduced it (on a material basis, not speaking of how likely it is) are: r113375, r113376, r113378, r113382, r113388, r113389, r113395. It might be r113395 that did it: * config/rs6000/rs6000.c (rs6000_override_options): Enable TARGET_NO_FP_IN_TOC for section anchors. (optimization_options): Enable section anchors for all non-Objective languages. As I don't fully understand what this means, I'm adding dje to the Cc list. Maybe r113394 is worth testing, could someone do that? (i'm in no position to do any testing right now) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug c++/27771] inlined return not optimized, overfullfills ABI calling convention
--- Comment #1 from familie dot glaser at web dot de 2006-05-26 08:34 --- Created an attachment (id=11513) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11513action=view) preprocessed c++-example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
[Bug c++/27771] inlined return not optimized, overfullfills ABI calling convention
--- Comment #2 from familie dot glaser at web dot de 2006-05-26 08:37 --- Created an attachment (id=11514) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11514action=view) assembler-listing with markup-comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
[Bug middle-end/27743] [4.1 Regression] Wrong code for ((unsigned) ((a) 2)) 15
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-05-26 09:53 --- Subject: Bug 27743 Author: rguenth Date: Fri May 26 09:53:01 2006 New Revision: 114128 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114128 Log: 2006-05-26 Richard Guenther [EMAIL PROTECTED] PR middle-end/27743 * fold-const.c (fold_binary): Do not look at the stripped op0 for (a OP c1) OP c2 to a OP (c1+c2) shift optimization. * gcc.dg/torture/pr27743.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr27743.c - copied unchanged from r114112, trunk/gcc/testsuite/gcc.dg/torture/pr27743.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27743
[Bug middle-end/27743] [4.1 Regression] Wrong code for ((unsigned) ((a) 2)) 15
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-05-26 09:53 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27743
[Bug java/27756] ICE in update_aliases, at java/decl.c:192
--- Comment #5 from aph at gcc dot gnu dot org 2006-05-26 10:20 ---
I have found the real cause of these weird non-nested variable ranges.
It's because ecj reorganizes for loops in this way:
for (a; b; c)
{
foo;
}
becomes
goto barf;
do
{
foo;
c;
barf:
a;
if (!b)
goto x;
} forever;
x:
And this movement of the for body causes variable ranges to be discontinuous.
Duplicate variable definitions are issued.
It would be very nice if ecj could be prevented from doing this, at least for
the purpose of acting as a gcj front end.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-05-26 10:20:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27756
[Bug java/27756] ICE in update_aliases, at java/decl.c:192
--- Comment #6 from aph at gcc dot gnu dot org 2006-05-26 10:23 ---
Err, I mean:
a;
goto barf;
do
{
foo;
c;
barf:
if (!b)
goto x;
} forever;
x:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27756
[Bug target/27772] New: mr instruction with odd-numbered register created
I get testsuite failures in mpfr compiling for s390 with /usr/lib/gcc/s390-suse-linux/4.1.0/cc1 -fpreprocessed mul.i -quiet -dumpbase mul.c -march=z900 -mtune=z9-109 -m31 -mesa -auxbase mul -O2 -Wall -version -fmessage-length=0 -fPIC -o mul.s s390z27:/usr/src/packages/BUILD/mpfr-2.2.0/tests# LD_LIBRARY_PATH=../.libs/ gdb .libs/tcheck GNU gdb 6.4.90.20060522 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as s390-suse-linux...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /usr/src/packages/BUILD/mpfr-2.2.0/tests/.libs/tcheck Program received signal SIGILL, Illegal instruction. 0x400c0902 in mpfr_mul () from ../.libs/libmpfr.so.1 (gdb) disassemble ... 0x400c08f6 mpfr_mul+802: sra %r5,31 0x400c08fa mpfr_mul+806: l %r1,0(%r3) 0x400c08fe mpfr_mul+810: lr %r4,%r2 0x400c0900 mpfr_mul+812: mr %r3,%r1 0x400c0902 mpfr_mul+814: nr %r5,%r1 0x400c0904 mpfr_mul+816: sra %r1,31 0x400c0908 mpfr_mul+820: ar %r5,%r3 0x400c090a mpfr_mul+822: nr %r2,%r1 where the only thing I notice is 'mr %r3,%r1' which seems to contradict the requirement of an even-numbered register for the destination argument. Note that even with -march=g5 odd-numbered target registers are produced for mr. I'll attach preprocessed source for mul.i. -- Summary: mr instruction with odd-numbered register created Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: s390-ibm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27772
[Bug target/27772] mr instruction with odd-numbered register created
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-26 10:32 --- Created an attachment (id=11515) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11515action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27772
[Bug c++/27771] inlined return not optimized, overfullfills ABI calling convention
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-26 11:00 --- Works for me without all the volatile crap. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #7 from berndtrog at yahoo dot com 2006-05-26 11:15 --- This bug is target independent. I see the same behaviour for --target=mingw32. Workaround (for avr only): Index: mlib-utl.adb === --- mlib-utl.adb(revision 114128) +++ mlib-utl.adb(working copy) @@ -38,7 +38,7 @@ Initialized : Boolean := False; - Gcc_Name : constant String := gcc; + Gcc_Name : constant String := avr-gcc; Gcc_Exec : OS_Lib.String_Access; Ar_Name: OS_Lib.String_Access; -- berndtrog at yahoo dot com changed: What|Removed |Added GCC target triplet|avr | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug libobjc/19850] libobjc leaks threads on posix
--- Comment #2 from lcampbel at akamai dot com 2006-05-26 11:37 --- Any chance this will get fixed any time soon? I think all you have to do is to change a NULL to _objc_thread_attribs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19850
[Bug target/27571] [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
--- Comment #5 from falk at gcc dot gnu dot org 2006-05-26 12:29 --- Subject: Bug 27571 Author: falk Date: Fri May 26 12:28:40 2006 New Revision: 114130 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114130 Log: PR target/27571 * config/alpha/alpha.c (alpha_does_function_need_gp): Skip jump table data. * gcc.c-torture/compile/pr27571.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr27571.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug target/27571] [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
--- Comment #6 from falk at debian dot org 2006-05-26 12:30 --- Fixed. -- falk at debian dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug target/27772] mr instruction with odd-numbered register created
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-26 12:58
---
This looks like a source-code problem. The assembler instruction
union {DItype __ll; struct {USItype __h, __l;} __i; } __x;
__asm__ (lr %N0,%1\n\tmr %0,%2 : =r (__x.__ll)
: r (__xm0), r (__xm1));
fundamentally assumes __ll is in fact of mode DImode, as the type name
DItype suggests -- that's (on 32-bit) what causes reload to allocate a
register *pair* for the %0 operand.
However, in your mul.i file, that type is defined as:
typedef long int DItype;
which happens to be in fact SImode ...
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27772
[Bug tree-optimization/27773] New: ICE: in find_lattice_value, at tree-complex.c:133
With the attached source, gcc version 4.2.0 20060524 (experimental) gets: /usr/snp/bin/gfortran -S -O2 -ffast-math imhdiff4_pp.f imhdiff4_pp.f: In function 'imhdiff4': imhdiff4_pp.f:1: internal compiler error: in find_lattice_value, at tree-complex.c:133 Note the use of -ffast-math - without it, there's no error. -- Summary: ICE: in find_lattice_value, at tree-complex.c:133 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug tree-optimization/27773] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-05-26 13:02 --- Created an attachment (id=11516) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11516action=view) Source file showing the wrong behaviour -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug tree-optimization/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-05-26 13:06 --- Changed summary to indicate this bug is a 4.2 regression. -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Summary|ICE: in find_lattice_value, |[4.2 regression] ICE: in |at tree-complex.c:133 |find_lattice_value, at tree- ||complex.c:133 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug java/27756] ICE in update_aliases, at java/decl.c:192
--- Comment #7 from aph at gcc dot gnu dot org 2006-05-26 13:52 --- Subject: Bug 27756 Author: aph Date: Fri May 26 13:52:18 2006 New Revision: 114131 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114131 Log: 2006-05-25 Andrew Haley [EMAIL PROTECTED] PR java/27756 * decl.c (maybe_pushlevels): When variable ranges are non-nested update all lifetimes, not just the first one. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27756
[Bug java/27756] ICE in update_aliases, at java/decl.c:192
--- Comment #8 from aph at gcc dot gnu dot org 2006-05-26 13:54 --- What am I supposed to write here, anyway? It's fixed because I fixed it. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27756
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #20 from dje at gcc dot gnu dot org 2006-05-26 14:07 --- The patch you reference enables section anchors by default. Neither AIX nor PPC Linux show new Gfortran testsuite failures from the use of section anchors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug target/25758] gcc.c-torture/compile/20030921-1.c fails at -O0
--- Comment #8 from jakub at gcc dot gnu dot org 2006-05-26 14:17 --- Subject: Bug 25758 Author: jakub Date: Fri May 26 14:17:47 2006 New Revision: 114132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114132 Log: PR target/27758 Backported from mainline 2006-01-25 Andrew Pinski [EMAIL PROTECTED] PR target/25758 * config/i386/i386.c (output_pic_addr_const) case SYMBOL_REF: Use output_addr_const instead of assemble_name. * gcc.dg/pr27758.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr27758.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug target/27758] [4.1 regression] -O0 -fpic link failure
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-26 14:17 --- Subject: Bug 27758 Author: jakub Date: Fri May 26 14:17:47 2006 New Revision: 114132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114132 Log: PR target/27758 Backported from mainline 2006-01-25 Andrew Pinski [EMAIL PROTECTED] PR target/25758 * config/i386/i386.c (output_pic_addr_const) case SYMBOL_REF: Use output_addr_const instead of assemble_name. * gcc.dg/pr27758.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr27758.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27758
[Bug target/27758] [4.1 regression] -O0 -fpic link failure
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-26 14:19 --- Subject: Bug 27758 Author: jakub Date: Fri May 26 14:19:16 2006 New Revision: 114133 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114133 Log: PR target/27758 * gcc.dg/pr27758.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr27758.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27758
[Bug c++/27722] [4.0/4.1/4.2 regression] ICE incrementing an array
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:56 --- This didn't fail with 4.0.2pre, so it must be a regression on a release branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27722
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #21 from konqueror at gmx dot de 2006-05-26 14:58 --- Can this please get backportet to the 4.1 branch? This bug is still holding back some Java stuff on Debian/ia64 from being working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug c++/27714] [4.0/4.1/4.2 regression] operator new as friend in template class rejected
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:59 --- Confirmed. A regression. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2006-05-26 14:59:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27714
[Bug c++/27713] [4.0/4.1 regression] ICE on invalid operator new
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:00 --- Confirmed. A regression. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:00:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27713
[Bug c++/27689] [4.1/4.2 regression] function template incorrectly selected as candidate
--- Comment #4 from bangerth at dealii dot org 2006-05-26 15:04 --- (In reply to comment #1) I think GCC 4.2.0 is correct in saying the function call is ambiguous, bar is still a template class. Most definitely, fooint::bar is not a template class, and the only thing the call to f() can match is the '...' argument. This is a regression post 4.0.x. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.0 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:04:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27689
[Bug c++/27670] ICE on invalid template parameter
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:04 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:04:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27670
[Bug c++/27668] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:06 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:06:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug c++/27667] [4.0/4.1/4.2 regression] ICE with in-class specialization
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:06 --- Confirmed.. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:06:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27667
[Bug c++/27665] [4.0/4.1/4.2 regression] ICE writing class instead of typename
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:08 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:08:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27665
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
--- Comment #4 from bangerth at dealii dot org 2006-05-26 15:14 --- Confirmed. Though it is worth mentioning that icc has the same problem. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:14:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527
[Bug pch/27475] ICE when generate a precompiled header, and the same header is given to -include on the command-line
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:16 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |pch Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:16:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27475
[Bug c++/27465] [4.0 only] ICE on dependent const folding
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:18 --- This works fine with 4.0.2, and 4.1-pre and 4.2-pre snapshots I have here. Could you check that it works for you as well with a recent snapshot? Thanks W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27465
[Bug c++/27433] diagnostic for vector template argument is poor
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:21 --- template class A void f(A, vector A, int); You meant __vector here. Certainly, the expectation is that the vector attribute will apply to the type only after instantiation. Whether that is feasible is a different matter. I agree that for the moment, the diagnostic is not helpful. I assume this is the same matter as with alignof, etc, applied to template arguments. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27433
[Bug c++/27720] ICE with initialization of invalid variable
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:57 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 14:57:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27720
[Bug c++/27716] [4.1 regression] ICE with invalid assignment
--- Comment #5 from bangerth at dealii dot org 2006-05-26 14:58 --- Just for completeness' sake: confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 14:58:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27716
[Bug c++/27403] T() can be an integer constant but is rejected as not one
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:26 ---
gcc parses this as
template class T
typename AT ()() ::I foo (T) { return 0; }
i.e. as meaning that the argument is not an integer, but a function that
returns an integer.
A simpler testcase is this (icc accepts it, though I'm not sure who's right):
---
template int struct A {};
Aint() foo (int);
---
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27403
[Bug c++/27227] [4.0/4.1/4.2 Regression] rejects valid code with some extern C
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:28 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.2 4.1.0 Known to work||3.3.5 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:28:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug c++/27211] Bogus error template definition of non-template when there is no non-template
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:29 --- Confirmed, but low priority. One should just follow the first error message. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:29:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27211
[Bug c++/26698] g++ accepts const-incorrect code due to conversion function
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:37 --- Confirmed. We should not be calling the conversion operator. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 15:37:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug c++/25863] Allowed knowledge of private structure.
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:38 --- As mentioned before, this is legal code. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25863
[Bug tree-optimization/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug target/27758] [4.1 regression] -O0 -fpic link failure
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-26 16:15 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27758
[Bug middle-end/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-26 16:31 --- D.1024_166 = COMPLEX_EXPR zkq_165, 0.0; D.1025_167 = 1.0e+0 - D.1024_166; That is wrong, that 1.0 should be complex_cst 1.0e+0, 0.0 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug c++/27465] [4.0 only] ICE on dependent const folding
--- Comment #3 from tneumann at pi3 dot informatik dot uni-mannheim dot de 2006-05-26 16:35 --- This still happens with gcc-4.0-20060518, see the error message below. The gcc-4.[12] branches presumably work, I only tried 4.1. ./gcc4/bin/g++ -c foo.cpp foo.cpp: In member function 'unsigned int AT::foo(unsigned int)': foo.cpp:3: internal compiler error: tree check: expected class 'type', have 'type' (array_type) in operand_equal_p, at fold-const.c:2404 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- tneumann at pi3 dot informatik dot uni-mannheim dot de changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27465
[Bug middle-end/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-26 16:38 --- More reduced testcase: subroutine imhdiff4(qhat, zkq) complex qhat real zkq qhat = qhat - zkq*qhat end -- Trying to get a C testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-26 16:38:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug middle-end/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-26 16:41 ---
C testcase:
_Complex float f(_Complex float a, float b)
{
return a - a*b;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|x86_64-unknown-linux-gnu|
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug middle-end/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-26 16:44 --- This has been failing since 4.2.0 20060131. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-26 16:59 --- Woops what did I do to make this assign this to myself. Anyways I am no way at all working on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug other/27774] New: make install-info no longer works
I got [EMAIL PROTECTED] build-i686-linux]$ make install-info DESTDIR=../release make[1]: Entering directory `/export/build/gnu/gcc/build-i686-linux' Doing info in gcc make[2]: Entering directory `/export/build/gnu/gcc/build-i686-linux/gcc' make[2]: Nothing to be done for `info'. make[2]: Leaving directory `/export/build/gnu/gcc/build-i686-linux/gcc' Doing install-info in gcc make[2]: Entering directory `/export/build/gnu/gcc/build-i686-linux/gcc' /bin/sh /net/gnu-13/export/gnu/src/gcc/gcc/gcc/../mkinstalldirs ../release/usr/gcc-4.2/lib/gcc/i686-pc-linux-gnu/4.2.0 /bin/sh /net/gnu-13/export/gnu/src/gcc/gcc/gcc/../mkinstalldirs ../release/usr/gcc-4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0 /bin/sh /net/gnu-13/export/gnu/src/gcc/gcc/gcc/../mkinstalldirs ../release/usr/gcc-4.2/bin /bin/sh /net/gnu-13/export/gnu/src/gcc/gcc/gcc/../mkinstalldirs ../release/usr/gcc-4.2/include /bin/sh /net/gnu-13/export/gnu/src/gcc/gcc/gcc/../mkinstalldirs ../release/usr/gcc-4.2/info /bin/sh /net/gnu-13/export/gnu/src/gcc/gcc/gcc/../mkinstalldirs ../release/usr/gcc-4.2/lib /bin/sh /net/gnu-13/export/gnu/src/gcc/gcc/gcc/../mkinstalldirs ../release/usr/gcc-4.2/man/man1 /bin/sh /net/gnu-13/export/gnu/src/gcc/gcc/gcc/../mkinstalldirs ../release/usr/gcc-4.2/man/man7 rm -f ../release/usr/gcc-4.2/info/cpp.info if [ -f doc/cpp.info ]; then \ for f in doc/cpp.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /usr/bin/install -c -m 644 $f ../release/usr/gcc-4.2/info/$realfile; \ chmod a-x ../release/usr/gcc-4.2/info/$realfile; \ done; \ else true; fi if /bin/sh -c 'install-info --version' /dev/null 21; then \ if [ -f ../release/usr/gcc-4.2/info/cpp.info ]; then \ install-info --dir-file=../release/usr/gcc-4.2/info/dir ../release/usr/gcc-4.2/info/cpp.info; \ else true; fi; \ else true; fi; rm -f ../release/usr/gcc-4.2/info/gcc.info if [ -f doc/gcc.info ]; then \ for f in doc/gcc.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /usr/bin/install -c -m 644 $f ../release/usr/gcc-4.2/info/$realfile; \ chmod a-x ../release/usr/gcc-4.2/info/$realfile; \ done; \ else true; fi if /bin/sh -c 'install-info --version' /dev/null 21; then \ if [ -f ../release/usr/gcc-4.2/info/gcc.info ]; then \ install-info --dir-file=../release/usr/gcc-4.2/info/dir ../release/usr/gcc-4.2/info/gcc.info; \ else true; fi; \ else true; fi; rm -f ../release/usr/gcc-4.2/info/cppinternals.info if [ -f doc/cppinternals.info ]; then \ for f in doc/cppinternals.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /usr/bin/install -c -m 644 $f ../release/usr/gcc-4.2/info/$realfile; \ chmod a-x ../release/usr/gcc-4.2/info/$realfile; \ done; \ else true; fi if /bin/sh -c 'install-info --version' /dev/null 21; then \ if [ -f ../release/usr/gcc-4.2/info/cppinternals.info ]; then \ install-info --dir-file=../release/usr/gcc-4.2/info/dir ../release/usr/gcc-4.2/info/cppinternals.info; \ else true; fi; \ else true; fi; rm -f ../release/usr/gcc-4.2/info/gccinstall.info if [ -f doc/gccinstall.info ]; then \ for f in doc/gccinstall.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /usr/bin/install -c -m 644 $f ../release/usr/gcc-4.2/info/$realfile; \ chmod a-x ../release/usr/gcc-4.2/info/$realfile; \ done; \ else true; fi if /bin/sh -c 'install-info --version' /dev/null 21; then \ if [ -f ../release/usr/gcc-4.2/info/gccinstall.info ]; then \ install-info --dir-file=../release/usr/gcc-4.2/info/dir ../release/usr/gcc-4.2/info/gccinstall.info; \ else true; fi; \ else true; fi; rm -f ../release/usr/gcc-4.2/info/gccint.info if [ -f doc/gccint.info ]; then \ for f in doc/gccint.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /usr/bin/install -c -m 644 $f ../release/usr/gcc-4.2/info/$realfile; \ chmod a-x ../release/usr/gcc-4.2/info/$realfile; \ done; \ else true; fi if /bin/sh -c 'install-info --version' /dev/null 21; then \ if [ -f ../release/usr/gcc-4.2/info/gccint.info ]; then \ install-info --dir-file=../release/usr/gcc-4.2/info/dir ../release/usr/gcc-4.2/info/gccint.info; \ else true; fi; \ else true; fi; rm -f ../release/usr/gcc-4.2/info/gfortran.info if [ -f doc/gfortran.info ]; then \ for f in doc/gfortran.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /usr/bin/install -c -m 644 $f ../release/usr/gcc-4.2/info/$realfile; \ chmod a-x ../release/usr/gcc-4.2/info/$realfile; \ done; \ else true; fi if /bin/sh -c 'install-info --version' /dev/null 21; then \ if [ -f ../release/usr/gcc-4.2/info/gfortran.info ]; then \ install-info --dir-file=../release/usr/gcc-4.2/info/dir ../release/usr/gcc-4.2/info/gfortran.info; \ else true; fi; \ else true; fi; rm -f ../release/usr/gcc-4.2/info/gcj.info if [ -f doc/gcj.info ]; then \ for f in doc/gcj.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /usr/bin/install -c -m 644 $f
[Bug bootstrap/27774] make install-info no longer works
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-26 17:35 --- Missing a couple of pieces of info. How did you configure GCC? Did you do a build before doing make install-info? By the way a relative path for DESTDIR will not work so why are you trying to do that in the first place. And does this work with say 4.1.0 or 4.0.0 or even 3.4.6? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|other |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27774
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #21 from dir at lanl dot gov 2006-05-26 17:45 --- It is rev 113395 that is causing the problem. I backed out that change and built today's version of gfortran - it now correctly runs one of the tests that has been failing - [dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical write_logical.f90 [dranta:~/tests/gfortran-D] dir% write_logical [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060526 (experimental) [dranta:~/tests/gfortran-D] dir% cat write_logical.f90 ! PR 14334, L edit descriptor does not work ! ! this test uses L1 and L4 to print TRUE and FALSE logical true,false character*10 b true = .TRUE. false = .FALSE. b = '' write (b, '(L1)') true if (b(1:1) .ne. 'T') call abort b = '' write (b, '(L1)') false if (b(1:1) .ne. 'F') call abort b = '' write(b, '(L4)') true if (b(1:4) .ne. ' T') call abort b = '' write(b, '(L4)') false if (b(1:4) .ne. ' F') call abort end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug bootstrap/27774] make install-info no longer works
--- Comment #2 from hjl at lucon dot org 2006-05-26 17:57 --- make install-info doesn't work in gcc/intl in 3.4, 4.0, 4.1. But it used to work in src/intl. After merging intl from gcc to src, make install-info no longers in src/intl. -- hjl at lucon dot org changed: What|Removed |Added URL||http://sources.redhat.com/bu ||gzilla/show_bug.cgi?id=2701 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27774
[Bug target/27683] [4.2 Regression] Many new GFORTRAN testsuite failures
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-05-26 17:58 --- (In reply to comment #21) It is rev 113395 that is causing the problem. I backed out that change and built today's version of gfortran - it now correctly runs one of the tests that has been failing - I had tested with section anchors turned on for all languages on powerpc-darwin (except for Ada because it was broken a different way anyways) before I join SCEA. I will definitely take a look this long weekend. I bet someone else changed something or there is just missing a merge attribute on a section. Can someone give the assembly difference between before and after rev 113395? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |target GCC host triplet|powerpc-apple-darwin8.6.0 | GCC target triplet||powerpc-apple-darwin Keywords||wrong-code Summary|Many new GFORTRAN testsuite |[4.2 Regression] Many new |failures|GFORTRAN testsuite failures Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug bootstrap/27774] make install-info no longer works
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-26 17:59 --- What about 3.3.x? gcc/intl changed in 3.4.x? Also you still have not said how you configured. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL|http://sources.redhat.com/bu| |gzilla/show_bug.cgi?id=2701 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27774
[Bug bootstrap/15212] [4.0/4.1/4.2 Regression] bootstrap fails on interix3
--- Comment #19 from neroden at gcc dot gnu dot org 2006-05-26 18:34 --- I'm afraid I've become very busy and my priorities have changed; I'm not going to get this bug fixed. Unassigning. -- neroden at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|neroden at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug middle-end/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #7 from janis at gcc dot gnu dot org 2006-05-26 18:36 --- A regression hunt on powerpc-linux using the testcase from comment #5 with --ffast-math identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=107218 r107218 | rguenth | 2005-11-19 11:29:10 + (Sat, 19 Nov 2005) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug c++/24561] no static definition at -O0
--- Comment #13 from mueller at gcc dot gnu dot org 2006-05-26 18:39 --- It also causes bootstrap failures (see PR18058) -- mueller at gcc dot gnu dot org changed: What|Removed |Added CC||mueller at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24561
[Bug middle-end/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-26 18:41 --- The problem is here with that patch: + if (!FLOAT_TYPE_P (type)) + arg11 = build_int_cst (type, 1); + else + arg11 = build_real (type, dconst1); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug c++/24561] no static definition at -O0
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-26 18:43 --- (In reply to comment #13) It also causes bootstrap failures (see PR18058) Can you try bootstrapping with a newer GCC as that problem should have been fixed (though the orginally problem in that bug still remains as it still fails with -fkeep-inline-functions and using Sun's CC). Anyways this has been fixed for 4.2.0 so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24561
[Bug bootstrap/27774] make install-info no longer works
--- Comment #4 from hjl at lucon dot org 2006-05-26 18:49 --- I didn't see intl in my gcc 3.3. My gcc is configured with /net/gnu-13/export/gnu/src/gcc/gcc/configure \ \ --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \ \ --enable-shared \ --enable-threads=posix \ --enable-haifa \ --enable-checking=assert \ --prefix=/usr/gcc-4.2 \ --with-local-prefix=/usr/local I never used make install-info in gcc. I only used it in binutils. It used to work until int from gcc was copied over. I am using: 2006-05-26 H.J. Lu [EMAIL PROTECTED] PR binutils/2701 PR gcc/27774 * Makefile.in (install-info): Put it back. --- intl/Makefile.in.info 2006-05-24 09:01:37.0 -0700 +++ intl/Makefile.in2006-05-26 10:36:01.0 -0700 @@ -116,6 +116,7 @@ DEFS-relocatable.o = -DINSTALLDIR=\$(l all: [EMAIL PROTECTED]@ all-yes: libintl.a libintl.h config.intl all-no: # nothing +install-info: # nothing libintl.a: $(OBJECTS) rm -f $@ to work around it. -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2006-05-26 18:49:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27774
[Bug target/27683] [4.2 Regression] Many new GFORTRAN testsuite failures
--- Comment #23 from dir at lanl dot gov 2006-05-26 19:36 --- Here is the good and the bad - [dranta:~/tests/gfortran-D] dir% gfortran -O1 -save-temps -o write_logical2 write_logical2.f90 [dranta:~/tests/gfortran-D] dir% write_logical2 At line 9 of file write_logical2.f90 Fortran runtime error: Missing initial left parenthesis in format [dranta:~/tests/gfortran-D] dir% cat write_logical2.f90 ! PR 14334, L edit descriptor does not work ! ! this test uses L1 and L4 to print TRUE and FALSE logical true,false character*10 b true = .TRUE. false = .FALSE. b = '' write (b, '(L1)') true if (b(1:1) .ne. 'T') call abort end [dranta:~/tests/gfortran-D] dir% cat write_logical2.s .machine ppc .text .align 2 .globl _MAIN__ _MAIN__: mflr r0 stmw r28,-16(r1) stw r0,8(r1) stwu r1,-384(r1) bcl 20,31,L001$pb L001$pb: mflr r31 li r3,70 li r4,127 li r5,0 bl L__gfortran_set_std$stub li r0,1 stw r0,56(r1) addi r28,r1,60 addis r29,r31,ha16(LANCHOR0-L001$pb) la r29,lo16(LANCHOR0-L001$pb)(r29) li r3,10 mr r4,r28 li r5,0 mr r6,r29 bl L__gfortran_copy_string$stub addis r2,r31,ha16(LC1-L001$pb) la r2,lo16(LC1-L001$pb)(r2) stw r2,80(r1) li r0,9 stw r0,84(r1) stw r28,132(r1) li r0,10 stw r0,136(r1) li r0,0 stw r0,112(r1) stw r0,76(r1) stw r29,116(r1) li r0,4 stw r0,120(r1) li r0,20480 stw r0,72(r1) addi r29,r1,72 mr r3,r29 bl L__gfortran_st_write$stub mr r3,r29 addi r4,r1,56 li r5,4 bl L__gfortran_transfer_logical$stub mr r3,r29 bl L__gfortran_st_write_done$stub lbz r0,60(r1) cmpwi cr7,r0,84 beq+ cr7,L4 bl L__gfortran_abort$stub L4: addi r1,r1,384 lwz r0,8(r1) mtlr r0 lmw r28,-16(r1) blr .const .align 2 .setLANCHOR0, . + 0 LC0: .space 1 LC2: .ascii (L1) .cstring .align 2 LC1: .ascii write_logical2.f90\0 .section __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32 .align 5 L__gfortran_transfer_logical$stub: .indirect_symbol __gfortran_transfer_logical mflr r0 bcl 20,31,L001$spb L001$spb: mflr r11 addis r11,r11,ha16(L__gfortran_transfer_logical$lazy_ptr-L001$spb) mtlr r0 lwzu r12,lo16(L__gfortran_transfer_logical$lazy_ptr-L001$spb)(r11) mtctr r12 bctr .lazy_symbol_pointer L__gfortran_transfer_logical$lazy_ptr: .indirect_symbol __gfortran_transfer_logical .long dyld_stub_binding_helper .section __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32 .align 5 L__gfortran_st_write_done$stub: .indirect_symbol __gfortran_st_write_done mflr r0 bcl 20,31,L002$spb L002$spb: mflr r11 addis r11,r11,ha16(L__gfortran_st_write_done$lazy_ptr-L002$spb) mtlr r0 lwzu r12,lo16(L__gfortran_st_write_done$lazy_ptr-L002$spb)(r11) mtctr r12 bctr .lazy_symbol_pointer L__gfortran_st_write_done$lazy_ptr: .indirect_symbol __gfortran_st_write_done .long dyld_stub_binding_helper .section __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32 .align 5 L__gfortran_abort$stub: .indirect_symbol __gfortran_abort mflr r0 bcl 20,31,L003$spb L003$spb: mflr r11 addis r11,r11,ha16(L__gfortran_abort$lazy_ptr-L003$spb) mtlr r0 lwzu r12,lo16(L__gfortran_abort$lazy_ptr-L003$spb)(r11) mtctr r12 bctr .lazy_symbol_pointer L__gfortran_abort$lazy_ptr: .indirect_symbol __gfortran_abort .long dyld_stub_binding_helper .section __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32 .align 5 L__gfortran_set_std$stub: .indirect_symbol __gfortran_set_std mflr r0 bcl 20,31,L004$spb L004$spb: mflr r11 addis r11,r11,ha16(L__gfortran_set_std$lazy_ptr-L004$spb) mtlr r0 lwzu r12,lo16(L__gfortran_set_std$lazy_ptr-L004$spb)(r11) mtctr r12 bctr .lazy_symbol_pointer L__gfortran_set_std$lazy_ptr: .indirect_symbol __gfortran_set_std .long dyld_stub_binding_helper .section __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32 .align 5 L__gfortran_copy_string$stub: .indirect_symbol __gfortran_copy_string mflr r0 bcl
Prosper your life
We are a team of private investors, with years of good experience http://209.200.152.115
[Bug fortran/23151] print (buf, format), expression should be invalid
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-05-26 19:53 --- Subject: Bug 23151 Author: tkoenig Date: Fri May 26 19:53:18 2006 New Revision: 114138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114138 Log: 2006-05-26 Thomas Koenig [EMAIL PROTECTED] PR fortran/23151 * io.c (match_io): print (1,*) is an error. 2006-05-26 Thomas Koenig [EMAIL PROTECTED] PR fortran/23151 * gfortran.dg/inquire_9.f90: Fix illegal print syntax. * gfortran.dg/print_parentheses_1.f: New test. * gfortran.dg/print_parentheses_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/print_parentheses_1.f trunk/gcc/testsuite/gfortran.dg/print_parentheses_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/inquire_9.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23151
[Bug rtl-optimization/27661] ICE in subst_reloads
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-05-26 20:22 --- Subject: Bug 27661 Author: uweigand Date: Fri May 26 20:21:53 2006 New Revision: 114141 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114141 Log: PR rtl-optimization/27661 * reload.c (find_reloads): When reloading a VOIDmode constant as address due to an EXTRA_MEMORY_CONSTRAINT or 'o' constraint, use Pmode as mode of the reload register. PR rtl-optimization/27661 * gcc.dg/pr27661.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/pr27661.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27661
[Bug target/27683] [4.2 Regression] Many new GFORTRAN testsuite failures
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-05-26 20:51 --- Looks like .const sections are merged, I will deal with this (it is an one liner). Dale thanks for the assembly of both the good and bad. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug target/27683] [4.2 Regression] Many new GFORTRAN testsuite failures
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-05-26 20:52 --- I had wished Apple would care more about the FSF GCC than they are right now. I still don't understand why an employee of SCEA has to fix their bugs for them. Maybe Apple should pay me for work I do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug libfortran/27524] -fbounds-check interacts with array function
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-26 21:18 --- Subject: Bug 27524 Author: fxcoudert Date: Fri May 26 21:18:45 2006 New Revision: 114142 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114142 Log: PR fortran/27524 * trans-array.c (gfc_trans_dummy_array_bias): Don't use stride as a temporary variable when -fbounds-check is enabled, since its value will be needed later. * gfortran.dg/bounds_check_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27524
[Bug libfortran/27524] [4.1 only] -fbounds-check interacts with array function
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 Known to work||4.2.0 Summary|-fbounds-check interacts|[4.1 only] -fbounds-check |with array function |interacts with array ||function Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27524
[Bug fortran/25828] [f2003] ACCESS='STREAM' io support
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25828
[Bug c++/27775] New: incorrect ambiguous error message with multiple inheritance and nested class.
The test-case:
// testcase: -
struct A
{
struct B
{
};
};
struct C : A, A::B
{
void foo(B b);
void bar(B* pb);
};
//
==
The error:
foo.cc:11: error: reference to 'B' is ambiguous
foo.cc:5: error: candidates are: struct A::B
foo.cc:5: error: struct A::B
foo.cc:11: error: 'B' has not been declared
foo.cc:12: error: reference to 'B' is ambiguous
foo.cc:5: error: candidates are: struct A::B
foo.cc:5: error: struct A::B
foo.cc:12: error: 'B' has not been declared
-
There is only one type B, whether it's referred to as ::A::B, (from the
global scope), or A::B, injected from the first inheritance, or simpy B
injected from the second. These all refer to the same type. There is no
ambiguity.
Note, GCC accepts this if the foo member functions are delcared w/ namespace
qualification. For example, this code is accepted:
struct C : A, A::B
{
void foo(A::B b);
void bar(A::B* pb);
};
=
This behaviour is found in the following versions of GCC:
egcs-2.91.66, gcc-3.2, gcc-3.3, gcc-3.4.3, gcc-3.4.6, gcc-4.0
I haven't tried other versions.
--
Summary: incorrect ambiguous error message with multiple
inheritance and nested class.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rnewman at compubrite dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27775
[Bug target/27683] [4.2 Regression] Many new GFORTRAN testsuite failures
--- Comment #26 from pinskia at gcc dot gnu dot org 2006-05-27 02:27 --- Actually this is a dup of bug 26427. I had forgot about this issue until now. *** This bug has been marked as a duplicate of 26427 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug target/26427] Regressions with -fsection-anchors with zero sized structs
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-27 02:27 --- *** Bug 27683 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug fortran/27757] Problems with direct access io
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-05-27 02:35 --- The following patch causes no regressions. I can't reproduce the problem here, but I have a hunch. Ray, can you try this and see if it resolves the problem? Thanks for tests and reports. Index: io/transfer.c === *** io/transfer.c (revision 114105) --- io/transfer.c (working copy) *** st_write_done (st_parameter_dt *dtp) *** 2416,2421 --- 2416,2425 break; } + if (dtp-u.p.current_unit != NULL +dtp-u.p.current_unit-flags.access == ACCESS_DIRECT) + flush (dtp-u.p.current_unit-s); + free_format_data (dtp); free_ionml (dtp); if (dtp-u.p.scratch != NULL) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-27 02:35:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-27 04:11 --- Created an attachment (id=11517) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11517action=view) patch which fixes part of the problem This fixes the C testcase but it does not fix the Fortran issue but I don't think the fortran issue is a target back-end issue now since darwin_use_anchors_for_symbol_p does return false for the rtx. I am off to the bar for tonight so I cannot test this or fix the fortran issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug fortran/25058] missing diagnostic about ENTRY dummy argument
--- Comment #3 from patchapp at dberlin dot org 2006-05-27 04:30 --- Subject: Bug number PR25058 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01385.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25058
[Bug fortran/27662] [4.1 only]: Transpose doesn't work on function return
--- Comment #14 from pault at gcc dot gnu dot org 2006-05-27 05:03 --- (In reply to comment #12) Are you using Tonto in SPEC CPU 2006? It is slightly different from Tonto 1.0 on SF. The problem in Tonto in SPEC CPU 2006 is it uses something like Ah, sorry HJ. You are right. But nullify is never called on d before. Tonto compiled by gfortran may return TRUE and abort. I checked Fortran standard. It isn't very clear if it is valid Fortran code. Stephen is correct on this. The fortran code should take care of this. However, it might be very convenient to NULL all pointers by default. Another issue, to which tonto is very sensitive, is that of chained component references ending in a pointer. Checking if the pointer is associated causes a segfault if one of the intermediate references is an unallocated pointer. I believe that other compilers check for this. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug fortran/27757] Problems with direct access io
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-05-27 05:10 --- Here is some good news. I came up with a test case that fails with gfortran and passes with intel. The bad news is that I have not fixed it yet. At least I have something to work with now and its ugly. program testdirect implicit none integer, dimension(100) :: a integer :: i,j,k,ier real:: x a = 0 call random_seed() open(unit=15,file=testdirectio,access=direct,form=unformatted,recl=4) do i=1,100 call random_number(x) k= int(x * 100)+1 a(i)=k write(unit=15, rec=k) k enddo do j=1,100 read(unit=15, rec=a(j), iostat=ier) k if (ier.ne.0) then print *, No Record: , j else print *, Bad Record at ,a(j), k endif enddo close(unit=15, status=delete) end program testdirect -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
