Invalid code emitted

[Umesh Kalappa]

Hi All ,

The following C  code snippet

unsigned char c ;
int d ;

int test ()
{
 d = c;
return d;
}

below is the RTL without optimisation enabled

(insn 6 5 0 (set (reg:QI 18 [ c.0 ])

(mem/c:QI (symbol_ref:HI ("c")  ) [0
c+0 S1 A8])) cnv.c:5 -1

 (nil))


(insn 7 6 8 (set (reg:QI 19)

(const_int 0 [0])) cnv.c:5 -1

 (nil))



(insn 8 7 0 (set (reg:HI 19 [ d.1 ])

(subreg:HI (reg:QI 18 [ c.0 ]) 0)) cnv.c:5 -1

 (expr_list:REG_EQUAL (zero_extend:HI (reg:QI 18 [ c.0 ]))

(nil)))



(insn 9 8 0 (set (mem/c:HI (symbol_ref:HI ("d")  ) [0 d+0 S2 A16])

(reg:HI 19 [ d.1 ])) cnv.c:5 -1

 (nil))



(insn 10 9 0 (set (reg:HI 20 [ D.1323 ])

(mem/c:HI (symbol_ref:HI ("d")  ) [0
d+0 S2 A16])) cnv.c:6 -1

 (nil))

and  respective ASM

ld  C, (c)
ld  B, 0
ld  (d), BC
ld  WA, (d)
ret


But problem arises when i enabled the optimisation -O3 ( with -da)  .

RTL is expanded  as show above, but after subreg pass(*.subreg)   we
see the below RTL


(note 4 0 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 3 4 8 2 NOTE_INSN_FUNCTION_BEG)

(insn 8 3 9 2 (set (mem/c:HI (symbol_ref:HI ("d")  ) [2 d+0 S2 A16])

(reg:HI 19 [ d.1 ])) cnv.c:5 9 {*movhi}

 (nil))

(insn 9 8 13 2 (set (reg:HI 20 [  ])

(reg:HI 19 [ d.1 ])) cnv.c:6 9 {*movhi}

 (nil))

(insn 13 9 16 2 (set (reg/i:HI 0 W)

(reg:HI 20 [  ])) cnv.c:7 9 {*movhi}

 (nil))

(insn 16 13 0 2 (use (reg/i:HI 0 W)) cnv.c:7 -1

 (nil))

;;  su

and respective asm emited as


ld  C, (c)
ld  (d), BC ;This is invalid  since B can have a clobbered value
ld  WA, (d)
ret

Would like know there exist any target hook to surpass the above
optimization so that i ended up emitting valid instructions.

Any lights on the above problem is appreciated .

Thanks in advance
~Umesh

Re: [RFC, LRA] Repeated looping over subreg reloads.

[Tejas Belagod]

Vladimir Makarov wrote:

On 12/5/2013, 9:35 AM, Tejas Belagod wrote:

Vladimir Makarov wrote:

On 12/4/2013, 6:15 AM, Tejas Belagod wrote:

Hi,

I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all
mode changes on FP_REGS as aarch64 does not have register-packing, but
I'm running into an LRA ICE. A test case generates an RTL subreg of the
following form

(set (reg:DF 97) (subreg:DF (reg:V2DF 95) 8))

LRA has to reload the subreg because the subreg is not representable as
a full register. When LRA reloads this in
lra-constraints.c:simplyfy_operand_subreg (), it seems to reload
SUBREG_REG() and leave the byte offset alone.

i.e.

  (set (reg:V2DF 100) (reg:V2DF 95))
  (set (reg:DF 97) (subreg:DF (reg:V2DF 100) 8))

