Quoting "H.J. Lu" :
We only have very few bits to in STB_XXX field.
Well, you could put the information somewhere else. E.g. a special
relocation,
or a special elf section. Or you could mangle the information into
the section name in which the symbol is present.
Even better, you could u
"H.J. Lu" writes:
> On Fri, Apr 20, 2012 at 5:49 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> In our usage, the backup definition may not be at the end of
>>> command line since it may reference library symbols.
>>
>> You could write out the backup function you need under a different
On Fri, Apr 20, 2012 at 5:49 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> In our usage, the backup definition may not be at the end of
>> command line since it may reference library symbols.
>
> You could write out the backup function you need under a different name.
> Then have the backu
"H.J. Lu" writes:
> In our usage, the backup definition may not be at the end of
> command line since it may reference library symbols.
You could write out the backup function you need under a different name.
Then have the backup symbol at the end of the link call the new name of
the backup func
Oops, meant to CC gcc-patches ...
On 21 April 2012 01:01, Jonathan Wakely wrote:
> On 21 April 2012 00:37, Todd Edwards wrote:
>> In Section "New Languages and Language specific improvements" In subsection
>> "C Family" Objective-C is repeated twice. :
>> "A new experimental -ftrack-macro-expansi
On 21 April 2012 00:37, Todd Edwards wrote:
> In Section "New Languages and Language specific improvements" In subsection
> "C Family" Objective-C is repeated twice. :
> "A new experimental -ftrack-macro-expansion option was added for C, C++,
> Objective-C, Objective-C and Fortran. It allows the co
On Fri, Apr 20, 2012 at 4:40 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Fri, Apr 20, 2012 at 3:59 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote:
>> We only have very few bits to in STB_XXX field.
>
> This
"H.J. Lu" writes:
> On Fri, Apr 20, 2012 at 3:59 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote:
> We only have very few bits to in STB_XXX field.
This is exactly why I'm not in favor of this extension. The feature
In Section "New Languages and Language specific improvements" In
subsection "C Family" Objective-C is repeated twice. :
"A new experimental -ftrack-macro-expansion option was added for C, C++,
Objective-C, Objective-C and Fortran. It allows the compiler to emit
diagnostic about the current macro
On Fri, Apr 20, 2012 at 3:59 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote:
We only have very few bits to in STB_XXX field.
>>>
>>> This is exactly why I'm not in favor of this extension. The feature
>>> doesn't seem compelling enou
On Fri, Apr 20, 2012 at 3:54 PM, Petr Baudis wrote:
> On Fri, Apr 20, 2012 at 01:11:34PM -0700, H.J. Lu wrote:
>> On Fri, Apr 20, 2012 at 12:50 PM, Roland McGrath
>> wrote:
>> > Please provide an example that illustrates why you think you need this.
>> >
>>
>> Currently we use weak undefined sym
Other target-patches exposed this for me.
I have on the 4.7-branch an insn:
(jump_insn 245 277 246 (set (pc)
(label_ref:SI 312)) whatever.c:511 -1
(nil)
-> 187)
and two (or more) pattern candidates in the following .md file
order:
(define_insn "jump"
[(set (pc)
(label_ref
Snapshot gcc-4.6-20120420 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120420/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
"H.J. Lu" writes:
> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote:
>>> We only have very few bits to in STB_XXX field.
>>
>> This is exactly why I'm not in favor of this extension. The feature
>> doesn't seem compelling enough to use up one of these precious
>> reserved values (in fact, yo
On Fri, Apr 20, 2012 at 01:11:34PM -0700, H.J. Lu wrote:
> On Fri, Apr 20, 2012 at 12:50 PM, Roland McGrath wrote:
> > Please provide an example that illustrates why you think you need this.
> >
>
> Currently we use weak undefined symbol, foo, to do
>
> if (&foo != 0)
> foo is defined.
> else
>
On Fri, Apr 20, 2012 at 3:47 PM, H.J. Lu wrote:
> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote:
>>> We only have very few bits to in STB_XXX field.
>>
>> This is exactly why I'm not in favor of this extension. The feature
>> doesn't seem compelling enough to use up one of these precious
>>
On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote:
>> We only have very few bits to in STB_XXX field.
>
> This is exactly why I'm not in favor of this extension. The feature
> doesn't seem compelling enough to use up one of these precious
> reserved values (in fact, you're using the next-to-last
> We only have very few bits to in STB_XXX field.
This is exactly why I'm not in favor of this extension. The feature
doesn't seem compelling enough to use up one of these precious
reserved values (in fact, you're using the next-to-last one that's
reserved for OS use).
You want a backup definitio
On Fri, Apr 20, 2012 at 1:55 PM, Joern Rennecke wrote:
> Quoting "H.J. Lu" :
>
>> Hi,
>>
>> We have a need to define a secondary symbol as backup in
>> case there isn't a primary one. Here is a proposal for
>> STB_GNU_SECONDARY. Any comments?
>
>
> If two levels of prevedence (ordinary and weak)
Quoting "H.J. Lu" :
Hi,
We have a need to define a secondary symbol as backup in
case there isn't a primary one. Here is a proposal for
STB_GNU_SECONDARY. Any comments?
If two levels of prevedence (ordinary and weak) are not enough, why will
three levels be so much better?
If you use a sign
On Fri, Apr 20, 2012 at 1:26 PM, Roland McGrath wrote:
>> Currently we use weak undefined symbol, foo, to do
>>
>> if (&foo != 0)
>> foo is defined.
>> else
>> foo isn't defined.
>>
>> We want is to define foo as a secondary symbol so that
>> we can always use foo without checking. If there is
> Currently we use weak undefined symbol, foo, to do
>
> if (&foo != 0)
> foo is defined.
> else
> foo isn't defined.
>
> We want is to define foo as a secondary symbol so that
> we can always use foo without checking. If there is a primary
> one in a .o file and .so file, we will get the prim
On Tue, 3 Apr 2012, Pawe�~B Sikora wrote:
> i'm only suggesting that astyle (or another tool) can be used in svn
> pre-commit
> hook to verifying gnu formatting rules (incoming files can be extracted from
I think it's a bad idea to check anything in a pre-commit hook that isn't
also covered by
On Fri, Apr 20, 2012 at 12:50 PM, Roland McGrath wrote:
> Please provide an example that illustrates why you think you need this.
>
Currently we use weak undefined symbol, foo, to do
if (&foo != 0)
foo is defined.
else
foo isn't defined.
We want is to define foo as a secondary symbol so that
Please provide an example that illustrates why you think you need this.
Thanks,
Roland
Hi,
We have a need to define a secondary symbol as backup in
case there isn't a primary one. Here is a proposal for
STB_GNU_SECONDARY. Any comments?
Thanks.
--
H.J.
---
STB_GNU_SECONDARY
Secondary symbols are similar to weak symbols, but their definitions
have even lower precede
> Why wouldn't it be constructive?
>
> Even if it's impractical for gcc to change to the degree needed to fit
> your particular project (especially in the short term), hearing the
> details of how gcc's representations fell short, and how others may
> have done things better, seems useful.
My main
Since nobody answered to Richard, and I find the discussion
interesting to understand what the future of GCC might be
> Our high-level AST is language specific. In case of C++ its GENERIC plus
> some C++ specific tree codes. There is no framework for building a CFG
> on top of that (not sure if
On Fri, Apr 20, 2012 at 11:04 AM, Bin.Cheng wrote:
> On Fri, Apr 20, 2012 at 4:54 PM, Richard Guenther
> wrote:
>> On Fri, Apr 20, 2012 at 9:52 AM, Bin.Cheng wrote:
>>> On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther
>>> wrote:
On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote:
>>>
On Fri, Apr 20, 2012 at 4:54 PM, Richard Guenther
wrote:
> On Fri, Apr 20, 2012 at 9:52 AM, Bin.Cheng wrote:
>> On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther
>> wrote:
>>> On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote:
>>
>>>
>>> I don't understand method 2. I'd do
>>>
>>> start at the
On Fri, Apr 20, 2012 at 9:52 AM, Bin.Cheng wrote:
> On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther
> wrote:
>> On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote:
>
>>
>> I don't understand method 2. I'd do
>>
>> start at the single predecessor of the sink-to block
>>
>> foreach stmt from th
On Thu, Apr 19, 2012 at 10:20 PM, Diego Novillo wrote:
> On 4/19/12 4:14 PM, Andrew Pinski wrote:
>
>> How do you know it is a major effort? Has any issues related to
>> changing Tuple/front-ends AST been raised to the mailing list and
>> asked for help on how to implement these changes?
>
>
> Th
On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther
wrote:
> On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote:
>
> I don't understand method 2. I'd do
>
> start at the single predecessor of the sink-to block
>
> foreach stmt from the end to the beginning of that block
> if the stmt has a VDEF
33 matches
Mail list logo
