[Bug c++/48914] #pragma GCC diagnostic ignored -Wc++0x-compat doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914 --- Comment #4 from asmwarrior asmwarrior at gmail dot com 2012-08-02 06:41:33 UTC --- We are Code::Blocks' developers, we see the same annoying warnings, hope it will be fixed. Thanks. See: http://forums.codeblocks.org/index.php/topic,16670.msg113169.html#msg113169
[Bug other/53615] Buffer overflow in the compiler?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53615 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||ebotcazou at gcc dot ||gnu.org --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-08-02 07:09:02 UTC --- You should run the compiler under Valgrind and see whether it complains.
[Bug rtl-optimization/54133] regrename introduces additional dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-08-02 07:21:50 UTC --- In experiment, if I disable r0/r1 from renaming, most regressions observed in CSiBE are gone. So how should this be fixed? Thanks. The choice of the renaming register can be parameterized at the class level, but I'm not sure this would work here. You could also try to add some additional heuristics for this choice, as it seems to be clearly counter-productive here.
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-08-02 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-08-02 07:36:14 UTC --- /*** COMPILATION OUTPUT ***/ bash-3.2# gcc -o test1 test.cpp -m32 -mcpu=ultrasparc -lstdc++ /usr/local/bin/ld: target elf32-sparc not found collect2: ld returned 1 exit status # If I eliminate the -m32/-m64 flag output file is successfully generated. # bash-3.2# file test1 test1: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped # Is it something that has gone wrong during configuration due to which the compiler does not recognize the -m option? Rather strange indeed. What does `/usr/local/bin/ld -V' report? Could you compare the command line passed to collect2 w/ and w/o the -m32 flag? You need to add -v on the link line to have it printed.
[Bug c/54088] ICE at dwarf2out.c:20632 with -O1 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54088 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-08-02 08:01:06 UTC --- Investigating.
[Bug tree-optimization/50672] [4.7/4.8 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|tom at codesourcery dot com |rguenth at gcc dot gnu.org Summary|[4.7 Regression] ice: |[4.7/4.8 Regression] ice: |verify_ssa failed: no |verify_ssa failed: no |immediate_use list |immediate_use list --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-02 08:05:05 UTC --- Let me look into this some more - I removed the code because we later mark all virtual operands for renaming anyway, so it seemed redundant. But yes, releasing an SSA name and keeping released names in the IL is not going to work. The original testcase still passes though.
[Bug c++/48914] #pragma GCC diagnostic ignored -Wc++0x-compat doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914 --- Comment #5 from asmwarrior asmwarrior at gmail dot com 2012-08-02 08:28:10 UTC --- (In reply to comment #4) We are Code::Blocks' developers, we see the same annoying warnings, hope it will be fixed. Thanks. See: http://forums.codeblocks.org/index.php/topic,16670.msg113169.html#msg113169 Sorry, I post a wrong link, the link is only accessed by C::B developers, so it is a private link. But we just discuss the same issue.
[Bug fortran/54159] New: Fortran quad precision rounding seemingly nonsensical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54159 Bug #: 54159 Summary: Fortran quad precision rounding seemingly nonsensical Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jonathan.h...@stfc.ac.uk program quad_test implicit none integer, parameter :: dp = kind(0d0) integer, parameter :: qp = selected_real_kind(32) real(qp) :: qpreal1, qpreal2 ! Two quad prec numbers that differ by last 3 digits qpreal1 = 42246.397327831658913055434823036200_qp qpreal2 = 42246.397327831658913055434823036194_qp print *, qpreal1 = , qpreal1 print *, qpreal2 = , qpreal2 print * print *, trunc qpreal1 = , real(qpreal1, kind=dp) print *, trunc qpreal2 = , real(qpreal2, kind=dp) end program quad_test produces output qpreal1 =42246.397327831658913055434823036200 qpreal2 =42246.397327831658913055434823036194 trunc qpreal1 =42246.397327831663 trunc qpreal2 =42246.397327831655 the truncated output is incorrect in two ways: 1) Neither truncation is correct. 2) Both truncations are different but should be the same. Being unable to rely on quad-double conversions makes quad precision considerably less useful to us.
[Bug fortran/54147] [F03] Interface checks for PPCs deferred TBPs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54147 --- Comment #4 from janus at gcc dot gnu.org 2012-08-02 08:58:01 UTC --- Author: janus Date: Thu Aug 2 08:57:58 2012 New Revision: 190069 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190069 Log: 2012-08-02 Janus Weil ja...@gcc.gnu.org PR fortran/54147 * resolve.c (check_proc_interface): New routine for PROCEDURE interface checks. (resolve_procedure_interface,resolve_typebound_procedure, resolve_fl_derived0): Call it. 2012-08-02 Janus Weil ja...@gcc.gnu.org PR fortran/54147 * gfortran.dg/abstract_type_6.f03: Modified. * gfortran.dg/proc_ptr_comp_3.f90: Modified. * gfortran.dg/proc_ptr_comp_35.f90: New. * gfortran.dg/typebound_proc_9.f03: Modified. * gfortran.dg/typebound_proc_26.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_35.f90 trunk/gcc/testsuite/gfortran.dg/typebound_proc_26.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/abstract_type_6.f03 trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_3.f90 trunk/gcc/testsuite/gfortran.dg/typebound_proc_9.f03
[Bug fortran/54147] [F03] Interface checks for PPCs deferred TBPs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54147 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from janus at gcc dot gnu.org 2012-08-02 09:00:51 UTC --- Fixed with r190069. Closing.
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #5 from Paulo J. Matos Paulo.Matos at csr dot com 2012-08-02 09:34:03 UTC --- I have now a patch for this which I will submit shortly.
[Bug c++/54158] [4.6, 4.7, 4.8 Regression] Silently accepts sizeof to non-static member without object in C++03 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54158 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-02 Known to work||3.4.3, 4.1.2 Summary|Silently accepts sizeof to |[4.6, 4.7, 4.8 Regression] |non-static member without |Silently accepts sizeof to |object in C++03 mode|non-static member without ||object in C++03 mode Ever Confirmed|0 |1 Known to fail||4.4.3 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-02 09:42:07 UTC --- Confirmed, 3.4 and 4.1 got this right: t.cc:3: error: invalid use of non-static data member `Class::Member' t.cc:6: error: from this location
[Bug tree-optimization/50672] [4.7/4.8 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 --- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-02 09:43:19 UTC --- Author: rguenth Date: Thu Aug 2 09:43:14 2012 New Revision: 190070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190070 Log: 2012-08-02 Richard Guenther rguent...@suse.de PR tree-optimization/50672 Revert 2012-08-01 Richard Guenther rguent...@suse.de * tree-ssa-tail-merge.c (release_last_vdef): Remove. (replace_block_by): Adjust. * g++.dg/torture/pr50672.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr50672.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/50672] [4.7/4.8 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-02 09:43:19 UTC --- Author: rguenth Date: Thu Aug 2 09:43:14 2012 New Revision: 190070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190070 Log: 2012-08-02 Richard Guenther rguent...@suse.de PR tree-optimization/50672 Revert 2012-08-01 Richard Guenther rguent...@suse.de * tree-ssa-tail-merge.c (release_last_vdef): Remove. (replace_block_by): Adjust. * g++.dg/torture/pr50672.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr50672.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-tail-merge.c --- Comment #20 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-02 09:43:48 UTC --- Fixed again.
[Bug tree-optimization/50672] [4.7/4.8 Regression] ice: verify_ssa failed: no immediate_use list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50672 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #20 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-02 09:43:48 UTC --- Fixed again.
[Bug c++/54158] [4.6, 4.7, 4.8 Regression] Silently accepts sizeof to non-static member without object in C++03 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54158 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-02 09:45:06 UTC --- Ah, it was changed by a DR (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613) not a C++11 proposal, so supporting it in C++03 mode is probably intentional.
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #6 from Paulo J. Matos Paulo.Matos at csr dot com 2012-08-02 09:58:55 UTC --- Created attachment 27926 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27926 regcprop patch to remove redundant moves This patch seems to fix 54154. I am not sure its generic enough to make it straight into GCC but it works with our port and I ran all the tests I have access to without any regressions. With send it to gcc-patches.
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |tree-optimization Summary|Very slow compile at -O1|Very slow compile with |(expand vars) |attribute((flatten)) --- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2012-08-02 10:01:03 UTC --- (In reply to comment #10) indeed flatten will override any inlining heuristic that avoids creating gigant function bodies. Still eventually improving worst-case performance of some of our algorithms sounds good, even if it will never fix all issues that pop up when you for example put flatten on main () ;) Feel free to have a stab at it, if you must. It would be great if you could have a look at the patch I attached to this bug report for stack var conflicts (I'd finish it myself, but I won't have time for it before September or so). Oh, and document your loop changes, because loop_optimizer_init accounts for ~20% of the compile time (half of it incorrectly accounted to if-conversion, I'll post a bunch oftimevar fixes this week). Note that the flattened functions in themselves do not present much of a problem to the compiler (not at -O1, anyway), so the problem here is not the by-passing of the inlining heuristics per-se. It is the flattening operation itself that causes the compiler to explode. You can only see this by adding a timevar around flatten_function (I used TV_LOCAL_ALLOC for that, but I'll add a proper timevar for it :-) because the compiler as-is incorrectly accounts the time for flatten_function to TV_INLINE_HEURISTICS. There must be something non-linear in the flattening algorithm. I'm still trying to find out where, but it's kinda hard to debug a problem with a test case that takes literally hours to compile :-)
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 --- Comment #2 from damz dshanke at gmail dot com 2012-08-02 10:02:46 UTC --- (In reply to comment #1) /*** COMPILATION OUTPUT ***/ bash-3.2# gcc -o test1 test.cpp -m32 -mcpu=ultrasparc -lstdc++ /usr/local/bin/ld: target elf32-sparc not found collect2: ld returned 1 exit status # If I eliminate the -m32/-m64 flag output file is successfully generated. # bash-3.2# file test1 test1: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped # Is it something that has gone wrong during configuration due to which the compiler does not recognize the -m option? Rather strange indeed. What does `/usr/local/bin/ld -V' report? Could you compare the command line passed to collect2 w/ and w/o the -m32 flag? You need to add -v on the link line to have it printed. Output of ld -V is as follows: bash-3.2# /usr/local/bin/ld -V GNU ld (GNU Binutils) 2.21.1 Supported emulations: elf32_sparc_sol2 elf32_sparc elf64_sparc_sol2 elf64_sparc Collect options passed are as follows: Without -m32: COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-shared-libgcc' '-mcpu=v9' With -m32: COLLECT_GCC_OPTIONS='-o' 'test' '-m32' '-v' '-shared-libgcc' '-mcpu=v9' Without -m32: collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link... With -m32: collect2 -V -m elf32_sparc -Y P,/usr/ccs/lib:/usr/lib -rpath-link Note: On another machine where the output of ld -V is as follows, gcc 4.4.4 is able to compile successfully with the -m32/-m64 options bash-3.00# /usr/local/bin/ld -V GNU ld (GNU Binutils) 2.20.1.20100303 Supported emulations: elf32_sparc elf64_sparc bash-3.00# If I replace only the ld from GNU Binutils 2.21.x with the ld from 2.20.x then the compilation is successful with -m32/-m64. Is this a bug in the GNU ld 2.21.x? I read the following link (http://archives.gentoo.org/gentoo-alt/msg_a4641a1c17ce5f66a05c6440dd5cfc87.xml) which suggests a solution to the problem but it did not help me. I ran the following command but no change in behavior when i use ld from gnu binutils 2.21.x sed -i -e 's/^OUTPUT_FORMAT ( elf32-sparc )$/OUTPUT_FORMAT ( elf32-sparc-sol2 )/' $EPREFIX/usr/lib/lib*.so Please help. Thanks, damz
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #7 from Paulo J. Matos Paulo.Matos at csr dot com 2012-08-02 10:05:40 UTC --- (In reply to comment #6) With send it to gcc-patches. 's/With/Will/'
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 --- Comment #3 from damz dshanke at gmail dot com 2012-08-02 10:08:44 UTC --- Note: My gcc libraries are available at the /usr/local/gcc-4.4.4/lib whereas I ran the sed command on usr/lib/lib*.so
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664
--- Comment #15 from ramrad01 at arm dot com 2012-08-02 10:10:47 UTC ---
On 08/02/12 00:35, janis at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664
--- Comment #14 from Janis Johnson janis at gcc dot gnu.org 2012-08-01
23:35:12 UTC ---
Ramana, chunks of regular expressions within parentheses are matched and added
to the returned expression that is used in scan-assembler-times. To avoid
returning parenthesized bits you need to replace (regexp) with (?:regexp).
Here's what works in vst4Qu8.c (cut and pasted, so tabs are wrong):
/* { dg-final { scan-assembler-times vst4\.8\[
\]+\\\{(?:(?:\[dD\]\[0-9\]+-\[dD\]\[0-9\]+)|(?:\[dD\]\[0-9\]+, \[dD\]\[0-9\]+,
\[dD\]\[0-9\]+, \[dD\]\[0-9\]+))\\\},
\\\[\[rR\]\[0-9\]+\(?::\[0-9\]+\)?\\\]!?\(?:\[ \]+@\[a-zA-Z0-9 \]+\)?\n 2
} } */
Thanks for digging further. I assume this will work the same regardless
of whether it used in scan-assembler and scan-assembler-times. I'll try
to change the generator later today if you think that to be the case or
muck about with a couple of the vld2Q tests to check if this works there
as well.
Ramana
I haven't tried modifying the test generator.
[Bug rtl-optimization/54133] regrename introduces additional dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 --- Comment #7 from amker.cheng amker.cheng at gmail dot com 2012-08-02 10:18:41 UTC --- (In reply to comment #6) In experiment, if I disable r0/r1 from renaming, most regressions observed in CSiBE are gone. So how should this be fixed? Thanks. The choice of the renaming register can be parameterized at the class level, but I'm not sure this would work here. You could also try to add some additional heuristics for this choice, as it seems to be clearly counter-productive here. My bad that I did not mention details of the method by disabling r0/r1 from renaming. When comparing to trunk(where regrename is disabled for Os), the method fixes most of regrenaming regressions, which is good. But it is too conservertive that some renaming opportunities are missed. From the view of code size: data show that this method has 700/440 bytes benefit/regression against the current implemention of regrename. This means only 250 bytes benefit overall. The data is collected from CSiBE on arm cortex-m0. Giving that the regressions may cross basic_block, it's hard to fix them in regrenaming without missing renaming opportunities. Is it possible to run regcprop pass both before and after regrenaming?
[Bug c++/54111] function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-02 10:18:44 UTC --- FWIW Clang 3.2 accepts bug-int?.cc and rejects bug-u?.cc
[Bug fortran/54159] Fortran quad precision rounding seemingly nonsensical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54159 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-02 10:29:29 UTC --- Just for completeness, one obtains exactly the same result with ifort 12.2, which uses Intel's REAL(16) implementations. For your program, the result is: qpreal1 =42246.3973278316589130554348230362 qpreal2 =42246.3973278316589130554348230362 trunc qpreal1 =42246.3973278317 trunc qpreal2 =42246.3973278317 However, if one explicitly specifies that more digits are shown, i.e. '(a,f40.30)' and '(a,f30.20)', the result is: qpreal1 = 42246.397327831658913055434823036200 qpreal2 = 42246.397327831658913055434823036194 trunc qpreal1 = 42246.39732783166255103424 trunc qpreal2 = 42246.39732783165527507663 which matches gfortran's result. (Recall that REAL(..., kind=dp) operates on the binary (radix=2) representation, which often cannot simply be converted into decimal; such as 0.1, which is not representable as (finite) binary floating point number. * * * I believe that the current implementation matches the rounding mode IEEE_NEAREST. To get the same double-precision result, you have to forcefully round to a specific direction, i.e. IEEE_TO_ZERO, IEEE_UP or IEEE_DOWN. If gfortran had support for Fortran 2003's optional IEEE modules, you could use, e.g., CALL IEEE_SET_ROUNDING_MODE (IEEE_TO_ZERO) Unfortunately, TR15580/Fortran 2003's IEEE modules is not yet supported. And as some other features have a higher priority, it will take a while. Unless, of course, you (or someone else) volunteers ...
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de 2012-08-02 10:35:56 UTC --- On Thu, 2 Aug 2012, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |tree-optimization Summary|Very slow compile at -O1|Very slow compile with |(expand vars) |attribute((flatten)) --- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2012-08-02 10:01:03 UTC --- (In reply to comment #10) indeed flatten will override any inlining heuristic that avoids creating gigant function bodies. Still eventually improving worst-case performance of some of our algorithms sounds good, even if it will never fix all issues that pop up when you for example put flatten on main () ;) Feel free to have a stab at it, if you must. It would be great if you could have a look at the patch I attached to this bug report for stack var conflicts (I'd finish it myself, but I won't have time for it before September or so). It looks sensible - I hope Micha will pick it up though, I'll ping him personally. Oh, and document your loop changes, because loop_optimizer_init accounts for ~20% of the compile time (half of it incorrectly accounted to if-conversion, I'll post a bunch oftimevar fixes this week). It's on my list of things (for stage3, I really want to push more invasive cleanups for stage1 ... heh). Note that the flattened functions in themselves do not present much of a problem to the compiler (not at -O1, anyway), so the problem here is not the by-passing of the inlining heuristics per-se. It is the flattening operation itself that causes the compiler to explode. You can only see this by adding a timevar around flatten_function (I used TV_LOCAL_ALLOC for that, but I'll add a proper timevar for it :-) because the compiler as-is incorrectly accounts the time for flatten_function to TV_INLINE_HEURISTICS. There must be something non-linear in the flattening algorithm. I'm still trying to find out where, but it's kinda hard to debug a problem with a test case that takes literally hours to compile :-) I suppose it's the old issue that we update fibheap keys along each inlining decision - and with flatten there are just very many ... Honza? It also seems we flatten depth-first (thus inline leafs) instead of the other way around: orig_callee = callee; inline_call (e, true, NULL, NULL); if (e-callee != orig_callee) orig_callee-symbol.aux = (void *) node; flatten_function (e-callee, early); if (e-callee != orig_callee) orig_callee-symbol.aux = NULL; This means we will materialize all intermediate flattenings in functions that will not be reclaimed, right? flattening foo should inline everything into foo, but not affect remaining callee bodies. Richard.
[Bug fortran/54159] Fortran quad precision rounding seemingly nonsensical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54159
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-02
10:37:56 UTC ---
Actually, you can also change the rounding mode by calling the following C
program from your Fortran program.
/*/
#include fenv.h
void
set_round (void)
{ /* FE_TONEAREST, FE_UPWARD, FE_DOWNWARD, FE_TOWARDZERO. */
fesetround (FE_DOWNWARD);
}
/*/
!
interface
subroutine set_round() bind(C)
end subroutine
end interface
call set_round()
!
[Bug c++/54158] [4.6, 4.7, 4.8 Regression] Silently accepts sizeof to non-static member without object in C++03 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54158 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-02 10:45:09 UTC --- Indeed, I have recollections of the resolution being implemented. Let's close this. If I can quickly find a pointer I will add it here.
[Bug c++/54158] [4.6, 4.7, 4.8 Regression] Silently accepts sizeof to non-static member without object in C++03 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54158 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-02 10:51:32 UTC --- 2009-03-31 Jason Merrill ja...@redhat.com C++ DR 613 * semantics.c (finish_non_static_data_member): Allow such references without an associated object in sizeof/decltype/alignof.
[Bug c++/54111] function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111 --- Comment #3 from Leonid Volnitsky leonid at volnitsky dot com 2012-08-02 11:13:26 UTC --- if in bug-int2.cc (and only in this file) to replace tuple with pair - it becomes accepted by any gcc version.
[Bug fortran/54159] Fortran quad precision rounding seemingly nonsensical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54159 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-08-02 11:35:32 UTC --- What you see is the round to even effect as shown with the simpler following test: program quad_test implicit none integer, parameter :: dp = kind(0d0) integer, parameter :: qp = selected_real_kind(32) real(qp) :: y y = 1.0_qp+0.5*real(epsilon(1.0_dp), kind=qp) print *, y, nearest(y,1.0_qp) print *, real(y, kind=dp), real(nearest(y,1.0_qp), kind=dp) end program quad_test which outputs 1.00011102230246251565404 1.00011102230246251565423 1.1.0002 i.e., y is rounded to 1.0_dp (the closest even binary representation) while nearest(y,1.0_qp) is rounded to the closest double: nearest(1.0_dp,1.0_dp). For your numbers the hexa representations are: 400E4A0CCB6E8DB58801 400E4A0CCB6E8DB58800 40E4A0CCB6E8DB59 40E4A0CCB6E8DB58 and if I am not mistaken, the (default) rounding to even are correct. Your comments Two quad prec numbers that differ by last 3 digits and truncated output make me suspect that you are not fully aware of the detailed behavior of floating-point representations and their default rounding properties.
[Bug fortran/54159] Fortran quad precision rounding seemingly nonsensical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54159 --- Comment #4 from Jonathan Hogg jonathan.hogg at stfc dot ac.uk 2012-08-02 11:37:17 UTC --- I can confirm that if we fiddle the fp rounding mode using a bit of C (very similar to the one you just suggested) then the problem goes away for this example. With your clue and looking at the binary representation we can see the probable cause: If we believe the output of http://babbage.cs.qc.cuny.edu/IEEE-754/ Then the binary representation for the qp mantissa is 1.0100101011001100101101101110100011011011010110001000 vs 1.0100101011001100101101101110100011011011010110001001 between qpreal1 and qpreal2. These differ only in the last binary digit. A double precision mantissa is 1.010010101100110010110110111010001101101101011001 If you line these up in a text editor, the truncation occurs such that the 1001 part needs got rid of, which seems incorrectly rounded (if I've not made a mistake) Of course, if the correct qp mantissas are 1.010010101100110010110110111010001101101101011111 vs 1.0100101011001100101101101110100011011011010110001000 the rounding mode would make a difference. Apologies for mistaking floating point behavior for a bug.
[Bug c++/54111] function return type template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111 --- Comment #4 from Leonid Volnitsky leonid at volnitsky dot com 2012-08-02 13:12:44 UTC --- Please disregard my last message (about std::pair) - it was incorrect.
[Bug target/54087] __atomic_fetch_add does not use xadd instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087 --- Comment #4 from Ulrich Drepper drepper.fsp at gmail dot com 2012-08-02 14:33:19 UTC --- One more data point. In a micro-benchmark which uses realistic code used in production the change from __sync_sub_and_fetch(var, constant) to __sync_add_and_fetch(var, -constant) lead to a 10% to 27% improvement in performance. The cmpxchg use with the necessary initial load and I-S cache transition really kills performance when memory is highly contested.
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||ro at gcc dot gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-08-02 15:17:25 UTC --- Without -m32: COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-shared-libgcc' '-mcpu=v9' With -m32: COLLECT_GCC_OPTIONS='-o' 'test' '-m32' '-v' '-shared-libgcc' '-mcpu=v9' Without -m32: collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link... With -m32: collect2 -V -m elf32_sparc -Y P,/usr/ccs/lib:/usr/lib -rpath-link Note: On another machine where the output of ld -V is as follows, gcc 4.4.4 is able to compile successfully with the -m32/-m64 options bash-3.00# /usr/local/bin/ld -V GNU ld (GNU Binutils) 2.20.1.20100303 Supported emulations: elf32_sparc elf64_sparc bash-3.00# If I replace only the ld from GNU Binutils 2.21.x with the ld from 2.20.x then the compilation is successful with -m32/-m64. Is this a bug in the GNU ld 2.21.x? Certainly there is a mismatch between the compiler and the linker, and the linker now rejecting elf32_sparc is unexpected. Rainer, is that a known issue?
[Bug fortran/54159] Fortran quad precision rounding seemingly nonsensical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54159 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org 2012-08-02 15:23:51 UTC --- (In reply to comment #4) I can confirm that if we fiddle the fp rounding mode using a bit of C (very similar to the one you just suggested) then the problem goes away for this example. With your clue and looking at the binary representation we can see the probable cause: If we believe the output of http://babbage.cs.qc.cuny.edu/IEEE-754/ You don't need to resort to that URL. program quad_test implicit none integer, parameter :: dp = kind(0d0) integer, parameter :: qp = selected_real_kind(32) real(qp) :: qpreal1, qpreal2 ! Two quad prec numbers that differ by last 3 digits qpreal1 = 42246.3973278316589130554348230362000_qp qpreal2 = 42246.3973278316589130554348230361940_qp print '(A,Z32)', qpreal1 = , qpreal1 print '(A,Z32)', qpreal2 = , qpreal2 print * print '(A,Z16)', trunc qpreal1 = , real(qpreal1, kind=dp) print '(A,Z16)', trunc qpreal2 = , real(qpreal2, kind=dp) end program quad_test laptop:kargl[225] gfortran46 -o z -rpath /usr/local/lib/gcc46 a.f90 laptop:kargl[226] ./z qpreal1 = 400E4A0CCB6E8DB58801 qpreal2 = 400E4A0CCB6E8DB58800 trunc qpreal1 = 40E4A0CCB6E8DB59 trunc qpreal2 = 40E4A0CCB6E8DB58
[Bug preprocessor/54160] New: gcc should not define __OBJC2__ when lang is not set to ObjC (gcc 4.6 and later)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54160 Bug #: 54160 Summary: gcc should not define __OBJC2__ when lang is not set to ObjC (gcc 4.6 and later) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: jerem...@macports.org gcc should not be defining the __OBJC2__ preprocessor macro when it is not building for the Objective C or Objective C++ languages. ~ $ echo | gcc-mp-4.5 -x objective-c -E -dM - | grep OBJ #define __OBJC__ 1 ~ $ echo | gcc-mp-4.5 -E -dM - | grep OBJ ~ $ echo | gcc-mp-4.6 -x objective-c -E -dM - | grep OBJ #define __OBJC__ 1 #define __OBJC2__ 1 ~ $ echo | gcc-mp-4.6 -E -dM - | grep OBJ #define __OBJC2__ 1 This is a regression that entered gcc 4.6 and is present in current versions of 4.6, 4.7, and 4.8 snapshots
[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53876 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-02 15:39:10 UTC --- The ICE occurs for: CALL display_indv(indv(1)) in gfc_conv_class_to_class, which is called for e == indiv-_data(1). Namely for: /* Set the data. */ ctree = gfc_class_data_get (var); ... gfc_add_modify (parmse-pre, ctree, parmse-expr); That's the line: class.1._data = indv._data.data + (sizetype) ((indv._data.offset + 1) * (integer(kind=8)) indv._vptr-_size); The problem is that the LHS and the RHS have a different type. Both are pointers to a record_type, which contains genes (type array1_real(kind=4)) as component. However, the decl for both the record type and the genes type is different (only their respective canonical type is the same). I wonder whether it has something to do with restricted and not. (See also PR 45586). Though, as marking all variables as TARGET doesn't help, I might also be off track.
[Bug target/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961
--- Comment #21 from uros at gcc dot gnu.org 2012-08-02 16:24:35 UTC ---
Author: uros
Date: Thu Aug 2 16:24:25 2012
New Revision: 190089
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190089
Log:
Backport from mainline
2012-07-24 Uros Bizjak ubiz...@gmail.com
PR target/53961
* config/i386/i386.c (ix86_legitimate_address_p): Move check for
negative constant address for TARGET_X32 ...
(ix86_decompose_address): ... here. Reject constant addresses
that don't satisfy x86_64_immediate_operand predicate.
2012-07-23 Uros Bizjak ubiz...@gmail.com
PR target/53961
* config/i386/i386.md (*lea): Add asserts to detect invalid addresses.
* config/i386/i386.c (ix86_print_operand_address): Ditto.
(ix86_decompose_address): Allow (zero_extend:DI (subreg:SI (...)))
addresses. Prevent zero extensions of CONST_INT operands.
2012-07-22 Uros Bizjak ubiz...@gmail.com
PR target/53961
* config/i386/i386.md (*lea): New insn pattern.
(*lea_1): Remove.
(*leamode_2): Ditto.
(*lea_{3,4,5,6}_zext): Ditto.
* config/i386/predicates.md (lea_address_operand): Do not reject
zero-extended address operands.
* config/i386/constraints.md (j): Remove address constraint.
* config/i386/i386.c (ix86_decompose_address): Allow SImode subreg
of an address.
(ix86_print_operand_address): Handle SImode subreg of an address.
(ix86_avoid_lea_for_addr): Reject zero-extended addresses for now.
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/constraints.md
branches/gcc-4_7-branch/gcc/config/i386/i386.c
branches/gcc-4_7-branch/gcc/config/i386/i386.md
branches/gcc-4_7-branch/gcc/config/i386/predicates.md
[Bug target/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #22 from Uros Bizjak ubizjak at gmail dot com 2012-08-02 16:30:39 UTC --- Fixed everywhere.
[Bug other/53615] Buffer overflow in the compiler?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53615 --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-08-02 16:45:24 UTC --- (In reply to comment #6) You should run the compiler under Valgrind and see whether it complains. I never built the compiler with valgrind support. Is the a comprehensible documentation? The wiki has http://gcc.gnu.org/wiki/DebuggingGCC to use valgring as wrapper, but I also see many valgrind strings in GCC sources and some in gcc/doc. You mean --enable-checking=valgrind? This bug does no more appear since PR53595 is fixed. This is strange; maybe it's just incidental and now some other test case is needed to trigger this bug. Or one bug is actually a duplicate if the other?
[Bug middle-end/53865] [4.8 Regression] 176.gcc in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53865 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-08-02 16:58:42 UTC --- Author: hjl Date: Thu Aug 2 16:58:33 2012 New Revision: 190090 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190090 Log: Add free inline summary pass after pass_early_local_passes PR middle-end/53321 PR middle-end/53865 * ipa-inline-analysis.c (inline_free_summary): Return if inline_edge_summary_vec is NULL. * ipa-split.c (execute_split_functions): Check if a function is inlinable only if inline_edge_summary_vec != NULL. * ipa.c (symtab_remove_unreachable_nodes): Restore cgraph_propagate_frequency call when something was changed. (free_inline_summary): New function. (pass_ipa_free_inline_summary): New pass. * passes.c (init_optimization_passes): Add pass_ipa_free_inline_summary before pass_ipa_tree_profile. * timevar.def (TV_IPA_FREE_INLINE_SUMMARY): New. * tree-pass.h (pass_ipa_free_inline_summary): New. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-split.c trunk/gcc/ipa.c trunk/gcc/passes.c trunk/gcc/timevar.def trunk/gcc/tree-pass.h
[Bug middle-end/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 --- Comment #25 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-08-02 16:58:41 UTC --- Author: hjl Date: Thu Aug 2 16:58:33 2012 New Revision: 190090 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190090 Log: Add free inline summary pass after pass_early_local_passes PR middle-end/53321 PR middle-end/53865 * ipa-inline-analysis.c (inline_free_summary): Return if inline_edge_summary_vec is NULL. * ipa-split.c (execute_split_functions): Check if a function is inlinable only if inline_edge_summary_vec != NULL. * ipa.c (symtab_remove_unreachable_nodes): Restore cgraph_propagate_frequency call when something was changed. (free_inline_summary): New function. (pass_ipa_free_inline_summary): New pass. * passes.c (init_optimization_passes): Add pass_ipa_free_inline_summary before pass_ipa_tree_profile. * timevar.def (TV_IPA_FREE_INLINE_SUMMARY): New. * tree-pass.h (pass_ipa_free_inline_summary): New. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-split.c trunk/gcc/ipa.c trunk/gcc/passes.c trunk/gcc/timevar.def trunk/gcc/tree-pass.h
[Bug bootstrap/54128] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128 Steve Ellcey sje at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW
[Bug other/50925] [4.6/4.7/4.8 Regression][avr] ICE at spill_failure, at reload1.c:2118
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2012-02-17 00:00:00 |2012-08-02 0:00 --- Comment #24 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-08-02 17:24:25 UTC --- FYI, I just tried the TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P hook but without avail: Even with the most restrict setup (always return true) attachment 26765 triggers the bug. The kook isn't even called once...
[Bug libfortran/30162] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 Hristo Iliev iliev at rz dot rwth-aachen.de changed: What|Removed |Added CC||iliev at rz dot ||rwth-aachen.de --- Comment #22 from Hristo Iliev iliev at rz dot rwth-aachen.de 2012-08-02 17:34:03 UTC --- Revision 180701 removed all checks for special files in unit.c:unit_truncate(). As a consequence programs compiled with gfortran 4.6.3 and newer cannot to write (formatted) to Unix named pipes as ftruncate() fails with EINVAL: (64-bit code) lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) write(3, Hello, world!\n, 15)= 15 lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) ftruncate(3, 18446744073709551615) = -1 EINVAL (Invalid argument) (32-bit code) _llseek(3, 0, 0xffba8fa0, SEEK_CUR) = -1 ESPIPE (Illegal seek) write(3, Hello, world!\n, 15)= 15 _llseek(3, 0, 0xffba9080, SEEK_CUR) = -1 ESPIPE (Illegal seek) ftruncate64(3, 18446744073709551615)= -1 EINVAL (Invalid argument)
[Bug other/50925] [4.6/4.7/4.8 Regression][avr] ICE at spill_failure, at reload1.c:2118
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925 --- Comment #25 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-08-02 17:34:40 UTC --- (In reply to comment #24) The kook isn't even called once... My bad... The hook IS called, but it does not help with this bug.
[Bug target/54087] __atomic_fetch_add does not use xadd instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087
--- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-08-02 17:35:30
UTC ---
Created attachment 27927
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27927
Patch that introduces atomic_fetch_submode with const_int operands
This patch introduces atomic_fetch_submode:
--cut here--
(define_expand atomic_fetch_submode
[(set (match_operand:SWI 0 register_operand)
(unspec_volatile:SWI
[(match_operand:SWI 1 memory_operand)
(match_operand:SI 3 const_int_operand)];; model
UNSPECV_XCHG))
(set (match_dup 1)
(minus:SWI (match_dup 1)
(match_operand:SWI 2 const_int_operand)))
(clobber (reg:CC FLAGS_REG))]
TARGET_XADD
{
/* Avoid overflows. */
if (mode_signbit_p (MODEmode, operands[2]))
FAIL;
operands[2] = negate_rtx (MODEmode, operands[2]);
emit_insn (gen_atomic_fetch_addmode (operands[0], operands[1],
operands[2], operands[3]));
DONE;
})
--cut here--
We have to take care of overflows, so we can handle only const_int operands
with known-to-be overflow free values.
[Bug c++/54161] New: sizeof(void) expressions are accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161 Bug #: 54161 Summary: sizeof(void) expressions are accepted Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com gcc 4.8.0 20120729 (experimental) accepts the following code even using the following options: -Wall -pedantic -ansi with either of -std=c++98 or -std=c++0x // void f(); void (g())(); const int a = sizeof(void); const int b = sizeof(void()); const int c = sizeof(f()); const int d = sizeof(g()); typedef char test[a + b + c + d 0 ? 1 : -1]; // albeit issuing warnings: 4|warning: invalid application of 'sizeof' to a void type [-Wpedantic]| 5|warning: invalid application of 'sizeof' to a function type [-Wpedantic]| 6|warning: invalid application of 'sizeof' to a void type [-Wpedantic]| 7|warning: invalid application of 'sizeof' to a function type [-Wpedantic]| This code is ill-formed according to [expr.sizeof] p1: The sizeof operator shall not be applied to an expression that has function or incomplete type, [..], to the parenthesized name of such types, or to an lvalue that designates a bit-field. and thus should be rejected. The current behaviour is especially annoying, because such expression can occur in SFINAE expression where corresponding template specializations are not excluded from the set.
[Bug middle-end/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #26 from H.J. Lu hjl.tools at gmail dot com 2012-08-02 18:06:00 UTC --- Fixed.
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-08-02
18:29:41 UTC ---
(In reply to comment #9)
Fixed.
NACK. I cannot confirm that anything changed:
If I revert the Hack from comment #4 that represents a memory access as UNSPEC
instead of as MEM (so that lower-subreg won't split), the code bloat returns.
Just suppose the examples given in comment #0
long readx (const __memx long *p)
{
return *p;
}
long read0 (const __flash long *p)
{
return *p;
}
with GCC: (GNU) 4.8.0 20120802 (experimental)
and -S -Os -dp -mmcu=avr5 -fno-split-wide-types
the result is fine and there are 32-bit accesses:
readx:
movw r30,r22 ; 17*movhi/1[length = 1]
mov r21,r24 ; 18movqi_insn/1[length = 1]
call __xload_4 ; 19xload_si_libgcc[length = 2]
ret ; 24return[length = 1]
read0:
movw r30,r24 ; 19*movhi/1[length = 1]
lpm r22,Z+ ; 20*movsi/3[length = 4]
lpm r23,Z+
lpm r24,Z+
lpm r25,Z+
ret ; 24return[length = 1]
Without -fno-split-wide-types the bloat is still there:
readx:
push r12 ; 54pushqi1/1[length = 1]
push r13 ; 55pushqi1/1[length = 1]
push r14 ; 56pushqi1/1[length = 1]
mov r26,r24 ; 2*movpsi/1[length = 2]
movw r24,r22
movw r30,r24 ; 35*movhi/1[length = 1]
sbrc r26,7 ; 37xload_8/1[length = 4]
ld r22,Z
sbrs r26,7
lpm r22,Z
ldi r18,lo8(1) ; 49*movpsi/5[length = 3]
ldi r19,0
ldi r20,0
add r18,r24 ; 19addpsi3/1[length = 3]
adc r19,r25
adc r20,r26
movw r30,r18 ; 38*movhi/1[length = 1]
sbrc r20,7 ; 40xload_8/1[length = 4]
ld r23,Z
sbrs r20,7
lpm r23,Z
ldi r18,lo8(2) ; 64*reload_inpsi[length = 4]
mov r12,r18
mov r13,__zero_reg__
mov r14,__zero_reg__
add r12,r24 ; 22addpsi3/1[length = 3]
adc r13,r25
adc r14,r26
ldi r18,lo8(3) ; 51*movpsi/5[length = 3]
ldi r19,0
ldi r20,0
add r18,r24 ; 25addpsi3/1[length = 3]
adc r19,r25
adc r20,r26
movw r30,r12 ; 41*movhi/1[length = 1]
sbrc r14,7 ; 43xload_8/1[length = 4]
ld r24,Z
sbrs r14,7
lpm r24,Z
movw r30,r18 ; 44*movhi/1[length = 1]
sbrc r20,7 ; 46xload_8/1[length = 4]
ld r25,Z
sbrs r20,7
lpm r25,Z
pop r14 ; 59popqi[length = 1]
pop r13 ; 60popqi[length = 1]
pop r12 ; 61popqi[length = 1]
ret ; 62return_from_epilogue[length = 1]
read0:
movw r30,r24 ; 35*movhi/1[length = 1]
lpm r22,Z+ ; 17movqi_insn/4[length = 1]
lpm r23,Z ; 20movqi_insn/4[length = 1]
movw r18,r24 ; 38*movhi/1[length = 1]
subi r18,-2 ; 22addhi3_clobber/2[length = 2]
sbci r19,-1
movw r20,r24 ; 39*movhi/1[length = 1]
subi r20,-3 ; 25addhi3_clobber/2[length = 2]
sbci r21,-1
movw r30,r18 ; 40*movhi/1[length = 1]
lpm r24,Z ; 33movqi_insn/4[length = 1]
movw r30,r20 ; 41*movhi/1[length = 1]
lpm r25,Z ; 34movqi_insn/4[length = 1]
ret ; 44return[length = 1]
Each 32-bit move is still split into 4 8-bit moves even though that is
extremely expensive. This happens both for PSImode and for HImode addresses.
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-08-02 18:37:18 UTC --- Created attachment 27928 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27928 /local/gnu/patches/pr52543-undo-185605.diff Just for reference: Here is the patch that undoes the MEM-UNSPEC workaround from SVN 185605, comment #4 that I used.
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #12 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-08-02 18:39:31 UTC --- CCing Andrew.
[Bug c++/54161] sizeof(void) expressions are accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-02
18:41:54 UTC ---
The code checking for this is in c-common.c, thus changing the behavior is a
*tad* less trivial than it could be, we have to check c_dialect_cxx (), but
definitely very easy to do, if we wanted. Jason can you double check whether we
want to reject even without -pedantic?
Anyway, Daniel, it would be nice if you could add also SFINAE testcase too,
because likely it's a different issue: AFAICS, when we are in a SFINAE context,
the complain passed to c_sizeof_or_alignof_type should be false, thus the
function should return error_mark_node anyway, which, if properly checked by
the caller, should be enough for a correct SFINAE, irrespective of -pedantic or
any other command line option. Eg, for function type:
if (is_sizeof)
{
if (complain (pedantic || warn_pointer_arith))
pedwarn (loc, pedantic ? OPT_Wpedantic : OPT_Wpointer_arith,
invalid application of %sizeof% to a function type);
else if (!complain)
return error_mark_node;
value = size_one_node;
}
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 --- Comment #11 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-08-02 18:45:04 UTC --- Author: paolo Date: Thu Aug 2 18:44:58 2012 New Revision: 190093 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190093 Log: /cp 2012-08-02 Jason Merrill ja...@redhat.com Paolo Carlini paolo.carl...@oracle.com PR c++/51213 (again) * pt.c (type_unification_real): Call push_deferring_access_checks / pop_deferring_access_checks around the substitution of default template args. (instantiate_template_1): When the specialization returned by retrieve_specialization has FNDECL_HAS_ACCESS_ERRORS set and we are in a SFINAE context, simply return error_mark_node. * cp-tree.h (FNDECL_RECHECK_ACCESS_P): Rename FNDECL_HAS_ACCESS_ERRORS. /testsuite 2012-08-02 Jason Merrill ja...@redhat.com Paolo Carlini paolo.carl...@oracle.com PR c++/51213 (again) * g++.dg/cpp0x/sfinae37.C: Extend. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/sfinae37.C
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-02 19:37:23 UTC --- I guess we can close again.
[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820 --- Comment #20 from Mikael Morin mikael at gcc dot gnu.org 2012-08-02 19:48:55 UTC --- Author: mikael Date: Thu Aug 2 19:48:50 2012 New Revision: 190098 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190098 Log: fortran/ PR fortran/48820 * trans-array.c (gfc_conv_ss_startstride): Set the intrinsic result's lower and upper bounds according to the rank. (set_loop_bounds): Set the loop upper bound in the intrinsic case. testsuite/ PR fortran/48820 * gfortran.dg/assumed_rank_bounds_1.f90: New test. * gfortran.dg/assumed_rank_bounds_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_rank_bounds_1.f90 trunk/gcc/testsuite/gfortran.dg/assumed_rank_bounds_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/53805] combine_comparisons changes trapping behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805
--- Comment #10 from Marc Glisse glisse at gcc dot gnu.org 2012-08-02
19:54:47 UTC ---
Author: glisse
Date: Thu Aug 2 19:54:43 2012
New Revision: 190100
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190100
Log:
2012-08-02 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/53805
* gcc/fold-const.c (invert_tree_comparison): Invert ORDERED_EXPR and
UNORDERED_EXPR even for trapping floating point.
* gcc/testsuite/gcc.dg/fold-notunord.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/fold-notunord.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/gcc.dg/fold-notunord.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.dg/fold-notunord.c
('svn:keywords' added)
[Bug c++/54161] sizeof(void) expressions are accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-08-02 20:13:29 UTC --- (In reply to comment #1) Jason can you double check whether we want to reject even without -pedantic? I hope it will be active even without -pedantic Anyway, Daniel, it would be nice if you could add also SFINAE testcase too, because likely it's a different issue:[..] Yes, you are right, I was generalizing too early here. The actual test case was this one: templateclass T, class = decltype(sizeof(T)) auto f(int) - char; templateclass auto f(...) - char()[2]; static_assert(sizeof(fvoid(0)) != 1, ); // OK - Oops static_assert(sizeof(fvoid()(0)) != 1, ); // OK - Oops but Jason reported on the core reflector that this is already a very special situation that the core language needs to handle first. So lets take the SFINAE rumors away from this report.
[Bug c++/54161] sizeof(void) expressions are accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-08-02 20:34:52 UTC --- A SFINAE testcase that doesn't depend on core 1172 would be templateclass T, unsigned = sizeof(T) auto f(int) - char; templateclass auto f(...) - char()[2]; static_assert(sizeof(fvoid(0)) != 1, ); // OK - Oops static_assert(sizeof(fvoid()(0)) != 1, ); // OK - Oops which already works fine. I agree that we should get the pedwarn without -pedantic, but that seems to be all there is to this bug.
[Bug c++/54161] sizeof(void) expressions are accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-08-02
Ever Confirmed|0 |1
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-02
21:11:37 UTC ---
Ok, thanks. Thus this specific issue seems quite minor, because even without
-pedantic we warn anyway *by default* because warn_pointer_arith is enabled by
default (ie, -Wall -pedantic are not needed).
(-pedantic-errors can always be used to have hard errors, of course)
In summary, I understand we want something like this (untested):
Index: c-common.c
===
--- c-common.c(revision 190092)
+++ c-common.c(working copy)
@@ -4578,10 +4578,17 @@ c_sizeof_or_alignof_type (location_t loc,
{
if (is_sizeof)
{
- if (complain (pedantic || warn_pointer_arith))
-pedwarn (loc, pedantic ? OPT_Wpedantic : OPT_Wpointer_arith,
- invalid application of %sizeof% to a function type);
- else if (!complain)
+ if (complain)
+{
+ if (c_dialect_cxx ())
+pedwarn (loc, 0, invalid application of %sizeof% to
+ a function type);
+ else if (pedantic || warn_pointer_arith)
+pedwarn (loc, pedantic ? OPT_Wpedantic : OPT_Wpointer_arith,
+ invalid application of %sizeof% to
+ a function type);
+}
+ else
return error_mark_node;
value = size_one_node;
}
@@ -4601,12 +4608,17 @@ c_sizeof_or_alignof_type (location_t loc,
}
else if (type_code == VOID_TYPE || type_code == ERROR_MARK)
{
- if (type_code == VOID_TYPE
- complain (pedantic || warn_pointer_arith))
-pedwarn (loc, pedantic ? OPT_Wpedantic : OPT_Wpointer_arith,
- invalid application of %qs to a void type, op_name);
+ if (complain type_code == VOID_TYPE)
+{
+ if (c_dialect_cxx ())
+pedwarn (loc, 0,
+ invalid application of %qs to a void type, op_name);
+ else if (pedantic || warn_pointer_arith)
+pedwarn (loc, pedantic ? OPT_Wpedantic : OPT_Wpointer_arith,
+ invalid application of %qs to a void type, op_name);
+}
else if (!complain)
-return error_mark_node;
+return error_mark_node;
value = size_one_node;
}
else if (!COMPLETE_TYPE_P (type)
[Bug target/51931] No support for MIPS16 long branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51931 --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-08-02 21:32:02 UTC --- Author: rsandifo Date: Thu Aug 2 21:31:57 2012 New Revision: 190104 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190104 Log: gcc/ PR target/51931 * config/mips/mips-protos.h (mips_strip_unspec_address): Declare. * config/mips/mips.c (mips_strip_unspec_address): Make extern. (mips16_rewrite_pool_constant): Make a copy of the pool constant before adding to a PC-relative table. (mips16_lay_out_constants): Add a SPLIT_P parameter. (mips16_load_branch_target, mips16_split_long_branches): New functions. (mips_reorg): Update call to mips16_lay_out_constants. Call mips16_split_long_branches. * config/mips/predicates.md (pc_or_label_operand): Delete. * config/mips/mips.md (length): Add a calculation for MIPS16 branches. Move the extended_mips16 handling further down. (*branch_equalitymode_mips16): Replace use pc_or_label_operand with explicit label_ref and pc. Follow the usual operand numbering. (*branch_equalitymode_mips16_inverted): New pattern. (*jump_mips16): Add length attribute. (indirect_jump_and_restore_mode): New pattern. (consttable_int): Call mips_strip_unspec_address on the operand. gcc/testsuite/ PR target/51931 * gcc.c-torture/compile/20001226-1.c: Remove nomips16 attribute. * g++.dg/opt/longbranch1.C: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips-protos.h trunk/gcc/config/mips/mips.c trunk/gcc/config/mips/mips.md trunk/gcc/config/mips/predicates.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/opt/longbranch1.C trunk/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
[Bug c/54162] New: Does not accept static global anonymous unions or structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54162
Bug #: 54162
Summary: Does not accept static global anonymous unions or
structs
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@joshtriplett.org
C1X, and numerous other compilers, support static anonymous unions or structs
at file scope. For example, the following code should work with a C1X
compiler:
static union {
unsigned x;
unsigned y;
};
int main(void)
{
x = 5;
return y;
}
However, GCC says:
test.c:4:1: warning: unnamed struct/union that defines no instances [enabled by
default]
test.c: In function ‘main’:
test.c:8:5: error: ‘x’ undeclared (first use in this function)
test.c:8:5: note: each undeclared identifier is reported only once for each
function it appears in
test.c:9:12: error: ‘y’ undeclared (first use in this function)
[Bug c/54162] Does not accept static global anonymous unions or structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54162 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-08-02 23:23:19 UTC --- On Thu, 2 Aug 2012, josh at joshtriplett dot org wrote: C1X, and numerous other compilers, support static anonymous unions or structs at file scope. For example, the following code should work with a C1X compiler: No it shouldn't. Anonymous structures and unions are *members* of a containing structure or union, not declarations outside such a context; see C11 6.7.2.1 paragraph 13. The constraint in 6.7 paragraph 2 applies: A declaration other than a static_assert declaration shall declare at least a declarator (other than the parameters of a function or the members of a structure or union), a tag, or the members of an enumeration.. Your union declares none of those.
[Bug c++/54158] [4.6, 4.7, 4.8 Regression] Silently accepts sizeof to non-static member without object in C++03 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54158 --- Comment #5 from Ai Azuma ai.azuma at gmail dot com 2012-08-03 02:05:45 UTC --- Well, I'm a bit confused. So I would like to make sure some points. Ah, it was changed by a DR (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613) not a C++11 proposal, so supporting it in C++03 mode is probably intentional. The proposed resolution for DRs on 03's wording with Status: CD1 is not considered as a part of C++11, right? And GCC's `-std=c++03' intentionally includes such proposed resolutions, right?
[Bug target/54087] __atomic_fetch_add does not use xadd instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087 --- Comment #6 from Ulrich Drepper drepper.fsp at gmail dot com 2012-08-03 02:16:57 UTC --- (In reply to comment #5) This patch introduces atomic_fetch_submode: Seems to work nicely.