The code in lra-constraints.c is this conditional:

   /* Force a reload of the SUBREG_REG if this is a constant or PLUS or
  if there may be a problem accessing OPERAND in the outer
  mode.  */
   if ((REG_P (reg)
   
   insert_move_for_subreg (insert_before ? &before : NULL,
   insert_after ? &after : NULL,
   reg, new_reg);
 }
   

What happens subsequently is that LRA keeps looping over this RTL and
keeps reloading the SUBREG_REG() till the limit of constraint passes is
reached.

  (set (reg:V2DF 100) (reg:V2DF 95))
  (set (reg:DF 97) (subreg:DF (reg:V2DF 100) 8))

I can't see any place where this subreg is resolved (eg. into equiv
memref) before the next iteration comes around for reloading the inputs
and outputs of curr_insn. Or am I missing something some part of code
that tries reloading the subreg with different alternatives or reg
classes?


I guess this behaviour is wrong.  We could spill the V2DF pseudo or
put it into another class reg. But it is not implemented.  This code
is actually a modified version of reload pass one.  We could implement
alternative strategies and a check for potential loop (such code
exists in process_alt_operands).

Could you send me the macro change and the test.  I'll look at it and
figure out what can we do.

Hi,

Thanks for looking at this.

The macro change is in this patch
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03638.html. The test is
gcc.c-torture/compile/simd-3.c and when compiled with -O1 for aarch64,
ICEs:

gcc/testsuite/gcc.c-torture/compile/simd-3.c:22:1: internal compiler
error: Maximum number of LRA constraint passes is achieved (30)

Also, I'm curious to know - is it possible to vec_extract for vector
mode subregs and zero/sign extract for scalars and spilling be the last
resort if either of these are not possible? As you say, non-zero
SUBREG_BYTE offset could also be resolved using a different regclass
where the sub-mode could just be a full-register.



Here is the patch which solves the problem.  Right now it is only 
spilling but it is the best what can be done for this case.  I'll submit 
the patch on the next week after better testing on different platforms.




Hi Vladimir,

Have you had a chance to get this patch tested? This can fix a regression I'm 
seeing on AArch64, and I'd like to get it in if you think this patch is good to go.


Thanks,
Tejas.


Vec_extract is interesting but it is a rare case which needs a lot of 
code to implement this.  I think we need more general approach called 
bitwidth-aware RA (putting several pseudo values into regs, e.g vec 
regs).  Although I don't know will it help for arm64 cpus.  Last time i 
checked manually bitwidth-aware RA for intel cpus, it makes code bigger 
and slower.


If there is a mainstream processor for which it can improve performance, 
i'd put it in my higher priority list to do.

Re: Invalid code emitted

[Ian Lance Taylor]

On Tue, Jan 21, 2014 at 12:52 AM, Umesh Kalappa
 wrote:
