Re: CSE bug when narrowing constants
> cse_insn() calls lookup_as_function() ultimately through fold_rtx(), IIRC, > and is the routine that writes the REG_EQUAL note. OK, thanks. But I'm a little at a loss as to why this problem arises only now: the problematic code in lookup_as_function is one decade old. Do you happen to have older compilers around (say GCC 4.1.x based) that correctly compile the testcase? If so, what happens differently with them? -- Eric Botcazou
Re: CSE bug when narrowing constants
All, One thing that may or may not be related is that the current main fails to bootstrap on x86_64 with fold checking enabled. It aborts due to a fold-checking failure (i.e fold has modified it's inputs) using the stage1 compiler. I don't recall exactly which file it triggers on (I think it was one of the host-ieee*.c files in libdecnumber library). The last bootstrap I did was about 8 weeks ago and that passed with all checking enabled so its a *recent* regression. I'll look into the cause this evening. Cheers Graham --- On Mon, 1/12/08, Eric Botcazou <[EMAIL PROTECTED]> wrote: > From: Eric Botcazou <[EMAIL PROTECTED]> > Subject: Re: CSE bug when narrowing constants > To: "Gary Funck" <[EMAIL PROTECTED]> > Cc: gcc@gcc.gnu.org > Date: Monday, 1 December, 2008, 10:50 AM > > cse_insn() calls lookup_as_function() ultimately > through fold_rtx(), IIRC, > > and is the routine that writes the REG_EQUAL note. > > OK, thanks. But I'm a little at a loss as to why this > problem arises only > now: the problematic code in lookup_as_function is one > decade old. Do you > happen to have older compilers around (say GCC 4.1.x based) > that correctly > compile the testcase? If so, what happens differently with > them? > > -- > Eric Botcazou
g77 correct version
Dear all, I would like to install a g77 on my version of Linux that is Scientific Linux SL-52-062608-i386. I tried to install 3 packages of g77 but I don't know what is the package suitable for me and my Linux version. Could you be so kind to indicate me the correct link for downloading g77 package? And also I would like to know if I should install g77 as a root or as a simple user. Thank you very much. Angela Intermite -- Angela Intermite c/o Max Planck Institut fuer Kerphysik Saupfercheckweg 1 69117 Heidelberg Germany
About the procedure of fixinclude in building gcc
Hi All: Now I am working on the procedure of fixinclude in building gcc and got following concepts. Take three PATH as example to illustrate, ginclude: which provided by gcc source includes system headers wanted by gcc; sys_inc : the location of system header files; local : the locattion for system headers fixed by gcc; When building gcc, there are two steps to finish the job of fixing headers: STEP1:fixinc.sh will fix system headers in PATH: sys_inc and put fixed ones into PATH:local ; STEP2:gcc(actually is building makefiles) will copy all files from PATH:ginclude to PATH:local. In this step, it will copy anything into PATH:local even if there is one as the result of STEP1. After all, gcc will search system headers in PATH:local firstly and then in PATH:sys_inc. I'am not sure about my comprehension, am I right? And there is a question about ./fixincludes/Makefile. I think the gcc's top level Makefile will configure fixincludes and create that Makefile, and then will do such "make ./fixincludes/Makefile" thing, But I found following rules in ./fixincludes/Makefile: all : oneprocess fixinc.sh mkheaders fixinc.sh : fixinc.in mkfixinc.sh Makefile (commands to create fixinc.sh) Makefile: $(srcdir)/Makefile.in config.status $(SHELL) ./config.status Makefile Look at the last rule with target Makefile, does it recreate exactly this Makefile recursively? And why doing this? I have to admit that I know nothing about config.status except comments say that it is used to recreate the current configuration. Thanks for look at this message, and any suggestion will be greatly appreciated!
pruning in gcc/testsuite/lib/gcc.exp
Doug, Is there a reason why prune.exp is loaded in lib/gcc.exp and lib/g++.exp but never actually used? I need to prune a linker warning with.. regsub -all "(^|\n)ld: warning: can't make compact unwind encoding from dwarf for \[^\n\]* in \[^\n\]*" $text "" text on x86_64-apple-darwin10 to suppress false failures in dg-struct-layout-1 for gcc.dg and g++.dg. Elsewhere in the testsuite, I can suppress these warnings easily by placing that line in lib/prune.exp. However it is unclear how I should code this pruning into lib/g++.exp and lib/gcc.exp so that the dg-struct-layout-1 false excessive error failures are suppressed. Any advice would be appreciated. Jack
Re: optimization removes a __builtin_memcpy?
On Sun, Nov 30, 2008 at 10:18:22PM +0100, Richard Guenther wrote:
> On Sun, Nov 30, 2008 at 5:28 AM, Steve Kargl
> <[EMAIL PROTECTED]> wrote:
> >
> > ERRMSG.12 = &"Attempt to deallocate an unallocated object"[1]{lb: 1 sz:
> > 1};
> > -ERRMSG.12 = stat.11 != 0 ? (void) __builtin_memcpy ((void *) &err,
> > (void *) ERRMSG.12, 30) : (void) 0;
> > +ERRMSG.12 = stat.11 != 0 ? err = *(character(kind=1)[1:30] *
> > {ref-all}) ERRMSG.12 : (void) 0;
>
> Btw, you assign "void" to ERRMSG.12 - this is certainly invalid GENERIC and
> not
> what you want to do, right?
>
I have a working patch. Don't know if it's completely correct;
however, there are no regressions. The key appeared to be that
I needed to build a pointer to err instead on passing err itself.
--
Steve
Re: How to control code segments ?
Alan Lehotsky wrote: Look at the implementation of the IP2K compiler and linker. It uses a segmented paged architecture just like the machine you are describing. In essence what we did was implement linker relaxation to deal with this. When we called any function, we emitted the appropriate long-call by setting the page register and jumping to the location on that page. In the linker, we implemented relaxation code that looked to see if we were changing to the SAME page, and if so deleted the instruction changing the PAGE and did a local jump to the destination. Now, because a function could cross a page boundary (we only had 4kb pages (and 16 bit instructions), all our branches were done this way (if I recall correctly). Yes, every call and branch was emitted in its long form and then relaxed back down to the shorter form wherever it was possible. A later version that we had in-house did an even longer sequence that allowed us to bounce through an emulator to utilize the holes that the architecture allowed but that weren't physically present on the chip and we'd relax to either a page-crossing operation or a in-page operation. Regards, Dave
Re: CSE bug when narrowing constants
On 12/01/08 11:50:48, Eric Botcazou wrote: > > cse_insn() calls lookup_as_function() ultimately through fold_rtx(), IIRC, > > and is the routine that writes the REG_EQUAL note. > > OK, thanks. But I'm a little at a loss as to why this problem arises only > now: the problematic code in lookup_as_function is one decade old. Do you > happen to have older compilers around (say GCC 4.1.x based) that correctly > compile the testcase? If so, what happens differently with them? Yeah, I was surprised as well. The compiler base line this problem arose on is 4.2.3, but I think that it will occur in both older and newer base lines. The problem is triggered by code generated by the UPC (Unified Parllel C) support that we've implemented in a project we call GCC/UPC. It fails on a small UPC test case, but a number of factors have to be present to trigger the problem. I tried developing a vanilla C test case to duplicate the problem, but have so far been unsuccessful. Internally, we use VIEW_CONVERT_EXPR to overlay a TImode container on top of a struct. There is no exact C equivalent, though a union comes close. I tried that, but couldn't replicate the exact set of events that have to be present to hit the problem. I send what I tried to you separately. Perhaps adding some sort of logging in lookup_as_function() that indicates narrowing is occurring, and then running all test cases (including Ada, because its unchecked_conversion is close to what we're doing internally) would turn something up?
Re: "R_ARM_GOTOFF32" problem on uClinux
2008/12/1 K.J. Kuan-Jau Lin(林寬釗) <[EMAIL PROTECTED]>: > Hi Shaun, > > I have trouble in uClinux world. > After long and painful debugging, i found it is due to the "R_ARM_GOTOFF32" > relocation type. > By google, i found you got the same problem before. > (http://mailman.uclinux.org/pipermail/uclinux-dev/2006-June/039089.html). > I knew you have tried the gcc-4.0.x & gcc-4.1.x toolchains. > My toolchian is gcc-4.2.4 and seems still have the same problem. > Besides changing to gcc-4.0.x, did you have any workaround solutions? > Any hints will be very appreciated. Hi KJ, I never did find a solution. Only two cases in particular bit me: * strings constants * addresses of static functions passed as arguments The first I worked around by placing strings constants in the read-write memory (RODATA after the GOT) rather than the read-only memory (RODATA after TEXT), although this does use RAM unnecessarily. I never did fix the second issue. A possible quick hack, although not a solution, would be to find wherever GCC decides to emit a GOTOFF32 relocation and use a GOT32 relocation instead. This issue has a bug report in bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194 I've cc'ed the GCC mailing list. Cheers, Shaun
MIPS -mplt option in N32 abi system
Hi there,
I have just tried gcc 4.4 svn trunk on a MIPS N32 system.
But I found -mplt is practically not usable, because -mno-shared is not used
when generating non-PIC code.
I dug into the code and found the cause is in gcc/config/mips/linux64.h.
Unlike linux.h under the same directory, DRIVER_SELF_SPECS in linux64.h has no
LINUX_DRIVER_SELF_SPECS.
Is it left out intentionally?
However it seems to me that -mplt works on N32 system.
So what about the patch attached? ok to apply?
Zhang, Le
--- gcc/config/mips/linux64.h.orig 2008-12-01 13:55:43.0 +
+++ gcc/config/mips/linux64.h 2008-12-01 13:54:48.0 +
@@ -23,6 +23,7 @@
#undef DRIVER_SELF_SPECS
#define DRIVER_SELF_SPECS \
BASE_DRIVER_SELF_SPECS \
+LINUX_DRIVER_SELF_SPECS \
" %{!EB:%{!EL:%(endian_spec)}}" \
" %{!mabi=*: -mabi=n32}"
Re: MIPS -mplt option in N32 abi system
Zhang Le wrote:
Hi there,
I have just tried gcc 4.4 svn trunk on a MIPS N32 system.
But I found -mplt is practically not usable, because -mno-shared is not used
when generating non-PIC code.
I dug into the code and found the cause is in gcc/config/mips/linux64.h.
Unlike linux.h under the same directory, DRIVER_SELF_SPECS in linux64.h has no
LINUX_DRIVER_SELF_SPECS.
Is it left out intentionally?
However it seems to me that -mplt works on N32 system.
So what about the patch attached? ok to apply?
[...]
BASE_DRIVER_SELF_SPECS \
+LINUX_DRIVER_SELF_SPECS \
" %{!EB:%{!EL:%(endian_spec)}}" \
" %{!mabi=*: -mabi=n32}"
You are missing a comma there between BASE_DRIVER_SELF_SPECS and
LINUX_DRIVER_SELF_SPECS. Without the comma, I am told that
gcc.target/mips/pr35802.c FAILs. Other than that (and some formatting)
this patch is equivalent to:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00033.html
David Daney
Thomas Schwinge appointed GNU Hurd maintainer
I am pleased to announce that the GCC Steering Committee has appointed Thomas Schwinge as GCC maintainer for GNU Hurd. Please join me in congratulating Thomas on his new role. Thomas, please update your listing in the MAINTAINERS file. Happy hacking! David
Re: MIPS -mplt option in N32 abi system
On 10:33 Mon 01 Dec , David Daney wrote:
> Zhang Le wrote:
>> BASE_DRIVER_SELF_SPECS \
>> +LINUX_DRIVER_SELF_SPECS \
>> " %{!EB:%{!EL:%(endian_spec)}}" \
>> " %{!mabi=*: -mabi=n32}"
>
> You are missing a comma there between BASE_DRIVER_SELF_SPECS and
> LINUX_DRIVER_SELF_SPECS. Without the comma, I am told that
> gcc.target/mips/pr35802.c FAILs. Other than that (and some formatting)
> this patch is equivalent to:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00033.html
Thanks!
I will pay much closer attention to gcc-patches list in the future.
Zhang, Le
Re: MIPS -mplt option in N32 abi system
Zhang Le wrote:
On 10:33 Mon 01 Dec , David Daney wrote:
Zhang Le wrote:
BASE_DRIVER_SELF_SPECS \
+LINUX_DRIVER_SELF_SPECS \
" %{!EB:%{!EL:%(endian_spec)}}" \
" %{!mabi=*: -mabi=n32}"
You are missing a comma there between BASE_DRIVER_SELF_SPECS and
LINUX_DRIVER_SELF_SPECS. Without the comma, I am told that
gcc.target/mips/pr35802.c FAILs. Other than that (and some formatting)
this patch is equivalent to:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00033.html
Thanks!
I will pay much closer attention to gcc-patches list in the future.
In this case, it may not have helped much. I only beat you be about an
hour.
David Daney
Re: pruning in gcc/testsuite/lib/gcc.exp
On Mon, 2008-12-01 at 08:59 -0500, Jack Howarth wrote: > Doug, >Is there a reason why prune.exp is loaded in lib/gcc.exp and lib/g++.exp > but never actually used? I need to prune a linker warning with.. > > regsub -all "(^|\n)ld: warning: can't make compact unwind encoding from dwarf > for \[^\n\]* in \[^\n\]*" $text "" text > > on x86_64-apple-darwin10 to suppress false failures in dg-struct-layout-1 > for gcc.dg and g++.dg. Elsewhere in the testsuite, I can suppress these > warnings easily by placing that line in lib/prune.exp. However it is > unclear how I should code this pruning into lib/g++.exp and lib/gcc.exp > so that the dg-struct-layout-1 false excessive error failures are > suppressed. Any advice would be appreciated. Jack, The compat tests use different procedures to compile and link, defined in lib/compat.exp. Those could call prune_gcc_output, or compat tests could be made to handle dg-prune-output directives in tests by modifying compat-get-options-main in compat.exp. Janis
Re: MIPS -mplt option in N32 abi system
On 11:02 Mon 01 Dec , David Daney wrote:
> Zhang Le wrote:
>> On 10:33 Mon 01 Dec , David Daney wrote:
>>> Zhang Le wrote:
BASE_DRIVER_SELF_SPECS \
+LINUX_DRIVER_SELF_SPECS \
" %{!EB:%{!EL:%(endian_spec)}}" \
" %{!mabi=*: -mabi=n32}"
>>> You are missing a comma there between BASE_DRIVER_SELF_SPECS and
>>> LINUX_DRIVER_SELF_SPECS. Without the comma, I am told that
>>> gcc.target/mips/pr35802.c FAILs. Other than that (and some formatting)
>>> this patch is equivalent to:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00033.html
>> Thanks!
>> I will pay much closer attention to gcc-patches list in the future.
>
> In this case, it may not have helped much. I only beat you be about an
> hour.
Yes, but at least this can save you an email to remind me that a similar patch
is already sent, ;)
Actually, I made this patch at least 4 hours ago.
When I sent this, I was just about to go to bed and figured that I'd better
send it before I went to bed.
OK, really need to go to bed now, already 3 a.m. Good night.
Zhang, Le
Re: Application for maintainer role for mingw
On Sat, 8 Nov 2008, Gerald Pfeifer wrote: > On Sat, 8 Nov 2008, Kai Tietz wrote: >> Hello Steering Committee, > I raised this on the steering committee... You've got the hat, Kai, congratulations! Please update the MAINTAINERS file accordingly. Happy hacking, Gerald
Athlon XP segfaults with -fweb -ftracer
Hi all. I'm a Gentoo user with an Athlon XP: [EMAIL PROTECTED] ~ $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP 3000+ stepping: 0 cpu MHz : 2157.092 cache size : 512 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 cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up bogomips: 4314.18 clflush size: 32 power management: ts [EMAIL PROTECTED] ~ $ I'm using gcc 4.3.2: [EMAIL PROTECTED] ~ $ gcc --version gcc (Gentoo 4.3.2 p1.1) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] ~ $ I'm experiencing segfaults with applications that use fontconfig, only if fontconfig is compiled with -fweb -ftracer. In full, I used: -march=athlon-xp -O2 -pipe -fweb -ftracer I have seen a very similar bugs reported at: https://bugs.gentoo.org/show_bug.cgi?id=147290 https://bugs.gentoo.org/show_bug.cgi?id=135632 ... but they talk about -ftree-vectorize. The symptoms are the same anyway. If I rebuild fontconfig with: -march=athlon-xp -O2 -pipe ... the segfaults are fixed. Comment #8 in https://bugs.gentoo.org/show_bug.cgi?id=135632 says that this is fixed in gcc-4.3, but possibly this was not fixed for athlon-xp? I can enter a bug with the above info if people want. Should I? Is there an existing bug / is it still a known issue? I can also rebuild with debugging symbols if it will help. Thanks. Dan
Re: Application for maintainer role for mingw
On Mon, Dec 1, 2008 at 3:22 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Sat, 8 Nov 2008, Gerald Pfeifer wrote: >> On Sat, 8 Nov 2008, Kai Tietz wrote: >>> Hello Steering Committee, >> I raised this on the steering committee... > > You've got the hat, Kai, congratulations! Please update the MAINTAINERS > file accordingly. > > Happy hacking, > Gerald > Congratulations!!
Re: g77 correct version
Hi Angela > I would like to install a g77 on my version of Linux that is Scientific > Linux SL-52-062608-i386. > I tried to install 3 packages of g77 but I don't know what is the package > suitable for me and my Linux version. This mailing list is for discussing the development of gcc and g77, rather than installing it. You should probably address your question to your distro vendor/community. > Could you be so kind to indicate me the correct link for downloading g77 > package? And also I would like to know if I should install g77 as a root > or as a simple user. If your distro uses RPMs or deb packages, you will need to install them as root. Cheers, Ben
