RC it is one of those things that worked on the cfg-branch or
the rtlopt-branch (and probably on the hammer-branch) but that
never got merged to the mainline. Honza knows more about it, I
think...
Gr.
Steven
or (insn = get_insns (); insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
num_insn++;
and then compare the result with the estimate of the tree inliner.
The results were quite discouraging at the time, which is why
Honza rewrote the size estimate. No idea how well or poor we do
today ;-)
Gr.
Steven
On Thursday 24 February 2005 21:16, James E Wilson wrote:
> On Thu, 2005-02-24 at 03:15, Steven Bosscher wrote:
> > On Feb 24, 2005 11:13 AM, Tarun Kawatra <[EMAIL PROTECTED]> wrote:
> > Does GCSE look into stuff in PARALLELs at all? From gcse.c:
>
> Shrug. The code i
hing different. Didn't Dan already have patches for
that in the old tree SSAPRE, and some ideas on how to do it
in GVN-PRE?
Gr.
Steven
64-unknown-linux-gnu
> and ia64-hp-hpux11.23.
Great!
I'll merge mainline to the GOMP branch when your parser is in.
Gr.
Steven
On Feb 25, 2005 10:50 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> I have posted the GCC 4.1 project submissions I received here:
>
>http://gcc.gnu.org/wiki/GCC%204.1%20Projects
Nice!
Gr.
Steven
Known problem, happens from time to time (especially after
tagging/merging, apparently). I tried to fix it via pme's
workaround. Can you see if it works again?
Gr.
Steven
Mainline java is broken:
./.libs/libgcj0_convenience.a(Logger.o)(.text+0x620): In function
`java::util::logging::Logger::getName()':
/abuild/gcc-test/gcc/libjava/java/util/logging/Logger.java:510: multiple
definition of `java::util::logging::Logger::getName()'
Gr.
Steven
his patch?
Gr.
Steven
On Feb 27, 2005 02:04 AM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> In the end we surely want to watch CiSBE and SPEC testers.
Maybe so, but your timings already show this is pretty unacceptable.
Gr.
Steven
On Sunday 27 February 2005 10:57, Richard Guenther wrote:
> Steven Bosscher wrote:
> > On Feb 27, 2005 02:04 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> >>In the end we surely want to watch CiSBE and SPEC testers.
> >
> > Maybe so, but your timings alre
On Saturday 26 February 2005 20:45, Steven Bosscher wrote:
> Mainline java is broken:
> ./.libs/libgcj0_convenience.a(Logger.o)(.text+0x620): In function
> `java::util::logging::Logger::getName()':
> /abuild/gcc-test/gcc/libjava/java/util/logging/Logger.java:510: multiple
>
to other functions and similar)
> and forcing their costs to be CALL_INSN_COST, but didn't get across that
> yet.
Another idea might be to give "small" functions with one or more
constant arguments a smaller inlining penalty.
> So we should slow down compilation of testcases like tramp3d to
> get sane performance and not affect too much lower level code, like
> SPEC.
Or have different inlining heuristics for C++.
Gr.
Steven
On Sun, 10 Mar 2013 at 13:51, Matt Davis wrote:
> I have a GIMPLE_CALL gimple object. I want to get the tree node
> representing the callsite for this particular instance of a call, how
> can I get this information?
The GIMPLE_CALL gimple object *is* the call site.
Ciao!
Steven
f a call output pattern
emits multiple assembly instructions for a single call RTL
instruction.
Ciao!
Steven
11 - 7
> --- ---
> Total80 - 3
How did you compile these numbers? The "Serious regressions" link on
gcc.gnu.org results in a bug list with no P1 bugs and only 74 P2+P3
bugs.
Ciao!
Steven
On Sat, Mar 16, 2013 at 3:04 PM, Jakub Jelinek wrote:
> On Sat, Mar 16, 2013 at 02:51:03PM +0100, Steven Bosscher wrote:
>> On Sat, Mar 16, 2013 at 9:55 AM, Jakub Jelinek wrote:
>> > Quality Data
>> >
>> >
>> >
noticed compilations of many
small files being slower. I wonder if the larger cc1 and .bss sections
could be in part responsible for that...?
Ciao!
Steven
Test set are cc1-i files for trunk r189478, configured with release checking:
Compiler flags: -S -O2 -fpreprocessed:
Run 1 Run 2
on" to GIMPLE is an idea that is around since
> quite some time. Basically you'd lower switches so that remaining
> switch statements directly map to jump-tables only. Steven was working
> on this a bit and if I remember correctly 4.8 has some improvements
> here in the switch-conve
uld really help if this code can go away...
Ciao!
Steven
from the .expand dump:
(note 317 8 9 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(jump_insn 9 317 10 4 (set (pc)
(mem:SI (plus:SI (mult:SI (reg:SI 97)
(const_int 4 [0x4]))
(label_ref 10)) [0 S4 A32])) t.c:1
On Sat, Apr 6, 2013 at 7:09 PM, John David Anglin wrote:
> On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote:
>
>> Are there any reasons against removing !TARGET_BIG_SWITCH support? It
>> would really help if this code can go away...
>
>
> Yes, branch distances are limite
.c's delay slot
scheduling, it somehow knows that insn 23 can fill the delay slot of
insn 24 while insn 22 cannot.
How can I tell whether an insn "only" sets a call arg register, and is
otherwise permutable with the call insn itself?
Thanks,
Ciao!
Steven
$ cat t.c
long bar
s that at least some of the ifcvt.c transformations could
be applied to fill more delay slots (obviously if_case_1 and
if_case_2. In reorg.c, optimize_skip does some kind of if-conversion.
Has anyone looked at whether optimize_skip still does something, and
derived a test case for that?
Thanks for any comments/suggestions/insights/...
Ciao!
Steven
On Thu, Apr 18, 2013 at 6:22 AM, Jeff Law wrote:
> On 04/17/2013 03:52 PM, Steven Bosscher wrote:
>>
>> First of all: What is still important to handle?
>>
>> It's clear that the expectations in reorg.c are "anything goes" but
>> modern RISCs (every
quot;un-PRE" around loops, code hoisting and
redundancy elimination, etc. My new toy scheduler can't compete unless
I implement at least a few of these tricks (but hopefully a little
cleaner)...
Ciao!
Steven
et but sched-dbr looks through the
call to find the sub.
Ciao!
Steven
/* Perform delay slot filling.
Copyright (C) 2013 Free Software Foundation, Inc.
Contributed by Steven Bosscher.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under
the terms of th
ndent on asm target
hooks/macros. It's even been suggested to internally represent
everything as DWARF and to write a dwarf-to-stabs debug emitter.
Ciao!
Steven
[ sent to both Linux kernel mailing list and to gcc list ]
I was looking at some of the old code I still have marked in my TODO
list, that I never pushed to get mainlined. One of them is to move trace
point logic out of the fast path to get rid of the stress that it
imposes on the icache.
Almost
On Mon, 2013-08-05 at 10:02 -0700, H. Peter Anvin wrote:
> > if (x) __attibute__((section(".foo"))) {
> > /* do something */
> > }
> >
>
> One concern I have is how this kind of code would work when embedded
> inside a function which already has a section attribute. This could
> easily caus
On Mon, 2013-08-05 at 10:12 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 9:55 AM, Steven Rostedt wrote:
> First off, we have very few things that are *so* unlikely that they
> never get executed. Putting things in a separate section would
> actually be really bad.
My mai
On Mon, 2013-08-05 at 13:55 -0400, Steven Rostedt wrote:
> The difference between this and the
> "section" hack I suggested, is that this would use a "call"/"ret" when
> enabled instead of a "jmp"/"jmp".
I wonder if this is what Kris Kross meant in their song?
/me goes back to work...
-- Steve
On Mon, 2013-08-05 at 11:17 -0700, H. Peter Anvin wrote:
> On 08/05/2013 10:55 AM, Steven Rostedt wrote:
> >
> > Well, as tracepoints are being added quite a bit in Linux, my concern is
> > with the inlined functions that they bring. With jump labels they are
> > disa
On Mon, 2013-08-05 at 11:20 -0700, Linus Torvalds wrote:
> Of course, it would be good to optimize static_key_false() itself -
> right now those static key jumps are always five bytes, and while they
> get nopped out, it would still be nice if there was some way to have
> just a two-byte nop (turn
On Mon, 2013-08-05 at 11:29 -0700, H. Peter Anvin wrote:
> Traps nest, that's why there is a stack. (OK, so you don't want to take
> the same trap inside the trap handler, but that code should be very
> limited.) The trap instruction just becomes very short, but rather
> slow, call-return.
>
>
On Mon, 2013-08-05 at 11:34 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
> wrote:
> >
> > Ugh. I can see the attraction of your section thing for that case, I
> > just get the feeling that we should be able to do better somehow.
>
&g
On Mon, 2013-08-05 at 11:51 -0700, H. Peter Anvin wrote:
> On 08/05/2013 11:49 AM, Steven Rostedt wrote:
> > On Mon, 2013-08-05 at 11:29 -0700, H. Peter Anvin wrote:
> >
> >> Traps nest, that's why there is a stack. (OK, so you don't want to take
> >>
On Mon, 2013-08-05 at 12:04 -0700, Andi Kleen wrote:
> Steven Rostedt writes:
>
> Can't you just use -freorder-blocks-and-partition?
Yeah, I'm familiar with this option.
>
> This should already partition unlikely blocks into a
> different section. Just a single
On Mon, 2013-08-05 at 11:49 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:39 AM, Steven Rostedt wrote:
> >
> > I had patches that did exactly this:
> >
> > https://lkml.org/lkml/2012/3/8/461
> >
> > But it got dropped for some reason. I don&#
On Mon, 2013-08-05 at 12:57 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
> wrote:
> >
> > I remember that choosing between 2 and 5 bytes nop in the asm goto was
> > tricky: it had something to do with the fact that gcc doesn't know the
> > exact size of each in
On Mon, 2013-08-05 at 17:28 -0400, Mathieu Desnoyers wrote:
> Another thing that bothers me with Steven's approach is that decoding
> jumps generated by the compiler seems fragile IMHO.
The encodings wont change. If they do, then old kernels will not run on
new hardware.
Now if it adds a third o
On Mon, 2013-08-05 at 22:26 -0400, Jason Baron wrote:
> I think if the 'cold' attribute on the default disabled static_key
> branch moved the text completely out-of-line, it would satisfy your
> requirement here?
>
> If you like this approach, perhaps we can make something like this work
> wit
On Mon, 2013-08-05 at 11:49 -0700, Linus Torvalds wrote:
> Ugh. Why the crazy update_jump_label script stuff?
After playing with the patches again, I now understand why I did that.
It wasn't just for optimization.
Currently the way jump labels work is that we use asm goto() and place a
5 byte no
On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
> For unconditional jmp that should be pretty safe barring any fundamental
> changes to the instruction set, in which case we can enable it as
> needed, but for extra robustness it probably should skip prefix bytes.
Would the assembler add
On Tue, 2013-08-06 at 09:19 -0700, H. Peter Anvin wrote:
> On 08/06/2013 09:15 AM, Steven Rostedt wrote:
> > On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
> >
> >> For unconditional jmp that should be pretty safe barring any fundamental
> >> changes
On Tue, 2013-08-06 at 10:48 -0700, Linus Torvalds wrote:
> So I wonder if this is a "ok, let's not bother, it's not worth the
> pain" issue. 128 bytes of offset is very small, so there probably
> aren't all that many cases that would use it.
OK, I'll forward port the original patches for the hell
On Tue, 2013-08-06 at 16:33 -0400, Mathieu Desnoyers wrote:
> Steve, perhaps you could add a mode to your binary rewriting program
> that counts the number of 2-byte vs 5-byte jumps found, and if possible
> get a breakdown of those per subsystem ?
I actually started doing that, as I was curious t
On Tue, 2013-08-06 at 16:43 -0400, Steven Rostedt wrote:
> On Tue, 2013-08-06 at 16:33 -0400, Mathieu Desnoyers wrote:
>
> > Steve, perhaps you could add a mode to your binary rewriting program
> > that counts the number of 2-byte vs 5-byte jumps found, and if possible
>
On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote:
> [3.387362] short jumps: 106
> [3.390277] long jumps: 330
>
> Thus, approximately 25%. Not bad.
Also, where these happen to be is probably even more important than how
many. If all the short jumps happen in slow
On Wed, 2013-08-07 at 07:06 +0200, Ondřej Bílka wrote:
> Add short_counter,long_counter and before increment counter before each
> jump. That way we will know how many short/long jumps were taken.
That's not trivial at all. The jump is a single location (in an asm
goto() statement) that happens
On Wed, 2013-08-07 at 12:03 -0400, Mathieu Desnoyers wrote:
> You might want to try creating a global array of counters (accessible
> both from C for printout and assembly for update).
>
> Index the array from assembly using: (2f - 1f)
>
> 1:
> jmp ...;
> 2:
>
> And put an atomic incr
On Tue, 13 Aug 2013 07:46:46 -0700
"H. Peter Anvin" wrote:
> > On Mon, Aug 12, 2013 at 10:47:37AM -0700, H. Peter Anvin wrote:
> >> Since we really doesn't want to...
>
> Ow. Can't believe I wrote that.
>
All your base are belong to us!
-- Steve
On Sun, Aug 11, 2013 at 10:04 PM, Gerald Pfeifer wrote:
> It's my pleasure to announce the appointment of Steven Bosscher
> as RTL optimizers reviewer.
>
> Congratulations and Happy Hacking, Steven!
>
> Gerald
>
> PS: Please update MAINTAINERS accordingly.
Thanks
pc64-linux libsanitizer broken since r204368.
How do I fix this? :-)
Ciao!
Steven
_expr_type (stmt))
tree-chrec.c: if (POINTER_TYPE_P (chrec_type (poly0)))
tree-chrec.c: if (POINTER_TYPE_P (chrec_type (chrec)))
tree-ssa-ccp.c: || POINTER_TYPE_P (gimple_expr_type (stmt
tree-ssa-structalias.c: && !(POINTER_TYPE_P (gimple_expr_type (t))
Not sure what to do about them (if anything) but I don't think this is
intended...
Ciao!
Steven
he best place to start IMHO would be to evict 'tree' from the
front ends. That would really be a step towards making the front ends
independent of the rest of the compiler, and it would simplify changes
towards static 'tree' types.
Ciao!
Steven
of that transition - see the changes
> done to 'tree' during the last 6 years). And the other nice thing is that
> even non-100% success will end up in something better than we have now.
> With the second project it's a all-or-nothing (or rather
> all-or-just-uglification).
Agreed. Obviously something has to be done, but I've got the feeling
we may be attacking the problem from the wrong end...
Ciao!
Steven
ay: Let it be! If a port is actively maintained, any breakage
will be found quickly. The amount of Werror breakage is a good KPI for
the maintenance state of a port :-)
It's all accidental breakage, and there's no obligation to test
patches on all targets.
Ciao!
Steven
flow anymore, especially jump threading around/near loops.
Ciao!
Steven
nfuses the rest of the CE
code processing. ??? we should fix this in the future. */
and it is assumed that there is a noreturn call in the block without
successors. In other words, the THEN block is really a dead end in the
CFG and it cannot be merged away unless the noreturn call is
if-converted away. In the case of builtin_unreachable, obviously there
isn't a call, but I'm guessing your test case goes through this path
anyway.
I believe the proper fix would be to not recognize this as an
if-conversion block candidate in cond_exec_find_if_block.
Ciao!
Steven
in_unreachable completely
during expand? (It's caused me quite a lot of pain already:
__builtin_unreachable in the middle of a basic block confuses
find_many_sub_basic_blocks, there's a PR somewhere with my name on
it...).
Hacking BARRIERs by hand in a function that's supposed to know about
the CFG just seems wrong :-(
Ciao!
Steven
On Tue, Nov 26, 2013 at 11:05 PM, Jeff Law wrote:
> On 11/26/13 14:41, Steven Bosscher wrote:
>>
>>
>> I suppose with "cruft" you mean the dead end in the CFG due to
>> builtin_unreachable, correct?
>
> Yes.
>
>
>
> > If so, then I suppose
d in cfgrtl mode right now anyway.)
I suppose we'll have to look for a better solution in the next stage1.
Ciao!
Steven
t and wisdom for this new challenge.
Congratulations Joseph!
Ciao!
Steven
f this is an acceptable solution for my issue.
I don't think this is not the right fix for the problem. GCSE doesn't
handle expressions containing hard registers, oprs_unchanged_p should
never even see expressions involving hard registers.
What is the expression that is recorded as anticipated in insn 38? Is
it "mho:SI 0>>0x3" or "udiv(r159:SI,0xa)" from the REG_EQUAL note?
Ciao!
Steven
t it?
Oh, hmm, it isn't.
Your entire rant seems to be based on nothing more than marketing
statements that you present as facts, and an unbalanced deduction of
irrational conclusions from there. It's a waste of bandwidth, if you
ask me...
Ciao!
Steven
ay, another "fact".
You must have missed the almost complete rewrite of GCC's optimization
framework that was merged in 2004 and that's been continuously
improved since than: http://gcc.gnu.org/projects/tree-ssa/
Really. Do your homework.
Ciao!
Steven
needed for rs6000, or can all the
PRE_GCC3_DWARF_FRAME_REGISTERS stuff be cleaned up?
Ciao!
Steven
On Thu, 2012-03-15 at 03:07 +0100, Vincent Lefevre wrote:
> On 2012-03-14 14:40:06 +, Joseph S. Myers wrote:
> > On Wed, 14 Mar 2012, Vincent Lefevre wrote:
> >
> > > For double-double (IBM long double), I don't think the notion of
> > > correct rounding makes much sense anyway. Actually the d
On Mon, 2012-03-26 at 12:26 +0200, Vincent Lefevre wrote:
> On 2012-03-22 16:29:00 +, Joseph S. Myers wrote:
> > On Thu, 22 Mar 2012, Vincent Lefevre wrote:
> > > For the same reason, if the user chose long double instead of
> > > double, this may be because he wanted more precision than double
ssued during gimplification.
That is something I'll have to address before this patch could go in.
Before I spend the effort, I'd like to know if there is consensus on
the general direction proposed here... ;-)
Ciao!
Steven
her people think of
this kind of change before spending loads of time on it :-)
Thanks for your comments!
Ciao!
Steven
SJLJ exception handling will be
less efficient, if I move GIMPLE_SWITCH lowering earlier in the pass
pipeline?
Ciao!
Steven
, maybe PHI-OPT should recognize this pattern and reject the
transformation???
Your thoughts/comments/suggestions, please?
Ciao!
Steven
P.S. Unfortunately I haven't been able to produce a test case that
shows the problem without my switch conversion pass.
xori 3,9,1
blr
.p2align 4,,15
.L3:
.L2:
li 3,0
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size foo,.-.L.foo
.ident "GCC: (GNU) 4.8.0 20120418 (experimental) [trunk
revision 186580]"
I will file a PR for this later today, maybe after trying on a few
other targets to see if this is a middle-end problem or a target
issue.
Ciao!
Steven
On Mon, Apr 23, 2012 at 4:43 PM, Alan Modra wrote:
> On Mon, Apr 23, 2012 at 02:50:13PM +0200, Steven Bosscher wrote:
>> csui = (ONEUL << a);
>> b = ((csui & cst) != 0);
>> if (b)
>> return 1;
>> else
>> return 0;
>
> We
On Mon, Apr 23, 2012 at 2:50 PM, Steven Bosscher wrote:
> I will file a PR for this later today, maybe after trying on a few
> other targets to see if this is a middle-end problem or a target
> issue.
This is now PR target/53087 (http://gcc.gnu.org/PR53087).
Actually the poor code lo
ot;
patterns in pa.md and pa.c, and most of the cleanups to remove support
for SOM objects.
The resulting PA port would support HP-UX11 on 64bits PA-RISC 2.0
(i.e. HP-PA8xxx).
It's hard enough to maintain HP-UX11 support on HP-PA. With this
cleanup, the job would become a bit simpler.
Thoughts/comments?
Ciao!
Steven
On Mon, May 7, 2012 at 7:42 PM, Jeff Law wrote:
> On 05/07/2012 11:33 AM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
>> for targets to be deprecated. I have one I would like to put on the
&
hedule model
(http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00753.html) and that
will simply be a less daunting job if the back end is smaller. It will
also be easier to test.
Ciao!
Steven
patch below be tested? (I choose 16 but I don't know if there
are larger insns for x86 - I assume you do ;-)
Ciao!
Steven
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 187257)
+++ config/i386/i386.md (wo
the number of
machine instructions specified in the asm statement, determined by
counting the number of semicolons and newlines in the string.
Therefore, the value of the length attribute specified in a
define_asm_attributes should be the maximum possible length of a
single machine instruction. "
Ciao!
Steven
On Tue, May 8, 2012 at 1:56 PM, Ulrich Weigand wrote:
> Steven Bosscher wrote:
>
>> 2. HP-UX 10 is also the last target that only supports SJLJ exceptions.
>
> Hmm, SPU also supports only SJLJ exceptions ...
Then why is force_sjlj_exceptions not set for it?
Ciao!
Steven
On Wed, Apr 18, 2012 at 2:44 PM, Richard Henderson wrote:
> On 04/18/2012 05:39 AM, Jan Hubicka wrote:
>> Well, if SJLJ lowering happens as gimple pass somewhere near the end of
>> gimple
>> queue, this should not be problem at all. (and implementation would be
>> cleaner)
>
> If you can find a
or whether this patch is OK or not?
I also have no problems leaving the switch expanding code in stmt.c,
and just adding new code for switch lowering as a GIMPLE pass. That
way (of least resistance) SJLJ exception dispatches can continue to be
expanded as decision trees. Just tell me what you want.
Ciao!
Steven
On Mon, May 14, 2012 at 4:23 PM, Richard Henderson wrote:
> On 05/12/12 06:00, Steven Bosscher wrote:
>> * toplev.c (process_options): Fail for sjlj exceptions if the
>> target machine
>> has no casesi insn and no tablejump insn.
>
> Looks good. How man
How can this work? As far as grep understands, only link_cc0_insns
creates REG_CC_SETTER notes, but that function is only called from
reorg.c (and even then, only if it makes a transformation). So NOTE
will always be NULL.
Are REG_CC_SETTER/REG_CC_USER notes supposed to exist before dbr_sched?
Ci
l
propose to add GCC_OUTPUT_H to the poisoned identifiers list under
system.h:IN_GCC_FRONTEND.
Thanks for any help you can offer,
Ciao!
Steven
On Mon, Jun 4, 2012 at 2:40 PM, Steven Bosscher wrote:
> asm_out_file for PCH:
> c-family/c-pch.c:#include "output.h" /* for asm_out_file */
> c-family/c-pch.c: fprintf (asm_out_file, "%s ", ASM_COMMENT_START);
> c-family/c-pch.c: c_common_print_pch_check
var_decl) = 1;
That does look like premature optimization to me, but I don't really
understand the comment, or the effect of this code. Eric, could you
please have a look at this and help me out?
Ciao!
Steven
ntually, is that targetm will be split up in front end and
middle/back end specific parts.
Ciao!
Steven
ied into a special segment of
> the object file. On other systems, the directive is ignored. The
> @samp{#sccs} directive is a synonym for @samp{#ident}.
>
> I suppose make ASM_OUTPUT_IDENT a target hook instead.
This doesn't really help: You'd now have a target hook called from the
front end that writes to asm_out_file. I want front ends to stop
writing to asm_out_file at all.
Ciao!
Steven
lude output.h) but doesn't solve the bigger problem (try to avoid
writing to asm_out_file from front ends).
Ciao!
Steven
On Mon, Jun 4, 2012 at 4:55 PM, Richard Guenther
wrote:
>> I mean make the whole "write #ident" a target hook.
>
> Another possibility would be to generate a toplevel asm at this point ...
Yes, that might work, I'll try that. Thanks for the ideas and suggestions!
Ciao!
Steven
aven't look at how e.g. clang handles such things, maybe there's
another, better way.
Ciao!
Steven
ariables in one section or another :-D) I was hoping
maybe you know how to rewrite that piece of code such that you get
that uninitialized variable into BSS without DECL_COMMON.
Or maybe you can tell if this code is no longer needed, so I can
prepare a patch to remove it.
Hope you can help,
Ciao!
Steven
On Mon, Jun 4, 2012 at 10:04 PM, David Edelsohn wrote:
> On Mon, Jun 4, 2012 at 3:53 PM, Steven Bosscher wrote:
>
>> What I don't understand, is whether this is still something GNAT has
>> to support, or whether this code can be deprecated/removed. And I ask
>> for
right? That means that
Tru64 also has BSS
(http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50A_ACRO_SUP/OBJSPEC.PDF).
Did GCC support that for Tru64 too?
Is there a test case, so that I can see what GCC 4.7 for Tru64 does
with it, without and with this code in utils.c?
Ciao!
Steven
vax, and non-ELF cris as the only targets without
.bss support. AFAICT, that is :-)
Eric, do you remember a test case that was the reason for the patch
that added this to utils.c? I would like to play with it, and see if I
can understand why apparently the data didn't end up in a .bss
section.
Ciao1
Steven
t for XCOFF
(http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2FXCOFF.htm).
AFAIU the equivalent C test case is a file with just "char
BigArray[1024*1024*256 -1] = {0};", where BigArray ends up in .data
instead of .bss. If the "= {0}" is removed, BigArray is put in
.common.
Ciao!
Steven
Are you sure? There should be no initializer, i.e. DECL_INITIAL == NULL_TREE.
>
> The flag_zero_initialized_in_bss thing looks orthogonal to me.
You are right, DECL_INITIAL is 0.
Ciao!
Steven
801 - 900 of 1056 matches
Mail list logo
