GCC calling GNU assembler
Hello all,
Could anybody please answer me on following question:
where is GCC callin assembler where it recognizes assembler code in C
function? For example, let's say that there is this line in C code:
asm("mov r1,r0");
So, the parser parses this as an assembler string. But where, in GCC
code, is assembler called to process this string?
Or maybe the question is where this "mov r1, r0" string is passed to
assembler. Anyway, I think you got my question.
Thanks in advance!
Best regards,
Nikola
Re: Support for export keyword to use with C++ templates ?
On 02/02/2010 05:04 AM, Michael Witten wrote: On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini wrote: it's extremely unlikely that the C++ front-end maintainers could even consider reviewing patches from a novice for such an hard to implement feature. That says more about the tangled mess that is gcc then about any particular programmer's ability. That says more about how deeply you have looked at the front-end's sources than about anything else. ^ Paolo
RE: GCC calling GNU assembler
GCC just literally emits the string in your asm expression together with other
assembly code generated by compiler. Only in next step assembler is invoked by
GCC driver.
Typically, hard register number is not used so that GCC can do register
allocation
for inline assembly.
Bingfeng
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Nikola Ikonic
> Sent: 03 February 2010 09:27
> To: gcc@gcc.gnu.org
> Subject: GCC calling GNU assembler
>
> Hello all,
>
> Could anybody please answer me on following question:
>
> where is GCC callin assembler where it recognizes assembler code in C
> function? For example, let's say that there is this line in C code:
>
> asm("mov r1,r0");
>
> So, the parser parses this as an assembler string. But where, in GCC
> code, is assembler called to process this string?
> Or maybe the question is where this "mov r1, r0" string is passed to
> assembler. Anyway, I think you got my question.
>
> Thanks in advance!
>
> Best regards,
>Nikola
>
>
insn length attribute and code size optimization
According to the internal manual, insn length attribute can be used to to calculate the length of emitted code chunks when verifying branch distances. Can it be used in code size optimization? I may change TARGET_RTX_COSTS in my gcc port and return costs regarding the ins lengths. I can see code snippets for this purpose in i386/i386.c, however, the insn sizes are hard coded in array size_cost. Are there any other places where the insn length impacts insn selection? -- -Qifei Fan
Re: insn length attribute and code size optimization
fanqifei writes: > According to the internal manual, insn length attribute can be used to > to calculate the length of emitted code chunks when verifying branch > distances. > Can it be used in code size optimization? I suppose it could, but it isn't. Instead of asking the backend for the length of instructions, the compiler asks the backend for the cost of instructions. The backend is free to determine that cost however it likes. When using -Os, using the size of the instruction is a good measure of cost. > I may change TARGET_RTX_COSTS in my gcc port and return costs > regarding the ins lengths. I can see code snippets for this purpose > in i386/i386.c, however, the insn sizes are hard coded in array > size_cost. > Are there any other places where the insn length impacts insn selection? In one sense, insn length never currently affects insn selection. In another sense, the costs hook is the right place for it to affect insn selection, when using -Os. Ian
Parser extension points for plug-ins
Hello, The current set of plug-in events does not appear to include extension points at the parser level. I think it may be useful to allow plug-ins to process, e.g., #pragmas. That would allow directives à la OpenMP to be added/extended, which is an increasingly popular way to augment C and other languages. Has it been discussed before? What do people think? Thanks, Ludo’.
Re: insn length attribute and code size optimization
On Wed, Feb 03, 2010 at 06:23:19AM -0800, Ian Lance Taylor wrote: > fanqifei writes: > > > According to the internal manual, insn length attribute can be used to > > to calculate the length of emitted code chunks when verifying branch > > distances. > > Can it be used in code size optimization? > > I suppose it could, but it isn't. Instead of asking the backend for > the length of instructions, the compiler asks the backend for the cost > of instructions. The backend is free to determine that cost however > it likes. When using -Os, using the size of the instruction is a good > measure of cost. It seems to me that there's a hard ordering problem here: we can't determine insn lengths, using the current framework, until very late. We need at least (A) whole instructions, not just RTL expressions; (B) register allocation to select alternatives; (C) branch shortening to determine branch alternatives. I'm curious if anyone thinks there's a generic solution to this (that doesn't involve a complete instruction selection rewrite :-). -- Daniel Jacobowitz CodeSourcery
Re: Parser extension points for plug-ins
l...@gnu.org (Ludovic Courtès) writes: > I think it may be useful to allow plug-ins to process, e.g., #pragmas. Of course soon after posting I noticed ‘PLUGIN_PRAGMAS’... Sorry for the noise, Ludo’.
Re: [trans-mem] ipa tm pass and dominator walks
> I don't think that's true at all. You showed that the walking was
> incorrect; I don't see you you can now argue that it is correct,
> regardless of inlining and jump threading.
>
> All one needs to create the cfg that exhibits the problem is
> multiple exits from the transaction. It's not terribly hard to
> create such a cfg directly in the source...
Can't believe I forgot about explicit gotos and the like.
Below is a patch fixing the transformation of calls during the TM ipa
pass. It walks the CFG instead of the dominator tree.
OK for branch?
* trans-mem.c (ipa_tm_scan_irr_block): Iterate CFG.
(ipa_tm_transform_calls_1): Rename from ipa_tm_transform_calls.
Only process one block.
(ipa_tm_transform_calls): Iterate through CFG and call helper
function.
Index: testsuite/c-c++-common/tm/ipa-1.c
===
--- testsuite/c-c++-common/tm/ipa-1.c (revision 0)
+++ testsuite/c-c++-common/tm/ipa-1.c (revision 0)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm -O -fdump-ipa-tmipa" } */
+
+int val, george;
+
+extern void func();
+
+int set_remove(void)
+{
+ int result = 8;
+ __transaction {
+result = george;
+if (val)
+ goto out;
+ }
+ out:
+ func();
+ return result;
+}
+
+
+/* { dg-final { scan-ipa-dump-not "getTMCloneOrIrrevocable" "tmipa" } } */
+/* { dg-final { cleanup-ipa-dump "tmipa" } } */
Index: trans-mem.c
===
--- trans-mem.c (revision 156432)
+++ trans-mem.c (working copy)
@@ -3346,15 +3346,18 @@ ipa_tm_scan_irr_block (basic_block bb)
return false;
}
-/* For each of the blocks seeded witin PQUEUE, walk its dominator tree
- looking for new irrevocable blocks, marking them in NEW_IRR. Don't
- bother scanning past OLD_IRR or EXIT_BLOCKS. */
+/* For each of the blocks seeded witin PQUEUE, walk the CFG looking
+ for new irrevocable blocks, marking them in NEW_IRR. Don't bother
+ scanning past OLD_IRR or EXIT_BLOCKS. */
static bool
ipa_tm_scan_irr_blocks (VEC (basic_block, heap) **pqueue, bitmap new_irr,
bitmap old_irr, bitmap exit_blocks)
{
bool any_new_irr = false;
+ edge e;
+ edge_iterator ei;
+ bitmap visited_blocks = BITMAP_ALLOC (NULL);
do
{
@@ -3370,12 +3373,19 @@ ipa_tm_scan_irr_blocks (VEC (basic_block
any_new_irr = true;
}
else if (exit_blocks == NULL || !bitmap_bit_p (exit_blocks, bb->index))
- for (bb = first_dom_son (CDI_DOMINATORS, bb); bb;
-bb = next_dom_son (CDI_DOMINATORS, bb))
- VEC_safe_push (basic_block, heap, *pqueue, bb);
+ {
+ FOR_EACH_EDGE (e, ei, bb->succs)
+ if (!bitmap_bit_p (visited_blocks, e->dest->index))
+ {
+ bitmap_set_bit (visited_blocks, e->dest->index);
+ VEC_safe_push (basic_block, heap, *pqueue, e->dest);
+ }
+ }
}
while (!VEC_empty (basic_block, *pqueue));
+ BITMAP_FREE (visited_blocks);
+
return any_new_irr;
}
@@ -3857,13 +3867,13 @@ ipa_tm_insert_gettmclone_call (struct cg
return safe;
}
-/* Walk the dominator tree for REGION, beginning at BB. Install calls to
- tm_irrevocable when IRR_BLOCKS are reached, redirect other calls to the
- generated transactional clone. */
+/* Helper function for ipa_tm_transform_calls. For a given BB,
+ install calls to tm_irrevocable when IRR_BLOCKS are reached,
+ redirect other calls to the generated transactional clone. */
static bool
-ipa_tm_transform_calls (struct cgraph_node *node, struct tm_region *region,
- basic_block bb, bitmap irr_blocks)
+ipa_tm_transform_calls_1 (struct cgraph_node *node, struct tm_region *region,
+ basic_block bb, bitmap irr_blocks)
{
gimple_stmt_iterator gsi;
bool need_ssa_rename = false;
@@ -3945,13 +3955,43 @@ ipa_tm_transform_calls (struct cgraph_no
gimple_call_set_fndecl (stmt, fndecl);
}
- if (!region || !bitmap_bit_p (region->exit_blocks, bb->index))
-for (bb = first_dom_son (CDI_DOMINATORS, bb); bb;
-bb = next_dom_son (CDI_DOMINATORS, bb))
- {
- need_ssa_rename |=
- ipa_tm_transform_calls (node, region, bb, irr_blocks);
- }
+ return need_ssa_rename;
+}
+
+/* Walk the CFG for REGION, beginning at BB. Install calls to
+ tm_irrevocable when IRR_BLOCKS are reached, redirect other calls to
+ the generated transactional clone. */
+
+static bool
+ipa_tm_transform_calls (struct cgraph_node *node, struct tm_region *region,
+ basic_block bb, bitmap irr_blocks)
+{
+ bool need_ssa_rename = false;
+ edge e;
+ edge_iterator ei;
+ VEC(basic_block, heap) *queue = NULL;
+ bitmap visited_blocks = BITMAP_ALLOC (NULL);
+
+ VEC_safe_push (basic_block, heap, queue, bb);
+ do
+{
+ bb = VEC_pop (basic_block, queue);
+
+ need_ssa_rename
Re: [trans-mem] ipa tm pass and dominator walks
On 02/03/2010 10:26 AM, Aldy Hernandez wrote: I don't think that's true at all. You showed that the walking was incorrect; I don't see you you can now argue that it is correct, regardless of inlining and jump threading. All one needs to create the cfg that exhibits the problem is multiple exits from the transaction. It's not terribly hard to create such a cfg directly in the source... Can't believe I forgot about explicit gotos and the like. Below is a patch fixing the transformation of calls during the TM ipa pass. It walks the CFG instead of the dominator tree. OK for branch? * trans-mem.c (ipa_tm_scan_irr_block): Iterate CFG. This part is ok. (ipa_tm_transform_calls_1): Rename from ipa_tm_transform_calls. Only process one block. (ipa_tm_transform_calls): Iterate through CFG and call helper function. This part isn't. As we discussed on IRC, you're missing a check for irr_blocks and stopping the iteration then. r~
Re: [trans-mem] ipa tm pass and dominator walks
> This part is ok.
Committed.
> > (ipa_tm_transform_calls_1): Rename from ipa_tm_transform_calls.
> > Only process one block.
> > (ipa_tm_transform_calls): Iterate through CFG and call helper
> > function.
>
> This part isn't. As we discussed on IRC, you're missing a check
> for irr_blocks and stopping the iteration then.
Fixed below, approved on IRC, and committed.
Thanks for reviewing.
* trans-mem.c (ipa_tm_scan_irr_block): Iterate CFG.
(ipa_tm_transform_calls_1): Rename from ipa_tm_transform_calls.
Only process one block.
(ipa_tm_transform_calls): Iterate through CFG and call helper
function.
Index: testsuite/c-c++-common/tm/ipa-1.c
===
--- testsuite/c-c++-common/tm/ipa-1.c (revision 0)
+++ testsuite/c-c++-common/tm/ipa-1.c (revision 0)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm -O -fdump-ipa-tmipa" } */
+
+int val, george;
+
+extern void func();
+
+int set_remove(void)
+{
+ int result = 8;
+ __transaction {
+result = george;
+if (val)
+ goto out;
+ }
+ out:
+ func();
+ return result;
+}
+
+
+/* { dg-final { scan-ipa-dump-not "getTMCloneOrIrrevocable" "tmipa" } } */
+/* { dg-final { cleanup-ipa-dump "tmipa" } } */
Index: trans-mem.c
===
--- trans-mem.c (revision 156432)
+++ trans-mem.c (working copy)
@@ -3346,15 +3346,18 @@ ipa_tm_scan_irr_block (basic_block bb)
return false;
}
-/* For each of the blocks seeded witin PQUEUE, walk its dominator tree
- looking for new irrevocable blocks, marking them in NEW_IRR. Don't
- bother scanning past OLD_IRR or EXIT_BLOCKS. */
+/* For each of the blocks seeded witin PQUEUE, walk the CFG looking
+ for new irrevocable blocks, marking them in NEW_IRR. Don't bother
+ scanning past OLD_IRR or EXIT_BLOCKS. */
static bool
ipa_tm_scan_irr_blocks (VEC (basic_block, heap) **pqueue, bitmap new_irr,
bitmap old_irr, bitmap exit_blocks)
{
bool any_new_irr = false;
+ edge e;
+ edge_iterator ei;
+ bitmap visited_blocks = BITMAP_ALLOC (NULL);
do
{
@@ -3370,12 +3373,19 @@ ipa_tm_scan_irr_blocks (VEC (basic_block
any_new_irr = true;
}
else if (exit_blocks == NULL || !bitmap_bit_p (exit_blocks, bb->index))
- for (bb = first_dom_son (CDI_DOMINATORS, bb); bb;
-bb = next_dom_son (CDI_DOMINATORS, bb))
- VEC_safe_push (basic_block, heap, *pqueue, bb);
+ {
+ FOR_EACH_EDGE (e, ei, bb->succs)
+ if (!bitmap_bit_p (visited_blocks, e->dest->index))
+ {
+ bitmap_set_bit (visited_blocks, e->dest->index);
+ VEC_safe_push (basic_block, heap, *pqueue, e->dest);
+ }
+ }
}
while (!VEC_empty (basic_block, *pqueue));
+ BITMAP_FREE (visited_blocks);
+
return any_new_irr;
}
@@ -3857,13 +3867,13 @@ ipa_tm_insert_gettmclone_call (struct cg
return safe;
}
-/* Walk the dominator tree for REGION, beginning at BB. Install calls to
- tm_irrevocable when IRR_BLOCKS are reached, redirect other calls to the
- generated transactional clone. */
+/* Helper function for ipa_tm_transform_calls. For a given BB,
+ install calls to tm_irrevocable when IRR_BLOCKS are reached,
+ redirect other calls to the generated transactional clone. */
static bool
-ipa_tm_transform_calls (struct cgraph_node *node, struct tm_region *region,
- basic_block bb, bitmap irr_blocks)
+ipa_tm_transform_calls_1 (struct cgraph_node *node, struct tm_region *region,
+ basic_block bb, bitmap irr_blocks)
{
gimple_stmt_iterator gsi;
bool need_ssa_rename = false;
@@ -3945,13 +3955,48 @@ ipa_tm_transform_calls (struct cgraph_no
gimple_call_set_fndecl (stmt, fndecl);
}
- if (!region || !bitmap_bit_p (region->exit_blocks, bb->index))
-for (bb = first_dom_son (CDI_DOMINATORS, bb); bb;
-bb = next_dom_son (CDI_DOMINATORS, bb))
- {
- need_ssa_rename |=
- ipa_tm_transform_calls (node, region, bb, irr_blocks);
- }
+ return need_ssa_rename;
+}
+
+/* Walk the CFG for REGION, beginning at BB. Install calls to
+ tm_irrevocable when IRR_BLOCKS are reached, redirect other calls to
+ the generated transactional clone. */
+
+static bool
+ipa_tm_transform_calls (struct cgraph_node *node, struct tm_region *region,
+ basic_block bb, bitmap irr_blocks)
+{
+ bool need_ssa_rename = false;
+ edge e;
+ edge_iterator ei;
+ VEC(basic_block, heap) *queue = NULL;
+ bitmap visited_blocks = BITMAP_ALLOC (NULL);
+
+ VEC_safe_push (basic_block, heap, queue, bb);
+ do
+{
+ bb = VEC_pop (basic_block, queue);
+
+ need_ssa_rename |=
+ ipa_tm_transform_calls_1 (node, region, bb, irr_blocks);
+
+ if (irr_blocks && bitmap_bit_p (irr_blocks, bb->index))
+ contin
gen_lowpart called where 'truncate' needed?
I am porting gcc-4.4.3 to TILE-Gx, a 64-bit VLIW RISC. It's gone pretty well so far; most tests work, Linux builds, etc. Thanks for writing such good documentation. This chip, like MIPS64, maintains the invariant that SImode values in DImode registers are always sign-extended. So I have implemented PROMOTE_MODE, TARGET_MODE_REP_EXTENDED and LOAD_EXTEND_OP accordingly, and made sure my .md file always preserves this invariant. This almost works, but testing has shown two cases that break this invariant, and I want to know if it's my fault. The problem is that 'widen_bswap' and 'expand_divmod' each produce a DImode value whose high 32 bits are known to be zero, and then simply 'gen_lowpart' the DImode value to convert it to SImode. This produces a SUBREG, not a 'truncate' rtx, so I end up with a register that is incorrectly zero-extended. Am I doing something wrong, or are these functions incorrect? As far as I can tell, gen_lowpart is not expected to force a sign-extension operation. But SUBREG rules are a bit subtle so I could be missing something. Everything works fine if I modify 'widen_bswap' and 'expand_divmod' to do this instead of 'return gen_lowpart (mode, x)': return simplify_gen_unary (TRUNCATE, mode, x, GET_MODE (x)); Since the high bits are already zero, that would be less efficient on most platforms, so guarding it with something like this would probably be smarter: if (targetm.mode_rep_extended (mode, GET_MODE(x)) == SIGN_EXTEND) return simplify_gen_unary (TRUNCATE, mode, x, GET_MODE (x)); I'm happy to believe I'm doing something wrong in my back end, but I'm not sure what that would be. I could also believe these are obscure edge cases no one cared about before. Any tips would be appreciated. Thanks! -Mat
Re: Question about IRA (setup_allocno_priorities)
On 01/28/10 12:30, Vladimir Makarov wrote: It is originated from the old register allocator. I don't think that just nrefs will work well because it is already reflected in the cost. IMHO, log2 (nrefs) is here for taking code size into account which affects code locality and as a consequence its execution performance. But this is just speculations. Only benchmarking a lot of credible tests will show the truth because all widely used RA algorithms are heuristic ones. I am sure that a lot of people (including me about 7 years ago) checked log2 (nrefs) and nrefs and other priority definitions. I wouldn't be surprised if the sources have had that form for more than a decade... The "why" is probably lost forever. One possibility if nrefs is generally worse than log2 (nrefs) is to use a hybrid scheme. For a small nrefs, use it directly for a large nrefs, use log2 (nrefs). I certainly agree that benchmarking would be absolutely necessary before any such change would be made. jeff
Re: Long paths with ../../../../ throughout
Hello Ian
Thank you for your reply.
Ian Lance Taylor wrote:
Jon writes:
Is there a way to get collect2 to save the temporary .c file it
generates to have a look at it? I believe it may be the __main()
function, with the -debug option it gives the attached
gplusplus_collect2_log.txt, looking at the [/tmp/ccyBAI9V.c] file
though it is empty, any ideas?
Using -debug will direct collect2 to save the temporary .c file when
it creates one. However, in ordinary use on GNU/Linux, collect2 will
never generate a temporary .c file.
Is there any information about how GCC start up constructors for C/C++
are generated and called before main you could point me to please. I'd
like to understand how it works.
[.]
Take a look at the config.log file to see the test that failed.
Thanks, I had ibgmp3-dev, libmpfr-dev, libmpc-dev missing. The former
is 0.7-1 in current Ubuntu, so I took from April's pre-release package
(and deps). Not sure if this has been discussed, but my feedback would
be for gcc build not to depend on packages until they are in the
mainstream distros.
I've attached collect2 patch. Let me know what you think of it.
If happy with the patch. I'll prepare another which changes all the
int 0/1 flags to be bool and true/false.
Please include my address in any replies.
Best regards, Jon
2010-02-03 Jon Grant
* collect2.c: Handle --version as well as -v.
Likewise handle --help as well as -h.
Display Usage when --help given on command line.
vflag, debug (and additional helpflag) use bool instead of int.
Index: collect2.c
===
--- collect2.c (revision 156482)
+++ collect2.c (working copy)
@@ -174,7 +174,7 @@
int number;
};
-int vflag;/* true if -v */
+bool vflag;/* true if -v or --version */
static int rflag; /* true if -r */
static int strip_flag; /* true if -s */
static const char *demangle_flag;
@@ -193,7 +193,8 @@
/* Current LTO mode. */
static enum lto_mode_d lto_mode = LTO_MODE_NONE;
-int debug;/* true if -debug */
+bool debug;/* true if -debug */
+bool helpflag; /* true if --help */
static int shared_obj; /* true if -shared */
@@ -1228,7 +1229,7 @@
for (i = 1; argv[i] != NULL; i ++)
{
if (! strcmp (argv[i], "-debug"))
- debug = 1;
+ debug = true;
else if (! strcmp (argv[i], "-flto") && ! use_plugin)
{
use_verbose = true;
@@ -1458,7 +1459,7 @@
if (use_verbose && *q == '-' && q[1] == 'v' && q[2] == 0)
{
/* Turn on trace in collect2 if needed. */
- vflag = 1;
+ vflag = true;
}
}
obstack_free (&temporary_obstack, temporary_firstobj);
@@ -1588,7 +1589,7 @@
case 'v':
if (arg[2] == '\0')
- vflag = 1;
+ vflag = true;
break;
case '-':
@@ -1619,6 +1620,10 @@
}
else if (strncmp (arg, "--sysroot=", 10) == 0)
target_system_root = arg + 10;
+ else if (strncmp (arg, "--version", 9) == 0)
+ vflag = true;
+ else if (strncmp (arg, "--help", 9) == 0)
+ helpflag = true;
break;
}
}
@@ -1720,6 +1725,17 @@
fprintf (stderr, "\n");
}
+ if (helpflag)
+{
+ fprintf (stderr, "collect2 is a GCC utility to arrange and call ");
+ fprintf (stderr, "various initialization functions at start time.\n");
+ fprintf (stderr, "Wrapping the linker and generating an additional ");
+ fprintf (stderr, "temporary `.c' of constructor fnctions if needed.\n");
+ fprintf (stderr, "Usage: collect2 [options]\n");
+ fprintf (stderr, " -v, --version Display version\n");
+ fprintf (stderr, " -debug Enable debug output. `gcc -Wl,-debug'\n");
+}
+
if (debug)
{
const char *ptr;
Re: Long paths with ../../../../ throughout
Updated patch attached which includes collect2.h change to bool.
Please include my address in any replies.
Best regards, Jon
Index: collect2.c
===
--- collect2.c (revision 156482)
+++ collect2.c (working copy)
@@ -174,7 +174,7 @@
int number;
};
-int vflag;/* true if -v */
+bool vflag;/* true if -v or --version */
static int rflag; /* true if -r */
static int strip_flag; /* true if -s */
static const char *demangle_flag;
@@ -193,7 +193,8 @@
/* Current LTO mode. */
static enum lto_mode_d lto_mode = LTO_MODE_NONE;
-int debug;/* true if -debug */
+bool debug;/* true if -debug */
+bool helpflag; /* true if --help */
static int shared_obj; /* true if -shared */
@@ -1228,7 +1229,7 @@
for (i = 1; argv[i] != NULL; i ++)
{
if (! strcmp (argv[i], "-debug"))
- debug = 1;
+ debug = true;
else if (! strcmp (argv[i], "-flto") && ! use_plugin)
{
use_verbose = true;
@@ -1458,7 +1459,7 @@
if (use_verbose && *q == '-' && q[1] == 'v' && q[2] == 0)
{
/* Turn on trace in collect2 if needed. */
- vflag = 1;
+ vflag = true;
}
}
obstack_free (&temporary_obstack, temporary_firstobj);
@@ -1588,7 +1589,7 @@
case 'v':
if (arg[2] == '\0')
- vflag = 1;
+ vflag = true;
break;
case '-':
@@ -1619,6 +1620,10 @@
}
else if (strncmp (arg, "--sysroot=", 10) == 0)
target_system_root = arg + 10;
+ else if (strncmp (arg, "--version", 9) == 0)
+ vflag = true;
+ else if (strncmp (arg, "--help", 9) == 0)
+ helpflag = true;
break;
}
}
@@ -1720,6 +1725,17 @@
fprintf (stderr, "\n");
}
+ if (helpflag)
+{
+ fprintf (stderr, "collect2 is a GCC utility to arrange and call ");
+ fprintf (stderr, "various initialization functions at start time.\n");
+ fprintf (stderr, "Wrapping the linker and generating an additional ");
+ fprintf (stderr, "temporary `.c' of constructor fnctions if needed.\n");
+ fprintf (stderr, "Usage: collect2 [options]\n");
+ fprintf (stderr, " -v, --version Display version\n");
+ fprintf (stderr, " -debug Enable debug output. `gcc -Wl,-debug'\n");
+}
+
if (debug)
{
const char *ptr;
Index: collect2.h
===
--- collect2.h (revision 156482)
+++ collect2.h (working copy)
@@ -38,7 +38,7 @@
extern const char *c_file_name;
extern struct obstack temporary_obstack;
extern char *temporary_firstobj;
-extern int vflag, debug;
+extern bool vflag, debug;
extern void error (const char *, ...) ATTRIBUTE_PRINTF_1;
extern void notice (const char *, ...) ATTRIBUTE_PRINTF_1;
Re: Support for export keyword to use with C++ templates ?
On Wed, Feb 3, 2010 at 4:19 AM, Richard Kenner wrote: >> I see that what I need is an assignment for all future changes. If my >> employer is not involved with any contributions of mine, the employer >> disclaimer is not needed, right ? > > It's safest to have it. The best way to prove that your employer is > not involved with any contributions of yours is with such a disclaimer. The term "employer" is inappropriate for legal purposes in my case as I am a self-employed individual or a freelancer. I do not know the correct wording in English for this but I am legally licensed as an individual to offer software consulting services and to develop software. So the so-called employer is really my client, with whom I have signed a contract for consulting services. What legal papers would I need for this ? Thank you, Timothy Madden
Re: Long paths with ../../../../ throughout
Jon writes: > Is there any information about how GCC start up constructors for C/C++ > are generated and called before main you could point me to please. I'd > like to understand how it works. Second half of http://www.airs.com/blog/archives/51 . > I've attached collect2 patch. Let me know what you think of it. There is actually a GNU standard for --help output, and collect2 might as well follow it. http://www.gnu.org/prep/standards/html_node/_002d_002dhelp.html Do you have a copyright assignment/disclaimer with the FSF? Ian
Re: gen_lowpart called where 'truncate' needed?
Mat Hostetter writes: > Since the high bits are already zero, that would be less efficient on > most platforms, so guarding it with something like this would probably > be smarter: > > if (targetm.mode_rep_extended (mode, GET_MODE(x)) == SIGN_EXTEND) > return simplify_gen_unary (TRUNCATE, mode, x, GET_MODE (x)); > > I'm happy to believe I'm doing something wrong in my back end, but I'm > not sure what that would be. I could also believe these are obscure > edge cases no one cared about before. Any tips would be appreciated. Interesting. I think you are in obscure edge case territory. Your suggestion makes sense to me, and in fact it should probably be put into gen_lowpart_common. Ian
Re: Support for export keyword to use with C++ templates ?
Timothy Madden writes: > On Wed, Feb 3, 2010 at 4:19 AM, Richard Kenner > wrote: >>> I see that what I need is an assignment for all future changes. If my >>> employer is not involved with any contributions of mine, the employer >>> disclaimer is not needed, right ? >> >> It's safest to have it. The best way to prove that your employer is >> not involved with any contributions of yours is with such a disclaimer. > > The term "employer" is inappropriate for legal purposes in my case as > I am a self-employed individual or a freelancer. > > I do not know the correct wording in English for this but I am legally > licensed as an individual to offer software consulting services and to > develop software. > > So the so-called employer is really my client, with whom I have signed > a contract for consulting services. > > What legal papers would I need for this ? It depends on who owns the code that you write. If you own the code, then you need to sign papers as an individual contributor. Thanks. Ian
Re: Support for export keyword to use with C++ templates ?
> I do not know the correct wording in English for this but I am legally > licensed as an individual to offer software consulting services and to > develop software. > > So the so-called employer is really my client, with whom I have signed > a contract for consulting services. If you have exactly one client, then I would treat them as an "employer" for this purpose and get a disclaimer from them. If you have multiple clients, I'd suggest asking the FSF directly since this is a potentially tricky situation.
Re: Support for export keyword to use with C++ templates ?
> It depends on who owns the code that you write. If you own the code, > then you need to sign papers as an individual contributor. I don't think it's that simple. "who owns the code" is not always clear. There's often a question of who that is. That's why if somebody HAS an employer we usually ask for a disclaimer from that employer even when the person doesn't think their employer has any claims on the code.
Re: gen_lowpart called where 'truncate' needed?
Ian Lance Taylor writes: > Mat Hostetter writes: > >> Since the high bits are already zero, that would be less efficient on >> most platforms, so guarding it with something like this would probably >> be smarter: >> >> if (targetm.mode_rep_extended (mode, GET_MODE(x)) == SIGN_EXTEND) >> return simplify_gen_unary (TRUNCATE, mode, x, GET_MODE (x)); >> >> I'm happy to believe I'm doing something wrong in my back end, but I'm >> not sure what that would be. I could also believe these are obscure >> edge cases no one cared about before. Any tips would be appreciated. > > Interesting. I think you are in obscure edge case territory. Your > suggestion makes sense to me, and in fact it should probably be put > into gen_lowpart_common. FWIW, I disagree. Firstly, mode_rep_extended is a special case of !TRULY_NOOP_TRUNCATION so the above check should use that. Secondly, in MIPS we call gen_lowpart to convert DI to SI when we know it's safe. In this case we always want a subreg not a truncate for better code. So I don't think gen_lowpart_common is the right place to fix this. I think the right fix is to call convert_to_mode or convert_move in the expansion code which ensure the proper truncation. Adam
