headers
Robert Dewar | 1 Jan 2012 06:42
Favicon

Re: a nifty feature for c preprocessor

On 12/31/2011 4:44 AM, R A wrote:
>
> alright, here's another example why eval is a good idea:
>
> #define A           17
> #define B           153
> #define N1          ((A + B)/2)  /* intended was (17 + 153)/2 */
>
> #undef  A
> #define A           230
> #define N2          ((A + B)/2) /* intended was (230 + 153)/2 */

Bad example, this is a misuse of the preprocessor in any case!
Permalink | Reply | 3 comments |
headers
R A | 1 Jan 2012 09:04
Picon
Favicon

RE: a nifty feature for c preprocessor


i don't know if you're trying to be funny...

but what's between the definition of N1 and the undef of A may be a very complex. it's just simplified for demonstration.

----------------------------------------
> Date: Sun, 1 Jan 2012 00:42:16 -0500
> From: dewar <at> adacore.com
> To: ren_zokuken01 <at> hotmail.com
> CC: gcc <at> gcc.gnu.org
> Subject: Re: a nifty feature for c preprocessor
>
> On 12/31/2011 4:44 AM, R A wrote:
> >
> > alright, here's another example why eval is a good idea:
> >
> > #define A 17
> > #define B 153
> > #define N1 ((A + B)/2) /* intended was (17 + 153)/2 */
> >
> > #undef A
> > #define A 230
> > #define N2 ((A + B)/2) /* intended was (230 + 153)/2 */
>
> Bad example, this is a misuse of the preprocessor in any case!
Permalink | Reply | 1 comment |
headers
Richard Kenner | 1 Jan 2012 13:40
Picon

RE: a nifty feature for c preprocessor

> i don't know if you're trying to be funny...
> 
> but what's between the definition of N1 and the undef of A may be a very
> complex. it's just simplified for demonstration.

It's not good programming practice to have a macro (in this case A) have
two different values, with an #undef between then.    There are very
few good reasons to use #undef, but that's not one of them.

The reason is that when you look at the usage of the macro and want to
find how it's defined, a search for the definition may come up with the
wrong one.
Permalink | Reply | 0 comments |
headers
David Brown | 1 Jan 2012 13:58
Picon

Re: a nifty feature for c preprocessor

On 31/12/11 10:44, R A wrote:
>
> alright, here's another example why eval is a good idea:
>
> #define A           17 #define B           153 #define N1
> ((A + B)/2)  /* intended was (17 + 153)/2 */
>
> #undef  A #define A           230 #define N2          ((A + B)/2) /*
> intended was (230 + 153)/2 */
>
> printf("%u %u", N1, N2);
>
>
> sure, you can assign N1 to a static const, say N1_var, then invoke
> that in when printf is finally called. or simply print N1, then after
> the undef print N2. but what if we have to use both N1 and N2 in the
> same conditional expression?? everybody should be aware by now that
> there's a lot of ugly dependencies in cpp.
>

