[gcc] Misc cleanup.

[gcc] Misc cleanup.

- Use TARGET_NACL instead of flag_control_integrity;
- Kill getenv calls used for debugging nacl-specific code;
- Remove few debug printings;

[Mark Seaborn, 2010-07-05 16:27:36]

All the NACL_TARGET changes look good to me -- that code I'm somewhat familiar
with.

http://codereview.chromium.org/2880018/diff/2001/3001
File gcc/gcc/cfgrtl.c (left):

http://codereview.chromium.org/2880018/diff/2001/3001#oldcode1072
gcc/gcc/cfgrtl.c:1072: if ((e->flags & EDGE_FALLTHRU) == 0) {
I don't know this part of the code, but do you want something stronger than a
printf here?

It looks like you want to assert that this block is not reachable.

[Mark Seaborn, 2010-07-05 16:30:15]

On 2010/07/05 16:27:36, Mark Seaborn wrote:
> http://codereview.chromium.org/2880018/diff/2001/3001#oldcode1072
> gcc/gcc/cfgrtl.c:1072: if ((e->flags & EDGE_FALLTHRU) == 0) {
> I don't know this part of the code, but do you want something stronger than a
> printf here?

Sorry, I'm an idiot.  You are removing this printf, which is obviously fine. 
Clearly I don't look at Rietveld-formatted diffs enough. :-)  LGTM.

Mark

[eaeltsin, 2010-07-05 16:31:21]

http://codereview.chromium.org/2880018/diff/2001/3001
File gcc/gcc/cfgrtl.c (left):

http://codereview.chromium.org/2880018/diff/2001/3001#oldcode1072
gcc/gcc/cfgrtl.c:1072: if ((e->flags & EDGE_FALLTHRU) == 0) {
The if () { printf } block was added by us for some debugging reasons (ss you
can see, if printing happens, then the subsequent assert always fail - so we
just wanted to visualize the assert).

Now I remove this, and cfgrtl.c becomes untouched by our patch.

On 2010/07/05 16:27:36, Mark Seaborn wrote:
> I don't know this part of the code, but do you want something stronger than a
> printf here?
> 
> It looks like you want to assert that this block is not reachable.

[pasko-google - do not use, 2010-07-05 19:21:32]

1. there is still flag_control_integrity remaining in gcc/opts.c and in
gcc/config/nacl.opt

2. there is a #define TARGET_NACL (flag_control_integrity) in nacl.h that must
be defined differently (also it must be defined to 0 in non-NaCl builds) //
probably better be done as part of a dedicated cleanup that repairs the non-NaCl
build in GCC

http://codereview.chromium.org/2880018/diff/2001/3003
File gcc/gcc/config/i386/i386.md (right):

http://codereview.chromium.org/2880018/diff/2001/3003#newcode9826
gcc/gcc/config/i386/i386.md:9826: [(call (mem:QI (unspec [(match_operand:DI 0
"register_operand" "r")] UNSPEC_NACLCALL))
I am curious, is it a style violation to hae a >80 chars line in a machine
description file?

[eaeltsin, 2010-07-06 08:43:51]

The idea was not to get rid of the flag_control_integrity flag completely. Of
course it is still mentioned in command line processing stuff...

http://codereview.chromium.org/2880018/diff/2001/3003
File gcc/gcc/config/i386/i386.md (right):

http://codereview.chromium.org/2880018/diff/2001/3003#newcode9826
gcc/gcc/config/i386/i386.md:9826: [(call (mem:QI (unspec [(match_operand:DI 0
"register_operand" "r")] UNSPEC_NACLCALL))
There are many.
However, I'm going to revise these instructions anyway.

On 2010/07/05 19:21:32, pasko wrote:
> I am curious, is it a style violation to hae a >80 chars line in a machine
> description file?