bug report : -save-temps and stdin
using a very recent : gcc version 4.8.0 20121021 (experimental) (GCC) h4ck3rm1k3@gcc10:~/experiments/build/glibc$ echo int x; | g++ -save-temps -x c - cc1: error: unrecognized command line option ‘-.i’ this causes problems compiling glibc with -save-temps. is this known? should I report a bug? any ideas on fixing it, I might be able to do so, it should be simple. mike -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com Contributor FOSM, the CC-BY-SA map of the world http://fosm.org Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3 Free Software Foundation Europe Fellow http://fsfe.org/support/?h4ck3rm1k3
Re: AIX trunk build fail #3
Does the group / team have an AIX 6.1 build machine to build the trunk on? Or am I the first to person walk into this? I'm still curious in the question above And I'm still curious :-) I opened this bug report: http://gcc.gnu.org/bugzilla/post_bug.cgi I finally got trunk to build. pedz
Re: AIX trunk build fail #3
On 28 October 2012 13:39, Perry Smith wrote: I opened this bug report: http://gcc.gnu.org/bugzilla/post_bug.cgi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55105
Re: AIX trunk build fail #3 (edited)
Does the group / team have an AIX 6.1 build machine to build the trunk on? Or am I the first to person walk into this? I'm still curious in the question above And I'm still curious :-) I opened this bug report:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55105 I finally got trunk to build. pedz
Re: bug report : -save-temps and stdin
On Sun, 28 Oct 2012, Mike Dupont wrote: is this known? should I report a bug? any ideas on fixing it, I might be able to do so, it should be simple. I think the fix should be to give an early error message for compiling from stdin with -save-temps, and then stop the compilation because there's nowhere to save the intermediate files (given the lack of an input file name). -- Joseph S. Myers jos...@codesourcery.com
gcc-4.8-20121028 is now available
Snapshot gcc-4.8-20121028 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20121028/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 192898 You'll find: gcc-4.8-20121028.tar.bz2 Complete GCC MD5=382e01eb27e2d0221a1ce9278c4a9456 SHA1=4396cf293072185e3535c986f6a704410a426a54 Diffs from 4.8-20121021 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug c/55084] please submit full bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55084 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-28 07:51:55 UTC --- Closing.
[Bug middle-end/55103] New: [4.8 Regression] gcc.target/mips/int-moves-2.c ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55103
Bug #: 55103
Summary: [4.8 Regression] gcc.target/mips/int-moves-2.c ICEs
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Target: mips*-linux-gnu
./cc1
/home/apinski/src/gcc-fsf/local/gcc/gcc/testsuite/gcc.target/mips/int-moves-2.c
-quiet -DNOMIPS16= -DMIPS16=__attribute__((mips16)) -mgp64 -mabi=o64
/home/apinski/src/gcc-fsf/local/gcc/gcc/testsuite/gcc.target/mips/int-moves-2.c:27:1:
internal compiler error: Bus error
{
^
0x105164f7 crash_signal
/home/apinski/src/gcc-fsf/local/gcc/gcc/toplev.c:333
0x103f9191 init_op_alt_data
/home/apinski/src/gcc-fsf/local/gcc/gcc/lra.c:575
0x103f9191 lra_init()
/home/apinski/src/gcc-fsf/local/gcc/gcc/lra.c:2389
0x1051639b lang_dependent_init_target
/home/apinski/src/gcc-fsf/local/gcc/gcc/toplev.c:1673
0x108aa893 save_target_globals()
/home/apinski/src/gcc-fsf/local/gcc/gcc/target-globals.c:89
0x10776987 mips_set_mips16_mode
/home/apinski/src/gcc-fsf/local/gcc/gcc/config/mips/mips.c:16350
0x100bec4b store_parm_decls()
/home/apinski/src/gcc-fsf/local/gcc/gcc/c/c-decl.c:8306
0x10109557 c_parser_declaration_or_fndef
/home/apinski/src/gcc-fsf/local/gcc/gcc/c/c-parser.c:1755
0x1010e1c3 c_parser_translation_unit
/home/apinski/src/gcc-fsf/local/gcc/gcc/c/c-parser.c:1251
0x1010e1c3 c_parse_file()
/home/apinski/src/gcc-fsf/local/gcc/gcc/c/c-parser.c:10889
0x1015356f c_common_parse_file()
/home/apinski/src/gcc-fsf/local/gcc/gcc/c-family/c-opts.c:1062
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/55103] [4.8 Regression] gcc.target/mips/int-moves-2.c ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55103 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/52956] Missing overflow warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52956 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-28 09:31:27 UTC --- Dup. *** This bug has been marked as a duplicate of bug 55095 ***
[Bug c++/55095] Wshift-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||xinliangli at gmail dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-28 09:31:27 UTC --- *** Bug 52956 has been marked as a duplicate of this bug. ***
[Bug middle-end/55103] [4.8 Regression] gcc.target/mips/int-moves-2.c ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55103 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-28 09:32:06 UTC --- This is because save_target_globals does not allocate a target_lra_int (though it might be zero out the array before doing anything else too).
[Bug middle-end/55103] [4.8 Regression] All MIPS16 attribute tests ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55103 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8 Regression]|[4.8 Regression] All MIPS16 |gcc.target/mips/int-moves-2 |attribute tests ICEs |.c ICEs | --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-28 09:49:42 UTC --- It is not just int-moves-2.c but all of the tests of the mips16 attribute.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #30 from Jan Hubicka hubicka at gcc dot gnu.org 2012-10-28 10:08:23 UTC --- Created attachment 28543 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28543 Updated patch Hi, this is updated patch I am testing. It fixes the big speedup test and also changes badness metric completely to be based on expected speedup of the caller. It seems to work pretty well in my test with the catch that I still can't beat 4.6 on tramp3d.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #31 from Jan Hubicka hubicka at gcc dot gnu.org 2012-10-28 10:11:13 UTC --- Concerning vincenzo's request about 4.7 version, it won't work - it depends on improvements of inline metric and ipa-prop we made for 4.8
[Bug c++/54526] [C++11] :: is incorrectly treated as digraph : followed by colon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-28 10:59:50 UTC --- You are right, sorry. I have a lexer patch in testing which I will be sending shortly.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortr ||an/2012-10/msg00061.html CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #26 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-10-28 11:11:19 UTC --- The patch has been posted some time ago, with an OK for trunk.. http://gcc.gnu.org/ml/fortran/2012-10/msg00067.html Maybe it is a good time to commit before the next stage starts ?
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #27 from Tobias Schlüter tobi at gcc dot gnu.org 2012-10-28 11:15:24 UTC --- There were concerns about error handling in out-of-memory conditions which I addressed in a separate patch http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01470.html. This patch got no reply so far. May plan was to submit the non-C++ patch if the patch for C++ error handling is not approved during stage 1.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #32 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-10-28 11:27:22 UTC --- In a small test (that I will eventually publish here) the new patch at -O2 looks superior to 4.7.2 at O3. I would like to build a test with multiple source files where lto matters though. We will also try to build our whole software stack with 4.8 (we have a production version with 4.7.2 at this point, so we can move to experimenting builds with 4.8…)
[Bug rtl-optimization/39607] [4.5 Regression] Revision 145309 caused ICE in emit_swap_insn, at reg-stack.c:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39607
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||steven at gcc dot gnu.org
Resolution|FIXED |
--- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2012-10-28
11:41:45 UTC ---
Open again since r192440.
The real problem here is this assert:
if (hard_regno == -1)
{
/* Something failed if the register wasn't on the stack. If we had
malformed asms, we zapped the instruction itself, but that didn't
produce the same pattern of register sets as before. To prevent
further failure, adjust REGSTACK to include REG at TOP. */
gcc_assert (any_malformed_asm);
regstack-reg[++regstack-top] = REGNO (reg);
return;
}
If IRA uses DF_LIVE, the assert may trigger if there is a use of a stack
register that is not initialized. The following C test case (derived from
gfortran.dg/pr40587.f) shows the problem:
void
test (int *i, double *r, double *result)
{
int i2;
double r2;
i2 = *i;
if (i == 0)
r2 = *r;
else
error ();
*result = r2;
}
r2 is used uninitialized if the path through error() is taken. When
using DF_LR, r2 is made live through that path all the way up to the
function entry, but when using DF_LIVE r2 is only live in the trace
from r2 = *r to *result = r2.
With IRA using DF_LIVE and removing the assert, the result is an fstpl
instruction that triggers an FP-stack underflow. IMHO that would be
a reasonable behavior for this kind of problem.
[Bug middle-end/54961] [4.8 Regression] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54961 --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2012-10-28 11:44:50 UTC --- The problems of comment #4 and comment #5 are PR39607, a problem that should be solved in reg-stack. The problem of comment #0 is a problem in IRA. There is code to prevent stack registers from living across EDGE_ABNORMAL edges but clearly this code fails in the pr48757.f test case. I suspect there is a bug in the splitting or merging of allocno ranges where the ALLOCNO_NO_STACK_REG_P and ALLOCNO_TOTAL_NO_STACK_REG_P maybe are not properly copied/merged.
[Bug rtl-optimization/38711] ira should not be using df-lr except at -O1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38711 --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-10-28 11:52:16 UTC --- Author: steven Date: Sun Oct 28 11:52:11 2012 New Revision: 192890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192890 Log: PR rtl-optimization/38711 * ira.c (ira): Remove DF_LIVE if the problem is in the stack. (do_reload): Add it back at the end for -O2 and higher. * function.c (thread_prologue_and_epilogue_insns): Use REG_SET_TO_HARD_REG_SET instead of CLEAR_HARD_REG_SET and reg_set_to_hard_reg_set. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/ira.c
[Bug rtl-optimization/38711] ira should not be using df-lr except at -O1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38711 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-10-28 11:53:01 UTC --- Much of GCC is still not ready for this.
[Bug rtl-optimization/39607] [4.5 Regression] Revision 145309 caused ICE in emit_swap_insn, at reg-stack.c:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39607 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|SUSPENDED --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-10-28 11:53:53 UTC --- Depends on IRA using DF_LIVE. To be visited later.
[Bug middle-end/54961] [4.8 Regression] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54961 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2012-10-28 11:54:16 UTC --- Depends on IRA using DF_LIVE. To be visited later.
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-10-28 12:33:50 UTC --- I cannot reproduce this problem, neither before nor after r192890. Can you please attach the .ira dump (with -fdump-rtl-ira-all) after r192890, with and without the following patch applied? Index: ira.c === --- ira.c (revision 192893) +++ ira.c (working copy) @@ -4405,9 +4405,11 @@ interpretation of the DF_LR problem. See PR38711. Remove the problem, so that we don't spend time updating it in any of the df_analyze() calls during IRA/LRA. */ +#if 0 if (optimize 1) df_remove_problem (df_live); gcc_checking_assert (df_live == NULL); +#endif #ifdef ENABLE_CHECKING df-changeable_flags |= DF_VERIFY_SCHEDULED;
[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-28
12:54:01 UTC ---
I think the reason this doesn't show up everywhere is due to a problem with
older versions of GDB. Using GDB 7.3.50.20110722-16.fc16 I get this in the
test logs:
48362.gdb:5: Error in sourced command file:^M
No symbol t1 in current context.^M
skipping: 48362.gdb:5: Error in sourced command file:^M
skipping: No symbol t1 in current context.^M
UNSUPPORTED: libstdc++-prettyprinters/48362.cc
and I've had the same problem running gdb myself, with gdb saying No symbol x
in current context for all local variables, when they clearly do exist!
I also see GDB 7.3 completely confused about the type of std::string:
Temporary breakpoint 1, main () at d.cc:6
6 std::string s1 = string 1;
(gdb) n
7 std::string s2 = string 2;
(gdb) p s1
$1 = {i = {1431655765, -1077586603}, x = -0.1}
(gdb) ptype s1
type = const union {
int4 i[2];
double x;
}
Huh?!
Using GDB from the git mirror or upgrading to rawhide's 7.5.0.20120926-25.fc18
makes the problem go away and now I see the FAILs when running
libstdc++-prettyprinters.exp (which I'm fixing now)
This only happens for code built with trunk, so there seems to be some problem
with trunk and GDB 7.3 - any ideas?
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Comment #18 from Segher Boessenkool segher at gcc dot gnu.org 2012-10-28 13:15:14 UTC --- Not a GCC bug; fixed in binutils (will be in 2.24).
[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-28 13:20:38 UTC --- Author: redi Date: Sun Oct 28 13:20:31 2012 New Revision: 192894 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192894 Log: PR libstdc++/55041 * python/libstdcxx/v6/printers.py (Tr1UnorderedMapPrinter): Update to handle hashtable as member of unordered_map not base class. (Tr1UnorderedSetPrinter): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-28
13:27:20 UTC ---
The shared_ptr tests fail because GDB is getting the variable's type wrong,
seeing it as the base class not the correct type:
(gdb) p sp1
$1 = {std::__shared_ptrint, (__gnu_cxx::_Lock_policy)2 = {_M_ptr =
0x12345678, _M_refcount = {_M_pi = 0x604010}}, No data fields}
(gdb) p wp1
$2 = {std::__weak_ptrint, (__gnu_cxx::_Lock_policy)2 = {_M_ptr =
0x12344321, _M_refcount = {_M_pi = 0x604040}}, No data fields}
(gdb) p wp2
$3 = {std::__weak_ptrint, (__gnu_cxx::_Lock_policy)2 = {_M_ptr =
0x56788765, _M_refcount = {_M_pi = 0x604070}}, No data fields}
(gdb) p/r wp2
$4 = {std::__weak_ptrint, (__gnu_cxx::_Lock_policy)2 = {_M_ptr =
0x56788765, _M_refcount = {_M_pi = 0x604070}}, No data fields}
(gdb) p/r sp1
$5 = {std::__shared_ptrint, (__gnu_cxx::_Lock_policy)2 = {_M_ptr =
0x12345678, _M_refcount = {_M_pi = 0x604010}}, No data fields}
This doesn't look like a libstdc++ problem.
[Bug c++/55104] New: ice in inline_call, at ipa-inline-transform.c:269
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104 Bug #: 55104 Summary: ice in inline_call, at ipa-inline-transform.c:269 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 28544 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28544 gzipped C++ source code I just tried to compile the package openbabel-2.3.1-6 on gcc-4.8 trunk dated 20121027 on an AMD x86_64 box. The compiler said /home/dcb/rpmbuild/BUILD/openbabel-2.3.1/src/mol.cpp:4233:1: internal compiler error: in inline_call, at ipa-inline-transform.c:269 } // end namespace OpenBabel ^ 0xe8e22b inline_call(cgraph_edge*, bool, vec_tcgraph_edge***, int*, bool) ../../src/trunk/gcc/ipa-inline-transform.c:265 0xe8d214 inline_small_functions ../../src/trunk/gcc/ipa-inline.c:1524 0xe8d214 ipa_inline ../../src/trunk/gcc/ipa-inline.c:1706 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug c/55105] New: use of LD_LIBRARY_PATH incorrect for AIX -- cause trunk build to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55105
Bug #: 55105
Summary: use of LD_LIBRARY_PATH incorrect for AIX -- cause
trunk build to fail
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pedz...@gmail.com
configure.ac has this:
# Decide which environment variable is used to find dynamic libraries.
case ${host} in
*-*-hpux*) RPATH_ENVVAR=SHLIB_PATH ;;
*-*-darwin*) RPATH_ENVVAR=DYLD_LIBRARY_PATH ;;
*-*-mingw* | *-*-cygwin ) RPATH_ENVVAR=PATH ;;
*) RPATH_ENVVAR=LD_LIBRARY_PATH ;;
esac
Starting with AIX 6.1, LD_LIBRARY_PATH is used. I don't 100% understand the
intent of the code above. The environment variable mentioned (e.g.
LD_LIBRARY_PATH) is passed via the environment when (e.g.) libatomic is built.
With LD_LIBRARY_PATH in the environment, xgcc and cc1 no longer execute
properly because at the time they execute, LD_LIBRARY_PATH points to the bit
version being built -- not the bit version that xgcc was built for. There is a
longer description here: http://gcc.gnu.org/ml/gcc/2012-10/msg00386.html
I changed it to this:
# Decide which environment variable is used to find dynamic libraries.
case ${host} in
*-*-aix*) RPATH_ENVVAR=BOGUS ;;
*-*-hpux*) RPATH_ENVVAR=SHLIB_PATH ;;
*-*-darwin*) RPATH_ENVVAR=DYLD_LIBRARY_PATH ;;
*-*-mingw* | *-*-cygwin ) RPATH_ENVVAR=PATH ;;
*) RPATH_ENVVAR=LD_LIBRARY_PATH ;;
esac
In theory, it should be LIBPATH but I'm sure that will cause the build to
fail as well. In essence, the logic needs to be reviewed. Perhaps other
platforms are different in their use of LD_LIBRARY_PATH / LIBPATH than AIX.
[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-28
13:37:31 UTC ---
Sorry, I misread that output, it does know the right type, it just doesn't
match the printer for some reason
(gdb) ptype sp1
type = class std::shared_ptrint : public std::__shared_ptrint,
(__gnu_cxx::_Lock_policy)2 {
public:
void shared_ptr(void);
void shared_ptr(const std::shared_ptrint );
void shared_ptr(unknown type in /dev/shm/a.out, CU 0x0, DIE 0x127f);
void shared_ptr(std::nullptr_t);
std::shared_ptrint operator=(const std::shared_ptrint );
std::shared_ptrint operator=(unknown type in /dev/shm/a.out, CU 0x0,
DIE 0x12e3);
void shared_ptrint, deleter(int *, deleter);
}
(I'll file a separate bug about the unknown type error for the shared_ptr
type)
[Bug debug/54773] no debug info generated for rvalue reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54773
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-28
13:53:11 UTC ---
This seems to be fixed on trunk, but GDB can't handle it:
struct X {
X operator=(X) { return *this; }
};
int main()
{
X x;
x = X();
}
15e: Abbrev Number: 8 (DW_TAG_rvalue_reference_type)
5f DW_AT_byte_size : 8
60 DW_AT_type: 0x29
Temporary breakpoint 1, main () at rv.cc:8
8 x = X();
(gdb) ptype x
type = struct X {
public:
X operator=(unknown type in /dev/shm/a.out, CU 0x0, DIE 0x4b);
}
Jason, can this be closed as fixed?
[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-28 13:57:00 UTC --- (In reply to comment #9) (I'll file a separate bug about the unknown type error for the shared_ptr type) That's http://sourceware.org/PR14441
[Bug c++/55106] New: ice: Maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55106 Bug #: 55106 Summary: ice: Maximum number of LRA constraint passes is achieved (15) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 28545 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28545 C++ source code I just tried to compile the package verilator-3.805-5 on gcc-4.8 trunk dated 20121027 on an AMD x86_64 box. The compiler said ../V3Number.cpp:1286:1: internal compiler error: Maximum number of LRA constraint passes is achieved (15) } ^ 0x994c28 lra_constraints(bool) ../../src/trunk/gcc/lra-constraints.c:3262 0x9882fe lra(_IO_FILE*) ../../src/trunk/gcc/lra.c:2281 0x9507a6 do_reload ../../src/trunk/gcc/ira.c:4614 0x9507a6 rest_of_handle_reload ../../src/trunk/gcc/ira.c:4720 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug tree-optimization/55107] New: GCC in an infinite loop at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107
Bug #: 55107
Summary: GCC in an infinite loop at -O2
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Hello !
GCC 4.8.0 as of 20121021 and GCC 4.7.2 won't compile the following testcase at
-O2 and higher because they look stuck in an infinite loop.
$ cat infinite.c
#include stdint.h
uint16_t a, b;
uint16_t f(void)
{
int c, **p;
short d = 2, e = 4;
for (;; b++)
{
int *j, k = 0;
for (; *j; j++)
{
for(; c; c++)
for(; k 1; k++)
{
short *f = d;
if(b)
return *f;
}
}
if(!c)
d *= e;
((a = d) ? b = 0 : (**p ? : 1) != (d != 1 ? : (a = 0))) != (k ? a : 0)
(a *= c = k) (**p = 0);
}
}
$ ulimite -t 60
$ xgcc -O2 -w infinite.c
cc: internal compiler error: CPU time limit exceeded (program cc1)
linux-vdso.so.1: No such file or directory
0x40b937 execute
../../srcdir/gcc/gcc.c:2739
0x40c7be do_spec_1
../../srcdir/gcc/gcc.c:4534
0x40f0d5 process_brace_body
../../srcdir/gcc/gcc.c:5782
0x40f0d5 handle_braces
../../srcdir/gcc/gcc.c:5696
0x40d397 do_spec_1
../../srcdir/gcc/gcc.c:5179
0x40f0d5 process_brace_body
../../srcdir/gcc/gcc.c:5782
0x40f0d5 handle_braces
../../srcdir/gcc/gcc.c:5696
0x40d397 do_spec_1
../../srcdir/gcc/gcc.c:5179
0x40cff7 do_spec_1
../../srcdir/gcc/gcc.c:5284
0x40f0d5 process_brace_body
../../srcdir/gcc/gcc.c:5782
0x40f0d5 handle_braces
../../srcdir/gcc/gcc.c:5696
0x40d397 do_spec_1
../../srcdir/gcc/gcc.c:5179
0x40f0d5 process_brace_body
../../srcdir/gcc/gcc.c:5782
0x40f0d5 handle_braces
../../srcdir/gcc/gcc.c:5696
0x40d397 do_spec_1
../../srcdir/gcc/gcc.c:5179
0x40f0d5 process_brace_body
../../srcdir/gcc/gcc.c:5782
0x40f0d5 handle_braces
../../srcdir/gcc/gcc.c:5696
0x40d397 do_spec_1
../../srcdir/gcc/gcc.c:5179
0x40f0d5 process_brace_body
../../srcdir/gcc/gcc.c:5782
0x40f0d5 handle_braces
../../srcdir/gcc/gcc.c:5696
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Note that the stack trace looks the same as in PR55011.
[Bug rtl-optimization/55106] ice: Maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55106
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de, vmakarov at gcc dot
||gnu.org
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-10-28 14:52:03 UTC ---
markus@x4 tmp % cat test.ii
templatetypename _Tp struct A {
typedef _Tp *pointer;
typedef _Tp reference;
typedef _Tp const_reference;
templatetypenamestruct rebind
{
typedef A other;
};
};
templatetypename _Allocstruct __alloc_traits
{
typedef typename _Alloc::pointer pointer;
typedef typename _Alloc::reference reference;
typedef typename _Alloc::const_reference const_reference;
templatetypename _Tpstruct rebind
{
typedef typename _Alloc::template rebind_Tp::other other;
};
};
templatetypename _Tp, typename _Allocstruct B
{
typedef typename __alloc_traits_Alloc::template rebind
_Tp::other _Tp_alloc_type;
typedef typename __alloc_traits_Tp_alloc_type::pointer pointer;
struct F
{
pointer _M_start;
};
F _M_impl;
};
templatetypename _Tp, typename _Alloc = A_Tp class vec : B_Tp, _Alloc{
typedef B_Tp, _Alloc _Base;
typedef typename _Base::_Tp_alloc_type _Tp_alloc_type;
typedef __alloc_traits_Tp_alloc_type _Alloc_traits;
public:
typedef _Tp value_type;
typedef typename _Alloc_traits::reference reference;
typedef typename _Alloc_traits::const_reference const_reference;
reference operator[](int p1)
{
return *(this-_M_impl._M_start + p1);
}
const_reference operator[](long) const;
};
int a[17];
class C {
vecint m_value;
void opModDivGuts(const C);
int mostSetBitP1() const;
};
void C::opModDivGuts(const C p1)
{
int b = p1.mostSetBitP1(), c = b + 1;
int d[16];
for (int i = c; i; i--)
a[i] = p1.m_value[i] b;
for (int i = 0; i c; i++)
m_value[i] = d[i] b -b;
}
markus@x4 tmp % g++ -Wall -Wextra -c -O3 test.ii
test.ii: In member function ‘void C::opModDivGuts(const C)’:
test.ii:65:1: internal compiler error: Maximum number of LRA constraint passes
is achieved (15)
[Bug target/54996] gcc with --target=avr fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54996 --- Comment #2 from lvd.mhm at gmail dot com 2012-10-28 15:25:28 UTC --- I was wrong not setting $PATH to just compiled binutils. However, even after setting correct $PATH or just compiling binutils to default /usr/local/bin, problem still persisted. I used clean x86_64 virtual machine with fresh ubuntu12.04.1 server install with just nothing installed except SSH and then packages needed to build binutils and gcc, and I've found, that bug exists when $PATH has ./ at first place. If there is no ./ in $PATH or ./ at the end, gcc compiles fine. Of course then same behavior repeats itself on hardware.
[Bug target/54996] gcc with --target=avr fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54996 lvd.mhm at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #3 from lvd.mhm at gmail dot com 2012-10-28 15:27:04 UTC --- up
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2012-10-28 15:30:37 UTC --- What exactly did you test? The bug is clearly present before r192890. Here is the diff between r192889 and r192890: @@ -1663,16 +1663,17 @@ _Z6test01v: .cfi_startproc .cfi_personality 0,__gxx_personality_v0 .cfi_lsda 0,.LLSDA2633 -link.w %fp,#-68 +link.w %fp,#-72 .cfi_offset 14, -8 .cfi_def_cfa 14, 8 movem.l #12348,-(%sp) -.cfi_offset 2, -100 -.cfi_offset 3, -96 -.cfi_offset 10, -92 -.cfi_offset 11, -88 -.cfi_offset 12, -84 -.cfi_offset 13, -80 +.cfi_offset 2, -104 +.cfi_offset 3, -100 +.cfi_offset 10, -96 +.cfi_offset 11, -92 +.cfi_offset 12, -88 +.cfi_offset 13, -84 +lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5 clr.l -48(%fp) clr.l -44(%fp) pea 104.w @@ -1791,22 +1792,22 @@ _Z6test01v: jsr _ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE .LEHE14: addq.l #8,%sp -move.l -16(%fp),%a5 -tst.l %a5 +move.l -16(%fp),%a1 +tst.l %a1 jeq .L329 -lea (4,%a5),%a0 +lea (4,%a1),%a0 move.l #_ZL28__gthrw___pthread_key_createPjPFvPvE,%d2 jeq .L323 move.l (%a0),%d0 .L324: -move.l %d0,%a1 +move.l %d0,%d3 move.l %d0,%d1 subq.l #1,%d1 cas.l %d0,%d1,(%a0) seq %d1 tst.b %d1 jeq .L324 -move.l %a1,%d0 +move.l %d3,%d0 moveq #1,%d1 cmp.l %d0,%d1 jeq .L446 @@ -1925,7 +1926,7 @@ _Z6test01v: cmp.l %a0,%d1 jeq .L450 .L309: -movem.l -92(%fp),#15372 +movem.l -96(%fp),#15372 unlk %fp rts .L351: @@ -2005,30 +2006,32 @@ _Z6test01v: sub.l %a0,%a0 jra .L321 .L446: -move.l (%a5),%a0 -move.l %a5,-(%sp) +move.l (%a1),%a0 +move.l %a1,-(%sp) move.l 8(%a0),%a0 +move.l %a1,-72(%fp) jsr (%a0) -lea (8,%a5),%a0 +move.l -72(%fp),%a1 +lea (8,%a1),%a0 addq.l #4,%sp tst.l %d2 jeq .L326 move.l (%a0),%d0 .L327: -move.l %d0,%a1 +move.l %d0,%d2 move.l %d0,%d1 subq.l #1,%d1 cas.l %d0,%d1,(%a0) seq %d1 tst.b %d1 jeq .L327 -move.l %a1,%d0 +move.l %d2,%d0 moveq #1,%d1 cmp.l %d0,%d1 jne .L329 .L452: -move.l (%a5),%a0 -move.l %a5,-(%sp) +move.l (%a1),%a0 +move.l %a1,-(%sp) move.l 12(%a0),%a0 jsr (%a0) addq.l #4,%sp @@ -2056,7 +2059,7 @@ _Z6test01v: move.l 12(%a0),%a0 jsr (%a0) addq.l #4,%sp -movem.l -92(%fp),#15372 +movem.l -96(%fp),#15372 unlk %fp rts .L449: @@ -2147,19 +2150,19 @@ _Z6test01v: addq.l #1,4(%a2) jra .L312 .L323: -move.l 4(%a5),%d0 +move.l 4(%a1),%d0 move.l %d0,%d1 subq.l #1,%d1 -move.l %d1,4(%a5) +move.l %d1,4(%a1) moveq #1,%d1 cmp.l %d0,%d1 jne .L329 jra .L446 .L326: -move.l 8(%a5),%d0 +move.l 8(%a1),%d0 move.l %d0,%d1 subq.l #1,%d1 -move.l %d1,8(%a5) +move.l %d1,8(%a1) moveq #1,%d1 cmp.l %d0,%d1 jne .L329
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2012-10-28 15:36:55 UTC --- Created attachment 28546 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28546 wait.ii.203r.ira.r192889
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2012-10-28 15:38:09 UTC --- Created attachment 28547 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28547 wait.ii.203r.ira.r192890
[Bug c/55108] New: bad compile-time evaluation of members of initialized union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55108
Bug #: 55108
Summary: bad compile-time evaluation of members of initialized
union
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@cam.ac.uk
Created attachment 28548
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28548
internal file bad.i obtained using -save-temp, as requested.
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-8+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6
--with-fpu=vfp --with-float=hard --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-8+rpi1)
File bad.c contains
#include stdio.h
int main(int argc, char *argv[])
{
union
{ double d;
unsigned char c[8];
} u = {1.0/7.0};
printf(Bytes from float are %x %x %x %x\n,
u.c[0] 0xff, u.c[1] 0xff, u.c[2] 0xff, u.c[3] 0xff);
return 0;
}
My hope is that the aliasing is OK both because the float is aliased with chars
and because I believed that GCC was kind about unions.
The output is
acn1@raspberrypi ~ $ gcc -O0 bad.c -o bad0
acn1@raspberrypi ~ $ gcc -O1 bad.c -o bad1 -Wall -Wextra
bad.c: In function ‘main’:
bad.c:3:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
bad.c:3:26: warning: unused parameter ‘argv’ [-Wunused-parameter]
acn1@raspberrypi ~ $ ./bad0
Bytes from float are 92 24 49 92 expected output
acn1@raspberrypi ~ $ ./bad1
Bytes from float are 92 924924 9249 92output 0xff unexpected
acn1@raspberrypi ~ $
To my mind whatever else might be going on the 0xff that I have should not
let me get such large numbers displayed!
The .i file is attached. gcc is evaluating the components of the union at
compile time and not respecting the unsigned char width or the subseqent
0xff.
[Bug middle-end/54957] Two crashes introduced by rev192488
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54957 --- Comment #17 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-10-28 16:37:46 UTC --- (In reply to comment #8) Created attachment 28466 [details] Proposed patch Handle the possibility that stmt_bb may be NULL in emit_case_dispatch_table. Untested. It works for arc-elf32.
[Bug fortran/54958] Wrongly rejects ac-implied-DO variables which also occur with INTENT(IN)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54958 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-10-28 16:57:15 UTC --- Author: burnus Date: Sun Oct 28 16:57:12 2012 New Revision: 192896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192896 Log: 2012-10-28 Tobias Burnus bur...@net-b.de PR fortran/54958 * gfortran.h (gfc_resolve_iterator_expr, gfc_check_vardef_context): Update prototype. * expr.c (gfc_check_vardef_context): Add own_scope argument and honour it. * resolve.c (gfc_resolve_iterator_expr): Add own_scope argument and honour it. (resolve_deallocate_expr, resolve_allocate_expr, resolve_data_variables, resolve_transfer resolve_lock_unlock, resolve_code): Update calls. * array.c (resolve_array_list): Ditto. * check.c (gfc_check_atomic_def, gfc_check_atomic_ref): Ditto. * interface.c (compare_actual_formal): Ditto. * intrinsic.c (check_arglist): Ditto. * io.c (resolve_tag, gfc_resolve_dt, gfc_resolve_inquire): * Ditto. 2012-10-28 Tobias Burnus bur...@net-b.de PR fortran/54958 * gfortran.dg/do_check_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/do_check_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/io.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55109] New: internal compiler error: Segmentation fault while reporting error in template function instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55109
Bug #: 55109
Summary: internal compiler error: Segmentation fault while
reporting error in template function instantiation
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zetaetadan...@gmail.com
The compiler command was:
g++ -DHAVE_CONFIG_H -I.-O0 -g -std=c++11 -I src/ -Wall -Wextra -Werror
-Wno-error=unused-variable -Wno-error=unused-parameter
-Wno-error=unused-but-set-variable -MT mc___server-NetworkServer.o -MD -MP -MF
.deps/mc___server-NetworkServer.Tpo -c -o mc___server-NetworkServer.o `test -f
'src/network/NetworkServer.cpp' || echo './'`src/network/NetworkServer.cpp
The compiler output was (template stuff formatted for readability):
In file included from src/network/NetworkServer.cpp:22:0:
src/Scheduler.hpp: In instantiation of ‘typename std::enable_if
std::__and_
std::is_convertible
MemberFunc, std::function
decltype (MCServer::Scheduler::startThread::obj-
**MCServer::Scheduler::startThread::func(
MCServer::Scheduler::startThread::args ...
)
) (Args ...)
,
std::is_member_function_pointerMemberFunc
::value, long unsigned int
::type
MCServer::Scheduler::startImportantThread(MemberFunc, Class*, Args ...)
[with MemberFunc = void (MCServer::Network::NetworkServer::*)();
Class = MCServer::Network::NetworkServer;
Args = {};
typename std::enable_if
std::__and_
std::is_convertible
MemberFunc, std::function
decltype (MCServer::Scheduler::startThread::obj-
**MCServer::Scheduler::startThread::func(
MCServer::Scheduler::startThread::args ...
)
) (Args ...)
,
std::is_member_function_pointerMemberFunc
::value, long unsigned int
::type = long unsigned int]’:
src/network/NetworkServer.cpp:69:74: required from here
src/Scheduler.hpp:187:156: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions.
The backtrace of the segfault is:
#0 0x004e00e7 in ?? ()
#1 0x004e0464 in tsubst_copy_and_build ()
#2 0x004dbffa in ?? ()
#3 0x004e7ddf in ?? ()
#4 0x004e105b in tsubst_copy_and_build ()
#5 0x004dbffa in ?? ()
#6 0x004e28c0 in tsubst ()
#7 0x004e881c in ?? ()
#8 0x004e2ceb in tsubst ()
#9 0x004e5b13 in ?? ()
#10 0x004df422 in ?? ()
#11 0x004e2ec9 in tsubst ()
#12 0x004e0dac in tsubst_copy_and_build ()
#13 0x004e0ffe in tsubst_copy_and_build ()
#14 0x004dbffa in ?? ()
#15 0x004dcd0f in ?? ()
#16 0x004dcc4c in ?? ()
#17 0x004dc118 in ?? ()
#18 0x004f0da3 in instantiate_decl ()
#19 0x004f37ac in instantiate_pending_templates ()
#20 0x0050979d in cp_write_global_declarations ()
#21 0x00831a58 in toplev_main ()
#22 0x75eca725 in __libc_start_main () from /usr/lib/libc.so.6
#23 0x004abaf1 in _start ()
which is of course very incomplete, and I am currently compiling gcc with debug
symbols to get a better backtrace, but it will take some time.
The preprocessed source of the file being compiled is here:
http://www.mediafire.com/?hdv6qddwnwclj82
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-10-28 17:24:17 UTC --- (In reply to comment #2) What exactly did you test? The bug is clearly present before r192890. I was testing a cross from powerpc64-unknown-linux-gnu to m68k-linux-gnu, your wait.ii test case, with -fPIC -O2 -std=gnu++0x. Perhaps I somehow messed up, I'll try again.
[Bug tree-optimization/55110] New: Internal compiler error in vectorizable_reduction, at tree-vect-loop.c:4633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55110
Bug #: 55110
Summary: Internal compiler error in vectorizable_reduction, at
tree-vect-loop.c:4633
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Hello !
The following testcase makes GCC 4.8.0 as of 20121021 crash with -O1
-ftree-vectorize.
$ cat vector.c
int a, b, c;
void f(void)
{
for(; b; b++)
for(c = 0; c 2; c++)
a /= 5;
}
$ xgcc -O1 -ftree-vectorize -w vector.c
vector.c: In function ‘f’:
vector.c:3:6: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:4633
void f(void)
^
linux-vdso.so.1: No such file or directory
0xa67b9c vectorizable_reduction(gimple_statement_d*, gimple_stmt_iterator*,
gimple_statement_d**, _slp_tree*)
../../srcdir/gcc/tree-vect-loop.c:4633
0xa58fa0 vect_analyze_stmt(gimple_statement_d*, bool*, _slp_tree*)
../../srcdir/gcc/tree-vect-stmts.c:5710
0xa58aca vect_analyze_stmt(gimple_statement_d*, bool*, _slp_tree*)
../../srcdir/gcc/tree-vect-stmts.c:5632
0xa6356d vect_analyze_loop_operations
../../srcdir/gcc/tree-vect-loop.c:1447
0xa6356d vect_analyze_loop_2
../../srcdir/gcc/tree-vect-loop.c:1725
0xa6356d vect_analyze_loop(loop*)
../../srcdir/gcc/tree-vect-loop.c:1778
0xa75f1c vectorize_loops()
../../srcdir/gcc/tree-vectorizer.c:114
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/55109] internal compiler error: Segmentation fault while reporting error in template function instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55109 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-28 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-28 17:55:32 UTC --- Please reduce the testcase as much as possible - there are many tools which you can use for that, delta, creduce - and attach here what you get.
[Bug c++/55095] Wshift-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-10-28 17:58:55 UTC --- The constant folder (fold-const.c:int_const_binop_1) would seem to be the place where overflow information would most readily be available for this: as I understand it, it's specifically about constants, rather than the generic issue that almost any left shift with nonconstant operands might overflow. If diagnosing there, you'd want to pass down a location a few levels from fold_binary_loc (so changing lots of calls to const_binop to pass a location). (In any case, double-int will need a new interface to report whether shift overflow has occurred.)
[Bug c++/55077] implement and enable by default -Wliteral-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55077 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-10-28 18:02:07 UTC --- On Sat, 27 Oct 2012, manu at gcc dot gnu.org wrote: // Expressions, such as those that indicate rounding-down, should NOT produce warnings. int x = 24 * 0.5; int y = (24*60*60) * 0.25; int pennies = 123.45 * 100; The last of those seems pretty suspicious (123.45 isn't an exact floating-point value, but the user probably wants 12345 independent of whether the floating-point value is above or below the exact decimal value). Are you *sure* you don't want a warning in such a case?
[Bug target/51106] [4.6 Regression] ICE in move_insn, at haifa-sched.c:2314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106 --- Comment #21 from Andrey Belevantsev abel at gcc dot gnu.org 2012-10-28 18:17:16 UTC --- (In reply to comment #20) This issue still exists in mainline, there seems to be no objection to Andrey's suggested fix, could someone please commit it? Not quite, the last message was http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00161.html and then there was no consensus about the way to proceed.
[Bug fortran/54958] Wrongly rejects ac-implied-DO variables which also occur with INTENT(IN)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54958 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-10-28 18:25:19 UTC --- FIXED on the 4.8 trunk.
[Bug c++/55095] Wshift-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-28 18:34:43 UTC --- (In reply to comment #4) The constant folder (fold-const.c:int_const_binop_1) would seem to be the place where overflow information would most readily be available for this: as I understand it, it's specifically about constants, rather than the generic issue that almost any left shift with nonconstant operands might overflow. If diagnosing there, you'd want to pass down a location a few levels from fold_binary_loc (so changing lots of calls to const_binop to pass a location). (In any case, double-int will need a new interface to report whether shift overflow has occurred.) Is there some interface that I can directly call to perform the shift in the largest available precision (or infinite precision if that is possible) and then convert the result to the result type and compare the two values? That seems much more straight-forward than going through fold-const. And it allows to report what the result would have been and how much precision would be needed for it, like clang does.
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 --- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2012-10-28 18:34:52 UTC --- I didn't write anything about -fPIC. The PIC register is used for TLS accesses.
[Bug tree-optimization/55111] New: ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:89
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55111
Bug #: 55111
Summary: ICE: tree check: expected ssa_name, have integer_cst
in live_on_edge, at tree-vrp.c:89
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
With GCC 4.8.0 as of 20121021, at -O2 and higher :
$ cat ssa.c
int a, b, c;
long d;
unsigned long *e;
int f(void)
{
for(;; a++)
{
if(c)
{
for(b = d = 0; b 1; b++)
e = d;
--*e;
if(d 0)
a = 0;
return d;
}
}
}
$ xgcc -O2 -w ssa.c
ssa.c: In function ‘f’:
ssa.c:5:5: internal compiler error: tree check: expected ssa_name, have
integer_cst in live_on_edge, at tree-vrp.c:89
int f(void)
^
linux-vdso.so.1: No such file or directory
0xa90b9a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../srcdir/gcc/tree.c:8896
0xa7650d tree_check
../../srcdir/gcc/tree.h:3676
0xa7650d live_on_edge
../../srcdir/gcc/tree-vrp.c:89
0xa7ce9a register_edge_assert_for_2
../../srcdir/gcc/tree-vrp.c:4736
0xa7e4e0 register_edge_assert_for
../../srcdir/gcc/tree-vrp.c:5216
0xa81734 find_conditional_asserts
../../srcdir/gcc/tree-vrp.c:5304
0xa81734 find_assert_locations_1
../../srcdir/gcc/tree-vrp.c:5518
0xa88136 find_assert_locations
../../srcdir/gcc/tree-vrp.c:5658
0xa88136 insert_range_assertions
../../srcdir/gcc/tree-vrp.c:5846
0xa88136 execute_vrp
../../srcdir/gcc/tree-vrp.c:9156
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/52724] Internal read with character(kind=4) data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52724 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-10-28 20:51:37 UTC --- Fixed on trunk, closing.
[Bug target/49263] SH Target: underutilized TST #imm, R0 instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #19 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-28 22:01:47 UTC --- Another thing I've noticed... Cases such as: mov.l r0,@r2! LS mov r13,r0! MT and #7,r0 ! EX tst r0,r0 ! MT bt/s.L8 ! BR mov.l r0,@(16,r1) where the result of the and op is re-used would be slightly better as: mov.l r0,@r2 ! LS mov r13,r0 ! MT tst #7,r0! MT and #7,r0! EX bt/s.L8 ! BR mov.l r0,@(16,r1) because it reduces dependency on the result of the and op and thus has a higher chance to be executed in parallel.
[Bug lto/55112] New: internal compiler error: in simplify_subreg, at simplify-rtx.c:5424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55112 Bug #: 55112 Summary: internal compiler error: in simplify_subreg, at simplify-rtx.c:5424 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: patr...@motec.com.au Using cross compile gcc (x86_64-powerpc-eabispe) the following command line results in an internal compiler error. I've attached the problem object file. Hope this is enough information, thanks. patrick@gtr:~/bug/report1$ powerpc-eabispe-gcc -v -Os -flto=jobserver -nostdlib -o test bug.o Using built-in specs. COLLECT_GCC=powerpc-eabispe-gcc COLLECT_LTO_WRAPPER=/home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/lto-wrapper Target: powerpc-eabispe Configured with: /z/src/e7/toolchain/src/gcc-4.7.2/configure --prefix=/z/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c,c++ --with-sysroot=/z/src/e7/toolchain/../prex_sysroot --disable-nls --disable-werror --with-newlib --with-gmp=/z/src/e7/toolchain/stage2 --with-mpfr=/z/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp --with-cpu=8540 Thread model: single gcc version 4.7.2 (GCC) COMPILER_PATH=/home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/:/home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/:/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2/../../../../powerpc-eabispe/bin/ LIBRARY_PATH=/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2/:/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/:/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2/../../../../powerpc-eabispe/lib/ COLLECT_GCC_OPTIONS='-v' '-Os' '-flto=jobserver' '-nostdlib' '-o' 'test' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/collect2 -plugin /home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/liblto_plugin.so -plugin-opt=/home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/lto-wrapper -plugin-opt=-fresolution=/tmp/ccTv6kV7.res -flto=jobserver --sysroot=/z/src/e7/toolchain/../prex_sysroot --eh-frame-hdr -V -dn -Bstatic -o test -L/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2 -L/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc -L/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2/../../../../powerpc-eabispe/lib bug.o GNU ld (GNU Binutils) 2.22 Supported emulations: elf32ppc elf32ppclinux elf32ppcsim powerpc-eabispe-gcc @/tmp/ccu1YKNX.args Using built-in specs. COLLECT_GCC=powerpc-eabispe-gcc Target: powerpc-eabispe Configured with: /z/src/e7/toolchain/src/gcc-4.7.2/configure --prefix=/z/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c,c++ --with-sysroot=/z/src/e7/toolchain/../prex_sysroot --disable-nls --disable-werror --with-newlib --with-gmp=/z/src/e7/toolchain/stage2 --with-mpfr=/z/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp --with-cpu=8540 Thread model: single gcc version 4.7.2 (GCC) COLLECT_GCC_OPTIONS='-c' '-msdata=none' '-mno-spe' '-mcpu=8540' '-v' '-Os' '-nostdlib' '-mcpu=8540' '-dumpdir' './' '-dumpbase' 'test.wpa' '-fltrans-output-list=/tmp/cc4GjAt6.ltrans.out' '-fwpa' '-fresolution=/tmp/ccTv6kV7.res' /home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/../../libexec/gcc/powerpc-eabispe/4.7.2/lto1 -quiet -dumpdir ./ -dumpbase test.wpa -msdata=none -mno-spe -mcpu=8540 -mcpu=8540 -auxbase bug -Os -version -fltrans-output-list=/tmp/cc4GjAt6.ltrans.out -fwpa -fresolution=/tmp/ccTv6kV7.res @/tmp/ccfQPfB6 GNU GIMPLE (GCC) version 4.7.2 (powerpc-eabispe) compiled by GNU C version 4.7.2, GMP version 5.0.1, MPFR version 3.1.1, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GCC) version 4.7.2 (powerpc-eabispe) compiled by GNU C version 4.7.2, GMP version 5.0.1, MPFR version 3.1.1, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
[Bug lto/55112] internal compiler error: in simplify_subreg, at simplify-rtx.c:5424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55112 --- Comment #1 from Patrick Oppenlander patrick at motec dot com.au 2012-10-28 22:18:32 UTC --- Created attachment 28549 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28549 Problem object file
[Bug lto/55113] New: internal compiler error: in emit_library_call_value_1, at calls.c:3739
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 Bug #: 55113 Summary: internal compiler error: in emit_library_call_value_1, at calls.c:3739 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: patr...@motec.com.au Created attachment 28550 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28550 Problem object files Using cross-compile gcc (x86_64 to powerpc) the following command line results in an internal compiler error. I have attached the problem object files (couldn't reduce beyond these two). Hope this is enough information, thanks. patrick@gtr:~/bug/report2$ powerpc-eabispe-gcc -v -Os -flto=jobserver -nostdlib -o test *.o Using built-in specs. COLLECT_GCC=powerpc-eabispe-gcc COLLECT_LTO_WRAPPER=/home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/lto-wrapper Target: powerpc-eabispe Configured with: /z/src/e7/toolchain/src/gcc-4.7.2/configure --prefix=/z/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c,c++ --with-sysroot=/z/src/e7/toolchain/../prex_sysroot --disable-nls --disable-werror --with-newlib --with-gmp=/z/src/e7/toolchain/stage2 --with-mpfr=/z/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp --with-cpu=8540 Thread model: single gcc version 4.7.2 (GCC) COMPILER_PATH=/home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/:/home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/:/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2/../../../../powerpc-eabispe/bin/ LIBRARY_PATH=/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2/:/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/:/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2/../../../../powerpc-eabispe/lib/ COLLECT_GCC_OPTIONS='-v' '-Os' '-flto=jobserver' '-nostdlib' '-o' 'test' '-mcpu=8540' /home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/collect2 -plugin /home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/liblto_plugin.so -plugin-opt=/home/patrick/src/e7/toolchain/stage2/bin/../libexec/gcc/powerpc-eabispe/4.7.2/lto-wrapper -plugin-opt=-fresolution=/tmp/ccXmIQW9.res -flto=jobserver --sysroot=/z/src/e7/toolchain/../prex_sysroot --eh-frame-hdr -V -dn -Bstatic -o test -L/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2 -L/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc -L/home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/powerpc-eabispe/4.7.2/../../../../powerpc-eabispe/lib bug0.o bug1.o GNU ld (GNU Binutils) 2.22 Supported emulations: elf32ppc elf32ppclinux elf32ppcsim powerpc-eabispe-gcc @/tmp/ccMr3FEZ.args Using built-in specs. COLLECT_GCC=powerpc-eabispe-gcc Target: powerpc-eabispe Configured with: /z/src/e7/toolchain/src/gcc-4.7.2/configure --prefix=/z/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c,c++ --with-sysroot=/z/src/e7/toolchain/../prex_sysroot --disable-nls --disable-werror --with-newlib --with-gmp=/z/src/e7/toolchain/stage2 --with-mpfr=/z/src/e7/toolchain/stage2 --disable-shared --disable-debug --disable-libssp --with-cpu=8540 Thread model: single gcc version 4.7.2 (GCC) COLLECT_GCC_OPTIONS='-c' '-msdata=none' '-mno-spe' '-mcpu=8540' '-v' '-Os' '-nostdlib' '-mcpu=8540' '-dumpdir' './' '-dumpbase' 'test.wpa' '-fltrans-output-list=/tmp/cc06h8H9.ltrans.out' '-fwpa' '-fresolution=/tmp/ccXmIQW9.res' /home/patrick/src/e7/toolchain/stage2/bin/../lib/gcc/../../libexec/gcc/powerpc-eabispe/4.7.2/lto1 -quiet -dumpdir ./ -dumpbase test.wpa -msdata=none -mno-spe -mcpu=8540 -mcpu=8540 -auxbase bug0 -Os -version -fltrans-output-list=/tmp/cc06h8H9.ltrans.out -fwpa -fresolution=/tmp/ccXmIQW9.res @/tmp/ccZssqpa GNU GIMPLE (GCC) version 4.7.2 (powerpc-eabispe) compiled by GNU C version 4.7.2, GMP version 5.0.1, MPFR version 3.1.1, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GCC) version 4.7.2 (powerpc-eabispe) compiled by GNU C version 4.7.2, GMP version 5.0.1, MPFR version 3.1.1, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
[Bug target/54963] [4.8 Regression] Wrong code generated for libgfortran/generated/eoshift3_8.c on SH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-28 23:01:24 UTC --- Created attachment 28551 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28551 Proposed patch This patch fixes the problem, by using 'emit_move_insn' instead of manually doing the DImode reg copy. I've seized the moment and refactored the abs patterns -- the T_REG clobber handling was a bit confusing and using mode iterators saves a few lines. Kaz, could you please have a look at this one? Only briefly tested with make-gcc and compiling CSiBE. There are no code size changes in the CSiBE set, except for one: jikespg-1.3 src/prntstat3576 - 3568 -8 / -0.223714 % I guess it's the T_REG clobber thing that has a positive impact on register allocation in this case.
[Bug lto/55113] internal compiler error: in emit_library_call_value_1, at calls.c:3739
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-28 23:27:17 UTC --- Can you attach the preprocessed source for those object files and how those object files were compiled?
[Bug lto/55112] internal compiler error: in simplify_subreg, at simplify-rtx.c:5424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55112 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-28 23:28:39 UTC --- Can you attach the preprocessed source for this object file?
[Bug rtl-optimization/55093] [4.8 Regression] [x32] -maddress-mode=long failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55093
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #28541|0 |1
is obsolete||
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-10-29 00:10:37
UTC ---
Created attachment 28552
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28552
A smaller testcase
LRA failed to handle
(insn 34 32 35 4 (parallel [
(set (reg:SI 79)
(plus:SI (subreg:SI (reg/f:DI 16 argp) 0)
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) x.ii:63 247 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUIV (plus:SI (subreg:SI (reg/f:DI 16 argp) 0)
(const_int 4 [0x4]))
(nil
The old reload eliminates argp:
(insn 34 49 35 4 (parallel [
(set (reg:SI 4 si [79])
(plus:SI (reg:SI 4 si [79])
(const_int 20 [0x14])))
(clobber (reg:CC 17 flags))
]) x.ii:63 247 {*addsi_1}
(expr_list:REG_EQUIV (plus:SI (subreg:SI (plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10])) 0)
(const_int 4 [0x4]))
(nil)))
while LRA keeps:
(insn 34 32 35 4 (parallel [
(set (reg:SI 4 si [79])
(plus:SI (reg:SI 16 argp)
(const_int 20 [0x14])))
(clobber (reg:CC 17 flags))
]) x.ii:63 247 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUIV (plus:SI (subreg:SI (reg/f:DI 16 argp) 0)
(const_int 4 [0x4]))
(nil
[Bug rtl-optimization/55093] [4.8 Regression] [x32] -maddress-mode=long failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55093 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-10-29 00:41:19 UTC --- This patch: diff --git a/gcc/lra-eliminations.c b/gcc/lra-eliminations.c index d80..681c609 100644 --- a/gcc/lra-eliminations.c +++ b/gcc/lra-eliminations.c @@ -272,7 +272,7 @@ get_elimination (rtx reg) if ((hard_regno = REGNO (reg)) 0 || hard_regno = FIRST_PSEUDO_REGISTER) return NULL; if ((ep = elimination_map[hard_regno]) != NULL) -return ep-from_rtx != reg ? NULL : ep; +return ep-from_rtx != reg ep-from != hard_regno ? NULL : ep; if ((offset = self_elim_offsets[hard_regno]) == 0) return NULL; /* This is an iteration to restore offsets just after HARD_REGNO fixes the IC.
[Bug rtl-optimization/55106] ice: Maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55106 --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-10-29 00:42:30 UTC --- Author: vmakarov Date: Mon Oct 29 00:42:25 2012 New Revision: 192904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192904 Log: 2012-10-28 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/55106 * lra-constraints.c (skip_usage_debug_insns): New function. (check_secondary_memory_needed_p): Ditto. (inherit_reload_reg): Use the new functions. Improve debug output. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug rtl-optimization/55093] [4.8 Regression] [x32] -maddress-mode=long failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55093 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-10-29 00:44:53 UTC --- I am testing this patch: diff --git a/gcc/lra-eliminations.c b/gcc/lra-eliminations.c index d80..cbfbe7a 100644 --- a/gcc/lra-eliminations.c +++ b/gcc/lra-eliminations.c @@ -272,7 +272,7 @@ get_elimination (rtx reg) if ((hard_regno = REGNO (reg)) 0 || hard_regno = FIRST_PSEUDO_REGISTER) return NULL; if ((ep = elimination_map[hard_regno]) != NULL) -return ep-from_rtx != reg ? NULL : ep; +return ep-from != hard_regno ? NULL : ep; if ((offset = self_elim_offsets[hard_regno]) == 0) return NULL; /* This is an iteration to restore offsets just after HARD_REGNO
[Bug target/54963] [4.8 Regression] Wrong code generated for libgfortran/generated/eoshift3_8.c on SH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963 --- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-10-29 00:59:37 UTC --- (In reply to comment #3) Created attachment 28551 [details] Proposed patch This patch fixes the problem, by using 'emit_move_insn' instead of manually doing the DImode reg copy. Does the pattern in negdi_cond emit_insn (gen_negc (low_dst, low_src)); emit_label_after (skip_neg_label, emit_insn (gen_negc (high_dst, high_src))); work in the problematic situation? Perhaps I've missed something.
[Bug middle-end/55114] New: [4.8 Regression] gcc.dg/builtins-53.c ICEs on mips64 soft-float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55114 Bug #: 55114 Summary: [4.8 Regression] gcc.dg/builtins-53.c ICEs on mips64 soft-float Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: pins...@gcc.gnu.org /home/apinski/src/gcc-fsf/local/gcc/gcc/testsuite/gcc.dg/builtins-53.c:96:1: error: unrecognizable insn: (insn 12 13 14 2 (set (reg:TF 4 $4) (parallel:TF [ (expr_list:REG_DEP_TRUE (reg:DI 199) (const_int 0 [0])) (expr_list:REG_DEP_TRUE (reg:DI 200) (const_int 8 [0x8])) ])) /home/apinski/src/gcc-fsf/local/gcc/gcc/testsuite/gcc.dg/builtins-53.c:95 -1 (nil)) That instruction should be split into two sets.
[Bug rtl-optimization/55093] [4.8 Regression] [x32] -maddress-mode=long failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55093 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-10-29 02:31:44 UTC --- (In reply to comment #6) I am testing this patch: diff --git a/gcc/lra-eliminations.c b/gcc/lra-eliminations.c index d80..cbfbe7a 100644 --- a/gcc/lra-eliminations.c +++ b/gcc/lra-eliminations.c @@ -272,7 +272,7 @@ get_elimination (rtx reg) if ((hard_regno = REGNO (reg)) 0 || hard_regno = FIRST_PSEUDO_REGISTER) return NULL; if ((ep = elimination_map[hard_regno]) != NULL) -return ep-from_rtx != reg ? NULL : ep; +return ep-from != hard_regno ? NULL : ep; if ((offset = self_elim_offsets[hard_regno]) == 0) return NULL; /* This is an iteration to restore offsets just after HARD_REGNO It doesn't solve all problems. I got Starting program: /export/build/gnu/gcc-x32-mx32-native-long/build-x86_64-linux/gcc/cc1 -fpreprocessed /tmp/bad.i -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=generic -quiet -dumpbase bad.i -msse2 -mx32 -auxbase-strip O3-pr41881.s -O2 -O3 -version -fno-diagnostics-show-caret -ftree-vectorize -fno-vect-cost-model -fno-common -fdump-tree-vect-details -fno-ipa-cp-clone -o O3-pr41881.s GNU C (GCC) version 4.8.0 20121029 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.0 20121029 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.8.0 20121029 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.0 20121029 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 8b8bc795ba054ad7d30608d02345517d Program received signal SIGSEGV, Segmentation fault. 0x0073eddb in dump_gimple_bb_header (outf=outf@entry=0x136dab0, bb=bb@entry=0xf6943380, indent=indent@entry=0, flags=flags@entry=469762568) at /export/gnu/import/git/gcc-misc/gcc/gimple-pretty-print.c:2097 2097 memset (s_indent, ' ', (size_t) indent); (gdb) p/x $rsp $6 = 0xc8b0 (gdb) When -maddress-mode=long is used to compile x32 GCC, Pmode is DImode and ptr_mode is SImode. LRA fails to properly handle ptr_mode != Pmode: 0x0073edb6 +278:lea-0x1(%rbx),%eax 0x0073edb9 +281:mov%ebx,%edx 0x0073edbb +283:mov$0x20,%esi 0x0073edc0 +288:add$0x2e,%rax 0x0073edc4 +292:shr$0x4,%rax 0x0073edc8 +296:shl$0x4,%rax 0x0073edcc +300:sub%rax,%rsp 0x0073edcf +303:lea0x1f(%rsp),%r8 0x0073edd4 +308:and$0xffe0,%r8d 0x0073edd8 +312:mov%r8,%rdi = 0x0073eddb +315:callq 0x4a5970 memset@plt
Re: Ping / update: RFA: replace #ifdef with if/#if for HAVE_ATTR_*
Joern Rennecke joern.renne...@embecosm.com writes:
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 192840)
+++ gcc/doc/tm.texi (working copy)
@@ -11333,3 +11333,11 @@ @deftypefn {Target Hook} {unsigned HOST_
@deftypevr {Target Hook} {unsigned char} TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
This value should be set if the result written by @code{atomic_test_and_set}
is not exactly 1, i.e. the @code{bool} @code{true}.
@end deftypevr
+
+@deftypevr {Target Hook} bool TARGET_HAVE_CC0
+@deftypevrx {Target Hook} {bool} TARGET_AUTO_INC_DEC
+@deftypevrx {Target Hook} {bool} TARGET_STACK_REGS
+@deftypevrx {Target Hook} {bool} TARGET_HAVE_ATTR_ENABLED
+@deftypevrx {Target Hook} {bool} TARGET_HAVE_ATTR_LENGTH
+These flags are automatically generated; you should not override them in
tm.c:
Typo: s/:$/./, also @file{tm.c}.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Move @end to own line
The texinfo manual says that @end should always be put on a line of its
own. Tested with make info dvi pdf html and checked in as obvious.
(None of the converters have a problem with this so the output will be
the same.)
Andreas.
* doc/tm.texi.in (Misc): Add newline before @end.
* doc/tm.texi: Update.
Index: doc/tm.texi
===
--- doc/tm.texi (revision 192885)
+++ doc/tm.texi (working copy)
@@ -11323,7 +11323,8 @@ accepted by immediate-add plus one. We
value of @code{TARGET_CONST_ANCHOR} is a power of 2. For example, on
MIPS, where add-immediate takes a 16-bit signed value,
@code{TARGET_CONST_ANCHOR} is set to @samp{0x8000}. The default value
-is zero, which disables this optimization. @end deftypevr
+is zero, which disables this optimization.
+@end deftypevr
@deftypefn {Target Hook} {unsigned HOST_WIDE_INT} TARGET_MEMMODEL_CHECK
(unsigned HOST_WIDE_INT @var{val})
Validate target specific memory model mask bits. When NULL no target specific
Index: doc/tm.texi.in
===
--- doc/tm.texi.in (revision 192885)
+++ doc/tm.texi.in (working copy)
@@ -11165,7 +11165,8 @@ accepted by immediate-add plus one. We
value of @code{TARGET_CONST_ANCHOR} is a power of 2. For example, on
MIPS, where add-immediate takes a 16-bit signed value,
@code{TARGET_CONST_ANCHOR} is set to @samp{0x8000}. The default value
-is zero, which disables this optimization. @end deftypevr
+is zero, which disables this optimization.
+@end deftypevr
@hook TARGET_MEMMODEL_CHECK
Validate target specific memory model mask bits. When NULL no target specific
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: [RFC PATCH, i386]: Remove peephole2s for (subreg (operator (...)(...))) RTXes
On Sun, Oct 28, 2012 at 2:37 AM, H.J. Lu hjl.to...@gmail.com wrote:
As suggested by Richard S. [1], after the patch that converts subreg:M
(op:N (...)(...)) to op:M (subreg:M (...) subreg:M (...)), we can
remove several peephole2 patterns that handle subregs of PLUS, MINUS
and MULT operators. I have attached RFC prototype patch that will
trigger an ICE when to-be-removed pattern triggers, with the intention
that these patterns wil be removed entirely (An invalid pattern was
indeed generated elsewhere, see patch).
2012-10-18 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.md (ashift to lea splitter): Split to SImode
mult.
(simple lea to add/shift peephole2s): Remove peephole2s that operate
on subregs of DImode operations.
(*movmode_insv_1_rex64): Use gen_int_mode to truncate
const_int RTX to QImode value.
(*movsi_insv_1): Ditto.
The patch was bootstrapped and regression tested on
x86_64-pc-linux-gnu {,-m32} without problems, but I will ask H.J. to
test the patch on x32 before it is committed to mainline SVN.
[1] http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01856.html
Uros.
I tested it on x32, ia32 and x86-64 with GCC testsuite and glibc.
There are no GCC regressions on x32. However, for glibc trunk,
on x32 and x86-64, I got
make[4]: ***
[/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ildoubl.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ldouble.out]
Error 1
On ia32, I got
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-fenv.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-ifloat.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-idouble.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-float.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-double.out]
Error 1
I am testing if they are caused by the change.
They are caused by this patch. I configure glibc with CFLAGS=-O3 -g
Can you please send me offline preprocessed sources to investigate
this failure? There is another place in the code that generates subreg
by hand.
Thanks,
Uros.
Re: [RFC PATCH, i386]: Remove peephole2s for (subreg (operator (...)(...))) RTXes
On Sun, Oct 28, 2012 at 9:57 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Oct 28, 2012 at 2:37 AM, H.J. Lu hjl.to...@gmail.com wrote:
As suggested by Richard S. [1], after the patch that converts subreg:M
(op:N (...)(...)) to op:M (subreg:M (...) subreg:M (...)), we can
remove several peephole2 patterns that handle subregs of PLUS, MINUS
and MULT operators. I have attached RFC prototype patch that will
trigger an ICE when to-be-removed pattern triggers, with the intention
that these patterns wil be removed entirely (An invalid pattern was
indeed generated elsewhere, see patch).
2012-10-18 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.md (ashift to lea splitter): Split to SImode
mult.
(simple lea to add/shift peephole2s): Remove peephole2s that
operate
on subregs of DImode operations.
(*movmode_insv_1_rex64): Use gen_int_mode to truncate
const_int RTX to QImode value.
(*movsi_insv_1): Ditto.
The patch was bootstrapped and regression tested on
x86_64-pc-linux-gnu {,-m32} without problems, but I will ask H.J. to
test the patch on x32 before it is committed to mainline SVN.
[1] http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01856.html
Uros.
I tested it on x32, ia32 and x86-64 with GCC testsuite and glibc.
There are no GCC regressions on x32. However, for glibc trunk,
on x32 and x86-64, I got
make[4]: ***
[/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ildoubl.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ldouble.out]
Error 1
On ia32, I got
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-fenv.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-ifloat.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-idouble.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-float.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-double.out]
Error 1
I am testing if they are caused by the change.
They are caused by this patch. I configure glibc with CFLAGS=-O3 -g
Can you please send me offline preprocessed sources to investigate
this failure? There is another place in the code that generates subreg
by hand.
Maybe following patch helps:
--cut here--
Index: i386.c
===
--- i386.c (revision 192872)
+++ i386.c (working copy)
@@ -11821,7 +11821,7 @@ ix86_decompose_address (rtx addr, struct ix86_addr
return 0;
}
else if (GET_MODE (addr) == DImode)
- addr = gen_rtx_SUBREG (SImode, addr, 0);
+ addr = simplify_gen_subreg (SImode, addr, DImode, 0);
else if (GET_MODE (addr) != VOIDmode)
return 0;
}
--cut here--
Uros.
Fix use of @item vs. @itemx inside @table
Tested with make info dvi pdf html and checked in as obvious.
Andreas.
* doc/cppopts.texi: Fix use of @item vs. @itemx inside @table.
* doc/extend.texi: Likewise.
* doc/generic.texi: Likewise.
* doc/invoke.texi: Likewise.
* doc/md.texi: Likewise.
* doc/sourcebuild.texi: Likewise.
diff --git a/gcc/doc/cppopts.texi b/gcc/doc/cppopts.texi
index 27b1095..a2eb79d 100644
--- a/gcc/doc/cppopts.texi
+++ b/gcc/doc/cppopts.texi
@@ -1,5 +1,5 @@
@c Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
-@c 2010, Free Software Foundation, Inc.
+@c 2010, 2012, Free Software Foundation, Inc.
@c This is part of the CPP and GCC manuals.
@c For copying conditions, see the file gcc.texi.
@@ -805,7 +805,7 @@ Replacement: []@{@}#\^|
~
Enable special code to work around file systems which only permit very
short file names, such as MS-DOS@.
-@itemx --help
+@item --help
@itemx --target-help
@opindex help
@opindex target-help
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index fb1becb..5c4f8fd 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -1251,10 +1251,10 @@ The @code{__flash} qualifier will locate data in the
instruction. Pointers to this address space are 16 bits wide.
@item __flash1
-@item __flash2
-@item __flash3
-@item __flash4
-@item __flash5
+@itemx __flash2
+@itemx __flash3
+@itemx __flash4
+@itemx __flash5
@cindex @code{__flash1} AVR Named Address Spaces
@cindex @code{__flash2} AVR Named Address Spaces
@cindex @code{__flash3} AVR Named Address Spaces
diff --git a/gcc/doc/generic.texi b/gcc/doc/generic.texi
index c739731..e878811 100644
--- a/gcc/doc/generic.texi
+++ b/gcc/doc/generic.texi
@@ -1,4 +1,4 @@
-@c Copyright (c) 2004, 2005, 2007, 2008, 2010 Free Software Foundation, Inc.
+@c Copyright (c) 2004, 2005, 2007, 2008, 2010, 2012 Free Software Foundation,
Inc.
@c Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
@@ -1417,13 +1417,13 @@ generate these expressions anyhow, if it can tell that
strictness does
not matter. The type of the operands and that of the result are
always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
-@itemx POINTER_PLUS_EXPR
+@item POINTER_PLUS_EXPR
This node represents pointer arithmetic. The first operand is always
a pointer/reference type. The second operand is always an unsigned
integer type compatible with sizetype. This is the only binary
arithmetic operand that can operate on pointer types.
-@itemx PLUS_EXPR
+@item PLUS_EXPR
@itemx MINUS_EXPR
@itemx MULT_EXPR
These nodes represent various binary arithmetic operations.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index afb9f21..15ecaf1 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1617,7 +1617,7 @@ GNU dialect of ISO C99. When ISO C99 is fully
implemented in GCC,
this will become the default. The name @samp{gnu9x} is deprecated.
@item gnu11
-@item gnu1x
+@itemx gnu1x
GNU dialect of ISO C11. Support is incomplete and experimental. The
name @samp{gnu1x} is deprecated.
@@ -5310,7 +5310,7 @@ is set by this option.
For example, with @option{-fdbg-cnt=dce:10,tail_call:0},
@code{dbg_cnt(dce)} returns true only for first 10 invocations.
-@itemx -fenable-@var{kind}-@var{pass}
+@item -fenable-@var{kind}-@var{pass}
@itemx -fdisable-@var{kind}-@var{pass}=@var{range-list}
@opindex fdisable-
@opindex fenable-
@@ -5464,11 +5464,11 @@ Dump after duplicating the computed gotos.
@option{-fdump-rtl-ce3} enable dumping after the three
if conversion passes.
-@itemx -fdump-rtl-cprop_hardreg
+@item -fdump-rtl-cprop_hardreg
@opindex fdump-rtl-cprop_hardreg
Dump after hard register copy propagation.
-@itemx -fdump-rtl-csa
+@item -fdump-rtl-csa
@opindex fdump-rtl-csa
Dump after combining stack adjustments.
@@ -5479,11 +5479,11 @@ Dump after combining stack adjustments.
@option{-fdump-rtl-cse1} and @option{-fdump-rtl-cse2} enable dumping after
the two common subexpression elimination passes.
-@itemx -fdump-rtl-dce
+@item -fdump-rtl-dce
@opindex fdump-rtl-dce
Dump after the standalone dead code elimination passes.
-@itemx -fdump-rtl-dbr
+@item -fdump-rtl-dbr
@opindex fdump-rtl-dbr
Dump after delayed branch scheduling.
@@ -5528,7 +5528,7 @@ Dump after the initialization of the registers.
@opindex fdump-rtl-initvals
Dump after the computation of the initial value sets.
-@itemx -fdump-rtl-into_cfglayout
+@item -fdump-rtl-into_cfglayout
@opindex fdump-rtl-into_cfglayout
Dump after converting to cfglayout mode.
@@ -5558,7 +5558,7 @@ Dump after removing redundant mode switches.
@opindex fdump-rtl-rnreg
Dump after register renumbering.
-@itemx -fdump-rtl-outof_cfglayout
+@item -fdump-rtl-outof_cfglayout
@opindex fdump-rtl-outof_cfglayout
Dump after converting from cfglayout mode.
@@ -10815,10 +10815,10 @@ integer multiply, or integer
Make inliner to take cgraph SCCs into account
Hi,
this patch implements simple hints on strongly connected components to inliner.
It increases badness of inlining functions within the same scc component, since
this
non-trivial recursive inlining is not win very often and it may blow up stack
frames a lot.
It also increases the entry points of SCC components to have bigger badness,
this is because inlining ufnctions in SCCs is usually also just complicating
callgraph furhter (it however can be great win when the recursion over SCC
is unlikely)
This is based on Richard's observation on one of the fortran testcases and
also on analysis of povray where we make our live very difficult by first
inlining within scc missing obvious inline of cheap entry of the component.
The badness update is a quick hack. I am experimenting with new and simpler
badness metric for 4.8. So with bit of luck good part of estimate_edge_badness
will go.
Bootstrapped/regtested x86_64-linux.
Honza
* ipa-inline.c (edge_badness): Reduce precision; use scc hints.
(inline_small_functions): Fix dumps; update all callees after inlining.
* ipa-inline.h (INLINE_HINT_in_scc, INLINE_HINT_same_scc): New
constants.
(inline summary): Add SCC_NO.
* ipa-inline-analysis.c (dump_inline_hints): Dump SCC hints.
(reset_inline_summary): Reset scc_no.
(estimate_node_size_and_time): Set in_scc hint.
(do_estimate_edge_time): Add same_scc hint.
(do_estimate_edge_hints): Likewise.
Index: ipa-inline.c
===
*** ipa-inline.c(revision 192887)
--- ipa-inline.c(working copy)
*** edge_badness (struct cgraph_edge *edge,
*** 845,852
precision for small bandesses (those are interesting) yet we don't
overflow for growths that are still in interesting range.
!Fixed point arithmetic with point at 8th bit. */
! badness = ((gcov_type)growth) * (1(19+8));
badness = (badness + div / 2) / div;
/* Overall growth of inlining all calls of function matters: we want to
--- 845,852
precision for small bandesses (those are interesting) yet we don't
overflow for growths that are still in interesting range.
!Fixed point arithmetic with point at 6th bit. */
! badness = ((gcov_type)growth) * (1(19+6));
badness = (badness + div / 2) / div;
/* Overall growth of inlining all calls of function matters: we want to
*** edge_badness (struct cgraph_edge *edge,
*** 861,869
We might mix the valud into the fraction by taking into account
relative growth of the unit, but for now just add the number
into resulting fraction. */
! if (badness INT_MAX / 2)
{
! badness = INT_MAX / 2;
if (dump)
fprintf (dump_file, Badness overflow\n);
}
--- 861,869
We might mix the valud into the fraction by taking into account
relative growth of the unit, but for now just add the number
into resulting fraction. */
! if (badness INT_MAX / 4)
{
! badness = INT_MAX / 4;
if (dump)
fprintf (dump_file, Badness overflow\n);
}
*** edge_badness (struct cgraph_edge *edge,
*** 871,876
--- 871,880
| INLINE_HINT_loop_iterations
| INLINE_HINT_loop_stride))
badness /= 8;
+ if (hints (INLINE_HINT_same_scc))
+ badness *= 4;
+ if (hints (INLINE_HINT_in_scc))
+ badness *= 2;
if (dump)
{
fprintf (dump_file,
*** inline_small_functions (void)
*** 1337,1352
if (flag_indirect_inlining)
new_indirect_edges = VEC_alloc (cgraph_edge_p, heap, 8);
- if (dump_file)
- fprintf (dump_file,
-\nDeciding on inlining of small functions. Starting with size
%i.\n,
-initial_size);
-
/* Compute overall unit size and other global parameters used by badness
metrics. */
max_count = 0;
- initialize_growth_caches ();
FOR_EACH_DEFINED_FUNCTION (node)
if (!node-global.inlined_to)
--- 1341,1350
*** inline_small_functions (void)
*** 1355,1369
--- 1353,1377
|| node-thunk.thunk_p)
{
struct inline_summary *info = inline_summary (node);
+ struct ipa_dfs_info *dfs = (struct ipa_dfs_info *) node-symbol.aux;
if (!DECL_EXTERNAL (node-symbol.decl))
initial_size += info-size;
+ info-scc_no = (dfs dfs-next_cycle dfs-next_cycle != node
+ ? dfs-scc_no + 1 : 0);
}
for (edge = node-callers; edge; edge = edge-next_caller)
if (max_count edge-count)
max_count = edge-count;
}
+ ipa_free_postorder_info ();
+ initialize_growth_caches ();
+
+ if (dump_file)
+
Re: [m68k] Fix option handling for -m68020-40 and -m68020-60
Andreas Schwab wrote: Gunther Nikl gn...@users.sourceforge.net writes: The patch should be installed on trunk and on the 4.7 branch. Thanks, done. The 4.7 branch required some adjustment, since it's not compiled as C++. Right. Maybe a better solution would have been then to only change m68k.c/m68k_option_override to additionally check for -m68020-[46]0 in global_options_set when setting cpu and tune entries. Thank you for taking care of the patch. Sorry that I didn't remember to adjust the copyright year. Regards, Gunther Nikl
Re: Make inliner to take cgraph SCCs into account
On Sun, 28 Oct 2012, Jan Hubicka wrote: Bootstrapped/regtested x86_64-linux. Honza * ipa-inline.c (edge_badness): Reduce precision; use scc hints. (inline_small_functions): Fix dumps; update all callees after inlining. * ipa-inline.h (INLINE_HINT_in_scc, INLINE_HINT_same_scc): New constants. (inline summary): Add SCC_NO. * ipa-inline-analysis.c (dump_inline_hints): Dump SCC hints. (reset_inline_summary): Reset scc_no. (estimate_node_size_and_time): Set in_scc hint. (do_estimate_edge_time): Add same_scc hint. (do_estimate_edge_hints): Likewise. Hello, I haven't tried bisecting or anything, but bootstrap is broken on x86_64-linux: libtool: compile: /tmp/testgcc/pristine/build/./gcc/xgcc -B/tmp/testgcc/pristine/build/./gcc/ -B/tmp/testgcc/pristine/inst/x86_64-unknown-linux-gnu/bin/ -B/tmp/testgcc/pristine/inst/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/testgcc/pristine/inst/x86_64-unknown-linux-gnu/include -isystem /tmp/testgcc/pristine/inst/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.. -I/data/repos/gcc/pristine/libstdc++-v3/../libiberty -I/data/repos/gcc/pristine/libstdc++-v3/../include -D_GLIBCXX_SHARED -I/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/data/repos/gcc/pristine/libstdc++-v3/libsupc++ -g -O2 -DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c -fPIC -DPIC -o cp-demangle.o cp-demangle.c:5462:1: internal compiler error: in edge_badness, at ipa-inline.c:910 } ^ 0x1046ce7 edge_badness /data/repos/gcc/pristine/gcc/ipa-inline.c:910 0x1046d33 update_edge_key /data/repos/gcc/pristine/gcc/ipa-inline.c:922 0x1047fe6 inline_small_functions /data/repos/gcc/pristine/gcc/ipa-inline.c:1399 0x1048cf9 ipa_inline /data/repos/gcc/pristine/gcc/ipa-inline.c:1717 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [cp-demangle.lo] Error 1 make[5]: Leaving directory `/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3' make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/tmp/testgcc/pristine/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/tmp/testgcc/pristine/build' make: *** [all] Error 2 -- Marc Glisse
[C++ Patch] PR 54526 (again)
Hi,
as pointed out in the audit trail, my first patch for this C++11 parsing
issue was misguided: I changed cp_parser_template_id but in fact C++11
wants new special *lexing* rules, which must be active outside templates
too, as the additional test (and the old manded one) shows. Thus the below.
Tested x86_64-linux.
Thanks,
Paolo.
/libcpp
2012-10-28 Paolo Carlini paolo.carl...@oracle.com
PR c++/54526 (again)
* lex.c (_cpp_lex_direct): In C++11 mode, implement 2.5 p3, bullet 2.
/gcc/cp
2012-10-28 Paolo Carlini paolo.carl...@oracle.com
PR c++/54526 (again)
* parser.c (cp_parser_template_id): Revert core of previous change
(keep adjusted inform message).
/gcc/testsuite
2012-10-28 Paolo Carlini paolo.carl...@oracle.com
PR c++/54526 (again)
* g++.dg/cpp0x/parse2.C: Extend.
* g++.old-deja/g++.other/crash28.C: Adjust.
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 192887)
+++ gcc/cp/parser.c (working copy)
@@ -12655,9 +12655,8 @@ cp_parser_template_id (cp_parser *parser,
/* Otherwise, emit an error about the invalid digraph, but continue
parsing because we got our argument list. In C++11 do not emit
any error, per 2.5/3. */
- if (cxx_dialect cxx0x
- permerror (next_token-location,
- %::% cannot begin a template-argument list))
+ if (permerror (next_token-location,
+%::% cannot begin a template-argument list))
{
static bool hint = false;
inform (next_token-location,
Index: gcc/testsuite/g++.dg/cpp0x/parse2.C
===
--- gcc/testsuite/g++.dg/cpp0x/parse2.C (revision 192887)
+++ gcc/testsuite/g++.dg/cpp0x/parse2.C (working copy)
@@ -10,3 +10,6 @@ int main()
{
X::A x;
}
+
+int a;
+bool b = 0::a;
Index: gcc/testsuite/g++.old-deja/g++.other/crash28.C
===
--- gcc/testsuite/g++.old-deja/g++.other/crash28.C (revision 192887)
+++ gcc/testsuite/g++.old-deja/g++.other/crash28.C (working copy)
@@ -31,5 +31,5 @@ class foo
};
void foo::x() throw(bar)
{
- if (!b) throw bar (static_cast::N::X*(this)); // { dg-error lambda
expressions|expected } parse error
+ if (!b) throw bar (static_cast::N::X*(this)); // { dg-error lambda
expressions|expected|invalid } parse error
}
Index: libcpp/lex.c
===
--- libcpp/lex.c(revision 192887)
+++ libcpp/lex.c(working copy)
@@ -2291,6 +2291,25 @@ _cpp_lex_direct (cpp_reader *pfile)
if (*buffer-cur == ':')
{
buffer-cur++;
+
+ /* C++11 - 2.5 p3, bullet 2. */
+ if (CPP_OPTION (pfile, cplusplus)
+ (CPP_OPTION (pfile, lang) == CLK_CXX11
+ || CPP_OPTION (pfile, lang) == CLK_GNUCXX11))
+ {
+ if (*buffer-cur == ':')
+ {
+ buffer-cur++;
+ if (*buffer-cur != ':' *buffer-cur != '')
+ {
+ --buffer-cur;
+ --buffer-cur;
+ break;
+ }
+ --buffer-cur;
+ }
+ }
+
result-flags |= DIGRAPH;
result-type = CPP_OPEN_SQUARE;
}
[wwwdocs] Rewrite glibc list archive references
...from sources.redhat.com to sourceware.org. With that, there are only a few references left in java/ . Gerald Index: c99status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v retrieving revision 1.58 diff -u -3 -p -r1.58 c99status.html --- c99status.html 13 Mar 2012 23:11:38 - 1.58 +++ c99status.html 28 Oct 2012 11:03:53 - @@ -326,11 +326,11 @@ expressions as required by C99./li liCompiler support is needed for thorough support of codemath_errhandling/code; see messages a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg8.html;1/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg8.html;1/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00014.html;2/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00014.html;2/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00015.html;3/a +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00015.html;3/a on this subject to libc-hacker. The compiler needs to mark its output from compilations using code-fno-trapping-math/code or code-fno-math-errno/code, possibly using Index: gcc-3.0/c99status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.0/c99status.html,v retrieving revision 1.7 diff -u -3 -p -r1.7 c99status.html --- gcc-3.0/c99status.html 29 Mar 2009 02:20:02 - 1.7 +++ gcc-3.0/c99status.html 28 Oct 2012 11:03:54 - @@ -314,11 +314,11 @@ definitions./li liCompiler support is needed for codemath_errhandling/code; see messages a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg8.html;1/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg8.html;1/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00014.html;2/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00014.html;2/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00015.html;3/a +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00015.html;3/a on this subject to libc-hacker./li liIn some places, code-pedantic/code warnings don't take proper Index: gcc-3.1/c99status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/c99status.html,v retrieving revision 1.6 diff -u -3 -p -r1.6 c99status.html --- gcc-3.1/c99status.html 29 Mar 2009 02:20:02 - 1.6 +++ gcc-3.1/c99status.html 28 Oct 2012 11:03:55 - @@ -315,11 +315,11 @@ definitions./li liCompiler support is needed for codemath_errhandling/code; see messages a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg8.html;1/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg8.html;1/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00014.html;2/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00014.html;2/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00015.html;3/a +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00015.html;3/a on this subject to libc-hacker./li liIn some places, code-pedantic/code warnings don't take proper Index: gcc-3.3/c99status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/c99status.html,v retrieving revision 1.5 diff -u -3 -p -r1.5 c99status.html --- gcc-3.3/c99status.html 29 Mar 2009 02:20:02 - 1.5 +++ gcc-3.3/c99status.html 28 Oct 2012 11:03:55 - @@ -304,11 +304,11 @@ pragmas./li liCompiler support is needed for codemath_errhandling/code; see messages a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg8.html;1/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg8.html;1/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00014.html;2/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00014.html;2/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00015.html;3/a +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00015.html;3/a on this subject to libc-hacker./li liIn some places, code-pedantic/code warnings don't take proper Index: gcc-3.4/c99status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/c99status.html,v retrieving revision 1.4 diff -u -3 -p -r1.4 c99status.html --- gcc-3.4/c99status.html 29 Mar 2009 02:20:02 - 1.4 +++ gcc-3.4/c99status.html 28 Oct 2012 11:03:56 - @@ -304,11 +304,11 @@ pragmas./li liCompiler support is needed for codemath_errhandling/code; see messages a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg8.html;1/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg8.html;1/a, a -href=http://sources.redhat.com/ml/libc-hacker/2000-06/msg00014.html;2/a, +href=http://sourceware.org/ml/libc-hacker/2000-06/msg00014.html;2/a, a
Re: Make inliner to take cgraph SCCs into account
On Sun, 28 Oct 2012, Jan Hubicka wrote: Bootstrapped/regtested x86_64-linux. Honza * ipa-inline.c (edge_badness): Reduce precision; use scc hints. (inline_small_functions): Fix dumps; update all callees after inlining. * ipa-inline.h (INLINE_HINT_in_scc, INLINE_HINT_same_scc): New constants. (inline summary): Add SCC_NO. * ipa-inline-analysis.c (dump_inline_hints): Dump SCC hints. (reset_inline_summary): Reset scc_no. (estimate_node_size_and_time): Set in_scc hint. (do_estimate_edge_time): Add same_scc hint. (do_estimate_edge_hints): Likewise. Hello, I haven't tried bisecting or anything, but bootstrap is broken on x86_64-linux: Hmm, sorry, that is indeed mine. I am testing a fix. Honza libtool: compile: /tmp/testgcc/pristine/build/./gcc/xgcc -B/tmp/testgcc/pristine/build/./gcc/ -B/tmp/testgcc/pristine/inst/x86_64-unknown-linux-gnu/bin/ -B/tmp/testgcc/pristine/inst/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/testgcc/pristine/inst/x86_64-unknown-linux-gnu/include -isystem /tmp/testgcc/pristine/inst/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.. -I/data/repos/gcc/pristine/libstdc++-v3/../libiberty -I/data/repos/gcc/pristine/libstdc++-v3/../include -D_GLIBCXX_SHARED -I/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/data/repos/gcc/pristine/libstdc++-v3/libsupc++ -g -O2 -DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c -fPIC -DPIC -o cp-demangle.o cp-demangle.c:5462:1: internal compiler error: in edge_badness, at ipa-inline.c:910 } ^ 0x1046ce7 edge_badness /data/repos/gcc/pristine/gcc/ipa-inline.c:910 0x1046d33 update_edge_key /data/repos/gcc/pristine/gcc/ipa-inline.c:922 0x1047fe6 inline_small_functions /data/repos/gcc/pristine/gcc/ipa-inline.c:1399 0x1048cf9 ipa_inline /data/repos/gcc/pristine/gcc/ipa-inline.c:1717 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [cp-demangle.lo] Error 1 make[5]: Leaving directory `/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/tmp/testgcc/pristine/build/x86_64-unknown-linux-gnu/libstdc++-v3' make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/tmp/testgcc/pristine/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/tmp/testgcc/pristine/build' make: *** [all] Error 2 -- Marc Glisse
Re: Make inliner to take cgraph SCCs into account
On Sun, 28 Oct 2012, Jan Hubicka wrote:
Bootstrapped/regtested x86_64-linux.
Honza
* ipa-inline.c (edge_badness): Reduce precision; use scc hints.
(inline_small_functions): Fix dumps; update all callees after inlining.
* ipa-inline.h (INLINE_HINT_in_scc, INLINE_HINT_same_scc): New
constants.
(inline summary): Add SCC_NO.
* ipa-inline-analysis.c (dump_inline_hints): Dump SCC hints.
(reset_inline_summary): Reset scc_no.
(estimate_node_size_and_time): Set in_scc hint.
(do_estimate_edge_time): Add same_scc hint.
(do_estimate_edge_hints): Likewise.
Hello,
I haven't tried bisecting or anything, but bootstrap is broken on
x86_64-linux:
Hmm, sorry, that is indeed mine. I am testing a fix.
Hi,
this is patch I comitted after regtesting and making sure that it gets past the
failure
point in the bootstrap. The issue s showing only on specific (most?) setups,
it is an
overflow in badness metric.
I also constructed testcase for the hint and found out there are two cases I
need
to deal with, too. First the linked list holding SCC components is not cyclic,
this looks like a bug - I do not see how it can reliably work, but I will look
into
that incrementaly. Second I do not want to handle simple recursion as SCCs since
those are understood by the inliner well, so when SCC gets collapsed into a
single
node and self recursive edge is created, we ought to ignore its SCC flag.
Honza
* gcc.dg/ipa/inlinehint-3.c: New testcase.
* ipa-inline.c (edge_badness): Fix overflow.
(inline_small_functions): Initialize SCCs correctly.
(do_estimate_edge_time, do_estimate_edge_hints): Skip self
recursive ufnctions in SCC hints.
Index: testsuite/gcc.dg/ipa/inlinehint-3.c
===
*** testsuite/gcc.dg/ipa/inlinehint-3.c (revision 0)
--- testsuite/gcc.dg/ipa/inlinehint-3.c (revision 0)
***
*** 0
--- 1,37
+ /* { dg-options -O3 -c -fdump-ipa-inline-details -fno-early-inlining
-fno-ipa-cp } */
+ void abort (void);
+ int sum;
+ int a[10];
+ int
+ scc_next (int c)
+ {
+ int i;
+ for (i=0;ic;i++)
+ a[i]=c;
+ scc_entry (c);
+ }
+ int
+ scc_entry (int c)
+ {
+ int i;
+ for (i=0;ic;i++)
+ sum+=a[i];
+ if (c--)
+ scc_next (c);
+ return sum;
+ }
+ main()
+ {
+ int sum;
+ int i;
+ for (i=0;i10;i++)
+ scc_entry (i);
+ if (sum 0)
+ abort ();
+ return 0;
+ }
+ /* { dg-final { scan-ipa-dump in_scc inline } } */
+ /* { dg-final { scan-ipa-dump same_scc inline } } */
+ /* Main is not in scc, the two functions are. */
+ /* { dg-final { scan-ipa-dump-times In SCC 2 inline } } */
+ /* { dg-final { cleanup-ipa-dump inline } } */
Index: ipa-inline.c
===
*** ipa-inline.c(revision 192889)
--- ipa-inline.c(working copy)
*** edge_badness (struct cgraph_edge *edge,
*** 861,869
We might mix the valud into the fraction by taking into account
relative growth of the unit, but for now just add the number
into resulting fraction. */
! if (badness INT_MAX / 4)
{
! badness = INT_MAX / 4;
if (dump)
fprintf (dump_file, Badness overflow\n);
}
--- 861,869
We might mix the valud into the fraction by taking into account
relative growth of the unit, but for now just add the number
into resulting fraction. */
! if (badness INT_MAX / 8)
{
! badness = INT_MAX / 8;
if (dump)
fprintf (dump_file, Badness overflow\n);
}
*** inline_small_functions (void)
*** 1360,1367
if (!DECL_EXTERNAL (node-symbol.decl))
initial_size += info-size;
! info-scc_no = (dfs dfs-next_cycle dfs-next_cycle != node
! ? dfs-scc_no + 1 : 0);
}
for (edge = node-callers; edge; edge = edge-next_caller)
--- 1360,1378
if (!DECL_EXTERNAL (node-symbol.decl))
initial_size += info-size;
! if (dfs dfs-next_cycle)
! {
! struct cgraph_node *n2;
! int id = dfs-scc_no + 1;
! for (n2 = node; n2;
!n2 = ((struct ipa_dfs_info *)
node-symbol.aux)-next_cycle)
! {
! struct inline_summary *info2 = inline_summary (n2);
! if (info2-scc_no)
! break;
! info2-scc_no = id;
! }
! }
}
for (edge = node-callers; edge; edge = edge-next_caller)
Index: ipa-inline-analysis.c
===
*** ipa-inline-analysis.c (revision 192888)
--- ipa-inline-analysis.c (working copy)
*** dump_inline_summary (FILE *
PR libstdc++/55041 update python printers
This fixes part of PR 55041 by updating the hash table printers to
account for Francois's recent changes.
PR libstdc++/55041
* python/libstdcxx/v6/printers.py (Tr1UnorderedMapPrinter): Update
to handle hashtable as member of unordered_map not base class.
(Tr1UnorderedSetPrinter): Likewise.
Tested x86_64-linux and committed to trunk.
commit a554179e10f867f983ca1915455ceb23a9edad3d
Author: Jonathan Wakely jwakely@gmail.com
Date: Sun Oct 28 13:16:31 2012 +
PR libstdc++/55041
* python/libstdcxx/v6/printers.py (Tr1UnorderedMapPrinter): Update
to handle hashtable as member of unordered_map not base class.
(Tr1UnorderedSetPrinter): Likewise.
diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 0eac413..07a5ee6 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -633,8 +633,13 @@ class Tr1UnorderedSetPrinter:
self.typename = typename
self.val = val
+def hashtable (self):
+if self.typename.startswith('std::tr1'):
+return self.val
+return self.val['_M_h']
+
def to_string (self):
-return '%s with %d elements' % (self.typename,
self.val['_M_element_count'])
+return '%s with %d elements' % (self.typename,
self.hashtable()['_M_element_count'])
@staticmethod
def format_count (i):
@@ -642,7 +647,7 @@ class Tr1UnorderedSetPrinter:
def children (self):
counter = itertools.imap (self.format_count, itertools.count())
-return itertools.izip (counter, Tr1HashtableIterator (self.val))
+return itertools.izip (counter, Tr1HashtableIterator
(self.hashtable()))
class Tr1UnorderedMapPrinter:
Print a tr1::unordered_map
@@ -651,8 +656,13 @@ class Tr1UnorderedMapPrinter:
self.typename = typename
self.val = val
+def hashtable (self):
+if self.typename.startswith('std::tr1'):
+return self.val
+return self.val['_M_h']
+
def to_string (self):
-return '%s with %d elements' % (self.typename,
self.val['_M_element_count'])
+return '%s with %d elements' % (self.typename,
self.hashtable()['_M_element_count'])
@staticmethod
def flatten (list):
@@ -671,7 +681,7 @@ class Tr1UnorderedMapPrinter:
def children (self):
counter = itertools.imap (self.format_count, itertools.count())
# Map over the hash table and flatten the result.
-data = self.flatten (itertools.imap (self.format_one,
Tr1HashtableIterator (self.val)))
+data = self.flatten (itertools.imap (self.format_one,
Tr1HashtableIterator (self.hashtable(
# Zip the two iterators together.
return itertools.izip (counter, data)
real_zerop for vectors
Hello,
this patch lets some predicates on floating point constants answer true
for vectors, so optimizations are applied.
Tested bootstrap + testsuite (default languages).
2012-10-29 Marc Glisse marc.gli...@inria.fr
PR middle-end/55027
gcc/
* tree.c (real_zerop, real_onep, real_twop, real_minus_onep):
Handle VECTOR_CST.
testsuite/
* gcc.dg/pr55027.c: New testcase.
--
Marc GlisseIndex: gcc/testsuite/gcc.dg/pr55027.c
===
--- gcc/testsuite/gcc.dg/pr55027.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr55027.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -Ofast -fdump-tree-optimized-raw } */
+
+typedef double v2df __attribute__ ((__vector_size__ (2 * sizeof (double;
+
+void f (v2df *x)
+{
+ *x = 0 + 1 * *x;
+}
+
+/* { dg-final { scan-tree-dump-not gimple_assign optimized } } */
+/* { dg-final { cleanup-tree-dump optimized } } */
Property changes on: gcc/testsuite/gcc.dg/pr55027.c
___
Added: svn:keywords
+ Author Date Id Revision URL
Added: svn:eol-style
+ native
Index: gcc/tree.c
===
--- gcc/tree.c (revision 192894)
+++ gcc/tree.c (working copy)
@@ -1985,75 +1985,127 @@ tree_floor_log2 (const_tree expr)
}
/* Return 1 if EXPR is the real constant zero. Trailing zeroes matter for
decimal float constants, so don't return 1 for them. */
int
real_zerop (const_tree expr)
{
STRIP_NOPS (expr);
- return ((TREE_CODE (expr) == REAL_CST
- REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst0)
- !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr)
- || (TREE_CODE (expr) == COMPLEX_CST
- real_zerop (TREE_REALPART (expr))
- real_zerop (TREE_IMAGPART (expr;
+ switch (TREE_CODE (expr))
+{
+case REAL_CST:
+ return REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst0)
+ !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr;
+case COMPLEX_CST:
+ return real_zerop (TREE_REALPART (expr))
+ real_zerop (TREE_IMAGPART (expr));
+case VECTOR_CST:
+ {
+ unsigned i;
+ for (i = 0; i VECTOR_CST_NELTS (expr); ++i)
+ if (!real_zerop (VECTOR_CST_ELT (expr, i)))
+ return false;
+ return true;
+ }
+default:
+ return false;
+}
}
/* Return 1 if EXPR is the real constant one in real or complex form.
Trailing zeroes matter for decimal float constants, so don't return
1 for them. */
int
real_onep (const_tree expr)
{
STRIP_NOPS (expr);
- return ((TREE_CODE (expr) == REAL_CST
- REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst1)
- !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr)
- || (TREE_CODE (expr) == COMPLEX_CST
- real_onep (TREE_REALPART (expr))
- real_zerop (TREE_IMAGPART (expr;
+ switch (TREE_CODE (expr))
+{
+case REAL_CST:
+ return REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst1)
+ !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr;
+case COMPLEX_CST:
+ return real_onep (TREE_REALPART (expr))
+ real_zerop (TREE_IMAGPART (expr));
+case VECTOR_CST:
+ {
+ unsigned i;
+ for (i = 0; i VECTOR_CST_NELTS (expr); ++i)
+ if (!real_onep (VECTOR_CST_ELT (expr, i)))
+ return false;
+ return true;
+ }
+default:
+ return false;
+}
}
/* Return 1 if EXPR is the real constant two. Trailing zeroes matter
for decimal float constants, so don't return 1 for them. */
int
real_twop (const_tree expr)
{
STRIP_NOPS (expr);
- return ((TREE_CODE (expr) == REAL_CST
- REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst2)
- !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr)
- || (TREE_CODE (expr) == COMPLEX_CST
- real_twop (TREE_REALPART (expr))
- real_zerop (TREE_IMAGPART (expr;
+ switch (TREE_CODE (expr))
+{
+case REAL_CST:
+ return REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst2)
+ !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr;
+case COMPLEX_CST:
+ return real_twop (TREE_REALPART (expr))
+ real_zerop (TREE_IMAGPART (expr));
+case VECTOR_CST:
+ {
+ unsigned i;
+ for (i = 0; i VECTOR_CST_NELTS (expr); ++i)
+ if (!real_twop (VECTOR_CST_ELT (expr, i)))
+ return false;
+ return true;
+ }
+default:
+ return false;
+}
}
/* Return 1 if EXPR is the real constant minus one. Trailing zeroes
matter for decimal float constants, so don't return 1 for them. */
int
real_minus_onep (const_tree expr)
{
STRIP_NOPS (expr);
- return ((TREE_CODE (expr) == REAL_CST
- REAL_VALUES_EQUAL (TREE_REAL_CST (expr),
Ping: [PATCH] Install error handler for out-of-memory when using STL containers
Ping. This issue stands in the way of a very simple solution of PR
fortran/51727. I've re-attached the patch for your convenience.
On 15 Oct 2012 at 22:51:05 +0200 Tobias Schlüter wrote:
The attached patch adds out-of-memory diagnostics for code using STL
containers by using set_new_handler. Since the intended allocation
size is not available to a new_handler, I had to forego a more
detailed error message such as the one from xmalloc_failed().
fatal_error() and abort() don't give a meaningful location when the
new_handler is called, so I chose to put together the error message
manually as is done in xmalloc_failed(). I would have found it more
appealing to have operator new call xmalloc() unless a custom
allocator is given, but I don't think there's a standard way of doing
this.
Built and tested on the C and Fortran testsuites. Ok for trunk?
Best regards,
- Tobi
2012-10-15 Tobias Schlüter t...@gcc.gnu.org
* toplev.c: Add '#include new'.
(cxx_out_of_memory): New function.
(general_init): Install cxx_out_of_memory as handler for
out-of-memory condition.
2012-10-15 Tobias Schlüter t...@gcc.gnu.org
* toplev.c: Add '#include new'.
(cxx_out_of_memory): New function.
(general_init): Install cxx_out_of_memory as handler for
out-of-memory condition.
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 2c9329f..2e6248a 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -89,6 +89,8 @@ along with GCC; see the file COPYING3. If not see
declarations for e.g. AIX 4.x. */
#endif
+#include new
+
static void general_init (const char *);
static void do_compile (void);
static void process_options (void);
@@ -1061,6 +1063,21 @@ open_auxiliary_file (const char *ext)
return file;
}
+
+/* Error handler for use with C++ memory allocation. Will be
+ installed via std::set_new_handler(). */
+
+static void
+cxx_out_of_memory()
+{
+ fprintf (stderr,
+ \n%s%sout of memory\n,
+ progname, *progname ? : : );
+
+ xexit (1);
+}
+
+
/* Initialization of the front end environment, before command line
options are parsed. Signal handlers, internationalization etc.
ARGV0 is main's argv[0]. */
@@ -1074,6 +1091,8 @@ general_init (const char *argv0)
--p;
progname = p;
+ std::set_new_handler (cxx_out_of_memory);
+
xmalloc_set_program_name (progname);
hex_init ();
Re: real_zerop for vectors
On 10/28/2012 04:14 PM, Marc Glisse wrote: Hello, this patch lets some predicates on floating point constants answer true for vectors, so optimizations are applied. Great. I wonder how are we doing lately in terms of function pointer inlining?! If the current optimizers can already able to smoothly inline real_zerop co we could have a single helper function and avoid all this redundancy... In case, I suppose other code could also benefit. Thanks, Paolo.
*ping* Re: [Patch, Fortran] Fix some libgfortran issues found by coverity
* ping * On 16.10.2012 23:18, Tobias Burnus wrote: In the Bessel-function algorithm, there was the useless code: ret-base_addr = ret-base_addr; And in all files which included ifunction.m4 is such code: iall_i4 (gfc_array_i4 * const restrict retarray, ... if (len = 0) *dest = 0; else ... } miall_i4 (gfc_array_i4 * const restrict retarray, ... if (len = 0) return; ... if (len = 0) *dest = 0; else Hence, for the MASK version (m'name`), the second if condition is always false. Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias
*ping* Re: [Patch, Fortran] PR54958 - Allow ac-implied-do and data-implied-do with INTENT(IN)
* ping * On 19.10.2012 18:54, Tobias Burnus wrote: gfortran's INTENT(IN) check was too strict for do variables. While a variable in the normal do-stmt and in an io-implied-do is in the scope and, hence, the variable may not be modified for a nonpointer intent(in) variable. However, ac-implied-do and data-implied-do live in their own scope and hence INTENT(IN) doesn't apply to them. (Neither does it apply to the FORALL/DO CONCURRENT index-name, but that was already handled correctly.) Build and regtested on x86-64-linux. OK for the trunk? Tobias
Re: real_zerop for vectors
On 10/28/2012 04:46 PM, Paolo Carlini wrote: On 10/28/2012 04:14 PM, Marc Glisse wrote: Hello, this patch lets some predicates on floating point constants answer true for vectors, so optimizations are applied. Great. I wonder how are we doing lately in terms of function pointer inlining?! If the current optimizers can already able to smoothly inline real_zerop co we could have a single helper function and avoid all this redundancy... In case, I suppose other code could also benefit. Uhm, sorry, I didn't notice the functions are recursive. The situation seems hopeless, too bad. Paolo.
Re: real_zerop for vectors
On Sun, 28 Oct 2012, Paolo Carlini wrote: On 10/28/2012 04:46 PM, Paolo Carlini wrote: On 10/28/2012 04:14 PM, Marc Glisse wrote: Hello, this patch lets some predicates on floating point constants answer true for vectors, so optimizations are applied. Great. I wonder how are we doing lately in terms of function pointer inlining?! If the current optimizers can already able to smoothly inline real_zerop co Inlining real_zerop can only happen in lto builds. we could have a single helper function and avoid all this redundancy... In case, I suppose other code could also benefit. Uhm, sorry, I didn't notice the functions are recursive. The situation seems hopeless, too bad. The recursion has a bounded depth of 2 ;-) It is true that we could have a single function in tree.c: bool real_intcstp (const_tree, int); with possible trivial wrappers in tree.h. -- Marc Glisse
Re: *ping* Re: [Patch, Fortran] Fix some libgfortran issues found by coverity
Hi Tobias, * ping * On 16.10.2012 23:18, Tobias Burnus wrote: In the Bessel-function algorithm, there was the useless code: ret-base_addr = ret-base_addr; The patch is OK. Thanks a lot! Thomas
Re: *ping* Re: [Patch, Fortran] PR54958 - Allow ac-implied-do and data-implied-do with INTENT(IN)
Hi Tobias, * ping * This is OK. Thanks for the patch! Thomas
Re: real_zerop for vectors
On Sun, 28 Oct 2012, Marc Glisse wrote: [there are 4 real_*p that only differ by 1 character] It is true that we could have a single function in tree.c: bool real_intcstp (const_tree, int); The helper function could even take a REAL_VALUE_TYPE as second argument, so the non-inline part doesn't have more work than currently. Trying to also merge the real_*p predicates with the integer_*p predicates seems harder (in fancy C++, we'd have a number of ways of writing the code for complex and vectors only once, but I don't think we want to go there). with possible trivial wrappers in tree.h. -- Marc Glisse
Re: real_zerop for vectors
Hi,
On 10/28/2012 05:51 PM, Marc Glisse wrote:
On Sun, 28 Oct 2012, Marc Glisse wrote:
[there are 4 real_*p that only differ by 1 character]
It is true that we could have a single function in tree.c:
bool real_intcstp (const_tree, int);
The helper function could even take a REAL_VALUE_TYPE as second
argument, so the non-inline part doesn't have more work than currently.
I was writing something like the below.
Paolo.
/
Index: tree.c
===
--- tree.c (revision 192887)
+++ tree.c (working copy)
@@ -1984,20 +1984,39 @@ tree_floor_log2 (const_tree expr)
: floor_log2 (low));
}
+static int
+real_somep (const_tree expr, REAL_VALUE_TYPE dcst)
+{
+ STRIP_NOPS (expr);
+
+ switch (TREE_CODE (expr))
+{
+case REAL_CST:
+ return REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dcst)
+ !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr;
+case COMPLEX_CST:
+ return real_somep (TREE_REALPART (expr), dcst)
+ real_somep (TREE_IMAGPART (expr), dconst0);
+case VECTOR_CST:
+ {
+ unsigned i;
+ for (i = 0; i VECTOR_CST_NELTS (expr); ++i)
+ if (!real_somep (VECTOR_CST_ELT (expr, i), dcst))
+ return false;
+ return true;
+ }
+default:
+ return false;
+}
+}
+
/* Return 1 if EXPR is the real constant zero. Trailing zeroes matter for
decimal float constants, so don't return 1 for them. */
int
real_zerop (const_tree expr)
{
- STRIP_NOPS (expr);
-
- return ((TREE_CODE (expr) == REAL_CST
- REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst0)
- !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr)
- || (TREE_CODE (expr) == COMPLEX_CST
- real_zerop (TREE_REALPART (expr))
- real_zerop (TREE_IMAGPART (expr;
+ return real_somep (expr, dconst0);
}
/* Return 1 if EXPR is the real constant one in real or complex form.
@@ -2007,14 +2026,7 @@ real_zerop (const_tree expr)
int
real_onep (const_tree expr)
{
- STRIP_NOPS (expr);
-
- return ((TREE_CODE (expr) == REAL_CST
- REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst1)
- !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr)
- || (TREE_CODE (expr) == COMPLEX_CST
- real_onep (TREE_REALPART (expr))
- real_zerop (TREE_IMAGPART (expr;
+ return real_somep (expr, dconst1);
}
/* Return 1 if EXPR is the real constant two. Trailing zeroes matter
@@ -2023,14 +2035,7 @@ real_onep (const_tree expr)
int
real_twop (const_tree expr)
{
- STRIP_NOPS (expr);
-
- return ((TREE_CODE (expr) == REAL_CST
- REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst2)
- !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr)
- || (TREE_CODE (expr) == COMPLEX_CST
- real_twop (TREE_REALPART (expr))
- real_zerop (TREE_IMAGPART (expr;
+ return real_somep (expr, dconst2);
}
/* Return 1 if EXPR is the real constant minus one. Trailing zeroes
@@ -2039,14 +2044,7 @@ real_twop (const_tree expr)
int
real_minus_onep (const_tree expr)
{
- STRIP_NOPS (expr);
-
- return ((TREE_CODE (expr) == REAL_CST
- REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconstm1)
- !(DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (expr)
- || (TREE_CODE (expr) == COMPLEX_CST
- real_minus_onep (TREE_REALPART (expr))
- real_zerop (TREE_IMAGPART (expr;
+ return real_somep (expr, dconstm1);
}
/* Nonzero if EXP is a constant or a cast of a constant. */
Re: real_zerop for vectors
On Sun, 28 Oct 2012, Paolo Carlini wrote: I was writing something like the below. I would move the one-liners (real_zerop, etc) to tree.h, but that looks good, yes. -- Marc Glisse
Re: Ping / update: RFA: replace #ifdef with if/#if for HAVE_ATTR_*
Quoting Andreas Schwab sch...@linux-m68k.org:
+These flags are automatically generated; you should not override
them in tm.c:
Typo: s/:$/./, also @file{tm.c}.
Thanks. I have re-bootstrapped the amended patch on i686-pc-linux-gnu.
2012-10-28 Joern Rennecke joern.renne...@embecosm.com
* doc/md.texi (Defining Attributes): Document that we are defining
HAVE_ATTR_name macors as 1 for defined attributes, and as 0
for undefined special attributes.
* doc/tm.texi.in: Add @hook TARGET_HAVE_CC0.
* doc/tm.texi: Regenerate.
* final.c (asm_insn_count, align_fuzz): Always define.
(insn_current_reference_address): Likewise.
(init_insn_lengths): Use if (HAVE_ATTR_length) instead of
#ifdef HAVE_ATTR_length.
(get_attr_length_1, shorten_branches, final): Likewise.
(final_scan_insn, output_asm_name): Likewise.
* genattr.c (gen_attr): Define HAVE_ATTR_name macros for
defined attributes as 1.
Remove ancient get_attr_alternative compatibility code.
For special purpose attributes not provided, define HAVE_ATTR_name
as 0.
In case no length attribute is given, provide stub definitions
for insn_*_length* functions, and also include insn-addr.h.
In case no enabled attribute is given, provide stub definition.
* genattrtab.c (write_length_unit_log): Always write a definition.
* hooks.c (hook_int_rtx_1): New function.
* hooks.h (hook_int_rtx_1): Declare.
* lra-int.h (struct lra_insn_recog_data): Make member
alternative_enabled_p unconditional.
* lra.c (free_insn_recog_data): Use if (HAVE_ATTR_length) instead of
#ifdef HAVE_ATTR_length.
(lra_set_insn_recog_data): Likewise. Make initialization of
alternative_enabled_p unconditional.
(lra_update_insn_recog_data): Use #if instead of #ifdef for
HAVE_ATTR_enabled.
* recog.c [!HAVE_ATTR_enabled] (get_attr_enabled): Don't define.
(extract_insn): Check HAVE_ATTR_enabled.
(gate_handle_split_before_regstack): Use #if instead of
#if defined for HAVE_ATTR_length.
* gcc/target-def.h: Provide definitions for TARGET_HAVE_CC0,
TARGET_AUTO_INC_DEC, TARGET_STACK_REGS, TARGET_HAVE_ATTR_LENGTH
and TARGET_HAVE_ATTR_ENABLED.
* target.def (have_cc0, auto_inc_dec): New flags in target structure.
(stack_regs, have_attr_enabled, have_attr_length): Likewise.
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 192840)
+++ gcc/doc/md.texi (working copy)
@@ -7558,7 +7558,7 @@ (define_attr type branch,fp,load,stor
the following lines will be written to the file @file{insn-attr.h}.
@smallexample
-#define HAVE_ATTR_type
+#define HAVE_ATTR_type 1
enum attr_type @{TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
TYPE_STORE, TYPE_ARITH@};
extern enum attr_type get_attr_type ();
@@ -7583,6 +7583,10 @@ extern enum attr_type get_attr_type ();
generation. @xref{Disable Insn Alternatives}.
@end table
+For each of these special attributes, the corresponding
+@samp{HAVE_ATTR_@var{name}} @samp{#define} is also written when the
+attribute is not defined; in that case, it is defined as @samp{0}.
+
@findex define_enum_attr
@anchor{define_enum_attr}
Another way of defining an attribute is to use:
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 192840)
+++ gcc/doc/tm.texi (working copy)
@@ -11333,3 +11333,11 @@ @deftypefn {Target Hook} {unsigned HOST_
@deftypevr {Target Hook} {unsigned char} TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
This value should be set if the result written by @code{atomic_test_and_set}
is not exactly 1, i.e. the @code{bool} @code{true}.
@end deftypevr
+
+@deftypevr {Target Hook} bool TARGET_HAVE_CC0
+@deftypevrx {Target Hook} {bool} TARGET_AUTO_INC_DEC
+@deftypevrx {Target Hook} {bool} TARGET_STACK_REGS
+@deftypevrx {Target Hook} {bool} TARGET_HAVE_ATTR_ENABLED
+@deftypevrx {Target Hook} {bool} TARGET_HAVE_ATTR_LENGTH
+These flags are automatically generated; you should not override them in
@file{tm.c}.
+@end deftypevr
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in (revision 192840)
+++ gcc/doc/tm.texi.in (working copy)
@@ -11173,3 +11173,5 @@ @hook TARGET_MEMMODEL_CHECK
@end deftypefn
@hook TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
+
+@hook TARGET_HAVE_CC0
Index: gcc/final.c
===
--- gcc/final.c (revision 192840)
+++ gcc/final.c (working copy)
@@ -204,9 +204,7 @@ Software Foundation; either version 3, o
/* True if printing into -fdump-final-insns= dump. */
bool final_insns_dump_p;
-#ifdef HAVE_ATTR_length
static int asm_insn_count (rtx);
-#endif
static void profile_function (FILE
RFA: hookize ADJUST_INSN_LENGTH (Was: RFA: Add lock_lenth attribute to support the ARC port)
Quoting Richard Biener richard.guent...@gmail.com:
Thus, you can allow the length to vary downwards as well as upwards
across iterations with suitable definitions of the @code{length} attribute
and/or @code{ADJUST_INSN_LENGTH}. Care has to be taken that this does not
lead to infinite loops.
I don't see that you can shrink length with just suitable lock_length and
length attributes.
I disagree there (for certain values of 'just'), but we can just agree
to disagree on this point because...
What seems to be the cruical difference is that you
apply ADJUST_INSN_LENGTH after combining lock-length-max and length.
But then you _decrease_ length with ADJUST_INSN_LENGHT ...
Maybe what you really want is ADJUST_INSN_LENGTH_AFTER which is
applied afterwards? Thus,
Well, actually, I found a number of problems with ADJUST_INSN_LENGTH:
- it is not applied to inner insn is a delay slot sequence. You can
sort of work around this by stitching recursive calls together, but
then you are faced with another problem:
- You don't know what the length prior to ADJUST_INSN_LENGTH was. That
was even worse with the non-unique uids where you didn't knew squat
about the instructions in the delay slot.
- As you said, I want the adjustment happen after the maximum calculation.
Well, usually. There are actually special cases where it would be useful
to have some sort of maximum calculation in place, to break up
alignment-driven cycles, but only applicable with a lesser priority than
for the range-driven branch offset calculations.
But adding yet another macro neither does solve all these problems, nor
would it align with our goal to move away from target macros.
I found now an alternate way to make the ARC port termiante building its
insn-attrtab.c - it involves using match_test(get_attr_length (insn) == 2)
instead of eq_attr([lock_]length (const_int 2)) - where I really want to
know if the instruction was considered short in the previous iteration.
So, I have made a patch to replace the ADJUST_INSN_LENGTH macro in final.c
with an adjust_insn_length hook, for which a default implementation
using ADJUST_INSN_LENGTH is provided in targhooks.c to provide for an
easy transition.
I've looked at the existing ports that use ADJUST_INSN_LENGTH, and some
seem to prefer to return an adjustment to be added to the length, while
others prefer to return the new length. The latter seemed to be slightly
more numerous, so I went with that.
The hook has two new parameters:
- a flag that tells it if the insn in question is a delay sequence.
The default hook implementation skips the invocation of ADJUST_INSN_LENGTH
in this case for the sake of compatibility.
- a pointer to int to set the number of iteration loops till the length
locking feature is supposed to apply to this instruction length when
using the increasing size calculations. The pointed-to value is initialized
to zero, which means that length locking is always applied (assuming final.c
uses the increasing length algorithm). Setting this to a higher number
effectively gives the new instruction length a lower priority to be put
into uid_lock_length.
Note that
Care has to be taken that this does not
lead to infinite loops.
doesn't convince me that is properly designed ;)
With the hook mechanism, it is much harder to create an infinite loop
inside shorten_branches. (It would involve something like setting
iteration_threshold to MAX_INT and making length decreasing when niter
is at MAX_INT, then letting integer overflow of niter take its course.
Making it impossible for a port maintainer to get things wrong is not a
meaningful goal for GCC, but making it straightforward to get it right is.)
This patch builds on:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02527.html
Bootstrapped in revision 192879 on i686-pc-linux-gnu.
Tested with config-list.mk on x86_64-unknown-linux-gnu.
2012-10-28 Joern Rennecke joern.renne...@embecosm.com
* doc/tm.texi.in (@hook TARGET_ADJUST_INSN_LENGTH): Add.
* doc/tm.texi: Regenerate.
* final.c (get_attr_length_1): Use targetm.adjust_insn_length
instead of ADJUST_INSN_LENGTH.
(adjust_length): New function.
(shorten_branches): Use adjust_length instead of ADJUST_INSN_LENGTH.
* target.def (adjust_insn_length): New hook.
* targhooks.c (default_adjust_insn_length): New function.
* targhooks.h (default_adjust_insn_length): Declare.
diff -drup gcc-192879-haveattr/doc/tm.texi gcc/doc/tm.texi
--- gcc-192879-haveattr/doc/tm.texi 2012-10-28 01:07:38.463469923 +
+++ gcc/doc/tm.texi 2012-10-28 01:31:15.57927 +
@@ -11341,3 +11341,7 @@ This value should be set if the result w
@deftypevrx {Target Hook} {bool} TARGET_HAVE_ATTR_LENGTH
These flags are automatically generated; you should not override them in tm.c:
@end deftypevr
+
+@deftypefn {Target Hook} int TARGET_ADJUST_INSN_LENGTH (rtx @var{insn}, int
@var{length},
Re: real_zerop for vectors
On 10/28/2012 06:06 PM, Marc Glisse wrote: On Sun, 28 Oct 2012, Paolo Carlini wrote: I was writing something like the below. I would move the one-liners (real_zerop, etc) to tree.h, but that looks good, yes. Ah great. But please, don't wait on me, I'm in the middle of too many other things, if you like the idea just integrate it with your other work in this area and go ahead! Cheers, Paolo.
