RFC: generalize STARTFILE/ENDFILE_SPEC for linux
Hello!
Would the attached patch be acceptable?
The gcc.c patch part should really go to gcc/config/linux.h, but sadly not
all archs include that file.
for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility
would be
%{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
%{ffast-math|funsafe-math-optimizations:%:if-exists(crtfastmath.o%s)}
Thanks, Peter
PS: please CC to me, not on ml.
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
--- gcc-4.1/gcc/config/alpha/elf.h.startend~2005-09-05 15:42:35 +0200
+++ gcc-4.1/gcc/config/alpha/elf.h 2006-01-09 02:12:01 +0100
@@ -392,25 +392,16 @@
before entering `main'. */
#undef STARTFILE_SPEC
-#ifdef HAVE_LD_PIE
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
- crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#else
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p:gcrt1.o%s;:crt1.o%s}}\
- crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#endif
+#define STARTFILE_SPEC STARTFILE_PIE_LINUX_SPEC
/* Provide a ENDFILE_SPEC appropriate for ELF. Here we tack on the
magical crtend.o file which provides part of the support for
getting C++ file-scope static object constructed before entering
`main', followed by a normal ELF "finalizer" file, `crtn.o'. */
+#define HAVE_ENDFILE_MATH 1
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
- %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+#define ENDFILE_SPEC ENDFILE_PIE_LINUX_SPEC
/* We support #pragma. */
#define HANDLE_SYSV_PRAGMA 1
--- gcc-4.1/gcc/config/arm/uclinux-elf.h.startend~ 2005-11-12 21:35:52
+0100
+++ gcc-4.1/gcc/config/arm/uclinux-elf.h2006-01-09 02:12:35 +0100
@@ -44,13 +44,9 @@
provides part of the support for getting C++ file-scope static
object constructed before entering `main'. */
+#define HAVE_NOSTARTFILE_STATIC 1
#undef STARTFILE_SPEC
-#define STARTFILE_SPEC \
- "%{!shared: \
- %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} \
- %{!p:%{profile:gcrt1.o%s} \
-%{!profile:crt1.o%s \
- crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}"
+#define STARTFILE_SPEC STARTFILE_PIE_LINUX_SPEC
/* Provide a ENDFILE_SPEC appropriate for GNU/Linux. Here we tack on
the GNU/Linux magical crtend.o file (see crtstuff.c) which
@@ -59,8 +55,7 @@
GNU/Linux "finalizer" file, `crtn.o'. */
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s"
+#define ENDFILE_SPEC ENDFILE_PIE_LINUX_SPEC
#undef CC1_SPEC
#define CC1_SPEC "%{profile:-p}"
--- gcc-4.1/gcc/config/frv/linux.h.startend~2006-01-09 02:18:18 +0100
+++ gcc-4.1/gcc/config/frv/linux.h 2006-01-09 02:18:46 +0100
@@ -28,13 +28,10 @@
"%{!mno-fdpic:-mfdpic}",
#undef STARTFILE_SPEC
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
- crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+#define STARTFILE_SPEC STARTFILE_PIE_LINUX_SPEC
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+#define ENDFILE_SPEC ENDFILE_PIE_LINUX_SPEC
#undef LINK_SPEC
#define LINK_SPEC "\
--- gcc-4.1/gcc/config/i386/linux.h.startend~ 2006-01-09 02:22:49 +0100
+++ gcc-4.1/gcc/config/i386/linux.h 2006-01-09 02:23:47 +0100
@@ -122,10 +122,8 @@
%{static:-static}}}"
/* Similar to standard Linux, but adding -ffast-math support. */
-#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
- %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+#define HAVE_ENDFILE_MATH 1
+#undef ENDFILE_SPEC ENDFILE_PIE_LINUX_SPEC
/* A C statement (sans semicolon) to output to the stdio stream
FILE the assembler definition of uninitialized global DECL named
--- gcc-4.1/gcc/config/ia64/linux.h.startend~ 2004-09-08 02:17:14 +0200
+++ gcc-4.1/gcc/config/ia64/linux.h 2006-01-09 02:11:09 +0100
@@ -16,23 +16,15 @@
builtin_define("_LONGLONG");\
} while (0)
-/* Need to override linux.h STARTFILE_SPEC, since it has crtbeginT.o in. */
+#define HAVE_NOSTARTFILE_STATIC 1
#undef STARTFILE_SPEC
-#ifdef HAVE_LD_PIE
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
- crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#else
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p|profile:gcrt1.o%s;:crt1.o%s}}\
- crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#endif
+#define STARTFILE_SPEC STARTFILE_PIE_LINUX_SPEC
/* Similar to standard Linux, but adding -ffast-math support. */
+
+#define HAVE_ENDFILE_MATH 1
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
- %{shared|pie:crtendS.o%s;:crtend.o%s}
Re: RFC: generalize STARTFILE/ENDFILE_SPEC for linux
On Mon, Jan 09, 2006 at 02:38:17PM +0100, Peter S. Mazinger wrote:
> for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility
> would be
> %{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
> %{ffast-math|funsafe-math-optimizations:%:if-exists(crtfastmath.o%s)}
That's IMHO a bad idea, because that means additional runtime overhead.
Jakub
Re: A questionable predicate in sh/predicates.md
Kazu Hirata wrote: Notice that match_code at the beginning does not mention PARALLEL, but we have GET_CODE (op) != PARALLEL later. Is this predicate intended to accept PARALLEL as well? Yes, it is. If so, should we change the match_code at the beginning? Yes.
Re: [gcjx] Tree-SSA Operands Processing Problem
On Mon, 2006-01-09 at 08:22 +0530, Ranjit Mathew wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > However, it still remains true that the code path > I referred to is wrong and if, as you say, it can > never be taken, it should just be removed and > replaced with an assertion codifying what you > are saying. That path in add_stmt_operands can be taken from other call points (ie those which pass in real operands), but never from the call point you mention, if the call clobbered list is set up correctly. You could stick an assert before calling add_stmt_operands to make sure that the variable in question is !is_gimple_reg(). It would probably be more effective to simply put the assert in mark_call_clobbered() where the call clobbered list is built to make sure that we never insert real registers into it. This would probably catch your bug quicker and be more to the point of what seems to be wrong. Andrew
Re: RFC: generalize STARTFILE/ENDFILE_SPEC for linux
On Mon, 9 Jan 2006, Jakub Jelinek wrote:
> On Mon, Jan 09, 2006 at 02:38:17PM +0100, Peter S. Mazinger wrote:
> > for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility
> > would be
> > %{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
> > %{ffast-math|funsafe-math-optimizations:%:if-exists(crtfastmath.o%s)}
>
> That's IMHO a bad idea, because that means additional runtime overhead.
>
> Jakub
ok, haven't thought of the performance impact, the patch as it is won't
have this problem.
Thanks, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Static coverage analysis with 'gcov'.
Greetings. Has anyone done or is aware of static coverage analysis tools that can be used with GCC? I know that people have used 'gcov' with the Linux kernel and User Mode Linux (UML) to do analysis with the kernel. I actually want to do coverage analysis on bootloader code from YAMON (used mostly on MIPS board). Obviously, I cannot invoke 'gcov' on bootloader code and thus the conundrum. Thanks in advance. -Steve
Re: Atomic operations on Sparc in libstdc++
Piotr, Hello. First, a note: you should be sending libstdc++ mail to the [EMAIL PROTECTED] list. I haven't verified your claim, but if it is true, I would suggest the following actions on your part to solve it: 1) enter a sparc backend bug in gcc bugzilla about not defining __sparcv9 in 32 bit mode. Make sure the sparc maintainer is cc'd. (That would be Eric Botcazou). 2) enter a libstdc++ feature request in gcc bugzilla about 32bit atomic operations on sparc. Please include the atomic operations you've developed and would like to be part of libstdc++. I don't have access (or time) to deal with sun/sparc issues directly at the moment, but hopefully this will be useful to you. best, benjamin
Fix PR/25677, rare bug in combine
This is a severe, but very rare, bug in combine, that one of the recent
changes have exposed. I don't know which.
Basically, combine will not try combining across call instructions, but
on the other hand it will not invalidate equivalences with registers
that are explicitly set in the call instruction. This patch teaches it
about this case.
Also, record_value_for_reg had a comment saying
"If INSN is zero, don't update reg_stat[].last_set; this is
only permitted with VALUE also zero and is used to invalidate the
register"
However, this feature was never used, and as implemented it was not
sufficient to fix the bug. So, I made combine set "last_set_invalid"
too when INSN == VALUE == NULL_RTX.
Combine already has a loop that tries to invalidate call-clobbered
register. The logic is the same as calling record_value_for_reg
*before* my bug fix. However I did not change this because I was not
sure if it was necessary -- and anyway, call-clobbered hard regs should
only be present in combine if the user is using the "register ... asm"
extension. In this case, the user cannot rely much on their semantics
across function calls if they specify call-clobbered registers.
This patch was bootstrapped on powerpc-apple-darwin8.3.0, and H-P
Nilsson tested on cris-axis-elf that it causes no assembly code
generation difference on the testsuite (except for fixing the bug!) and
CSiBE.
Ok for mainline?
2005-01-07 Paolo Bonzini <[EMAIL PROTECTED]>
* combine.c (record_value_for_reg): Invalidate registers
if INSN is null.
(record_dead_and_set_regs_1): Likewise, by passing them to
record_value_for_reg.
(record_dead_and_set_regs): Invalidate stores made by a
call. We do not combine across a call, but we still
relied on equivalences.
Index: combine.c
===
--- combine.c (revision 109374)
+++ combine.c (working copy)
@@ -10823,7 +10826,7 @@ record_value_for_reg (rtx reg, rtx insn,
for (i = regno; i < endregno; i++)
{
reg_stat[i].last_set_label = label_tick;
- if (value && reg_stat[i].last_set_table_tick == label_tick)
+ if (!insn || (value && reg_stat[i].last_set_table_tick == label_tick))
reg_stat[i].last_set_invalid = 1;
else
reg_stat[i].last_set_invalid = 0;
@@ -10872,6 +10874,13 @@ record_dead_and_set_regs_1 (rtx dest, rt
if (GET_CODE (dest) == SUBREG)
dest = SUBREG_REG (dest);
+ if (!record_dead_insn)
+{
+ if (REG_P (dest))
+ record_value_for_reg (dest, NULL_RTX, NULL_RTX);
+ return;
+}
+
if (REG_P (dest))
{
/* If we are setting the whole register, we know its value. Otherwise
@@ -10944,15 +10953,14 @@ record_dead_and_set_regs (rtx insn)
last_call_cuid = mem_last_set = INSN_CUID (insn);
- /* Don't bother recording what this insn does. It might set the
-return value register, but we can't combine into a call
-pattern anyway, so there's no point trying (and it may cause
-a crash, if e.g. we wind up asking for last_set_value of a
-SUBREG of the return value register). */
- return;
+ /* We can't combine into a call pattern. Remember, though, that
+the return value register is set at this CUID. We could
+still replace a register with the return value from the
+wrong subroutine call! */
+ note_stores (PATTERN (insn), record_dead_and_set_regs_1, NULL_RTX);
}
-
- note_stores (PATTERN (insn), record_dead_and_set_regs_1, insn);
+ else
+note_stores (PATTERN (insn), record_dead_and_set_regs_1, insn);
}
/* If a SUBREG has the promoted bit set, it is in fact a property of the
Command line options and pragmas
For a variety of reasons, we would like to be able to specify individual compilation switches *within* individual files. When building we specify a large number of compilation options. But, some files need tweaks of one sort or another to the generic set of options. Most of the tweaks involve turning selected warnings off. But, there are others as well -- turning warnings on, changing optimization levels, turning selected optimizations on or off, and so on. We'd like to be able to specify the tweaks to the individual compilation flags *within* the individual files. One of the advantages we see is that it would simplify some of the makefile logic -- rather than having logic (as we do now) to record the individual compilation switches and comparing that against what the options were the last time the file was successfully compiled, we could just look at the time stamp of the file. [The logic in question compensates for the lack of .KEEP_STATE support in GNU make.] Additionally, solutions such as .KEEP_STATE have potential problems when doing nested distributed builds. To change the individual compilation switches (as opposed to the generic compilation switches), you could then just edit the corresponding *.c file. (If you change a generic compilation switch, then *EVERYTHING* needs to be rebuilt and that is handled separately in our system (by having a depdendency of every *.o file upon the makefile fragment holding such information).) The options to be customized do NOT involve options handled by the gcc driver, only ones handled by the compiler proper (i.e., cc1 and friends). Some questions come to mind: . For starters, does this sound reasonable? That is, if I implemented this, and we contributed it back, would it be considered? Or would it likely be rejected out of hand? . Next, if it would not be rejected on the "we don't want to have such functionality" basis, then the question becomes one of what should the interface look like? Some possibilities include: #pragma GCC command-line -Wprecision-mismatch unilaterally set -Wprecision-mismatch or possibly: #pragma GCC command-line push(-Wprecision-mismatch) set -Wprecision-mismatch, remember previous values and #pragma GCC command-line pop(-Wprecision-mismatch) reset -Wprecision-mismatch to its previous value or maybe: #pragma GCC warnings Wprecision-mismatch (with some similiar syntax for other, non warning, options). Or possibly some other syntax? . Additionally, are there options you would emphatically *NOT* want to ever be allowed to be set this way? I would personally favor not supporting any options that take file names -- from a security perspective. And probably a command line option to enable / disable support for the pragma at all. Comments? David -- David Taylor [EMAIL PROTECTED]
Re: Command line options and pragmas
David Taylor wrote: . For starters, does this sound reasonable? That is, if I implemented this, and we contributed it back, would it be considered? Or would it likely be rejected out of hand? To me, it seems better to handle this in the external environment with appropriate build tools. For example, in the GNAT world, we rely on the project manager to handle this kind of thing, using a project file that specifies appropriate options, on a file by file basis if needed). Putting the options in the source file seems a confusion of concerns, since these are highly non-portable and have nothing to do with the source language.
Memory leak in bt-load.c ?
Hi,
in file 'bt-load.c', in function 'augment_live_range', some memory is
xmalloc'ed. It seems to be possible to never free it, if all the first tests
are true.
Yhe memory is only freed once at the end of the function.
CJ
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+
augment_live_range (bitmap live_range, HARD_REG_SET *btrs_live_in_range,
basic_block head_bb, basic_block new_bb, int full_range)
{
basic_block *worklist, *tos;
tos = worklist = xmalloc (sizeof (basic_block) * (n_basic_blocks + 1));
if (dominated_by_p (CDI_DOMINATORS, new_bb, head_bb))
{
if (new_bb == head_bb)
{
[...]
return;<-- *worklist is not
freed !*
}
*tos++ = new_bb;
}
else
{
}
[...]
free (worklist);
}
Re: Command line options and pragmas
On Mon, Jan 09, 2006 at 01:46:21PM -0500, David Taylor wrote: > For a variety of reasons, we would like to be able to specify > individual compilation switches *within* individual files. You don't need a gcc modification to do that; you can arrange to get the compiler flags from a comment in the file. A bit of scripting, and your build system can find these comments, and either use a default flag set or generate an error if the magic comment is not found.
Re: Command line options and pragmas
> . Next, if it would not be rejected on the "we don't want to have such > functionality" basis, then the question becomes one of what should the > interface look like? Some possibilities include: > > #pragma GCC command-line -Wprecision-mismatch > > unilaterally set -Wprecision-mismatch I was planning on proposing something like: #pragma GCC diagnostic [warning|error|ignore] -Wprecision-mismatch The diagnostic machinery already has support for some of this, I had hoped to find time to make it fine-grained, allowing you to override the KIND of each warning, and thus override -Werror on a per-warning-type basis. I had planned on forcing the user to place these pragmas before the first function definition, otherwise it becomes difficult to track when various warnings are in force.
RFC: Why don't we stop the optimizer pipeline when errorcount > 0?
I hit an ICE inside an optimizer pass because the code had a glaring syntax error that we diagnosed correctly, but since we kept going, the transformation didn't find the CFG in the assumed state, causing the ICE. Is there any reason in particular we don't just make the gate functions return false when errorcount > 0?
Re: Command line options and pragmas
DJ Delorie wrote: I had planned on forcing the user to place these pragmas before the first function definition, otherwise it becomes difficult to track when various warnings are in force. For warnings, it is definitely useful to be able to use them on a fine grained basis in the source. One way to get the source placement issue handled accurately is to have the pragma make an entry in a table of source positions, then before issuing a warning you check this table with a search to see if there is an active pragma that suppresses warnings. That's the way we do things in GNAT for pragma Warnings On|Off.
Re: Command line options and pragmas
DJ Delorie <[EMAIL PROTECTED]> writes: | > . Next, if it would not be rejected on the "we don't want to have such | > functionality" basis, then the question becomes one of what should the | > interface look like? Some possibilities include: | > | > #pragma GCC command-line -Wprecision-mismatch | > | > unilaterally set -Wprecision-mismatch | | I was planning on proposing something like: | | #pragma GCC diagnostic [warning|error|ignore] -Wprecision-mismatch | | The diagnostic machinery already has support for some of this, I had | hoped to find time to make it fine-grained, allowing you to override | the KIND of each warning, and thus override -Werror on a | per-warning-type basis. GCC's current architecture, heavily relying on global states, is not yet prepared to consistently support such feature -- even though the sole diagnostic machinery might be somewhat prepared for that. I think it would take more auditing of the -whole- compiler bundle than just the small diagnostic part of it to arrive to a decent state. That said, I'm very reluctant to that approach, for reasons mostly expressed by Robert Dewar. -- Gaby
Re: RFC: Why don't we stop the optimizer pipeline when errorcount > 0?
>
>
> I hit an ICE inside an optimizer pass because the code had a glaring syntax
> error that we diagnosed correctly, but since we kept going, the
> transformation didn't find the CFG in the assumed state, causing the ICE.
We do stop the optimization passes from running in general.
/* Gate: execute, or not, all of the non-trivial optimizations. */
static bool
gate_all_optimizations (void)
{
return (optimize >= 1
/* Don't bother doing anything if the program has errors. */
&& !(errorcount || sorrycount));
}
tatic bool
gate_rest_of_compilation (void)
{
/* Early return if there were errors. We can run afoul of our
consistency checks, and there's not really much point in fixing them. */
return !(rtl_dump_and_exit || flag_syntax_only || errorcount || sorrycount);
}
> Is there any reason in particular we don't just make the gate functions
> return false when errorcount > 0?
the only passes which do run are cfg creation, expand, and maybe a couple other
simple ones.
-- Pinski
Re: RFC: Why don't we stop the optimizer pipeline when errorcount > 0?
Diego Novillo <[EMAIL PROTECTED]> writes: | I hit an ICE inside an optimizer pass because the code had a glaring syntax | error that we diagnosed correctly, but since we kept going, the | transformation didn't find the CFG in the assumed state, causing the ICE. | | Is there any reason in particular we don't just make the gate functions | return false when errorcount > 0? none I can see. We should not try to get into the gimplifier (as the C++ front-end does) when we know the translation unit is doomed to fail. This is an annoying issue, especially in the C++ front-end (see cp_finish_file) where template instantiations are stubbornly tried even when we know we won't get a good translation unit out ot it. -- Gabriel Dos Reis [EMAIL PROTECTED] Texas A&M University -- Department of Computer Science 301, Bright Building -- College Station, TX 77843-3112
Re: RFC: Why don't we stop the optimizer pipeline when errorcount > 0?
On Monday 09 January 2006 14:42, Andrew Pinski wrote: > the only passes which do run are cfg creation, expand, and maybe a > couple other simple ones. > I know that. It's expand the one bothering me. Are we issuing errors that late in the pipeline?
Re: RFC: Why don't we stop the optimizer pipeline when errorcount > 0?
On Jan 9, 2006, at 2:46 PM, Diego Novillo wrote: On Monday 09 January 2006 14:42, Andrew Pinski wrote: the only passes which do run are cfg creation, expand, and maybe a couple other simple ones. I know that. It's expand the one bothering me. Are we issuing errors that late in the pipeline? yes but we should not be but that is a different story and just because this was how GCC worked since 1987. -- Pinski
Re: Command line options and pragmas
Robert Dewar <[EMAIL PROTECTED]> writes: | DJ Delorie wrote: | | >I had planned on forcing the user to place these pragmas before the | >first function definition, otherwise it becomes difficult to track | >when various warnings are in force. | > | For warnings, it is definitely useful to be able to use them on a fine | grained basis in the | source. One way to get the source placement issue handled accurately | is to have the | pragma make an entry in a table of source positions, then before | issuing a warning | you check this table with a search to see if there is an active pragma | that suppresses | warnings. That's the way we do things in GNAT for pragma Warnings On|Off. Most of the time I've seen request for the #pragma (#dogma?) stuff, it was mostly for controlling diagnostic in a limited region or program text. GCC in its current state is not prepared to handle that correctly. (That said, I still remain unconvinced. Many of the requests come partly from defects in the diagnostic logic, and partly from program organization logic.) -- Gaby
PATCH: m68k PIC touchup
Hello!
patch for m68k to handle PIC as the other archs
Please apply, thx, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
--- gcc-4.0.2/gcc/config/m68k/linux.h.mps 2006-01-08 23:02:06 +0100
+++ gcc-4.0.2/gcc/config/m68k/linux.h 2006-01-08 23:03:02 +0100
@@ -85,6 +85,11 @@
LINUX_TARGET_OS_CPP_BUILTINS(); \
builtin_define_std ("mc68000"); \
builtin_define_std ("mc68020"); \
+ if (flag_pic) \
+ { \
+ builtin_define ("__PIC__"); \
+ builtin_define ("__pic__"); \
+ } \
} \
while (0)
@@ -98,10 +103,10 @@
#undef CPP_SPEC
#if TARGET_DEFAULT & MASK_68881
#define CPP_SPEC \
- "%{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic__} %{!msoft-float:-D__HAVE_68881__}
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
+ "%{!msoft-float:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE}
%{pthread:-D_REENTRANT}"
#else
#define CPP_SPEC \
- "%{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic__} %{m68881:-D__HAVE_68881__}
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
+ "%{m68881:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
#endif
/* We override the ASM_SPEC from svr4.h because we must pass -m68040 down
-symbolic unsupported
Hello!
Checking the linux configs for different archs only arm has
%{symbolic:-Bsymbolic} for linking.
Is arm out of date, or should the others been updated?
Thanks, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: Command line options and pragmas
> Date: Mon, 9 Jan 2006 11:13:22 -0800 > From: Joe Buck <[EMAIL PROTECTED]> > > On Mon, Jan 09, 2006 at 01:46:21PM -0500, David Taylor wrote: > > For a variety of reasons, we would like to be able to specify > > individual compilation switches *within* individual files. > > You don't need a gcc modification to do that; you can arrange to get > the compiler flags from a comment in the file. A bit of scripting, > and your build system can find these comments, and either use a default > flag set or generate an error if the magic comment is not found. We're considering that option. One of the considerations is that some files are compiled 20+ times (e.g., if it's present in a lot of variations of the product and contains conditional compilation), and the individual compilation options sometimes vary depending upon which variation the file is being compiled for -- so, we'd like to be able to use CPP. Yes, we can run a sed or awk or perl script over the file, feed the output to cpp, and then modify the compiler invocation line as appropriate. It's something we have considered doing. But, less than 10% of the files have individual compilation options -- over 90% of the files use the generic set without any additions (and the percentage using the generic set is likely to increase over time). We would end up invoking the script more than a dozen times for files without individual compilation switches for every time we invoked it for a file with individual compilation switches. So, I'd prefer to avoid the overhead of the script if I could. David -- David Taylor [EMAIL PROTECTED]
Re: Command line options and pragmas
> GCC's current architecture, heavily relying on global states, is not > yet prepared to consistently support such feature -- even though the > sole diagnostic machinery might be somewhat prepared for that. Yes, we've covered this a couple of times before. There's a limited set of things we can get away with, and that limited set is useful to real users.
Re: Command line options and pragmas
> Date: Mon, 9 Jan 2006 14:30:03 -0500 > From: DJ Delorie <[EMAIL PROTECTED]> > > . Next, if it would not be rejected on the "we don't want to have such > > functionality" basis, then the question becomes one of what should the > > interface look like? Some possibilities include: > > > > #pragma GCC command-line -Wprecision-mismatch > > > > unilaterally set -Wprecision-mismatch > > I was planning on proposing something like: > > #pragma GCC diagnostic [warning|error|ignore] -Wprecision-mismatch > > The diagnostic machinery already has support for some of this, I had > hoped to find time to make it fine-grained, allowing you to override > the KIND of each warning, and thus override -Werror on a > per-warning-type basis. > > I had planned on forcing the user to place these pragmas before the > first function definition, otherwise it becomes difficult to track > when various warnings are in force. The *BULK* of our files with individual compilation switches only have switches for warnings or for profiling. I'd be leary of any attempt (e.g. changing code profiling options) to change code generation in the middle of a function. Our intended use (if we implement it) would be to use the pragma only prior to the start of code -- only comments, whitespace, and preprocessor directives permitted prior to the pragma. So, I'd be comfortable with such a restriction long term for code generation and related options and short term for warnings. Longer term, I'd like to be able to control warnings on a line by line basis. The ability to say "I've examined this expression / line / block / whatever of code and I'm happy with it with-regard-to warning XYZ, please be quiet" would be very valuable. Based on Gaby's comments, it sounds like fine-grained control would be a much bigger project. David -- David Taylor [EMAIL PROTECTED]
Re: Command line options and pragmas
> Longer term, I'd like to be able to control warnings on a line by > line basis. The ability to say "I've examined this expression / > line / block / whatever of code and I'm happy with it with-regard-to > warning XYZ, please be quiet" would be very valuable. > > Based on Gaby's comments, it sounds like fine-grained control would > be a much bigger project. Right, what you'd basically have to do is attach the warning control state (or state diffs) to the tree objects, and make sure they propogate all over the place, and figure out which one(s) to use when you need to issue a diagnostic. Like, if you add a signed and unsigned, and they have conflicting signedness warning settings, what do you do? I had thought of keeping a table of pragma-settings-by-line-number and, for diagnostics with line number information, doing the lookup to see what was in effect at that line. But the complications are worse than the benefits.
Re: Command line options and pragmas
DJ Delorie wrote: I had thought of keeping a table of pragma-settings-by-line-number and, for diagnostics with line number information, doing the lookup to see what was in effect at that line. But the complications are worse than the benefits. Can you explain the complications you see. This seems like the way to go to me, because it guarantees that the effect is precisely what the programmer has asked for.
Re: Command line options and pragmas
> >and, for diagnostics with line number information, doing the lookup > >to see what was in effect at that line. But the complications are > >worse than the benefits. > > Can you explain the complications you see. This seems like the way > to go to me, because it guarantees that the effect is precisely what > the programmer has asked for. For example, if you have two warnings in one statement, you can't control one but not the other if they use the same -W option. A minor point, but if we used line numbers we'd be really close to "this should work" that people would claim it's a bug when it doesn't. Plus, we'd need to keep track of a linked list of flag state structures. Some folks made convincing arguments that it wouldn't always work the way the user wanted, too. We don't always have a line number, for example. Which warning state takes effect? When we have a "first used here" type diagnostic, which warning state is used? But I'm willing to implement something if people think it's the best thing to do.
