Re: Why can't copy renaming capture this assignment?
On Sat, Mar 31, 2012 at 6:23 AM, Jiangning Liu jiangning@arm.com wrote:
Hi,
For this small case,
char garr[100];
void f(void)
{
unsigned short h, s;
s = 20;
for (h = 1; h (s-1); h++)
{
garr[h] = 0;
}
}
After copyrename3, we have the following dump,
f ()
{
short unsigned int h;
int D.4066;
bb 2:
D.4066_14 = 1;
if (D.4066_14 = 18)
goto bb 3;
else
goto bb 4;
bb 3:
# h_15 = PHI h_8(3), 1(2)
# D.4066_16 = PHI D.4066_4(3), D.4066_14(2)
garr[D.4066_16] = 0;
h_8 = h_15 + 1;
D.4066_4 = (int) h_8;
if (D.4066_4 = 18)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
copy renaming fails to capture the assignment statement D.4066_4 = (int)
h_8; to trigger renaming partition coalesce.
I find gimple_assign_single_p invoked by gimple_assign_ssa_name_copy_p
always returns false, because for this statement gs-gsbase.subcode is
NOP_EXPR rather than GIMPLE_SINGLE_RHS.
Should subcode be correctly initialized anywhere to fix this problem?
BTW, my expectation after copy renaming is like below,
f ()
{
int D.4679;
bb 2:
D.4679_7 = 1;
if (D.4679_7 != 19)
goto bb 3;
else
goto bb 4;
bb 3:
# D.4679_15 = PHI D.4679_4(3), D.4679_7(2)
# D.4679_17 = PHI D.4679_14(3), 1(2)
garr[D.4679_15] = 0;
D.4679_14 = D.4679_17 + 1;
D.4679_4 = D.4679_14;
if (D.4679_4 != 19)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
Err - you completely lost the fact that h was short instead of int.
Richard.
and then PRE can finally remove that redundancy for symbol D. away.
Thanks,
-Jiangning
Re: Plugins always enabled in GCC 4.8?
On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch bas...@starynkevitch.net wrote: On Sun, 01 Apr 2012 16:41:09 -0400 Diego Novillo dnovi...@google.com wrote: On 3/31/12 1:51 PM, Basile Starynkevitch wrote: If we want to aim towards a more modular GCC made of several shared libraries, it seems that we are requiring the host system to have dynamic libraries (which is not a big deal today; all the major OSes running on developers desktop or laptop have them). I don't follow. Modularity does not require shared libraries. Indeed, but when GCC is made of several shared libraries, it would be modular, since each such shared library would be defined by a module. (I mean that modules are a design thing existing at the source level, and each shared library would implement one module; look into GTK/Gnome to feel what I mean: Pango, Glib, Gio, Atk, are modules there and have libpango.so, libglib.so, libgio.so, libatk.so ... at runtime..). In that case, I think that we should always --enable-plugin at configure time, hence making that configure switch useless (since always on). Plugins are auto-detected on systems that support it and always enabled. I've heard that some Linux distributions (perhaps some version of RedHat?) explicitly configure with --disable-plugin SUSE does. And until we get a real plugin API we will continue to do so. Richard.
Re: GCC 4.7.0 as a AVR cross compiler
On 03/30/2012 05:46 PM, stuart wrote: I can not seem to get gcc 4.7.0 to compile; it will not complete the configuration stage complaining about missing packages (GMP, MPFR and MPC). Go into the top-level source directory in the unpacked gcc sources and run this script: ./contrib/download_prerequisites Andrew.
Re: Plugins always enabled in GCC 4.8?
On Mon, Apr 02, 2012 at 10:44:41AM +0200, Richard Guenther wrote:
On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Sun, 01 Apr 2012 16:41:09 -0400
Diego Novillo dnovi...@google.com wrote:
On 3/31/12 1:51 PM, Basile Starynkevitch wrote:
I've heard that some Linux distributions (perhaps some version of RedHat?)
explicitly
configure with --disable-plugin
SUSE does. And until we get a real plugin API we will continue to do so.
I suppose that internally at SUSE you have a well defined criteria of what a
real plugin API should be.
Unfortunately, I (Basile) have no precise idea of what such a criteria
should be.
(it probably could be related to what I believe being modular means, but
AFAIU being modular have different meanings to different persons on this
gcc@ list, and there is no consensus here).
As a plugin developer, I call plugin API whatever is available as
callable from plugins, so for me the plugin API is just the set of headers
under $(gcc -print-file-name=plugin/include), which I agree is not very sexy
today, but is the only things plugin developers can have today.
So it seems that real plugin API has no consensual definition yet.
A simple example is libiberty: should it be part of the plugin API? If yes,
every function there (including pex_execute xstrndup which current plugins
cannot use, because libiberty is statically linked, ... etc etc ad nauseam).
If libiberty is not part of the plugin API, how should plugin writers obtain
similar services?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [GCC Steering Committee] Android sub-port reviewer
On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote: I volunteer as the reviewer for Android sub-port. Android/Bionic support is an extension over Linux port and is being gradually added for more and more architectures. I wrote the original Android GCC support for ARM (under a watchful design eye of Joseph Myers), and know how the bits fit together. As adding Android support to a new architecture requires changes to that architecture, the architecture maintainer will have the power of veto for the Android-related changes. One of the members of SC raised a good point about whether architecture maintainers would prefer to handle the Android patches themselves. My intention is to spare you the additional headache of dealing with Android, but, well, maybe you like it :-). Richard E., Jan, Richard S., Do you want to handle Android changes by yourself or do you want to delegate? I am happy with the idea of having Android manintainer. The configure bits are kind of independent of the actual architecture support anyway. Honza Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7)
Hello All,
It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for GCC
4.6 or 4.7.
NEWS for 0.9.5rc2 MELT plugin for GCC 4.6 4.7
[[April 2nd 2012]] release candidate 2
Alternative infix syntax is abandoned (it was never implemented)
Accept $(sub sepxr) in macro-string and $[seq sepxr]
Handle SIGIO Unix signals with asynchronous input channels
(experimental feature)
Can be compiled by C++ (since GCC 4.7 often is)
All the values are translated to melt_ptr_t variables, not void*
ones.
###
I believe it should work for a GCC 4.7 compiled in C++ mode.
Thanks to Alexnadre Lissy Romain Geissler for their help.
Please test and report bugs or build success or failure on
gcc-m...@googlegroups.com list.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Plugins always enabled in GCC 4.8?
On Mon, Apr 2, 2012 at 12:37 AM, Basile Starynkevitch bas...@starynkevitch.net wrote: On Sun, 01 Apr 2012 16:41:09 -0400 Diego Novillo dnovi...@google.com wrote: On 3/31/12 1:51 PM, Basile Starynkevitch wrote: If we want to aim towards a more modular GCC made of several shared libraries, it seems that we are requiring the host system to have dynamic libraries (which is not a big deal today; all the major OSes running on developers desktop or laptop have them). I don't follow. Modularity does not require shared libraries. Indeed, but when GCC is made of several shared libraries, it would be modular, since each such shared library would be defined by a module. I feel that you are moving the goal post, and you are either confusing the notion of modularity with something else you have not been asking until now. I find that a bit worrisome. As pointed out by Diego, modularity and shared libraries are orthogonal notions. Modularity does not require shared libraries, not does it provide them. A long time ago, GCC was designed on purpose in a way that entangled all levels of abstractions for fear that making it modular would encourage proprietary work based on GCC without the benefits of contribution back. Eventually the argument was won that we can make GCC follow less contrived software engineering practices without giving away the treasure. You appear to be moving in directions that may give pause to those who championed better separation of concerns in GCC. -- Gaby
Re: Plugins always enabled in GCC 4.8?
On Mon, Apr 02, 2012 at 05:40:37AM -0500, Gabriel Dos Reis wrote:
On Mon, Apr 2, 2012 at 12:37 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Sun, 01 Apr 2012 16:41:09 -0400
Diego Novillo dnovi...@google.com wrote:
On 3/31/12 1:51 PM, Basile Starynkevitch wrote:
If we want to aim towards a more modular GCC made of several shared
libraries, it seems
that we are requiring the host system to have dynamic libraries (which
is not a big deal
today; all the major OSes running on developers desktop or laptop have
them).
I don't follow. Modularity does not require shared libraries.
Indeed, but when GCC is made of several shared libraries, it would be
modular, since each
such shared library would be defined by a module.
I feel that you are moving the goal post, and you are either
confusing the notion of modularity with something else you have not
been asking until now. I find that a bit worrisome.
What I was just saying that if a software is properly organized as a set of
well defined shared libraries (on current GNU/Linux systems), then these
shared libraries are defining an organisation of modules and bring ipso
facto some modularity. Of course, a modular software can be linked
statically, because IMHO modules are mostly a property of the source code,
not of the binary. (And a set of dynamically linked libraries can stay messy,
e.g. if it had circular dependencies).
(For instance, ocaml may not have shared libraries, but does have modules at
the language level.)
I also am in favor of having a software linked dynamically with shared
libraries, for a very pragramtical reason: If a software has shared
libraries, then modifying one such library in its implementation (not its
interface) is very often easier for the developer, who can, thanks to the
dynamic linking, test and use his improved shared library more easily and
more quickly. In particular, if GCC were made of shared libraries, I believe
that the build time would be much faster for the developer (ie the GCC
contributor), and this is a big comfort in practice.
As pointed out by Diego, modularity and shared libraries are orthogonal
notions. Modularity does not require shared libraries, not does it
provide them.
Indeed. But I would think that properly designed shared libraries make a
modular software (of course, the design could be poor; at the worst mutually
circularily depending shared libraries don't give any modularity).
A long time ago, GCC was designed on purpose in a way that entangled
all levels of abstractions for fear that making it modular would encourage
proprietary work based on GCC without the benefits of contribution back.
Yes, but I thought that position was de jure abandoned once the licence
permitted plugins (I was understoooding the heated debate on the runtime
exception license was exactly that, and also I understood that debate has
ended).
Eventually the argument was won that we can make GCC follow
less contrived software engineering practices without giving away the
treasure.
I certainly don't want to open that debate again, and I really think it was
settled long time ago (ie.e. when the runtime exception license has been
last published, legally enabling the possibility of plugins).
You appear to be moving in directions that may give pause to
those who championed better separation of concerns in GCC.
I am not sure to understand that last sentence (I had to read it 4 times,
with different ways of understanding it). But I certainly don't understand
why you feel that my wish of having a collection of named and identified
modules in GCC is not a way of wanting seperation of concerns in GCC. If GCC
had an organisation in well identified modules (each having a name), why
would that go against seperation of concerns? I feel quite the opposite (see
Gnome/Gtk as my favorite example). And if GCC had well identified modules,
it would be easy (useful, but not necessary, just possible comfortable) to
make it a collection of shared libraries (of course, we still would give the
ability to disable shared libraries at configure time to those wanting
that).
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Plugins always enabled in GCC 4.8?
On Mon, Apr 2, 2012 at 6:17 AM, Basile Starynkevitch bas...@starynkevitch.net wrote: You appear to be moving in directions that may give pause to those who championed better separation of concerns in GCC. I am not sure to understand that last sentence (I had to read it 4 times, with different ways of understanding it). But I certainly don't understand why you feel that my wish of having a collection of named and identified modules in GCC is not a way of wanting seperation of concerns in GCC. Where do you take that feeling from? -- Gaby
Re: Plugins always enabled in GCC 4.8?
On Mon, Apr 2, 2012 at 2:38 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Mon, Apr 2, 2012 at 6:17 AM, Basile Starynkevitch bas...@starynkevitch.net wrote: You appear to be moving in directions that may give pause to those who championed better separation of concerns in GCC. I am not sure to understand that last sentence (I had to read it 4 times, with different ways of understanding it). But I certainly don't understand why you feel that my wish of having a collection of named and identified modules in GCC is not a way of wanting seperation of concerns in GCC. Where do you take that feeling from? And what does this all have to do with always enabling plugins or not? Richard. -- Gaby
Re: Plugins always enabled in GCC 4.8?
Quoting Basile Starynkevitch bas...@starynkevitch.net: I also am in favor of having a software linked dynamically with shared libraries, for a very pragramtical reason: If a software has shared libraries, then modifying one such library in its implementation (not its interface) is very often easier for the developer, who can, thanks to the dynamic linking, test and use his improved shared library more easily and more quickly. In particular, if GCC were made of shared libraries, I believe that the build time would be much faster for the developer (ie the GCC contributor), and this is a big comfort in practice. I don't see that. Re-linking cc1 / cc1plus is reasonably fast. And you'll have to rebuild all the target libraries for a full test, no matter if you have a monolithic exectuable or one with lots of dsos. But in the latter case, you'll have to dynamically link against numerous dso for each library file compilation. Where we could save rebuilding time is in cutting unwanted header file dependencies, like tm.h included by frontends. So, in that sense, more modularity helps build times. But any gain from not statically re-linking the full executable is likely already lost by more resource-hungry -fpic compilation, and even more so by the dynamic link overhead. Time savings when compiling the compiler with lto might be more noticable, but only because you add additionaly boundaries which severely limit of what lto can do for you. lto and fast turn-around times don't mix very well, anyway.
GRAPHITE-OpenCL?
Hello, The GRAPHITE-OpenCL work published a couple of years ago looks interesting [0]. What’s the status of the code? Is it accessible on-line? Thanks in advance, Ludo’. [0] http://gcc.gnu.org/wiki/summit2010?action=AttachFiledo=gettarget=belevantsev.pdf
Re: C++: Letting compiler know asm block can call function that can throw?
Hi,
On Fri, 30 Mar 2012, Jan Hubicka wrote:
Motion across hardreg sets/uses are not restricted. And I would not expect
an optimizing compiler to do that (it's your own fault to use hardregs in
complex C code).
Well, the syscall sequence is an example of somehting that should be
inlined into arbitrary code w/o potential risk of ICEs.
The syscall sequence doesn't consist of multiple independend instructions,
but rather is one asm with the right constraints. So gcc has no chance to
move something between the register setup (which only is explicit after
reload) and the syscall instruction. If syscall sequences were
implemented like this:
inline int syscall1(int number, long arg1) {
register int ax __asm__(eax);
register long di __asm__(rdi);
ax = number;
di = arg1;
__asm__ volatile (syscall);
}
_then_ we would probably get miscompilations here and there.
Ciao,
Michael.
Re: C++: Letting compiler know asm block can call function that can throw?
On Mon, Apr 02, 2012 at 04:07:59PM +0200, Michael Matz wrote:
On Fri, 30 Mar 2012, Jan Hubicka wrote:
Motion across hardreg sets/uses are not restricted. And I would not
expect
an optimizing compiler to do that (it's your own fault to use hardregs in
complex C code).
Well, the syscall sequence is an example of somehting that should be
inlined into arbitrary code w/o potential risk of ICEs.
The syscall sequence doesn't consist of multiple independend instructions,
but rather is one asm with the right constraints. So gcc has no chance to
move something between the register setup (which only is explicit after
reload) and the syscall instruction. If syscall sequences were
implemented like this:
inline int syscall1(int number, long arg1) {
register int ax __asm__(eax);
register long di __asm__(rdi);
ax = number;
di = arg1;
__asm__ volatile (syscall);
}
_then_ we would probably get miscompilations here and there.
That is actually what is used on most targets, including x86_64 (i?86 is an
exception here, because it has single hard register constraints for most of
the interesting registers).
Jakub
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Stefano == Stefano Lattarini stefano.lattar...@gmail.com writes: Stefano Note there's nothing I'm planning to do, nor I should do, in Stefano this regard: the two setups described above are both already Stefano supported by the current automake implementation (but the last Stefano one is not encouraged, even though it makes perfect sense in Stefano some *rare* situations). I was just pointing out that you have Stefano to choose one of these setups -- so, if you want to distribute Stefano info files, you must accept to have them build in the srcdir. Or we can just stick with an older version of automake. It seems to me that this is the sensible approach. Or move to some other build system; either autogen-based or just requiring GNU make features. The latter is fine for GCC but I'm not sure whether all the src projects are on board. I'm pretty disappointed that automake would make this change. I realize these choices may (arguably) make the most sense for most projects, but the gcc and src trees are not like most projects; and really the whole 'cygnus' feature is there just to support these two big users. Tom
Re: GRAPHITE-OpenCL?
Hello, On Mon, 2 Apr 2012, Ludovic Courtès wrote: Hello, The GRAPHITE-OpenCL work published a couple of years ago looks interesting [0]. What’s the status of the code? Is it accessible on-line? The code has been merged into graphite branch; it can be obtained via: svn co svn://gcc.gnu.org/svn/gcc/branches/graphite (or it can be browsed online; see http://gcc.gnu.org/svn.html for details). Unfortunately, no new developments have happened since then. Alexander
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On 04/02/2012 04:25 PM, Tom Tromey wrote:
Stefano == Stefano Lattarini stefano.lattar...@gmail.com writes:
Stefano Note there's nothing I'm planning to do, nor I should do, in
Stefano this regard: the two setups described above are both already
Stefano supported by the current automake implementation (but the last
Stefano one is not encouraged, even though it makes perfect sense in
Stefano some *rare* situations). I was just pointing out that you have
Stefano to choose one of these setups -- so, if you want to distribute
Stefano info files, you must accept to have them build in the srcdir.
Or we can just stick with an older version of automake.
It seems to me that this is the sensible approach.
Or move to some other build system; either autogen-based or just
requiring GNU make features.
shameless plug
In this later case, you might want to take a look at the Automake-NG fork,
started by myself (and still in a VERY early stage):
- https://lists.gnu.org/mailman/listinfo/automake-ng
Fork which will possibly be the subject of the oncoming Google summer of
code:
- http://www.gnu.org/software/soc-projects/ideas-2012.html#automake
/shameless plug
The latter is fine for GCC but I'm not sure whether all the src projects
are on board.
I'm pretty disappointed that automake would make this change. I realize
these choices may (arguably) make the most sense for most projects, but
the gcc and src trees are not like most projects; and really the whole
'cygnus' feature is there just to support these two big users.
True, and that was even stated in the manual; the whole point of ditching
support for cygnus trees is that by now those two big users are basically
not making any real use of the 'cygnus' option anymore. To quote my
previous report:
And as of today, almost any use of the 'cygnus' option has disappeared
from the GCC and GDB trees; for example, the command:
grep cygnus `find -name '*configure*' -o -name '*[Mm]akefile*' \
-o -name '*.am' -o -name '*.mk'`
yields this in the GCC tree:
./zlib/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus
./zlib/Makefile.in:AUTOMAKE_OPTIONS = 1.8 cygnus
and this in the GDB tree:
./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus
./bfd/doc/Makefile.in:# cygnus option.
./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
./bfd/doc/Makefile.am:# cygnus option.
./etc/configure.texi:option of @file{/usr/cygnus/@var{release}}, where
@var{release} is the
./etc/configure.texi:@file{/usr/cygnus/@var{release}/H-@var{host}}, where
@var{host} is the
./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus
./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus 1.3
./etc/configure.texi:@cindex canadian cross in cygnus tree
./etc/configure.texi:@cindex cygnus configure
Regards,
Stefano
Re: Proposed plugin API for GCC
Hi, On Fri, 30 Mar 2012, Gabriel Dos Reis wrote: On Fri, Mar 30, 2012 at 7:45 PM, David Malcolm dmalc...@redhat.com wrote: Here's another proposal then: actually use GObject introspection - provide a GObject-based API to GCC. In this approach, GCC would gain a dependency on glib and gobject, and expose its API via a .gir file. I greatly prefer the other alternative, by far. By far, by far, by far! I can't repeat it enough :) glibc/gobject in cc1, *shudder*. I think a clean C only API would be the best, and if only because a multitude of wrapper generators exist that work with that. If you do away with the strange Gcc prefix and the 'I' suffix (Interface?) and use some common abbreviations (cfgblock - bb, cfgedge - edge, cgraph - cg) it wouldn't be even too unwieldy. Ciao, Michael.
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Stefano == Stefano Lattarini stefano.lattar...@gmail.com writes: Stefano True, and that was even stated in the manual; the whole point Stefano of ditching support for cygnus trees is that by now those two Stefano big users are basically not making any real use of the 'cygnus' Stefano option anymore. To quote my previous report: Stefano ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus Stefano ./bfd/doc/Makefile.in:# cygnus option. Stefano ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus Stefano ./bfd/doc/Makefile.am:# cygnus option. But this is a reason not to remove it; or at least to restore the previous handling of info files. I don't care about the cygnus option per se. It was always a grab bag of hacks. The issue is removing a feature that an important user relies on. So far the suggested replacements haven't seemed that good to me. Tom
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On 04/02/2012 05:16 PM, Tom Tromey wrote: Stefano == Stefano Lattarini stefano.lattar...@gmail.com writes: Stefano True, and that was even stated in the manual; the whole point Stefano of ditching support for cygnus trees is that by now those two Stefano big users are basically not making any real use of the 'cygnus' Stefano option anymore. To quote my previous report: Stefano ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus Stefano ./bfd/doc/Makefile.in:# cygnus option. Stefano ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus Stefano ./bfd/doc/Makefile.am:# cygnus option. But this is a reason not to remove it; or at least to restore the previous handling of info files. I don't care about the cygnus option per se. It was always a grab bag of hacks. And it's the hacks I'd like to remove, not the option per se :-) The issue is removing a feature that an important user relies on. So far the suggested replacements haven't seemed that good to me. Sorry if I sound dense, but what exactly is the feature you are talking about here? Regards, Stefano
Re: C++: Letting compiler know asm block can call function that can throw?
Hi,
On Mon, 2 Apr 2012, Jakub Jelinek wrote:
inline int syscall1(int number, long arg1) {
register int ax __asm__(eax);
register long di __asm__(rdi);
ax = number;
di = arg1;
__asm__ volatile (syscall);
}
_then_ we would probably get miscompilations here and there.
That is actually what is used on most targets, including x86_64
Yikes! That's indeed the case. I'll want to retract what I said, concede
with Honza that we're lucky and add that we're lucky mostly because
register variables are not regarded as gimple registers, hence all stores
to such variables are regarded as VDEFs. So there will be VDEF/VUSE
chains between initializer and syscall, which prevents most code motion
into that chain. That itself doesn't e.g. prevent the load/store
disambiguator from disambiguating two such decls, even if they refer to
the same hardreg. So we really are merely lucky, with enough effort we
probably could create a miscompiling testcase.
Ciao,
Michael.
Re: [GCC Steering Committee] Android sub-port reviewer
On 01/04/12 20:57, Maxim Kuvyrkov wrote: On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote: I volunteer as the reviewer for Android sub-port. Android/Bionic support is an extension over Linux port and is being gradually added for more and more architectures. I wrote the original Android GCC support for ARM (under a watchful design eye of Joseph Myers), and know how the bits fit together. As adding Android support to a new architecture requires changes to that architecture, the architecture maintainer will have the power of veto for the Android-related changes. One of the members of SC raised a good point about whether architecture maintainers would prefer to handle the Android patches themselves. My intention is to spare you the additional headache of dealing with Android, but, well, maybe you like it :-). Richard E., Jan, Richard S., Do you want to handle Android changes by yourself or do you want to delegate? Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics I have no desire to hold back android development, so I have no objections to an Android-specific maintainer. But the only file in the ARM back-end that is Android specific is t-linux-android, a grand total of ten lines of code. Any file shared with other arm ports would still need generic ARM maintainer approval. There are, however, some target independent android files in the config directory and I guess it would make sense for a maintainer to be appointed for those. R.
Proposed gcc plugin plugin API mk 2 (this time without camel case!)
I wrote a script and ported my proposed API for GCC plugins from my CamelCase naming convention to an underscore_based_convention (and manually fixed up things in a few places also). The result compiles and passes the full test suite for the Python plugin; that said, I'm still breaking the encapsulation in quite a few places (hey, this is an experimental prototype). You can see the latest version of it within the proposed-plugin-api branch of the Python plugin here: http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api within the proposed-plugin-api subdirectory. How is this looking? If this landed e.g. in GCC 4.8, would this be usable by other plugins? Hope this is helpful Dave
compiling gcc 2.95.3 under ubuntu 10.04.2, x86_64
Hello everyone, Not sure if this is the right place to ask this question, feel free to point me in the right direction. I'm looking into the evolution of Linux kernel and this requires me to build some ancient releases (as old as 2.4.0) from source using GCC. I have gcc 4.4.3-4ubuntu5 installed on my lab machine but it's incompatible with these old sources, and the lowest common denominator would be gcc 2.95.3, so I've been trying to compile it from source - so far with little success. It's hard but not impossible - done before by this guy: http://www.trevorpounds.com/blog/?p=111cpage=1#comment-102. I followed all of his suggestions but so far hasn't had much luck - most recent attempt dies with the following message: /usr/bin/ld.bfd.real: error in pic/cstrmain.o(.eh_frame); no .eh_frame_hdr table will be created. The URL above contains a link to my stdout/stderr logs too. Has anyone here tried compiling such an old version of GCC? Any advice/help would be greatly appreciated. Regards, Roman.
Re: [GCC Steering Committee] Android sub-port reviewer
Maxim Kuvyrkov ma...@codesourcery.com writes: On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote: I volunteer as the reviewer for Android sub-port. Android/Bionic support is an extension over Linux port and is being gradually added for more and more architectures. I wrote the original Android GCC support for ARM (under a watchful design eye of Joseph Myers), and know how the bits fit together. As adding Android support to a new architecture requires changes to that architecture, the architecture maintainer will have the power of veto for the Android-related changes. One of the members of SC raised a good point about whether architecture maintainers would prefer to handle the Android patches themselves. My intention is to spare you the additional headache of dealing with Android, but, well, maybe you like it :-). Richard E., Jan, Richard S., Do you want to handle Android changes by yourself or do you want to delegate? Having a separate maintainer of MIPS Android sounds good to me too (and thanks for asking). As Richard E says, we should probably coordinate any changes to the generic MIPS files, but I wouldn't know what's right for Android-specific stuff. Richard
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Stefano == Stefano Lattarini stefano.lattar...@gmail.com writes: Stefano Sorry if I sound dense, but what exactly is the feature you are Stefano talking about here? I was under the impression that it would no longer be possible to build info files in the build tree. But, I see that, according to the Automake manual, I am wrong about that. So, sorry for the noise. Tom
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On 04/02/2012 09:36 PM, Tom Tromey wrote: Stefano == Stefano Lattarini stefano.lattar...@gmail.com writes: Stefano Sorry if I sound dense, but what exactly is the feature you are Stefano talking about here? I was under the impression that it would no longer be possible to build info files in the build tree. It should still be possible, with the right hack (which is tested in the testsuite, and required by other packages anyway). The baseline is: if you don't want your '.info' files to be distributed, then it should be easily possible to have them built in the builddir; but if you want them distributed, they will be built in the srcdir. The rationale to do so is to ensure that, in both cases, the developer's tree layout (as bootstrapped from a VCS checkout) will match the user's tree layout (as obtained from a distribution tarball). But, I see that, according to the Automake manual, I am wrong about that. Weird, I didn't expect that hack to be documented in the manual... And in fact I cannot find it. Could you please point me to it? Thanks. So, sorry for the noise. Well, better safe than sorry :-) Regards, Stefano
Re: GSoC proposal: Provide optimizations feedback through post-compilation messages
Bump! Let me renew my interest in contributing through GSoC with post-compilation feedback (This was not an early april joke). Do you think it could lead to an acceptable GSoC proposal? (mentor interested?) @Tomasz: On the interaction side I totally agree that communication between compiler and programmer is scarce (and there is room for improvement). Focusing too soon on the editor would overlook the vast users needs though, as: _ some users do not use an IDE (and will kindly refuse); _ some users do not need more communication, as they already know what GCC can and cannot do; _ some users do not want more communication, as they have other business to focus on; I think the editor being split from the compiler is good thing. There still exist tools to expose static analysis data from the compiler (and choose the editor to visualize it with), but fundamentally they are assisting him/her rather than helping him/her improve. Instead of gathering loads of data on the optimizations/analysis performed, and filtering it for visualization by the user, we could relate the optimization technique used so that the user truly knows what GCC is capable of (instead of guessing by observation). My proposal is thus not to be confused with a static analysis visualization: the programmer learns what techniques are implemented in GCC (or in compilers in general), how to write code that is more easily compiled, and can further browse the Internet for detailed theory on the techniques involved. The point on the possible-optimizations-which-could-be-enabled-if-specific- -constraint-is-lifted is particularly interesting, but is also extremely risky if the compiler makes a stupid remark on a constraint which can obviously (for the programmer) not be lifted. If ever, I would introduce it with a LOT of care. Thibault ps: As for an editor with real-time feedback on static analysis and more, I am 100% with you :) (and there are some promising prototypes, like in this talk: http://vimeo.com/36579366) Hello all, My name is Thibault Raffaillac, CS degree student at Kungliga Tekniska Högskolan, Stockholm, Sweden (in double-degree partnership with Ecole Centrale Marseille, France). GCC currently provides no concise way to inform the user whether it applied an expected optimization (ie, it understood the code). As a result, some will do premature optimizations when they do not trust the compiler, and some others will create overly convoluted code with blind belief in the compiler. This is especially relevant for users non-initiated to the internals of GCC. The project I would like to propose is a feedback for the optimizations performed by GCC. To avoid binding users to the compiler, I would focus on some very standard optimizations across vendors, or for some specific yet nice features I would indicate their specificity to GCC/an architecture. The feedback would be triggered when compilation is successful, and display a couple of different messages each time it is run: gcc --feedback test.c test.c:xx:x: info: All operands being constant, constant folding was applied to assign '2560' to 'a' test.c:xx:x: info: GCC could not fold constants here because... test.c:xx:x: info: As integers are stored in binary format, strength reduction was applied to replace '* 8' by ' 3' test.c:xx:x: info: Basic block vectorization was applied to pack the 3 independent additions into a single SIMD instruction test.c:xx:x: info: GCC implements unordered_map as open-addressed hash tables, with double hashing probing As a difference with the internal verbose messages, here they would form a set, and the system would remember those already displayed and decrease their frequency of occurence between compilations. All messages would explain what triggered them, cite the optimization name, and describe the consequence. As for the work plan, it would consist in: _ Enumerating all possible messages in the messages set. _ Implementing a function receiving feedback from each optimization unit and choosing whether to display it: info_printf(enum INFO_INDEX, const char*, ...); _ Write a formatting guide for adding messages in the set. My academic background includes compiler construction, C programming and Human- Computer Interactions. I am very much interested in the usability of compilers (on which I am currently carrying my degree thesis - http://www.csc.kth.se/~traf/traf-sketch.pdf) and thus would be glad to contribute to GCC. If this can be of interest, suggestions are welcome! Best regards, Thibault (http://www.csc.kth.se/~traf/)
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Stefano == Stefano Lattarini stefano.lattar...@gmail.com writes: Stefano It should still be possible, with the right hack (which is Stefano tested in the testsuite, and required by other packages Stefano anyway). The baseline is: if you don't want your '.info' files Stefano to be distributed, then it should be easily possible to have Stefano them built in the builddir; but if you want them distributed, Stefano they will be built in the srcdir. Now I am confused. Is it possible to continue to work the way it does today, or not? If so, then great. If not, then we need some other plan. Tom But, I see that, according to the Automake manual, I am wrong about that. Stefano Weird, I didn't expect that hack to be documented in the Stefano manual... And in fact I cannot find it. Could you please Stefano point me to it? Thanks. http://www.gnu.org/software/automake/manual/automake.html#Cygnus Info files are always created in the build directory, and not in the source directory. Packages that don't use the cygnus option can emulate this effect by using the no-installinfo option and listing the generated info files in the CLEANFILES variable. Re-reading the suggestion here, I can't understand how it would work. Anyway the real use in the src tree is different, IIUC. Info files are built in the build tree by developers, but put in the source tree for distribution. Tom
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On 04/02/2012 10:19 PM, Tom Tromey wrote:
Stefano == Stefano Lattarini stefano.lattar...@gmail.com writes:
Stefano It should still be possible, with the right hack (which is
Stefano tested in the testsuite, and required by other packages
Stefano anyway). The baseline is: if you don't want your '.info' files
Stefano to be distributed, then it should be easily possible to have
Stefano them built in the builddir; but if you want them distributed,
Stefano they will be built in the srcdir.
Now I am confused. Is it possible to continue to work the way it does
today, or not?
The point is: if you want to have info files build in the builddir *and*
distributed, than no, it won't be possible (without bending over backwards).
But I still don't understand why it's a big deal to have the '.info' files
placed in the srcdir *if you are going do distribute them*.
If so, then great.
If not, then we need some other plan.
By looking at the 'handle_texinfo_helper' function in the automake script,
I suspect adding a new Automake option 'info-in-builddir' (say) and an
handful of lines to the automake script might be enough to give you an easy
way to force the '.info' files to be generated in the builddir. But before
doing so, I'd like to understand why you want so strongly to support such
a setup.
Tom But, I see that, according to the Automake manual, I am wrong about that.
Stefano Weird, I didn't expect that hack to be documented in the
Stefano manual... And in fact I cannot find it. Could you please
Stefano point me to it? Thanks.
http://www.gnu.org/software/automake/manual/automake.html#Cygnus
Info files are always created in the build directory, and not in the
source directory. Packages that don't use the cygnus option can emulate
this effect by using the no-installinfo option and listing the generated
info files in the CLEANFILES variable.
Re-reading the suggestion here, I can't understand how it would work.
Another automake internal hack basically. For more details, in case you are
interested, see code and comments in the 'automake.in:handle_texinfo_helper'
subroutine, and the test cases txinfo{23,24,25}.test in the Automake
distribution.
Anyway the real use in the src tree is different, IIUC.
Info files are built in the build tree by developers, but put in the
source tree for distribution.
In such a setup, what is the issue with having the '.info' files built
in the srcdir? It's not like the developers will develop with a
read-only source tree, right?
Regards,
Stefano
RE: [GCC Steering Committee] Android sub-port reviewer
Richard Sandiford wrote: Sent: Monday, April 02, 2012 11:45 AM To: Maxim Kuvyrkov Cc: Richard Earnshaw; Jan Hubicka; gcc@gcc.gnu.org Subject: Re: [GCC Steering Committee] Android sub-port reviewer Maxim Kuvyrkov ma...@codesourcery.com writes: On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote: I volunteer as the reviewer for Android sub-port. Android/Bionic support is an extension over Linux port and is being gradually added for more and more architectures. I wrote the original Android GCC support for ARM (under a watchful design eye of Joseph Myers), and know how the bits fit together. As adding Android support to a new architecture requires changes to that architecture, the architecture maintainer will have the power of veto for the Android-related changes. One of the members of SC raised a good point about whether architecture maintainers would prefer to handle the Android patches themselves. My intention is to spare you the additional headache of dealing with Android, but, well, maybe you like it :-). Richard E., Jan, Richard S., Do you want to handle Android changes by yourself or do you want to delegate? Having a separate maintainer of MIPS Android sounds good to me too (and thanks for asking). As Richard E says, we should probably coordinate any changes to the generic MIPS files, but I wouldn't know what's right for Android-specific stuff. Richard Hi All, We did the MIPS Android port, and here is the change that we submitted to googlesource. https://android-review.googlesource.com/#/c/34000/ Please check this file: 0007-gcc-mips.patch under ndk/build/tools/toolchain-patches/gcc after git clone https://android.googlesource.com/platform/ndk; (Or, https://android-review.googlesource.com/#/c/34000/2/build/tools/toolchain-patches/gcc/0007-gcc-mips.patch) It basically sets the MIPS target to little-endian MIPS32 for mips-linux-android. Also, it changes the GCC driver for MIPS Android. For MIPS Android unwinding supports, we add __BIONIC__ check to compile unwind-dw2-fde-glibc.c. We will be glad to help to merge code to GCC mainline. Thanks! Regards, Chao-ying
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Stefano Lattarini stefano.lattar...@gmail.com writes: Anyway the real use in the src tree is different, IIUC. Info files are built in the build tree by developers, but put in the source tree for distribution. In such a setup, what is the issue with having the '.info' files built in the srcdir? It's not like the developers will develop with a read-only source tree, right? There are many different people who build gcc from snapshots, not releases, for various different reasons. It would be good if those people could continue to build from a read-only source directory. It would be good if those people could get .info files appropriate to their source code. Of course releases should continue to contain .info files. We do not want .info files to be part of source code control for development, but we do want them to be part of source code control for releases. That means that there is no correct setting for svn:ignore or whatever. This can be worked around, it's just a minor pain. Ian
Re: [GCC Steering Committee] Android sub-port reviewer
On Mon, Apr 2, 2012 at 1:55 PM, Fu, Chao-Ying f...@mips.com wrote: It basically sets the MIPS target to little-endian MIPS32 for mips-linux-android. That seems broken because mips-*-* is big-endian and mipsel-*-* is little-endian. Is any way of fixing that before even trying to submitting the patch? Because it will be the only port for mips which is the opposite endian which makes it out of place. Thanks, Andrew Pinski
[Bug c++/52830] New: ICE: canonical types differ for identity types ... when attempting SFINAE with member type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Bug #: 52830 Summary: ICE: canonical types differ for identity types ... when attempting SFINAE with member type Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 27061 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27061 Testcase Using $ gcc-snapshot --version gcc-snapshot (Debian 20120313-1) 4.8.0 20120313 (experimental) [trunk revision 185345] I get the following when attempting to compile what I believe to be a correct testcase program (although I could be wrong on correctness): main.cpp:25:21: internal compiler error: canonical types differ for identical types std::enable_ifstd::is_sametypename fooT::type, U::value, int and std::enable_ifstd::is_sameT, U::value, int The program compiles and behaves as expected if T is used instead of type/typename fooT::type in both declaration and definition, or if bar is defined inline.
[Bug c/52825] incorrect message for incompatible pointer type with extra struct for a typedeffed struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52825
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-04-02
07:09:49 UTC ---
Also happens with gcc 4.6, 4.5, and 4.4. gcc 4.3 and older just print passing
argument 1 of 'f' from incompatible pointer type without trying to show the
corresponding types.
The problem is that gcc incorrectly refers to the type foo from 'typedef struct
{...} foo;' (note: no struct tag) as 'struct foo' in the diagnostic.
[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52789 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-04-02 07:40:32 UTC --- This may have been fixed with the fix for PR 48847. Can you maybe check on trunk/4.7.0 ?
[Bug c++/9050] [DR 147] Can't explicitly specialize C++ constructor templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050 --- Comment #16 from Johannes Schaub schaub.johannes at googlemail dot com 2012-04-02 07:43:23 UTC --- (In reply to comment #15) (In reply to comment #14) Good point, I've pointed out the problem with the proposed resolution. Note that we currently have http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#581 open. Even when 12.1 would have allowed both the injected class name and it followed by template-arguments, the name lookup rules would never allow it to match the second condition because the injected class name would always have been translated to a name denoting the constructor instead of the class. So ultimately, 12.1 allowing the injected class name followed by template arguments could only be used in an unqualified-id constructor declaration in C++03.
[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52789 --- Comment #4 from Mat Cross mathewc at nag dot co.uk 2012-04-02 08:03:22 UTC --- (In reply to comment #3) Can you maybe check on trunk/4.7.0 ? I've just tried with $ gfortran --version GNU Fortran (GCC) 4.7.1 20120331 (prerelease) $ gfortran -c -Wunused-parameter unused.f90 unused.f90:2.23: integer, parameter :: i = 0 1 Warning: Unused parameter 'i' declared at (1) unused.f90:1:0: warning: unused parameter ‘x’ [-Wunused-parameter] and $ gfortran --version GNU Fortran (GCC) 4.8.0 20120330 (experimental) [trunk revision 185988] $ gfortran -c -Wunused-parameter unused.f90 unused.f90:2.23: integer, parameter :: i = 0 1 Warning: Unused parameter 'i' declared at (1) unused.f90:1:0: warning: unused parameter ‘x’ [-Wunused-parameter]
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #31 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02 08:16:52 UTC --- (In reply to comment #30) (In reply to comment #26) The caret is not a solution to this problem, because what Gabriel wants is to not reconstruct expressions ONLY when the caret is shown, but he has said in the past that the caret should default to OFF to not change the current output for IDEs and other software parsing the output of gcc like emacs, so we are back to printing the monsters mentioned above by default. I think I've said before that caret should default to on when the output is a terminal. Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? Is there a GCC way to detect that the output is a terminal?
[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40942 --- Comment #9 from Dodji Seketeli dodji at gcc dot gnu.org 2012-04-02 08:51:30 UTC --- Author: dodji Date: Mon Apr 2 08:51:26 2012 New Revision: 186067 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186067 Log: PR c++/40942 - Failure of template specialization partial ordering gcc/cp/ * pt.c (more_specialized_fn): Don't apply decay conversion to types of function parameters. gcc/testsuite/ * g++.old-deja/g++.pt/spec40.C: Adjust to take the resolution of DR 214 in account. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.pt/spec40.C
[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40942 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Dodji Seketeli dodji at gcc dot gnu.org 2012-04-02 08:56:24 UTC --- Fixed in 4.8 (trunk).
[Bug middle-end/52821] [4.8 Regression] 191.fma3d in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52821 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-02 09:10:16 UTC --- Ah great, thanks. For the FSF branches, I would say, let's just condition the assignment on 4.6 (+ testcase) and have the complete fix/improvement for 4.7/4.8. Can you send the patch to the mailing lists too? Minor nit: first blush, doesn't seem completely obvious to me what a 'true' predicate is - and normally we just have a test for each overload, eg, with/without predicate. Thus I would recommend extending a bit the comment in the testcase, even better also have a separate testcase (named as the PR #) for the specific case in the PR and also extend at will the existing test(s).
[Bug c++/52814] Internal compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52814 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 Known to fail||4.6.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:12:27 UTC --- Fixed in 4.6.1.
[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52808 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:13:44 UTC --- Mine.
[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52805 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:14:35 UTC --- I also see the issue, all runtime tests fail with OOM.
[Bug c/52802] Equality rewrites pessimizes code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52802 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-02 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:16:20 UTC --- How would you do with a single compare?!
[Bug middle-end/52793] [4.8 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52793 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug rtl-optimization/52803] [4.8 Regression] ICE: in ira, at ira.c:3616 with -fno-move-loop-invariants on almost any code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52803 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:15:50 UTC --- Might be caused by my changes. Looking into it.
[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52789 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-02 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 09:38:34 UTC --- Confirmed. * * * We have for GCC in general: Language Independent Options Warning Options -Wunused-parameter Warn whenever a function parameter is unused aside from its declaration. (It is automatically enabled with -Wunused or -Wall.) And gfortran specific: -Wunused-dummy-argument Warn about unused dummy arguments. This option is implied by -Wall. -Wunused-parameter Contrary to gcc's meaning of -Wunused-parameter, gfortran's implementation of this option does not warn about unused dummy arguments (see -Wunused-dummy-argument), but about unused PARAMETER values. -Wunused-parameter is not included in -Wall but is implied by -Wall -Wextra. * * * TODO: * -Wunused does not imply any of the Fortran -Wunused-* warnings. But it should! Interestingly, is does not even seem to enable the middle end warnings. * If only -Wunused-parameter is used - but no flag which implies -Wunused-dummy-argument, the parameter has to be eliminated for the middle-end handling. Thus, we need a gfc_option.* for it - and ensure that warn_unused_parameter has the proper value (e.g. 0 if only -Wunused-parameter is used.)
[Bug middle-end/52831] New: extract_bit_field_1: issue when str_rtx unsafe from target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52831 Bug #: 52831 Summary: extract_bit_field_1: issue when str_rtx unsafe from target Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: aurelien.buhrig@gmail.com This bug makes gcc.c-torture/execute/20040625-1.c fail on my private target port with gcc 4.6.3. Note that it also occurs on trunk during expand, but it seems to be masked by next passes. The issue occurs when: - str_rtx (op0) is not safe from target - when bitsize BITS_PER_WORD Example: WORD_MODE = HImode Pmode == ptr_mode == PSImode extract_bit_field_1 (str_rtx=0x2c15be28, bitsize=32, bitnum=0, unsignedp=1, packedp=1 '\001', target=0x2c16c880, mode=PSImode, tmode=PSImode, fallback_p=1 '\001') (gdb) call debug_rtx (str_rtx) (mem:BLK (reg/v/f:PSI 22 [ s ]) [2 *s_3(D)+0 S4 A8]) (gdb) call debug_rtx (target) (reg/v/f:PSI 22 [ s ]) Here is the expand log from trunk (see insns 19 and 20): ; s_4 = s_3(D)-next; (insn 10 9 11 (clobber (reg/v/f:PSI 22 [ s ])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 11 10 12 (set (reg:QI 25) (mem:QI (plus:PSI (reg/v/f:PSI 22 [ s ]) (const_int 2 [0x2])) [0+2 S1 A8])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 12 11 13 (set (reg:HI 24) (zero_extend:HI (reg:QI 25))) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 13 12 14 (set (reg:HI 26) (reg:HI 24)) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 14 13 15 (set (reg:HI 26) (unspec:HI [ (reg:HI 26) ] 11)) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 15 14 16 (set (strict_low_part (subreg:QI (reg:HI 26) 1)) (const_int 0 [0])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 16 15 17 (set (reg:QI 28) (mem:QI (plus:PSI (reg/v/f:PSI 22 [ s ]) (const_int 3 [0x3])) [0+3 S1 A8])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 17 16 18 (set (reg:HI 27) (zero_extend:HI (reg:QI 28))) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 18 17 19 (set (reg:HI 29) (ior:HI (reg:HI 27) (reg:HI 26))) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 19 18 20 (set (subreg:HI (reg/v/f:PSI 22 [ s ]) 2) (reg:HI 29)) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 20 19 21 (set (reg:QI 31) (mem:QI (reg/v/f:PSI 22 [ s ]) [0+0 S1 A8])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 21 20 22 (set (reg:HI 30) (zero_extend:HI (reg:QI 31))) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 22 21 23 (set (reg:HI 32) (reg:HI 30)) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) The provided patch solves the issue by using an intermediate reg, when needed, before extracting in word mode.
[Bug middle-end/52831] extract_bit_field_1: issue when str_rtx unsafe from target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52831 --- Comment #1 from Aurelien Buhrig aurelien.buhrig.gcc at gmail dot com 2012-04-02 09:42:28 UTC --- Created attachment 27062 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27062 Fix
[Bug c/52802] Equality rewrites pessimizes code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52802 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-04-02 09:43:03 UTC --- On x86, mov and jcc don't clobber the flags, so the first cmpl should compare with 8 not 7, the jbe should be adjusted to jb, and then the second cmpl is redundant as the flags from the first cmpl are still available.
[Bug fortran/52729] Symbol has no implicit type in SELECT TYPE block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52729 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-02 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 09:54:32 UTC --- That's an odd issue. The problem only occurs if one has a BLOCK (or the SELECT TYPE or ASSOCIATE constructs which use it internally). At the same time, one needs to have the function on the LHS of both a procedure call and a proc-pointer assignment. I think that one somewhere only looks as the namespace and its parent (ns-parent) instead of walking higher up. Reduced example: module testMod implicit none contains subroutine testSub() procedure(double precision ), pointer :: r double precision :: testVal block testVal=testFunc() r = testFunc end block end subroutine testSub double precision function testFunc() end function testFunc end module testMod
[Bug fortran/52832] New: ASSOCIATE construct with proc-pointer selector is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832 Bug #: 52832 Summary: ASSOCIATE construct with proc-pointer selector is rejected Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Encountered when looking at PR 52729. I have not checked whether the following program is valid, but my feeling is that it is. Currently, gfortran rejects it with: associate (k=r) 1 Error: Expected association at (1) subroutine testSub() procedure(real), pointer :: r associate (k=r) end associate end subroutine testSub
[Bug c++/52833] New: -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833
Bug #: 52833
Summary: -O2 optimizes loop to infinite when loop invariant
based on arithmetic overflow
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gwpub...@wp.pl
Created attachment 27063
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27063
This loop compiles to endless when O2 in gcc 4.6.1
Hello,
following code is based on artihmetic overflow assumption (after overflow we
gen 0 number on x86 and x86_64):
$cat overflow_loop.cpp
int main(){
int s=1, i=0;
while (s0) {
++i;
s=2*s;
}
return i;
}
While it compiles fine when -O1 and -O2 , on -O3 compiles to infinite loop.
Let's generate assembly codes:
$ g++ -O1 -S -o overflow_loop-O1.s overflow_loop.cpp
$ g++ -O2 -S -o overflow_loop-O2.s overflow_loop.cpp
There is following difference between loops:
overflow_loop-O1.s
(...)
.L2:
addl$1, %eax
cmpl$31, %eax
jne.L2
(...)
overflow_loop-O2.s
(...)
.L2:
jmp.L2
(...)
Let's check what flags are enabled for O1 and O2
$ echo '$ gcc -c -Q -O2 --help=optimizers | grep enabled | sort '
optim_O2.txt
$ gcc -c -Q -O2 --help=optimizers | grep enabled | sort optim_O2.txt
$ echo '$ gcc -c -Q -O1 --help=optimizers | grep enabled | sort '
optim_O1.txt
$ gcc -c -Q -O1 --help=optimizers | grep enabled | sort optim_O1.txt
Here is the difference:
$ diff optim_O{1,2}.txt
1c1,5
$ gcc -c -Q -O1 --help=optimizers | grep enabled | sort
---
$ gcc -c -Q -O2 --help=optimizers | grep enabled | sort
-falign-functions [enabled]
-falign-jumps [enabled]
-falign-labels [enabled]
-falign-loops [enabled]
3a8
-fcaller-saves [enabled]
7a13,14
-fcrossjumping [enabled]
-fcse-follow-jumps [enabled]
10a18
-fdevirtualize [enabled]
12a21
-fexpensive-optimizations [enabled]
13a23
-fgcse [enabled]
18a29,30
-finline-small-functions[enabled]
-fipa-cp[enabled]
21a34
-fipa-sra [enabled]
27a41,43
-foptimize-register-move[enabled]
-foptimize-sibling-calls[enabled]
-fpeephole2 [enabled]
29a46
-fregmove [enabled]
30a48,50
-freorder-blocks[enabled]
-freorder-functions [enabled]
-frerun-cse-after-loop [enabled]
40a61
-fschedule-insns2 [enabled]
44a66,67
-fstrict-aliasing [enabled]
-fthread-jumps [enabled]
47a71
-ftree-builtin-call-dce [enabled]
62a87
-ftree-pre [enabled]
68a94
-ftree-switch-conversion[enabled]
70a97
-ftree-vrp [enabled]
Finally, detailed compiler version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.6-20110819/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object
--enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto
--enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--disable-multilib --disable-libssp --disable-libstdcxx-pch
--enable-checking=release
Thread model: posix
gcc version 4.6.1 20110819 (prerelease) (GCC)
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #1 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:09:15 UTC --- Created attachment 27064 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27064 overflow_loop-O1.s - Assembly after -O1
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #2 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:09:48 UTC --- Created attachment 27065 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27065 overflow_loop-O2.s - assembly after -O2
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #3 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:11:02 UTC --- Created attachment 27066 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27066 compiler flags enabled by -O1
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #4 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:11:32 UTC --- Created attachment 27067 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27067 compiler flags enabled by -O2
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-02 10:12:34 UTC --- (In reply to comment #0) following code is based on artihmetic overflow assumption (after overflow we gen 0 number on x86 and x86_64): Bad assumption, overflow is undefined behaviour. The bug submission form asys to read http://gcc.gnu.org/bugs/ before reporting bugs, which says if your code works as you expect with -fwrapv then it's not a bug in the compiler, it's a bug in your code.
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 Grzegorz Wierzowiecki gwpublic at wp dot pl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:16:31 UTC --- Thanks for confirmation, I wanted to ensure it works as expected.
[Bug target/52802] Equality rewrites pessimizes code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52802 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|WAITING |NEW Component|c |target --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 10:28:58 UTC --- Confirmed. On the tree level we canonicalize things which is good, if you change the source to what the canonicalization looks like you get the same problem. Target issue.
[Bug fortran/52832] ASSOCIATE construct with proc-pointer selector is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 10:30:43 UTC --- From Fortran 2008: R804 association is associate-name = selector R805 selector is expr or variable R602 variable is designator or expr R601 designator is object-name and expr boils down to: R701 primary is constant or designator ! See above or ... Thus, it boils down to the question whether that's fulfilled for a procedure pointer. Note that there such entries, which make me inclined that it is not valid: R554 saved-entity is object-name or proc-pointer-name R639 pointer-object is variable-name [or ...] or proc-pointer-name Possible usage of proc-pointer selectors: associate(f = very%long%name%procptr) f = something ! usage as variable a = f(4) + f(7) * f(x) + ... ! usage as expr where the latter is more useful. A quick test shows that ifort, pgf95 and crayftn accept proc-pointers in ASSOCIATE.
[Bug middle-end/52800] [4.8 Regression] eglibc build broken with internal compiler error in cfgloop .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Summary|eglibc build broken with|[4.8 Regression] eglibc |internal compiler error in |build broken with internal |cfgloop . |compiler error in cfgloop . Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 10:34:03 UTC --- Fixed by Index: gcc/cprop.c === --- gcc/cprop.c (revision 186066) +++ gcc/cprop.c (working copy) @@ -1916,7 +1916,7 @@ execute_rtl_cprop (void) changed = one_cprop_pass (); flag_rerun_cse_after_global_opts |= changed; if (changed) -cleanup_cfg (0); +cleanup_cfg (CLEANUP_CFG_CHANGED); return 0; }
[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52808 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||52756 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 10:39:39 UTC --- The fix for this depends on fixing PR52756. The issue here is -ftracer.
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52756
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02
11:38:59 UTC ---
It doesn't work, as we expect loop_latch_edge () to work during further
threading.
It also does not work because we miss some threadings and thus hit the assert
that e-aux is NULL after threading is done.
The issue is that we thread both the latch and the loop entry edge. But the
code special casing each case does not consider that both may happen at
the same time. If we'd re-start at thread_through_loop_header for the case
in this bug we'd fail, as the entry edges THREAD_TARGET2 is set.
Thus, I'll try again with
Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 186066)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -838,6 +838,7 @@ thread_through_loop_header (struct loop
edge_iterator ei;
basic_block tgt_bb, atgt_bb;
enum bb_dom_status domst;
+ bool threaded_latch = false;
/* We have already threaded through headers to exits, so all the threading
requests now are to the inside of the loop. We need to avoid creating
@@ -908,6 +909,7 @@ thread_through_loop_header (struct loop
if (single_succ_p (header))
goto fail;
+thread_rest:
if (latch-aux)
{
if (THREAD_TARGET2 (latch))
@@ -916,7 +918,7 @@ thread_through_loop_header (struct loop
tgt_bb = tgt_edge-dest;
}
else if (!may_peel_loop_headers
- !redirection_block_p (loop-header))
+ !redirection_block_p (header))
goto fail;
else
{
@@ -950,7 +952,7 @@ thread_through_loop_header (struct loop
if (!tgt_bb)
{
/* There are no threading requests. */
- return false;
+ return threaded_latch;
}
/* Redirecting to empty loop latch is useless. */
@@ -971,7 +973,7 @@ thread_through_loop_header (struct loop
loop-header = NULL;
loop-latch = NULL;
loops_state_set (LOOPS_NEED_FIXUP);
- return thread_block (header, false);
+ return threaded_latch | thread_block (header, false);
}
if (tgt_bb-loop_father-header == tgt_bb)
@@ -994,9 +996,10 @@ thread_through_loop_header (struct loop
loop-latch = thread_single_edge (latch);
gcc_assert (single_succ (loop-latch) == tgt_bb);
loop-header = tgt_bb;
+ threaded_latch = true;
/* Thread the remaining edges through the former header. */
- thread_block (header, false);
+ goto thread_rest;
}
else
{
@@ -1039,7 +1042,7 @@ fail:
free (e-aux);
e-aux = NULL;
}
- return false;
+ return threaded_latch;
}
/* Walk through the registered jump threads and convert them into a
[Bug rtl-optimization/52803] [4.8 Regression] ICE: in ira, at ira.c:3616 with -fno-move-loop-invariants on almost any code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52803 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 11:59:51 UTC --- Author: rguenth Date: Mon Apr 2 11:59:47 2012 New Revision: 186080 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186080 Log: 2012-04-02 Richard Guenther rguent...@suse.de PR middle-end/52803 * loop-init.c (gate_handle_loop2): Destroy loops here if we don't enter RTL loop optimizers. * gcc.dg/pr52803.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr52803.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-init.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52800] [4.8 Regression] eglibc build broken with internal compiler error in cfgloop .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 12:00:39 UTC --- Fixed.
[Bug rtl-optimization/52803] [4.8 Regression] ICE: in ira, at ira.c:3616 with -fno-move-loop-invariants on almost any code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52803 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 2012-04-02 11:59:59 UTC --- Fixed.
[Bug middle-end/52800] [4.8 Regression] eglibc build broken with internal compiler error in cfgloop .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 12:00:34 UTC --- Author: rguenth Date: Mon Apr 2 12:00:30 2012 New Revision: 186081 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186081 Log: 2012-04-02 Richard Guenther rguent...@suse.de PR rtl-optimization/52800 * cprop.c (execute_rtl_cprop): Call cleanup_cfg with CLEANUP_CFG_CHANGED. Modified: trunk/gcc/ChangeLog trunk/gcc/cprop.c
[Bug regression/52834] New: [4.7 Regression] ICE (segfault) in check_tag_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52834 Bug #: 52834 Summary: [4.7 Regression] ICE (segfault) in check_tag_decl Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 27068 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27068 preprocessed source seen with the 4.7.0 release (x86_64-linux-gnu), works with 4.6.3 $ g++ -c -g ProcessDies.ii In file included from /usr/include/libsysactivity/global.h:56:0, from /usr/include/libsysactivity/libsysactivity.h:122, from /home/packages/tmp/sentinella-0.9.0/src/Conditions/ProcessDies.h:24, from /home/packages/tmp/sentinella-0.9.0/src/Conditions/ProcessDies.cpp:21: /usr/include/libsysactivity/process.h:40:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Program received signal SIGSEGV, Segmentation fault. 0x004fed50 in check_tag_decl(cp_decl_specifier_seq*) () (gdb) bt #0 0x004fed50 in check_tag_decl(cp_decl_specifier_seq*) () #1 0x0050f0e6 in shadow_tag(cp_decl_specifier_seq*) () #2 0x0056bfdd in ?? () #3 0x00571238 in ?? () #4 0x0057547c in ?? () #5 0x00574118 in ?? () #6 0x00574458 in ?? () #7 0x005754f8 in ?? () #8 0x00574118 in ?? () #9 0x005759e3 in c_parse_file() () #10 0x00605c05 in c_common_parse_file() () #11 0x0086fae0 in toplev_main(int, char**) () #12 0x75ddcead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #13 0x004e8181 in _start ()
[Bug regression/52834] [4.7 Regression] ICE (segfault) in check_tag_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52834
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-04-02 13:47:30 UTC ---
Testcase:
__attribute__ ((visibility(default))) enum foo{
bar = 0 };
% gcc -c test.ii
test.ii:2:11: internal compiler error: Segmentation fault
Please submit a full bug report,
[Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52756
--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02
14:05:31 UTC ---
With that patch gcc.dg/tree-ssa/ssa-dom-thread-2.c regresses as we do not
perform the threading through the header edge anymore. Note that using
thread_block (header, true); for the rest of the header edges does not
work either, as it still happily creates the multiple entry loop with
the bogus header.
The following is another possibility - remove the remaining threadings
that would be harmful but allow those that would be safe.
Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 186082)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -826,6 +826,17 @@ determine_bb_domination_status (struct l
return (bb_reachable ? DOMST_DOMINATING : DOMST_LOOP_BROKEN);
}
+/* Return true if BB is part of the new pre-header that is created
+ when threading the latch to DATA. */
+
+static bool
+def_split_header_continue_p (const_basic_block bb, const void *data)
+{
+ const_basic_block new_header = (const_basic_block) data;
+ return (bb-loop_father == new_header-loop_father
+ bb != new_header);
+}
+
/* Thread jumps through the header of LOOP. Returns true if cfg changes.
If MAY_PEEL_LOOP_HEADERS is false, we avoid threading from entry edges
to the inside of the loop. */
@@ -990,11 +1001,46 @@ thread_through_loop_header (struct loop
if (latch-aux)
{
+ basic_block *bblocks;
+ unsigned nblocks, i;
+
/* First handle the case latch edge is redirected. */
loop-latch = thread_single_edge (latch);
gcc_assert (single_succ (loop-latch) == tgt_bb);
loop-header = tgt_bb;
+ /* Remove the new pre-header blocks from our loop. */
+ bblocks = XCNEWVEC (basic_block, loop-num_nodes);
+ nblocks = dfs_enumerate_from (header, 0, def_split_header_continue_p,
+ bblocks, loop-num_nodes, tgt_bb);
+ for (i = 0; i nblocks; i++)
+ {
+ remove_bb_from_loops (bblocks[i]);
+ add_bb_to_loop (bblocks[i], loop_outer (loop));
+ }
+ free (bblocks);
+
+ /* Cancel remaining threading requests that would make the
+loop a multiple entry loop. */
+ FOR_EACH_EDGE (e, ei, header-preds)
+ {
+ edge e2;
+ if (e-aux == NULL)
+ continue;
+
+ if (THREAD_TARGET2 (e))
+ e2 = THREAD_TARGET2 (e);
+ else
+ e2 = THREAD_TARGET (e);
+
+ if (e-src-loop_father != e2-dest-loop_father
+ e2-dest != loop-header)
+ {
+ free (e-aux);
+ e-aux = NULL;
+ }
+ }
+
/* Thread the remaining edges through the former header. */
thread_block (header, false);
}
[Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52756 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 15:13:50 UTC --- Author: rguenth Date: Mon Apr 2 15:13:45 2012 New Revision: 186085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186085 Log: 2012-04-02 Richard Guenther rguent...@suse.de PR tree-optimization/52756 * tree-ssa-threadupdate.c (def_split_header_continue_p): New function. (thread_through_loop_header): After threading through the loop latch remove the split part from the loop and clear further threading opportunities that would create a multiple entry loop. * gcc.dg/torture/pr52756.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52756.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug fortran/52835] New: Incorrect code generated by gfortran 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 Bug #: 52835 Summary: Incorrect code generated by gfortran 4.7.0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net uname -sm Linux x86_64 cat qq.f SUBROUTINE QQ2( ISU, ZSPM, RSV, MS ) INTEGER :: ISU(MS) CHARACTER(8) :: ZSPM(MS) REAL :: RSV(MS) DO IS=1,MS ISU(IS)=0 ZSPM(IS)=' ' RSV(IS) =0.0 ENDDO END subroutine qq2 SUBROUTINE QQ() INTEGER, ALLOCATABLE :: ISU(:) CHARACTER(8), ALLOCATABLE :: ZSPM(:) REAL, ALLOCATABLE :: RSV(:) ALLOCATE( RSV(3) ) ALLOCATE( ISU(3) ) ALLOCATE( ZSPM(3) ) CALL QQ2( ISU, ZSPM, RSV, 3 ) write(*,*) '--',zspm(1) END subroutine qq program p1 call qq() end program p1 gfortran470 -O3 -g qq.f -static-libgfortran ; valgrind --track-origins=yes ./a.out ==18017== Memcheck, a memory error detector ==18017== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==18017== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==18017== Command: ./a.out ==18017== ==18017== Syscall param write(buf) points to uninitialised byte(s) ==18017==at 0x3541CC4150: __write_nocancel (in /lib64/libc-2.5.so) ==18017==by 0x40981C: raw_write (unix.c:308) ==18017==by 0x40F4FE: _gfortrani_fbuf_flush (unix.h:56) ==18017==by 0x405416: _gfortrani_next_record (transfer.c:3397) ==18017==by 0x405CF8: _gfortran_st_write_done (transfer.c:3592) ==18017==by 0x401C5B: qq_ (qq.f:22) ==18017==by 0x401CFC: main (qq.f:26) ==18017== Address 0x4c2fb44 is 4 bytes inside a block of size 512 alloc'd ==18017==at 0x4A0776F: malloc (vg_replace_malloc.c:263) ==18017==by 0x4037B8: _gfortrani_get_mem (memory.c:43) ==18017==by 0x40F38A: _gfortrani_fbuf_init (fbuf.c:43) ==18017==by 0x408F89: _gfortrani_init_units (unit.c:585) ==18017==by 0x403747: init (main.c:226) ==18017==by 0x4196F5: ??? (in /tmp/arnaud/a.out) ==18017==by 0x401612: ??? (in /tmp/arnaud/a.out) ==18017==by 0x9CA212C: ??? ==18017==by 0x419676: __libc_csu_init (in /tmp/arnaud/a.out) ==18017==by 0x3541C1D84D: (below main) (in /lib64/libc-2.5.so) ==18017== Uninitialised value was created by a heap allocation ==18017==at 0x4A0776F: malloc (vg_replace_malloc.c:263) ==18017==by 0x401BE0: qq_ (qq.f:20) ==18017==by 0x401CFC: main (qq.f:26) ==18017== -- ==18017== ==18017== HEAP SUMMARY: ==18017== in use at exit: 0 bytes in 0 blocks ==18017== total heap usage: 20 allocs, 20 frees, 3,878 bytes allocated ==18017== ==18017== All heap blocks were freed -- no leaks are possible ==18017== ==18017== For counts of detected and suppressed errors, rerun with: -v ==18017== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) The test case above demonstrates the problem observed on a large production system. In qq2, zspm is not set properly to as shown by valgrind. This is taking place only when compiled with -O3. This is a regression with respect to gfortran 4.6.2.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #32 from Jason Merrill jason at gcc dot gnu.org 2012-04-02 15:57:16 UTC --- (In reply to comment #31) Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? No, there should be no need to. Is there a GCC way to detect that the output is a terminal? I don't know if there's a usual GCC way, but isatty seems like a good way.
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-04-02 Component|fortran |middle-end CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Incorrect code generated by |[4.7/4.8 Regression] -O3 |gfortran 4.7.0 |wrongly optimizes loop ||__builtin_memcpy away Target Milestone|--- |4.7.1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 16:11:37 UTC --- Confirmed - and smells rather like a middle-end issue. (Or a rather convoluted FE declaration bug.) Works with my 2011-12-24-r182676 build Fails with my 2012-02-28-r184613 build (Note: Those contained some patches, which shouldn't™ affect the result.) * * * Works with: gfortran -fdump-tree-optimized -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize -finline-functions -fipa-cp-clone -O2 (And fails with -O3 and the -fno-* version of those flags.) Thus, none of the specific flags which get enabled with -O3 seems too blame. * * * Looking at the optimized dump, the loop DO IS=1,MS ISU(IS)=0 ZSPM(IS)=' ' RSV(IS) =0.0 ENDDO gets replaced by: __builtin_memset (D.1976_27, 0, 12); __builtin_memset (D.1956_11, 0, 12); That's almost fine, however, the ZSPM(is) = ' ' is lacking. With -O2 one finds in the loop: __builtin_memcpy (D.2078_113, [0], 8); Note that ZSPM is an array of size 3 of character strings of length 8: character(len=8) :: ZSPM(MS) where MS is 3. The best (optimized) version would be something like memset(ZSPM, , 3*8);. In 4.6, one had (with -O3) and expanded loop with the following for [0], [1] and [2]: D.1697_89 = MEM[(character(kind=1)[0:D.1598][1:8] *)D.1577_23][0]; __builtin_memcpy (D.1697_89, [0], 8);
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-04-02 16:18:47 UTC --- r183622 is OK r183649 miscompiles the code.
[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52805 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 2012-04-02 16:29:25 UTC --- Rainer's commit (http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00031.html) fixes this for i686-darwin9.
[Bug fortran/52774] Derived-type assignment: check required to prevent double deallocation of allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52774 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-04-02 CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever Confirmed|0 |1 Summary|A check is needed to|Derived-type assignment: |prevent deallocation in |check required to prevent |realloc-lhs |double deallocation of ||allocatable component Known to fail||4.3.4, 4.7.1, 4.8.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 16:36:17 UTC --- Confirmed. Remarks: a) The reduced program in comment 0 is invalid: As p1%p is not allocated, accessing it with print *, p1%p is invalid - and is likely to segfault. Solution: Use print *, allocated (p1%p) which shall print F; that still gives the expected segfault or invalid free() errors from valgrind with current gfortran - as expected. b) The issue is unrelated to realloc on assignment and seems to be related to allocatable components (TR 15581, a GCC 4.2 feature). At least the program in comment 0 [modified as in comment (a)] also fails with GCC 4.3, using -fno-realloc-lhs does not help, and valgrind shows the same failure.
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #7 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-02 16:41:41 UTC --- Sounds good. Will send the patches to the list, probably tomorrow. Thanks!
[Bug regression/52834] [4.7 Regression] ICE (segfault) in check_tag_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52834 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-02 16:45:42 UTC --- Dup of PR52671 ?
[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52805 --- Comment #6 from Iain Sandoe iains at gcc dot gnu.org 2012-04-02 17:13:14 UTC --- (In reply to comment #2) e.g. AFAICT, although darwin defines JCR_SECTION_NAME, there is no crt machinery to deal with it [darwin has it's own crt code] JFTR (in case anyone else has gone looking for it), there's no entry in the Darwin system-provided crts for this, and we don't supply an FSF one for it either - instead, it appears that the class init code is provided in libgcj.dylib (from libjava/darwin.cc).
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #33 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02 17:15:47 UTC --- (In reply to comment #32) (In reply to comment #31) Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? No, there should be no need to. As a first minimal step, would a first patch be enough that simply: * Adds an option to disable/enable the caret? By default on if(isatty), otherwise off. * Implements the caret by reopening the file, looks for the appropriate line, and prints this line, then prints a '^' below it using the column info. Of course this may fail in some cases, like non-ANSI input, and not preprocessing, but it will work in 99% of the cases. In any case, it is not clear to me that we want to print the preprocessed line instead of the original text.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #34 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02 17:18:34 UTC --- (In reply to comment #32) Of course this may fail in some cases, like non-ANSI input, and not preprocessing, but it will work in 99% of the cases. In any case, it is not clear to me that we want to print the preprocessed line instead of the original text. BTW, non-ANSI input may not even handled correctly by libcpp according to PR49152, so I think we don't need to worry about it just now.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #35 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02 17:19:15 UTC --- (In reply to comment #34) (In reply to comment #32) Of course this may fail in some cases, like non-ANSI input, and not preprocessing, but it will work in 99% of the cases. In any case, it is not clear to me that we want to print the preprocessed line instead of the original text. BTW, non-ANSI input may not even handled correctly by libcpp according to PR49152, so I think we don't need to worry about it just now. Sorry, I meant PR49973 .
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #36 from pinskia at gmail dot com pinskia at gmail dot com 2012-04-02 17:35:59 UTC --- I know some of us use tee and that disables termainal detection code usually. Or output to a file and then use tail -f. So please don't do that. It would confuse lots of users. Sent from my Palm Pre on ATamp;T On Apr 2, 2012 4:17, manu at gcc dot gnu.org lt;gcc-bugzi...@gcc.gnu.orggt; wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #31 from Manuel López-Ibáñez lt;manu at gcc dot gnu.orggt; 2012-04-02 08:16:52 UTC --- (In reply to comment #30) gt; (In reply to comment #26) gt; gt; The caret is not a solution to this problem, because what Gabriel wants is to gt; gt; not reconstruct expressions ONLY when the caret is shown, but he has said in gt; gt; the past that the caret should default to OFF to not change the current output gt; gt; for IDEs and other software parsing the output of gcc like emacs, so we are gt; gt; back to printing the monsters mentioned above by default. gt; gt; I think I've said before that caret should default to on when the output is a gt; terminal. gt; Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? Is there a GCC way to detect that the output is a terminal?
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 --- Comment #3 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-04-02 17:54:06 UTC --- Additionally: cat xxx.f SUBROUTINE XXX(RES,ALP,REN,NN ) DIMENSION ALP(NN),REN (NN),RES (NN) DO IP = 1,NN REN(IP) = 0.0 ALP(IP) = 0.0 CALL YYY(ALP(IP),REN(IP),RES(IP)) ENDDO END gfortran470 -c -O3 -o xxx_O3.o xxx.f ; gfortran470 -c -O2 -o xxx_O2.o xxx.f ; nm xxx*.o xxx_O2.o: T xxx_ U yyy_ xxx_O3.o: U memset T xxx_ When compiled with -O3, the call to YYY is not generated. This is a pretty serious wrong code generation.
[Bug regression/52834] [4.7 Regression] ICE (segfault) in check_tag_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52834 --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-04-02 18:31:21 UTC --- (In reply to comment #2) Dup of PR52671 ? Yes. Gcc-4.8 from today is fine. Gcc-4.7 release fails. Haven't tried the gcc-4.7 branch, but it seems obvious.
[Bug libffi/52497] libffi doesn't build on powerpc64-linux after latest upstream merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52497 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-02 AssignedTo|unassigned at gcc dot |bergner at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug libffi/52497] libffi doesn't build on powerpc64-linux after latest upstream merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52497 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Peter Bergner bergner at gcc dot gnu.org 2012-04-02 18:50:22 UTC --- Patch committed to gcc sources as revision 186091. AG will merge these changes back to upstream libffi.
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-02 19:18:22 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=183624 and it is ldist that incorrectly removes the call.
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-02 19:38:31 UTC --- Created attachment 27069 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27069 gcc48-pr52835.patch Untested fix. Ignoring failures from compute_*loop can't be right.
[Bug fortran/52724] Internal read with character(kind=4) data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52724 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-02 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 20:01:08 UTC --- (In reply to comment #2) I am curious about what this line is doing: character buffer4(100) buffer4 = 4_'123' Well, that line does what it should do: It assign the value '123' - trimmed to one character (namely '1') to the array buffer4. The array4 then contains 100 times the value '1'. (In reply to comment #0) read(buffer4,*) i print *,i end ig25@linux-fd1f:~/Krempel/Opt gfortran foo.f90 ig25@linux-fd1f:~/Krempel/Opt ./a.out 1 And seemingly that's also what Thomas gets. * * * (In reply to comment #2) buffer4 is a kind=1 variable. have you tried: character(kind=4) buffer4(100) ? Well, with len=1,kind=4 or with len=2,kind=2 one gets, respectively, 1 and 12 - which is the expected result. However, the following fails: character(len=2,kind=4) buffer4(100) integer i buffer4 = 4_'123' read(buffer4,*) i print *,i end Fortran runtime error: Bad integer for item 1 in list input Printing the value of the array as print *, buffer4, one gets the expected 121212 as output. And reading the line as read(buffer4,'(i5)') i works and yields 12. Only when replacing the formatted read by a list-directed read, it fails.
[Bug target/52836] New: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52836 Bug #: 52836 Summary: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mead...@codesourcery.com Target: arm From r185746 trunk: $ ./install/bin/arm-none-linux-gnueabi-gcc -O2 -funroll-loops -march=armv7-a arm-minipool-ice.c /home/meadori/etc/bugs/arm-minipool-ice.c: In function 'Super_Mix': /home/meadori/etc/bugs/arm-minipool-ice.c:144:3: warning: incompatible implicit declaration of built-in function 'memset' [enabled by default] /home/meadori/etc/bugs/arm-minipool-ice.c: In function 'Next_Fugue': /home/meadori/etc/bugs/arm-minipool-ice.c:175:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/52836] internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52836 --- Comment #1 from Meador Inge meadori at codesourcery dot com 2012-04-02 20:54:30 UTC --- Created attachment 27070 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27070 Reproduction case
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #37 from Jason Merrill jason at gcc dot gnu.org 2012-04-02 22:05:13 UTC --- (In reply to comment #36) I know some of us use tee and that disables termainal detection code usually. Right, so then you don't get the caret by default. You can still enable it with a flag if you want. Actually, it's not clear to me that the caret line would be likely to cause trouble for IDEs in any case; they already have to deal with output that isn't a specific error. Maybe we should just turn it on by default in all cases, and possibly backtrack to only on a tty if it causes problems.
[Bug c++/52837] New: ICE in cp/mangle.c:3306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837 Bug #: 52837 Summary: ICE in cp/mangle.c:3306 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@godbolt.org GCC version: 4.7.0 (custom build) System type: Ubuntu 11.10 3.0.0-16-generic $ /site/apps/gcc-4.7.0-drw.2/bin/gcc -v Using built-in specs. COLLECT_GCC=/site/apps/gcc-4.7.0-drw.2/bin/gcc COLLECT_LTO_WRAPPER=/site/apps/gcc-4.7.0-drw.2/libexec/gcc/x86_64-linux-gnu/4.7.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ./configure --prefix /site/apps/gcc-4.7.0-drw.2 --build=x86_64-linux-gnu --enable-clocale=gnu --enable-gold --enable-languages=c,c++ --enable-ld=default --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugin --enable-shared --enable-threads=posix --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-pkgversion=DRW-internal-build --with-plugin-ld=ld.gold --with-system-zlib --with-gmp=/home/prodappadmin/fig-packages/scratch/gcc/4.7.0/build/gmp-5.0.2 --with-mpfr=/home/prodappadmin/fig-packages/scratch/gcc/4.7.0/build/mpfr-3.1.0 --with-mpc=/home/prodappadmin/fig-packages/scratch/gcc/4.7.0/build/mpc-0.9 --with-libelf=/home/prodappadmin/fig-packages/scratch/gcc/4.7.0/build/libelf-0.8.9 Thread model: posix gcc version 4.7.0 (DRW-internal-build) command-line: /site/apps/gcc-4.7.0-drw.2/bin/gcc -MD -g3 -Wall -fPIC -DXP_UNIX -DIN_GCC -DPLUGIN_NO_POISON -DHAVE_CONFIG_H -I/site/apps/gcc-4.7.0-drw.2/lib/gcc/x86_64-linux-gnu/4.7.0/plugin/include -I/home/mgodbolt/build/objs-js/dist/include -I/home/mgodbolt/build/objs-js/dist/lib -I//home/mgodbolt/local/include/js/ -O2 -x c++ -c util.c compiler output: In file included from /home/mgodbolt/build/objs-js/dist/include/jsval.h:48:0, from /home/mgodbolt/build/objs-js/dist/include/jspubtd.h:47, from /home/mgodbolt/build/objs-js/dist/include/jsapi.h:49, from gcc_compat.h:31, from util.c:21: /home/mgodbolt/build/objs-js/dist/include/jsutil.h:642:58: internal compiler error: in mangle_decl_string, at cp/mangle.c:3306 When compiling the attached file we get an ICE in cp/mangle.c line 3306 (commented We shouldn't be trying to mangle an uninstantiated template.). I have been unable to winnow down a more confined example of this error as I am very unfamiliar with the code being built (it's an old version of the mozilla JS runtime). The error can be reproduced with the attached preprocessed file using simply cc1plus util.ii
