> -Original Message-
> From: Jiangning Liu
> Sent: Wednesday, December 28, 2011 5:38 PM
> To: Jiangning Liu; 'Richard Guenther'
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
>
>
> > -Original Message-
> > From: gcc-ow...@gcc.gnu.org [mailt
On 29/12/2011 00:08, R A wrote:
And if you want portable pre-processing or code generation, use
something that generates the code rather than inventing tools and
features that don't exist, nor will ever exist. It is also quite
common to use scripts in languages like perl or python to generate
t
On 12/28/2011 6:25 PM, R A wrote:
that all being said, i really don't think it's a hard feature to
implement like i said, just whenever there is an 1) evaluation in
the conditional directives or 2) #define is called, look for "eval",
if there, evaluate the expression, then substitute token.
I was looking again at:
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00294.html
and was comparing the RTL {true,output,anti}_dependence functions.
output_dependence and anti_dependence call fixed_scalar_and_varying_struct_p
with rtx_addr_varies_p. Many places also call true_dependence with
AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
anti_dependence between a load X and store Y because Y might be defining
a new object in the same space as the object that was being read by X.
But it looks like we still use component-based disambiguation
(nonoverlapping_compon
Quoting Dmitry Melnik :
Hi,
In cortex-a8.md call cost is set to 32, while in cortex-a9.md it's 0:
== cortex-a8.md ==
;; Call latencies are not predictable. A semi-arbitrary very large
;; number is used as "positive infinity" so that everything should be
;; finished by the time of return.
(def
Richard,
I'm interested in implementing (some of) the new __atomic builtins using the
xlr/xlp atomic instructions ldadd and swap.
Do you perhaps have work in progress there?
Thanks,
- Tom
> fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
> So in these cases fixed_scalar_and_varying_struct_p effectively becomes
> a no-op on targets that don't allow MEMs in addresses and takes on
> suspicious semantics for those that do. In the former case, every
> address is
Hi,
In cortex-a8.md call cost is set to 32, while in cortex-a9.md it's 0:
== cortex-a8.md ==
;; Call latencies are not predictable. A semi-arbitrary very large
;; number is used as "positive infinity" so that everything should be
;; finished by the time of return.
(define_insn_reservation "cort
> The gcc developers, and everyone else involved in the development of C
> as a language, are perhaps not superhuman - but I suspect their combined
> knowledge, experience and programming ability outweighs yours.
given. but do you have a consensus of the community that this feature is not
worth
R A writes:
>> The gcc developers, and everyone else involved in the development of C
>> as a language, are perhaps not superhuman - but I suspect their combined
>> knowledge, experience and programming ability outweighs yours.
>
> given. but do you have a consensus of the community that this fea
The idea sounds useful to me ..
Or perhaps introduce template into C :)
David
On Thu, Dec 29, 2011 at 1:12 PM, Ian Lance Taylor wrote:
> R A writes:
>
>>> The gcc developers, and everyone else involved in the development of C
>>> as a language, are perhaps not superhuman - but I suspect their
> given. but do you have a consensus of the community that this
> feature is not worth including? i haven't even heard but from a few
> people saying that "it's not worth it because if it was, 'we're the
> ones to have thought about it'".
No, that's not what people are saying.
It's important to t
> I personally do not feel it is worth the effort. It's easy to use a
> more powerful macro processor, such as m4, to generate your C code. The
> benefit of building a more powerful macro processor into the language
> proper seems minimal.
>
> This particular extension seems problematic when cross
I've been investigating some LTO-related test failures in a GCC port for
a DSP target that has not yet been submitted to the FSF. The bug I've
hit looks like the same issue with spurious multiple definitions that
was previously reported on the gcc-help list:
http://gcc.gnu.org/ml/gcc-help/201
On 29/12/11 22:05, R A wrote:
The gcc developers, and everyone else involved in the development
of C as a language, are perhaps not superhuman - but I suspect
their combined knowledge, experience and programming ability
outweighs yours.
given. but do you have a consensus of the community that
R A writes:
>> This particular extension seems problematic when cross-compiling. In
>> what environment should the expressions be evaluated?
>
>
> why
> are you asking for a specific environment? it's coding convenience and
> elegance for coding in c itself. simplest case scenario is what i've
(Sorry for the double reply back, I should have read ahead).
R A writes:
> good questions, but i'm surprised that you don't know basic semantics of how
> the cpp works. i take it that you don't use it as extensively as others??
Thank for the patronizing words. That is always a good way to get
On Thu, Dec 29, 2011 at 1:50 PM, David Brown wrote:
> On 29/12/11 22:05, R A wrote:
>>
>>
>>> The gcc developers, and everyone else involved in the development
>>> of C as a language, are perhaps not superhuman - but I suspect
>>> their combined knowledge, experience and programming ability
>>> ou
for some reason they blocked my very last email, but i tried CC'ing it again,
maybe this time they'll let it through. i'm forwarding it to you, since we
agree on some points. if it doesn't make it to the mailing list, you might want
to forward it, then... or not.
thnx
-
---
> Date: Thu, 29 Dec 2011 16:30:04 -0800
> Subject: Re: a nifty feature for c preprocessor
> From: james.denn...@gmail.com
> To: david.br...@hesbynett.no
> CC: ren_zokuke...@hotmail.com; gcc@gcc.gnu.org
.
>
> I'd tend to agree; we ought to move functionality
i meant "general purpose" macro processor. sorry.
22 matches
Mail list logo
