Re: [testsuite, android] Disabling thread_local4.C and thread_local4g.C for Android.
Hello, OK. Checked into MT: http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00731.html -- Thanks, K
Re: [Patch, Aarch64]: Handle return address via. frame pointer
On Sun, Jul 28, 2013 at 3:53 AM, Venkataramanan Kumar venkataramanan.ku...@linaro.org wrote: Hi Maintainers, This patch adds supports to handle return address via. frame pointer. I noticed this patch causes undefined behavior when -fomit-frame-pointer and __builtin_return_address(1) is used. On PowerPC it is defined correctly that is it generates a frame for that case. Now on x86_64 it might be undefined but I think that is just wrong since __builtin_return_address is just used for debugging anyways. Thanks, Andrew gcc/ChangeLog - 2013-07-28 Venkataramanan Kumar venkataramanan.ku...@linaro.org * config/aarch64/aarch64.c (aarch64_return_addr): Handle returning address from a frame. Regression tested with aarch64-none-elf with V8 foundation model. regards, Venkat.
[ping**3] Re: [patch 0/4] reimplement -fstrict-volatile-bitfields, v3
On 07/20/2013 01:12 PM, Sandra Loosemore wrote:
On 07/09/2013 10:23 AM, Sandra Loosemore wrote:
On 06/30/2013 09:24 PM, Sandra Loosemore wrote:
Here is my third attempt at cleaning up -fstrict-volatile-bitfields.
Ping?
...and ping again.
...and again. Hmmm.
struct patch_status
{
volatile int approved:1;
volatile int rejected:1;
volatile int needs_changes:1;
int pinged;
};
extern struct patch_status s;
while (!s.approved !s.rejected !s.needs_changes)
{
sleep (a_week_or_two ());
pinged++;
}
Part 1 removes the warnings and packedp flag. It is the same as in the
last version, and has already been approved. I'll skip reposting it
since the patch is here already:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00908.html
Part 2 replaces parts 2, 3, and 4 in the last version. I've re-worked
this code significantly to try to address Bernd Edlinger's comments on
the last version in PR56997.
Part 2: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg1.html
Part 3 is the test cases, which are the same as in the last version.
Nobody has reviewed these but I assume they are OK if Part 2 is
approved?
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00912.html
Part 4 is new; it makes -fstrict-volatile-bitfields not be the default
for any target any more. It is independent of the other changes.
Part 4: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg2.html
It seems that the change to the defaults in part 4 is still
controversial but my understanding based on discussion of the previous
version of the patches is that the maintainers were going to insist on
that as a condition of getting the other bug fixes in. From my
perspective, I'd be happy just to wrap up this patch series somehow or
another, so please let me know if there are additional changes I need to
make before this is suitable to check in.
Please note that I'm pinging my own 4-part patch series, not the Bernd's
followup patch confusingly posted in the same thread.
-Sandra
Re: [Patch, Aarch64]: Handle return address via. frame pointer
Hi Andrew, I can see that rs6000 port uses a flag cfun-machine-ra_needs_full_frame = 1. But I need to check if this flag helps to generate frame for all the functions in a compilation unit. The requirement is that frame need to be preserved by any function that calls our function which uses _builtin_return_address(1), even when -fomit-frame-pointer is used. regards, venkat. On 29 July 2013 11:57, Andrew Pinski pins...@gmail.com wrote: On Sun, Jul 28, 2013 at 3:53 AM, Venkataramanan Kumar venkataramanan.ku...@linaro.org wrote: Hi Maintainers, This patch adds supports to handle return address via. frame pointer. I noticed this patch causes undefined behavior when -fomit-frame-pointer and __builtin_return_address(1) is used. On PowerPC it is defined correctly that is it generates a frame for that case. Now on x86_64 it might be undefined but I think that is just wrong since __builtin_return_address is just used for debugging anyways. Thanks, Andrew gcc/ChangeLog - 2013-07-28 Venkataramanan Kumar venkataramanan.ku...@linaro.org * config/aarch64/aarch64.c (aarch64_return_addr): Handle returning address from a frame. Regression tested with aarch64-none-elf with V8 foundation model. regards, Venkat.
[PATCH] S/390: Fix movcc patter
Hi, the attached patch fixes a problem with the movcc pattern on S/390. I've committed the patch to mainline after a regression test. Ok for GCC 4.8 branch? Bye, -Andreas- 2013-07-29 Dominik Vogt v...@linux.vnet.ibm.com * config/s390/s390.md (movcc): Swap load and store instructions. --- gcc/config/s390/s390.md | 12 1 file changed, 12 modifications(!) Index: gcc/config/s390/s390.md === *** gcc/config/s390/s390.md.orig --- gcc/config/s390/s390.md *** *** 2289,2301 lr\t%0,%1 tmh\t%1,12288 ipm\t%0 !st\t%0,%1 !sty\t%0,%1 !l\t%1,%0 !ly\t%1,%0 [(set_attr op_type RR,RI,RRE,RX,RXY,RX,RXY) !(set_attr type lr,*,*,store,store,load,load) !(set_attr z10prop z10_fr_E1,z10_super,*,z10_rec,z10_rec,z10_fwd_A3,z10_fwd_A3) (set_attr z196prop *,*,z196_ends,*,*,*,*)]) ; --- 2289,2301 lr\t%0,%1 tmh\t%1,12288 ipm\t%0 !l\t%0,%1 !ly\t%0,%1 !st\t%1,%0 !sty\t%1,%0 [(set_attr op_type RR,RI,RRE,RX,RXY,RX,RXY) !(set_attr type lr,*,*,load,load,store,store) !(set_attr z10prop z10_fr_E1,z10_super,*,z10_fwd_A3,z10_fwd_A3,z10_rec,z10_rec) (set_attr z196prop *,*,z196_ends,*,*,*,*)]) ;
Re: [Patch] Refractor Thompson matcher
Hi, On 07/29/2013 02:06 AM, Tim Shen wrote: On Mon, Jul 29, 2013 at 1:08 AM, Paolo Carlini paolo.carl...@oracle.com wrote: Oh well, thanks. But then I expect specific testcases to come with it, for the various values of the parameter, both the default and the other other values. Otherwise, the idea isn't really immediately useful. See what I mean? So I modified testcases to test both of them. Also, please make sure that this change is in any case a step in the right direction. I mean: I suppose that if we do this only the logic to control automatically the switch is missing and when we add it we are done. Let's not do it if I'm mistaken. Never mind, this patch makes them switch to be automatic(based on whether there're back-references in the regex), thanks to the full-featured regex scanner. A testcase is given too. Ah, excellent. As usual, let's wait a day or so for further comments and then please commit the whole thing. Minor nit: it's not clear to me why in the previous patch you added the includes of map and queue. Thanks, Paolo.
Re: [Patch] Refractor Thompson matcher
On Mon, Jul 29, 2013 at 4:26 PM, Paolo Carlini paolo.carl...@oracle.com wrote: Minor nit: it's not clear to me why in the previous patch you added the includes of map and queue. I use them in regex_grep_matcher.h and regex_grep_matcher.tcc; Is include/std/regex the right place where I include them? -- Tim Shen
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE = CLASS
Dear Tobias,
I think that Janus's OK of the 27th was already enough :-)
The tweaks that you have made since make it look much cleaner. So,
once more - OK for trunk.
Thanks for the patch
Paul
On 27 July 2013 21:51, Tobias Burnus bur...@net-b.de wrote:
Tobias Burnus wrote:
Giving up on the class.c version, would be the following change okay?
+ if (expr1-ts.type == BT_DERIVED expr2-ts.type == BT_CLASS
+ expr2-expr_type != EXPR_FUNCTION)
+{
+ gfc_add_data_component (expr2);
+ /* The following is required as gfc_add_data_component doesn't
+update ts.type if there is a tailing REF_ARRAY. */
+ expr2-ts.type = BT_DERIVED;
+}
It still feels a bit like a hack - but it is definitely much cleaner than
my previous band aid.
Built and regtested on x86-64-gnu-linux.
OK?
Attached is now the patch which does what I wrote above.
OK?
Tobias
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Re: [Patch] Refractor Thompson matcher
On 07/29/2013 10:37 AM, Tim Shen wrote: On Mon, Jul 29, 2013 at 4:26 PM, Paolo Carlini paolo.carl...@oracle.com wrote: Minor nit: it's not clear to me why in the previous patch you added the includes of map and queue. I use them in regex_grep_matcher.h and regex_grep_matcher.tcc; Is include/std/regex the right place where I include them? I guess it's the right place yes. Sorry, I didn't notice the uses (when I think refactoring, I don't think two more std:: containers are needed ;) Paolo.
RE: [patch] ICE with combination of -openmp and -femit-struct-debug-reduced/baseonly
Hi! We've got assignment form, finally. I've add Changelog record and two testcases. Please, review, is it ok to commit? /* With optimism, Evgeny Gavrin email : evgeny.gav...@hotmail.com */ Date: Tue, 2 Jul 2013 13:54:14 -0700 Subject: Re: [patch] ICE with combination of -openmp and -femit-struct-debug-reduced/baseonly From: ccout...@google.com To: evgeny.gav...@hotmail.com CC: gcc-patches@gcc.gnu.org; slava.garbu...@gmail.com I've find out that compiler may crash with SEGFAULT on some openmp-enabled code (attached as debug-1.c) called with the following flags: -g -fopenmp -gdwarf-2 -femit-struct-debug-reduced Also, can be reproduced with -femit-struct-debug-baseonly The problem is in dwarf2out.c:350:should_emit_struct_debug() at this line: 366 type_decl = TYPE_STUB_DECL (TYPE_MAIN_VARIANT (type)); In some cases type_decl can be NULL and this causes ICE in the following code: 368 if (criterion == DINFO_STRUCT_FILE_SYS DECL_IN_SYSTEM_HEADER (type_decl)) 369 return DUMP_GSTRUCT (type, usage, criterion, generic, false, true); 370 371 if (matches_main_base (DECL_SOURCE_FILE (type_decl))) 372 return DUMP_GSTRUCT (type, usage, criterion, generic, true, true); Can be fixed with checking for type_decl is not NULL. I've attached patch to fix this. Could you check, is it ok? The patch looks OK to me. Do you have a copyright assignment on file with FSF? For a patch this size, I don't think you need one, but I'd appreciate confirmation from the more legally-inclined (Danny, Ian?). Do you need someone to commit it for you? This is very straightforward fix, can the problem be in incorrect debug info generation on early stages? Sorry, I'm not sure what you're asking here. -cary ice-omp-fesdr.patch Description: Binary data test-results Description: Binary data
Re: Request to merge Undefined Behavior Sanitizer in
On Thu, Jul 25, 2013 at 10:50:14PM -0600, Jeff Law wrote: On 07/25/2013 04:40 PM, Joseph S. Myers wrote: On Thu, 25 Jul 2013, Marek Polacek wrote: So far it sanitizes division-by-zeros, shifts and __builtin_unreachable calls. This is of course far from being complete; I intend to write more features during this 4.9 stage. Such as everything needed for it to replace -ftrapv (for -ftrapv to become an alias for an appropriate subset of this option)? I'm guessing Marek would probably start with looking to provide feature parity with LLVM's -fsanitize=undefined which is defined as: -fsanitize=undefined: Fast and compatible undefined behavior checker. Enables the undefined behavior checks that have small runtime cost and no impact on address space layout or ABI. This includes all of the checks listed below other than unsigned-integer-overflow. So I wouldn't necessarily expect ubsan, at least in the near future, to catch the -ftrapv stuff. Though it's something that might be able to be added at some point. Yeah, exactly. I expect to get back to -ftrapv after providing the most useful subset of LLVM's ubsan functionality. Marek
Re: [Patch ARM] Fix PR19599 tail
Ramana Radhakrishnan writes: Hi, This fixes up the issues with PR target/19599 and the issues we've had around it. ... 2013-07-25 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/19599 PR target/57731 PR target/57748 Are you sure about the 57748 reference? Looks to me like it should reference 57837 instead. /Mikael * config/arm/arm.md (*sibcall_value_insn): Replace use of Ss with US. Adjust output for v5 and v4t. (*sibcall_value_insn): Likewise and loosen predicate on operand0. * config/arm/constraints.md (Ss): Rename to US.
Re: [PATCH 00/11] Rewrite of pass management
On 26/07/13 16:04, David Malcolm wrote: The following patch series eliminates the mutable global variables representing GCC's passes, allowing for multiple compilation contexts in one process, potentially with different combinations of passes (e.g. JIT-compilation of JavaScript in one thread, JIT-compilation of OpenGL shader programs in another) and with pass instances owning additional data, including GC references. The opt_pass hierarchy becomes a true C++ class hierarchy. Patch 1 introduces a gcc::pipeline class and moves various non-GTY globals relating to pass management into it. The gcc::context gains its first field: a pointer to the gcc::pipeline instance. Why 'pipeline'? Given that we already use the term for hardware scheduling, it seems particularly confusing to use that term here for something that seems to be completely unrelated. R.
Re: [PATCH, libgcc] Fix licenses on several files
On 28/07/13 23:03, Maxim Kuvyrkov wrote: While verifying license compliance for GCC and its libraries I noticed that several libgcc files that end up in the final library are licensed under GPL-3.0+ instead of GPL-3.0-with-GCC-exception. This is, obviously, was not the intention of developers who just copied wrong boilerplate text, and this patch fixes the oversights. Just to avoid any possible fallout from this issue ... Marcus, did you and ARM intend to license config/aarch64/sfp-machine.h and config/aarch64/sync-cache.c under GPL-3.0-with-GCC-exception? Our intention was to use GPL3.0 with GCC exception and therefore have no objection to this change, however I have no idea what the appropriate process is in FSF/GCC for such a change. /Marcus Sriram, did you and Google intend to license config/i386/cpuinfo.c under GPL-3.0-with-GCC-exception? Richard, did you and Red Hat intend to license config/ia64/unwind-ia64.h under GPL-3.0-with-GCC-exception? DJ, did you and Red Hat intend to license config/mips/vr4120-div.S under GPL-3.0-with-GCC-exception? Once confirmed, I will apply this patch to all active branches: trunk, gcc-4_8-branch and gcc-4_7-branch. Thank you, -- Maxim Kuvyrkov www.kugelworks.com
RE: [PATCH][4.8 backport] Fix PR57735
Ping? Thanks, Kyrill -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 23 July 2013 10:09 To: 'Richard Sandiford' Cc: gcc-patches; mi...@it.uu.se; 'Richard Biener' Subject: RE: [PATCH][4.8 backport] Fix PR57735 Hi Richard, Richard Sandiford rdsandif...@googlemail.com writes: Kyrylo Tkachov kyrylo.tkac...@arm.com writes: Hi all, The fix for PR57735 is in current trunk (for a different issue I think), just needs a backport to 4.8. It is r198462 by Richard Sandiford: 2013-04-30 Richard Sandiford rsand...@linux.vnet.ibm.com * explow.c (plus_constant): Pass mode to immed_double_int_const. Use gen_int_mode rather than GEN_INT. Ok to backport to the 4.8 branch? Sorry for dropping the ball. It's already been approved for 4.8, and I think I even remembered to test it ready for commit. I just never actually hit commit afterwards :-( *sigh*. Scratch that. I'd confused it with: 2013-05-22 Richard Sandiford rsand...@linux.vnet.ibm.com * recog.c (offsettable_address_addr_space_p): Fix calculation of address mode. Move pointer mode initialization to the same place. which I _did_ apply to 4.8. Sorry about the confusion instead... It's ok, didn't have time to act on the confusion anyway :) So is the proposed one ok to backport? I've bootstrapped it on arm-none-linux-gnueabihf and tested on arm-none-eabi with qemu. Thanks, Kyrill
[PATCH, i386]: Fix PR57954 - AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
Hello!
Attached patch (that is in fact a variant of HJ's patch) implements
clearing of SSE target register before cvt* instructions (the same
approach as ICC takes).
While there, there is also no need to check for SUBREGs in post-reload
splitters.
2013-07-29 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.md (float post-reload splitters): Do not check
for subregs of SSE registers.
2013-07-29 Uros Bizjak ubiz...@gmail.com
H.J. Lu hongjiu...@intel.com
PR target/57954
PR target/57988
* config/i386/i386.md (post-reload splitter
to avoid partial SSE reg dependency stalls): New.
Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
{,-m32} and committed to mainline.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 201298)
+++ config/i386/i386.md (working copy)
@@ -4596,10 +4596,7 @@
(clobber (match_operand:SWI48 2 memory_operand))]
SSE_FLOAT_MODE_P (MODEF:MODEmode) TARGET_MIX_SSE_I387
TARGET_INTER_UNIT_CONVERSIONS
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+reload_completed SSE_REG_P (operands[0])
[(set (match_dup 0) (float:MODEF (match_dup 1)))])
(define_split
@@ -4608,10 +4605,7 @@
(clobber (match_operand:SWI48 2 memory_operand))]
SSE_FLOAT_MODE_P (MODEF:MODEmode) TARGET_MIX_SSE_I387
!(TARGET_INTER_UNIT_CONVERSIONS || optimize_function_for_size_p (cfun))
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+reload_completed SSE_REG_P (operands[0])
[(set (match_dup 2) (match_dup 1))
(set (match_dup 0) (float:MODEF (match_dup 2)))])
@@ -4697,10 +4691,7 @@
(clobber (match_operand:SI 2 memory_operand))]
TARGET_SSE2 TARGET_SSE_MATH
TARGET_USE_VECTOR_CONVERTS optimize_function_for_speed_p (cfun)
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+reload_completed SSE_REG_P (operands[0])
[(const_int 0)]
{
rtx op1 = operands[1];
@@ -4740,10 +4731,7 @@
(clobber (match_operand:SI 2 memory_operand))]
TARGET_SSE2 TARGET_SSE_MATH
TARGET_USE_VECTOR_CONVERTS optimize_function_for_speed_p (cfun)
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+reload_completed SSE_REG_P (operands[0])
[(const_int 0)]
{
operands[3] = simplify_gen_subreg (ssevecmodemode, operands[0],
@@ -4764,10 +4752,7 @@
(float:MODEF (match_operand:SI 1 register_operand)))]
TARGET_SSE2 TARGET_SSE_MATH
TARGET_USE_VECTOR_CONVERTS optimize_function_for_speed_p (cfun)
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+reload_completed SSE_REG_P (operands[0])
[(const_int 0)]
{
rtx op1 = operands[1];
@@ -4810,10 +4795,7 @@
(float:MODEF (match_operand:SI 1 memory_operand)))]
TARGET_SSE2 TARGET_SSE_MATH
TARGET_USE_VECTOR_CONVERTS optimize_function_for_speed_p (cfun)
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+reload_completed SSE_REG_P (operands[0])
[(const_int 0)]
{
operands[3] = simplify_gen_subreg (ssevecmodemode, operands[0],
@@ -4872,10 +4854,7 @@
(clobber (match_operand:SWI48 2 memory_operand))]
SSE_FLOAT_MODE_P (MODEF:MODEmode) TARGET_SSE_MATH
(TARGET_INTER_UNIT_CONVERSIONS || optimize_function_for_size_p (cfun))
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+reload_completed SSE_REG_P (operands[0])
[(set (match_dup 0) (float:MODEF (match_dup 1)))])
(define_insn *floatSWI48:modeMODEF:mode2_sse_nointerunit
@@ -4905,10 +4884,7 @@
(clobber (match_operand:SWI48 2 memory_operand))]
SSE_FLOAT_MODE_P (MODEF:MODEmode) TARGET_SSE_MATH
!(TARGET_INTER_UNIT_CONVERSIONS || optimize_function_for_size_p (cfun))
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+reload_completed SSE_REG_P (operands[0])
[(set (match_dup 2) (match_dup 1))
(set (match_dup 0) (float:MODEF (match_dup 2)))])
@@ -4917,10 +4893,7 @@
(float:MODEF (match_operand:SWI48 1 memory_operand)))
(clobber (match_operand:SWI48 2 memory_operand))]
SSE_FLOAT_MODE_P (MODEF:MODEmode) TARGET_SSE_MATH
-reload_completed
-(SSE_REG_P (operands[0])
- || (GET_CODE (operands[0]) == SUBREG
- SSE_REG_P (SUBREG_REG (operands[0]
+
Re: fatal error: gnu/stubs-32.h: No such file
As a consensual first step toward addressing this issue, I suggest the
following patch to the doc. I hope it is clear enough, but suggestions are
obviously welcome. (I haven't even compiled the docs with it, as I'm on my
laptop with little battery.)
Given that I received no feedback, I'd like to submit this doc patch formally.
Tested by doing make info html pdf.
OK to commit to trunk? What about other active release branches?
FX
Index: install.texi
===
--- install.texi(revision 201292)
+++ install.texi(working copy)
@@ -255,6 +255,26 @@ may need to use @option{--disable-stage1
bootstrapping the compiler with such earlier compilers is strongly
discouraged.
+@item C standard library and headers
+
+In order to build GCC, the C standard library and headers must be present
+for all target variants for which target libraries will be built (and not
+only the variant of the host C++ compiler).
+
+This affects the popular @samp{x86_64-unknown-linux-gnu} platform (among
+other multilib targets), for which 64-bit (@samp{x86_64}) and 32-bit
+(@samp{i386}) libc headers are usually packaged separately. If you do a
+build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
+either:
+
+@itemize @bullet
+@item having 32-bit libc developer package properly installed (the exact
+name of the package depends on your distro); otherwise, you may encounter an
+error such as @samp{fatal error: gnu/stubs-32.h: No such file}
+@item building GCC as a 64-bit only compiler, by configuring with the
+option @option{--disable-multilib}
+@end itemize
+
@item GNAT
In order to build the Ada compiler (GNAT) you must already have GNAT
Re: fatal error: gnu/stubs-32.h: No such file
On 07/29/2013 02:06 PM, FX wrote:
+build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
+either:
+
+@itemize @bullet
+@item having 32-bit libc developer package properly installed (the exact
+name of the package depends on your distro); otherwise, you may encounter an
+error such as @samp{fatal error: gnu/stubs-32.h: No such file}
+@item building GCC as a 64-bit only compiler, by configuring with the
+option @option{--disable-multilib}
+@end itemize
Looks good.
This should be
Make sure you either have the 32-bit libc developer package properly
installed (the exact name of the package depends on your distro) or
you must build GCC as a 64-bit-only compiler by configuring with the
--disable-multilib option. Otherwise, you may encounter an
error such as @samp{fatal error: gnu/stubs-32.h: No such file}
Re: [PATCH, libgcc] Fix licenses on several files
On Mon, 29 Jul 2013, Maxim Kuvyrkov wrote: Marcus, did you and ARM intend to license config/aarch64/sfp-machine.h and config/aarch64/sync-cache.c under GPL-3.0-with-GCC-exception? In general I think it's appropriate for sfp-machine.h files to use the soft-fp license (LGPLv2.1+ with exception; soft-fp code is shared by glibc, libgcc and potentially the Linux kernel although the copy there hasn't been merged from glibc for years), although in this case for some reason the AArch64 file in libgcc is substantially different from that in glibc. -- Joseph S. Myers jos...@codesourcery.com
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley a...@redhat.com wrote: There should be a better diagnostic. If you remember, the start of this thread was: Why is it that configure worked but stubs-32.h was not found? That is the correct thing to do. The reply, basically, was: It's too hard. OK, fine, the backup is to Google: fatal error: gnu/stubs-32.h: No such file or directory and have an early hit that tells you that you did not configure some 32 bit developer package you had never heard of before. I guess that's easier than configure tests or #error directives for the folks who do the multi-lib stuff. But we know people are running into this issue and reporting it. Yes. But that on its own is not sufficient to change the default That's a pretty obnoxious comment. I translate it as, I don't care if people are having trouble. It is a nuisance to me to do that and anyone building GCC should already know they need whateveritwas-devel for 32 bits. I guess I can be obnoxious, too. But slightly more politely put: No, we aren't. We're disagreeing about whether it's acceptable to enable a feature by default that breaks the compiler build half way through with an obscure error message. Real systems need features that aren't enabled by default sometimes. The fundamental issue, to me, is: What do you do when you cannot proceed? I think you should detect the issue as *soon as practical* and then *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. This failure is later than it could be and leaves the user hanging and twisting in the wind. Not good.
[PATCH][AArch64] Fix FAIL: gcc.target/aarch64/cmn.c scan-assembler cmn\tw[0-9]
Hi all, Now that combine emits the canonical form for (eq (neg x) (y)) instead of (eq (x) (neg y)), this patch fixes up the corresponding pattern in aarch64 to match that. This enables combine to properly generate the cmn instruction where appropriate. Tested aarch64-none-elf on model. Ok for trunk? Thanks, Kyrill 2013-07-29 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/aarch64/aarch64.md (compare_negmode): Match canonical RTL form. aarch64-cmn.patch Description: Binary data
Re: [PATCH, libgcc] Fix licenses on several files
On Mon, Jul 29, 2013 at 12:10:42PM +0100, Marcus Shawcroft wrote: On 28/07/13 23:03, Maxim Kuvyrkov wrote: While verifying license compliance for GCC and its libraries I noticed that several libgcc files that end up in the final library are licensed under GPL-3.0+ instead of GPL-3.0-with-GCC-exception. This is, obviously, was not the intention of developers who just copied wrong boilerplate text, and this patch fixes the oversights. To be sure it would be good idea to have check for this issue. First question is which files need copyright exception? Second is which files actually have this license. As first approximation I used: git grep Section 7 of GPL version 3 Is that list full or did I missed something?
Re: fatal error: gnu/stubs-32.h: No such file
On 07/29/2013 02:55 PM, Bruce Korb wrote: On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley a...@redhat.com wrote: There should be a better diagnostic. If you remember, the start of this thread was: Why is it that configure worked but stubs-32.h was not found? That is the correct thing to do. The reply, basically, was: It's too hard. It was This is possible, but it's tricky, and it's really important to get it right. We don't want a half-arsed patch. But we know people are running into this issue and reporting it. Yes. But that on its own is not sufficient to change the default That's a pretty obnoxious comment. Oh dear. I translate it as, I don't care if people are having trouble. That's a mistranslation. It means that there are other criteria beyond some people having trouble. Such as, we really want multilibs to be built. It is a nuisance to me to do that and anyone building GCC should already know they need whateveritwas-devel for 32 bits. I guess I can be obnoxious, too. But slightly more politely put: No, we aren't. We're disagreeing about whether it's acceptable to enable a feature by default that breaks the compiler build half way through with an obscure error message. Real systems need features that aren't enabled by default sometimes. The fundamental issue, to me, is: What do you do when you cannot proceed? I think you should detect the issue as *soon as practical* and then *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. Yes! Yes! Yes! Andrew.
Re: [PATCH v4] MIPS: IEEE 754-2008 features support
On Sat, 27 Jul 2013, Richard Sandiford wrote: gcc/ * config/mips/linux.h (GLIBC_DYNAMIC_LINKER): Handle `-mnan=2008'. (UCLIBC_DYNAMIC_LINKER): New macro. * config/mips/linux64.h (GLIBC_DYNAMIC_LINKER32): Handle `-mnan=2008'. (GLIBC_DYNAMIC_LINKER64, GLIBC_DYNAMIC_LINKERN32): Likewise. (UCLIBC_DYNAMIC_LINKER32): Undefine macro first. Handle `-mnan=2008'. (UCLIBC_DYNAMIC_LINKER64): Redefine macro. (UCLIBC_DYNAMIC_LINKERN32): Likewise. * config/mips/mips-modes.def: Remove RESET_FLOAT_FORMAT calls for SF and DF modes. Use ieee_quad_format for TF mode. * config/mips/mips-opts.h (mips_ieee_754_setting): New enum. * config/mips/mips.c (mips_file_start): Output a `.nan' directive. (mips_option_override): Handle `-mnan=legacy'. * config/mips/mips.h (TARGET_CPU_CPP_BUILTINS): Handle `-mabs=2008' and `-mnan=2008'. (OPTION_DEFAULT_SPECS): Add nan default. (ASM_SPEC): Handle `-mnan='. [!HAVE_AS_NAN] (HAVE_AS_NAN): New macro. * config/mips/mips.md (absmode2): Handle `-mabs=2008', update comment accordingly. (negmode2): Likewise. * config/mips/mips.opt (mabs, mnan): New options. * doc/install.texi (Configuration): Document `--with-nan=' option. * doc/invoke.texi (Option Summary): List MIPS `-mabs=' and `-mnan=' options. (MIPS Options): Document them. * config.gcc mips*-*-*: Handle `--with-nan='. * configure.ac mips*-*-*: Check for GAS `-mnan=2008' support. * configure: Regenerate. * config.in: Regenerate. gcc/testsuite/ * gcc.target/mips/fabs-2008.c: New test case. * gcc.target/mips/fabs-legacy.c: New test case. * gcc.target/mips/fabsf-2008.c: New test case. * gcc.target/mips/fabsf-legacy.c: New test case. * gcc.target/mips/fneg-2008.c: New test case. * gcc.target/mips/fneg-legacy.c: New test case. * gcc.target/mips/fneg-2008.c: New test case. * gcc.target/mips/fneg-legacy.c: New test case. * gcc.target/mips/nan-2008.c: New test case. * gcc.target/mips/nan-legacy.c: New test case. * gcc.target/mips/nanf-2008.c: New test case. * gcc.target/mips/nanf-legacy.c: New test case. * gcc.target/mips/nans-2008.c: New test case. * gcc.target/mips/nans-legacy.c: New test case. * gcc.target/mips/nansf-2008.c: New test case. * gcc.target/mips/nansf-legacy.c: New test case. * gcc.target/mips/mips.exp: Handle `-mabs=' and `-mnan='. OK, thanks. Committed now, thanks for your review. Maciej
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE = CLASS
I think that Janus's OK of the 27th was already enough :-)
The tweaks that you have made since make it look much cleaner. So,
once more - OK for trunk.
Agreed. Sorry for the late reply,
Janus
On 27 July 2013 21:51, Tobias Burnus bur...@net-b.de wrote:
Tobias Burnus wrote:
Giving up on the class.c version, would be the following change okay?
+ if (expr1-ts.type == BT_DERIVED expr2-ts.type == BT_CLASS
+ expr2-expr_type != EXPR_FUNCTION)
+{
+ gfc_add_data_component (expr2);
+ /* The following is required as gfc_add_data_component doesn't
+update ts.type if there is a tailing REF_ARRAY. */
+ expr2-ts.type = BT_DERIVED;
+}
It still feels a bit like a hack - but it is definitely much cleaner than
my previous band aid.
Built and regtested on x86-64-gnu-linux.
OK?
Attached is now the patch which does what I wrote above.
OK?
Tobias
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Re: [PATCH 00/11] Rewrite of pass management
On Mon, 2013-07-29 at 11:19 +0100, Richard Earnshaw wrote:
On 26/07/13 16:04, David Malcolm wrote:
The following patch series eliminates the mutable global variables
representing GCC's passes, allowing for multiple compilation contexts in
one process, potentially with different combinations of passes
(e.g. JIT-compilation of JavaScript in one thread, JIT-compilation
of OpenGL shader programs in another) and with pass instances owning
additional data, including GC references.
The opt_pass hierarchy becomes a true C++ class hierarchy.
Patch 1 introduces a gcc::pipeline class and moves various non-GTY
globals relating to pass management into it. The gcc::context gains its
first field: a pointer to the gcc::pipeline instance.
Why 'pipeline'? Given that we already use the term for hardware
scheduling, it seems particularly confusing to use that term here for
something that seems to be completely unrelated.
How about gcc::pass_manager? (retaining passes as the typical name
for instances, for brevity), so we'd have this method within
gcc::context:
pass_manager get_passes () { gcc_assert (passes_); return *passes_; }
and pipeline.h would become pass_manager.h
(and probably with a using gcc::pass_manager; to avoid spelling out
the namespace everywhere).
Re: [c++-concepts] __is_same_as
Looks good. Jason
Re: [PATCH 03/11] Handwritten part of conversion of passes to C++ classes
On Sun, 2013-07-28 at 10:37 +0200, Basile Starynkevitch wrote:
On Fri, 2013-07-26 at 11:04 -0400, David Malcolm wrote:
This patch is the hand-written part of the conversion of passes from
C structs to C++ classes. It does not work without the subsequent
autogenerated part, which is huge.
Given that the autogenerated part of the conversion is very large
(500k), for the sake of human comprehension I have kept the change as
two separate patches to keep the hand-written changes separate from the
automatically-generated ones. I would commit these as two separate
changes to SVN in order to keep this readability for posterity in the
logs as well as at review-time.
This pair of patches eliminates the mutable global variables
representing the passes, allowing for multiple compilation contexts in
one process, potentially with different combinations of passes, and with
pass instance owning additional data.
It converts the hierarchy of opt_pass types into an actual C++ class
hierarchy, where each of:
* gimple_opt_pass
* rtl_opt_pass
* ipa_opt_pass_d
* simple_ipa_opt_pass
all become subclasses of opt_pass.
[...]
This looks good to me. I suggest adding into the `opt_pass` class two
constant fields for the approximate source location of the pass, e.g. a
field const char* _file; and another const unsigned _lineno; initialized
with __FILE__ and __LINE__ respectively.
This won't cost much (we don't have zillions of instances of
opt_pass) and would help a lot finding where (in which source file)
an actual pass is.
This is particularly useful for newbies writing plugins (which are
trying to add new passes). It takes a lot of time to them to find which
actual source file inside the compiler is implementing a given
(existing) pass.
Thanks - I like this idea. As a relative newbie myself, I've often
found myself hunting down the implementation of a specific pass, and it
seems like your idea is something we'd want to expose in plugins such as
MELT and the Python plugin - I wrote a script to draw a subway map of
GCC's passes:
https://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
and it would be great to be able to add hyperlinks to the relevant
passes.
So this would be an extra (const char*) and int per pass, or per pass
instance, giving about 2 kilobytes of extra memory usage, which sounds
acceptable to me. We could either put it in the pass_data instance, so
that this could look like this (and be purely const):
const pass_data pass_data_vrp =
{
GIMPLE_PASS, /* type */
vrp, /* name */
OPTGROUP_NONE, /* optinfo_flags */
true, /* has_gate */
true, /* has_execute */
TV_TREE_VRP, /* tv_id */
PROP_ssa, /* properties_required */
0, /* properties_provided */
0, /* properties_destroyed */
0, /* todo_flags_start */
( TODO_cleanup_cfg | TODO_update_ssa
| TODO_verify_ssa
| TODO_verify_flow ), /* todo_flags_finish */
__FILE__, __LINE__,
* ^^^ New stuff here
};
or in the opt_pass itself, looking like:
class pass_vrp : public gimple_opt_pass
{
public:
pass_vrp(gcc::context *ctxt)
: gimple_opt_pass(pass_data_vrp, ctxt, __FILE__, __LINE__)
*^^
*^ New stuff here
{}
A related idea occurred to me: adding links to the *documentation* of
the specific passes: right now, if you want to go from a pass to the
documentation of said pass, there doesn't seem to be a consistent URL
pattern. For example, tree-vrp.c defines pass_vrp, with name vrp,
but the documentation is in
@item Value range propagation
within passes.texi
In the HTML build of the documentation, this is documented on this page:
http://gcc.gnu.org/onlinedocs/gccint/Tree-SSA-passes.html#Tree-SSA-passes
though the generated HTML appears to have no per-pass anchors; all I see
is:
liValue range propagation
followed by a p tag (it's also not-well-formed as XHTML, but that's a
whole other issue).
So it would be great if
(a) the pass docs had per-pass anchors and
(b) the runtime pass metadata contained enough information so that we
could generate URLs to the docs, so that e.g. you could ask for docs at
the command-line and get sane URLs.
It may be possible to achieve (b) by making the anchors in (a) be the
pass names.
Re: [PATCH] Add atomic type qualifier
On 07/28/2013 03:34 PM, Joseph S. Myers wrote: On Fri, 26 Jul 2013, Andrew MacLeod wrote: What it doesn't do: * It doesn't implement the stdatomic.h header - do you intend that to be provided by GCC or glibc? (Substantive review of the full patch still to come.) I figured gcc would provide it... but I hadn't given it a ton of thought on whether that was good or bad. again, that sort of thing isn't really my strong suit :-) * It doesn't implement the C11 expression expansion into atomic built-ins. ie, you can't write: _Atomic int x; x = 0; and have the result be an atomic operation calling __atomic_store (x, 0). That will be in a follow on patch. So none of the expression expansion from C11 is included yet. This just enables that. The hardest part will probably be compound assignment to an atomic object where either operand of the assignment has floating-point type - see C11 footnote 113, but you can't actually use feholdexcept or feclearexcept or feupdateenv here because that would introduce libm dependencies, so back ends will need to provide appropriate insn patterns to do those operations inline. Blick. What were they smoking the night before... I guess we'll probably need to enhance the current atomic patterns in RTL...We should be able to figure out that its floating point and invoke the appropriate RTL pattern during expansion rather than an existing one.OR just frigging call libatomic and let it deal with it. :-) I guess there wouldnt be any other fallback available. Actually, thats a mess... no way for the librtary to know its floating point unless you tell it somehow with new entry points or somesuch.. very lame. I planned to do the work in gimplification... let the atomic decls through, and during gimplification, loads or stores of an atomic decl would be converted to the appropriate load or store builtin, and at the same time recognize the 'decl = decl op value' expression and replace those as appropriate with atomic_op_fetch operations. I had discussed this at some length with Lawrence crowl and Jeffrey Yasskin some time ago.. At gimplification time we no longer know whether the original form was decl op= val or decl = decl op val;, but the decision was that it is ok to recognize decl = decl op val and make that atomic.. it would still satisfy the language requirements.. Andrew
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
On Thu, 2013-07-18 at 07:56 -0700, Andrew Pinski wrote: On Thu, Jul 18, 2013 at 4:33 AM, David Malcolm dmalc...@redhat.com wrote: On Thu, 2013-07-18 at 00:08 -0700, Andrew Pinski wrote: On Wed, Jul 17, 2013 at 6:18 PM, David Malcolm dmalc...@redhat.com wrote: gcc/ Explicitly number the instances of passes within passes.def. This is needed by a subsequent patch so that we can create fields within the pipeline class for each pass instance (to help locate pass instances when debugging). * passes.c (NEXT_PASS_NUM): Define. * passes.def (NEXT_PASS, NEXT_PASS_NUM): Replace uses of NEXT_PASS on passes that have multiple instances with uses of NEXT_PASS_NUM. I don't like this patch at all. Mainly because the numbers can get out of sync very quickly especially when it comes to internal versions of the compiler where it is normal to reorder passes and add another pass a few times. How would you feel about a passes.def.in and having that be what's in svn, with some kind of preprocessing step that builds a passes.def from it? That way we get the flexibility of before, but gain the ability I'm looking for to make a class holding the passes, and have easy access in gdb to the various instances of the class (rather than just the last instance of each that was created). That would work and would be ok with me. If so, what tools are blessed for usage at build time? (I'd prefer Python, but I don't think that's a build-time dep yet). So far awk and shell and C programming are the blessed processing tools. Awk in this case seems like the best for this though. I don't think Python is a good solution only because it does add another build dependency that is not there already though I would not complain about it if it gets added. FWIW I implemented this approach, and the result can be seen in: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01263.html in the patch series I sent for review on Friday. Thanks Dave
Re: [PATCH] Add atomic type qualifier
On Mon, 29 Jul 2013, Andrew MacLeod wrote: Blick. What were they smoking the night before... I guess we'll probably need to enhance the current atomic patterns in RTL...We should be able to figure out that its floating point and invoke the appropriate RTL pattern during expansion rather than an existing one.OR just frigging call libatomic and let it deal with it. :-) I guess there wouldnt be any other fallback available. Actually, thats a mess... no way for the librtary to know its floating point unless you tell it somehow with new entry points or somesuch.. very lame. Note that you only need *one* of the types to be floating-point for this issue to apply. If you have _Atomic char c; float f; c /= f; then all the same requirements apply; there may be exceptions to discard not just from the division, but from the conversion of a float division result to char. I planned to do the work in gimplification... let the atomic decls through, and during gimplification, loads or stores of an atomic decl would be converted to the appropriate load or store builtin, and at the same time recognize the 'decl = decl op value' expression and replace those as appropriate with atomic_op_fetch operations. I had discussed this at some length with Lawrence crowl and Jeffrey Yasskin some time ago.. At gimplification time we no longer know whether the original form was decl op= val or decl = decl op val;, but the decision was that it is ok to recognize decl = decl op val and make that atomic.. it would still satisfy the language requirements.. I think that's probably OK (though, is this a theorem of the formal modelling work that has been done on the memory model?), but note it's not just a decl but an arbitrary pointer dereference (the address of the lvalue is only evaluated once, no matter how many compare-and-exchange operations are needed), and the operation may end up looking like *ptr = (convert to type of *ptr) ((promote) *ptr op (promote) val) rather than a simple decl = decl op val. Or something more complicated if the operation involves complex numbers - look at what gets for mixed real / complex arithmetic, for example. Given _Atomic _Complex float f; double d; f += d; the atomicity is for the whole complex number (and so the compare-and-exchange needs to work on the whole number) although only the real part is modified by the addition. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Add atomic type qualifier
On 07/29/2013 10:59 AM, Andrew MacLeod wrote: Blick. What were they smoking the night before... I guess we'll probably need to enhance the current atomic patterns in RTL...We should be able to figure out that its floating point and invoke the appropriate RTL pattern during expansion rather than an existing one.OR just frigging call libatomic and let it deal with it. :-) I guess there wouldnt be any other fallback available. Actually, thats a mess... no way for the librtary to know its floating point unless you tell it somehow with new entry points or somesuch.. very lame. Actually, in hind sight, we will need new atomic builtins It lists other operators we need to support that we currently do not: They list *, / , % + -^ | we currently don't support *,/, modulus, right or left shift. Maybe the simple thing is simply to emit the compare_exchange loop for all these, and not bother libatomic with them at all.We can eventually add rtl patterns for them if we want better performance for these new bits. As for the floating point operations, emit the same loop, and if there is a target pattern emit it, otherwise issue a warning saying those footnote items are not properly protected or whatever. Also, If I read this right, arithmetic type also includes complex type does it not? which means we need to support this for complex as well... Does C++14(or onward) intend to support these additions as well? Andrew
[PATCH v2 01/18] clean up SHLIB so subshells are not needed
This changes the handling of SHLIB so that it is inlined into
DRIVER_DEFINES. This is ok because SHLIB is defined in a Makefile
fragment that is included by the generated Makefile.
The rationale for this is that it simplifies some .o targets, so that
we can share more code.
* Makefile.in (DRIVER_DEFINES): Use $(and), not shell code,
to add -DENABLE_SHARED_LIBGCC.
(gcc.o): Don't use subshell.
* Make-lang.in (c/gccspec.o): Don't use subshell.
* Make-lang.in (g++spec.o): Don't use subshell.
* Make-lang.in (gfortranspec.o): Don't use subshell.
* Make-lang.in (gospec.o): Don't use subshell.
* Make-lang.in (jvspec.o): Don't use subshell.
---
gcc/Makefile.in | 5 ++---
gcc/c/Make-lang.in | 3 +--
gcc/cp/Make-lang.in | 3 +--
gcc/fortran/Make-lang.in | 3 +--
gcc/go/Make-lang.in | 3 +--
gcc/java/Make-lang.in| 3 +--
6 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index fb0cb4b..ce5b159 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2056,16 +2056,15 @@ DRIVER_DEFINES = \
-DTOOLDIR_BASE_PREFIX=\$(libsubdir_to_prefix)$(prefix_to_exec_prefix)\ \
@TARGET_SYSTEM_ROOT_DEFINE@ \
$(VALGRIND_DRIVER_DEFINES) \
- `test X$${SHLIB} = X || test @enable_shared@ != yes || echo
-DENABLE_SHARED_LIBGCC` \
+ $(and $(SHLIB),$(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC) \
-DCONFIGURE_SPECS=\@CONFIGURE_SPECS@\
gcc.o: gcc.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) intl.h multilib.h \
Makefile $(lang_specs_files) specs.h prefix.h $(GCC_H) $(FLAGS_H) \
configargs.h $(OBSTACK_H) $(OPTS_H) $(DIAGNOSTIC_H) $(VEC_H) $(PARAMS_H)
- (SHLIB='$(SHLIB)'; \
$(COMPILER) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \
$(DRIVER_DEFINES) \
- -c $(srcdir)/gcc.c $(OUTPUT_OPTION))
+ -c $(srcdir)/gcc.c $(OUTPUT_OPTION)
specs.h : s-specs ; @true
s-specs : Makefile
diff --git a/gcc/c/Make-lang.in b/gcc/c/Make-lang.in
index 1161742..86deb1d 100644
--- a/gcc/c/Make-lang.in
+++ b/gcc/c/Make-lang.in
@@ -46,10 +46,9 @@ c: cc1$(exeext)
# is to cc1 as e.g. g++ is to cc1plus, or gfortran is to f951).
c/gccspec.o: c/gccspec.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(GCC_H) \
$(OPTS_H)
- (SHLIB='$(SHLIB)'; \
$(COMPILER) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \
$(DRIVER_DEFINES) \
- -c $(srcdir)/c/gccspec.c $(OUTPUT_OPTION))
+ -c $(srcdir)/c/gccspec.c $(OUTPUT_OPTION)
# The C compiler itself.
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 2cb919a..da8e87b 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -53,9 +53,8 @@ c++: cc1plus$(exeext)
g++spec.o: $(srcdir)/cp/g++spec.c $(SYSTEM_H) coretypes.h $(TM_H) $(GCC_H) \
$(CONFIG_H) $(OPTS_H)
- (SHLIB='$(SHLIB)'; \
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
- $(INCLUDES) $(srcdir)/cp/g++spec.c)
+ $(INCLUDES) $(srcdir)/cp/g++spec.c
# Create the compiler driver for g++.
GXX_OBJS = $(GCC_OBJS) g++spec.o
diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
index ee70423..035a1d5 100644
--- a/gcc/fortran/Make-lang.in
+++ b/gcc/fortran/Make-lang.in
@@ -78,9 +78,8 @@ fortran: f951$(exeext)
gfortranspec.o: $(srcdir)/fortran/gfortranspec.c $(SYSTEM_H) $(TM_H) $(GCC_H) \
$(CONFIG_H) coretypes.h intl.h $(OPTS_H)
- (SHLIB='$(SHLIB)'; \
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
- $(INCLUDES) $(srcdir)/fortran/gfortranspec.c)
+ $(INCLUDES) $(srcdir)/fortran/gfortranspec.c
# Create the compiler driver gfortran.
GFORTRAN_D_OBJS = $(GCC_OBJS) gfortranspec.o
diff --git a/gcc/go/Make-lang.in b/gcc/go/Make-lang.in
index 3cb18d6..015ed7a 100644
--- a/gcc/go/Make-lang.in
+++ b/gcc/go/Make-lang.in
@@ -32,9 +32,8 @@ go: go1$(exeext)
gospec.o: $(srcdir)/go/gospec.c $(SYSTEM_H) coretypes.h $(TM_H) $(GCC_H) \
$(CONFIG_H) opts.h
- (SHLIB='$(SHLIB)'; \
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
- $(INCLUDES) $(srcdir)/go/gospec.c)
+ $(INCLUDES) $(srcdir)/go/gospec.c
GCCGO_OBJS = $(GCC_OBJS) gospec.o
gccgo$(exeext): $(GCCGO_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS)
diff --git a/gcc/java/Make-lang.in b/gcc/java/Make-lang.in
index 8a6210f..078f6d4 100644
--- a/gcc/java/Make-lang.in
+++ b/gcc/java/Make-lang.in
@@ -57,9 +57,8 @@ JAVA_TARGET_INDEPENDENT_BIN_TOOLS = jcf-dump
jvspec.o: $(srcdir)/java/jvspec.c $(SYSTEM_H) coretypes.h $(TM_H) \
$(GCC_H) $(CONFIG_H) java/jcf.h java/javaop.h $(OPTS_H)
- (SHLIB='$(SHLIB)'; \
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
- $(INCLUDES) $(srcdir)/java/jvspec.c $(OUTPUT_OPTION))
+ $(INCLUDES) $(srcdir)/java/jvspec.c $(OUTPUT_OPTION)
# Create the compiler driver for $(XGCJ).
$(XGCJ)$(exeext): $(GCC_OBJS)
[PATCH v2 00/18] resurrect automatic dependencies
This is a refresh of my series to resurrect automatic dependency tracking. v1 was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01218.html Compared to v1: * I ran the hanging test using GNU make 3.81 on each revision, as detailed: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01267.html * I introduced a POSTCOMPILE step. This helps cope with dependency issues if gcc is interrupted. See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35697 This came up during review of the original patch, ages ago. * I've rebased a few times so that it applies to current trunk. Ok? Tom
[PATCH v2 02/18] update generated_files
A few generated files were not mentioned in the generated_files variable. This fixes the problem. * Makefile.in (generated_files): Add options.h, target-hooks-def.h, insn-opinit.h, common/common-target-hooks-def.h. --- gcc/Makefile.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index ce5b159..f13ea01 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3856,7 +3856,9 @@ s-gtype: build/gengtype$(build_exeext) $(filter-out [%], $(GTFILES)) \ generated_files = config.h tm.h $(TM_P_H) $(TM_H) multilib.h \ $(simple_generated_h) specs.h \ tree-check.h genrtl.h insn-modes.h tm-preds.h tm-constrs.h \ - $(ALL_GTFILES_H) gtype-desc.c gtype-desc.h gcov-iov.h + $(ALL_GTFILES_H) gtype-desc.c gtype-desc.h gcov-iov.h \ + options.h target-hooks-def.h insn-opinit.h \ + common/common-target-hooks-def.h # In order for parallel make to really start compiling the expensive # objects from $(OBJS) as early as possible, build all their -- 1.8.1.4
[PATCH v2 06/18] convert the C++ front end to automatic dependencies
This converts the C++ front end. This renames g++spec.o to cp/g++spec.o for uniformity. This lets us remove an explicit rule. This patch does not remove various *_H macros from cp/Make-lang.in. These are still needed by ObjC++. They're removed by a later patch. * Make-lang.in (g++spec.o): Remove. (CFLAGS-cp/g++spec.o): New variable. (GXX_OBJS): Reference cp/g++spec.o. (cc1plus-checksum.o, cp/lex.o, cp/cp-array-notation.o) (cp/cp-lang.o, cp/decl.o, cp/decl2.o, cp/cp-objcp-common.o) (cp/typeck2.o, cp/typeck.o, cp/class.o, cp/call.o) (cp/friend.o, cp/init.o, cp/method.o, cp/cvt.o, cp/search.o) (cp/tree.o, cp/ptree.o, cp/rtti.o, cp/except.o, cp/expr.o) (cp/pt.o, cp/error.o, cp/repo.o, cp/semantics.o, cp/dump.o) (cp/optimize.o, cp/mangle.o, cp/parser.o, cp/cp-gimplify.o) (cp/name-lookup.o, cp/cxx-pretty-print.o): Remove. --- gcc/cp/Make-lang.in | 95 ++--- 1 file changed, 2 insertions(+), 93 deletions(-) diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in index da8e87b..43b7003 100644 --- a/gcc/cp/Make-lang.in +++ b/gcc/cp/Make-lang.in @@ -51,13 +51,10 @@ c++: cc1plus$(exeext) # Tell GNU make to ignore these if they exist. .PHONY: c++ -g++spec.o: $(srcdir)/cp/g++spec.c $(SYSTEM_H) coretypes.h $(TM_H) $(GCC_H) \ -$(CONFIG_H) $(OPTS_H) - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \ - $(INCLUDES) $(srcdir)/cp/g++spec.c +CFLAGS-cp/g++spec.o += $(DRIVER_DEFINES) # Create the compiler driver for g++. -GXX_OBJS = $(GCC_OBJS) g++spec.o +GXX_OBJS = $(GCC_OBJS) cp/g++spec.o xg++$(exeext): $(GXX_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS) +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(GXX_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a \ @@ -96,8 +93,6 @@ cc1plus-checksum.c : build/genchecksum$(build_exeext) checksum-options \ checksum-options cc1plus-checksum.c.tmp \ $(srcdir)/../move-if-change cc1plus-checksum.c.tmp cc1plus-checksum.c -cc1plus-checksum.o : cc1plus-checksum.c $(CONFIG_H) $(SYSTEM_H) - cc1plus$(exeext): $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(LIBDEPS) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS) @@ -261,89 +256,3 @@ CXX_TREE_H = $(TREE_H) cp/name-lookup.h cp/cp-tree.h $(C_COMMON_H) \ $(srcdir)/../include/hashtab.h CXX_PARSER_H = tree.h $(CXX_TREE_H) c-family/c-pragma.h cp/parser.h CXX_PRETTY_PRINT_H = cp/cxx-pretty-print.h $(C_PRETTY_PRINT_H) - -cp/lex.o: cp/lex.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \ - $(C_PRAGMA_H) input.h cp/operators.def $(TM_P_H) \ - c-family/c-objc.h -cp/cp-array-notation.o: cp/cp-array-notation.c $(CONFIG_H) $(SYSTEM_H) \ - coretypes.h $(TREE_H) $(CXX_TREE_H) $(DIAGNOSTIC_H) tree-iterator.h vec.h \ - $(GIMPLE_H) c-family/array-notation-common.o $(C_COMMON_H) -cp/cp-lang.o: cp/cp-lang.c $(CXX_TREE_H) $(TM_H) debug.h langhooks.h \ - $(LANGHOOKS_DEF_H) $(C_COMMON_H) gtype-cp.h gt-cp-cp-lang.h \ - cp/cp-objcp-common.h $(EXPR_H) $(TARGET_H) $(CXX_PARSER_H) -cp/decl.o: cp/decl.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) cp/decl.h \ - output.h toplev.h $(HASHTAB_H) $(RTL_H) \ - cp/operators.def $(TM_P_H) $(TREE_INLINE_H) $(DIAGNOSTIC_H) $(C_PRAGMA_H) \ - debug.h gt-cp-decl.h $(TIMEVAR_H) $(TARGET_H) $(PLUGIN_H) \ - intl.h tree-iterator.h pointer-set.h $(SPLAY_TREE_H) \ - c-family/c-objc.h -cp/decl2.o: cp/decl2.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) cp/decl.h \ - toplev.h $(C_COMMON_H) gt-cp-decl2.h $(CGRAPH_H) \ - $(C_PRAGMA_H) dumpfile.h intl.h $(TARGET_H) $(GIMPLE_H) pointer-set.h \ - $(SPLAY_TREE_H) c-family/c-ada-spec.h \ - c-family/c-objc.h -cp/cp-objcp-common.o : cp/cp-objcp-common.c $(CONFIG_H) $(SYSTEM_H) \ - coretypes.h $(TM_H) $(TREE_H) $(CXX_TREE_H) $(C_COMMON_H) \ - langhooks.h $(LANGHOOKS_DEF_H) $(DIAGNOSTIC_H) debug.h \ - $(CXX_PRETTY_PRINT_H) cp/cp-objcp-common.h gt-cp-cp-objcp-common.h -cp/typeck2.o: cp/typeck2.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \ - $(TM_P_H) $(DIAGNOSTIC_CORE_H) gt-cp-typeck2.h $(REAL_H) intl.h -cp/typeck.o: cp/typeck.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) $(PARAMS_H) \ - toplev.h $(DIAGNOSTIC_H) convert.h $(C_COMMON_H) $(TARGET_H) \ - c-family/c-objc.h -cp/class.o: cp/class.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) toplev.h \ - $(TARGET_H) convert.h $(CGRAPH_H) dumpfile.h gt-cp-class.h \ - $(SPLAY_TREE_H) pointer-set.h $(HASH_TABLE_H) -cp/call.o: cp/call.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) toplev.h \ - $(DIAGNOSTIC_CORE_H) intl.h gt-cp-call.h convert.h $(TARGET_H) langhooks.h \ - $(TIMEVAR_H) c-family/c-objc.h -cp/friend.o: cp/friend.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) -cp/init.o: cp/init.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \ - $(EXCEPT_H) $(TARGET_H) -cp/method.o: cp/method.c $(CXX_TREE_H) $(TM_H) toplev.h \ - $(TM_P_H) $(TARGET_H) $(DIAGNOSTIC_H) gt-cp-method.h $(GIMPLE_H) \ -
[PATCH v2 03/18] move generated_files order-only dependency later
There is an order-only dependency in gcc/Makefile.in that tries to build the generated files before compiling regular objects. However, this appears too early, and so at the time it is seen by make, GCOV_OBJS and GCOV_DUMP_OBJS have not yet been set. This patch fixes the problem and prevents any future problems of this nature by moving the order-only dependency to the end of Makefile.in. This also adds lto-wrapper.o to ALL_HOST_BACKEND_OBJS. * Makefile.in (ALL_HOST_BACKEND_OBJS): Add lto-wrapper.o. ($(ALL_HOST_OBJS)): Move order-only dependency to end of file. --- gcc/Makefile.in | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index f13ea01..6ba2e93 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1493,7 +1493,8 @@ ALL_HOST_FRONTEND_OBJS = $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) $(OBJS-libcommon) \ $(OBJS-libcommon-target) @TREEBROWSER@ main.o c-family/cppspec.o \ - $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) + $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) \ + lto-wrapper.o # This lists all host object files, whether they are included in this # compilation or not. @@ -3860,11 +3861,6 @@ generated_files = config.h tm.h $(TM_P_H) $(TM_H) multilib.h \ options.h target-hooks-def.h insn-opinit.h \ common/common-target-hooks-def.h -# In order for parallel make to really start compiling the expensive -# objects from $(OBJS) as early as possible, build all their -# prerequisites strictly before all objects. -$(ALL_HOST_OBJS) : | $(generated_files) - # # How to compile object files to run on the build machine. @@ -5357,3 +5353,8 @@ po/gcc.pot: force $(MAKE) srcextra AWK=$(AWK) $(SHELL) $(srcdir)/po/exgettext \ $(XGETTEXT) gcc $(srcdir) + +# In order for parallel make to really start compiling the expensive +# objects from $(OBJS) as early as possible, build all their +# prerequisites strictly before all objects. +$(ALL_HOST_OBJS) : | $(generated_files) -- 1.8.1.4
[PATCH v2 05/18] convert the C front end to automatic dependencies
This converts the C front end. Note that this fixes a latent bug in gcc/Makefile.in's definition of C_TREE_H. This is needed to avoid breaking this build with this patch. * Makefile.in (C_TREE_H): Reference c/c-tree.h. * Make-lang.in (c/gccspec.o): Remove. (CFLAGS-c/gccspec.o): New variable. (cc1-checksum.o, C_TREE_H, c/c-aux-info.o, c/c-convert.o) (c/c-decl.o, c/c-errors.o, c/c-lang.o, c/c-objc-common.o) (c/c-parser.o, c/c-typeck.o, c/c-array-notation.o): Remove. --- gcc/Makefile.in| 2 +- gcc/c/Make-lang.in | 60 +- 2 files changed, 2 insertions(+), 60 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index c663c81..c225e0f 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -928,7 +928,7 @@ INSN_ADDR_H = $(srcdir)/insn-addr.h C_COMMON_H = c-family/c-common.h c-family/c-common.def $(TREE_H) \ $(SPLAY_TREE_H) $(CPPLIB_H) $(GGC_H) $(DIAGNOSTIC_CORE_H) C_PRAGMA_H = c-family/c-pragma.h $(CPPLIB_H) -C_TREE_H = c-tree.h $(C_COMMON_H) $(DIAGNOSTIC_H) +C_TREE_H = c/c-tree.h $(C_COMMON_H) $(DIAGNOSTIC_H) SYSTEM_H = system.h hwint.h $(srcdir)/../include/libiberty.h \ $(srcdir)/../include/safe-ctype.h $(srcdir)/../include/filenames.h PREDICT_H = predict.h predict.def diff --git a/gcc/c/Make-lang.in b/gcc/c/Make-lang.in index 86deb1d..d79fc4f 100644 --- a/gcc/c/Make-lang.in +++ b/gcc/c/Make-lang.in @@ -44,11 +44,7 @@ c: cc1$(exeext) # The C front end driver. This is different from the drivers for other # front ends, because there is no C language specific driver (i.e. nothing # is to cc1 as e.g. g++ is to cc1plus, or gfortran is to f951). -c/gccspec.o: c/gccspec.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(GCC_H) \ -$(OPTS_H) - $(COMPILER) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \ - $(DRIVER_DEFINES) \ - -c $(srcdir)/c/gccspec.c $(OUTPUT_OPTION) +CFLAGS-c/gccspec.o += $(DRIVER_DEFINES) # The C compiler itself. @@ -71,8 +67,6 @@ cc1-checksum.c : build/genchecksum$(build_exeext) checksum-options \ checksum-options cc1-checksum.c.tmp\ $(srcdir)/../move-if-change cc1-checksum.c.tmp cc1-checksum.c -cc1-checksum.o : cc1-checksum.c $(CONFIG_H) $(SYSTEM_H) - cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) \ cc1-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS) @@ -144,55 +138,3 @@ c.stageprofile: stageprofile-start c.stagefeedback: stagefeedback-start -mv c/*$(objext) stagefeedback/c -# -# .o: .h dependencies. -# C language specific files. -C_TREE_H = c/c-tree.h $(C_COMMON_H) $(DIAGNOSTIC_H) -c/c-aux-info.o : c/c-aux-info.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(C_TREE_H) $(TREE_H) $(FLAGS_H) - -c/c-convert.o : c/c-convert.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(TREE_H) $(C_TREE_H) $(FLAGS_H) $(C_COMMON_H) convert.h \ - langhooks.h $(TARGET_H) - -c/c-decl.o : c/c-decl.c c/c-lang.h $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(TREE_H) $(C_TREE_H) $(GGC_H) $(TARGET_H) $(FLAGS_H) $(FUNCTION_H) \ - output.h debug.h toplev.h intl.h $(TM_P_H) $(TREE_INLINE_H) \ - $(TIMEVAR_H) $(OPTS_H) $(C_PRAGMA_H) gt-c-c-decl.h $(CGRAPH_H) \ - $(HASH_TABLE_H) $(LANGHOOKS_DEF_H) \ - dumpfile.h $(C_COMMON_H) $(CPPLIB_H) $(DIAGNOSTIC_CORE_H) \ - $(INPUT_H) langhooks.h pointer-set.h tree-iterator.h \ - $(PLUGIN_H) c-family/c-ada-spec.h c-family/c-objc.h - -c/c-errors.o: c/c-errors.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ - $(C_TREE_H) $(FLAGS_H) $(DIAGNOSTIC_H) $(TM_P_H) - -c/c-lang.o : c/c-lang.c c/c-objc-common.h \ - $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ - $(C_TREE_H) $(DIAGNOSTIC_CORE_H) \ - langhooks.h $(LANGHOOKS_DEF_H) $(C_COMMON_H) gtype-c.h \ - $(C_PRAGMA_H) $(TREE_INLINE_H) - -c/c-objc-common.o : c/c-objc-common.c c/c-objc-common.h \ - $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(TREE_H) $(C_TREE_H) $(FLAGS_H) $(DIAGNOSTIC_H) \ - langhooks.h $(GGC_H) $(C_PRETTY_PRINT_H) intl.h \ - $(TREE_PRETTY_PRINT_H) - -c/c-parser.o : c/c-parser.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(TM_H) $(TREE_H) $(C_TREE_H) $(C_COMMON_H) $(C_PRAGMA_H) $(CPPLIB_H) \ - $(GGC_H) $(TIMEVAR_H) $(INPUT_H) $(FLAGS_H) \ - gt-c-c-parser.h langhooks.h \ - $(VEC_H) $(TARGET_H) $(CGRAPH_H) $(PLUGIN_H) \ - c-family/c-objc.h - -c/c-typeck.o : c/c-typeck.c c/c-lang.h $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(TREE_H) $(C_TREE_H) $(TARGET_H) $(FLAGS_H) intl.h \ - langhooks.h tree-iterator.h $(BITMAP_H) $(GIMPLE_H) \ - c-family/c-objc.h c-family/c-common.h - -c/c-array-notation.o: c/c-array-notation.c c/c-lang.h $(CONFIG_H) \ - $(SYSTEM_H) coretypes.h $(TREE_H) $(C_TREE_H) $(TARGET_H) \ - intl.h output.h $(EXPR_H) langhooks.h
[PATCH v2 07/18] convert the ObjC front end to automatic dependencies
This converts the ObjC front end. Note that there is a latent possible bug in this code -- both ObjC and ObjC++ define START_HDRS. Whichever is included last, wins; if they are out of sync, then something could break. This possibility is eliminated by this series. * Make-lang.in (START_HDRS, cc1obj-checksum.o, objc/objc-lang.o) (objc/objc-runtime-shared-support.o) (objc/objc-gnu-runtime-abi-01.o, objc/objc-next-runtime-abi-01.o) (objc/objc-next-runtime-abi-02.o, objc/objc-act.o) (objc/objc-encoding.o, objc/objc-map.o): Remove. --- gcc/objc/Make-lang.in | 79 --- 1 file changed, 79 deletions(-) diff --git a/gcc/objc/Make-lang.in b/gcc/objc/Make-lang.in index f04d606..02e78fb 100644 --- a/gcc/objc/Make-lang.in +++ b/gcc/objc/Make-lang.in @@ -42,9 +42,6 @@ objc: cc1obj$(exeext) # Tell GNU make to ignore these if they exist. .PHONY: objc -START_HDRS = $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) $(C_TREE_H) \ - c/c-lang.h langhooks.h c-family/c-objc.h objc/objc-act.h - # Use maximal warnings for this front end. objc-warn = $(STRICT_WARN) @@ -65,87 +62,11 @@ cc1obj-checksum.c : build/genchecksum$(build_exeext) checksum-options \ $(BACKEND) $(LIBDEPS) checksum-options cc1obj-checksum.c.tmp \ $(srcdir)/../move-if-change cc1obj-checksum.c.tmp cc1obj-checksum.c -cc1obj-checksum.o : cc1obj-checksum.c $(CONFIG_H) $(SYSTEM_H) - cc1obj$(exeext): $(OBJC_OBJS) $(C_AND_OBJC_OBJS) cc1obj-checksum.o $(BACKEND) $(LIBDEPS) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(OBJC_OBJS) $(C_AND_OBJC_OBJS) cc1obj-checksum.o \ $(BACKEND) $(LIBS) $(BACKENDLIBS) -# Objective C language specific files. - -# When editing, please keep the objc/ header dependencies in -# alphabetical order, and try to use a similar logical order for the -# other files between the different targets. - -objc/objc-lang.o : objc/objc-lang.c \ - $(START_HDRS) \ - $(GGC_H) \ - $(LANGHOOKS_DEF_H) $(C_COMMON_H) gtype-objc.h \ - c/c-objc-common.h - -objc/objc-runtime-shared-support.o : objc/objc-runtime-shared-support.c \ - gt-objc-objc-runtime-shared-support.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - objc/objc-encoding.h \ - objc/objc-next-metadata-tags.h \ - objc/objc-runtime-shared-support.h - -objc/objc-gnu-runtime-abi-01.o: objc/objc-gnu-runtime-abi-01.c \ - gt-objc-objc-gnu-runtime-abi-01.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - toplev.h \ - objc/objc-encoding.h \ - objc/objc-runtime-hooks.h \ - objc/objc-runtime-shared-support.h - -objc/objc-next-runtime-abi-01.o: objc/objc-next-runtime-abi-01.c \ - gt-objc-objc-next-runtime-abi-01.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - $(TARGET_H) \ - objc/objc-encoding.h \ - objc/objc-next-metadata-tags.h \ - objc/objc-runtime-hooks.h \ - objc/objc-runtime-shared-support.h - -objc/objc-next-runtime-abi-02.o: objc/objc-next-runtime-abi-02.c \ - gt-objc-objc-next-runtime-abi-02.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - $(TARGET_H) \ - objc/objc-encoding.h \ - objc/objc-next-metadata-tags.h \ - objc/objc-runtime-hooks.h \ - objc/objc-runtime-shared-support.h - -objc/objc-act.o : objc/objc-act.c \ - gt-objc-objc-act.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - toplev.h $(FUNCTION_H) debug.h $(LANGHOOKS_DEF_H) \ - $(HASH_TABLE_H) $(GIMPLE_H) \ - $(C_PRAGMA_H) $(C_TARGET_H) \ - objc/objc-encoding.h \ - objc/objc-map.h \ - objc/objc-runtime-hooks.h \ - objc/objc-runtime-shared-support.h - -objc/objc-encoding.o : objc/objc-encoding.c \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - $(OBSTACK_H) \ - objc/objc-encoding.h \ - objc/objc-runtime-shared-support.h - -objc/objc-map.o : objc/objc-map.c \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - $(OBSTACK_H) \ - objc/objc-map.h - objc.srcextra: # -- 1.8.1.4
[PATCH v2 08/18] convert the ObjC++ front end to automatic dependencies
This converts the ObjC++ front end. Now we can finally remove the *_H macros from cp/Make-lang.in. * Make-lang.in (CXX_TREE_H, CXX_PARSER_H, CXX_PRETTY_PRINT_H): Remove. * Make-lang.in (START_HDRS, cc1objplus-checksum.o) (objcp/objcp-lang.o, objcp/objcp-decl.o (objcp/objc-runtime-shared-support.o) (objcp/objc-gnu-runtime-abi-01.o objcp/objc-next-runtime-abi-01.o) (objcp/objc-next-runtime-abi-02.o, objcp/objcp-act.o) (objcp/objc-encoding.o, objcp/objc-map.o): Use COMPILE and POSTCOMPILE. Remove explicit dependencies. --- gcc/cp/Make-lang.in| 9 gcc/objcp/Make-lang.in | 128 +++-- 2 files changed, 27 insertions(+), 110 deletions(-) diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in index 43b7003..a7943c8 100644 --- a/gcc/cp/Make-lang.in +++ b/gcc/cp/Make-lang.in @@ -247,12 +247,3 @@ c++.stageprofile: stageprofile-start -mv cp/*$(objext) stageprofile/cp c++.stagefeedback: stagefeedback-start -mv cp/*$(objext) stagefeedback/cp - -# -# .o: .h dependencies. -CXX_TREE_H = $(TREE_H) cp/name-lookup.h cp/cp-tree.h $(C_COMMON_H) \ - $(FUNCTION_H) \ - $(SYSTEM_H) coretypes.h $(CONFIG_H) $(TARGET_H) $(GGC_H) \ - $(srcdir)/../include/hashtab.h -CXX_PARSER_H = tree.h $(CXX_TREE_H) c-family/c-pragma.h cp/parser.h -CXX_PRETTY_PRINT_H = cp/cxx-pretty-print.h $(C_PRETTY_PRINT_H) diff --git a/gcc/objcp/Make-lang.in b/gcc/objcp/Make-lang.in index ec10fc8..4714788 100644 --- a/gcc/objcp/Make-lang.in +++ b/gcc/objcp/Make-lang.in @@ -43,9 +43,6 @@ obj-c++: cc1objplus$(exeext) # Tell GNU make to ignore these if they exist. .PHONY: obj-c++ -START_HDRS = $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) $(CXX_TREE_H) \ - $(CXX_PARSER_H) $(CXX_PRETTY_PRINT_H) langhooks.h c-family/c-objc.h objc/objc-act.h - # Use maximal warnings for this front end. Also, make ObjC and C++ # headers accessible. objcp-warn = $(STRICT_WARN) -DOBJCPLUS -I$(srcdir)/objc -I$(srcdir)/cp @@ -69,110 +66,39 @@ cc1objplus-checksum.c : build/genchecksum$(build_exeext) checksum-options \ $(srcdir)/../move-if-change cc1objplus-checksum.c.tmp \ cc1objplus-checksum.c -cc1objplus-checksum.o : cc1objplus-checksum.c $(CONFIG_H) $(SYSTEM_H) - cc1objplus$(exeext): $(OBJCXX_OBJS) cc1objplus-checksum.o $(BACKEND) $(LIBDEPS) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(OBJCXX_OBJS) cc1objplus-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS) # Objective C++ language specific files. -objcp/objcp-lang.o : objcp/objcp-lang.c \ - $(START_HDRS) \ - $(GGC_H) \ - $(C_COMMON_H) $(LANGHOOKS_DEF_H) cp/cp-objcp-common.h \ - $(TARGET_H) gtype-objcp.h - -objcp/objcp-decl.o : objcp/objcp-decl.c \ - $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) $(CXX_TREE_H) \ - objc/objc-act.h c-family/c-objc.h \ - objcp/objcp-decl.h - -objcp/objc-runtime-shared-support.o : objc/objc-runtime-shared-support.c \ - gt-objc-objc-runtime-shared-support.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - objc/objc-encoding.h \ - objc/objc-next-metadata-tags.h \ - objc/objc-runtime-shared-support.h \ - objcp/objcp-decl.h - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $ \ - $(OUTPUT_OPTION) - -objcp/objc-gnu-runtime-abi-01.o: objc/objc-gnu-runtime-abi-01.c \ - gt-objc-objc-gnu-runtime-abi-01.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - toplev.h \ - objc/objc-encoding.h \ - objc/objc-runtime-hooks.h \ - objc/objc-runtime-shared-support.h \ - objcp/objcp-decl.h - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $ \ - $(OUTPUT_OPTION) - -objcp/objc-next-runtime-abi-01.o: objc/objc-next-runtime-abi-01.c \ - gt-objc-objc-next-runtime-abi-01.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - $(TARGET_H) output.h \ - objc/objc-encoding.h \ - objc/objc-next-metadata-tags.h \ - objc/objc-runtime-hooks.h \ - objc/objc-runtime-shared-support.h \ - objcp/objcp-decl.h - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $ \ - $(OUTPUT_OPTION) - -objcp/objc-next-runtime-abi-02.o: objc/objc-next-runtime-abi-02.c \ - gt-objc-objc-next-runtime-abi-02.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_CORE_H) $(FLAGS_H) input.h \ - $(TARGET_H) \ - objc/objc-encoding.h \ - objc/objc-next-metadata-tags.h \ - objc/objc-runtime-hooks.h \ - objc/objc-runtime-shared-support.h \ - objcp/objcp-decl.h - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $ \ - $(OUTPUT_OPTION) - - -# The following must be an explicit rule; please keep in sync with the implicit -# one in Makefile.in. -objcp/objcp-act.o : objc/objc-act.c \ - gt-objc-objc-act.h \ - $(START_HDRS) \ - $(GGC_H) $(DIAGNOSTIC_H) $(FLAGS_H)
[PATCH v2 09/18] convert the Java front end to automatic dependencies
This converts the Java front end. We also rename jvspec.o to java/jvspec.o, for uniformity; this lets us remove an explicit rule. * Make-lang.in (jvspec.o): Remove. (CFLAGS-java/jvspec.o): New variable. ($(XGCJ)$(exeext), java_OBJS): Use java/jvspec.o (java/jvspec.o-warn): Rename from jvspec.o-warn. (JAVA_TREE_H, java/jcf-dump.o, java/boehm.o, java/builtins.o) (java/class.o, java/constants.o, java/decl.o, java/except.o) (java/expr.o, java/jcf-depend.o, java/jcf-parse.o) (java/jvgenmain.o, java/lang.o, java/mangle.o, java/mangle_name.o) (java/resource.o java/typeck.o, java/win32-host.o) (java/verify-glue.o, java/verify-impl.o, java/zextract.o) (java/java-gimplify.o, java/jcf-io.o, java/jcf-path.o): Remove. --- gcc/java/Make-lang.in | 75 --- 1 file changed, 5 insertions(+), 70 deletions(-) diff --git a/gcc/java/Make-lang.in b/gcc/java/Make-lang.in index 078f6d4..5ed344c 100644 --- a/gcc/java/Make-lang.in +++ b/gcc/java/Make-lang.in @@ -55,16 +55,13 @@ JAVA_TARGET_INDEPENDENT_BIN_TOOLS = jcf-dump # Tell GNU make to ignore these if they exist. .PHONY: java -jvspec.o: $(srcdir)/java/jvspec.c $(SYSTEM_H) coretypes.h $(TM_H) \ - $(GCC_H) $(CONFIG_H) java/jcf.h java/javaop.h $(OPTS_H) - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \ - $(INCLUDES) $(srcdir)/java/jvspec.c $(OUTPUT_OPTION) +CFLAGS-java/jvspec.o += $(DRIVER_DEFINES) # Create the compiler driver for $(XGCJ). -$(XGCJ)$(exeext): $(GCC_OBJS) jvspec.o java/jcf-path.o \ +$(XGCJ)$(exeext): $(GCC_OBJS) java/jvspec.o java/jcf-path.o \ libcommon-target.a $(LIBDEPS) $(EXTRA_GCC_OBJS) +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ $(GCC_OBJS) \ - jvspec.o java/jcf-path.o $(EXTRA_GCC_OBJS) libcommon-target.a \ + java/jvspec.o java/jcf-path.o $(EXTRA_GCC_OBJS) libcommon-target.a \ $(EXTRA_GCC_LIBS) $(LIBS) # Create a version of the $(XGCJ) driver which calls the cross-compiler. @@ -88,13 +85,13 @@ JCFDUMP_OBJS = java/jcf-dump.o java/jcf-io.o java/jcf-depend.o java/jcf-path.o \ JVGENMAIN_OBJS = java/jvgenmain.o java/mangle_name.o -java_OBJS = $(sort $(JAVA_OBJS) $(JCFDUMP_OBJS) $(JVGENMAIN_OBJS)) jvspec.o +java_OBJS = $(sort $(JAVA_OBJS) $(JCFDUMP_OBJS) $(JVGENMAIN_OBJS)) java/jvspec.o # Use strict warnings for this front end. java-warn = $(STRICT_WARN) # String length warnings -jvspec.o-warn = -Wno-error +java/jvspec.o-warn = -Wno-error jc1$(exeext): $(JAVA_OBJS) $(BACKEND) $(LIBDEPS) attribs.o rm -f $@ @@ -262,76 +259,14 @@ java.stagefeedback: stageprofile-start -mv java/*$(objext) stagefeedback/java # -# .o:.h dependencies. -JAVA_TREE_H = $(TREE_H) $(HASHTAB_H) java/java-tree.h - -java/jcf-dump.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h $(JAVA_TREE_H) \ - java/jcf-dump.c java/jcf-reader.c java/jcf.h java/javaop.h java/javaop.def \ - version.h $(GGC_H) intl.h java/zipfile.h $(DIAGNOSTIC_H) -java/boehm.o: java/boehm.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(TREE_H) $(JAVA_TREE_H) java/parse.h -java/builtins.o: java/builtins.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(JAVA_TREE_H) $(GGC_H) $(FLAGS_H) $(OPTABS_H) $(EXPR_H) langhooks.h \ - gt-java-builtins.h -java/class.o: java/class.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(JAVA_TREE_H) java/jcf.h java/parse.h toplev.h output.h $(GGC_H) \ - $(FUNCTION_H) gt-java-class.h -java/constants.o: java/constants.c $(CONFIG_H) $(JAVA_TREE_H) java/jcf.h \ - toplev.h $(SYSTEM_H) coretypes.h $(TM_H) $(GGC_H) gt-java-constants.h -java/decl.o: java/decl.c $(CONFIG_H) $(JAVA_TREE_H) java/jcf.h \ - toplev.h $(FLAGS_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - java/java-except.h $(GGC_H) $(REAL_H) gt-java-decl.h \ - $(TARGET_H) $(CGRAPH_H) langhooks.h -java/except.o: java/except.c $(CONFIG_H) $(JAVA_TREE_H) java/jcf.h $(REAL_H) \ - java/javaop.h java/java-opcodes.h java/java-except.h \ - toplev.h $(SYSTEM_H) coretypes.h -java/expr.o: java/expr.c $(CONFIG_H) $(JAVA_TREE_H) java/jcf.h $(REAL_H) \ - java/javaop.h java/java-opcodes.h \ - java/java-except.h java/java-except.h java/parse.h \ - $(SYSTEM_H) coretypes.h $(TM_H) $(GGC_H) gt-java-expr.h $(TARGET_H) \ - tree-iterator.h -java/jcf-depend.o: java/jcf-depend.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - java/jcf.h -java/jcf-parse.o: java/jcf-parse.c $(CONFIG_H) $(JAVA_TREE_H) $(FLAGS_H) \ - input.h java/java-except.h $(SYSTEM_H) coretypes.h \ - java/parse.h $(GGC_H) debug.h $(REAL_H) gt-java-jcf-parse.h \ - java/jcf-reader.c java/zipfile.h java/jcf.h $(BITMAP_H) -java/jvgenmain.o: java/jvgenmain.c $(CONFIG_H) $(JAVA_TREE_H) $(SYSTEM_H) \ - coretypes.h $(TM_H) intl.h $(DIAGNOSTIC_H) -java/lang.o: java/lang.c $(CONFIG_H) $(JAVA_TREE_H) java/jcf.h input.h \ - $(SYSTEM_H) coretypes.h $(TM_H) $(DIAGNOSTIC_H) \ - langhooks.h $(LANGHOOKS_DEF_H) gt-java-lang.h $(OPTS_H)
[PATCH v2 10/18] Fix up c-family targets
This removes manual dependencies for the c-family .o files. * Makefile.in (c-family/cppspec.o, c-family/c-common.o) (c-family/c-cppbuiltin.o, c-family/c-dump.o, c-family/c-format.o) (c-family/c-gimplify.o, c-family/c-lex.o, c-family/c-omp.o) (c-family/c-opts.o, c-family/c-pch.o, c-family/c-ppoutput.o) (c-family/c-pragma.o, c-family/c-pretty-print.o) (c-family/c-semantics.o, c-family/c-ada-spec.o) (c-family/array-notation-common.o, c-family/stub-objc.o): Remove. --- gcc/Makefile.in | 76 - 1 file changed, 76 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index c225e0f..d8aeb3d 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1960,87 +1960,11 @@ lto-wrapper.o: lto-wrapper.c $(CONFIG_H) $(SYSTEM_H) coretypes.h intl.h \ $(OBSTACK_H) $(DIAGNOSTIC_H) $(OPTS_H) $(OPTIONS_H) # Files used by all variants of C or by the stand-alone pre-processor. -c-family/cppspec.o: c-family/cppspec.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ -$(TM_H) $(GCC_H) $(OPTS_H) - -c-family/c-common.o : c-family/c-common.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(TM_H) $(TREE_H) \ - $(OBSTACK_H) $(C_COMMON_H) $(FLAGS_H) toplev.h output.h $(C_PRAGMA_H) \ - $(GGC_H) builtin-types.def builtin-attrs.def \ - $(DIAGNOSTIC_H) langhooks.h c-family/c-objc.h \ - $(TARGET_H) tree-iterator.h langhooks.h tree-mudflap.h \ - intl.h $(OPTS_H) $(CPPLIB_H) $(TREE_INLINE_H) $(HASHTAB_H) \ - $(BUILTINS_DEF) $(CGRAPH_H) $(TARGET_DEF_H) \ - gt-c-family-c-common.h $(COMMON_TARGET_H) - -c-family/c-cppbuiltin.o : c-family/c-cppbuiltin.c $(CONFIG_H) $(SYSTEM_H) \ - coretypes.h $(TM_H) $(TREE_H) version.h $(C_COMMON_H) $(C_PRAGMA_H) \ - $(FLAGS_H) output.h $(TREE_H) $(TARGET_H) $(COMMON_TARGET_H) \ - $(TM_P_H) debug.h $(CPP_ID_DATA_H) cppbuiltin.h - -c-family/c-dump.o : c-family/c-dump.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(TM_H) $(TREE_H) $(TREE_DUMP_H) - -c-family/c-format.o : c-family/c-format.c c-family/c-format.h \ - $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) langhooks.h \ - $(C_COMMON_H) $(FLAGS_H) intl.h $(C_TARGET_H) \ - $(DIAGNOSTIC_CORE_H) alloc-pool.h c-family/c-objc.h - -c-family/c-gimplify.o : c-family/c-gimplify.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) \ - $(C_COMMON_H) $(DIAGNOSTIC_CORE_H) $(GIMPLE_H) \ - $(FLAGS_H) langhooks.h $(LANGHOOKS_DEF_H) \ - $(TM_H) coretypes.h $(C_PRETTY_PRINT_H) $(CGRAPH_H) \ - $(DUMPFILE_H) $(TREE_INLINE_H) - -c-family/c-lex.o : c-family/c-lex.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(TM_H) $(TREE_H) $(FIXED_VALUE_H) debug.h $(C_COMMON_H) $(SPLAY_TREE_H) \ - $(C_PRAGMA_H) $(INPUT_H) intl.h $(FLAGS_H) \ - $(CPPLIB_H) $(TARGET_H) $(TIMEVAR_H) - -c-family/c-omp.o : c-family/c-omp.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(TREE_H) $(C_COMMON_H) $(GIMPLE_H) langhooks.h CFLAGS-c-family/c-opts.o += @TARGET_SYSTEM_ROOT_DEFINE@ -c-family/c-opts.o : c-family/c-opts.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ -$(TREE_H) $(C_PRAGMA_H) $(FLAGS_H) toplev.h langhooks.h \ -$(DIAGNOSTIC_H) intl.h debug.h $(C_COMMON_H) $(C_TARGET_H) \ -$(OPTS_H) $(OPTIONS_H) $(MKDEPS_H) incpath.h cppdefault.h CFLAGS-c-family/c-pch.o += -DHOST_MACHINE=\$(host)\ \ -DTARGET_MACHINE=\$(target)\ -c-family/c-pch.o : c-family/c-pch.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(CPPLIB_H) $(TREE_H) $(C_COMMON_H) output.h $(C_PRAGMA_H) \ - $(GGC_H) debug.h langhooks.h $(FLAGS_H) hosthooks.h version.h \ - $(TARGET_H) $(OPTS_H) $(TIMEVAR_H) - -c-family/c-ppoutput.o : c-family/c-ppoutput.c $(CONFIG_H) $(SYSTEM_H) \ - coretypes.h $(C_COMMON_H) $(TREE_H) $(CPPLIB_H) $(CPP_INTERNAL_H) \ - $(C_PRAGMA_H) - -c-family/c-pragma.o: c-family/c-pragma.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(TM_H) $(TREE_H) $(FUNCTION_H) $(C_PRAGMA_H) output.h \ - $(TM_P_H) $(C_COMMON_H) $(TARGET_H) $(CPPLIB_H) $(FLAGS_H) \ - $(DIAGNOSTIC_H) $(OPTS_H) $(PLUGINS_H) \ - gt-c-family-c-pragma.h - -c-family/c-pretty-print.o : c-family/c-pretty-print.c $(C_PRETTY_PRINT_H) \ - $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ - $(DIAGNOSTIC_H) tree-iterator.h intl.h $(TREE_PRETTY_PRINT_H) - -c-family/c-semantics.o : c-family/c-semantics.c $(CONFIG_H) $(SYSTEM_H) \ - coretypes.h $(TM_H) $(TREE_H) $(FLAGS_H) \ - $(C_COMMON_H) $(FUNCTION_H) langhooks.h $(SPLAY_TREE_H) $(TIMEVAR_H) \ - tree-iterator.h - -c-family/c-ada-spec.o : c-family/c-ada-spec.c c-family/c-ada-spec.h \ - $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(CPP_ID_DATA_H) $(TM_H) \ - coretypes.h tree-iterator.h $(DUMPFILE_H) - -c-family/array-notation-common.o : c-family/array-notation-common.c $(TREE_H) \ - $(SYSTEM_H) $(TREE_H) coretypes.h tree-iterator.h $(DIAGNOSTIC_CORE_H) - -c-family/stub-objc.o : c-family/stub-objc.c
[PATCH v2 11/18] convert the Fortran front end to automatic dependencies
This convert fortran. It renames gfortranspec.o to fortran/gfortranspec.o, for uniformity and to allow removing an explicit rule. * Make-lang.in (fortran_OBJS): Use fortran/gfortranspec.o. (gfortranspec.o): Remove. (CFLAGS-fortran/gfortranspec.o): New variable. (GFORTRAN_D_OBJS): Update. ($(F95_PARSER_OBJS), fortran/openmp.o, GFORTRAN_TRANS_DEPS) (fortran/f95-lang.o, fortran/scanner.o, fortran/convert.o) (fortran/frontend-passes.o, fortran/trans.o, fortran/trans-decl.o) (fortran/trans-types, fortran/trans-const.o, fortran/trans-expr.o) (fortran/trans-stmt.o, fortran/trans-openmp.o, fortran/trans-io.o) (fortran/trans-array.o, fortran/trans-intrinsic.o) (fortran/dependency.o, fortran/trans-common.o, fortran/resolve.o) (fortran/data.o, fortran/options.o, fortran/cpp.o) (fortran/scanner.o, fortran/module.o): Remove. --- gcc/fortran/Make-lang.in | 62 +++- 1 file changed, 3 insertions(+), 59 deletions(-) diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in index 035a1d5..35fff87 100644 --- a/gcc/fortran/Make-lang.in +++ b/gcc/fortran/Make-lang.in @@ -67,7 +67,7 @@ F95_OBJS = $(F95_PARSER_OBJS) $(FORTRAN_TARGET_OBJS) \ fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o \ fortran/trans-stmt.o fortran/trans-types.o fortran/frontend-passes.o -fortran_OBJS = $(F95_OBJS) gfortranspec.o +fortran_OBJS = $(F95_OBJS) fortran/gfortranspec.o # # Define the names for selecting gfortran in LANGUAGES. @@ -76,13 +76,10 @@ fortran: f951$(exeext) # Tell GNU make to ignore files by these names if they exist. .PHONY: fortran -gfortranspec.o: $(srcdir)/fortran/gfortranspec.c $(SYSTEM_H) $(TM_H) $(GCC_H) \ - $(CONFIG_H) coretypes.h intl.h $(OPTS_H) - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \ - $(INCLUDES) $(srcdir)/fortran/gfortranspec.c +CFLAGS-fortran/gfortranspec.o += $(DRIVER_DEFINES) # Create the compiler driver gfortran. -GFORTRAN_D_OBJS = $(GCC_OBJS) gfortranspec.o +GFORTRAN_D_OBJS = $(GCC_OBJS) fortran/gfortranspec.o gfortran$(exeext): $(GFORTRAN_D_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a \ $(LIBDEPS) +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ @@ -316,59 +313,6 @@ fortran.stagefeedback: stageprofile-start -mv fortran/*$(objext) stagefeedback/fortran # -# .o: .h dependencies. - -# Everything depends on gfortran.h, but only a few files depend on -# the other headers. So at some point we'll have to split out -# which objects depend on what. FIXME -# TODO: Add dependencies on the backend/tree header files - -$(F95_PARSER_OBJS): fortran/gfortran.h fortran/libgfortran.h \ - fortran/intrinsic.h fortran/match.h fortran/constructor.h \ - fortran/parse.h fortran/arith.h fortran/target-memory.h \ - $(CONFIG_H) $(SYSTEM_H) $(TM_H) $(TM_P_H) coretypes.h \ - dumpfile.h $(TREE_H) dumpfile.h $(GGC_H) $(VEC_H) \ - $(FLAGS_H) $(DIAGNOSTIC_H) errors.h $(FUNCTION_H) \ - fortran/iso-c-binding.def fortran/iso-fortran-env.def -fortran/openmp.o: pointer-set.h $(TARGET_H) toplev.h - -GFORTRAN_TRANS_DEPS = fortran/gfortran.h fortran/libgfortran.h \ -fortran/intrinsic.h fortran/trans-array.h \ -fortran/trans-const.h fortran/trans-const.h fortran/trans.h \ -fortran/trans-stmt.h fortran/trans-types.h \ -$(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(TM_H) coretypes.h $(GGC_H) \ -fortran/iso-c-binding.def fortran/iso-fortran-env.def CFLAGS-fortran/cpp.o += $(TARGET_SYSTEM_ROOT_DEFINE) -fortran/f95-lang.o: $(GFORTRAN_TRANS_DEPS) fortran/mathbuiltins.def \ - gt-fortran-f95-lang.h gtype-fortran.h $(CGRAPH_H) $(TARGET_H) fortran/cpp.h \ - $(BUILTINS_DEF) fortran/types.def \ - $(TM_H) debug.h langhooks.h $(FLAGS_H) $(EXPR_H) $(LANGHOOKS_DEF_H) \ - libfuncs.h expr.h $(DIAGNOSTIC_H) -fortran/scanner.o: toplev.h fortran/cpp.h -fortran/convert.o: $(GFORTRAN_TRANS_DEPS) convert.h -fortran/frontend-passes.o: $(GFORTRAN_TRANS_DEPS) -fortran/trans.o: $(GFORTRAN_TRANS_DEPS) tree-iterator.h -fortran/trans-decl.o: $(GFORTRAN_TRANS_DEPS) gt-fortran-trans-decl.h \ - $(CGRAPH_H) $(TARGET_H) $(FUNCTION_H) $(FLAGS_H) $(RTL_H) $(GIMPLE_H) \ - $(TREE_DUMP_H) debug.h pointer-set.h -fortran/trans-types.o: $(GFORTRAN_TRANS_DEPS) gt-fortran-trans-types.h \ - $(REAL_H) toplev.h $(TARGET_H) $(FLAGS_H) dwarf2out.h -fortran/trans-const.o: $(GFORTRAN_TRANS_DEPS) realmpfr.h -fortran/trans-expr.o: $(GFORTRAN_TRANS_DEPS) fortran/dependency.h -fortran/trans-stmt.o: $(GFORTRAN_TRANS_DEPS) fortran/dependency.h -fortran/trans-openmp.o: $(GFORTRAN_TRANS_DEPS) -fortran/trans-io.o: $(GFORTRAN_TRANS_DEPS) gt-fortran-trans-io.h \ - fortran/ioparm.def -fortran/trans-array.o: $(GFORTRAN_TRANS_DEPS) $(GIMPLE_H) -fortran/trans-intrinsic.o: $(GFORTRAN_TRANS_DEPS) fortran/mathbuiltins.def \ -
[PATCH v2 17/18] remove last definition of CROSS_FLOAT_H
There is a single definition of CROSS_FLOAT_H in the source. As far as I can tell, this is never used anywhere. So, this patch removes it. * config/mcore/t-mcore (CROSS_FLOAT_H): Remove. --- gcc/config/mcore/t-mcore | 3 --- 1 file changed, 3 deletions(-) diff --git a/gcc/config/mcore/t-mcore b/gcc/config/mcore/t-mcore index 92fefb1..e5f37ee 100644 --- a/gcc/config/mcore/t-mcore +++ b/gcc/config/mcore/t-mcore @@ -16,9 +16,6 @@ # along with GCC; see the file COPYING3. If not see # http://www.gnu.org/licenses/. -# We have values for float.h. -CROSS_FLOAT_H = $(srcdir)/config/mcore/gfloat.h - # If support for -m4align is ever re-enabled then comment out the # following line and uncomment the multilib lines below. -- 1.8.1.4
[PATCH v2 13/18] convert LTO to automatic dependencies
This converts LTO. This also fixes a latent buglet in lto/Make-lang.in. lto_OBJS should hold all the objects for a language, but LTO never defined this. * Make-lang.in (LTO_H, LINKER_PLUGIN_API_H, LTO_TREE_H) (lto/lto-lang.o, lto/lto.o, lto/lto-partition.o) (lto/lto-object.o): Remove. --- gcc/lto/Make-lang.in | 26 +- 1 file changed, 1 insertion(+), 25 deletions(-) diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in index 5f2f475..ddef3bf 100644 --- a/gcc/lto/Make-lang.in +++ b/gcc/lto/Make-lang.in @@ -23,10 +23,7 @@ LTO_EXE = lto1$(exeext) # The LTO-specific object files inclued in $(LTO_EXE). LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o -LTO_H = lto/lto.h $(HASHTAB_H) -LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h -LTO_TREE_H = lto/lto-tree.h $(LINKER_PLUGIN_API_H) - +lto_OBJS = $(LTO_OBJS) # Rules @@ -74,26 +71,5 @@ $(LTO_EXE): $(LTO_OBJS) $(BACKEND) $(LIBDEPS) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(LTO_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS) -# Dependencies -lto/lto-lang.o: lto/lto-lang.c $(CONFIG_H) coretypes.h debug.h \ - flags.h $(GGC_H) langhooks.h $(LANGHOOKS_DEF_H) $(SYSTEM_H) \ - $(TARGET_H) $(LTO_H) $(GIMPLE_H) gtype-lto.h gt-lto-lto-lang.h \ - $(EXPR_H) $(LTO_STREAMER_H) -lto/lto.o: lto/lto.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(OPTS_H) \ - toplev.h $(TREE_H) $(TREE_FLOW_H) $(DIAGNOSTIC_CORE_H) $(TM_H) \ - $(CGRAPH_H) $(GGC_H) tree-ssa-operands.h $(TREE_PASS_H) \ - langhooks.h $(VEC_H) $(BITMAP_H) pointer-set.h $(IPA_PROP_H) \ - $(COMMON_H) debug.h $(GIMPLE_H) $(LTO_H) $(LTO_TREE_H) \ - $(LTO_TAGS_H) $(LTO_STREAMER_H) $(SPLAY_TREE_H) gt-lto-lto.h \ - $(TREE_STREAMER_H) $(DATA_STREAMER_H) lto/lto-partition.h -lto/lto-partition.o: lto/lto-partition.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - toplev.h $(TREE_H) $(TM_H) \ - $(CGRAPH_H) $(TIMEVAR_H) \ - $(LTO_STREAMER_H) $(SPLAY_TREE_H) gt-lto-lto.h $(PARAMS_H) \ - ipa-inline.h $(IPA_UTILS_H) lto/lto-partition.h -lto/lto-object.o: lto/lto-object.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(DIAGNOSTIC_CORE_H) $(LTO_H) $(TM_H) $(LTO_STREAMER_H) \ - ../include/simple-object.h - # LTO testing is done as part of C/C++/Fortran etc. testing. check-lto: -- 1.8.1.4
[PATCH v2 12/18] convert the Go front end to automatic dependencies
This converts Go. It renames gospec.o to go/gospec.o, for uniformity and so we can remove an explicit rule. It defines go_OBJS, to conform to the documented Make-lang.in conventions, and to ensure that Go objects are given the correct order-only dependencies on generated files. * Make-lang.in (gospec.o): Remove. (CFLAGS-go/gospec.o): New variable. (GCCGO_OBJS): Update to use go/gospec.o. (go_OBJS): Define. (GO_SYSTEM_H, GO_C_H, GO_LINEMAP_H, GO_LEX_H, GO_PARSE_H) (GO_GOGO_H, GO_TYPES_H, GO_STATEMENTS_H, GO_EXPRESSIONS_H) (GO_EXPORT_H, GO_IMPORT_H, GO_RUNTIME_H, GO_AST_DUMP_H) (go/go-backend.o, go/go-lang.o, go/go-gcc.o, go/go-linemap.o) (go/ast-dump.o, go/dataflow.o, go/export.o, go/expressions.o) (go/go.o, go/go-dump.o, go/go-optimize.o, go/gogo-tree.o) (go/gogo.o, go/import.o, go/import-archive.o, go/lex.o) (go/parse.o, go/runtime.o, go/statements.o, go/types.o) (go/unsafe.o): Remove. (CFLAGS-go/go-gcc.o, CFLAGS-go/go-linemap.o): New variables. (go/%.o: go/gofrontend/%.cc): Use COMPILE and POSTCOMPILE. --- gcc/go/Make-lang.in | 99 + 1 file changed, 8 insertions(+), 91 deletions(-) diff --git a/gcc/go/Make-lang.in b/gcc/go/Make-lang.in index 015ed7a..e4bceb2 100644 --- a/gcc/go/Make-lang.in +++ b/gcc/go/Make-lang.in @@ -30,12 +30,9 @@ go: go1$(exeext) .PHONY: go -gospec.o: $(srcdir)/go/gospec.c $(SYSTEM_H) coretypes.h $(TM_H) $(GCC_H) \ -$(CONFIG_H) opts.h - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \ - $(INCLUDES) $(srcdir)/go/gospec.c +CFLAGS-go/gospec.o += $(DRIVER_DEFINES) -GCCGO_OBJS = $(GCC_OBJS) gospec.o +GCCGO_OBJS = $(GCC_OBJS) go/gospec.o gccgo$(exeext): $(GCCGO_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS) +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(GCCGO_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a \ @@ -74,6 +71,8 @@ GO_OBJS = \ go/types.o \ go/unsafe.o +go_OBJS = $(GO_OBJS) go/gospec.o + go1$(exeext): $(GO_OBJS) attribs.o $(BACKEND) $(LIBDEPS) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(GO_OBJS) attribs.o $(BACKEND) $(LIBS) $(BACKENDLIBS) @@ -222,96 +221,14 @@ go.stageprofile: stageprofile-start go.stagefeedback: stagefeedback-start -mv go/*$(objext) stagefeedback/go -GO_SYSTEM_H = go/go-system.h $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(DIAGNOSTIC_CORE_H) $(INPUT_H) intl.h - -GO_C_H = go/go-c.h $(MACHMODE_H) -GO_LINEMAP_H = go/gofrontend/go-linemap.h $(GO_SYSTEM_H) go/go-location.h -GO_LEX_H = go/gofrontend/lex.h go/gofrontend/operator.h $(GO_LINEMAP_H) -GO_PARSE_H = go/gofrontend/parse.h -GO_GOGO_H = go/gofrontend/gogo.h $(GO_LINEMAP_H) -GO_TYPES_H = go/gofrontend/types.h $(GO_LINEMAP_H) -GO_STATEMENTS_H = go/gofrontend/statements.h go/gofrontend/operator.h -GO_EXPRESSIONS_H = go/gofrontend/expressions.h go/gofrontend/operator.h -GO_EXPORT_H = go/gofrontend/export.h go/gofrontend/string-dump.h -GO_IMPORT_H = go/gofrontend/import.h $(GO_EXPORT_H) $(GO_LINEMAP_H) -GO_RUNTIME_H = go/gofrontend/runtime.h go/gofrontend/runtime.def -GO_AST_DUMP_H = go/gofrontend/ast-dump.h go/gofrontend/string-dump.h - -go/go-backend.o: go/go-backend.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ - $(TM_H) $(TREE_H) $(TM_P_H) output.h $(TARGET_H) \ - $(COMMON_TARGET_H) - CFLAGS-go/go-lang.o += -DDEFAULT_TARGET_VERSION=\$(version)\ \ -DDEFAULT_TARGET_MACHINE=\$(target_noncanonical)\ -go/go-lang.o: go/go-lang.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(OPTS_H) \ - $(TREE_H) $(GIMPLE_H) $(GGC_H) $(TOPLEV_H) debug.h options.h \ - $(FLAGS_H) convert.h $(DIAGNOSTIC_H) langhooks.h \ - $(LANGHOOKS_DEF_H) $(TARGET_H) $(GO_C_H) \ - gt-go-go-lang.h gtype-go.h $(COMMON_TARGET_H) GOINCLUDES = -I $(srcdir)/go -I $(srcdir)/go/gofrontend -go/go-gcc.o: go/go-gcc.cc $(GO_SYSTEM_H) $(TREE_H) tree-iterator.h \ - $(GIMPLE_H) toplev.h output.h $(GO_C_H) $(GO_GOGO_H) \ - go/gofrontend/backend.h - $(CXX) -c $(GOINCLUDES) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $ $(OUTPUT_OPTION) - -go/go-linemap.o: go/go-linemap.cc $(GO_SYSTEM_H) $(GO_LINEMAP_H) - $(CXX) -c $(GOINCLUDES) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $ $(OUTPUT_OPTION) +CFLAGS-go/go-gcc.o += $(GOINCLUDES) +CFLAGS-go/go-linemap.o += $(GOINCLUDES) go/%.o: go/gofrontend/%.cc - $(CXX) -c $(GOINCLUDES) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $ $(OUTPUT_OPTION) - -go/ast-dump.o: go/gofrontend/ast-dump.cc $(GO_SYSTME_H) $(GO_GOGO_H) \ - $(GO_EXPRESSIONS_H) $(GO_STATEMENTS_H) $(GO_TYPES_H) \ - $(GO_AST_DUMP_H) $(GO_C_H) go/gofrontend/go-dump.h -go/dataflow.o: go/gofrontend/dataflow.cc $(GO_SYSTEM_H) $(GO_GOGO_H) \ - $(GO_EXPRESSIONS_H) $(GO_STATEMENTS_H) go/gofrontend/dataflow.h -go/export.o: go/gofrontend/export.cc $(GO_SYSTEM_H) \ -
[PATCH v2 18/18] remove unused macros
I used this perl script to find unused _H macros in the Makefile. I
deleted the definitions it reported and re-ran the script, until there
was no more output.
The script also makes note of _H variables which are used but never
defined. That is how I found the TREE_GIMPLE_H use, fixed earlier in
the series.
Once Ada and the various config files are migrated to automatic
dependencies, we can run this script again and remove more things.
while () {
chomp;
if (m/^(([A-Z0-9_]+)_H)\s*:?=\s/) {
$saw_def{$1} = $ARGV . : . $.;
}
while (m/\$[({](([A-Z0-9_]+)_H)[)}](.*)/) {
$saw_use{$1} = 1;
$_ = $3;
}
} continue {
close ARGV if eof;
}
foreach $key (sort keys %saw_use) {
if (! defined $saw_def{$key}) {
print use without a def of , $key, \n;
}
}
foreach $key (sort keys %saw_def) {
if (! defined $saw_use{$key}) {
print $saw_def{$key}, : no use of , $key, \n;
}
}
* Makefile.in (PARTITION_H, LTO_SYMTAB_H, COMMON_TARGET_DEF_H)
(RTL_ERROR_H, TRANS_MEM_H, COVERAGE_H, DEMANGLE_H, ALIAS_H)
(SCHED_INT_H, SEL_SCHED_IR_H, SEL_SCHED_DUMP_H, VALTRACK_H, DDG_H)
(GGC_INTERNAL_H, DECNUM_H, BACKTRACE_H, MKDEPS_H, TREE_HASHER_H)
(TREE_SSA_LIVE_H, SSAEXPAND_H, DWARF2OUT_H, SCEV_H, OMEGA_H)
(TREE_DATA_REF_H, IRA_INT_H, LRA_INT_H, DBGCNT_H, DATA_STREAMER_H)
(GIMPLE_STREAMER_H, TREE_STREAMER_H, STREAMER_HOOKS_H)
(TREE_VECTORIZER_H, IPA_INLINE_H, GSTAB_H, LIBFUNCS_H)
(GRAPHITE_HTAB_H, CONTEXT_H): Remove.
---
gcc/Makefile.in | 47 ---
1 file changed, 47 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index a21daba..e6d63d3 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -446,7 +446,6 @@ HASHTAB_H = $(srcdir)/../include/hashtab.h
OBSTACK_H = $(srcdir)/../include/obstack.h
SPLAY_TREE_H= $(srcdir)/../include/splay-tree.h
FIBHEAP_H = $(srcdir)/../include/fibheap.h
-PARTITION_H = $(srcdir)/../include/partition.h
MD5_H = $(srcdir)/../include/md5.h
DWARF2_H= $(srcdir)/../include/dwarf2.h $(srcdir)/../include/dwarf2.def
XREGEX_H= $(srcdir)/../include/xregex.h
@@ -454,7 +453,6 @@ FNMATCH_H = $(srcdir)/../include/fnmatch.h
# Linker plugin API headers
LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h
-LTO_SYMTAB_H = $(srcdir)/../include/lto-symtab.h
# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR = @NATIVE_SYSTEM_HEADER_DIR@
@@ -863,14 +861,11 @@ LANGHOOKS_DEF_H = langhooks-def.h $(HOOKS_H)
TARGET_DEF_H = target-def.h target-hooks-def.h $(HOOKS_H) targhooks.h
C_TARGET_DEF_H = c-family/c-target-def.h c-family/c-target-hooks-def.h \
$(TREE_H) $(C_COMMON_H) $(HOOKS_H) common/common-targhooks.h
-COMMON_TARGET_DEF_H = common/common-target-def.h \
- common/common-target-hooks-def.h $(HOOKS_H)
RTL_BASE_H = coretypes.h rtl.h rtl.def $(MACHMODE_H) reg-notes.def \
insn-notes.def $(INPUT_H) $(REAL_H) statistics.h $(VEC_H) \
$(FIXED_VALUE_H) alias.h $(HASHTAB_H)
FIXED_VALUE_H = fixed-value.h $(MACHMODE_H) double-int.h
RTL_H = $(RTL_BASE_H) $(FLAGS_H) genrtl.h
-RTL_ERROR_H = rtl-error.h $(RTL_H) $(DIAGNOSTIC_CORE_H)
READ_MD_H = $(OBSTACK_H) $(HASHTAB_H) read-md.h
PARAMS_H = params.h params.def
BUILTINS_DEF = builtins.def sync-builtins.def omp-builtins.def \
@@ -888,12 +883,8 @@ BASIC_BLOCK_H = basic-block.h $(PREDICT_H) $(VEC_H)
$(FUNCTION_H) \
GIMPLE_H = gimple.h gimple.def gsstruct.def pointer-set.h $(VEC_H) \
$(GGC_H) $(BASIC_BLOCK_H) $(TREE_H) tree-ssa-operands.h \
tree-ssa-alias.h $(INTERNAL_FN_H) $(HASH_TABLE_H)
-TRANS_MEM_H = trans-mem.h
GCOV_IO_H = gcov-io.h gcov-iov.h auto-host.h
-COVERAGE_H = coverage.h $(GCOV_IO_H)
-DEMANGLE_H = $(srcdir)/../include/demangle.h
RECOG_H = recog.h
-ALIAS_H = alias.h
EMIT_RTL_H = emit-rtl.h
FLAGS_H = flags.h flag-types.h $(OPTIONS_H)
OPTIONS_H = options.h flag-types.h $(OPTIONS_H_EXTRA)
@@ -902,11 +893,6 @@ FUNCTION_H = function.h $(HASHTAB_H) $(TM_H)
hard-reg-set.h \
EXPR_H = expr.h insn-config.h $(FUNCTION_H) $(RTL_H) $(FLAGS_H) $(TREE_H)
$(MACHMODE_H) $(EMIT_RTL_H)
OPTABS_H = optabs.h insn-codes.h insn-opinit.h
REGS_H = regs.h $(MACHMODE_H) hard-reg-set.h
-SCHED_INT_H = sched-int.h $(INSN_ATTR_H) $(BASIC_BLOCK_H) $(RTL_H) $(DF_H) \
- $(REGSET_H)
-SEL_SCHED_IR_H = sel-sched-ir.h $(INSN_ATTR_H) $(BASIC_BLOCK_H) $(RTL_H) \
- $(GGC_H) $(BITMAP_H) $(SCHED_INT_H) $(CFGLOOP_H) $(REGSET_H)
-SEL_SCHED_DUMP_H = sel-sched-dump.h $(SEL_SCHED_IR_H)
CFGLOOP_H = cfgloop.h $(BASIC_BLOCK_H) double-int.h \
$(BITMAP_H) sbitmap.h
IPA_UTILS_H = ipa-utils.h $(TREE_H) $(CGRAPH_H)
@@ -915,13 +901,9 @@ CGRAPH_H = cgraph.h $(VEC_H) $(TREE_H) $(BASIC_BLOCK_H)
$(FUNCTION_H) \
cif-code.def ipa-ref.h ipa-ref-inline.h $(LINKER_PLUGIN_API_H)
[PATCH v2 16/18] remove last reference to TREE_GIMPLE_H
There is a single reference to TREE_GIMPLE_H in the source tree. Since it is not defined anywhere, we might as well remove the use. * config/i386/t-i386 (i386.o): Don't use TREE_GIMPLE_H. --- gcc/config/i386/t-i386 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/i386/t-i386 b/gcc/config/i386/t-i386 index 3a77e14..af0ea94 100644 --- a/gcc/config/i386/t-i386 +++ b/gcc/config/i386/t-i386 @@ -22,7 +22,7 @@ i386.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h dumpfile.h $(TM_H) \ $(INSN_ATTR_H) $(FLAGS_H) $(C_COMMON_H) except.h $(FUNCTION_H) \ $(RECOG_H) $(EXPR_H) $(OPTABS_H) toplev.h $(BASIC_BLOCK_H) \ $(GGC_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h $(CGRAPH_H) \ - $(TREE_GIMPLE_H) $(DWARF2_H) $(DF_H) tm-constrs.h $(PARAMS_H) \ + $(DWARF2_H) $(DF_H) tm-constrs.h $(PARAMS_H) \ i386-builtin-types.inc debug.h dwarf2out.h sbitmap.h $(FIBHEAP_H) \ $(OPTS_H) $(DIAGNOSTIC_H) $(COMMON_TARGET_H) -- 1.8.1.4
[PATCH v2 15/18] make out_object_file rule use automatic dependencies
This is a small change to make out_object_file use automatic dependencies. * Makefile.in ($(out_object_file)): Use COMPILE and POSTCOMPILE. --- gcc/Makefile.in | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 47ecaf8..a21daba 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -2021,15 +2021,9 @@ s-bversion: BASE-VER CFLAGS-toplev.o += -DTARGET_NAME=\$(target_noncanonical)\ -$(out_object_file): $(out_file) $(CONFIG_H) coretypes.h $(TM_H) $(TREE_H) \ - $(RTL_H) $(REGS_H) hard-reg-set.h insn-config.h conditions.h \ - output.h $(INSN_ATTR_H) $(SYSTEM_H) toplev.h $(DIAGNOSTIC_CORE_H) \ - $(TARGET_H) $(LIBFUNCS_H) $(TARGET_DEF_H) $(FUNCTION_H) $(SCHED_INT_H) \ - $(TM_P_H) $(EXPR_H) langhooks.h $(GGC_H) $(OPTABS_H) $(REAL_H) \ - tm-constrs.h $(GIMPLE_H) $(DF_H) cselib.h $(COMMON_TARGET_H) hw-doloop.h \ - regrename.h - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \ - $(out_file) $(OUTPUT_OPTION) +$(out_object_file): $(out_file) + $(COMPILE) $ + $(POSTCOMPILE) $(common_out_object_file): $(common_out_file) $(COMPILE) $ -- 1.8.1.4
[PATCH v2 04/18] add configury
This adds the configury needed for automatic dependency tracking. It
also adds some bits to the Makefile so we can begin converting
(removing) explicit dependencies.
* Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
(COMPILE, POSTCOMPILE): New variables.
(.cc.o .c.o): Use COMPILE, POSTCOMPILE.
(DEPFILES): New variable.
Include .Po files.
* configure.ac: Add checks for dependency checking.
* configure, aclocal.m4: Regenerate.
---
gcc/Makefile.in | 28 ++-
gcc/aclocal.m4 | 2 +
gcc/configure| 148 ++-
gcc/configure.ac | 16 ++
4 files changed, 191 insertions(+), 3 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6ba2e93..c663c81 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -308,6 +308,11 @@ write_entries_to_file = $(shell rm -f $(2) || :) $(shell
touch $(2)) \
# UNSORTED
#
+# Dependency tracking stuff.
+CCDEPMODE = @CCDEPMODE@
+DEPDIR = @DEPDIR@
+depcomp = $(SHELL) $(srcdir)/../depcomp
+
# Some compilers can't handle cc -c blah.c -o foo/blah.o.
# In stage2 and beyond, we force this to -o $@ since we know we're using gcc.
OUTPUT_OPTION = @OUTPUT_OPTION@
@@ -1067,8 +1072,19 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
$(CPPINC) $(GMPINC) $(DECNUMINC) $(BACKTRACEINC) \
$(CLOOGINC) $(ISLINC)
+COMPILE.base = $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) -o $@
+ifeq ($(CCDEPMODE),depmode=gcc3)
+COMPILE = $(COMPILE.base) -MT $@ -MMD -MP -MF $(*D)/$(DEPDIR)/$(*F).TPo
+POSTCOMPILE = @mv $(*D)/$(DEPDIR)/$(*F).TPo $(*D)/$(DEPDIR)/$(*F).Po
+else
+COMPILE = source='$' object='$@' libtool=no \
+DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) $(COMPILE.base)
+POSTCOMPILE =
+endif
+
.cc.o .c.o:
- $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $ $(OUTPUT_OPTION)
+ $(COMPILE) $
+ $(POSTCOMPILE)
#
# Support for additional languages (other than C).
@@ -5354,7 +5370,17 @@ po/gcc.pot: force
AWK=$(AWK) $(SHELL) $(srcdir)/po/exgettext \
$(XGETTEXT) gcc $(srcdir)
+#
+
+# Dependency information.
+
# In order for parallel make to really start compiling the expensive
# objects from $(OBJS) as early as possible, build all their
# prerequisites strictly before all objects.
$(ALL_HOST_OBJS) : | $(generated_files)
+
+# Include the auto-generated dependencies for all host objects.
+DEPFILES = \
+ $(foreach obj,$(ALL_HOST_OBJS),\
+$(dir $(obj))$(DEPDIR)/$(patsubst %.o,%.Po,$(notdir $(obj
+-include $(DEPFILES)
diff --git a/gcc/aclocal.m4 b/gcc/aclocal.m4
index a992c3a..1bcf905 100644
--- a/gcc/aclocal.m4
+++ b/gcc/aclocal.m4
@@ -106,10 +106,12 @@ m4_include([../ltversion.m4])
m4_include([../lt~obsolete.m4])
m4_include([../config/acx.m4])
m4_include([../config/codeset.m4])
+m4_include([../config/depstand.m4])
m4_include([../config/dfp.m4])
m4_include([../config/gettext-sister.m4])
m4_include([../config/iconv.m4])
m4_include([../config/lcmessage.m4])
+m4_include([../config/lead-dot.m4])
m4_include([../config/lib-ld.m4])
m4_include([../config/lib-link.m4])
m4_include([../config/lib-prefix.m4])
diff --git a/gcc/configure b/gcc/configure
index 0d6ddaa..e09cd52 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -735,6 +735,9 @@ LDEXP_LIB
EXTRA_GCC_LIBS
GNAT_LIBEXC
COLLECT2_LIBS
+CCDEPMODE
+DEPDIR
+am__leading_dot
CXXCPP
AR
NM
@@ -8873,6 +8876,136 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
#
+# Dependency checking.
+#
+
+ac_ext=cpp
+ac_cpp='$CXXCPP $CPPFLAGS'
+ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext 5'
+ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS 5'
+ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
+
+rm -rf .tst 2/dev/null
+mkdir .tst 2/dev/null
+if test -d .tst; then
+ am__leading_dot=.
+else
+ am__leading_dot=_
+fi
+rmdir .tst 2/dev/null
+
+DEPDIR=${am__leading_dot}deps
+
+ac_config_commands=$ac_config_commands depdir
+
+
+ac_config_commands=$ac_config_commands gccdepdir
+
+
+depcc=$CC am_compiler_list=
+
+am_depcomp=$ac_aux_dir/depcomp
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking dependency style of $depcc
5
+$as_echo_n checking dependency style of $depcc... 6; }
+if test ${am_cv_CC_dependencies_compiler_type+set} = set; then :
+ $as_echo_n (cached) 6
+else
+ if test -f $am_depcomp; then
+ # We make a subdir and do the tests there. Otherwise we can end up
+ # making bogus files that we don't know about and never remove. For
+ # instance it was reported that on HP-UX the gcc test will end up
+ # making a dummy file named `D' -- because `-MD' means `put the output
+ # in D'.
+ mkdir conftest.dir
+ # Copy depcomp to subdir because otherwise we won't find it if we're
+ # using a relative directory.
+ cp $am_depcomp conftest.dir
+ cd conftest.dir
+ # We will build objects and dependencies in a subdirectory because
+ # it helps to detect
Re: [PATCH] Add atomic type qualifier
On 07/29/2013 12:06 PM, Joseph S. Myers wrote: On Mon, 29 Jul 2013, Andrew MacLeod wrote: Blick. What were they smoking the night before... I guess we'll probably need to enhance the current atomic patterns in RTL...We should be able to figure out that its floating point and invoke the appropriate RTL pattern during expansion rather than an existing one.OR just frigging call libatomic and let it deal with it. :-) I guess there wouldnt be any other fallback available. Actually, thats a mess... no way for the librtary to know its floating point unless you tell it somehow with new entry points or somesuch.. very lame. Note that you only need *one* of the types to be floating-point for this issue to apply. If you have _Atomic char c; float f; c /= f; then all the same requirements apply; there may be exceptions to discard not just from the division, but from the conversion of a float division result to char. yes, unfortunately. but gimplification should turn this to: t0 = c t1 =(float) t0 t2 = t0 / f t3 = (char) t2 c = t3 so we simply see a floating point division bracketted by load and store from a TYPE_ATOMIC expression. so we'd should be able to recognize the need for the floating point extra stuff based on the type of the operation . and just wrap the whole blasted thing. I must say, I'm not a fan :-) I planned to do the work in gimplification... let the atomic decls through, and during gimplification, loads or stores of an atomic decl would be converted to the appropriate load or store builtin, and at the same time recognize the 'decl = decl op value' expression and replace those as appropriate with atomic_op_fetch operations. I had discussed this at some length with Lawrence crowl and Jeffrey Yasskin some time ago.. At gimplification time we no longer know whether the original form was decl op= val or decl = decl op val;, but the decision was that it is ok to recognize decl = decl op val and make that atomic.. it would still satisfy the language requirements.. I think that's probably OK (though, is this a theorem of the formal modelling work that has been done on the memory model?), but note it's not I have no idea if its a theorem or not. just a decl but an arbitrary pointer dereference (the address of the lvalue is only evaluated once, no matter how many compare-and-exchange operations are needed), and the operation may end up looking like *ptr = (convert to type of *ptr) ((promote) *ptr op (promote) val) rather than a simple decl = decl op val. Or something more complicated if I think gimplification takes care of that as well since all assignments have to be in the form DECL = VALUE op VALUE.. it constructs the sequence so that something like *op_expr += 1 is properly transformed to t0 = op_expr t1 = *t0 t2 = t1 + 1 *t0 = t2 With the TYPE_ATOMIC attribute set and rippled through the op_expr expression, we know that *t0 is atomic in nature, so t1 is an atomic load, *t0 is an atomic store, and looking back at t2 = t1 + 1 can see that this is an atomic += 1. same thing with a normal load of an expression... the TYPE_ATOMIC gimple attribute *ought* to tell us everything we need. the operation involves complex numbers - look at what gets for mixed real / complex arithmetic, for example. Given _Atomic _Complex float f; double d; f += d; the atomicity is for the whole complex number (and so the compare-and-exchange needs to work on the whole number) although only the real part is modified by the addition. complex I hadn't thought about until just now, I'll have to look. I know we can deal with parts on complex sometimes. Hopefully at gimplification time we still have the whole complex reference and if we just take care of that with the atomic builtins, we'll maintain the entire thing as we need. Andrew
Re: [PATCH 00/11] Rewrite of pass management
On Jul 29, 2013, at 8:23 AM, David Malcolm dmalc...@redhat.com wrote: How about gcc::pass_manager? I like this name a whole lot better.
Re: [PATCH 00/11] Rewrite of pass management
On Mon, Jul 29, 2013 at 11:23 AM, David Malcolm dmalc...@redhat.com wrote: How about gcc::pass_manager? Yes, please. Diego.
Re: [PATCH v2 08/18] convert the ObjC++ front end to automatic dependencies
On Jul 29, 2013, at 9:24 AM, Tom Tromey tro...@redhat.com wrote: +objcp/objc-runtime-shared-support.o : objc/objc-runtime-shared-support.c +objcp/objc-gnu-runtime-abi-01.o: objc/objc-gnu-runtime-abi-01.c +objcp/objc-next-runtime-abi-01.o: objc/objc-next-runtime-abi-01.c +objcp/objc-next-runtime-abi-02.o: objc/objc-next-runtime-abi-02.c +objcp/objcp-act.o : objc/objc-act.c +objcp/objc-encoding.o : objc/objc-encoding.c +objcp/objc-map.o : objc/objc-map.c Please, no space before :. Ok with that.
Re: [PATCH v2 07/18] convert the ObjC front end to automatic dependencies
On Jul 29, 2013, at 9:24 AM, Tom Tromey tro...@redhat.com wrote: This converts the ObjC front end. Thanks.
Re: [PATCH] Add atomic type qualifier
On Mon, 29 Jul 2013, Andrew MacLeod wrote: complex I hadn't thought about until just now, I'll have to look. I know we can deal with parts on complex sometimes. Hopefully at gimplification time we still have the whole complex reference and if we just take care of that with the atomic builtins, we'll maintain the entire thing as we need. You have things in a fairly complicated form, building up COMPLEX_EXPRs out of operations on the individual parts of the complex operands. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH v2 08/18] convert the ObjC++ front end to automatic dependencies
Mike == Mike Stump mikest...@comcast.net writes: +objcp/objcp-act.o : objc/objc-act.c +objcp/objc-encoding.o : objc/objc-encoding.c +objcp/objc-map.o : objc/objc-map.c Mike Please, no space before :. Ok with that. I'll make the change, but please note that this is how it was before my patch. This fact is obscured by the way diff chooses to show the changes. Ordinarily I would not make a reformatting change like this at the same time as a non-formatting change. Tom
Re: [PATCH v2 00/18] resurrect automatic dependencies
On Jul 29, 2013, at 9:24 AM, Tom Tromey tro...@redhat.com wrote: This is a refresh of my series to resurrect automatic dependency tracking. I've looked over the whole set and I like the direction. Thanks.
[C++ Patch] PR 57948
Hi,
this testcase triggers the gcc_assert in initialize_reference because
the conv returned by reference_binding has conv-kind == ck_ambig.
Before the crash, the diagnostic about ambiguous conversion is produced
by build_user_type_conversion_1, and it seems that in this case too we
can safely return error_mark_node, as happens when it's called by
build_user_type_conversion instead of direct_reference_binding.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2013-07-29 Paolo Carlini paolo.carl...@oracle.com
PR c++/57948
* call.c (initialize_reference): Don't crash when reference_binding
returns a conv with conv-kind == ck_ambig.
/testsuite
2013-07-29 Paolo Carlini paolo.carl...@oracle.com
PR c++/57948
* g++.dg/conversion/ambig2.C: New.
Index: cp/call.c
===
--- cp/call.c (revision 201313)
+++ cp/call.c (working copy)
@@ -9282,11 +9282,15 @@ initialize_reference (tree type, tree expr,
return error_mark_node;
}
- gcc_assert (conv-kind == ck_ref_bind);
+ if (conv-kind == ck_ref_bind)
+/* Perform the conversion. */
+expr = convert_like (conv, expr, complain);
+ else if (conv-kind == ck_ambig)
+/* We gave an error in build_user_type_conversion_1. */
+expr = error_mark_node;
+ else
+gcc_unreachable ();
- /* Perform the conversion. */
- expr = convert_like (conv, expr, complain);
-
/* Free all the conversions we allocated. */
obstack_free (conversion_obstack, p);
Index: testsuite/g++.dg/conversion/ambig2.C
===
--- testsuite/g++.dg/conversion/ambig2.C(revision 0)
+++ testsuite/g++.dg/conversion/ambig2.C(working copy)
@@ -0,0 +1,18 @@
+// PR c++/57948
+
+struct Base { };
+struct Derived : Base
+{
+ struct Derived2 : Base
+ {
+struct ConvertibleToBothDerivedRef
+{
+ operator Derived();
+ operator Derived2();
+ void bind_lvalue_to_conv_lvalue_ambig(ConvertibleToBothDerivedRef both)
+ {
+ Base br1 = both; // { dg-error ambiguous }
+ }
+};
+ };
+};
[PATCH] libgcc/MIPS: Fill in delay slots of (some) MIPS16 call stubs
Hi, A shortcoming of older versions of GAS makes branch swapping not happen if the instruction to be reordered into a branch delay slot immediately follows a delay slot of another branch. This happens to hit some MIPS16 call stubs, e.g. (from libgcc.a): __mips16_call_stub_sf_0: 0: 03e09021moves2,ra 4: 0040f809jalrv0 8: 0040c821movet9,v0 c: 4402mfc1v0,$f0 10: 0248jr s2 14: nop The shortcoming has been recently lifted, but I gather GCC generally wants to (and does) schedule delay slots elsewhere manually, so why not to do so here as well. The piece of code above is generated from libgcc/config/mips/mips16.S with a macro called DELAYf() meant for pieces that read from an FPR. There's a complementing macro called DELAYt() to write an FPR that does schedule the delay slot manually. The reason for such an arrangement is I believe a possibility that a read from CP1 may require another instruction to complete before the value read is available in the destination GPR (a coprocessor move delay slot). I believe the only legacy MIPS processors that implemented the MIPS16 ASE in its original variation (i.e. with no compact jumps, no SAVE/RESTORE, and no extend instructions) were the LSI's TinyRISC cores. It's unclear to me from TinyRISC documentation whether these cores suffered from the coprocessor move delay slot. They featured a short three-stage pipeline that had a bypass implemented to make data from memory loads available to the immediately following instruction if needed, in parallel to the destination register write back, to avoid load delay slots. Unfortunately documentation does not mention whether such a bypass was available for coprocessor moves or not, even though the instructions are said to have the very same pipeline stages as memory moves. It is therefore safe to assume coprocessor move delay slots were required. OTOH no modern MIPS architecture processor requires coprocessor move delay slots (they were lifted with the MIPS IV ISA legacy ISA already), hence the current arrangement incurs unnecessary text space consumption and a performance hit for all the modern targets. Especially as in many cases the cases the next instruction executed after the branch delay slot will not access the GPR anyway and thus will not cause any potential pipeline stall even with any less efficient architecture implementations. This change therefore enables manual delay-slot scheduling of move-from-CP1 instructions whenever the stubs are built for the MIPS IV or a newer ISA. It makes the stub above look like this: __mips16_call_stub_sf_0: 0: 03e09021moves2,ra 4: 0040f809jalrv0 8: 0040c821movet9,v0 c: 0248jr s2 10: 4402mfc1v0,$f0 These stubs are I believe not really covered in our testing, because they require a mixed standard-MIPS/MIPS16 environment. I have therefore verified libgcc.a object code by inspection to be still correct after this change, i.e. no change at all with current GAS (that otherwise schedules these move-from-CP1 instructions into the following jump's delay slot automatically) and the expected improved code with old GAS (that otherwise inserts a NOP into that delay slot instead). OK to apply? 2013-07-29 Maciej W. Rozycki ma...@codesourcery.com libgcc/ * config/mips/mips16.S (DELAYf): Alias to DELAYt for the MIPS IV ISA and up. Maciej gcc-mips16-stub-delay-slot.patch Index: gcc-fsf-trunk-quilt/libgcc/config/mips/mips16.S === --- gcc-fsf-trunk-quilt.orig/libgcc/config/mips/mips16.S2013-03-27 15:20:54.0 + +++ gcc-fsf-trunk-quilt/libgcc/config/mips/mips16.S 2013-07-13 02:40:38.300930313 +0100 @@ -89,8 +89,13 @@ see the files COPYING3 and COPYING.RUNTI OPCODE, OP2;\ .setreorder +#if __mips = 4 +/* Coprocessor moves are interlocked from the MIPS IV ISA up. */ +#define DELAYf(T, OPCODE, OP2) DELAYt (T, OPCODE, OP2) +#else /* Use OPCODE. OP2 and jump to T. */ #define DELAYf(T, OPCODE, OP2) OPCODE, OP2; jr T +#endif /* MOVE_SF_BYTE0(D) Move the first single-precision floating-point argument between
Re: [PATCH] Add atomic type qualifier
On 07/29/2013 12:42 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
complex I hadn't thought about until just now, I'll have to look. I know we
can deal with parts on complex sometimes. Hopefully at gimplification time
we still have the whole complex reference and if we just take care of that
with the atomic builtins, we'll maintain the entire thing as we need.
You have things in a fairly complicated form, building up COMPLEX_EXPRs
out of operations on the individual parts of the complex operands.
I tried:
__complex__ double d;
int main (void)
{
d = 0;
d = d + 5;
}
and it seems to break it into:
d = __complex__ (0.0, 0.0);
and
d.1 = d;
d.0 = d.1;
D.1723 = REALPART_EXPR d.0;
D.1724 = D.1723 + 5.0e+0;
D.1725 = IMAGPART_EXPR d.0;
d.2 = COMPLEX_EXPR D.1724, D.1725;
d = d.2;
so again the loads and stores to (D) appear to be completely wrap the
entire complex operation, so this should be handle-able the same way...
So you really should be able to key into the atomic load from D followed
by the store to D and look at whats in between.
I thini is is straightforward in the gimplifier, we ought to have the d
=d op V expression at some point and be able to detect that d is the
same and atomic, and check op. but if it turns out not to be, then I
could simply turn those atomic loads and stores into atomic loads and
stores in the gimplifier and stop there., Then have a very early
always-run SSA pass pattern match looking for atomic stores fed from
atomic loads, and examine the operations in between, looking for
patterns that match d = d op v, and then turning the loads/store and
intermediate bits into the specified compare_exchange loops...
I'll get to this shortly.
Andrew
C++ coding conventions: namespaces, references and getters (was Re: [PATCH 2/2] Introduce beginnings of a pipeline class.)
On Thu, 2013-07-25 at 15:08 +0200, Martin Jambor wrote:
Hi,
I don't know why it's me again but again I do have a few comments.
Thanks for looking over the patch.
One global remark first: If we are going to start using the gcc
namespace (I understand it you need for isolation of symbols once you
use gcc as library, right?), I'm wondering whether mixing using
namespace gcc and explicit identifier qualifications is a good idea.
We have never had a discussion about namespace conventions but I'd
suggest that you add the using directive at the top of all gcc source
files that need it and never use explicit gcc:: qualification (unless
there is a reason for it, of course, like in symbol definitions).
But perhaps someone else with more C++ experience disagrees?
http://gcc.gnu.org/codingconventions.html#Namespace_Use says:
Namespaces are encouraged. All separable libraries should have a
unique global namespace.
[...snip...]
Header files should have neither using directives nor namespace-scope
using declarations.
and the rationale doc says:
Using them within an implementation file can help conciseness.
However, there doesn't seem to be a discussion on the merits of the
various forms of using directives.
These aren't the GCC coding conventions, but the Google conventions:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Namespaces
forbid using directives of the form:
using NAMESPACE;
but suggest using directives of the form:
using NAMESPACE::NAME;
to pick out individual names from a namespace, though *not* in global
scope in a header (to avoid polluting the global namespace).
I like this approach - how about using it for frequently used names in
a .c/.cc file, keeping the names alphabetizing by fully qualified
path, so e.g.:
#include foo.h
...
#include bar.h
using gcc::context;
using gcc::pass_manager;
...etc, individually grabbing the names we'll be needing
// code follows
and thus avoiding grabbing whole namespaces, whilst keeping the code
concise.
I may want to violate that rule within gtype-desc.c, as per:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01262.html
to simplify handling of GTY and gcc::
A few more comments inline:
Likewise
[...]
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index b82c2e0..dc489fb 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -194,6 +194,8 @@ along with GCC; see the file COPYING3. If not see
#include except.h
#include cfgloop.h
#include regset.h /* FIXME: For reg_obstack. */
+#include context.h
+#include pipeline.h
/* Queue of cgraph nodes scheduled to be added into cgraph. This is a
secondary queue used during optimization to accommodate passes that
@@ -478,6 +480,7 @@ cgraph_finalize_function (tree decl, bool nested)
void
cgraph_add_new_function (tree fndecl, bool lowered)
{
+ gcc::pipeline passes = g-get_passes ();
struct cgraph_node *node;
switch (cgraph_state)
{
@@ -508,7 +511,7 @@ cgraph_add_new_function (tree fndecl, bool lowered)
push_cfun (DECL_STRUCT_FUNCTION (fndecl));
gimple_register_cfg_hooks ();
bitmap_obstack_initialize (NULL);
- execute_pass_list (all_lowering_passes);
+ execute_pass_list (passes.all_lowering_passes);
execute_pass_list (pass_early_local_passes.pass.sub);
bitmap_obstack_release (NULL);
pop_cfun ();
@@ -640,7 +643,7 @@ analyze_function (struct cgraph_node *node)
gimple_register_cfg_hooks ();
bitmap_obstack_initialize (NULL);
- execute_pass_list (all_lowering_passes);
+ execute_pass_list (g-get_passes ().all_lowering_passes);
free_dominance_info (CDI_POST_DOMINATORS);
free_dominance_info (CDI_DOMINATORS);
compact_blocks ();
@@ -1588,7 +1591,7 @@ expand_function (struct cgraph_node *node)
/* Signal the start of passes. */
invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
- execute_pass_list (all_passes);
+ execute_pass_list (g-get_passes ().all_passes);
/* Signal the end of passes. */
invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
@@ -1807,6 +1810,8 @@ output_in_order (void)
static void
ipa_passes (void)
{
+ gcc::pipeline passes = g-get_passes ();
+
set_cfun (NULL);
current_function_decl = NULL;
gimple_register_cfg_hooks ();
@@ -1816,7 +1821,7 @@ ipa_passes (void)
if (!in_lto_p)
{
- execute_ipa_pass_list (all_small_ipa_passes);
+ execute_ipa_pass_list (passes.all_small_ipa_passes);
if (seen_error ())
return;
}
@@ -1843,14 +1848,15 @@ ipa_passes (void)
cgraph_process_new_functions ();
execute_ipa_summary_passes
- ((struct ipa_opt_pass_d *) all_regular_ipa_passes);
+ ((struct ipa_opt_pass_d *) passes.all_regular_ipa_passes);
}
/* Some targets need to handle LTO assembler output specially. */
Re: [PATCH, rs6000] power8 patches, revised patch #8, power8 load fusion
This is the revised version of my patch #8 for power8 support. I have removed
all of the incidental changes, and only added the support for load fusion. I
have added support for fusion on 32-bit Linux. I have added a test to make
sure the fusion ops are being generated.
I have built a compiler on power7 with the bootstrap options to use
-mcpu=power7 -mtune=power8 (which turns on power8 fusion), and it bootstraps
with the change. There are no make check regressions with this patch.
I also have done a full 64-bit spec 2006 run comparing my normal power7
configuration to a configuration that enables power8 fusion. There were no
significant differences in any of the 29 benchmarks.
As I mentioned before a better solution is to rework the secondary reload
interface, so that we recognize more general addresses before reload, and keep
fusion addresses after reload. I have started work on doing this, but I expect
it will be some time before I get the code so that it is stable, and perhaps a
longer period of time before it is acceptable for release, and corner case bugs
fixed. So, I would like to install this temporary patch to enable load fusion
while I'm working on the final solution. Is this patch ok to install?
I should note that while fusion will be enabled for AIX and for 64-bit small
code model with this patch, I don't expect you would see as many fusion
opportunities as you would under 32-bit Linux and 64-bit Linux for medium/large
code models, due to the fact that the TOC address is not a fusion opportunity.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 201273)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -1702,3 +1702,91 @@ (define_predicate small_toc_ref
return GET_CODE (op) == UNSPEC XINT (op, 1) == UNSPEC_TOCREL;
})
+
+;; Match the first insn (addis) in fusing the combination of addis and loads to
+;; GPR registers on power8.
+(define_predicate fusion_gpr_addis
+ (match_code const_int,high,plus)
+{
+ HOST_WIDE_INT value;
+ rtx int_const;
+
+ if (GET_CODE (op) == HIGH)
+return 1;
+
+ if (CONST_INT_P (op))
+int_const = op;
+
+ else if (GET_CODE (op) == PLUS
+ base_reg_operand (XEXP (op, 0), Pmode)
+ CONST_INT_P (XEXP (op, 1)))
+int_const = XEXP (op, 1);
+
+ else
+return 0;
+
+ /* Power8 currently will only do the fusion if the top 11 bits of the addis
+ value are all 1's or 0's. */
+ value = INTVAL (int_const);
+ if ((value (HOST_WIDE_INT)0x) != 0)
+return 0;
+
+ if ((value (HOST_WIDE_INT)0x) == 0)
+return 0;
+
+ return (IN_RANGE (value 16, -32, 31));
+})
+
+;; Match the second insn (lbz, lhz, lwz, ld) in fusing the combination of addis
+;; and loads to GPR registers on power8.
+(define_predicate fusion_gpr_mem_load
+ (match_code mem)
+{
+ rtx addr;
+
+ if (!MEM_P (op))
+return 0;
+
+ switch (mode)
+{
+case QImode:
+case HImode:
+case SImode:
+ break;
+
+case DImode:
+ if (!TARGET_POWERPC64)
+ return 0;
+ break;
+
+default:
+ return 0;
+}
+
+ addr = XEXP (op, 0);
+ if (GET_CODE (addr) == PLUS)
+{
+ rtx base = XEXP (addr, 0);
+ rtx offset = XEXP (addr, 1);
+
+ return (base_reg_operand (base, GET_MODE (base))
+ satisfies_constraint_I (offset));
+}
+
+ else if (GET_CODE (addr) == LO_SUM)
+{
+ rtx base = XEXP (addr, 0);
+ rtx offset = XEXP (addr, 1);
+
+ if (!base_reg_operand (base, GET_MODE (base)))
+ return 0;
+
+ else if (TARGET_XCOFF || (TARGET_ELF TARGET_POWERPC64))
+ return small_toc_ref (offset, GET_MODE (offset));
+
+ else if (TARGET_ELF !TARGET_POWERPC64)
+ return CONSTANT_P (offset);
+}
+
+ return 0;
+})
Index: gcc/config/rs6000/rs6000-modes.def
===
--- gcc/config/rs6000/rs6000-modes.def (revision 201273)
+++ gcc/config/rs6000/rs6000-modes.def (working copy)
@@ -42,5 +42,7 @@ VECTOR_MODES (FLOAT, 8); /*
VECTOR_MODES (FLOAT, 16); /* V8HF V4SF V2DF */
VECTOR_MODES (FLOAT, 32); /* V16HF V8SF V4DF */
-/* Replacement for TImode that only is allowed in GPRs. */
+/* Replacement for TImode that only is allowed in GPRs. We also use PTImode
+ for quad memory atomic operations to force getting an even/odd register
+ combination. */
PARTIAL_INT_MODE (TI);
Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h (revision 201273)
+++ gcc/config/rs6000/rs6000-protos.h (working copy)
@@ -73,6 +73,8 @@ extern int mems_ok_for_quad_peep (rtx, r
extern bool gpr_or_gpr_p (rtx, rtx);
extern bool
Re: [PATCH] Fix PR57993 (ICE in slsr)
On 07/27/2013 06:51 PM, Bill Schmidt wrote: PR57993 reports a scenario where a conditional candidate is incorrectly replaced when its putative hidden basis (the basis hidden by one or more PHI nodes) does not dominate all of the PHI nodes on which the candidate depends. This indicates that the hidden basis was incorrectly identified as a useful basis for the candidate. There are two ways we can fix this. One would be to add more complexity to the code that determines the hidden basis. Currently that code does not recursively follow the PHI definitions backwards to ensure that the basis dominates all the PHIs. Adding code to do this would ensure we didn't identify an incorrect basis in the first place, but would duplicate quite a bit of existing logic in the later analysis phase, and increase compile time. What I've done here is to instead delay detection of the problem until the analysis phase. If we detect that we chose an invalid basis, we assign an infinite cost to the replacement so that we won't pursue it further. This requires that we know which basic block contains the basis statement. The basis statement may have itself been replaced by another statement earlier, so we need to keep the candidate table up to date with respect to such replacements. Bootstrapped and tested on powerpc64-linux-gnu with no new regressions. Ok for trunk? Thanks, Bill gcc: 2013-07-27 Bill Schmidt wschm...@vnet.linux.ibm.com * gimple-ssa-strength-reduction.c (replace_mult_candidate): Record replaced statement in the candidate table. (phi_add_costs): Return infinite cost when the hidden basis does not dominate all phis on which the candidate is dependent. (replace_one_candidate): Record replaced statement in the candidate table. gcc/testsuite: 2013-07-27 Bill Schmidt wschm...@vnet.linux.ibm.com * gcc.dg/torture/pr57993.c: New test. Looks good. Please install! Thanks, Jeff
Re: C++ coding conventions: namespaces, references and getters (was Re: [PATCH 2/2] Introduce beginnings of a pipeline class.)
On Mon, 2013-07-29 at 14:20 -0400, David Malcolm wrote: The same here and at a few other places. It may be just me not being used to references... nevertheless, if someone really wants to use them like this, at least make them const and you will save a night of frantic debugging to someone, probably to yourself. But I strongly prefer pointers... it's hard to describe how strongly I prefer them. OK. How do others feel? As I said above, I like the above idiom, since it puts the assertion of non-NULLness in a single place. I'm voting for references. References can be seen as yet another software structuring tool that instantly communicate some properties such as you mentioned above. In addition to that it's also a hint of ownership, i.e. if I get an object from somewhere I know that I better not even think about whether to delete it or not. Cheers, Oleg
Re: [Patch, PR 57800] Waste work in gfc_match_call()
On 07/23/2013 03:32 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800 Bootstrap and regression-tested on x86_64-linux. In method gfc_match_call() in gcc/fortran/match.c, the loop on line 4189 should break immediately after i is set to 1. 2013-07-22 Chang pcha...@cs.wisc.edu * match.c (gfc_match_call): Exit loop after setting i. Installed. Thanks! Jeff
Re: [Patch, PR 57801] Waste work in resolve_variable()
On 07/23/2013 03:39 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801 Bootstrap and regression-tested on x86_64-linux. In method resolve_variable() in gcc/fortran/resolve.c, the loop on line 4908 should break immediately after seen is set to true. 2013-07-23 Chang pcha...@cs.wisc.edu * resolve.c (resolve_variable): Exit loop after setting seen. Installed. Thanks. jeff
Re: [Patch, PR 57791] Waste work in gfc_check_pointer_assign()
On 07/23/2013 03:42 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791 Bootstrap and regression-tested on x86_64-linux. In method gfc_check_pointer_assign() in expr.c, the loop on line 3763 should break immediately after warn is set to true. 2013-07-23 Chang pcha...@cs.wisc.edu * expr.c (gfc_check_pointer_assign): Exit loop after setting warn. Installed. Thanks! jeff
Re: [Patch, PR 57802] Wasted work in set_loop_bounds()
On 07/23/2013 03:49 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802 Bootstrap and regression-tested on x86_64-linux. In method set_loop_bounds() in gcc/fortran/trans-array.c, the loop on line 4456 should break immediately after nonoptional_arr is set to true. 2013-07-23 Chang pcha...@cs.wisc.edu * trans-array.c (set_loop_bounds): Exit loop after setting nonoptional_arr. Thanks. Installed. jeff
Re: [Patch, PR 57804] Wasted work in gfc_trans_transfer()
On 07/23/2013 03:55 PM, pcha...@cs.wisc.edu wrote: Hi, The problem appears in revision 201034 in version 4.9. I attached a one-line patch that fixes it. I also reported this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804 Bootstrap and regression-tested on x86_64-linux. In method gfc_trans_transfer() in gcc/fortran/trans-io.c, the loop on line 2261 should break immediately after seen_vector is set to true. 2013-07-23 Chang pcha...@cs.wisc.edu * trans-io.c (gfc_trans_transfer): Exit loop after setting seen_vector. Installed. Thanks! jeff
Re: [PATCH] libgcc/MIPS: Fill in delay slots of (some) MIPS16 call stubs
Maciej W. Rozycki ma...@codesourcery.com writes: I believe the only legacy MIPS processors that implemented the MIPS16 ASE in its original variation (i.e. with no compact jumps, no SAVE/RESTORE, and no extend instructions) were the LSI's TinyRISC cores. Ah, hadn't realised that the original version had no EXTEND instruction. Which TinyRISC iteration was that? The LR4102 had it AFAIK. FWIW GCC and binutils always assume that EXTEND is available and just make a distinction between original MIPS16 (which sounds like it might not be as original as I'd thought) and MIPS16e. The VR4121 and VR4131 were also in the original MIPS16 category (no compact jumps, SAVE/RESTORE, etc.). But they also had no FPU. These stubs are I believe not really covered in our testing, because they require a mixed standard-MIPS/MIPS16 environment. What's the barrier to testing a mixed environment? The normal *-linux-gnu configurations have no MIPS16 multilibs, so you should be able to test it on a plain mips-linux-gnu configuration using --target_flags unix/-mips16. FWIW I've been using the mips64-linux-gnu equivalent (--target_flags unix/-mabi=32/-mips16) without problems. Or if you don't want to test on GNU/Linux, you should be able to use something like mips64-elf configured with whichever --with-arch= you like (and an appropriate simulator). Long time since I tried that though. I prefer testing on GNU/Linux because it also covers libgcc.so symbol visibility and has better libgfortran support. libgcc/ * config/mips/mips16.S (DELAYf): Alias to DELAYt for the MIPS IV ISA and up. OK, thanks, but please do run it through the testsuite first. Richard
Re: [C++ Patch] PR 57948
OK.
Re: [PATCH] libgcc/MIPS: Fill in delay slots of (some) MIPS16 call stubs
Richard Sandiford rdsandif...@googlemail.com writes: Maciej W. Rozycki ma...@codesourcery.com writes: I believe the only legacy MIPS processors that implemented the MIPS16 ASE in its original variation (i.e. with no compact jumps, no SAVE/RESTORE, and no extend instructions) were the LSI's TinyRISC cores. Ah, hadn't realised that the original version had no EXTEND instruction. Which TinyRISC iteration was that? The LR4102 had it AFAIK. *sigh*. I only just realised you meant the _register_ extend instructions (SEB, etc.). Sorry about that. Richard
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
On Thu, 2013-07-18 at 10:25 -0600, Jeff Law wrote: On 07/17/2013 07:18 PM, David Malcolm wrote: gcc/ Explicitly number the instances of passes within passes.def. This is needed by a subsequent patch so that we can create fields within the pipeline class for each pass instance (to help locate pass instances when debugging). * passes.c (NEXT_PASS_NUM): Define. * passes.def (NEXT_PASS, NEXT_PASS_NUM): Replace uses of NEXT_PASS on passes that have multiple instances with uses of NEXT_PASS_NUM. So this means we have to track down the instance number if we add a duplicate pass in the pipeline. I can see positives and negatives of doing that. I'll go along as I'm a proponent of the goal of having the passes be a first class object. Ok for the trunk. Thanks. Out of interest, what do you see as the positives and negatives? Given Andrew's objections to managing pass instance numbers by hand, I went with an alternate approach, and wrote an awk script to generate a pass-instances.def from passes.def at build time: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01263.html in the patch series I sent for review on Friday. This approach would give us the uniqueness I was looking for (so that the pass_manager class can have fields tracking all the pass instances), avoids having to maintain the numbers by hand, and also gives us an easy way of e.g. seeing how many pass_copy_prop instances we have, and what their instance numbers are (see the example of the result at: http://dmalcolm.fedorapeople.org/gcc/2013-07-25/pass-instances.def ) Dave
PATCH Re: [c++] Question about write_unscoped_name (const tree decl)
On 07/29/2013 10:37 AM, Jason Merrill wrote:
Yep, I'll deal.
Thus.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1b76aeef615189d8b224201dac911f479900f0f5
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 29 10:32:20 2013 -0400
* mangle.c (write_name): Check for null context.
(write_unscoped_name): Allow PARM_DECL context.
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 68b956b..3cfca58 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -798,13 +798,14 @@ write_name (tree decl, const int ignore_local_scope)
context = decl_mangling_context (decl);
+ gcc_assert (context != NULL_TREE);
+
/* A decl in :: or ::std scope is treated specially. The former is
mangled using unscoped-name or unscoped-template-name, the
latter with a special substitution. Also, a name that is
directly in a local function scope is also mangled with
unscoped-name rather than a full nested-name. */
- if (context == NULL
- || context == global_namespace
+ if (context == global_namespace
|| DECL_NAMESPACE_STD_P (context)
|| (ignore_local_scope
(TREE_CODE (context) == FUNCTION_DECL
@@ -837,10 +838,10 @@ write_name (tree decl, const int ignore_local_scope)
directly in that function's scope, either decl or one of
its enclosing scopes. */
tree local_entity = decl;
- while (context != NULL context != global_namespace)
+ while (context != global_namespace)
{
/* Make sure we're always dealing with decls. */
- if (context != NULL TYPE_P (context))
+ if (TYPE_P (context))
context = TYPE_NAME (context);
/* Is this a function? */
if (TREE_CODE (context) == FUNCTION_DECL
@@ -883,9 +884,10 @@ write_unscoped_name (const tree decl)
else
{
/* If not, it should be either in the global namespace, or directly
- in a local function scope. */
+ in a local function scope. A lambda can also be mangled in the
+ scope of a default argument. */
gcc_assert (context == global_namespace
- || context != NULL
+ || TREE_CODE (context) == PARM_DECL
|| TREE_CODE (context) == FUNCTION_DECL);
write_unqualified_name (decl);
Re: [PATCH 01/11] Introduce beginnings of a pipeline class.
On 07/26/2013 09:04 AM, David Malcolm wrote: gcc/ * Makefile.in (PIPELINE_H): New. (lto-cgraph.o): Depend on CONTEXT_H and PIPELINE_H. (passes.o): Likewise. (statistics.o): Likewise. (cgraphunit.o): Likewise. (context.o): Depend on PIPELINE_H. * pipeline.h: New. * cgraphunit.c (cgraph_add_new_function): Update for moves of globals to fields of pipeline. (analyze_function): Likewise. (expand_function): Likewise. (ipa_passes): Likewise. (compile): Likewise. * context.c (context::context): New. * context.h (context::context): New. (context::get_passes): New. (context::passes_): New. * lto-cgraph.c (input_node): Update for moves of globals to fields of pipeline. * passes.c (all_passes): Remove, in favor of a field of the same name within the new class pipeline. (all_small_ipa_passes): Likewise. (all_lowering_passes): Likewise. (all_regular_ipa_passes): Likewise. (all_late_ipa_passes): Likewise. (all_lto_gen_passes): Likewise. (passes_by_id): Likewise. (passes_by_id_size): Likewise. (gcc_pass_lists): Remove, in favor of pass_lists field within the new class pipeline. (set_pass_for_id): Convert to... (pipeline::set_pass_for_id): ...method. (get_pass_for_id): Convert to... (pipeline::get_pass_for_id): ...method. (register_one_dump_file): Move body of implementation into... (pipeline::register_one_dump_file): ...here. (register_dump_files_1): Convert to... (pipeline::register_dump_files_1): ...method. (register_dump_files): Convert to... (pipeline::register_dump_files): ...method. (create_pass_tab): Update for moves of globals to fields of pipeline. (dump_passes): Move body of implementation into... (pipeline::dump_passes): ...here. (register_pass): Move body of implementation into... (pipeline::register_pass): ...here. (init_optimization_passes): Convert into... (pipeline::pipeline): ...constructor for new pipeline class, and initialize the pass_lists array. (check_profile_consistency): Update for moves of globals to fields of pipeline. (dump_profile_report): Move body of implementation into... (pipeline::dump_profile_report): ...here. (ipa_write_summaries_1): Update for moves of pass lists from being globals to fields of pipeline. (ipa_write_optimization_summaries): Likewise. (ipa_read_summaries): Likewise. (ipa_read_optimization_summaries): Likewise. (execute_all_ipa_stmt_fixups): Likewise. * statistics.c (statistics_fini): Update for moves of globals to fields of pipeline. * toplev.c (general_init): Replace call to init_optimization_passes with construction of the pipeline instance. * tree-pass.h (all_passes): Remove, in favor of a field of the same name within the new class pipeline. (all_small_ipa_passes): Likewise. (all_lowering_passes): Likewise. (all_regular_ipa_passes): Likewise. (all_lto_gen_passes): Likewise. (all_late_ipa_passes): Likewise. (passes_by_id): Likewise. (passes_by_id_size): Likewise. (gcc_pass_lists): Remove, in favor of pass_lists field within the new class pipeline. (get_pass_for_id): Remove. gcc/lto/ * Make-lang.in (lto/lto.o:): Depend on CONTEXT_H and PIPELINE_H. * lto.c (do_whole_program_analysis): Update for move of all_regular_ipa_passes from a global to a field of class pipeline. So as has been discussed elsewhere I'd like to see pipeline changed to pass_manager. WRT references. Not being a C++ guy, I'd always mentally equated references with pointers. I've done a little reading and it seems that references actually convey more information, which I'm generally a fan of -- with the caveat that they're pointers that act more like values, which might get confusing. At least in the immediate term, I think we should stick with pointers until we have a clearer sense of whether or not we want to be using references in this way. I doubt it's terribly important, but the non-nullness ought to be expressable via an attribute. With the pipeline-pass_manager change and using pointers instead of references on the return type, this patch is fine. Pre-approved with those changes. Jeff
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
On 07/29/2013 01:32 PM, David Malcolm wrote: On Thu, 2013-07-18 at 10:25 -0600, Jeff Law wrote: On 07/17/2013 07:18 PM, David Malcolm wrote: gcc/ Explicitly number the instances of passes within passes.def. This is needed by a subsequent patch so that we can create fields within the pipeline class for each pass instance (to help locate pass instances when debugging). * passes.c (NEXT_PASS_NUM): Define. * passes.def (NEXT_PASS, NEXT_PASS_NUM): Replace uses of NEXT_PASS on passes that have multiple instances with uses of NEXT_PASS_NUM. So this means we have to track down the instance number if we add a duplicate pass in the pipeline. I can see positives and negatives of doing that. I'll go along as I'm a proponent of the goal of having the passes be a first class object. Ok for the trunk. Thanks. Out of interest, what do you see as the positives and negatives? Positives being the uniqueness (which you need). Negatives are maintenance as we add passes, in particular if a pass is run more than once. Given Andrew's objections to managing pass instance numbers by hand, I went with an alternate approach, and wrote an awk script to generate a pass-instances.def from passes.def at build time: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01263.html in the patch series I sent for review on Friday. Which is even better. jeff
Re: [PATCH 02/11] Generate pass-instances.def
On 07/26/2013 09:04 AM, David Malcolm wrote: Introduce a new gen-pass-instances.awk script, and use it at build time to make a pass-instances.def from passes.def. An example of the result can be seen at: http://dmalcolm.fedorapeople.org/gcc/2013-07-25/pass-instances.def The generated pass-instances.def contains similar content to passes.def, but the pass instances within it are explicitly numbered, so that e.g. the third instance of: NEXT_PASS (pass_copy_prop) becomes: NEXT_PASS (pass_copy_prop, 3) This is needed by a subsequent patch so that we can create fields within the pipeline class for each pass instance, where we need unique field names to avoid a syntax error. For example, all 8 instances of pass_copy_prop will need different names. e.g. opt_pass *pass_copy_prop_1; ... opt_pass *pass_copy_prop_8; I have successfully tested the script with gawk, with gawk using the -c compatibility option to turn off gawk extensions, and with busybox awk (versions tested were gawk-4.0.1 and busybox-1.19.4). This patch replaces a previous attempt at this: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00686.html which converted multi-instance passes to using a new NEXT_PASS_NUM macro, requiring the instance numbering within passes.def to be maintained by hand. In the new approach, the instance numbers are generated automatically, and are visible at build time, giving the uniqueness needed by later patches, whilst avoiding manual maintenance work, and also making it easy to see the instance numbering (by inspecting the generated pass-instances.def). gcc/ * Makefile.in (pass-instances.def): New. (passes.o): Replace dependency on passes.def with one on pass-instances.def * gen-pass-instances.awk: New. * passes.c (pipeline::pipeline): Use pass-instances.def rather than passes.def, updating local definition of NEXT_PASS macro to add an extra NUM parameter (currently unused). My awk-fu isn't all that great. I'm going to assume this works and that if it breaks, you own it :-) Fine for the trunk. jeff
Re: [PATCH 05/11] Add -fno-rtti when building plugins.
On 07/26/2013 09:04 AM, David Malcolm wrote: With the conversion of passes to C++ classes, plugins that add custom passes must create them by creating their own derived classes of the relevant subclass of opt_pass. gcc itself is built with -fno-rtti, hence there is no RTTI available for the opt_pass class hierarchy. Hence plugins that create passes will need to be built with RTTI disabled in order to link against gcc, or they will fail to load, with an error like: cc1: error: cannot load plugin ./selfassign.so ./selfassign.so: undefined symbol: _ZTI8opt_pass (aka typeinfo for opt_pass). gcc/testsuite * lib/plugin-support.exp (plugin-test-execute): Add -fno-rtti to optstr when building plugins. Approved for the trunk. jeff
RFA: Fix rtl-optimization/58021
The interesting case where we encounter a basic block head is when the
check of return_copy for BB_HEAD check succeeds with return_copy being
a label;
then last_insn is a NOTE_INSN_BASIC_BLOCK, and we must not try to split
off a part of the basic block before that note.
That can be properly tested for by changing the !INSN_P (last_insn)
check into a
NOTE_INSN_BASIC_BLOCK_P (last_insn) check.
last_insn == BB_HEAD (src_bb) can't actually be true, because we don't copy
return_copy to last_insn when we've bit BB_HEAD, so I removed that test.
bootstrapped / regtested on i686-pc-linux-gnu .
AFAICT, the second block split is useless, and could be replaced with
pre_exit = src_bb;
, and then the slack space allocated for post_entry / pre_exit blocks reduced
to two. However, I didn't want to tie a bugfix with a potentialy
destabilizing
cleanup - maybe there's some target port code (in the context of
likely spilled
classes?) that relies on the MODE_EXIT switch note only before, but in
a block separate from the return value copy?
2013-07-29 Joern Rennecke joern.renne...@embecosm.com
PR rtl-optimization/58021
* mode-switching.c (create_pre_exit): Always split of preceding
insns if we are not at the basic block head.
Index: mode-switching.c
===
--- mode-switching.c(revision 201313)
+++ mode-switching.c(working copy)
@@ -420,7 +420,7 @@ create_pre_exit (int n_entities, int *en
|| (GET_MODE_CLASS (GET_MODE (ret_reg)) != MODE_INT
nregs != 1));
- if (INSN_P (last_insn))
+ if (!NOTE_INSN_BASIC_BLOCK_P (last_insn))
{
before_return_copy
= emit_note_before (NOTE_INSN_DELETED, last_insn);
@@ -428,9 +428,8 @@ create_pre_exit (int n_entities, int *en
require a different mode than MODE_EXIT, so if we might
have such instructions, keep them in a separate block
from pre_exit. */
- if (last_insn != BB_HEAD (src_bb))
- src_bb = split_block (src_bb,
- PREV_INSN (before_return_copy))-dest;
+ src_bb = split_block (src_bb,
+ PREV_INSN (before_return_copy))-dest;
}
else
before_return_copy = last_insn;
Committed: Epiphany ashlv2si3
gcc.c-torture/execute/loop-2e.c was failing at -O3 for lack of an
ashlv2si3 operation, so I added that.
2013-07-29 Joern Rennecke joern.renne...@embecosm.com
* config/epiphany/epiphany.md (*isub_i+2): New peephole.
(ashlv2si3): New expander.
(*ashlv2si3_i): New define_insn_and_split.
* predicates.md (float_operation): Allow patterns with three
basic sub-patterns.
Index: config/epiphany/epiphany.md
===
--- config/epiphany/epiphany.md (revision 201313)
+++ config/epiphany/epiphany.md (working copy)
@@ -587,7 +587,7 @@ (define_insn subsi3_i
; After mode-switching, floating point operations, fp_sfuncs and calls
; must exhibit the use of the control register, lest the setting of the
; control register could be deleted or moved. OTOH a use of a hard register
-; greatly coundounds optimizers like the rtl loop optimizers or combine.
+; greatly counfounds optimizers like the rtl loop optimizers or combine.
; Therefore, we put an extra pass immediately after the mode switching pass
; that inserts the USEs of the control registers, and sets a flag in struct
; machine_function that float_operation can henceforth only match with that
@@ -1058,6 +1058,28 @@ (define_peephole2
(clobber (reg:CC CC_REGNUM))])]
)
+(define_peephole2
+ [(match_parallel 3 float_operation
+ [(set (match_operand:SI 0 gpr_operand )
+ (mult:SI
+ (match_operand:SI 1 gpr_operand )
+ (match_operand:SI 2 gpr_operand )))
+ (clobber (reg:CC_FP CCFP_REGNUM))])]
+ prev_active_insn (peep2_next_insn (0))
+get_attr_sched_use_fpu (prev_active_insn (peep2_next_insn (0)))
+peep2_regno_dead_p (1, CC_REGNUM)
+get_attr_sched_use_fpu (next_active_insn (peep2_next_insn (0)))
+find_reg_note (insn, REG_EQUAL, NULL_RTX) != NULL_RTX
+GET_CODE (XEXP (find_reg_note (insn, REG_EQUAL, NULL_RTX), 0)) == MULT
+CONST_INT_P (XEXP (XEXP (find_reg_note (insn, REG_EQUAL, NULL_RTX), 0),
+1))
+ [(parallel [(set (match_dup 0) (ashift:SI (match_dup 1) (match_dup 4)))
+ (clobber (reg:CC CC_REGNUM))])]
+{
+ operands[4]
+= XEXP (XEXP (find_reg_note (curr_insn, REG_EQUAL, NULL_RTX), 0), 1);
+})
+
(define_expand mulsi3
[(parallel
[(set (match_operand:SI 0 gpr_operand )
@@ -2530,6 +2552,106 @@ (define_insn_and_split insn_opnamev2s
[(set_attr length 8)
(set_attr type v2fp)])
+(define_expand ashlv2si3
+ [(parallel
+ [(set (match_operand:V2SI 0 gpr_operand )
+ (ashift:V2SI (match_operand:V2SI 1 gpr_operand )
+ (match_operand:SI 2 general_operand)))
+ (use (match_dup 3))
+ (clobber (reg:CC_FP CCFP_REGNUM))])]
+
+{
+ if (const_int_operand (operands[2], VOIDmode))
+operands[3]
+ = copy_to_mode_reg (SImode, GEN_INT (1 INTVAL (operands[2])));
+ else
+{
+ int o, i;
+ rtx xop[2], last_out = pc_rtx;
+
+ for (o = 0; o = UNITS_PER_WORD; o += UNITS_PER_WORD)
+ {
+ for (i = 0; i 2; i++)
+ {
+ xop[i]
+ = (i == 2 ? operands[2]
+ : simplify_gen_subreg (SImode, operands[i], V2SImode, o));
+ gcc_assert (!reg_overlap_mentioned_p (last_out, xop[i])
+ /* ??? reg_overlap_mentioned_p doesn't understand
+about multi-word SUBREGs. */
+ || (GET_CODE (last_out) == SUBREG
+ GET_CODE (xop[i]) == SUBREG
+ SUBREG_REG (last_out) == SUBREG_REG (xop[i])
+ ((SUBREG_BYTE (last_out) -UNITS_PER_WORD)
+ != (SUBREG_BYTE (xop[i])
-UNITS_PER_WORD;
+ }
+ emit_insn (gen_ashlsi3 (xop[0], xop[1], operands[2]));
+ last_out = xop[0];
+ }
+ DONE;
+}
+})
+
+(define_insn_and_split *ashlv2si3_i
+ [(match_parallel 3 float_operation
+ [(set (match_operand:V2SI 0 gpr_operand =r,*1*2)
+ (ashift:V2SI (match_operand:V2SI 1 gpr_operand r,r)
+ (match_operand 2 const_int_operand n,n)))
+ (use (match_operand:SI 4 gpr_operand r,r))
+ (clobber (reg:CC_FP CCFP_REGNUM))])]
+
+ #
+ reload_completed
+ [(parallel
+ [(set (match_dup 5) (mult:SI (match_dup 6) (match_dup 4)))
+ (clobber (reg:CC_FP CCFP_REGNUM))
+ (match_dup 9)
+ (match_dup 10)])
+ (parallel
+ [(set (match_dup 7) (mult:SI (match_dup 8) (match_dup 4)))
+ (clobber (reg:CC_FP CCFP_REGNUM))
+ (match_dup 9)
+ (match_dup 10)])]
+{
+ operands[5] = simplify_gen_subreg (SImode, operands[0], V2SImode, 0);
+ operands[6] = simplify_gen_subreg (SImode, operands[1], V2SImode, 0);
+ operands[7] = simplify_gen_subreg (SImode, operands[0],
+V2SImode, UNITS_PER_WORD);
+ operands[8] = simplify_gen_subreg
Committed: Disable gcc.dg/tree-ssa/pr44258.c scan for Epiphany.
2013-07-29 Joern Rennecke joern.renne...@embecosm.com
* gcc.dg/tree-ssa/pr44258.c: Disable scan test for Epiphany.
Index: gcc.dg/tree-ssa/pr44258.c
===
--- gcc.dg/tree-ssa/pr44258.c (revision 201313)
+++ gcc.dg/tree-ssa/pr44258.c (working copy)
@@ -39,5 +39,7 @@ int foo (int b)
*e_u = u;
}
-/* { dg-final { scan-tree-dump-times Created a replacement 0 esra} } */
+/* Epiphany has struct alignment/padding that avoids the overlap of
+ str.b1 and val.b2. */
+/* { dg-final { scan-tree-dump-times Created a replacement 0 esra { target
{ ! epiphany-*-* } } } } */
/* { dg-final { cleanup-tree-dump esra } } */
Re: [Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization
Hi Tobias, here is a fix for class pointer initialization. I think the patch looks reasonable. well, it may appear so ... Additionally, the CLASS are wrongly initialized: You only set _data (indirectly as it is the first field/component of the class) but you do not set the _vptr component. ... but as you point out, it clearly produces wrong code :( The attached new version should do the right thing now. At least it shows the correct dump for the original test case as well as yours. It is currently being regtested. PS: The test case. With module - fails at run time for same_type_as. Without module - one gets an ICE. This now gives the correct run-time behavior with the module, but still ICEs without. Unfortunately I have no idea why ... Anyway, thanks for your review. Cheers, Janus pr57306_v3.diff Description: Binary data
Re: [PATCH] libgcc/MIPS: Fill in delay slots of (some) MIPS16 call stubs
On Mon, 29 Jul 2013, Richard Sandiford wrote: I believe the only legacy MIPS processors that implemented the MIPS16 ASE in its original variation (i.e. with no compact jumps, no SAVE/RESTORE, and no extend instructions) were the LSI's TinyRISC cores. Ah, hadn't realised that the original version had no EXTEND instruction. Which TinyRISC iteration was that? The LR4102 had it AFAIK. FWIW GCC and binutils always assume that EXTEND is available and just make a distinction between original MIPS16 (which sounds like it might not be as original as I'd thought) and MIPS16e. The VR4121 and VR4131 were also in the original MIPS16 category (no compact jumps, SAVE/RESTORE, etc.). But they also had no FPU. I meant the sign- and zero-extend instructions indeed, not the EXTEND opcode (not really a distinct instruction, more like a prefix), sorry for not being clear enough. Thanks for the reminder of the NEC silicon. These stubs are I believe not really covered in our testing, because they require a mixed standard-MIPS/MIPS16 environment. What's the barrier to testing a mixed environment? The normal *-linux-gnu configurations have no MIPS16 multilibs, so you should be able to test it on a plain mips-linux-gnu configuration using --target_flags unix/-mips16. FWIW I've been using the mips64-linux-gnu equivalent (--target_flags unix/-mabi=32/-mips16) without problems. Or if you don't want to test on GNU/Linux, you should be able to use something like mips64-elf configured with whichever --with-arch= you like (and an appropriate simulator). Long time since I tried that though. I prefer testing on GNU/Linux because it also covers libgcc.so symbol visibility and has better libgfortran support. We don't have specific coverage, but something in the testsuite might happen to pull one or more of these thunks indeed. libgcc/ * config/mips/mips16.S (DELAYf): Alias to DELAYt for the MIPS IV ISA and up. OK, thanks, but please do run it through the testsuite first. I'll see if I can do it -- the MIPS/Linux tree I used for recent MIPS32r2 MADD.fmt testing has no MIPS16 multilibs configured, so it might happen to just work with -mips16 passed as an extra option (otherwise MIPS16 libs would be automagically picked instead). I'll check if binaries executeed really pulled any of the thunks concerned. Maciej
Re: RFA: Fix rtl-optimization/58021
On 07/29/2013 02:24 PM, Joern Rennecke wrote: The interesting case where we encounter a basic block head is when the check of return_copy for BB_HEAD check succeeds with return_copy being a label; then last_insn is a NOTE_INSN_BASIC_BLOCK, and we must not try to split off a part of the basic block before that note. That can be properly tested for by changing the !INSN_P (last_insn) check into a NOTE_INSN_BASIC_BLOCK_P (last_insn) check. last_insn == BB_HEAD (src_bb) can't actually be true, because we don't copy return_copy to last_insn when we've bit BB_HEAD, so I removed that test. bootstrapped / regtested on i686-pc-linux-gnu . OK for the trunk. AFAICT, the second block split is useless, and could be replaced with pre_exit = src_bb; , and then the slack space allocated for post_entry / pre_exit blocks reduced to two. However, I didn't want to tie a bugfix with a potentialy destabilizing cleanup - maybe there's some target port code (in the context of likely spilled classes?) that relies on the MODE_EXIT switch note only before, but in a block separate from the return value copy? Well, the mode switching code is only used on sh (which you obviously know quite well) x86 and the epiphany ports. I trust your judgement on this since you've probably dealt more with the optimize_switching code than anyone. jeff
Re: [PATCH 03/11] Handwritten part of conversion of passes to C++ classes
On 07/26/2013 09:04 AM, David Malcolm wrote: This patch is the hand-written part of the conversion of passes from C structs to C++ classes. It does not work without the subsequent autogenerated part, which is huge. [ ... ] With the changes from pipeline - pass_manager this is fine. As is the follow-up autogenerated patch. Jeff
Re: [Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization
2013/7/29 Janus Weil ja...@gcc.gnu.org: Hi Tobias, here is a fix for class pointer initialization. I think the patch looks reasonable. well, it may appear so ... Additionally, the CLASS are wrongly initialized: You only set _data (indirectly as it is the first field/component of the class) but you do not set the _vptr component. ... but as you point out, it clearly produces wrong code :( The attached new version should do the right thing now. At least it shows the correct dump for the original test case as well as yours. It is currently being regtested. unfortunately it shows a couple of runtime problems with type-bound operators: FAIL: gfortran.dg/class_defined_operator_1.f03 -O0 execution test FAIL: gfortran.dg/typebound_operator_13.f03 -O0 execution test FAIL: gfortran.dg/typebound_operator_7.f03 -O0 execution test FAIL: gfortran.dg/typebound_operator_8.f03 -O0 execution test FAIL: gfortran.dg/typebound_operator_9.f03 -O0 execution test gfortran-4.9 class_defined_operator_1.f03 ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Will investigate ... Cheers, Janus
Re: [PATCH] Add atomic type qualifier
On 07/29/2013 12:06 PM, Joseph S. Myers wrote: On Mon, 29 Jul 2013, Andrew MacLeod wrote: I planned to do the work in gimplification... let the atomic decls through, and during gimplification, loads or stores of an atomic decl would be converted to the appropriate load or store builtin, and at the same time recognize the 'decl = decl op value' expression and replace those as appropriate with atomic_op_fetch operations. I had discussed this at some length with Lawrence crowl and Jeffrey Yasskin some time ago.. At gimplification time we no longer know whether the original form was decl op= val or decl = decl op val;, but the decision was that it is ok to recognize decl = decl op val and make that atomic.. it would still satisfy the language requirements.. I think that's probably OK (though, is this a theorem of the formal modelling work that has been done on the memory model?), but note it's not just a decl but an arbitrary pointer dereference (the address of the lvalue is only evaluated once, no matter how many compare-and-exchange operations are needed), and the operation may end up looking like *ptr = (convert to type of *ptr) ((promote) *ptr op (promote) val) rather than a simple decl = decl op val. Or something more complicated if the operation involves complex numbers - look at what gets for mixed real / complex arithmetic, for example. Given _Atomic _Complex float f; double d; f += d; the atomicity is for the whole complex number (and so the compare-and-exchange needs to work on the whole number) although only the real part is modified by the addition. Ive been poking at this today, and Im wondering what you think of the idea of adding a flag to MODIFY_EXPR, #define MODIFY_EXPR_IS_COMPOUND(NODE) MODIFY_EXPR_CHECK(NODE)-base.asm_written_flag and set that in the MODIFY_EXPR node when we create it from the x op= y form in the front end. That flag seems to be free for expressions. It will then be trivial to locate these expressions and issue a builtin or the wrapper compare_exchange code during gimplification. We just check if MODIFY_EXPR_IS_COMPOUND() is true and TYPE_ATOMIC() is set on the expression type. (Ive already confirmed the atomic type is set as the attribute ripples up to the MODIFY_EXPR node's type.) then we know all the important bits from the MODIFY_EXPR to perform the operation. Otherwise, it looks like it can get a bit hairy... What do you think? As a side effect, we also only get it for the actual statements we care about as well. Andrew
Re: [Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization
The attached new version should do the right thing now. At least it shows the correct dump for the original test case as well as yours. It is currently being regtested. unfortunately it shows a couple of runtime problems with type-bound operators: FAIL: gfortran.dg/class_defined_operator_1.f03 -O0 execution test FAIL: gfortran.dg/typebound_operator_13.f03 -O0 execution test FAIL: gfortran.dg/typebound_operator_7.f03 -O0 execution test FAIL: gfortran.dg/typebound_operator_8.f03 -O0 execution test FAIL: gfortran.dg/typebound_operator_9.f03 -O0 execution test The attached update fixes it, and thus should hopefully be regression-free. It also renames 'gfc_class_null_initializer' to 'gfc_class_initializer', since it now also does other initializations beside EXPR_NULL. Will do another regtest to make sure it's clean. Ok for trunk if it passes? Cheers, Janus pr57306_v4.diff Description: Binary data
Re: [patch] Add new -gmlt option for min. debug info with line tables (issue 4440072)
Is anyone still working on this? It would be very useful to include this option in gcc trunk, and have either -g1 or -gmlt emit line number information. This saves considerable space and time during compilation for large builds where full debug info is not needed, but line numbers in stack traces are still helpful (e.g. regression testing opt builds) If I can help somehow, please let me know how. I sent a revised patch a few months ago: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00260.html But got no response at all. I had intended to ping it after Stage 1 reopened, but I didn't get around to it (it's been a low priority). I'll ping it to get approval for the parts that are outside dwarf2out proper, and try to get it committed soon. Sorry for the delay. -cary
Re: [PATCH, libgcc] Fix licenses on several files
n 30/07/2013, at 2:06 AM, Ondřej Bílka wrote: On Mon, Jul 29, 2013 at 12:10:42PM +0100, Marcus Shawcroft wrote: On 28/07/13 23:03, Maxim Kuvyrkov wrote: While verifying license compliance for GCC and its libraries I noticed that several libgcc files that end up in the final library are licensed under GPL-3.0+ instead of GPL-3.0-with-GCC-exception. This is, obviously, was not the intention of developers who just copied wrong boilerplate text, and this patch fixes the oversights. To be sure it would be good idea to have check for this issue. First question is which files need copyright exception? Second is which files actually have this license. As first approximation I used: git grep Section 7 of GPL version 3 Is that list full or did I missed something? I used fossology's nomos license checker. The license checker can be run standalone and outputs a list of licenses a given file has (install fossology 2.2 or later and you can run /usr/share/fossology/nomos/agent/nomos list of files). We could add a post-commit hook that sends a warning to the mailing list if a new or changed file under libgcc, libstdc++, etc. has a more restrictive license than intended for these libraries (e.g., GPLv3 without exception). -- Maxim Kuvyrkov www.kugelworks.com
