Re: Ada.Exceptions.Exception_Propagation is not a predefined library unit
Hi Luke, a-exexpr.adb:39:06: Ada.Exceptions.Exception_Propagation is not a predefined library unit it looks like you get this error when the compiler can't find a file that it thinks forms part of the Ada library (this is determined by the name, eg: a package Ada.XYZ is expected to be part of the Ada library). For example, if the compiler looks for the spec of Ada.Exceptions.Exception_Propagation (which should be called a-exexpr.ads) but can't find it then you will get this message. At least, that's my understanding from a few minutes of rummaging around in the source code. Ciao, Duncan.
Re: Trouble doing bootstrap
On 14 October 2010 02:07, Paul Koning wrote: Explicitly setting LD_LIBRARY_PATH seems to cure the problem. It would be good to have that called out in the procedures (or, preferably, made not to be necessary). As Ian pointed out, it's documented under --with-mpc et al, although I only added that note recently. I find building the support libs in-tree is easiest, followed by installing them separately but with --disable-shared
Re: Ada.Exceptions.Exception_Propagation is not a predefined library unit
On Thu, 2010-10-14 at 09:31 +0200, Duncan Sands wrote: Hi Luke, a-exexpr.adb:39:06: Ada.Exceptions.Exception_Propagation is not a predefined library unit it looks like you get this error when the compiler can't find a file that it thinks forms part of the Ada library (this is determined by the name, eg: a package Ada.XYZ is expected to be part of the Ada library). For example, if the compiler looks for the spec of Ada.Exceptions.Exception_Propagation (which should be called a-exexpr.ads) but can't find it then you will get this message. At least, that's my understanding from a few minutes of rummaging around in the source code. Hmmm, well, this spec is actually inside the body of a-except.adb (which also specifies that the body of a-exexpr.ads is separate. All files are present in the rts dirs. Thanks, Luke.
Re: %pc relative addressing of string literals/const data
Joakim Tjernlund/Transmode wrote on 2010/10/12 11:00:36:
Alan Modra amo...@gmail.com wrote on 2010/10/11 14:58:45:
On Sun, Oct 10, 2010 at 11:20:06AM +0200, Joakim Tjernlund wrote:
Now I have had a closer look at this and it looks much like -fpic
on ppc32, you still use the GOT/TOC to load the address where the
data is.
No, with ppc64 -mcmodel=medium you use the GOT/TOC pointer plus an
offset to address local data.
I was looking for true %pc relative addressing of data. I guess this
is really
hard on PowerPC?
Yes, PowerPC lacks pc-relative instructions.
I am not sure this is all it takes to make -fpic to work with
-mrelocatable,
any ideas?
You might be lucky. With -mrelocatable, .got2 only contains
addresses. No other constants. So a simple run-time loader can
relocate the entire .got2 section, plus those locations specified in
.fixup. You'll have to make sure gcc does the same for .got, and your
run-time loader will need to be modified to handle .got (watch out for
the .got header!).
Got it working now. It was just u-boot reloc routine I first failed
to extend properly to reloc *got too.
I think this is safe as one can mix fpic with fPIC and
mrelocatable is the same as fPIC+fixups.
Will you accept this patch into gcc?
Ping?
From d8ff0b3f0b44480542eab04d1659f4368b6b09cf Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund joakim.tjernl...@transmode.se
Date: Sun, 10 Oct 2010 10:34:50 +0200
Subject: [PATCH] powerpc: Support -fpic too with mrelocatable
Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se
---
sysv4.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gcc/config/rs6000/sysv4.h b/gcc/config/rs6000/sysv4.h
index 8da8410..e4b8280 100644
--- a/gcc/config/rs6000/sysv4.h
+++ b/gcc/config/rs6000/sysv4.h
@@ -227,7 +227,8 @@ do {\
} \
\
else if (TARGET_RELOCATABLE) \
-flag_pic = 2; \
+if (!flag_pic) \
+ flag_pic = 2;\
} while (0)
#ifndef RS6000_BI_ARCH
--
1.7.2.2
Options for dumping dependence checking results
Hi All, What's the option for dumping the results of loop dependence checking? such as dependence relations, direction vectors, etc. Thanks, Hongtao
LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
Hello list,
When I compile this source with -flto:
extern int retval;
int func (void)
{
return retval;
}
... the LTO symbol table contains both symbols:
/gnu/binutils/git.repo/obj/ld/test/func.o: file format pe-i386
Contents of section .gnu.lto_.symtab.227b80e3:
66756e63 func
0010 4b00 72657476 616c 0200 K...retval..
0020 5100 ..Q...
But when I compile this:
extern int printf (const char *fmt, ...);
extern const char *text;
extern int func (void);
int retval = 0;
int main (int argc, const char **argv)
{
printf (%s\n, text);
return func ();
}
... there is no sign of printf:
/gnu/binutils/git.repo/obj/ld/test/main.o: file format pe-i386
Contents of section .gnu.lto_.symtab.6e8eaf64:
6d61696e main
0010 4b00 66756e63 0200 K...func
0020 5b00 74657874 0200 [...text
0030 5f00 72657476 _...retv
0040 616c 6100 ala.
0050 ..
Nor indeed is there any sign of puts, which is what the generated ltrans0.s
file ends up optimising it to (as indeed does the native code in the original
.o file). I'm assuming that this is by design and is for some reason along
the lines that we don't even know whether or which function calls are actually
going to be emitted until link time?
It makes life complicated in the linker though, because it means there are
symbols present in the object files that the plugin adds via the
add_input_files callback that weren't in the original symbols the linker
presented via add_symbols when it initially claimed the object file containing
the IR.
The consequence of this is that either there are going to be undefined
symbols in the final executable, or the linker has to perform another round of
library scanning. It occurred to me that the semantics of this might even not
have been decided yet, since ELF platforms are perfectly happy with undefined
symbols at final link time. The only documentation I know of that specifies
the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't say
anything explicit about this; maybe I've failed to infer something that I
should have.
So, is there a defined way in which this is supposed to work? And if the
linker is supposed to rescan the libs after the plugin adds files, is it
supposed to offer any archive members it finds to the plugin for claiming?
Should there be multiple iterations of claiming files and calling
all_symbols_read? And if not, what about if the archive members we find on
the second pass contain LTO IR?
It occurs to me that maybe this is what the add_input_library hook is for:
perhaps a simple fix would be for collect2 to pass a list of all the stdlibs
to the plugin as a plugin option, and it could add_input_library them after
it's finished adding object files. Would that be a reasonable approach?
(Right now I have a working COFF lto-plugin, but the link fails with
unresolved symbols unless I manually add (e.g.) -Wl,-u,_puts (... etc.) to
the command-line to make sure all the required libc archive members get pulled
in during the first pass over libs!)
cheers,
DaveK
--
(*) - http://gcc.gnu.org/wiki/whopr/driver
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
Hello list,
When I compile this source with -flto:
extern int retval;
int func (void)
{
return retval;
}
... the LTO symbol table contains both symbols:
/gnu/binutils/git.repo/obj/ld/test/func.o: file format pe-i386
Contents of section .gnu.lto_.symtab.227b80e3:
66756e63 func
0010 4b00 72657476 616c 0200 K...retval..
0020 5100 ..Q...
But when I compile this:
extern int printf (const char *fmt, ...);
extern const char *text;
extern int func (void);
int retval = 0;
int main (int argc, const char **argv)
{
printf (%s\n, text);
return func ();
}
... there is no sign of printf:
/gnu/binutils/git.repo/obj/ld/test/main.o: file format pe-i386
Contents of section .gnu.lto_.symtab.6e8eaf64:
6d61696e main
0010 4b00 66756e63 0200 K...func
0020 5b00 74657874 0200 [...text
0030 5f00 72657476 _...retv
0040 616c 6100 ala.
0050 ..
Nor indeed is there any sign of puts, which is what the generated ltrans0.s
file ends up optimising it to (as indeed does the native code in the original
.o file). I'm assuming that this is by design and is for some reason along
the lines that we don't even know whether or which function calls are actually
going to be emitted until link time?
I think this is because builtin functions are handled specially (their decls
are not streamed, likewise I think we don't stream their cgraph nodes).
As you noted we may eventually fold printf to puts (we may also generate
a memcpy call out of an aggregate assignment), so it might not make
your life perfect if we emit symbols for those calls (as indeed we don't know
which ones we will emit at link time).
It makes life complicated in the linker though, because it means there are
symbols present in the object files that the plugin adds via the
add_input_files callback that weren't in the original symbols the linker
presented via add_symbols when it initially claimed the object file containing
the IR.
The consequence of this is that either there are going to be undefined
symbols in the final executable, or the linker has to perform another round of
library scanning. It occurred to me that the semantics of this might even not
have been decided yet, since ELF platforms are perfectly happy with undefined
symbols at final link time. The only documentation I know of that specifies
the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't say
anything explicit about this; maybe I've failed to infer something that I
should have.
Yeah, I think you have to deal with undefined references to standard
functions (mostly from libc, libm but maybe also from libpthread or so).
So, is there a defined way in which this is supposed to work? And if the
linker is supposed to rescan the libs after the plugin adds files, is it
supposed to offer any archive members it finds to the plugin for claiming?
Should there be multiple iterations of claiming files and calling
all_symbols_read? And if not, what about if the archive members we find on
the second pass contain LTO IR?
It occurs to me that maybe this is what the add_input_library hook is for:
perhaps a simple fix would be for collect2 to pass a list of all the stdlibs
to the plugin as a plugin option, and it could add_input_library them after
it's finished adding object files. Would that be a reasonable approach?
(Right now I have a working COFF lto-plugin, but the link fails with
unresolved symbols unless I manually add (e.g.) -Wl,-u,_puts (... etc.) to
the command-line to make sure all the required libc archive members get pulled
in during the first pass over libs!)
I have no idea about the linker-plugin side, but we could of course
avoid generating any calls that were not there before (by for example
streaming builtin decls and only if they are used). But that's as much
a workaround as fixing things up in the linker afterwards ...
Richard.
cheers,
DaveK
--
(*) - http://gcc.gnu.org/wiki/whopr/driver
Re: Ada.Exceptions.Exception_Propagation is not a predefined library unit
Hello Luke, Luke A. Guest wrote: Can anyone give me a pointer here? I'm totally new to this :/ a-exexpr.adb:39:06: Ada.Exceptions.Exception_Propagation is not a predefined library unit a-exexpr.adb:39:06: Ada.Exceptions (body) depends on Ada.Exceptions.Exception_Propagation (body) a-exexpr.adb:39:06: Ada.Exceptions.Exception_Propagation (body) depends on Ada.Exceptions.Exception_Propagation (spec) We discussed this internally a bit. The compiler is looking for the spec of Ada.Exceptions.Exception_Propagation in a separate file (which would be a-exexpr.ads) because you are trying to add a child of it. This won't work, as there is indeed no such file today because this unit is provided as a subunit of ada.exceptions (package bla is ... end; package body bla is separate;) What you probably could do instead is to define a System unit (e.g. System.GCC_Exceptions or System.Unwind_Control or ...) to hold the low level unwinder type definitions. That would allow reuse from other units, which might become of interest in the not so distant future. In case you don't already know about it, gnatmake -a is a very convenient device to experiment with alternate/extra Ada runtime units (accounts for variants in the current directory, for example). Olivier
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On 14/10/2010 15:44, Richard Guenther wrote: On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn dave.korn.cyg...@gmail.com wrote: Nor indeed is there any sign of puts, which is what the generated ltrans0.s file ends up optimising it to (as indeed does the native code in the original .o file). I'm assuming that this is by design and is for some reason along the lines that we don't even know whether or which function calls are actually going to be emitted until link time? I think this is because builtin functions are handled specially (their decls are not streamed, likewise I think we don't stream their cgraph nodes). Ah, yes; -fno-builtin avoids it, for example. As you noted we may eventually fold printf to puts (we may also generate a memcpy call out of an aggregate assignment), so it might not make your life perfect if we emit symbols for those calls (as indeed we don't know which ones we will emit at link time). Yes, I can see that we'd quite possibly end up with unused library code pulled into the link. It makes life complicated in the linker though, because it means there are symbols present in the object files that the plugin adds via the add_input_files callback that weren't in the original symbols the linker presented via add_symbols when it initially claimed the object file containing the IR. The consequence of this is that either there are going to be undefined symbols in the final executable, or the linker has to perform another round of library scanning. It occurred to me that the semantics of this might even not have been decided yet, since ELF platforms are perfectly happy with undefined symbols at final link time. The only documentation I know of that specifies the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't say anything explicit about this; maybe I've failed to infer something that I should have. Yeah, I think you have to deal with undefined references to standard functions (mostly from libc, libm but maybe also from libpthread or so). Well, the thing I'm trying to figure out is how to deal with them. COFF doesn't allow undefined references in executables. So, is there a defined way in which this is supposed to work? And if the linker is supposed to rescan the libs after the plugin adds files, is it supposed to offer any archive members it finds to the plugin for claiming? Should there be multiple iterations of claiming files and calling all_symbols_read? And if not, what about if the archive members we find on the second pass contain LTO IR? It occurs to me that maybe this is what the add_input_library hook is for: perhaps a simple fix would be for collect2 to pass a list of all the stdlibs to the plugin as a plugin option, and it could add_input_library them after it's finished adding object files. Would that be a reasonable approach? (Right now I have a working COFF lto-plugin, but the link fails with unresolved symbols unless I manually add (e.g.) -Wl,-u,_puts (... etc.) to the command-line to make sure all the required libc archive members get pulled in during the first pass over libs!) I have no idea about the linker-plugin side, but we could of course avoid generating any calls that were not there before (by for example streaming builtin decls and only if they are used). But that's as much a workaround as fixing things up in the linker afterwards ... Sorry, I don't quite understand that suggestion! Do you mean we'd emit a symbol for printf and that would result in an explicit printf which wouldn't have the chance of being optimised to a puts at link-time? If so I see how it'd work, but it would be a shame to lose optimisation in LTO. Or to include unnecessary library members. I *think* that re-adding the stdlibs after all the new input files in the plugin might work, but haven't tried it yet. I have the same problem with '__main', BTW. Is that supposed to count as a builtin, or do we need to do something in expand_main_function() to make LTO aware when it calls __main? cheers, DaveK
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn dave.korn.cyg...@gmail.com wrote: On 14/10/2010 15:44, Richard Guenther wrote: On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn dave.korn.cyg...@gmail.com wrote: Nor indeed is there any sign of puts, which is what the generated ltrans0.s file ends up optimising it to (as indeed does the native code in the original .o file). I'm assuming that this is by design and is for some reason along the lines that we don't even know whether or which function calls are actually going to be emitted until link time? I think this is because builtin functions are handled specially (their decls are not streamed, likewise I think we don't stream their cgraph nodes). Ah, yes; -fno-builtin avoids it, for example. As you noted we may eventually fold printf to puts (we may also generate a memcpy call out of an aggregate assignment), so it might not make your life perfect if we emit symbols for those calls (as indeed we don't know which ones we will emit at link time). Yes, I can see that we'd quite possibly end up with unused library code pulled into the link. It makes life complicated in the linker though, because it means there are symbols present in the object files that the plugin adds via the add_input_files callback that weren't in the original symbols the linker presented via add_symbols when it initially claimed the object file containing the IR. The consequence of this is that either there are going to be undefined symbols in the final executable, or the linker has to perform another round of library scanning. It occurred to me that the semantics of this might even not have been decided yet, since ELF platforms are perfectly happy with undefined symbols at final link time. The only documentation I know of that specifies the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't say anything explicit about this; maybe I've failed to infer something that I should have. Yeah, I think you have to deal with undefined references to standard functions (mostly from libc, libm but maybe also from libpthread or so). Well, the thing I'm trying to figure out is how to deal with them. COFF doesn't allow undefined references in executables. So, is there a defined way in which this is supposed to work? And if the linker is supposed to rescan the libs after the plugin adds files, is it supposed to offer any archive members it finds to the plugin for claiming? Should there be multiple iterations of claiming files and calling all_symbols_read? And if not, what about if the archive members we find on the second pass contain LTO IR? It occurs to me that maybe this is what the add_input_library hook is for: perhaps a simple fix would be for collect2 to pass a list of all the stdlibs to the plugin as a plugin option, and it could add_input_library them after it's finished adding object files. Would that be a reasonable approach? (Right now I have a working COFF lto-plugin, but the link fails with unresolved symbols unless I manually add (e.g.) -Wl,-u,_puts (... etc.) to the command-line to make sure all the required libc archive members get pulled in during the first pass over libs!) I have no idea about the linker-plugin side, but we could of course avoid generating any calls that were not there before (by for example streaming builtin decls and only if they are used). But that's as much a workaround as fixing things up in the linker afterwards ... Sorry, I don't quite understand that suggestion! Do you mean we'd emit a symbol for printf and that would result in an explicit printf which wouldn't have the chance of being optimised to a puts at link-time? Yes. If so I see how it'd work, but it would be a shame to lose optimisation in LTO. Or to include unnecessary library members. I *think* that re-adding the stdlibs after all the new input files in the plugin might work, but haven't tried it yet. I have the same problem with '__main', BTW. Is that supposed to count as a builtin, or do we need to do something in expand_main_function() to make LTO aware when it calls __main? Hm, I don't know - I suppose that's from the crt*.o stuff? The main function itself should already appear in the symbols. Richard. cheers, DaveK
RE: Bootstrap failures on sparc/x86 solaris2.10 machines
Hi Art,
No luck with this mornings builds on both x86 and sparc.
My last successful i386-pc-solaris2.10 build was several weeks ago; all
the build attempts fail at this assertion in the function/file below:
{ ... snip ... }
I'm building mainline on Solaris 8 to 11 with both Sun as and gas all
the time without problems, though I'm very rarely using GNU ld
(install.texi warns against doing so for a reason). What version of gld
are you using above? I recently found a couple of bugs with CVS
binutils and am in the process of fixing them. In the rare attempts of
building with gld, I've never seen a problem as you report, so please
file a bug for this issue. Also, please try to use Sun ld and see if
this helps.
A build using Sun 'ld' also failed in a similar manner.
I've added the bug to GCC bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018
{ ... snip sparc bug error ... }
Known bug, already fixed:
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00942.html
My sparc builds are working fine now. Thanks!
Art Haas
RE: Bootstrap errors on i386-pc-solaris2.10 bisected
On Tue, Oct 12, 2010 at 2:46 PM, Art Haas ah...@impactweather.com wrote:
Hi.
The bootstrap problems I've been having on the x86 Solaris machine,
plus the reply from maintainer Rainer Orth that his builds have
been succeeding were the impetus to investigate how 'git bisect'
works. After a bit of fumbling around, including a rebuild of
an apparently miscompiled 'git' binary, I was able to bisect
the build problems to this commit:
{ ... snip ... }
It could be:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45865
I tried the one-line patch at the end of the bug report and it did not help.
Art Haas
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On 14/10/2010 16:24, Richard Guenther wrote: On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn dave.korn.cyg...@gmail.com wrote: On 14/10/2010 15:44, Richard Guenther wrote: I have no idea about the linker-plugin side, but we could of course avoid generating any calls that were not there before (by for example streaming builtin decls and only if they are used). But that's as much a workaround as fixing things up in the linker afterwards ... Sorry, I don't quite understand that suggestion! Do you mean we'd emit a symbol for printf and that would result in an explicit printf which wouldn't have the chance of being optimised to a puts at link-time? Yes. I'd rather leave that as a real last resort! If so I see how it'd work, but it would be a shame to lose optimisation in LTO. Or to include unnecessary library members. I *think* that re-adding the stdlibs after all the new input files in the plugin might work, but haven't tried it yet. I have the same problem with '__main', BTW. Is that supposed to count as a builtin, or do we need to do something in expand_main_function() to make LTO aware when it calls __main? Hm, I don't know - I suppose that's from the crt*.o stuff? Typically it's from libgcc: If no init section is available, when GCC compiles any function called `main' (or more accurately, any function designated as a program entry point by the language front end calling `expand_main_function'), it inserts a procedure call to `__main' as the first executable code after the function prologue. The `__main' function is defined in `libgcc2.c' and runs the global constructors. On cygwin, it's supplied by libc. On other systems I don't know, maybe it can be in the crt.o files, but in that case there wouldn't be any problem with it getting pulled into the link, it's only a problem when it's a library archive member. The main function itself should already appear in the symbols. It does, but there's no reference to __main. I was wondering if that was supposed to happen, and looking at expand_main_function I guess so, because it's calling emit_library_call (init_one_libfunc (...)), but this is one libfunc that we know can't be optimised away at linktime, so it would probably be OK to stream it. (But there's a lot I don't know about LTO, so I could always be wrong there.) cheers, DaveK
Re: Trouble doing bootstrap
On Oct 13, 2010, at 9:07 PM, Ian Lance Taylor wrote: Paul Koning paul_kon...@dell.com writes: My build system doesn't have LD_LIBRARY_PATH defined so whatever is the Linux default would apply. Perhaps I should change that. But it seems strange that configure finds the prerequisites and then ends up generating makefiles that produce a compiler that can't find those things, even when it's built into the same /usr/local as the libraries it depends on. Yes, it's a mess. But we don't know of any really clean way to fix it. I very strongly recommend that if you want to build gcc's supporting libraries yourself, rather than getting them from your distro, that you configure them with --disable-shared when you build them. Or, if you must, add /usr/local/lib to your /etc/ld.so.conf file or to one of your /etc/ld.so.conf.d files, and run ldconfig. I tried the static-only approach. That worked for quite a while and then blew up with some java bits complaining they couldn't find libgmp.so. So for now I'm doing the ldconfig thing. paul
Re: Trouble doing bootstrap
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 03:07:46AM CEST: Paul Koning writes: My build system doesn't have LD_LIBRARY_PATH defined so whatever is the Linux default would apply. Perhaps I should change that. But it seems strange that configure finds the prerequisites and then ends up generating makefiles that produce a compiler that can't find those things, even when it's built into the same /usr/local as the libraries it depends on. Yes, it's a mess. But we don't know of any really clean way to fix it. Provide a configure switch --with-hardcoded-gccdeps that adds run path entries for pre-installed support libraries? I'm fine with that, but it just introduces another configure option for people to learn about. If we have to teach people something, I'd rather teach them to use --disable-shared when they build the libraries themselves. Of course the same could be done for when support libraries are built as part of the GCC source tree, but then we'd have to know about whether run path entries override LD_LIBRARY_PATH settings, and/or might need to relink upon installation in order to not use old preinstalled stuff while inside the build tree ... There is no problem when the support libraries are built as part of the gcc source tree, because in that case the build system automatically configures them with --disable-shared. Ian
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
Dave Korn dave.korn.cyg...@gmail.com writes: The consequence of this is that either there are going to be undefined symbols in the final executable, or the linker has to perform another round of library scanning. It occurred to me that the semantics of this might even not have been decided yet, since ELF platforms are perfectly happy with undefined symbols at final link time. Only when linking dynamically, though. This suggests that your test case should fail on ELF when linking with -static. If not, why not? Ian
Re: Trouble doing bootstrap
* Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 06:56:27PM CEST: Ralf Wildenhues writes: Provide a configure switch --with-hardcoded-gccdeps that adds run path entries for pre-installed support libraries? I'm fine with that, but it just introduces another configure option for people to learn about. If we have to teach people something, I'd rather teach them to use --disable-shared when they build the libraries themselves. OK. I won't argue my point further, but I am interested to learn why shared libraries in nonstandard locations are seemingly frowned upon here. Is that due to fragility of the libtool approach of relinking, or for relocatability issues of the installed program? Thanks, Ralf
Re: Trouble doing bootstrap
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 06:56:27PM CEST: Ralf Wildenhues writes: Provide a configure switch --with-hardcoded-gccdeps that adds run path entries for pre-installed support libraries? I'm fine with that, but it just introduces another configure option for people to learn about. If we have to teach people something, I'd rather teach them to use --disable-shared when they build the libraries themselves. OK. I won't argue my point further, but I am interested to learn why shared libraries in nonstandard locations are seemingly frowned upon here. Is that due to fragility of the libtool approach of relinking, or for relocatability issues of the installed program? 1) We don't use libtool to build gcc. 2) If we did use libtool to build gcc, then, yes, I would be concerned about the relinking issue. 3) Shared libraries are less efficient. You get some efficiency back if the libraries are in fact shared by multiple different executables running simultaneously. But in this case it is relatively unlikely that gmp, mpfr, and mpc will actually be used by any executable other than gcc. So why make them shared libraries? We lose something, as can be seen by the number of times this has come up in gcc-help. We gain nothing. 4) People sometimes suggest seeing the DT_RPATH/DT_RUNPATH of the executable to point to the shared library locations. Past experience has shown that this is a bad idea for some organizations. Some places mount /usr/local/lib or other directories over NFS. Putting that in DT_RPATH/DT_RUNPATH causes the dynamic linker to search those directories at program startup. That causes startup to be much slower, and can even cause it to hang until the NFS server returns. That is not desirable for the compiler. Ian
Re: Trouble doing bootstrap
* Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 08:43:51PM CEST: Ralf Wildenhues writes: OK. I won't argue my point further, but I am interested to learn why shared libraries in nonstandard locations are seemingly frowned upon here. Is that due to fragility of the libtool approach of relinking, or for relocatability issues of the installed program? 1) We don't use libtool to build gcc. I know. That's easily fixed though.[1] Whether one uses the tool or reinvents or reuses part of the functionality is a different question than whether some functionality itself is desirable or not, however. 2) If we did use libtool to build gcc, then, yes, I would be concerned about the relinking issue. Why? Because of 'make install' run as root? Any other reasons? 3) Shared libraries are less efficient. You get some efficiency back if the libraries are in fact shared by multiple different executables running simultaneously. But in this case it is relatively unlikely that gmp, mpfr, and mpc will actually be used by any executable other than gcc. It is not so unlikely that multiple instances of cc1, cc1plus, and f951 are running simultaneously. Granted, I haven't done any measurements. So why make them shared libraries? We lose something, as can be seen by the number of times this has come up in gcc-help. We gain nothing. Well, we *could* make hardcoding the default in order to cope with gcc-help.[2] 4) People sometimes suggest seeing the DT_RPATH/DT_RUNPATH of the executable to point to the shared library locations. Past experience has shown that this is a bad idea for some organizations. Some places mount /usr/local/lib or other directories over NFS. Putting that in DT_RPATH/DT_RUNPATH causes the dynamic linker to search those directories at program startup. That causes startup to be much slower, and can even cause it to hang until the NFS server returns. That is not desirable for the compiler. Good points. Thanks, Ralf [1] I'll hope you'll excuse me playing devil's advocate here. ;-) [2] Oops. Twice in one message.
Re: Trouble doing bootstrap
Ralf Wildenhues ralf.wildenh...@gmx.de writes: 2) If we did use libtool to build gcc, then, yes, I would be concerned about the relinking issue. Why? Because of 'make install' run as root? Any other reasons? Any install process which is more complex than cp is a matter for concern. It should only be undertaken for a really good reason. 3) Shared libraries are less efficient. You get some efficiency back if the libraries are in fact shared by multiple different executables running simultaneously. But in this case it is relatively unlikely that gmp, mpfr, and mpc will actually be used by any executable other than gcc. It is not so unlikely that multiple instances of cc1, cc1plus, and f951 are running simultaneously. Granted, I haven't done any measurements. Most projects are written in only one language. Sure, there may be cases where cc1 and cc1plus are running simultaneously. But I suspect those cases are relatively unlikely. In particular, I suspect that the gain when that happens, which is really quite small, is less than the cost of using a shared library. Needless to say, I also have not done any measurements. Ian
Re: Trouble doing bootstrap
On Thu, Oct 14, 2010 at 12:47:34PM -0700, Ian Lance Taylor wrote: It is not so unlikely that multiple instances of cc1, cc1plus, and f951 are running simultaneously. Granted, I haven't done any measurements. Most projects are written in only one language. Sure, there may be cases where cc1 and cc1plus are running simultaneously. But I suspect those cases are relatively unlikely. In particular, I suspect that the gain when that happens, which is really quite small, is less than the cost of using a shared library. Needless to say, I also have not done any measurements. Projects that use C in some places and C++ in others are common, so a simultaneous cc1 and cc1plus run will often occur with parallel builds. However, the mp math libraries are relatively small compared to the size of cc1 or cc1plus so the memory savings from having one copy instead of two are minimal.
Re: Trouble doing bootstrap
On Thu, 14 Oct 2010, Ian Lance Taylor wrote: Ralf Wildenhues ralf.wildenh...@gmx.de writes: 2) If we did use libtool to build gcc, then, yes, I would be concerned about the relinking issue. Why? Because of 'make install' run as root? Any other reasons? Any install process which is more complex than cp is a matter for concern. It should only be undertaken for a really good reason. And we should be aiming to make the GCC build, test and install process simpler: install to a staging directory during build, use the built-in relocatability in building target libraries and running testsuites rather than needing to pass long sequences of -B etc. options at those stages, and just copy the staging directory for final installation. (It's nasty that not just the build systems of the various toolchain components but upstream DejaGnu itself has hardcoded information about how bits of the tools can locate each other in their build directories. Nothing should ever need to know that; the staging install code should just put things so that they can find each other automatically.) -- Joseph S. Myers jos...@codesourcery.com
Re: Ada.Exceptions.Exception_Propagation is not a predefined library unit
On 10/14/2010 3:31 AM, Duncan Sands wrote: Hi Luke, a-exexpr.adb:39:06: Ada.Exceptions.Exception_Propagation is not a predefined library unit it looks like you get this error when the compiler can't find a file that it thinks forms part of the Ada library (this is determined by the name, eg: a package Ada.XYZ is expected to be part of the Ada library). For example, if the compiler looks for the spec of Ada.Exceptions.Exception_Propagation (which should be called a-exexpr.ads) but can't find it then you will get this message. At least, that's my understanding from a few minutes of rummaging around in the source code. You are not allowed to add new children or grandchildren to the Ada hierarchy. Only the implementor can do this, and it must be done following all the implementation rules (impunit entry, use -gnatg to compile etc).
gcc-4.5-20101014 is now available
Snapshot gcc-4.5-20101014 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101014/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 165484 You'll find: gcc-4.5-20101014.tar.bz2 Complete GCC (includes all of below) MD5=917fc632f528188a860595eef2b5457a SHA1=90ffcb6ec91697caa31fd6586f1ab3322ac0d733 gcc-core-4.5-20101014.tar.bz2C front end and core compiler MD5=ed36fbd3cdf70c921df9fff21402c6ee SHA1=60b4419840e93cf6935e994a69cb9e5a65f15f73 gcc-ada-4.5-20101014.tar.bz2 Ada front end and runtime MD5=3d087ce08dea89e4513ff0f2918c08ab SHA1=a88427dd88d75712af853befe78f6577be6777c0 gcc-fortran-4.5-20101014.tar.bz2 Fortran front end and runtime MD5=3573be4cc71e5379e43286e31ec93e02 SHA1=2ddc94250c3805b16ff51266daf314364a3f204f gcc-g++-4.5-20101014.tar.bz2 C++ front end and runtime MD5=2a01cbd49fe0cba7c4d92f19fc45f2e7 SHA1=164540a0cd9e498c37870e03e9540eb212c013f9 gcc-java-4.5-20101014.tar.bz2Java front end and runtime MD5=1251c4f78a7a6361ebf9fd31eac052d9 SHA1=34080e954b6c5dd2822b0b7661cc9ea019596251 gcc-objc-4.5-20101014.tar.bz2Objective-C front end and runtime MD5=ea4a5719e454ec152cf2ef42076c71eb SHA1=6cc87d487337ac1634ef9773dc4ab3a390f8d365 gcc-testsuite-4.5-20101014.tar.bz2 The GCC testsuite MD5=534abb72da9c929c5deb01a1b553b3d3 SHA1=7a792b0976aad25579c898ed5b43332b1a0f9ac6 Diffs from 4.5-20101007 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: show size of stack needed by functions
-Original Message- From: Eric Botcazou [mailto:ebotca...@adacore.com] Sent: Wednesday, October 13, 2010 4:43 PM To: sebastianspublicaddr...@googlemail.com Cc: gcc@gcc.gnu.org; Joe Buck Subject: Re: show size of stack needed by functions We have had something along these lines in our compiler at AdaCore for a few years; it's called -fcallgraph-info, it generates a very low-level callgraph in VCG format for each compilation unit, and the nodes can be decorated with information (typically stack usage indeed). Then you run a script to link all the VCG files for a program and you can (try and) compute the worst case stack usage for example. This works reasonably well for embedded stuff. I'll try and submit something before stage 1 ends if people are interested. Yes, I'm very interested. Eric Weddington
Re: check_cxa_atexit_available
On 9/29/2010 3:53 PM, Richard Henderson wrote:
The test program in target-supports.exp is broken, since
it doesn't preclude the use of cleanups instead. Indeed,
the init/cleanup3.C seems to be essentially identical to
the target-supports test.
Why isn't the test program in target-supports.exp just a link-time test
that __cxa_atexit exists? In other words:
void main () {
__cxa_atexit (...);
}
Is the idea that we want to be able to run the tests with
-fno-use-cxa-atexit in the command-line options? I guess we have to
worry about that. In that case, yes, I guess an assembly-scan test in
target-supports.exp is the best that we can do.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
[Bug rtl-optimization/45570] [4.6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4584
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45570 --- Comment #4 from Andrey Belevantsev abel at gcc dot gnu.org 2010-10-14 07:56:50 UTC --- Author: abel Date: Thu Oct 14 07:56:47 2010 New Revision: 165454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165454 Log: PR rtl-optimization/45570 * sel-sched-ir.c (cfg_preds_1): When walking out of the region, assert that we are pipelining outer loops. Allow returning zero predecessors. * gcc.dg/pr45570.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45570.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46010] I/O: Namelist-reading bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46010 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-14 08:09:04 UTC --- Reduced test case: --nml.dat--- namtoptrc tracer(1) = 'Aa', .true. tracer(2) = 'Bb', .true. tracer(3) = 'Cc', .true. / --test.f90-- TYPE PTRACER CHARACTER(len = 2) :: sname LOGICAL :: lini END TYPE PTRACER TYPE(PTRACER) , DIMENSION(3) :: tracer NAMELIST/namtoptrc/ tracer open (99, file='nml.dat') read (99, nml=namtoptrc) write (*, nml=namtoptrc) end Works with -std=f90/f2003/f2008 but fails with without -std=f* (i.e. with -std=gnu) as follows: At line 10 of file test.f90 (unit = 99, file = 'nml.dat') Fortran runtime error: Cannot match namelist object name 'bb' The issue is really the .true. (T,true, .false., F, false). If the last item (in the namelist and in the derived type) is an integer or a string it works.
[Bug libstdc++/45990] 28_regex/07_traits/char/isctype.cc XPASSes on Solaris 2/IRIX 6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45990 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-14 08:23:39 UTC --- Thanks, Rainer. This should xfail now, please reopen if not.
[Bug middle-end/46011] New: 256bit vectorizer failed on double-int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46011 Summary: 256bit vectorizer failed on double-int Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com For gcc.target/i386/vectorize4-avx.c, vect256 branch generates: .L2: vmovaps-120(%rsp,%rax), %ymm0 vcvtps2pd%xmm0, %ymm1 vextractf128$0x1, %ymm0, %xmm0 vsqrtpd%ymm1, %ymm1 vcvttpd2dqy%ymm1, %xmm1 vmovdqu%xmm1, (%rdi,%rax) vcvtps2pd%xmm0, %ymm0 vsqrtpd%ymm0, %ymm0 vcvttpd2dqy%ymm0, %xmm0 vmovdqu%xmm0, 16(%rdi,%rax) addq$32, %rax cmpq$1024, %rax jne.L2 Trunk at revision 165455 generates .L2: vmovaps-120(%rsp,%rax), %xmm1 vmovhlps%xmm1, %xmm0, %xmm0 vcvtps2pd%xmm1, %xmm2 vsqrtpd%xmm2, %xmm2 vcvttpd2dqx%xmm2, %xmm2 vcvtps2pd%xmm0, %xmm1 vsqrtpd%xmm1, %xmm1 vcvttpd2dqx%xmm1, %xmm1 vpunpcklqdq%xmm1, %xmm2, %xmm1 vmovdqu%xmm1, (%rdi,%rax) addq$16, %rax cmpq$1024, %rax jne.L2
[Bug middle-end/46011] 256bit vectorizer failed on double-int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46011 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-14 08:33:13 UTC --- Author: hjl Date: Thu Oct 14 08:33:09 2010 New Revision: 165457 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165457 Log: Scan 256bit AVX register and xfail vectorize4-avx.c. 2010-10-14 H.J. Lu hongjiu...@intel.com PR middle-end/46011 * gcc.target/i386/vectorize4-avx.c: Scan 256bit AVX register and xfail. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/vectorize4-avx.c
[Bug tree-optimization/46011] 256bit vectorizer failed on double-int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46011 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.14 08:36:25 Component|middle-end |tree-optimization Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 08:36:25 UTC --- Yep, that's a known limitation with the new scheme which just allows one vector size per loop. It needs special support in the vectorize_conversion routine.
[Bug tree-optimization/46012] New: 256bit vectorizer failed on int-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46012
Summary: 256bit vectorizer failed on int-double
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: rgue...@gcc.gnu.org
For
---
double a[1024];
float b[1024];
int c[1024];
void dependence_distance_4_mixed_0 (void)
{
int i;
for (i = 0; i 1020; ++i)
a[i + 4] = a[i] + a[i + 4] + c[i];
}
---
with -O3 -ffast-math -mavx, vect256 branch generates:
.L2:
vmovapda(%rax,%rax), %ymm0
vcvtdq2pdc(%rax), %ymm1
vaddpda+32(%rax,%rax), %ymm0, %ymm0
vaddpd%ymm1, %ymm0, %ymm0
vmovapd%ymm0, a+32(%rax,%rax)
addq$16, %rax
cmpq$4080, %rax
jne.L2
Trunk at revision 165455 generates
.L2:
vmovapd16(%rax), %xmm2
vaddpd-16(%rax), %xmm2, %xmm2
vmovdqa(%rdx), %xmm0
addq$16, %rdx
vpshufd$238, %xmm0, %xmm1
vcvtdq2pd%xmm0, %xmm0
vcvtdq2pd%xmm1, %xmm1
vaddpd%xmm1, %xmm2, %xmm1
vmovapd(%rax), %xmm2
vaddpd-32(%rax), %xmm2, %xmm2
vmovapd%xmm1, 16(%rax)
vaddpd%xmm0, %xmm2, %xmm0
vmovapd%xmm0, (%rax)
addq$32, %rax
cmpq%rax, %rcx
jne.L2
[Bug tree-optimization/46012] 256bit vectorizer failed on int-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46012 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.14 09:01:56 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 09:01:56 UTC --- Related to PR46011
[Bug tree-optimization/45764] [4.6 Regression] wrong code -O2 vs -O3 (problem in vectorizer???)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45764
--- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-03
05:41:44 UTC ---
Author: hjl
Date: Sun Oct 3 05:39:32 2010
New Revision: 164914
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164914
Log:
Disallow negative steps in vectorizer.
gcc/
2010-10-02 H.J. Lu hongjiu...@intel.com
PR tree-optimization/45720
PR tree-optimization/45764
* tree-vect-data-refs.c (vect_analyze_data_ref_access):
Don't accept backwards consecutive accesses.
(vect_create_data_ref_ptr): Disallow negative steps.
* tree-vect-stmts.c (vectorizable_store): Allow negative steps.
(perm_mask_for_reverse): Removed.
(reverse_vec_elements): Likewise.
(vectorizable_load): Don't hanle negative steps.
gcc/testsuite/
2010-10-02 H.J. Lu hongjiu...@intel.com
PR tree-optimization/45720
PR tree-optimization/45764
* g++.dg/torture/pr45764.C: New.
* gcc.dg/vect/pr43432.c: Xfail.
* gcc.dg/vect/vect-114.c: Likewise.
* gcc.dg/vect/vect-15.c: Likewise.
Added:
trunk/gcc/testsuite/g++.dg/torture/pr45764.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr43432.c
trunk/gcc/testsuite/gcc.dg/vect/vect-114.c
trunk/gcc/testsuite/gcc.dg/vect/vect-15.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-stmts.c
--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14
10:19:07 UTC ---
(In reply to comment #5)
This patch will set the correct misalign info on that data-reference:
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 164476)
+++ tree-vect-data-refs.c (working copy)
@@ -900,6 +900,19 @@ vect_compute_data_ref_alignment (struct
|| (TREE_CODE (base) == VAR_DECL
DECL_ALIGN (base) = TYPE_ALIGN (vectype)));
+ /* If this is a backward running DR then first access in the larger
+ vectype actually is N-1 elements before the address in the DR.
+ Adjust misalign accordingly. */
+ if (tree_int_cst_compare (DR_STEP (dr), size_zero_node) 0)
+{
+ tree offset = ssize_int (TYPE_VECTOR_SUBPARTS (vectype) - 1);
+ /* DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
+ otherwise we wouldn't be here. */
+ offset = fold_build2 (MULT_EXPR, ssizetype, offset, DR_STEP (dr));
+ /* PLUS because DR_STEP was negative. */
+ misalign = size_binop (PLUS_EXPR, misalign, offset);
+}
+
/* Modulo alignment. */
misalign = size_binop (FLOOR_MOD_EXPR, misalign, alignment);
Unfortunately this will later result in an ICE during peeling. It
wants to peel these data-refs that now are known misaligned, and during cost
computation changes data-refs that have the same alignment state to be
aligned too (makes sense because those data-refs will also be aligned when
the to-be-peeled DR is aligned).
Unfortunately the STMT_VINFO_SAME_ALIGN_REFS contains bogus reference,
because ultimately the distance vectors are wrong:
(compute_affine_dependence
(stmt_a = D.2097_46 = ibuf[D.2094_43];)
(stmt_b = D.2100_64 = ibuf[D.2099_63];)
(subscript_dependence_tester
(analyze_overlapping_iterations
(chrec_a = {64, +, -1}_2)
(chrec_b = {64, +, 1}_2)
(analyze_siv_subscript
(analyze_subscript_affine_affine
(overlaps_a = [0]
(overlaps_b = [0]
(overlap_iterations_a = [0]
(overlap_iterations_b = [0]
(build_classic_dist_vector
dist_vector = ( 0 )
So, we have two DRs running in opposite directions, which happen to
have the initial element in common (index 64), but afterwards diverge and
have nothing in common anymore. So overlap_iterations_a/b is correct.
But the distance vector is 0, meaning 'same in all iterations'. That
is used to initialize STMT_VINFO_SAME_ALIGN_REFS in
vect_find_same_alignment_drs .
Obviously the distance vector should be unknown (it could be a chrec, if
we really want, namely {0, +, 2}_2, but we don't do anything with such
distances). I tried to determine why it is wrong, it's ultimately
coming from SUB_DISTANCE of that DDR, computed like so
(compute_subscript_distance):
subscript = DDR_SUBSCRIPT (ddr, i);
cf_a = SUB_CONFLICTS_IN_A (subscript);
cf_b = SUB_CONFLICTS_IN_B (subscript);
fn_a = common_affine_function (cf_a);
fn_b = common_affine_function (cf_b);
if (!fn_a || !fn_b)
{
SUB_DISTANCE (subscript) = chrec_dont_know;
return;
}
diff = affine_fn_minus (fn_a, fn_b);
if (affine_function_constant_p (diff))
SUB_DISTANCE (subscript) = affine_function_base (diff);
else
SUB_DISTANCE (subscript) = chrec_dont_know;
And this is baffling me a bit. How could it be correct to
determine a distance
[Bug tree-optimization/44913] [4.6 Regression] -ftree-vectorize causes FAIL: gcc.dg/pr44838.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44913 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 10:38:45 UTC --- Mine.
[Bug c++/46013] New: crash when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46013 Summary: crash when compiling Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: merflo...@gmail.com Created attachment 22033 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22033 the preprocessed file (*.i*) that triggers the bug $ make g++ -c -g -v -save-temps ../sort_list_student/sort_list_student.cpp -o ../sort_list_student/sort_list_student.o Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) COLLECT_GCC_OPTIONS='-c' '-g' '-v' '-save-temps' '-o' '../sort_list_student/sort_list_student.o' '-shared-libgcc' '-mtune=generic' '-march=i486' /usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE ../sort_list_student/sort_list_student.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=i486 -g -fworking-directory -fpch-preprocess -fstack-protector -o sort_list_student.ii ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /usr/include/c++/4.4 /usr/include/c++/4.4/i486-linux-gnu /usr/include/c++/4.4/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.4.3/include /usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed /usr/include End of search list. built-in:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. make: *** [../sort_list_student/sort_list_student.o] Error 1
[Bug c/46014] New: internal compiler error compiling clamav-0.96.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46014 Summary: internal compiler error compiling clamav-0.96.3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@htw-saarland.de output of gcc -v: Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.3.0/configure --enable-languages=c,c++ Thread model: posix gcc version 4.3.0 (GCC) detailed compiler flags for building gcc are unknown Error message: init2.c:37: assertion failed: ((64 - 0)+0) == (((64 - 0)+0)/8) * 8 sizeof(mp_limb_t) == (((64 - 0)+0)/8) bytecode_api.c: In function 'cli_bcapi_ilog2': bytecode_api.c:952: internal compiler error: Abort makefile and bytecode_api.i are attached
[Bug c/46014] internal compiler error compiling clamav-0.96.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46014 --- Comment #1 from mar...@htw-saarland.de 2010-10-14 10:46:01 UTC --- Created attachment 22034 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22034 intermediate file of error producing source
[Bug c/46014] internal compiler error compiling clamav-0.96.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46014 --- Comment #2 from mar...@htw-saarland.de 2010-10-14 10:46:47 UTC --- Created attachment 22035 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22035 Makefile with compiler flags
[Bug libstdc++/45999] runtime error in std::vector python pretty printer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45999
--- Comment #2 from Pawel Sikora pluto at agmk dot net 2010-10-14 10:53:03
UTC ---
(In reply to comment #1)
Reduced
#include vector
int main()
{
std::vectorbool b(4);
b.push_back(1);
return 0;
}
There's no pretty printer for vectorbool
seems to fixed on trunk:
http://gcc.gnu.org/viewcvs?view=revisionrevision=163282
can we get a backport for this fix on 4.5 branch?
[Bug c++/46013] crash when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46013 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-14 10:59:33 UTC --- that preprocessed file refers to a precompiled header, student.h.gch, which isn't included can you reproduce it without using precompiled headers?
[Bug c/46014] internal compiler error compiling clamav-0.96.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46014 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.10.14 11:02:53 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 11:02:53 UTC --- Please try GCC 4.3.5. Can't reproduce with the sparse info you provided with 4.3.0.
[Bug c++/45690] broken debuginfo with dwarf4?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690 --- Comment #3 from Pawel Sikora pluto at agmk dot net 2010-10-14 11:13:10 UTC --- Created attachment 22036 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22036 my gcc build script.
[Bug c++/45690] broken debuginfo with dwarf4?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690 --- Comment #4 from Pawel Sikora pluto at agmk dot net 2010-10-14 11:17:55 UTC --- attached gcc build script builds libstdc++.a with dwarf3 debuginfo which works with testcase compiled with dwarf3 or dwarf4. if you change CUSTOM_FLAGS in build script to emit dwarf4 for libstdc++.a then you'll get runtime error in python gdb printer.
[Bug tree-optimization/45764] [4.6 Regression] wrong code -O2 vs -O3 (problem in vectorizer???)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45764
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14
11:54:13 UTC ---
The snippet seems to work as far as to set SUB_DISTANCE to chrec_dont_know,
together with the suggested fix in comment #5 it fixes this PR.
Now, the hunk below alone would already compute the distance vector,
so I'm not sure what the rest of the function is supposed to do
(and why it doesn't handle steps appropriately).
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 165456)
+++ tree-data-ref.c (working copy)
@@ -1165,6 +1165,16 @@ compute_subscript_distance (struct data_
SUB_DISTANCE (subscript) = chrec_dont_know;
return;
}
+
+ if (tree_contains_chrecs
+ (chrec_fold_minus (TREE_TYPE (DR_ACCESS_FN (DDR_A (ddr), i)),
+ DR_ACCESS_FN (DDR_A (ddr), i),
+ DR_ACCESS_FN (DDR_B (ddr), i)), NULL))
+ {
+ SUB_DISTANCE (subscript) = chrec_dont_know;
+ return;
+ }
+
diff = affine_fn_minus (fn_a, fn_b);
if (affine_function_constant_p (diff))
It looks like if we ever start to vectorize strided stores then we'd miscompile
a[i*2] = a[(i+1)*2];
as well. Here we have no dependence, thus the conflict function should
be no-conflict (which leads us to no distance vector).
[Bug c++/44561] using nullptr_t with -flto/-fwhopr causes ICE: tree code 'lang_type' is not supported in gimple streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44561 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 11:59:50 UTC --- Author: rguenth Date: Thu Oct 14 11:59:47 2010 New Revision: 165462 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165462 Log: 2010-10-14 Richard Guenther rguent...@suse.de PR lto/44561 * tree.def (NULLPTR_TYPE): New tree code. * dbxout.c (dbxout_type): Handle NULLPTR_TYPE. * dwarf2out.c (is_base_type): Likewise. (gen_type_die_with_usage): Likewise. * sdbout.c (plain_type_1): Likewise. * tree.c (build_int_cst_wide): Likewise. * gimple.c (gimple_types_compatible_p_1): NULLPTR_TYPE types are equal. cp/ * cp-tree.h (NULLPTR_TYPE_P): Adjust. * decl.c (cxx_init_decl_processing): Build a NULLPTR_TYPE node, use build_int_cst. * error.c (dump_type): Handle NULLPTR_TYPE. (dump_type_prefix): Likewise. (dump_type_suffix): Likewise. * mangle.c (write_type): Likewise. * name-lookup.c (arg_assoc_type): Likewise. * rtti.c (typeinfo_in_lib_p): Likewise. * pt.c (tsubst): Likewise. * g++.dg/lto/20101010-3_0.C: New testcase. * g++.dg/lto/20101010-4_0.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/lto/20101010-3_0.C trunk/gcc/testsuite/g++.dg/lto/20101010-4_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/error.c trunk/gcc/cp/mangle.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/cp/rtti.c trunk/gcc/dbxout.c trunk/gcc/dwarf2out.c trunk/gcc/gimple.c trunk/gcc/sdbout.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.def
[Bug c/46015] New: -Wunused-but-set-variable false positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46015
Summary: -Wunused-but-set-variable false positive
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fo...@rmki.kfki.hu
/* test.c */
int f(int i)
{
static void* labs[2] =
{ lab1,
lab2
};
goto *(labs[i1]);
lab1: return 1;
lab2: return 2;
return 0;
}
/* test.c end */
GCC 4.6.0 20101014 -Wall prints the followiung warning:
test.c: In function 'f':
test.c:5:16: warning: variable 'labs' set but not used
[-Wunused-but-set-variable]
(GCC 4.5.1 is OK.)
[Bug c++/44561] using nullptr_t with -flto/-fwhopr causes ICE: tree code 'lang_type' is not supported in gimple streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44561 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 12:02:34 UTC --- Fixed.
[Bug driver/46016] New: libgcc build failure for libmpc installation not in /usr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46016 Summary: libgcc build failure for libmpc installation not in /usr Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: amits...@gmx.net Building gcc out-of-tree from latest svn checkout (r165458). configure line: ~/src/gcc/configure --prefix=/home/amit/install/gcc Installing libmpc from sources either in my home dir or in /usr/local produces the following error (in case of installation in home dir, I appended --with-mpc=/home/amit/install/mpc --with-mpc-include=/home/amit/install/mpc/include --with-mpc-lib=/home/amit/install/mpc/lib to the configure line): checking for x86_64-unknown-linux-gnu-gcc... /home/amit/build/gcc/./gcc/xgcc -B/home/amit/build/gcc/./gcc/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/bin/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/include -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/home/amit/build/gcc/x86_64-unknown-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 The config.log snippet is: gcc version 4.6.0 20101014 (experimental) (GCC) configure:3004: $? = 0 configure:2993: /home/amit/build/gcc/./gcc/xgcc -B/home/amit/build/gcc/./gcc/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/bin/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/include -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/sys-include-V 5 xgcc: error: unrecognized option '-V' xgcc: fatal error: no input files compilation terminated. configure:3004: $? = 1 configure:2993: /home/amit/build/gcc/./gcc/xgcc -B/home/amit/build/gcc/./gcc/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/bin/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/include -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/sys-include-qversion 5 xgcc: error: unrecognized option '-qversion' xgcc: fatal error: no input files compilation terminated. configure:3004: $? = 1 configure:3020: /home/amit/build/gcc/./gcc/xgcc -B/home/amit/build/gcc/./gcc/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/bin/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/include -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/sys-include-o conftest -g -O2 conftest.c 5 /home/amit/build/gcc/./gcc/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory configure:3023: $? = 1 configure:3211: checking for suffix of object files configure:3233: /home/amit/build/gcc/./gcc/xgcc -B/home/amit/build/gcc/./gcc/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/bin/ -B/home/amit/install/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/include -isystem /home/amit/install/gcc/x86_64-unknown-linux-gnu/sys-include-c -g -O2 conftest.c 5 /home/amit/build/gcc/./gcc/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory configure:3237: $? = 1
[Bug fortran/46017] New: Reject ALLOCATE(a, a%b) as a%b depends on the allocation status of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017 Summary: Reject ALLOCATE(a, a%b) as a%b depends on the allocation status of a Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Follow up to PR 42647 comment 11 allocate(a1, a1%b1, a1%b1%c1) is invalid as it violates: An allocate-object [...] shall not depend [...] on the [...] allocation status [...] of any allocate-object in the same ALLOCATE statement. (F2008, 6.7.1 ALLOCATE statement first paragraph after C644.) The solution is to write three independent ALLOCATE statements. I think this particular case could be compile-time detectable. Cf. also http://gcc.gnu.org/ml/fortran/2010-10/msg00159.html (contains quote from the F2003 handbook.) Full test case: PR 42647 comment 10
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #33 from Loaden YC loaden at gmail dot com 2010-10-14 12:18:58 UTC --- Because of this issue, I have been using GCC4.4.x, but do not want to upgrade to 4.5.x. Why this issue can not been confirmed?
[Bug c++/45984] [4.6 Regression] ICE: canonical types differ for identical types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45984 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 12:25:36 UTC --- Fixed.
[Bug driver/46016] libgcc build failure for libmpc installation not in /usr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46016 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 13:45:11 UTC --- You need to adjust your runtime linker paths accordingly.
[Bug c/46015] [4.6 Regression] -Wunused-but-set-variable false positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46015 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |4.6.0 Summary|-Wunused-but-set-variable |[4.6 Regression] |false positive |-Wunused-but-set-variable ||false positive
[Bug driver/46016] libgcc build failure for libmpc installation not in /usr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46016 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-14 13:51:36 UTC --- The docs for --with-mpc do mention this: http://gcc.gnu.org/install/configure.html
[Bug rtl-optimization/45570] [4.6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4584
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45570 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org 2010-10-14 14:42:12 UTC --- Fixed.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #34 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-14 15:09:52 UTC --- (In reply to comment #33) Because of this issue, I have been using GCC4.4.x, but do not want to upgrade to 4.5.x. Why this issue can not been confirmed? The way I read it, this is not a bug as Microsoft Visual Studio acts the same way (when their precompiled headers are not included).
[Bug tree-optimization/45957] [4.6 Regression] g++.dg/ext/fnname3.C FAILs with -flto/-fwhopr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45957
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.10.14 15:14:34
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14
15:14:34 UTC ---
This happens because we clear DECL_INITIAL in free-lang-data and appearantly
S::S which is the context of __func__ is DECL_ABSTRACT ...
Surely an artifact of the C++ constructor/destructor cloning.
We could simply remove
if (TREE_CODE (decl) == VAR_DECL)
{
tree context = DECL_CONTEXT (decl);
if (context)
{
enum tree_code code = TREE_CODE (context);
if (code == FUNCTION_DECL DECL_ABSTRACT (context))
{
/* Do not clear the decl context here, that will promote
all vars to global ones. */
DECL_INITIAL (decl) = NULL_TREE;
}
}
}
from free-lang-data.
[Bug c/46014] internal compiler error compiling clamav-0.96.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46014 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-14 15:15:10 UTC --- This is a bug in a version of GMP/MPRF that you are using. *** This bug has been marked as a duplicate of bug 34207 ***
[Bug fortran/34207] libgfortran configure: GNU Fortran is not working on sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34207 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||mar...@htw-saarland.de --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-14 15:15:10 UTC --- *** Bug 46014 has been marked as a duplicate of this bug. ***
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #35 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 15:24:57 UTC --- (In reply to comment #34) (In reply to comment #33) Because of this issue, I have been using GCC4.4.x, but do not want to upgrade to 4.5.x. Why this issue can not been confirmed? The way I read it, this is not a bug as Microsoft Visual Studio acts the same way (when their precompiled headers are not included). This reply either demonstrates complete misunderstanding of the issue or is deliberate misinformation. To set the record straight, Microsoft Visual Studio absolutely doesn't act the same way and doesn't generate neither object files nor DLLs of this ridiculous size, whether precompiled headers are used or not. Besides, the issue does arise when precompiled headers _are_ used with gcc. Continuing to justify what is clearly and uncontroversially a bad regression in gcc by compatibility with MSVC which never suffered from this problem and refusing to even acknowledge the issue, let alone revert the breakage, does no good whatsoever neither to the gcc project nor to its image.
[Bug bootstrap/46018] New: Bootstrap fails on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018 Summary: Bootstrap fails on i386-pc-solaris2.10 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ah...@airmail.net As stated in the summary, the bootstrap build fails when compiling lto-lang.o: /export/home/arth/gnu/gcc-1014/./prev-gcc/xgcc -B/export/home/arth/gnu/gcc-1014/./prev-gcc/ -B/export/home/arth/local/i386-pc-solaris2.10/bin/ -B/export/home/arth/local/i386-pc-solaris2.10/bin/ -B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem /export/home/arth/local/i386-pc-solaris2.10/include -isystem /export/home/arth/local/i386-pc-solaris2.10/sys-include-c -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -Ilto -I/home/ahaas/gnu/gcc.git/gcc -I/home/ahaas/gnu/gcc.git/gcc/lto -I/home/ahaas/gnu/gcc.git/gcc/../include -I/home/ahaas/gnu/gcc.git/gcc/../libcpp/include -I/export/home/arth/local/include -I/export/home/arth/local/include -I/home/ahaas/gnu/gcc.git/gcc/../libdecnumber -I/home/ahaas/gnu/gcc.git/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/include/libelf -I/export/home/arth/local/include /home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c -o lto/lto-lang.o /home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c: In function 'lto_type_for_mode': /home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c:951:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1881 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [lto/lto-lang.o] Error 1 The error itself is a gcc_assert() in dwarf2out.c: gcc_assert (REGNO (XEXP (src, 0)) == cfa.reg) Using 'git bisect' I was able to identify the revision which introduced the failure: 4899856f3f2fdefaffa0d5355d8dae034da9ec26 is the first bad commit commit 4899856f3f2fdefaffa0d5355d8dae034da9ec26 Author: bernds ber...@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Sep 23 10:04:33 2010 + PR rtl-optimization/44374 * basic-block.h (enum bb_flags): Add BB_MODIFIED. * df-core.c (df_set_bb_dirty): Set it. * ifcvt.c (find_memory): Remove function. (dead_or_predicable): Use can_move_insns_across. * df.h (can_move_insns_across): Declare function. * cfgcleanup.c (block_was_dirty): New static variable. (try_crossjump_bb, try_forward_edges): Test BB_MODIFIED flag rather than df_get_bb_dirty. (try_head_merge_bb): New static function. (try_optimize_cfg): Call it. Call df_analyze if block_was_dirty is set. * df-problems.c: Include target.h (df_simulate_find_uses): New static function. (MEMREF_NORMAL, MEMREF_VOLATILE): New macros. (find_memory, find_memory_store): New static functions. (can_move_insns_across): New function. * Makefile.in (df-problems.o): Update dependencies. testsuite/ PR rtl-optimization/44374 * gcc.target/arm/headmerge-1.c: New test. * gcc.target/arm/headmerge-2.c: New test. * gcc.target/i386/headmerge-1.c: New test. * gcc.target/i386/headmerge-2.c: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/tr...@164552 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 8eba3de7802f571601cb7092cfd546609f24086f c8b21579e48331ae0fa528fb89a228ea94211691 M gcc My last successful build was on Sep. 22: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.6.0/lto-wrapper Target: i386-pc-solaris2.10 Configured with: /home/ahaas/gnu/gcc.git/configure --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran --disable-nls --with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local --enable-checking=release --enable-threads=posix --with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no --enable-objc-gc --build=i386-pc-solaris2.10 Thread model: posix gcc version 4.6.0 20100922 (experimental) (GCC)
[Bug c++/45382] internal compiler error: tree code ‘call_expr’ is not supported in gimple streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45382 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 15:31:42 UTC --- Author: rguenth Date: Thu Oct 14 15:31:36 2010 New Revision: 165471 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165471 Log: 2010-10-14 Richard Guenther rguent...@suse.de PR lto/45382 * g++.dg/lto/20101014-2_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/20101014-2_0.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/45382] internal compiler error: tree code ‘call_expr’ is not supported in gimple streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45382 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.14 15:33:17 Known to work||4.6.0 Ever Confirmed|0 |1 Known to fail|| --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 15:33:17 UTC --- Works on trunk.
[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||i386-pc-solaris2.10 Target Milestone|--- |4.6.0 Summary|Bootstrap fails on |[4.6 Regression] Bootstrap |i386-pc-solaris2.10 |fails on ||i386-pc-solaris2.10
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #36 from Dave Korn davek at gcc dot gnu.org 2010-10-14 15:37:34 UTC --- Hi everyone, sorry I've been busy working on LTO stuff for a bit but I haven't forgotten this. Before this discussion gets too heated, could Vadim and/or Cesar please add some of the object files we've been discussing as attachments to this bug report, so that we can all take a close look at why gcc's files are so much bigger? Thanks. I think depending what we uncover this might be an enhancement request rather than a bug, but we'll see.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #37 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 15:42:59 UTC --- Created attachment 22037 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22037 appbase.cpp file from wxWidgets compiled with g++ 4.4
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #38 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 15:44:23 UTC --- Created attachment 22038 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22038 appbase.cpp file from wxWidgets compiled with g++ 4.5
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Vadim Zeitlin vz-gcc at zeitlins dot org changed: What|Removed |Added Attachment #22037|0 |1 is obsolete|| --- Comment #39 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 15:45:41 UTC --- Created attachment 22039 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22039 appbase.cpp file from wxWidgets compiled with g++ 4.4 Replaces previous file which was uncompressed, sorry for the double post.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #40 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 15:47:36 UTC --- (In reply to comment #36) could Vadim and/or Cesar please add some of the object files we've been discussing as attachments to this bug report, so that we can all take a close look at why gcc's files are so much bigger? I attached 4.4 and 4.5 versions and can also add 3.4 one as well as MSVC9 build of the same file, please let me know if this could be useful. Thanks!
[Bug c/45969] [4.5/4.6 Regression] ICE in build_binary_op, at c-typeck.c:9833
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45969 --- Comment #3 from Joseph S. Myers jsm28 at gcc dot gnu.org 2010-10-14 15:48:59 UTC --- Author: jsm28 Date: Thu Oct 14 15:48:52 2010 New Revision: 165472 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165472 Log: PR c/45969 * c-typeck.c (build_binary_op): Don't try to compute a semantic type with excess precision for boolean operations. testsuite: * gcc.c-torture/compile/pr45969-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr45969-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #41 from Dave Korn davek at gcc dot gnu.org 2010-10-14 15:50:53 UTC --- (In reply to comment #40) (In reply to comment #36) could Vadim and/or Cesar please add some of the object files we've been discussing as attachments to this bug report, so that we can all take a close look at why gcc's files are so much bigger? I attached 4.4 and 4.5 versions and can also add 3.4 one as well as MSVC9 build of the same file, please let me know if this could be useful. Thanks! Yes please, I'm particularly interested in comparing the gcc files with the MSVC ones. (I'm going to be AFK for a few hours now and will look through them this evening.)
[Bug tree-optimization/44913] [4.6 Regression] -ftree-vectorize causes FAIL: gcc.dg/pr44838.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44913 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 15:51:22 UTC --- Author: rguenth Date: Thu Oct 14 15:51:15 2010 New Revision: 165473 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165473 Log: 2010-10-14 Richard Guenther rguent...@suse.de PR tree-optimization/44913 * tree-data-ref.c (disjoint_objects_p): Remove. (dr_may_alias_p): Simplify. Only hand the base object to the alias-oracle. * tree-ssa-alias.c (ptr_deref_may_alias_decl_p): Handle some more trees, bail out instead of asserting. (ptr_derefs_may_alias_p): Likewise. Export. (refs_may_alias_p_1): Handle STRING_CSTs. * tree-ssa-alias.h (ptr_derefs_may_alias_p): Declare. * gcc.dg/torture/pr44913.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr44913.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h
[Bug tree-optimization/44913] [4.6 Regression] -ftree-vectorize causes FAIL: gcc.dg/pr44838.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44913 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-14 15:55:34 UTC --- Fixed.
[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.10.14 15:56:50 CC||hjl.tools at gmail dot com Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-14 15:56:50 UTC --- Please provide preprocessed file.
[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-14 15:57:52 UTC --- Please also show the full options passed to cc1.
[Bug lto/45343] LTO doesn't work with Boost on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45343 xunxun1982 xunxun1982 at gmail dot com changed: What|Removed |Added CC||xunxun1982 at gmail dot com --- Comment #6 from xunxun1982 xunxun1982 at gmail dot com 2010-10-14 15:57:43 UTC --- I encountered similar problems above by using mingw gcc4.5.1 -flto to compile the wxWidgets dll.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #42 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 16:01:20 UTC --- Created attachment 22040 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22040 appbase.cpp file from wxWidgets compiled with g++ 3.4
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #43 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 16:01:55 UTC --- Created attachment 22041 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22041 appbase.cpp file from wxWidgets compiled with MSVC 9 (a.k.a. 2008)
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Vadim Zeitlin vz-gcc at zeitlins dot org changed: What|Removed |Added Attachment #22041|0 |1 is obsolete|| --- Comment #44 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 16:05:02 UTC --- Created attachment 22042 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22042 appbase.cpp file from wxWidgets compiled with MSVC 9 (a.k.a. 2008) Oops, sorry for another double post, I accidentally took a non-DLL version of the file the first time, this one is the right one.
[Bug c++/45642] g++ 4.6 regression, c++0x, weird mismatch for arguments with forwarded declaration when attributes are involved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2010-10-14 16:09:10 UTC --- This seems to have been fixed by the patch for bug 45984.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #45 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 16:12:00 UTC --- Here are the files. Notice that about half of the size of the MSVC object file is taken by debug information (/Zi option was used when compiling it) while all gcc versions contain no debug information at all. More details about the file contents can be obtained using dumpbin Microsoft utility which I'd be glad to run for you if you don't have it. Here is just an overview for now: Microsoft (R) COFF/PE Dumper Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build/msw/vc_mswudll/base/appbase.obj File Type: COFF OBJECT Summary 4 .CRT$XCU 29 .bss 3E9 .data 345D0 .debug$S 50 .debug$T 68D2 .drectve E67 .rdata 8BC .rdata$r 178 .sxdata 8A34 .text 13D3 .text$x 18 .text$yc 14 .text$yd 14B4 .xdata$x
[Bug target/43129] Simplify global variable's address loading with option -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129 Stephen Clarke stephen.clarke at st dot com changed: What|Removed |Added CC||stephen.clarke at st dot ||com --- Comment #8 from Stephen Clarke stephen.clarke at st dot com 2010-10-14 16:32:56 UTC --- For arm instruction set, could you fold pc into the indexing to save an instruction? foo: ldr r3, .L2// C .LPIC0: ldr r3, [r3,pc]// C @ sp needed for prologue ldr r2, [r3] str r0, [r3] mov r0, r2 bx lr .L3: .align 2 .L2: .word ABS_ADDRESS_OF_GOT_ENTRY_FOR_i -(.LPIC0+4) // C
Re: [Bug target/43129] Simplify global variable's address loading with option -fpic
On Thu, 2010-10-14 at 16:33 +, stephen.clarke at st dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129 Stephen Clarke stephen.clarke at st dot com changed: What|Removed |Added CC||stephen.clarke at st dot ||com --- Comment #8 from Stephen Clarke stephen.clarke at st dot com 2010-10-14 16:32:56 UTC --- For arm instruction set, could you fold pc into the indexing to save an instruction? foo: ldr r3, .L2// C .LPIC0: ldr r3, [r3,pc]// C You'll find that the ARM-ARM thinks that PC in any of the 3 locations in this instruction form is *unpredictable*. Thus this form of the instruction should not be used. cheers Ramana
[Bug target/43129] Simplify global variable's address loading with option -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129 --- Comment #9 from ramana.radhakrishnan at arm dot com ramana.radhakrishnan at arm dot com 2010-10-14 16:39:26 UTC --- On Thu, 2010-10-14 at 16:33 +, stephen.clarke at st dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129 Stephen Clarke stephen.clarke at st dot com changed: What|Removed |Added CC||stephen.clarke at st dot ||com --- Comment #8 from Stephen Clarke stephen.clarke at st dot com 2010-10-14 16:32:56 UTC --- For arm instruction set, could you fold pc into the indexing to save an instruction? foo: ldr r3, .L2// C .LPIC0: ldr r3, [r3,pc]// C You'll find that the ARM-ARM thinks that PC in any of the 3 locations in this instruction form is *unpredictable*. Thus this form of the instruction should not be used. cheers Ramana
[Bug ada/46019] New: [4.3/4.4/4.5/4.6 Regression] x / (0x200000000ULL y) miscompilation with 32-bit HWI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46019
Summary: [4.3/4.4/4.5/4.6 Regression] x / (0x2ULL y)
miscompilation with 32-bit HWI
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: ada
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
extern void abort (void);
int
main (void)
{
unsigned long long l = 0x400ULL;
int n;
for (n = 0; n 8; n++)
if (l / (0x2ULL n) != (0x200 n))
abort ();
return 0;
}
is miscompiled on 32-bit HWI targets, e.g. i?86-linux, since PR26026 fix.
[Bug ada/46019] [4.3/4.4/4.5/4.6 Regression] x / (0x200000000ULL y) miscompilation with 32-bit HWI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46019 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.3.6
[Bug target/43129] Simplify global variable's address loading with option -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129 --- Comment #10 from Stephen Clarke stephen.clarke at st dot com 2010-10-14 17:01:47 UTC --- OK, I can see that the ARM ARM states for Rm == PC then its unpredictable. But for Rn == PC, I can only see that its unpredictable if W is 1 or P is 0 (I am looking at encoding A1). So I am struggling to understand that: ldr r3, [pc,r3] is unpredictable. Forgive me if I made a mistake, my knowledge of ARM is a little rusty.
[Bug fortran/46020] New: Improve error string for BIND(C) diagnostic for len1 character return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46020 Summary: Improve error string for BIND(C) diagnostic for len1 character return type Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following is a misleading error message. The return type may be a character string -- but only of length one! FUNCTION F_X(A) bind(c,name='F_X') 1 Error: Return type of BIND(C) function 'f_x' at (1) cannot be a character string Example (taken from: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ee444a5894644f72#) FUNCTION F_X(A) bind(c,name='F_X') CHARACTER*(*) F_X END FUNCTION NAG prints: Error: BIND(C) function F_X has assumed CHARACTER length though the error for CHARACTER(len=4) is also not that helpful: Error: BIND(C) function F_X has CHARACTER(LEN=4) Maybe one can keep the current string and only add with length 1, i.e. Error: Return type of BIND(C) function 'f_x' at (1) cannot be a character string with length 1
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #46 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 17:09:05 UTC --- Another data point after having a closer look at .drectve section in all of the files: as previously noticed, 4.4 generates -export directives for 180 symbols while 4.5 generates them for 2724 symbols. MSVC however records /EXPORT directives for 526 symbols when using PCH and 3764 symbols when not using PCH. In the latter case the size of the object file also inflates to 3.1MB (with all sections growing, not just the .drectve one). So while it's difficult to compare the sets of symbols because of the different name mangling schemes used, it does seem that MSVC generates these directives for all of the class members used, as 4.5 does and unlike 4.4. However many classes included in 4.5 don't appear at all in the MSVC file when using PCH resulting in much more reasonable object file sizes. It still remains that the size of the DLL produced by MSVC is very small compared to gcc. E.g. the wxbase DLL is 1.9MB with MSVC and 6.5MB with gcc 4.4 while the entire wxcore DLL is just 3.9MB with MSVC and 11.6MB with gcc 4.4, without even mentioning 4.5 numbers. This is without using any fancy optimizations (i.e. /LG and/or /LTCG MSVC options). And the size of the DLL does _not_ depend on whether PCH was used or not (although the compilation speed and disk consumption of the object files definitely do, by a factor of more than 10 for both of them). So maybe the new 4.5 behaviour is indeed more MSVC-like. But MSVC seems to avoid generating ~80% of the stuff gcc creates when using PCH and its linker still creates reasonably sized files in reasonable time even when the object files contain a lot of redundant sections. But using MSVC strategy for gcc currently is simply disastrous and I still don't understand why shouldn't the change of r147799 be reverted now and be reapplied later when PCH handling is improved and/or the linker is capable of dealing with it. If this is not a regression I honestly don't know what counts as one.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #47 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-14 17:13:01 UTC --- One should note that GCC's implementation of PCH is way different from MSVC's. So comparing with PCH is not the correct thing to do really. PCH in GCC is really preprocessed/sematicized headers rather than header that is an object file like in MSVC's case.
[Bug fortran/46020] Improve error string for BIND(C) diagnostic for len1 character return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46020 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-14 17:14:45 UTC --- Thinking of it again, one probably needs also NAGs error message as: FUNCTION F_X(A) bind(c,name='F_X') CHARACTER*(*) F_X END FUNCTION ... interface FUNCTION F_X(A) bind(c,name='F_X') CHARACTER*(1) F_X END FUNCTION end interface is also invalid - even though the effective string length is one; F2008 has: If the type is character, the length type parameter is interoperable if and only if its value is one. [...] [only interoperable] if it is of type character its length is not assumed or declared by an expression that is not a constant expression. Thus, one could think of handling the assumed length case explicitly. Or one uses, e.g. Error: Return type of BIND(C) function 'f_x' at (1) of character type must have length 1
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #48 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-10-14 17:29:46 UTC --- (In reply to comment #47) One should note that GCC's implementation of PCH is way different from MSVC's. So comparing with PCH is not the correct thing to do really. I understand this in theory but in practice nobody uses MSVC without PCH (and I guess by now most people use PCH with gcc as well but this doesn't change anything here, of course, as after this change gcc is unusable, with or without PCH). Anyhow, notice that MSVC still manages to produce correctly-sized DLLs even without using PCH. And in any case while comparing with MSVC may be interesting, surely the most urgent goal is to fix gcc to actually work and not to make it more similar to MSVC at the price of breaking it completely? I just can't wrap my head around your arguments, everything you say may be correct (except comment 6) but how do you deduce from it that the current situation is fine and don't even want to acknowledge this change for a bug and regression that it is is beyond me.
[Bug tree-optimization/46021] New: 3 tree-ssa tests XPASS almost everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46021 Summary: 3 tree-ssa tests XPASS almost everywhere Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Target: i386-pc-solaris2.*, sparc-sun-solaris2.*, alpha-dec-osf5.1b, mips-sgi-irix6.5 Three tree-ssa tests started to XPASS on all of my targets between 20100520 and 20100708: XPASS: gcc.dg/tree-ssa/20031106-3.c scan-tree-dump-times optimized link_error 0 XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times optimized link_error 0 XPASS: gcc.dg/tree-ssa/fre-vce-1.c scan-tree-dump-times fre sv.i 2 If this is expected, either the xfail should be removed completely or adapted to remove that useless testsuite noise.
[Bug target/46022] New: [4.6 regression] gcc.dg/vect/vect-double-reduc-5.c FAILs on Solaris 10/x86 with gas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46022 Summary: [4.6 regression] gcc.dg/vect/vect-double-reduc-5.c FAILs on Solaris 10/x86 with gas Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: i386-pc-solaris2.10 Target: i386-pc-solaris2.10 Build: i386-pc-solaris2.10 Between 20100726 and 20100823, the gcc.dg/vect/vect-double-reduc-5.c execution test started to FAIL on Solaris 10/x86 with GNU as (2.20.1) only. With Sun as, everything works fine. This is a regression from the 4.5 branch.
[Bug target/46023] New: gcc.dg/vect/pr43430-2.c FAILs on Solaris 8 and 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46023 Summary: gcc.dg/vect/pr43430-2.c FAILs on Solaris 8 and 9/x86 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: i386-pc-solaris2.[89] Target: i386-pc-solaris2.[89] Build: i386-pc-solaris2.[89] On Solaris 8 and 9/x86, gcc.dg/vect/pr43430-2.c FAILs: FAIL: gcc.dg/vect/pr43430-2.c scan-tree-dump-times vect vectorized 1 loops 1
[Bug fortran/46010] I/O: Namelist-reading bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46010 --- Comment #5 from Marco van Hulten marco at hulten dot org 2010-10-14 18:15:59 UTC --- (In reply to comment #4) [...] The issue is really the .true. (T,true, .false., F, false). If the last item (in the namelist and in the derived type) is an integer or a string it works. No, that doesn't seem to be the issue. I tried both your minimal test case as well as my test case, with an added character as well as an added number, but all give the following result: ma...@graviton testje $ gfortran -std=f2003 test.f90 ma...@graviton testje $ ./a.out NAMTOPTRC TRACER(1)%SNAME=Aa, TRACER(1)%LINI=T, TRACER(1)%GETAL= 1, TRACER(2)%SNAME=Bb, TRACER(2)%LINI=T, TRACER(2)%GETAL= 1, TRACER(3)%SNAME=Cc, TRACER(3)%LINI=T, TRACER(3)%GETAL= 1, / ma...@graviton testje $ gfortran test.f90 ma...@graviton testje $ ./a.out At line 13 of file test.f90 (unit = 99, file = 'nml.dat') Fortran runtime error: Bad data for namelist object tracer%getal
[Bug c++/46024] New: g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46024 Summary: g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: i386-pc-solaris2.[89], sparc-sun-solaris2.8 Target: i386-pc-solaris2.[89], sparc-sun-solaris2.8 Build: i386-pc-solaris2.[89], sparc-sun-solaris2.8 Created attachment 22043 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22043 preprocessed input (from Solaris 8/x86) for miss-format-1.C The g++.dg/warn/miss-format-1.C FAILs on both Solaris 8 and 9/x86 and Solaris 8/SPARC, but not on Solaris 9/SPARC: i386-pc-solaris2.8: FAIL: g++.dg/warn/miss-format-1.C printf attribute warning (test for warnings, line 17) FAIL: g++.dg/warn/miss-format-1.C printf attribute warning 2 (test for warnings, line 42) FAIL: g++.dg/warn/miss-format-1.C (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/warn/miss-format-1.C:26:18: error: 'vscanf' was not declared in this scope i386-pc-solaris2.9: FAIL: g++.dg/warn/miss-format-1.C printf attribute warning (test for warnings, line 17) FAIL: g++.dg/warn/miss-format-1.C printf attribute warning 2 (test for warnings, line 42) sparc-sun-solaris2.8: FAIL: g++.dg/warn/miss-format-1.C (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/warn/miss-format-1.C:26:18: error: 'vscanf' was not declared in this scope It seems strange to get that excess error even though there's a dg-error covering exactly that situation. But what's even more strange is that the Solaris 8 and 9/x86 compilers don't warn for lines 17 and 42 for exactly the same preprocessed input that the Solaris 8/SPARC compiler warns about: s8sparc% gcc -Wmissing-format-attribute -S miss-format-1.ii miss-format-1.ii: In function 'void foo(const char*, ...)': miss-format-1.ii:123:19: warning: function might be possible candidate for 'gnu_printf' format attribute [-Wmissing-format-attribute] miss-format-1.ii: In function 'void bar(const char*, ...)': miss-format-1.ii:131:18: error: 'vscanf' was not declared in this scope miss-format-1.ii: In function 'void vfoo(const char*, va_list)': miss-format-1.ii:145:20: warning: function might be possible candidate for 'gnu_printf' format attribute [-Wmissing-format-attribute] s9x86% gcc -Wmissing-format-attribute -S miss-format-1.ii miss-format-1.s8x86.ii: In function 'void bar(const char*, ...)': miss-format-1.s8x86.ii:131:18: error: 'vscanf' was not declared in this scope I'd have expected such a warning to be target-independent.
[Bug target/46025] New: [4.6 regression] gcc.target/i386/pr38240.c FAILs on Solaris 8 and 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46025 Summary: [4.6 regression] gcc.target/i386/pr38240.c FAILs on Solaris 8 and 9/x86 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: i386-pc-solaris2.[89] Target: i386-pc-solaris2.[89] Build: i386-pc-solaris2.[89] Between 20100722 and 20100823, gcc.target/i386/pr38240.c started to FAIL on Solaris 8 and 9 x86: FAIL: gcc.target/i386/pr38240.c -Wl,-M,/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/clearcap.map (internal compiler error) FAIL: gcc.target/i386/pr38240.c -Wl,-M,/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/clearcap.map (test for excess errors) /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr38240.c: In function 'g': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr38240.c:8:21: internal compiler error: in convert_move, at expr.c:326