The best idea for something like this would be to use a static const (I 
don't know why you dismissed that).  Undefining and redefining your 
macros like this is almost always a bad idea - it is far easier to 
understand your program, and to write correct code, if macros mean one 
thing and one thing only.

> but for a *fairly complex*(1) conditional directives, spanning
> several files, you have to call the macros all at the same time and
> not one one-by-one. to get around it (if possible) is to employ an
> even more complex system of defs and conditionals... or you can use
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ruben Safir | 1 Jan 2012 17:46

Re: a nifty feature for c preprocessor

On 01/01/2012 12:42 AM, Robert Dewar wrote:
> On 12/31/2011 4:44 AM, R A wrote:
>>
>> alright, here's another example why eval is a good idea:
>>
>> #define A           17
>> #define B           153
>> #define N1          ((A + B)/2)  /* intended was (17 + 153)/2 */
>>
>> #undef  A
>> #define A           230
>> #define N2          ((A + B)/2) /* intended was (230 + 153)/2 */
>
> Bad example, this is a misuse of the preprocessor in any case!
>
>

why?
Permalink | Reply | 0 comments |
headers
Andi Kleen | 2 Jan 2012 08:22

Re: LTO multiple definition failures

Sandra Loosemore <sandra <at> codesourcery.com> writes:
>
> I'm still finding my way around LTO; can anyone who's more familiar
> with this help narrow down where to look for the cause of this?  I
> don't even know if this is a compiler or ld bug at this point.  I'm

I would look into the interaction between the LTO plugin and your ld
(and also try gold if you can)

Generally there are still various issues in these areas which need
workarounds in the LTOed programs, for some things (like ld -r and some
ar) you also need the latest version of HJ Lu's binutils which implement
http://gcc.gnu.org/ml/gcc/2010-12/msg00229.html

A lot of older binutils lds also tended to mishandle mixed LTOed ar
archives.

-Andi

--

-- 
ak <at> linux.intel.com -- Speaking for myself only
Permalink | Reply | 2 comments |
headers
Richard Guenther | 2 Jan 2012 10:22
Picon

Re: Bogus gcc.c-torture/execute/20071018-1.c testcase?

On Sat, 31 Dec 2011, Mark Kettenis wrote:

> Execution of the test randomly fails for me on OpenBSD/amd64.  Looking
> at the code, it seems it is doing an out-of-bounds array access.  For
> refernce I've copied the code of the testcase below.  As you can see
> there's a foo(0) call in main().  Therefore
> 
>   struct foo **upper = &as->x[rank * 8 - 1];
> 
> becomes
> 
>   struct foo **upper = &as->x[-1];
> 
> so upper points to an address before the malloc()'ed memory.  Then
> when the code does
> 
>   *upper = 0;
> 
> this generates a SIGSEGV, if the malloc()'ed memory happens to lie
> right at the start of a page.  I suppose that may never happen on some
> platforms (Linux?) since many malloc() implementations will use the
> start of a page for their own bookkeeping.
> 
> I don't really understand what the testcase is testing.  Richard, can
> you perhaps shed some light on this?

The testcase was added when trying to fix PR32921, I do not remember
whether it was relevant that an out-of-bounds array access occured
(but I suppose it was so).  It was a miscompile, so a runtime testcase
is required.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Guenther | 2 Jan 2012 12:36
Picon

Re: Lingering tbaa in anti_dependence?

On Fri, Dec 30, 2011 at 6:53 PM, Jakub Jelinek <jakub <at> redhat.com> wrote:
> On Thu, Dec 29, 2011 at 04:24:31PM +0000, Richard Sandiford wrote:
>> 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_component_refs_p) in this case.  Is it true that
>> that's also a problem?  E.g. for:
>>
>>     struct s { int f; float g; };
>>     struct t { int header; struct s s; };
>>
>>     float foo (struct t *newt, struct s *olds, int x, int y)
>>     {
>>       float ret = olds[x * y].g;
>>       newt->header = 0;
>>       newt->s.f = 1;
>>       newt->s.g = 1.0;
>>       return ret;
>>     }
>>
>> we can (and on ARM Cortex A8, do) move the store to newt->s.f above
>> the load from olds[...].g.  If we view the assignment to newt
>> as defining a new object in the same space as the now-defunct olds,
>> and if x * y happens to be zero, then the accesses might well be
>> to the same address.
>
> You would need a placement new in between the read from olds[x * y].g
> and newt->* stores, without that it is definitely valid to move it
> ahead of the store.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amker.Cheng | 2 Jan 2012 12:37
Picon

RFC: Handle conditional expression in sccvn/fre/pre

Hi,
Since SCCVN operates on SSA graph instead of the control flow graph
for the sake of efficiency,
it does not handle or value number the conditional expression of
GIMPLE_COND statement.
As a result, FRE/PRE does not simplify conditional expression, as
reported in bug 30997.

Since it would be complicate and difficult to process conditional
expression in currently SCCVN
algorithm, how about following method?

STEP1  Before starting FRE/PRE, we can factor out the conditional
expression, like change following
codes:
--------------------------------
if (cond_expr)
  goto lable_a
else
  goto label_b

into codes:
--------------------------------
tmp = cond_expr
if (tmp == 1)
  goto label_a
else
  goto label_b

STEP2  Let SCCVN/FRE/PRE do its job on value numbering cond_expr and
(Continue reading)

Permalink | Reply | 10 comments |
headers
Richard Guenther | 2 Jan 2012 13:33
Picon

Re: RFC: Handle conditional expression in sccvn/fre/pre

On Mon, Jan 2, 2012 at 12:37 PM, Amker.Cheng <amker.cheng <at> gmail.com> wrote:
> Hi,
> Since SCCVN operates on SSA graph instead of the control flow graph
> for the sake of efficiency,
> it does not handle or value number the conditional expression of
> GIMPLE_COND statement.
> As a result, FRE/PRE does not simplify conditional expression, as
> reported in bug 30997.
>
> Since it would be complicate and difficult to process conditional
> expression in currently SCCVN
> algorithm, how about following method?
>
> STEP1  Before starting FRE/PRE, we can factor out the conditional
> expression, like change following
> codes:
> --------------------------------
> if (cond_expr)
>  goto lable_a
> else
>  goto label_b
>
> into codes:
> --------------------------------
> tmp = cond_expr
> if (tmp == 1)
>  goto label_a
> else
>  goto label_b
>
(Continue reading)

Permalink | Reply | 9 comments |

Gmane