>
> The following C  code snippet
>
> unsigned char c ;
> int d ;
>
> int test ()
> {
>  d = c;
> return d;
> }
>
> below is the RTL without optimisation enabled
>
> (insn 6 5 0 (set (reg:QI 18 [ c.0 ])
>
> (mem/c:QI (symbol_ref:HI ("c")  ) [0
> c+0 S1 A8])) cnv.c:5 -1
>
>  (nil))
>
>
> (insn 7 6 8 (set (reg:QI 19)
>
> (const_int 0 [0])) cnv.c:5 -1
>
>  (nil))
>
>
>
> (insn 8 7 0 (set (reg:HI 19 [ d.1 ])
>
> (subreg:HI (reg:QI 18 [ c.0 ]) 0)) cnv.c:5 -1
>
>  (expr_list:REG_EQUAL (zero_extend:HI (reg:QI 18 [ c.0 ]))
>
> (nil)))
>
>
>
> (insn 9 8 0 (set (mem/c:HI (symbol_ref:HI ("d")   d>) [0 d+0 S2 A16])
>
> (reg:HI 19 [ d.1 ])) cnv.c:5 -1
>
>  (nil))
>
>
>
> (insn 10 9 0 (set (reg:HI 20 [ D.1323 ])
>
> (mem/c:HI (symbol_ref:HI ("d")  ) [0
> d+0 S2 A16])) cnv.c:6 -1
>
>  (nil))
>
> and  respective ASM
>
> ld  C, (c)
> ld  B, 0
> ld  (d), BC
> ld  WA, (d)
> ret
>
>
> But problem arises when i enabled the optimisation -O3 ( with -da)  .
>
> RTL is expanded  as show above, but after subreg pass(*.subreg)   we
> see the below RTL
>
>
> (note 4 0 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
>
> (note 3 4 8 2 NOTE_INSN_FUNCTION_BEG)
>
> (insn 8 3 9 2 (set (mem/c:HI (symbol_ref:HI ("d")   0xb7356114 d>) [2 d+0 S2 A16])
>
> (reg:HI 19 [ d.1 ])) cnv.c:5 9 {*movhi}
>
>  (nil))
>
> (insn 9 8 13 2 (set (reg:HI 20 [  ])
>
> (reg:HI 19 [ d.1 ])) cnv.c:6 9 {*movhi}
>
>  (nil))
>
> (insn 13 9 16 2 (set (reg/i:HI 0 W)
>
> (reg:HI 20 [  ])) cnv.c:7 9 {*movhi}
>
>  (nil))
>
> (insn 16 13 0 2 (use (reg/i:HI 0 W)) cnv.c:7 -1
>
>  (nil))
>
> ;;  su
>
> and respective asm emited as
>
>
> ld  C, (c)
> ld  (d), BC ;This is invalid  since B can have a clobbered value
> ld  WA, (d)
> ret
>
> Would like know there exist any target hook to surpass the above
> optimization so that i ended up emitting valid instructions.
>
> Any lights on the above problem is appreciated .


You didn't say what target you are using, you didn't say what version
of GCC you are using, and you didn't give enough information to
understand what is happening.  I don't know what the "ld (d),BC"
syntax means, but perhaps it means that two different registers, B and
C, are combined to form a single value.  If that is true, then it
appears that the subreg pass has dropped the insn setting
pseudo-register 19.  I have no idea how that could happen; it suggests
a bug in your backend port when handling a movqi of a subreg.

Ian

-Wformat-security warnings generated in gcc build

[Prathamesh Kulkarni]

There are about 35 warnings of type "format not a string literal and
no formal arguments [-Wformat-security]" generated during gcc-4.9.0
build (revision 206867)
I have attached them in orig-warnings.txt.

Souce of these warnings are typically calls to error() and friends.
In  C and C++ front ends there are many calls of error (errmsg).
errmsg is in many cases, assigned the return value of targetm hooks
(tagetm.invalid_return_type(), etc.)  Is it correct to replace error
(errmsg) by
error ("%s", errmsg) in these cases ?

I have attached a patch that removes 25 of these warnings
(attached in removed-warnings.txt).
I didn't replace the calls to error() and friends where gmsgid was passed.
(eg: c-typeck.c: error (gmsgid) called by error_init() function at line 6390)

Thanks and Regards,
Prathamesh
../../src/libcpp/expr.c:672:18: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/libcpp/expr.c:675:39: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/libcpp/macro.c:2972:58: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/libcpp/macro.c:2985:58: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-decl.c:5701:16: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-decl.c:6482:21: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-typeck.c:3303:28: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-typeck.c:3798:42: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-typeck.c:10066:42: warning: format not a string literal and 
no format arguments [-Wformat-security]
../../src/gcc/c/c-convert.c:82:31: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/tree-sra.c:3864:26: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/tree-ssa-uninit.c:767:26: warning: format not a string literal 
and no format arguments [-Wformat-security]
../../src/gcc/opts.c:1042:33: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/opts.c:1042:33: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/cp/decl.c:9553:16: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/cp/decl.c:11122:17: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/cp/pt.c:13968:20: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/cp/typeck.c:3986:24: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/cp/typeck.c:5562:24: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/cp/cvt.c:672:26: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/collect2.c:1985:21: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/collect2.c:2536:21: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/lto-wrapper.c:195:24: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/lto-wrapper.c:198:15: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/gcc.c:2785:25: warning: format not a string literal and no format 
arguments [-Wformat-security]
../../src/libcpp/expr.c:672:18: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/libcpp/expr.c:675:39: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/libcpp/macro.c:2972:58: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/libcpp/macro.c:2985:58: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-decl.c:5701:16: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-decl.c:6482:21: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-typeck.c:3303:28: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-typeck.c:3798:42: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-typeck.c:6390:16: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-typeck.c:6407:33: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c/c-typeck.c:6425:23: warning: format not a string literal and no 
format arguments [-Wformat-security]
../../src/gcc/c

Re: Invalid code emitted

[Umesh Kalappa]

My bad Ian,

Thanks for the input and the target was private and gcc 4.8.1 version
used and your are on same page on reg pairing .

Let me have a look on the port .

Thanks Again
~Umesh


On Tue, Jan 21, 2014 at 8:12 PM, Ian Lance Taylor  wrote:
> On Tue, Jan 21, 2014 at 12:52 AM, Umesh Kalappa
>  wrote:
>>
>> The following C  code snippet
>>
>> unsigned char c ;
>> int d ;
>>
>> int test ()
>> {
>>  d = c;
>> return d;
>> }
>>
>> below is the RTL without optimisation enabled
>>
>> (insn 6 5 0 (set (reg:QI 18 [ c.0 ])
>>
>> (mem/c:QI (symbol_ref:HI ("c")  ) [0
>> c+0 S1 A8])) cnv.c:5 -1
>>
>>  (nil))
>>
>>
>> (insn 7 6 8 (set (reg:QI 19)
>>
>> (const_int 0 [0])) cnv.c:5 -1
>>
>>  (nil))
>>
>>
>>
>> (insn 8 7 0 (set (reg:HI 19 [ d.1 ])
>>
>> (subreg:HI (reg:QI 18 [ c.0 ]) 0)) cnv.c:5 -1
>>
>>  (expr_list:REG_EQUAL (zero_extend:HI (reg:QI 18 [ c.0 ]))
>>
>> (nil)))
>>
>>
>>
>> (insn 9 8 0 (set (mem/c:HI (symbol_ref:HI ("d")  > d>) [0 d+0 S2 A16])
>>
>> (reg:HI 19 [ d.1 ])) cnv.c:5 -1
>>
>>  (nil))
>>
>>
>>
>> (insn 10 9 0 (set (reg:HI 20 [ D.1323 ])
>>
>> (mem/c:HI (symbol_ref:HI ("d")  ) [0
>> d+0 S2 A16])) cnv.c:6 -1
>>
>>  (nil))
>>
>> and  respective ASM
>>
>> ld  C, (c)
>> ld  B, 0
>> ld  (d), BC
>> ld  WA, (d)
>> ret
>>
>>
>> But problem arises when i enabled the optimisation -O3 ( with -da)  .
>>
>> RTL is expanded  as show above, but after subreg pass(*.subreg)   we
>> see the below RTL
>>
>>
>> (note 4 0 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
>>
>> (note 3 4 8 2 NOTE_INSN_FUNCTION_BEG)
>>
>> (insn 8 3 9 2 (set (mem/c:HI (symbol_ref:HI ("d")  > 0xb7356114 d>) [2 d+0 S2 A16])
>>
>> (reg:HI 19 [ d.1 ])) cnv.c:5 9 {*movhi}
>>
>>  (nil))
>>
>> (insn 9 8 13 2 (set (reg:HI 20 [  ])
>>
>> (reg:HI 19 [ d.1 ])) cnv.c:6 9 {*movhi}
>>
>>  (nil))
>>
>> (insn 13 9 16 2 (set (reg/i:HI 0 W)
>>
>> (reg:HI 20 [  ])) cnv.c:7 9 {*movhi}
>>
>>  (nil))
>>
>> (insn 16 13 0 2 (use (reg/i:HI 0 W)) cnv.c:7 -1
>>
>>  (nil))
>>
>> ;;  su
>>
>> and respective asm emited as
>>
>>
>> ld  C, (c)
>> ld  (d), BC ;This is invalid  since B can have a clobbered value
>> ld  WA, (d)
>> ret
>>
>> Would like know there exist any target hook to surpass the above
>> optimization so that i ended up emitting valid instructions.
>>
>> Any lights on the above problem is appreciated .
>
>
> You didn't say what target you are using, you didn't say what version
> of GCC you are using, and you didn't give enough information to
> understand what is happening.  I don't know what the "ld (d),BC"
> syntax means, but perhaps it means that two different registers, B and
> C, are combined to form a single value.  If that is true, then it
> appears that the subreg pass has dropped the insn setting
> pseudo-register 19.  I have no idea how that could happen; it suggests
> a bug in your backend port when handling a movqi of a subreg.
>
> Ian

Re: -Wformat-security warnings generated in gcc build

[Jakub Jelinek]

On Tue, Jan 21, 2014 at 09:09:25PM +0530, Prathamesh Kulkarni wrote:
> --- gcc/c/c-convert.c (revision 206867)
> +++ gcc/c/c-convert.c (working copy)
> @@ -79,7 +79,7 @@ convert (tree type, tree expr)
>if ((invalid_conv_diag
> = targetm.invalid_conversion (TREE_TYPE (expr), type)))
>  {
> -  error (invalid_conv_diag);
> +  error ("%s", invalid_conv_diag);

This looks wrong.  error/error_at/fatal_error and I think cpp_error
too mark the format string argument for translation (as in all these
cases the format string is actually a variable, not string literal,
that doesn't perform anything, supposedly the actual string literal
is marked with N_(...) earlier) and also the functions translate it using
gettext, which won't happen for the string passed to %s.
So I believe you actually need to use
  error ("%s", _(invalid_conv_diag));
etc. instead.  Of course not for the fprintf case.

Jakub

Re: -Wformat-security warnings generated in gcc build

[Joseph S. Myers]

On Tue, 21 Jan 2014, Prathamesh Kulkarni wrote:

> Souce of these warnings are typically calls to error() and friends.
> In  C and C++ front ends there are many calls of error (errmsg).
> errmsg is in many cases, assigned the return value of targetm hooks
> (tagetm.invalid_return_type(), etc.)  Is it correct to replace error
> (errmsg) by
> error ("%s", errmsg) in these cases ?

No.  Typically the message returned by the hook may contain no-arguments 
format specifiers such as %< and %>.  Instead, to avoid such warnings you 
need to add a new function error_at_no_args (location, message) that 
accepts and processes only formats taking no arguments (and probably 
aborts if given a format that needs arguments).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: -Wformat-security warnings generated in gcc build

[Florian Weimer]

On 01/21/2014 06:50 PM, Joseph S. Myers wrote:

On Tue, 21 Jan 2014, Prathamesh Kulkarni wrote:


Souce of these warnings are typically calls to error() and friends.
In  C and C++ front ends there are many calls of error (errmsg).
errmsg is in many cases, assigned the return value of targetm hooks
(tagetm.invalid_return_type(), etc.)  Is it correct to replace error
(errmsg) by
error ("%s", errmsg) in these cases ?


No.  Typically the message returned by the hook may contain no-arguments
format specifiers such as %< and %>.  Instead, to avoid such warnings you
need to add a new function error_at_no_args (location, message) that
accepts and processes only formats taking no arguments (and probably
aborts if given a format that needs arguments).


And printf format strings also can contain %% an %m (the latter is a GNU 
extension).  That's why we cannot perform the arg -> "%s", arg 
transformation unconditionally in the compiler, rendering 
-Wformat-security pointless.  Which is a bit disappointing.


--
Florian Weimer / Red Hat Product Security Team

clang and FSF's strategy

[Eric S. Raymond]

David Kastrup's recent question on emacs-devel motivates me to bring
up a larger related question I've been meaning to open for a while: Are the
FSF's goals best served by continuing to technically restrict GCC?

This is a question in which I have some positive stake.  Yes, I
continue to be opposed to the FSF's style of propaganda exactly
because I think it hinders an end goal - a software ecosystem that is
open-source and user-controlled - that I agree with and have worked
hard to achieve. On the other hand, I have always said that the FSF's
artifacts are its best artillery, and GCC is certainly one of the
biggest guns in that arsenal.

I want GCC to do what the FSF wants it to do - promote freedom and
openness, erode proprietary control, prevent vendor lock-in of
development toolchains. I think it is time to question whether the
anti-plugins policy is still the best way to accomplish this.

What gives this question point is the very existence of clang.  The
clang developers aren't shy about saying in public that they regard
the FSF's anti-plugin policy as obstructive and that this is a major
motivation for their work.  And they're making excellent progress;
clang is a production-quality tool today, not yet as mature as GCC but
with better features in some areas - its error messages, in particular
are *far* superior.

The clang developers very carefully do *not* say that they aim to make
GCC obsolete and relegate it to the dustbin of discarded tech.  But I
believe that is unmistakably among their goals, and I judge that they
are a credible threat to GCCs's dominance in the 3- to 5-year
timeframe.

It might be that my goals would actually be advanced if clang were to
kick GCC off the top of the heap.  That is, there is at least a
possible world in which a serious hit to FSF's prestige would decrease
its ability to hinder progress through PR I have made no secret of
considering ham-handed and counterproductive.

For the present I choose to ignore this possibility. It seems better
to me to promote as vigorous as possible a competitive race between 
GCC and clang, so that both will improve and the the aggregate position
of open-source toolchains will strengthen.

Therefore, I point out that FSF can no longer prevent proprietary
vendors from plugging into a free compiler to improve their tools.
That horse has left the barn; the strategic goal of the anti-plugin
policy has been definitively busted.

I also think it bears noticing that nobody outside of Microsoft seems
to particularly want to write proprietary compilers any more.  GCC won
its war; the cost and time-to-market advantages of hooking into
open-source toolchains are now so widely understood that new processor
designs support them as a matter of course.

Wouldn't it make sense, then, to entirely drop the factoring
restrictions from GCC so it can compete for developer attention more
effectively with clang?

Before clang existed, back when GCC had a near monopoly in its
competitive space, there might have been a functional case for those
restrictions. Reasonable people may differ on that; there's no point
in arguing it retrospectively. Now, I submit, they have become a pointless
gesture that serves only to hinder GCC development abd increase
clang's competitive advantage.

GCC has a lot of strengths to play from, most notably the maturity of
its multiplatform and cross-development support.  I urge the FSF to
fully free the code - drop the policy restrictions, encourage a
flourishing ecosystem of surrounding plugins.  Let GCC, clang, and
other alternatives compete for attention on pure technical merit.

I think the last fifteen years have demonstrated that in this sort of
competition, the proprietary vendors will eat dust if they try to
outcompete open-source tools on their own ground. Furthermore, they've
learned this the hard way, and are quite unlikely to try.  There are
less risky uses for their NRE.

In some sense I don't really care who wins.  Either GCC or clang
will serve my needs. I do prefer that both tools be as excellent
as possible.  And it would be nice if the FSF were to demonstrate that
it can recognize changed conditions and move with the times.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

There's a tendency today to absolve individuals of
moral responsibility and treat them as victims of
social circumstance.  You buy that, you pay with your
soul.
-Tom Robbins, Still Life with Woodpecker

RE: Automatic dependency file generation bug/question

[ANDY KENNEDY]

Ping (with one correction).

> -Original Message-
> From: ANDY KENNEDY
> Sent: Wednesday, January 15, 2014 3:16 PM
> To: 'gcc@gcc.gnu.org'
> Subject: Automatic dependency file generation bug/question
> 
> Reading , I find that
> dependency files should be created along the lines of
> 
> %.o:  %.c ...
> 
> In gcc version 4.4.4 (Slackware64 Linux version 13.0), I execute the
> following commands:
> 
> touch a.c
> gcc -c -MMD -MP -MF"a.d" -MT"a.d" -o "a.o" "a.c"
> cat a.d
> 
> and get the following output:
> 
> a.d a.o: a.c
> 
> which is precisely what I want.  However, I have a cross compiler using
> gcc version 4.7.3 which produces the following output using the same
> commands (obviously, with gcc replace with /bin/gcc:
> 
> a.d: a.c
> 
> I have been looking for the reason for the change, but am unable to find
> the rational.
> 
> Please advise whether this is a bug, or if this is meant to be the way
> gcc will work for all future releases.  As I see it, this complicates my
> Makefile(s) as I have two gcc version that behave differently.  This
> implies that my Makefile(s) will now require a section specifically
> dedicated to the .d file generation.  Whereas I remember that this used
> to be the way I had to construct the dependency list, this was
> cumbersome and the way e.g. 4.4.4 supported automatic dependency
> generation is preferable to me.
> 
> Thank you for your time,
> Andy

Re: clang and FSF's strategy

[David Kastrup]

e...@thyrsus.com (Eric S. Raymond) writes:

> David Kastrup's recent question on emacs-devel motivates me to bring
> up a larger related question I've been meaning to open for a while:
> Are the FSF's goals best served by continuing to technically restrict
> GCC?

I don't think that's even a sensible question.  The point of the GPL is
to promote expansion of Free Software, and the tool it uses for doing so
is by covering licensing of "the work as a whole".  When providing full
technical capabilities for accessing the functionality of of program
without creating a larger whole in the process, we are basically down to
the LGPL.

So most definitely the FSF's goals are best served by continuing to
technically restrict GCC.  If there is any question, the question is
rather _what_ restrictions serve its interests more than it impedes
them.  Since any lifted restrictions cannot easily be reinstated, it
makes sense to be conservative.

> This is a question in which I have some positive stake.  Yes, I
> continue to be opposed to the FSF's style of propaganda exactly
> because I think it hinders an end goal - a software ecosystem that is
> open-source and user-controlled - that I agree with and have worked
> hard to achieve.

You are crossposting to two public project lists of the GNU project with
inflammatory language and mischaracterizations.  You have been involved
with the GNU project long enough to be well aware that this kind of
crowbar approach does not lead to much more than headlines about Free
Software infighting.

> The clang developers very carefully do *not* say that they aim to make
> GCC obsolete and relegate it to the dustbin of discarded tech.

Like most Free Software, GCC started out in a state where its technical
competitiveness placed it in the dustbin.  And that's a state the GNU
project prefers over that of it being an enabling and seminal part of
proprietary software "ecosystems".  That's the reason GNU software is
licensed under copyleft rather than permissive licenses, and the
criterion of popularity should not render that choice irrelevant.

There is leeway for making and balancing individual decisions according
to individual tradeoffs.

Your black-and-white and all-or-nothing rhetoric and confrontational
style is not helpful for that.

> Therefore, I point out that FSF can no longer prevent proprietary
> vendors from plugging into a free compiler to improve their tools.

And we could not prevent proprietary vendors from plugging into
proprietary compilers to improve their tools, either.  And things like
Microsoft Visual C++ and the Intel compilers are quite competitive in
technical respects.  The only thing we ever have been able to prevent
people to do is them plugging into _our_ free compiler.

> That horse has left the barn;

Lots of horses have left the barn.  That's irrelevant as long as it is
not the horse we are sitting on.

> I also think it bears noticing that nobody outside of Microsoft seems
> to particularly want to write proprietary compilers any more.

Huh?  Intel still writes proprietary compilers, basically every GPU
vendor boosts his own proprietary compiler.

> In some sense I don't really care who wins.  Either GCC or clang will
> serve my needs. I do prefer that both tools be as excellent as
> possible.  And it would be nice if the FSF were to demonstrate that it
> can recognize changed conditions and move with the times.

The whole point of the FSF was _not_ to "move with the times".  If you
would be willing to forego your popularity contest based approach, you
might have a better chance of getting actual adjustments in the details.

But at the core level, I see a fundamental miscomprehension about the
contexts in which strong copyleft and the GNU project operate and make
sense.  As long as you don't come to terms with that, I don't see this
discussion leading anywhere.  And that's not even taking into account
that key players tend to be less than amused about such a
confrontational approach.

-- 
David Kastrup

Re: clang and FSF's strategy

[Alexandre Oliva]

On Jan 21, 2014, e...@thyrsus.com (Eric S. Raymond) wrote:

> I think it is time to question whether the anti-plugins policy is
> still the best way to accomplish this.

Err...  Excuse me, but what anti-plugins policy are you talking about?

The runtime license exception designed to make room for GCC plugins
without endangering its copyleft is almost 5 years old!

Did you feel so aligned with clang's FSF-disparaging propaganda that you
failed to check the facts, or are you being intentionally specious?


That GCC plugin interface is not sufficiently stable for major
uncoordinated developments by third-parties is just as true as that
Linux's module interface is constantly changing, and complaints about
its lack of stability in it are often responded with such phrases as
“contribute your driver and we'll even help you keep it up-to-date”.

If you were to applaud one while voicing objections to the other,
someone might even get the idea you're using double standards ;-)

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist Red Hat Brazil Toolchain Engineer

Re: clang and FSF's strategy

[Stefan Monnier]

> up a larger related question I've been meaning to open for a while: Are the
> FSF's goals best served by continuing to technically restrict GCC?

Let me repeat: please stop discussing such things on this list.
There are things like gnu.misc.discuss for that.


Stefan

Re: clang and FSF's strategy

[Ian Lance Taylor]

On Tue, Jan 21, 2014 at 12:19 PM, Eric S. Raymond  wrote:
>
> Wouldn't it make sense, then, to entirely drop the factoring
> restrictions from GCC so it can compete for developer attention more
> effectively with clang?
>
> Before clang existed, back when GCC had a near monopoly in its
> competitive space, there might have been a functional case for those
> restrictions. Reasonable people may differ on that; there's no point
> in arguing it retrospectively. Now, I submit, they have become a pointless
> gesture that serves only to hinder GCC development abd increase
> clang's competitive advantage.
>
> GCC has a lot of strengths to play from, most notably the maturity of
> its multiplatform and cross-development support.  I urge the FSF to
> fully free the code - drop the policy restrictions, encourage a
> flourishing ecosystem of surrounding plugins.  Let GCC, clang, and
> other alternatives compete for attention on pure technical merit.

I'm sympathetic to our comments regarding GCC vs. clang.  But I'm not
sure I grasp your proposed solution.  GCC does support plugins, and
has supported them for a few releases now.

GCC plugins have what turns out to be a significant defect: the plugin
interface simply exposes GCC internals, and as such is not stable
across releases.  I pushed for plugins in GCC, and I thought this
unstable interface would be OK, but I was wrong.  For general plugins
to be useful, we need a more stable interface.

But that is a technical issue, not a licensing issue.  You are talking
about licensing issues.  Do you think the licensing requirements on
plugins are too onerous?

Because of the non-standard interface, the most effective way for
people to write plugins for GCC today is to use something like MELT
(http://gcc-melt.org) or the GCC Python plugin
(https://fedorahosted.org/gcc-python-plugin/).  These provide a
somewhat more standard interface across releases.

Ideally we would develop a standard interface for C as well.  There
have been some efforts along those lines but as far as I know none of
them have been committed to the tree.

Ian

Re: clang and FSF's strategy

[Eric S. Raymond]

Ian Lance Taylor :
> I'm sympathetic to our comments regarding GCC vs. clang.  But I'm not
> sure I grasp your proposed solution.  GCC does support plugins, and
> has supported them for a few releases now.

Then I don't understand why David Kastrup's question was even controversial.

If I have failed to understand the background facts, I apologize and welcome
being corrected.

I hope you (and others) understand that I welcome chances to help the FSF's
projects when I believe doing so serves the hacker community as a whole. The
fact that I am currently working full-time on cleaning up the Emacs repoaitory
for full git conversion is only one instance of this.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond