Re: GCC and out-of-range constant array indexes?
On 10/07/10 21:24:18, Ian Lance Taylor wrote: -Warray-bounds, but that is one of the warnings which is unfortunately only available when optimizing. In this case it requires -O2. Ian, thanks. I had thought optimization might be involved, but didn't try -O2. There was an attempt a couple of years ago to implement this warning when not optimizing [...]. Would it be possible to compute enough of the control flow graph to process warnings like this one, without running the actual optimizations, unless those optimizations are requested? Would the cost be too high? - Gary
Re: RFE: 'enable checking' as a GCC compilation switch?
On 10/03/10 12:03:44, Ian Lance Taylor wrote: You will need to try a sample implementation and see how much the compiler slows down and how much bigger it gets. I began roughing out the required changes. This will be a background project. If I can finish it to the point of running some timing tests, I will post the results here. thanks, - Gary
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Thu, Sep 23, 2010 at 9:53 AM, NightStrike nightstr...@gmail.com wrote: On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn dave.korn.cyg...@gmail.com wrote: On 21/09/2010 02:51, NightStrike wrote: The toolchain is broken once again here: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../build/mingw/mingw-w64-crt -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD -I/tmp/build/root/x 86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-ali asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noret urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD -MP -MF math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o math/lib32_libmingwex_a-sf_erf.o `test -f 'math/sf_erf.c' || echo '../../../build/mingw/mingw-w64-crt/'`math/sf_ erf.c ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function `__trunc_float_wor d.isra.0': ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler error: tree check: expected var_decl, have debug_expr_decl in const_value_known_p, at varpool.c:375 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738 cheers, DaveK Thanks. Hope it gets fixed fast. I will post a new testsuite once that bug is closed. http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 8 October 2010 16:56, NightStrike wrote: http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html There are a lot of failures there, including quite a few tests which don't look platform-dependent. Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see what's failing? A lot of them look locale-related, so could just be disabled if the platform doesn't support them. Others are more concerning and shouldn't be failing on any platform.
Re: End of GCC 4.6 Stage 1: October 27, 2010
2010/10/8 Jonathan Wakely jwakely@gmail.com: On 8 October 2010 16:56, NightStrike wrote: http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html There are a lot of failures there, including quite a few tests which don't look platform-dependent. Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see what's failing? A lot of them look locale-related, so could just be disabled if the platform doesn't support them. Others are more concerning and shouldn't be failing on any platform. The locale stuff is related to printf-family and 'long double' types. Here is a special handling for printf functions necessary to use here instead the gnu-version of printf-family (_mingw_printf routines) we provide. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination
Re: GCC and out-of-range constant array indexes?
On Fri, 8 Oct 2010 08:14:23 -0700
Gary Funck g...@intrepid.com wrote:
On 10/07/10 21:24:18, Ian Lance Taylor wrote:
-Warray-bounds, but that is one of the warnings which is unfortunately
only available when optimizing. In this case it requires -O2.
Ian, thanks. I had thought optimization might be involved, but didn't try
-O2.
Would it be possible to compute enough of the control flow graph
to process warnings like this one, without running the
actual optimizations, unless those optimizations are requested?
Would the cost be too high?
I am not an expert on these optimizations, but why would you want that?
The optimizations involved are indeed expensive (otherwise it would be
-O1 not -O2), but once you asked for them, why only get warnings
without the code generation improvement? (I am assuming that the
required computations in the compiler are mostly in the middle end, and
that getting such warnings are a side effect).
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 mine, sont seulement les miennes} ***
Re: GCC and out-of-range constant array indexes?
On 10/08/10 18:38:29, Basile Starynkevitch wrote: I am not an expert on these optimizations, but why would you want that? I routinely compile/build with -O0 -g3 because the code is easier to debug. I also admit that I compile/build with -O0 because it is faster than -O2 or -O3 for example, and during development I am more interested in faster turn-around time on builds than faster execution time. Also, when I compile/build projects, I try to use the maximum level of warnings and checking that the source code base will support. I am willing to trade off some support/build time in favor of more thorough warnings. - Gary
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, Oct 8, 2010 at 12:06 PM, Jonathan Wakely jwakely@gmail.com wrote: On 8 October 2010 16:56, NightStrike wrote: http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html There are a lot of failures there, including quite a few tests which don't look platform-dependent. Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see what's failing? A lot of them look locale-related, so could just be disabled if the platform doesn't support them. Others are more concerning and shouldn't be failing on any platform. Sent log offlist
Re: GCC and out-of-range constant array indexes?
Gary Funck g...@intrepid.com writes: There was an attempt a couple of years ago to implement this warning when not optimizing [...]. Would it be possible to compute enough of the control flow graph to process warnings like this one, without running the actual optimizations, unless those optimizations are requested? Would the cost be too high? I think it could be done but I don't think it would be simple. I do think it would be a good idea to make warnings independent of optimization level, except for those warnings like -Wstrict-aliasing which are specifically about optimizations. Ian
Re: GCC and out-of-range constant array indexes?
On Fri, 8 Oct 2010 09:54:07 -0700
Gary Funck g...@intrepid.com wrote:
On 10/08/10 18:38:29, Basile Starynkevitch wrote:
I am not an expert on these optimizations, but why would you want that?
I routinely compile/build with -O0 -g3 because the code is easier to debug.
I
also admit that I compile/build with -O0 because it is faster than
-O2 or -O3 for example, and during development I am more interested
in faster turn-around time on builds than faster execution time.
I understand that. Using -O1 -g3 is a suitable compromise also.
Also, when I compile/build projects, I try to use the maximum level of
warnings
and checking that the source code base will support. I am willing to trade
off some support/build time in favor of more thorough warnings.
You could build both a release version with -O2 or -O2 -g and a
development version with -O0 -g3.
Howeer, I see a logic in needing -O2 to get some warnings.
Optimizations are expensive, and they compute static properties of the
source code, which are usable ( necessary and used) for additional
warnings.
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 mine, sont seulement les miennes} ***
Re: GCC and out-of-range constant array indexes?
Basile Starynkevitch bas...@starynkevitch.net writes: Howeer, I see a logic in needing -O2 to get some warnings. Optimizations are expensive, and they compute static properties of the source code, which are usable ( necessary and used) for additional warnings. The problem that I think we've discovered over the years is that when warnings depend on optimizations, the warnings are unstable. It means that as optimizations change, the warnings appear and disappear. And that means that as people move their code to new compiler releases, they get unpredictable new warnings. That can be OK when the warnings are always true positives. However, it is very problematic when the warnings are sometimes false positives, because it forces people to change their code for no reason, or to disable the warning. It might seem to be something like an out of bounds constant array index can not go wrong, in the sense that it can never give a false positive. However, we have already seen that it can go wrong if the compiler does not reliably ignore code which is not executed. Another reason that it's problematic to have warnings depend on optimization level is that many people develop with -O0, and we want to give them as many true positive warnings at that level as we can. Ian
Re: End of GCC 4.6 Stage 1: October 27, 2010
Most of the failing libstdc++ tests which shouldn't be platform-dependent fail with this message: sh: /usr/bin/stty: Bad address libstdc++-v3/config/os/mingw32/error_constants.h is missing several entries, causing failures in the 19_diagnostics tests. There are a few failures in 23_containers/vector/ext_pointer which might be caused by an inttype definition on the platform, I'm not sure. A bugzilla PR should probably be opened if there isn't one already.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, Oct 8, 2010 at 2:04 PM, Jonathan Wakely jwakely@gmail.com wrote: Most of the failing libstdc++ tests which shouldn't be platform-dependent fail with this message: sh: /usr/bin/stty: Bad address This Bad address stuff is due to some conflict with cygwin. We really need to work with cygwin folks to find a proper fix, but are having difficulty. Dave, can you work with Kai to help troubleshoot that, by any chance?
Re: GCC and out-of-range constant array indexes?
On Fri, 08 Oct 2010 11:03:27 -0700
Ian Lance Taylor i...@google.com wrote:
Basile Starynkevitch bas...@starynkevitch.net writes:
Howeer, I see a logic in needing -O2 to get some warnings.
Optimizations are expensive, and they compute static properties of the
source code, which are usable ( necessary and used) for additional
warnings.
The problem that I think we've discovered over the years is that when
warnings depend on optimizations, the warnings are unstable. It means
that as optimizations change, the warnings appear and disappear. And
that means that as people move their code to new compiler releases, they
get unpredictable new warnings.
Is this unstability of warnings related to the (perhaps stupid)
folklore of avoiding -O3 (what I mean is that, for instance, most Linux
distributions are built with -O2 at most; very few are using -O3; this
brings a chicken egg issue: since -O3 is much less used, it is
probably more buggy less usable!).
But I also noticed (even on the runtime inside the MELT branch of GCC)
that newer GCC releases give better more warnings than older ones.
(BTW, Ian, I am still hoping for your review ok of my gengtype patches!).
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 mine, sont seulement les miennes} ***
Re: GCC and out-of-range constant array indexes?
How about the following: 1) Default warnings are cheap, and work fine at -O0. 2) Expensive warnings (-Wall, -Warray-bounds, -Wuninitialized, -Wunused) [not sure about the actual list] that require optimizations, will issue a Warning when they are requested, but the appropriate optimization level has not been asserted, that is required for those warnings to work in their maximal fashion. Or: Specification of the expensive warnings will cause appropriate control flow computations that are required to support those warning levels. (as suggested previously)
Re: GCC and out-of-range constant array indexes?
Gary Funck g...@intrepid.com writes: 2) Expensive warnings (-Wall, -Warray-bounds, -Wuninitialized, -Wunused) [not sure about the actual list] that require optimizations, will issue a Warning when they are requested, but the appropriate optimization level has not been asserted, that is required for those warnings to work in their maximal fashion. Or: Specification of the expensive warnings will cause appropriate control flow computations that are required to support those warning levels. (as suggested previously) I think both of those alternatives would be surprising and easily misunderstood behaviour for many compiler users. The first means that you have to use different warnings at different optimization levels, or you need to use some mechanism to disable the default warning. The second means that adding a warning option could have a significant effect on compile time, which is surprising. My current thinking is that the following should be followed by all warnings: * They should be entirely independent of optimization level, or * They should warn specifically about the consequences of some easily misunderstood optimization, or * They should always be true positives. Almost all current warnings already meet those requirements; the main problem child is -Wuninitialized. Ian
Re: GCC and out-of-range constant array indexes?
On 10/08/10 13:22:46, Ian Lance Taylor wrote: I think both of those alternatives would be surprising and easily misunderstood behaviour for many compiler users. [...] I find the following behavior to be surprising: $ gcc -Warray-bounds -O0 -c t.c $ gcc -Warray-bounds -O1 -c t.c $ gcc -Warray-bounds -O2 -c t.c t.c: In function ‘main’: t.c:6: warning: array subscript is above array bounds t.c:7: warning: array subscript is below array bounds The impact is that I may think that after I build my project at -O0 or -O1, with various warnings enabled, that there are potential surprises that await, when I perform a production build at -O2 and higher. It makes perfect sense to me that the following happens: $ gcc -Warray-bounds -O1 -c t.c t.c: Warning: -Warray-bounds has no effect unless compiled with optimization level -O2 and higher. Almost all current warnings already meet those requirements; the main problem child is -Wuninitialized. ... and -Warray-bounds?
RE: GCC and out-of-range constant array indexes?
The impact is that I may think that after I build my project at -O0 or -O1, with various warnings enabled, that there are potential surprises that await, when I perform a production build at -O2 and higher. -Warray-bounds warnings can also be triggered only when using the aggressive inlining optimizations enabled by -O3. I assume the same is true for -flto, which would allow for a cross-module inlining and therefore deeper analysis. I personally just use PC-Lint as an extra safety net to help find issues like this during my necessarily short TDD cycle. Then when the optimized build is compiled, all of the issues that GCC would have found were generally already found by PC-Lint. It's quite nice to have the two tools cross-check each other in a usage pattern that they are both well-suited to.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, 8 Oct 2010, NightStrike wrote: On Thu, Sep 23, 2010 at 9:53 AM, NightStrike nightstr...@gmail.com wrote: On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn dave.korn.cyg...@gmail.com wrote: On 21/09/2010 02:51, NightStrike wrote: The toolchain is broken once again here: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../build/mingw/mingw-w64-crt -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD -I/tmp/build/root/x 86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-ali asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noret urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD -MP -MF math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o math/lib32_libmingwex_a-sf_erf.o `test -f 'math/sf_erf.c' || echo '../../../build/mingw/mingw-w64-crt/'`math/sf_ erf.c ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function `__trunc_float_wor d.isra.0': ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler error: tree check: expected var_decl, have debug_expr_decl in const_value_known_p, at varpool.c:375 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738 cheers, DaveK Thanks. Hope it gets fixed fast. I will post a new testsuite once that bug is closed. http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html Please also post results for the 4.5 branch. I think it doesn't make any sense to include a target in the list of primary or secondary targets if it didn't work reasonably for at least one release. Thanks, Richard.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther rguent...@suse.de wrote: Please also post results for the 4.5 branch. I think it doesn't make any sense to include a target in the list of primary or secondary targets if it didn't work reasonably for at least one release. Thanks, Richard. Ok. Does that have to be done regularly?
Re: GCC and out-of-range constant array indexes?
Gary Funck g...@intrepid.com writes: On 10/08/10 13:22:46, Ian Lance Taylor wrote: I think both of those alternatives would be surprising and easily misunderstood behaviour for many compiler users. [...] I find the following behavior to be surprising: $ gcc -Warray-bounds -O0 -c t.c $ gcc -Warray-bounds -O1 -c t.c $ gcc -Warray-bounds -O2 -c t.c t.c: In function ‘main’: t.c:6: warning: array subscript is above array bounds t.c:7: warning: array subscript is below array bounds The impact is that I may think that after I build my project at -O0 or -O1, with various warnings enabled, that there are potential surprises that await, when I perform a production build at -O2 and higher. It makes perfect sense to me that the following happens: $ gcc -Warray-bounds -O1 -c t.c t.c: Warning: -Warray-bounds has no effect unless compiled with optimization level -O2 and higher. Yes, that warning would be good for people, if it happened once. It's like the spiel on the airplane about how to buckle your seat belt. It's good for everybody to hear that once. The tenth time you hear it, it's pointless. The hundredth time, it's annoying. Many people compile with -Werror and most people use the same set of warning options at all optimization levels. So we would then require a way to explicitly disable this warning. Almost all current warnings already meet those requirements; the main problem child is -Wuninitialized. ... and -Warray-bounds? -Warray-bounds meets the criteria I listed, because it is pretty much always a true positive. I think you are basically suggesting that we drop the third criterion on my list (they should always be true positives). I could support that if others agree. Ian
Re: GCC and out-of-range constant array indexes?
Would it be possible to compute enough of the control flow graph to process warnings like this one, without running the actual optimizations, unless those optimizations are requested? Would the cost be too high? It is possible to do it quite fast. Clang implements all warnings, including Wuninitialized, in the FE using fast analysis and they claim very low false positives. However, there are various reasons why it has not been attempted in GCC: * GCC is too slow already at -O0, slowing it down further would not be acceptable. So you need a really high-performing implementation. * The FEs are quite complex, and both C and C++ construct gimple in a different way. It would be easier to do the analysis once the FE has finished building generic/gimple. However, * The FEs fold/transform expressions as they go, so you don't have a 1-to-1 relationship between the intermediate representation generated by the FEs and the code. Yet, anything is possible in principle. First, it would need someone to do the work. As far as I know, there is no one planning or willing to work on this. And second, it would need to be accepted by the maintainers. I suggest you clarify the latter before implementing your idea, or you will be seriously disappointed. An alternative would be to move the heavier analysis to an external tool that can be invoked by the compiler and share the same infrastructure. As http://clang-analyzer.llvm.org/ does. However, GCC is many years far away to enable implementing such technology. So perhaps implementing some analysis on the FE would be a more promising approach (despite the caveats mentioned above). But you have to find out if the overhead would be acceptable for the respective maintainers. Cheers, Manuel.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, 8 Oct 2010, NightStrike wrote: On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther rguent...@suse.de wrote: Please also post results for the 4.5 branch. I think it doesn't make any sense to include a target in the list of primary or secondary targets if it didn't work reasonably for at least one release. Thanks, Richard. Ok. Does that have to be done regularly? Not as regularly as for trunk. But catching regressions on a branch is still important. Richard. -- Richard Guenther rguent...@suse.de Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: GCC and out-of-range constant array indexes?
On 08/10/2010 21:39, Gary Funck wrote: The impact is that I may think that after I build my project at -O0 or -O1, with various warnings enabled, that there are potential surprises that await, when I perform a production build at -O2 and higher. The moral of the story is that you should *test* the *production* build. Not an experimental dev build. cheers, DaveK
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 08/10/2010 19:10, NightStrike wrote: On Fri, Oct 8, 2010 at 2:04 PM, Jonathan Wakely jwakely@gmail.com wrote: Most of the failing libstdc++ tests which shouldn't be platform-dependent fail with this message: sh: /usr/bin/stty: Bad address This Bad address stuff is due to some conflict with cygwin. We really need to work with cygwin folks to find a proper fix, but are having difficulty. Dave, can you work with Kai to help troubleshoot that, by any chance? I'm pretty busy at the moment, and you're the one who actually has the problem manifesting itself, plus all the log files and build dirs that you'd need to figure out what it is that's going wrong. cheers, DaveK
Re: GCC and out-of-range constant array indexes?
On Oct 8, 2010, at 18:18, Manuel López-Ibáñez wrote: It is possible to do it quite fast. Clang implements all warnings, including Wuninitialized, in the FE using fast analysis and they claim very low false positives. However, there are various reasons why it has not been attempted in GCC: * GCC is too slow already at -O0, slowing it down further would not be acceptable. So you need a really high-performing implementation. The Ada front end has very extensive warnings. I don't think they really contribute measurably to performance. We don't try to construct call graphs to determine wether the array reference will be executed or not. If the line appears in your program, it will cause an error if executed, so we will warn: either you wrote dead code, or wrong code. To avoid false positives in inlined code, code instantiated from templates and the like, we have a notion of code that comes from source or not. For many warnings, we will only post the warning if the code comes from source, that is: is not generated by the compiler as part of the compilation process. -Geert
[Bug fortran/45081] [4.3/4.4 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-08 06:01:44 UTC --- (In reply to comment #14) FAIL: gfortran.dg/derived_array_intrinisics_1.f90 -O (test for excess errors) FAIL: gfortran.dg/derived_array_intrinisics_1.f90 -O scan-tree-dump-times original j = 10 1: dump file does not exist Why should the dump file not exist? Because of the first line: Seemingly, you get some (excess) error(s) and thus the compiler aborts before it can dump the tree. Run the test with cd $GCCBUILD/gcc make check-gfortran RUNTESTFLAGS='dg.exp=derived_array_intrinisics_1.f90' and search for the excess error in testsuite/gfortran/gfortran.log.
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-08 09:13:00 UTC --- Honza made it go latent by defaulting to balanced partitioning.
[Bug rtl-optimization/45656] [4.6 Regression]: gfortran.dg/forall_4.f90 -O3, wrong code with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45656 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Component|debug |rtl-optimization --- Comment #14 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-10-08 09:13:22 UTC --- Changed to rtl-optimization (indeed in retrospect, tree-optimization was wrong). Changing it to debug was wrong too, as it did not just affect debug information. By the way, with this fixed, and no regressions, thumbs crossed, my autotester will be regression-free, first time since 2009-07-02 07:27:16 (UTC) r149169!
[Bug rtl-optimization/45656] [4.6 Regression]: gfortran.dg/forall_4.f90 -O3, wrong code with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45656 --- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-08 09:18:15 UTC --- Changing it to debug was wrong too, as it did not just affect debug information. Then you need to change the ChangeLog.
[Bug libstdc++/45893] [C++0x] [DR 817] Finish updating std::bind to rvalue refs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45893 --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-08 09:26:17 UTC --- Excellent. Thanks a lot again Jon!
[Bug tree-optimization/45902] CPU2006 benchmark sphinx3 fails with vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45902 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-08 09:44:04 UTC --- + if (CONVERT_EXPR_CODE_P (rhs_code) + TREE_TYPE (lhs) != TREE_TYPE (first_stmt_lhs)) checking types_compatible_p (TREE_TYPE (lhs), TREE_TYPE (first_stmt_lhs)) should work. If for some reason it doesn't please use at least TYPE_MAIN_VARIANT (TREE_TYPE (...
[Bug c++/45938] New: tree tag for CLASSTYPE_TEMPLATE_SPECIALIZATION spec is confusing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45938 Summary: tree tag for CLASSTYPE_TEMPLATE_SPECIALIZATION spec is confusing. Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamesmikedup...@googlemail.com In the file : gcc/cp/dump.c there is a dump of the CLASSTYPE_TEMPLATE_SPECIALIZATION, if (CLASSTYPE_TEMPLATE_SPECIALIZATION(t)) dump_string(di, spec); This is confusing, because spec already has a different meaning, it is used to denote other values, spec : NAME. It would be better to rename this output to dump_string(di, tmpl_spclz); for example so that the tag spec is consistent. thanks, mike
[Bug debug/45939] New: negative location ranges generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45939
Summary: negative location ranges generated
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org
Created attachment 21996
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21996
Testcase
When compiling the testcase with -O2 -g a negative location range for a
variable is generated:
0371 0174 0176 (DW_OP_breg10: 4)
0371 0176 0175 (DW_OP_fbreg: -412) [without
DW_AT_frame_base] (start end)
.8byte .LVL20-.Ltext0 # Location list begin address (*.LLST13)
.8byte .LVL20-1-.Ltext0# Location list end address (*.LLST13)
.2byte 0x3 # Location expression size
.byte 0x91# DW_OP_fbreg
The problem seem to arise from call related var_location note to be mixed with
non call related. 209r.vartrack:
(call_insn 150 580 583 20 wrongvainfo.c:31 (parallel [
(call (mem:QI (reg/v/f:DI 6 %r6 [orig:120 getRegUsage ] [120]) [0
S1 A8])
(const_int 0 [0x0]))
(clobber (reg:DI 14 %r14))
]) 546 {*basr} (expr_list:REG_DEAD (reg:DI 4 %r4)
(expr_list:REG_DEAD (reg:DI 3 %r3)
(expr_list:REG_DEAD (reg:DI 2 %r2)
(nil
(expr_list:REG_DEP_TRUE (use (reg:DI 4 %r4))
(expr_list:REG_DEP_TRUE (use (reg:DI 3 %r3))
(expr_list:REG_DEP_TRUE (use (reg:DI 2 %r2))
(nil)
(note 583 150 582 20 (var_location r (mem/c:SI (plus:DI (reg/f:DI 32 %ap)
(const_int -412 [0xfe64])) [14 %sfp+-252 S4 A32]))
NOTE_INSN_VAR_LOCATION)
(note/c 582 583 581 20 (var_location instr (nil)) NOTE_INSN_VAR_LOCATION)
(note/c 581 582 584 20 (var_location r (reg:SI 14 %r14))
NOTE_INSN_VAR_LOCATION)
For note 582 the LVL20-1 label is being generated while note 583 belongs to
label LVL20. That makes the location range of note 583 to be LVL20...LVL20-1.
[Bug debug/45939] negative location ranges generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45939
--- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2010-10-08
10:53:41 UTC ---
The problem could not be reproduced with head. On head the var_location note in
question is never been generated. I was not able to figure out which change
caused this.
209r.vartrack:
(call_insn 157 155 523 14 (parallel [
(call (mem:QI (reg/v/f:DI 6 %r6 [orig:133 getRegUsage ] [133]) [0
S1 A8])
(const_int 0 [0]))
(clobber (reg:DI 14 %r14))
]) wrongvainfo.c:31 548 {*basr}
(expr_list:REG_DEAD (reg:DI 4 %r4)
(expr_list:REG_DEAD (reg:DI 3 %r3)
(expr_list:REG_DEAD (reg:DI 2 %r2)
(nil
(expr_list:REG_DEP_TRUE (use (reg:DI 4 %r4))
(expr_list:REG_DEP_TRUE (use (reg:DI 3 %r3))
(expr_list:REG_DEP_TRUE (use (reg:DI 2 %r2))
(nil)
(note/c 523 157 522 14 (var_location instr (nil)) NOTE_INSN_VAR_LOCATION)
(note/c 522 523 524 14 (var_location r (reg:SI 12 %r12 [orig:98 D.2154 ] [98]))
NOTE_INSN_VAR_LOCATION)
[Bug other/38340] Error in pthread.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38340 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08 11:05:47 UTC --- Closing after no response in nearly two years. The user probably has #define _ASM somewhere or something else invalid
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08 11:32:00 UTC --- Author: redi Date: Fri Oct 8 11:31:56 2010 New Revision: 165163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165163 Log: PR libstdc++/45403 * python/libstdcxx/v6/printers.py: Check for lazy_string support. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08 11:40:04 UTC --- Fixed for 4.6.0 Pawel, can you test with an older GDB? I no longer have 7.0 around. If it works fine I will apply it to the 4.5 branch as well, it isn't a regression but I think it should be safe to do on the release branch.
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08 12:04:21 UTC --- Author: redi Date: Fri Oct 8 12:04:14 2010 New Revision: 165164 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165164 Log: PR libstdc++/45403 * python/libstdcxx/v6/printers.py: Check for lazy_string support. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.6.0 |4.5.2 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08 12:08:44 UTC --- I've tested it myself and have fixed it for 4.5.2 as well
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org 2010-10-08 12:12:34 UTC --- The problem seems to be the only folding of OBJ_TYPE_REF we do and which comes from a (copy) constructor. So I assume this is the same issue as PR 45934.
[Bug c++/45940] New: [trans-mem] Error of unsafe function even if annotated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45940
Summary: [trans-mem] Error of unsafe function even if annotated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincent.gram...@epfl.ch
CC: r...@gcc.gnu.org, al...@gcc.gnu.org
When I compile a transactional program which use an annotated STL, GCC
compilation says that the function is not safe even if it is annotated.
I have attached the ii file (I tried to make it smaller but it didn't
figure out when it happens).
Here the compilation:
$ g++ -O0 -c -Wall -g -fgnu-tm -fno-builtin Building.ii
In file included from src/Building.cpp:77:0:
src/Building.cpp:1341:27: error: unsafe function call ‘void
std::list_Tp, _Alloc::push_front(const value_type) [with _Tp =
Bullet*, _Alloc = std::allocatorBullet*, value_type = Bullet*]’ within
‘transaction_safe’ function
Extract from STL source:
__attribute__((transaction_pure))
void
push_front(const value_type __x)
{ this-_M_insert(begin(), __x); }
[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 belagod at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from belagod at gcc dot gnu.org 2010-10-08 12:53:04 UTC --- This bug has been fixed.
[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 --- Comment #10 from richard.earnshaw at arm dot com 2010-10-08 12:53:40 UTC --- I shall be out of the office from Monday 11 October until Monday 1 November; I will not have email access during most of that time, so I will read your message when I return. For urgent issues, please contact Roger Teague or Matthew Gretton-Dann.
[Bug middle-end/40893] ARM and PPC truncate intermediate operations unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40893
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org 2010-10-08
13:04:49 UTC ---
(In reply to comment #2)
Here's a minimal test case:
void foo(unsigned int v)
{
*(volatile unsigned short *)0xabcdefab = (v);
}
The compiler has to be extremely conservative with this code as it has a
volatile memory reference to deal with. It must take extreme care not to
modify that operation and one consequence of this is that it is then difficult
to remove the narrowing operation.
[Bug target/45847] ICE in supportable_widening_operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45847 belagod at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from belagod at gcc dot gnu.org 2010-10-08 13:09:41 UTC --- Fix for this bug has been checked in.
[Bug c/45941] New: Failed compile on Loongson2f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45941
Summary: Failed compile on Loongson2f
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wenheping2...@hotmail.com
Hi,
I am doing a LFS on Loongson2f, successed in gcc-4.5.1 pass1 but failed in
pass 2, here is the configure line:
../gcc-4.5.1/configure --prefix=/tools --disable-multilib
--libexecdir=/tools/lib --with-local-prefix=/tools --enable-long-long
--enable-c99 --enable-shared --enable-threads=posix --disable-nls
--enable-__cxa_atexit --enable-languages=c --disable-libstdcxx-pch
--disable-bootstrap --with-abi=${MABI} --with-gmp-include=$(pwd)/gmp
--with-gmp-lib=$(pwd)/gmp/.libs
then the result of running make:
m...@debian:/64_system/build/gcc-build$ make
make[1]: Entering directory `/64_system/build/gcc-build'
make[2]: Entering directory `/64_system/build/gcc-build/libiberty'
make[3]: Entering directory `/64_system/build/gcc-build/libiberty/testsuite'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/64_system/build/gcc-build/libiberty/testsuite'
make[2]: Leaving directory `/64_system/build/gcc-build/libiberty'
make[2]: Entering directory `/64_system/build/gcc-build/fixincludes'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/64_system/build/gcc-build/fixincludes'
make[2]: Entering directory `/64_system/build/gcc-build/gmp'
make all-recursive
make[3]: Entering directory `/64_system/build/gcc-build/gmp'
Making all in tests
make[4]: Entering directory `/64_system/build/gcc-build/gmp/tests'
Making all in .
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests'
make[5]: Nothing to be done for `all-am'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests'
Making all in devel
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/devel'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/devel'
Making all in mpn
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/mpn'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/mpn'
Making all in mpz
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/mpz'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/mpz'
Making all in mpq
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/mpq'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/mpq'
Making all in mpf
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/mpf'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/mpf'
Making all in rand
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/rand'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/rand'
Making all in misc
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/misc'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/misc'
Making all in cxx
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/cxx'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/cxx'
Making all in mpbsd
make[5]: Entering directory `/64_system/build/gcc-build/gmp/tests/mpbsd'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/64_system/build/gcc-build/gmp/tests/mpbsd'
make[4]: Leaving directory `/64_system/build/gcc-build/gmp/tests'
Making all in mpn
make[4]: Entering directory `/64_system/build/gcc-build/gmp/mpn'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/64_system/build/gcc-build/gmp/mpn'
Making all in mpz
make[4]: Entering directory `/64_system/build/gcc-build/gmp/mpz'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/64_system/build/gcc-build/gmp/mpz'
Making all in mpq
make[4]: Entering directory `/64_system/build/gcc-build/gmp/mpq'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/64_system/build/gcc-build/gmp/mpq'
Making all in mpf
make[4]: Entering directory `/64_system/build/gcc-build/gmp/mpf'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/64_system/build/gcc-build/gmp/mpf'
Making all in printf
make[4]: Entering directory `/64_system/build/gcc-build/gmp/printf'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/64_system/build/gcc-build/gmp/printf'
Making all in scanf
make[4]: Entering directory `/64_system/build/gcc-build/gmp/scanf'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/64_system/build/gcc-build/gmp/scanf'
Making all in cxx
make[4]: Entering directory `/64_system/build/gcc-build/gmp/cxx'
make[4]: Nothing
[Bug c++/45942] New: class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942
Summary: class will not get friends with another class
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michiel...@aim.com
In my current project, the construction of template class classB works well
when friend class declarations are replaced by making classA public.
With attempt 1, the compiler gives an error message, but not before
instantiation.
With attempt 2, the compiler gives an error message immediately, but an
incorrect one.
g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
template class T, int C class classA;
template class T, int C, classAT,C instanceA class classB;
template class T, int C class classA
{
// error message on instantiation: too few template parameters (1 3)
template classA instanceA friend class classB;
// incorrect error message: partial specialization claimed but not apparent
// template classA instanceA friend class classBT,C,instanceA;
private:
int for_use_by_classB;
};
template class T, int C, classAT,C instanceA class classB
{
classB (int i) { instanceA.for_use_by_classB = i; }
};
// instantiation
// template class classAchar,128;
[Bug driver/45936] [4.6 regression] cc1 fails to generate target code with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45936 --- Comment #3 from gee jojelino at gmail dot com 2010-10-08 14:12:53 UTC --- gcc without -mno-cygwin also fails to generate target code.. version of binutils is 2.20.51.20101005 $ gcc -DHAVE_HYPOT -DHAVE_FILE64 -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE=unsigned long long -g -DUSE_LIBICONV_GNU -I./obj -I./base -o ./obj/gxfill.o -c ./base/gxfill.c -save-temps -O2 -v;nm -sn ./obj/gxfill.o gcc -DHAVE_HYPOT -DHAVE_FILE64 -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE=unsigned long long -g -DUSE_LIBICONV_GNU -I./obj -I./base -o ./obj/gxfill.o -c ./base/gxfill.c -save-temps -O2 -v;nm -sn ./obj/gxfill.o Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --prefix=/usr --disable-win32-registry --enable-threads=posix --enable-languages=c,c++,lto --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp Thread model: posix gcc version 4.6.0 20101005 (experimental) (GCC) COLLECT_GCC_OPTIONS='-D' 'HAVE_HYPOT' '-D' 'HAVE_FILE64' '-D' 'HAVE_FONTCONFIG' '-D' 'HAVE_LIBIDN' '-D' 'HAVE_SETLOCALE' '-Wall' '-Wstrict-prototypes' '-Wundef' '-Wmissing-declarations' '-Wmissing-prototypes' '-Wwrite-strings' '-Wno-strict-aliasing' '-Wdeclaration-after-statement' '-fno-builtin' '-fno-common' '-D' 'HAVE_STDINT_H' '-D' 'GX_COLOR_INDEX_TYPE=unsigned long long' '-g' '-D' 'USE_LIBICONV_GNU' '-I' './obj' '-I' './base' '-o' './obj/gxfill.o' '-c' '-save-temps' '-O2' '-v' '-mtune=generic' '-march=pentiumpro' /usr/libexec/gcc/i686-pc-cygwin/4.6.0/cc1.exe -E -quiet -v -I ./obj -I ./base -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../../include/w32api -D HAVE_HYPOT -D HAVE_FILE64 -D HAVE_FONTCONFIG -D HAVE_LIBIDN -D HAVE_SETLOCALE -D HAVE_STDINT_H -D GX_COLOR_INDEX_TYPE=unsigned long long -D USE_LIBICONV_GNU ./base/gxfill.c -mtune=generic -march=pentiumpro -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -g -fworking-directory -O2 -fpch-preprocess -o gxfill.i ignoring duplicate directory /usr/include ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../../include/w32api #include ... search starts here: #include ... search starts here: ./obj ./base /usr/lib/gcc/i686-pc-cygwin/4.6.0/include /usr/local/include /usr/lib/gcc/i686-pc-cygwin/4.6.0/include-fixed /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/include /usr/lib/gcc/i686-pc-cygwin/4.6.0/../../../../i686-pc-cygwin/lib/../include/w32api End of search list. COLLECT_GCC_OPTIONS='-D' 'HAVE_HYPOT' '-D' 'HAVE_FILE64' '-D' 'HAVE_FONTCONFIG' '-D' 'HAVE_LIBIDN' '-D' 'HAVE_SETLOCALE' '-Wall' '-Wstrict-prototypes' '-Wundef' '-Wmissing-declarations' '-Wmissing-prototypes' '-Wwrite-strings' '-Wno-strict-aliasing' '-Wdeclaration-after-statement' '-fno-builtin' '-fno-common' '-D' 'HAVE_STDINT_H' '-D' 'GX_COLOR_INDEX_TYPE=unsigned long long' '-g' '-D' 'USE_LIBICONV_GNU' '-I' './obj' '-I' './base' '-o' './obj/gxfill.o' '-c' '-save-temps' '-O2' '-v' '-mtune=generic' '-march=pentiumpro' /usr/libexec/gcc/i686-pc-cygwin/4.6.0/cc1.exe -fpreprocessed gxfill.i -quiet -dumpbase gxfill.c -mtune=generic -march=pentiumpro -auxbase-strip ./obj/gxfill.o -g -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -version -fno-builtin -fno-common -o gxfill.s GNU C (GCC) version 4.6.0 20101005 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.6.0 20100925 (experimental), GMP version 5.0.0, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.6.0 20101005 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.6.0 20100925 (experimental), GMP version 5.0.0, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 07133399117e0f779c05a33aa9c33ff4 COLLECT_GCC_OPTIONS='-D' 'HAVE_HYPOT' '-D' 'HAVE_FILE64' '-D' 'HAVE_FONTCONFIG' '-D' 'HAVE_LIBIDN' '-D' 'HAVE_SETLOCALE' '-Wall' '-Wstrict-prototypes' '-Wundef' '-Wmissing-declarations'
[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725 --- Comment #5 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2010-10-08 14:13:08 UTC --- (In reply to comment #3) On Mon, 4 Oct 2010, siarhei.siamashka at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725 --- Comment #2 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2010-10-04 22:59:56 UTC --- (In reply to comment #1) So the compiler is correct not to be using vld1 for this code. The memory format of int32x4_t is defined to be the format of a neon register that has been filled from an array of int32 values and then stored to memory using VSTM (or equivalent sequence). The implication of all this is that int32x4_t does not (necessarily) have the same memory layout as int32_t[4]. Could you elaborate on this? Specifically about the case when memory format for VSTM and VST1 may differ. Big-endian. OK, I see. Looks like VLDM/VSTM instructions could be replaced with VLD1/VST1 (by artificially forcing element size to 64) in almost all cases except when SCTLR.A == 1 due to unwanted alignment traps potentially happening in this case. But the question is whether it is really necessary to suffer from a performance penalty on little endian systems? I previously explained the issues with big-endian NEON vectors in GCC at length: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00409.html Thanks for the link, something seems to be seriously overengineered. Looks like you brought a problem upon yourself and now are trying to valiantly solve it. Does (efficient) support of NEON intrinsics on big endian systems even have any practical value? Maybe it makes sense to get a reasonable performance at least on little endian systems first. To me it looks like you are just running after two hares...
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org 2010-10-08 14:40:41 UTC --- Please disregard the previous comment, I saw what I wanted to see and not what was actually there. But it is true that avoiding the only O_T_R folding avoids the segfault. But so far I see nothing wrong with that devirtualization... I will keep staring at it for a bit longer.
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08
14:41:28 UTC ---
It's not entirely clear what you're saying is a bug, because your testcase
doesn't give any error.
It's more helpful to provide the source code that you claim produces the bug.
I assume you this:
template class T, int C class classA;
template class T, int C, classAT,C instanceA class classB;
template class T, int C class classA
{
// incorrect error message: partial specialization claimed but not apparent
template classA instanceA friend class classBT,C,instanceA;
private:
int for_use_by_classB;
};
template class T, int C, classAT,C instanceA class classB
{
classB (int i) { instanceA.for_use_by_classB = i; }
};
// instantiation
template class classAchar,128;
That code is not valid, the error is not incorrect.
You have declared classB as a friend, and as a template with one template
parameter, instanceA, and the template arguments T,C,instanceA. That is a
partial specialization.
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08
14:46:16 UTC ---
This variation uses B1 for your first attempt and B2 for your second attempt.
template class T, int C class A;
template class T, int C, AT,C a class B1;
template class T, int C, AT,C a class B2;
template class T, int C class A
{
template A a friend class B1;
template A a friend class B2T,C,a;
};
// instantiation
template class Achar,128;
This code is not valid, G++ is correct to reject it.
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942
--- Comment #3 from Michiel MichieldeB at aim dot com 2010-10-08 14:51:36 UTC
---
(In reply to comment #1)
It's not entirely clear what you're saying is a bug, because your testcase
doesn't give any error.
It's more helpful to provide the source code that you claim produces the bug.
I assume you this:
template class T, int C class classA;
template class T, int C, classAT,C instanceA class classB;
template class T, int C class classA
{
// incorrect error message: partial specialization claimed but not apparent
template classA instanceA friend class classBT,C,instanceA;
private:
int for_use_by_classB;
};
template class T, int C, classAT,C instanceA class classB
{
classB (int i) { instanceA.for_use_by_classB = i; }
};
// instantiation
template class classAchar,128;
That code is not valid, the error is not incorrect.
You have declared classB as a friend, and as a template with one template
parameter, instanceA, and the template arguments T,C,instanceA. That is a
partial specialization.
Apparently you are making the same mistake as the compiler. In the friend class
declaration, the third parameter is not free, indeed, but its specialization
level does not exceed that of the class definition of class classB. Thus the
friend declaration is no specialization in the proper relative sense.
If you still do not agree, just provide code that makes classB a friend of
classA. That is what I want.
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942
Michiel MichieldeB at aim dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #4 from Michiel MichieldeB at aim dot com 2010-10-08 14:58:42 UTC
---
(In reply to comment #2)
This variation uses B1 for your first attempt and B2 for your second attempt.
template class T, int C class A;
template class T, int C, AT,C a class B1;
template class T, int C, AT,C a class B2;
template class T, int C class A
{
template A a friend class B1;
template A a friend class B2T,C,a;
};
// instantiation
template class Achar,128;
This code is not valid, G++ is correct to reject it.
Please explain why the code is invalid, and do not click Resolved invalid
until ClassB is a friend of ClassA.
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||INVALID --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-08 15:02:54 UTC --- (In reply to comment #3) Apparently you are making the same mistake as the compiler. Before adjusting the sentence to use a proper plural here (the same error happens with the Intel, EDG, Comeau, SunStudio and Microsoft compilers, for sure) I would suggest considering a little longer the first person singular.
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08
15:08:36 UTC ---
(In reply to comment #4)
(In reply to comment #2)
This code is not valid, G++ is correct to reject it.
Please explain why the code is invalid, and do not click Resolved invalid
until ClassB is a friend of ClassA.
You reported an invalid bug, so I rejected it.
It's not my job to teach you C++ but here you go:
template class T, int C class A;
template class T, int C, AT,C a class B;
template class T, int C class A
{
template class X, int Y, AX,Y friend class B;
};
That makes BX,Y,AX,Y a friend of A
Your original example is invalid for the reason the compiler gave, the syntax
you tried to use declares a partial specialization, which is not allowed in a
friend declaration. That's how C++ works, I don't make the rules.
[Bug lto/45343] LTO doesn't work with Boost on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45343 Gideon Amos gideon.amos at canfieldsci dot com changed: What|Removed |Added CC||gideon.amos at canfieldsci ||dot com --- Comment #5 from Gideon Amos gideon.amos at canfieldsci dot com 2010-10-08 15:09:31 UTC --- I see the same problem with a different program using GCC 4.5.1, boost 1.44 on MinGW
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942 --- Comment #7 from Michiel MichieldeB at aim dot com 2010-10-08 15:12:36 UTC --- (In reply to comment #5) (In reply to comment #3) Apparently you are making the same mistake as the compiler. Before adjusting the sentence to use a proper plural here (the same error happens with the Intel, EDG, Comeau, SunStudio and Microsoft compilers, for sure) I would suggest considering a little longer the first person singular. Does C++ accept dependencies between template parameters. G++ does that within my project. And all I am asking is to make ClassB a friend of ClassA before clicking Resolved Invalid. I am using G++ and do not see a reason why another compiler should be able to make ClassB a friend of ClassA.
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08 15:36:01 UTC --- (In reply to comment #7) (In reply to comment #5) (In reply to comment #3) Apparently you are making the same mistake as the compiler. Before adjusting the sentence to use a proper plural here (the same error happens with the Intel, EDG, Comeau, SunStudio and Microsoft compilers, for sure) I would suggest considering a little longer the first person singular. Does C++ accept dependencies between template parameters. G++ does that within my project. And all I am asking is to make ClassB a friend of ClassA before clicking Resolved Invalid. You seem to misunderstand what this bugzilla is for. You reported a bug, but it was invalid, so it doesn't belong in this bugzilla. Whether you know a workaround or not is irrelevant. You have not found a bug in the compiler. Figuring out what's wrong with your code and fixing it is your job, not GCC's. Resolved - Invalid means it's not a valid bug report, it doesn't mean We have analysed the user's code and shown how to fix it I am using G++ and do not see a reason why another compiler should be able to make ClassB a friend of ClassA. Other compilers don't accept your code either, because it's wrong. However, I have given you a workaround that makes classB a friend of classA, so you should be happy now, right?
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942
--- Comment #9 from Michiel MichieldeB at aim dot com 2010-10-08 15:43:13 UTC
---
(In reply to comment #6)
(In reply to comment #4)
(In reply to comment #2)
This code is not valid, G++ is correct to reject it.
Please explain why the code is invalid, and do not click Resolved invalid
until ClassB is a friend of ClassA.
You reported an invalid bug, so I rejected it.
It's not my job to teach you C++ but here you go:
template class T, int C class A;
template class T, int C, AT,C a class B;
template class T, int C class A
{
template class X, int Y, AX,Y friend class B;
};
That makes BX,Y,AX,Y a friend of A
Your original example is invalid for the reason the compiler gave, the syntax
you tried to use declares a partial specialization, which is not allowed in a
friend declaration. That's how C++ works, I don't make the rules.
I really tried everything, but I have to admit I missed that one. Sorry. But
you have to admit that it is a rather unnatural way to make friends.
Furthermore, the third parameter Z is missing (I would prefer AX,YZ), but
that does not seem to be a problem for the compiler.
Thus it seems that the bug is that c++ is designed is such a way that it gives
error messages which are incorrect.
If you would have followed the title of my bug report immediately instead of
saying that is was invalid, then the discussion would have been unnecessary.
Now it is still odd that the first attempt gives an error so lately. The
template precompiler counts three arguments and the template instantiator
counts one, which is not very consistent.
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #8 from bredelin at ucla dot edu 2010-10-08 15:58:49 UTC --- When you say segfault, I presume you mean abort? When I use the debugger, the problem appears to be in the call to new Parameters(*P); On x86_64, the problem occurs as follows: (x86_32 is different) In the copy constructor, Parameters::SuperModel2 is constructed OK. Then the copy constructor for Parameters::Probability_Model is called, which calls the copy constructor for Probability_Model::Model2, which calls the copy constructor for Model2::vectordouble. In the (synthesized) copy constructor vectordouble::vectordouble(const vectordouble __x), the debugger claims that this and __x are both optimized out, and won't let me inspect anything. The SIGABORT actually occurs because the __x has a __x.size() of 18446726482060379005. It should have a size of 0. (I can't call __x.size(), but I can access __n, which is initialized from __x.size()).
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-08 15:59:08 UTC --- (In reply to comment #9) I really tried everything, but I have to admit I missed that one. Sorry. But you have to admit that it is a rather unnatural way to make friends. Furthermore, the third parameter Z is missing (I would prefer AX,YZ), but that does not seem to be a problem for the compiler. You can just add it if it makes you feel better. That parameter isn't used in the friend declaration, so giving it a name is optional. YOu can call it Z or whatever you want, it doesn't matter. Thus it seems that the bug is that c++ is designed is such a way that it gives error messages which are incorrect. C++ doesn't specify the text of error messages, it says what is valid and what is not. The compiler rejected your code because it's not valid. I don't know why you think the error message is incorrect. This is a template declaration: template classA instanceA friend class classB; It has one parameter. classB was already declared as a template with three parameters. So you get this error message: pr45942.cc:9:45: error: redeclared with 1 template parameter pr45942.cc:3:57: note: previous declaration ‘templateclass T, int C, classAT, C instanceA class classB’ used 3 template parameters That seems correct to me. If you would have followed the title of my bug report immediately instead of saying that is was invalid, then the discussion would have been unnecessary. But your bug report IS invalid. I repeat, you said there was a bug in the compiler, I said there isn't. If you had said please help me fix my code that would have been a different discussion (and you'd have been asked to go somewhere else, like a C++ forum or newsgroup) Despite that, you have succeeded in turning it into a discussion of why your code is not valid. Now it is still odd that the first attempt gives an error so lately. The template precompiler counts three arguments and the template instantiator counts one, which is not very consistent. There's no template precompiler Please take this somewhere else, GCC's bugzilla is not the place for it.
[Bug c++/45942] class will not get friends with another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45942 --- Comment #11 from Michiel MichieldeB at aim dot com 2010-10-08 16:09:33 UTC --- C++ is designed to give an error message which is syntactically correct, but semantically incorrect. I thought that the template prechecker (preprocessor or whatever, do not correct me this time) counted template arguments in friend declarations, but now it seems it does not, sorry.
[Bug tree-optimization/45932] execute/pr37573.c fails after Neon misaligned patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45932 --- Comment #2 from jules at gcc dot gnu.org 2010-10-08 16:17:58 UTC --- Could you be more specific about testsuite options, etc. needed to observe this apparent regression? I haven't been able to reproduce it using default options, nor by specifying [-mthumb] -march=armv7-a -mfpu=neon -mfloat-abi=softfp to the test run. I do see a failure like so: .../gcc/testsuite/gcc.c-torture/execute/pr37573.c:64:1: sorry, unimplemented: gimple bytecode streams do not support machine specific builtin functions on this target for -flto and -fwhopr, but those happen irrespective of whether the misalignment patch is applied or not. Thanks!
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-08 16:28:39 UTC --- Paul's draft patch: http://gcc.gnu.org/ml/fortran/2010-10/msg00100.html
[GCC Bugzilla] Your account gcc-bugs@gcc.gnu.org is being impersonated
Frédéric Buclin lpso...@netscape.net has used the 'sudo' feature to access GCC Bugzilla using your account. Frédéric Buclin lpso...@netscape.net provided the following reason for doing this: Checking email preferences for the mailing-list. Ignore this message. If you feel that this action was inappropriate, please contact overse...@gcc.gnu.org. For more information on this feature, visit http://gcc.gnu.org/bugzilla/page.cgi?id=sudo.html.
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #9 from bredelin at ucla dot edu 2010-10-08 16:37:15 UTC --- On x86_32, the problem occurs somewhat differently. All I did differently is add -m32. It seems that on x86_32, the copy constructor vectorint::vectorint(const vector __x) for SuperModel2::object fails, whereas it succeeded on x86_64. The values for this and __x are not optimized out for SuperModel2::object, so they can be inspected. The values for __x appear to be crazy. This leads to a large __n, and thus another abort because of an attempt to allocate too much memory. (__n should be 0). The error may be caused by the fact that __x points to the wrong memory location (0xd4a0, instead of the correct value 0xd484). I think the location of __x is wrong on x86_64 also, but it just so happens on x86_64 that __x._M_finish - __x._M_start is 0 for the wrong location of __x, whereas on x86_32 it does not happen to be 0. Does this help any?
[Bug web/45922] notification email is not sent when an attachment is added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45922 --- Comment #2 from Frédéric Buclin LpSolit at netscape dot net 2010-10-08 16:47:48 UTC --- (In reply to comment #1) I set the email prefs accordingly. Oops, sorry. That was me, using the gcc-bugs@ user account to check email prefs. So as I said, this is now FIXED.
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2010-10-08 16:51:19 UTC --- I think I know what is going on. BINFO_VIRTUALS of the BINFO describing Probability_Model within Parameters pint to a wring thunk of the method Parameters:clone(). Therefore when the call is devirtualized, the this parameter is not adjusted to point to the whole Ptr object and points only to the part representing the Probability_Model ancestor. And so all references to the fields of the object just load garbage.
[Bug c++/45923] constexpr diagnostic w/ non-literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923 --- Comment #2 from Benjamin Kosnik bkoz at redhat dot com 2010-10-08 17:12:35 UTC --- It is not valid for real() to be constexpr in a non-literal class This is a helpful diagnostic. The existing one is not. -benjamin
[Bug middle-end/40893] ARM and PPC truncate intermediate operations unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40893
--- Comment #4 from paul walmsley paul at pwsan dot com 2010-10-08 17:17:24
UTC ---
The bug also appears without volatile:
/* generates an unnecessary uxth */
void foo(unsigned short a, unsigned short b, unsigned short c,
unsigned short *e, unsigned short *f)
{
*e = (a + b) + c;
*f = (a + b) - c;
}
/* works as expected */
void bar(unsigned short a, unsigned short b, unsigned short c,
unsigned short *e)
{
*e = (a + b) + c;
}
/* works as expected */
void baz(unsigned short a, unsigned short b, unsigned short c,
unsigned short *e)
{
*e = (a + b) - c;
}
-
compiled and dumped with:
arm-linux-gnueabi-gcc -O2 -c test.c ; objdump -DS test.o
produces:
-
Disassembly of section .text:
foo:
0: e0811000add r1, r1, r0
4: e1a01801lsl r1, r1, #16
8: e1a01821lsr r1, r1, #16
c: e0620001rsb r0, r2, r1
10: e0821001add r1, r2, r1
14: e1c310b0strhr1, [r3]
18: e59d3000ldr r3, [sp]
1c: e1c300b0strhr0, [r3]
20: e12fff1ebx lr
0024 bar:
24: e0811000add r1, r1, r0
28: e0822001add r2, r2, r1
2c: e1c320b0strhr2, [r3]
30: e12fff1ebx lr
0034 baz:
34: e0811000add r1, r1, r0
38: e0622001rsb r2, r2, r1
3c: e1c320b0strhr2, [r3]
40: e12fff1ebx lr
-
gcc -v:
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-2'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.4.5
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --disable-sjlj-exceptions --enable-checking=release
--program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabi
--with-headers=/usr/arm-linux-gnueabi/include
--with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-2)
[Bug fortran/45943] New: gfortran.dg/streamio_16.f90: Fails under MinGW64 - probably \r\n vs \n issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45943 Summary: gfortran.dg/streamio_16.f90: Fails under MinGW64 - probably \r\n vs \n issue Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org On MinGW64, the test case fails as follows: PASS: gfortran.dg/streamio_16.f90 (test for excess errors) spawn [open ...] This application has requested the Runtime to terminate it in an unusual way. I assume that this is due to the difference between LF and CRLF as the file is a formatted stream: open(50, access=stream, form=formatted) write(50, *, pos=1) Just something [...] read( 50, *,pos=i) inquire(50, access=sAccess, pos=mypos) if (mypos.ne.18) call abort On Linux, the file fort.50 contains: 000 sp J u s t sp s o m e t h i n g sp 020 nl 021 Thus nl is at position 17. As Kai tested: Using if (mypos.ne.19) call abort with 19 instead of 18 works on MinGW64.
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org 2010-10-08 17:57:11 UTC --- Created attachment 21998 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21998 proposed patch But fortunately BINFOs contain the delta and so we can find the appropriate thunk in the call graph. I'm attaching an untested proposed fix which seems to work on the testcase. Obviously I need to clean it up a little bit and will also try to make a simple testcase.
[Bug target/45944] New: genmddeps segfaults processing mips.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45944
Summary: genmddeps segfaults processing mips.md
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@blagblagblag.org
CC: aol...@gcc.gnu.org
Created attachment 21999
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21999
strace of genmddeps segfault in gcc-4.5.1
I am trying to rpmbuild gcc-4.5.1-20100924 from Fedora rawhide under Fedora 13
MIPS on a Lemote Yeeloong.
It is failing here:
build/genmddeps ../../gcc/config/mips/mips.md tmp-mddeps
/bin/sh: line 1: 32256 Segmentation fault build/genmddeps
../../gcc/config/mips/mips.md tmp-mddeps
make[3]: *** [s-mddeps] Error 139
Running strace outputs (full strace attached):
open(mips/generic.md, O_RDONLY|O_LARGEFILE) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=2957, ...}) = 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2b40
read(4, ;; Generic DFA-based pipeline de..., 4096) = 2957
read(4, , 4096) = 0
close(4)= 0
munmap(0x2b40, 65536) = 0
read(3, and\)\n\t\t (match_operand:GPR 2 \..., 4096) = 4096
read(3, ands[1])\n((INTVAL (operand..., 4096) = 4096
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
A successful strace snippet running under gcc-4.4.4:
open(mips/generic.md, O_RDONLY|O_LARGEFILE) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=2957, ...}) = 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2b
334000
read(4, ;; Generic DFA-based pipeline de..., 4096) = 2957
read(4, , 4096) = 0
close(4)= 0
munmap(0x2b334000, 65536) = 0
read(3, (ISA_HAS_COND_TRAP)\nreturn \..., 4096) = 4096
read(3,(set (match_dup 0) (plus:SI (..., 4096) = 4096
read(3, \n\t\t(match_operand:ANYF 2 \re..., 4096) = 4096
read(3, nstructions by another instructi..., 4096) = 4096
read(3, itable to use MADD over a \MUL; ..., 4096) = 4096
read(3, ratch:SI 5 \=d,d\))]\n \ISA_HAS_..., 4096) = 4096
read(3, perand\ \0,d\)\n ..., 4096) = 4096
read(3, \))\n\t (any_extend:DI (match_..., 4096) = 4096
brk(0x100c4000) = 0x100c4000
Running under gdb:
Starting program: /home/jebba/devel/gcc/segfault/genmddeps mips/mips.md
Programreceived signalSIGSEGV, Segmentation fault.
copy_rtx (orig=0x0) at ../../gcc/rtl.c:246
Build flags:
-O3 -mtune=loongson2f -march=loongson2f -mabi=n32 -mplt
I can attach the 1.3M buildlog if needed.
[Bug c++/45923] constexpr diagnostic w/ non-literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2010-10-08 18:37:52 UTC --- (In reply to comment #2) It is not valid for real() to be constexpr in a non-literal class This is a helpful diagnostic. The existing one is not. constexpr-basic.cc:9:20: error: enclosing class of ‘constexpr double complex::real() const’ is not a literal type isn't clear enough? How about non-static member function %D declared 'constexpr' in non-literal type ?
[Bug target/45944] genmddeps segfaults processing mips.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45944 --- Comment #1 from Jeff Moe moe at blagblagblag dot org 2010-10-08 18:51:27 UTC --- It was requested I post the ./configure and make lines: + ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin --disable-libgcj --disable-multilib --disable-fixed-point --without-ppl --without-cloog --disable-checking --disable-werror --build=mips64el-mofree-linux + GCJFLAGS='-O3 -mtune=loongson2f -march=loongson2f -mabi=n32 -mplt' + make -j6 'BOOT_CFLAGS=-O3 -mtune=loongson2f -march=loongson2f -mabi=n32 -mplt' profiledbootstrap
[Bug tree-optimization/45945] New: ICE: verify_ssa failed: error: SSA_NAME_DEF_STMT is wrong when using inline ASM with -flto/-fwhopr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45945 Summary: ICE: verify_ssa failed: error: SSA_NAME_DEF_STMT is wrong when using inline ASM with -flto/-fwhopr Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22000 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22000 reduced testcase Compiler output: $ gcc -O -fwhopr -r -nostdlib pr45945.c In file included from :0:0: pr45945.c: In function 'foo': pr45945.c:8:1: error: SSA_NAME_DEF_STMT is wrong Expected definition statement: __asm__( : =d VIEW_CONVERT_EXPRunnamed-unsigned:32(i_3)); Actual definition statement: GIMPLE_NOP pr45945.c:8:1: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-165152-lto-fortran-checking-yes-rtl-df/bin/gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status Output is the same with -fwhopr Tested revisions: r165152 - crash
[Bug middle-end/45505] [4.6 Regression] gfortran.dg/pr25923.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2010-10-08 19:27:23 UTC --- I have been seeing this XPASS on x86_64-apple-darwin10 at -m32... Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101007/gcc/testsuite/gfortran.dg/pr25923.f90 -O -O -Wuninitialized -S -m32 -o pr25923.s(timeout = 300) /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101007/gcc/testsuite/gfortran.dg/pr25923.f90: In function 'baz':^M /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101007/gcc/testsuite/gfortran.dg/pr25923.f90:13:0: warning: 'res.yr' may be used uninitialized in this function [-Wuninitialized]^M output is: /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101007/gcc/testsuite/gfortran.dg/pr25923.f90: In function 'baz':^M /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101007/gcc/testsuite/gfortran.dg/pr25923.f90:13:0: warning: 'res.yr' may be used uninitialized in this function [-Wuninitialized]^M XPASS: gfortran.dg/pr25923.f90 -O PR45505 (test for warnings, line 13) XPASS: gfortran.dg/pr25923.f90 -O PR45505 (test for bogus messages, line 22) PASS: gfortran.dg/pr25923.f90 -O (test for excess errors) Is that expected?
[Bug fortran/45943] gfortran.dg/streamio_16.f90: Fails under MinGW64 - probably \r\n vs \n issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45943 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.10.08 19:52:57 Ever Confirmed|0 |1 --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-10-08 19:52:57 UTC --- Yes, this is correct. I will adjust the test case. Thanks for report.
[Bug target/45946] New: ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45946 Summary: ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22001 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22001 reduced testcase Compiler output: $ gcc -Os -fno-omit-frame-pointer pr45946.c pr45946.c: In function 'foo': pr45946.c:9:1: error: unrecognizable insn: (insn 13 12 14 3 (set (mem/i:TI (pre_dec:DI (reg/f:DI 7 sp)) [0 S16 A128]) (const_double 0 [0] 3476778912330022912 [0x3040] 0 [0] 0 [0])) pr45946.c:8 -1 (nil)) pr45946.c:9:1: internal compiler error: in extract_insn, at recog.c:2127 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165152 - crash
[Bug rtl-optimization/45903] unnecessary load of 32/64bit variable when only 8 bits are needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45903 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-08 20:49:24 UTC --- Author: jakub Date: Fri Oct 8 20:49:19 2010 New Revision: 165200 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165200 Log: PR tree-optimization/45903 * simplify-rtx.c (simplify_subreg): Optimize lowpart SUBREG of *SHIFTRT of MEM. * gcc.target/i386/pr45903.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/45903] unnecessary load of 32/64bit variable when only 8 bits are needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45903 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-08 20:49:52 UTC --- Author: jakub Date: Fri Oct 8 20:49:44 2010 New Revision: 165202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165202 Log: PR tree-optimization/45903 * simplify-rtx.c (simplify_subreg): Optimize lowpart SUBREG of *SHIFTRT of MEM. * gcc.target/i386/pr45903.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr45903.c
[Bug lto/45947] New: ICE: tree code 'template_decl' is not supported in gimple streams with -flto/-fwhopr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45947 Summary: ICE: tree code 'template_decl' is not supported in gimple streams with -flto/-fwhopr Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22002 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22002 reduced testcase Compiler output: $ gcc -flto -c pr45947.C pr45947.C:7:26: internal compiler error: tree code 'template_decl' is not supported in gimple streams Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165152 - crash
[Bug fortran/45943] gfortran.dg/streamio_16.f90: Fails under MinGW64 - probably \r\n vs \n issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45943 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-10-08 22:28:54 UTC --- Author: jvdelisle Date: Fri Oct 8 22:28:49 2010 New Revision: 165208 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165208 Log: 2010-10-08 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/45943 * gfortran.dg/streamio_16.f90: Update test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/streamio_16.f90
[Bug fortran/45943] gfortran.dg/streamio_16.f90: Fails under MinGW64 - probably \r\n vs \n issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45943 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-10-08 22:30:18 UTC --- This should be fixed. Reopen if not.
[Bug tree-optimization/45948] New: ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) with -O2 -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45948 Summary: ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) with -O2 -ftree-loop-distribution Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22003 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22003 reduced testcase Command line: $ gcc -O2 -ftree-loop-distribution pr45948.c Related valgrind output: ==6585== Invalid read of size 8 ==6585==at 0x97C679: find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) ==6585==by 0x97C94F: find_uses_to_rename_bb (tree-ssa-loop-manip.c:284) ==6585==by 0x97CFED: rewrite_into_loop_closed_ssa (tree-ssa-loop-manip.c:331) ==6585==by 0x8F2CF2: distribute_loop (tree-loop-distribution.c:1087) ==6585==by 0x8F466C: tree_loop_distribution (tree-loop-distribution.c:1208) ==6585==by 0x7BF35E: execute_one_pass (passes.c:1562) ==6585==by 0x7BF5F4: execute_pass_list (passes.c:1617) ==6585==by 0x7BF606: execute_pass_list (passes.c:1618) ==6585==by 0x7BF606: execute_pass_list (passes.c:1618) ==6585==by 0x902275: tree_rest_of_compilation (tree-optimize.c:419) ==6585==by 0xAC4991: cgraph_expand_function (cgraphunit.c:1498) ==6585==by 0xAC6F29: cgraph_optimize (cgraphunit.c:1557) ==6585== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==6585== pr45948.c: In function 'foo': pr45948.c:4:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165152 - crash
[Bug lto/45949] New: ICE: SIGSEGV in gimple_default_def (tree-dfa.c:538) with -flto/-fwhopr on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45949 Summary: ICE: SIGSEGV in gimple_default_def (tree-dfa.c:538) with -flto/-fwhopr on invalid code Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22004 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22004 reduced testcase (from g++.dg/template/cond2.C) Command line: $ gcc -O2 -flto pr45949.C or $ gcc -O2 -fwhopr pr45949.C Related valgrind output: pr45949.C: In instantiation of 'int test(c(0 ? : X)*) [with int X = 2]': pr45949.C:2:24: instantiated from here pr45949.C:2:24: error: omitted middle operand to '?:' operand cannot be mangled ==22144== Invalid read of size 8 ==22144==at 0xA1125D: gimple_default_def (tree-dfa.c:538) ==22144==by 0xC132FB: ipa_analyze_node (ipa-prop.c:1282) ==22144==by 0xC05E2A: ipcp_generate_summary (ipa-cp.c:1538) ==22144==by 0x8FC6B5: execute_ipa_summary_passes (passes.c:1423) ==22144==by 0xC048C7: cgraph_optimize (cgraphunit.c:1718) ==22144==by 0xC04AA9: cgraph_finalize_compilation_unit (cgraphunit.c:1020) ==22144==by 0x58736C: cp_write_global_declarations (decl2.c:3928) ==22144==by 0x9E74E3: toplev_main (toplev.c:946) ==22144==by 0x657BBBC: (below main) (in /lib64/libc-2.11.2.so) ==22144== Address 0x40 is not stack'd, malloc'd or (recently) free'd ==22144== pr45949.C:7:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/45950] New: [4.6 Regression} ICE segmentation fault compiling __udivdi3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45950 Summary: [4.6 Regression} ICE segmentation fault compiling __udivdi3 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa*-*-* (32-bit) Target: hppa*-*-* (32-bit) Build: hppa*-*-* (32-bit) /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-4.6.0/hppa2.0w-hp-hpux11.11/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -frandom-seed=fixed-seed -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _udivdi3.o -MT _udivdi3.o -MD -MP -MF _udivdi3.dep -DL_udivdi3 -c ../../../gcc/libgcc/../gcc/libgcc2.c \ -fexceptions -fnon-call-exceptions ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__udivdi3': ../../../gcc/libgcc/../gcc/libgcc2.c:1134:1: internal compiler error: Segmentati on fault Introduced by the following change: 2010-10-08 Nathan Froyd froy...@codesourcery.com * tree-ssa-sccvn.c (init_vn_nary_op_from_pieces): New function. (init_vn_nary_op_from_op): New function. (init_vn_nary_op_from_stmt): New function. (vn_nary_op_lookup_1): New function. (sizeof_vn_nary_op): New function. (alloc_vn_nary_op_noinit): New function. (alloc_vn_nary_op): New function. (vn_nary_op_insert_into): New function. (vn_nary_op_lookup_pieces): Rewrite to use new helper functions. (vn_nary_op_lookup): Likewise. (vn_nary_op_lookup_stmt): Likewise. (vn_nary_op_insert_pieces): Likewise. (vn_nary_op_insert): Likewise. (vn_nary_op_insert_stmt): Likewise. (copy_nary): Likewise. (set_value_id_for_result): New function. (set_hashtable_value_ids): Call it. Program received signal SIGSEGV, Segmentation fault. 0x00037ff4 in $$dyncall () (gdb) bt #0 0x00037ff4 in $$dyncall () #1 0x03a80060 in htab_find_slot (htab=0x40122b58, element=0x7eff14f4, insert=NO_INSERT) at ../../gcc/libiberty/hashtab.c:712 #2 0x02ad98c4 in lookup_expression_id (expr=0x7eff14f4) at ../../gcc/gcc/tree-ssa-pre.c:292 #3 0x02adc658 in get_or_alloc_expr_for_constant (constant=0x7af2a738) at ../../gcc/gcc/tree-ssa-pre.c:1067 #4 0x02adcd18 in fully_constant_expression (e=0x40140088) at ../../gcc/gcc/tree-ssa-pre.c:1225 #5 0x02adda6c in phi_translate_1 (expr=0x40140088, set1=0x401464d0, set2=0x0, pred=0x7ad4a990, phiblock=0x7ad62750) at ../../gcc/gcc/tree-ssa-pre.c:1529 #6 0x02adeb54 in phi_translate (expr=0x4013ffc8, set1=0x401464d0, set2=0x0, pred=0x7ad4a990, phiblock=0x7ad62750) at ../../gcc/gcc/tree-ssa-pre.c:1858 #7 0x02adec28 in phi_translate_set (dest=0x401464f8, set=0x401464d0, pred=0x7ad4a990, phiblock=0x7ad62750) at ../../gcc/gcc/tree-ssa-pre.c:1892 #8 0x02adfa60 in defer_or_phi_translate_block (dest=0x401464f8, source=0x401464d0, block=0x7ad4a990, phiblock=0x7ad62750) at ../../gcc/gcc/tree-ssa-pre.c:2237 #9 0x02adfb64 in compute_antic_aux (block=0x7ad4a990, block_has_abnormal_pred_edge=0 '\000') at ../../gcc/gcc/tree-ssa-pre.c:2298 #10 0x02ae0ed4 in compute_antic () at ../../gcc/gcc/tree-ssa-pre.c:2604 #11 0x02ae8c6c in execute_pre (do_fre=0 '\000') at ../../gcc/gcc/tree-ssa-pre.c:4833 #12 0x02ae8e40 in do_pre () at ../../gcc/gcc/tree-ssa-pre.c:4868 #13 0x00ca6da0 in execute_one_pass (pass=0x40024168) at ../../gcc/gcc/passes.c:1562 #14 0x00ca7098 in execute_pass_list (pass=0x40024168) at ../../gcc/gcc/passes.c:1617 #15 0x00ca70bc in execute_pass_list (pass=0x40023748) at ../../gcc/gcc/passes.c:1618 #16 0x02548734 in tree_rest_of_compilation (fndecl=0x7ae68980) at ../../gcc/gcc/tree-optimize.c:419 #17 0x013ed6b0 in cgraph_expand_function (node=0x7aef4680) at ../../gcc/gcc/cgraphunit.c:1498 #18 0x013ed944 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1557 #19 0x013ee374 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1813 #20 0x013eb62c in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1020 #21 0x000c262c in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9821 #22 0x00e2c434 in compile_file () at ../../gcc/gcc/toplev.c:946 #23 0x00e30508 in do_compile () at ../../gcc/gcc/toplev.c:2374 #24 0x00e30694 in toplev_main (argc=74, argv=0x7eff0854) at
[Bug debug/45656] [4.6 Regression]: gfortran.dg/forall_4.f90 -O3, wrong code with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45656 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|debug --- Comment #16 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-10-09 01:25:12 UTC --- Bah, too much trouble for nothing.
[Bug tree-optimization/45950] [4.6 Regression] ICE segmentation fault compiling __udivdi3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45950 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build, ice-on-valid-code Target Milestone|--- |4.6.0 Summary|[4.6 Regression} ICE|[4.6 Regression] ICE |segmentation fault |segmentation fault |compiling __udivdi3 |compiling __udivdi3 Severity|normal |blocker --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-09 01:30:43 UTC --- Seen also on i686-linux-gnu (32bit where HWInt == 32).
[Bug tree-optimization/45950] [4.6 Regression] ICE segmentation fault compiling __udivdi3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45950 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Target|hppa*-*-* (32-bit) |hppa*-*-* Host|hppa*-*-* (32-bit) |hppa*-*-* Target Milestone|4.6.0 |--- Build|hppa*-*-* (32-bit) |hppa*-*-* Severity|blocker |normal --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2010-10-09 03:11:55 UTC --- Similar error on hppa64-hp-hpux11.11: /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc -4.6/hppa64-hp-hpux11.00/bin/ -B/opt/gnu64/gcc/gcc-4.6/hppa64-hp-hpux11.00/lib/ -isystem /opt/gnu64/gcc/gcc-4.6/hppa64-hp-hpux11.00/include -isystem /opt/gnu64/ gcc/gcc-4.6/hppa64-hp-hpux11.00/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold -style-definition -isystem ./include -fPIC -Dpa64=1 -DELF=1 -mlong-calls -g -D HAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../ ../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _moddi3.o -MT _moddi3 .o -MD -MP -MF _moddi3.dep -DL_moddi3 -c ../../../gcc/libgcc/../gcc/libgcc2.c \ -fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__moddi3': ../../../gcc/libgcc/../gcc/libgcc2.c:1099:1: internal compiler error: Segmentati on fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_moddi3.o] Error 1
[Bug tree-optimization/45950] [4.6 Regression] ICE segmentation fault compiling __udivdi3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45950 --- Comment #3 from froydnj at codesourcery dot com froydnj at codesourcery dot com 2010-10-09 03:34:20 UTC --- John, could you please confirm whether http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00761.html fixes the build errors that you see?
[Bug bootstrap/45951] New: [4.6 regression] Revision 165133 breaks bootstrap on Linux/ia32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45951 Summary: [4.6 regression] Revision 165133 breaks bootstrap on Linux/ia32 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: dave.korn.cyg...@gmail.com Revision 165133: http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00315.html caused: # CC=gcc -m32 CXX=g++ -m32 BOOT_CFLAGS=-g CFLAGS=-g RUNTESTFLAGS=--target_board 'unix' /export/gnu/import/git/gcc/configure --enable-languages=c --disable-bootstrap i686-linux --prefix=/usr/gcc-4.6.0-32bit --with-local-prefix=/usr/local --with-fpmath=sse --with-plugin-ld=ld.gold --enable-gold --with-fpmath=sse .. # make -j8 ... *** Configuration i686-linux not supported make: *** [configure-lto-plugin] Error 1
[Bug bootstrap/45951] [4.6 regression] Revision 165133 breaks bootstrap on Linux/ia32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45951 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-09 05:06:26 UTC --- Author: hjl Date: Sat Oct 9 05:06:21 2010 New Revision: 165214 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165214 Log: Add AC_CANONICAL_SYSTEM to configure.ac. 2010-10-08 H.J. Lu hongjiu...@intel.com PR bootstrap/45951 * configure.ac: Add AC_CANONICAL_SYSTEM. * configure: Regenerated. Modified: trunk/lto-plugin/ChangeLog trunk/lto-plugin/configure trunk/lto-plugin/configure.ac
[Bug bootstrap/45952] New: [4.6 regression] Revision 165178 breaks bootstrap on Linux/ia32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45952 Summary: [4.6 regression] Revision 165178 breaks bootstrap on Linux/ia32 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: froy...@codesourcery.com Depends on: 45951 Revision 165178: http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00360.html caused: # CC=gcc -m32 CXX=g++ -m32 BOOT_CFLAGS=-g CFLAGS=-g RUNTESTFLAGS=--target_board 'unix' /export/gnu/import/git/gcc/configure --enable-languages=c --disable-bootstrap i686-linux --prefix=/usr/gcc-4.6.0-32bit --with-local-prefix=/usr/local --with-fpmath=sse --with-fpmath=sse .. # make -j8 ... *** glibc detected *** /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1: double free or corruption (!prev): 0x08f2daa8 *** === Backtrace: = /lib/libc.so.6(+0x5aec41)[0x6cbc41] /lib/libc.so.6(obstack_free+0x4a)[0x6d3ada] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1[0x873121e] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(free_scc_vn+0x172)[0x87316c2] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1[0x871531d] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1[0x8715350] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(execute_one_pass+0x1b3)[0x84ca00b] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(execute_pass_list+0x40)[0x84ca1df] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(execute_pass_list+0x5c)[0x84ca1fb] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(tree_rest_of_compilation+0xf9)[0x862c7d0] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1[0x888103b] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1[0x88811ea] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(cgraph_optimize+0x1d8)[0x88817dc] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(cgraph_finalize_compilation_unit+0x6b)[0x887f545] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(c_write_global_declarations+0x28c)[0x80ddd57] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1[0x85a4b1e] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1[0x85a6d31] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(toplev_main+0xa6)[0x85a6df7] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1(main+0x1b)[0x81a8043] /lib/libc.so.6(__libc_start_main+0xe6)[0x672cc6] /export/build/gnu/gcc-32bit/build-i686-linux/./gcc/cc1[0x80b3891] === Memory map: 0011-00111000 r-xp 00:00 0 [vdso] 00111000-00131000 r-xp 08:02 24539 /usr/lib/libcloog.so.0.0.0 00131000-00132000 rw-p 0001f000 08:02 24539 /usr/lib/libcloog.so.0.0.0 00132000-00134000 rw-p 00:00 0 00134000-004a2000 r-xp 08:02 24525 /usr/lib/libppl_c.so.2.1.0 004a2000-004a5000 rw-p 0036d000 08:02 24525 /usr/lib/libppl_c.so.2.1.0 004a5000-004a8000 r-xp 08:02 396533 /usr/lib/sse2/libgmpxx.so.4.1.2 004a8000-004a9000 rw-p 2000 08:02 396533 /usr/lib/sse2/libgmpxx.so.4.1.2 004a9000-004bb000 r-xp 08:02 24535 /usr/lib/libmpc.so.2.0.0 004bb000-004bc000 rw-p 00012000 08:02 24535 /usr/lib/libmpc.so.2.0.0 004bc000-00509000 r-xp 08:02 21260 /usr/lib/libmpfr.so.1.2.2 00509000-0050a000 rw-p 0004d000 08:02 21260 /usr/lib/libmpfr.so.1.2.2 0051d000-0053b000 r-xp 08:02 19707 /lib/ld-2.12.1.so 0053b000-0053c000 r--p 0001d000 08:02 19707 /lib/ld-2.12.1.so 0053c000-0053d000 rw-p 0001e000 08:02 19707 /lib/ld-2.12.1.so 0053d000-005f5000 r-xp 08:02 24523 /usr/lib/libppl.so.7.1.0 005f5000-005f7000 rw-p 000b8000 08:02 24523 /usr/lib/libppl.so.7.1.0 005f7000-00643000 r-xp 08:02 396531 /usr/lib/sse2/libgmp.so.3.5.2 00643000-00644000 rw-p 0004c000 08:02 396531 /usr/lib/sse2/libgmp.so.3.5.2 00644000-0065a000 r-xp 08:02 43254 /usr/lib/libelf-0.148.so 0065a000-0065b000 r--p 00015000 08:02 43254 /usr/lib/libelf-0.148.so 0065b000-0065c000 rw-p 00016000 08:02 43254 /usr/lib/libelf-0.148.so 0065c000-007e1000 r-xp 08:02 22291 /lib/libc-2.12.1.so 007e1000-007e2000 ---p 00185000 08:02 22291 /lib/libc-2.12.1.so 007e2000-007e4000 r--p 00185000 08:02 22291 /lib/libc-2.12.1.so 007e4000-007e5000 rw-p
[Bug debug/45939] negative location ranges generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45939 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-debug Target||s390x-ibm-linux Host||s390x-ibm-linux Target Milestone|--- |4.5.2 Build||s390x-ibm-linux
[Bug target/45913] [4.6 Regression] ICE: in insn_default_length, at config/i386/i386.md:584 with -fselective-scheduling2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45913 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-09 05:34:15 UTC --- Author: hjl Date: Sat Oct 9 05:34:10 2010 New Revision: 165215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165215 Log: Support andhi/andsi/anddi as a zero-extending move. gcc/ 2010-10-08 H.J. Lu hongjiu...@intel.com PR target/45913 * config/i386/i386.c (ix86_binary_operator_ok): Support andhi/andsi/anddi as a zero-extending move. gcc/testsuite/ 2010-10-08 H.J. Lu hongjiu...@intel.com PR target/45913 * gcc.target/i386/pr45913.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr45913.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
