Fix chrome/arm build warnings.

Fix chrome/arm build warnings.

Set default warning suppression for PNaCL compiler (clang)
to match the existing clang suppressions.

BUG= https://code.google.com/p/nativeclient/issues/detail?id=3108

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=168069

[Sam Clegg, 2012-11-13 22:42:59]

This change is needed before I can commit the corresponding
change in NaCl:

http://codereview.chromium.org/11363175/

Michael, the change to qcms is needed since I am compiling
with GCC arm, rather then clang arm, and gcc doesn't seem
to define __has_attribute in the same way.  I think my change
has the same effect but applies (correctly) to all arm builds.  Do you have any
advice on how to regenerate the
patch file?

[Nico, 2012-11-13 22:53:49]

http://codereview.chromium.org/11360238/diff/1/build/common.gypi
File build/common.gypi (right):

http://codereview.chromium.org/11360238/diff/1/build/common.gypi#newcode1497
build/common.gypi:1497: # same warnings as we do for clang.
Which version of clang does pnacl use?

http://codereview.chromium.org/11360238/diff/1/third_party/qcms/src/transform.c
File third_party/qcms/src/transform.c (right):

http://codereview.chromium.org/11360238/diff/1/third_party/qcms/src/transform...
third_party/qcms/src/transform.c:1326: #if defined(__GNUC__) &&
!defined(__x86_64__) && !defined(__amd64__) && !defined(__arm__)
Instead of removing all the __has_attribute stuff, I'd keep that and be like

# if __has__atribute(__force_align…) || what you have.

I'd also do the two changes in two CLs, as they aren't related.

[Sam Clegg, 2012-11-13 23:24:46]

Regarding separating these changes, I will go ahead and do that.  I was
combining them since they are both required to
enable Werror on arm.

http://codereview.chromium.org/11360238/diff/1/build/common.gypi
File build/common.gypi (right):

http://codereview.chromium.org/11360238/diff/1/build/common.gypi#newcode1497
build/common.gypi:1497: # same warnings as we do for clang.
On 2012/11/13 22:53:49, Nico wrote:
> Which version of clang does pnacl use?

3.2.   I think they track upstream fairly closely.

http://codereview.chromium.org/11360238/diff/1/third_party/qcms/src/transform.c
File third_party/qcms/src/transform.c (right):

http://codereview.chromium.org/11360238/diff/1/third_party/qcms/src/transform...
third_party/qcms/src/transform.c:1326: #if defined(__GNUC__) &&
!defined(__x86_64__) && !defined(__amd64__) && !defined(__arm__)
On 2012/11/13 22:53:49, Nico wrote:
> Instead of removing all the __has_attribute stuff, I'd keep that and be like
> 
> # if __has__atribute(__force_align…) || what you have.
> 
> I'd also do the two changes in two CLs, as they aren't related.

You mean have __has_attribute() default to 0 when
building with non-clang?

It seems to me that the __has_attribute() stuff is clang
only.  What do we gain by including it rather the simple
single line patch?

[Nico, 2012-11-13 23:27:23]

http://codereview.chromium.org/11360238/diff/1/build/common.gypi
File build/common.gypi (right):

http://codereview.chromium.org/11360238/diff/1/build/common.gypi#newcode1497
build/common.gypi:1497: # same warnings as we do for clang.
On 2012/11/13 23:24:46, Sam Clegg wrote:
> On 2012/11/13 22:53:49, Nico wrote:
> > Which version of clang does pnacl use?
> 
> 3.2.   I think they track upstream fairly closely.
> 

3.2 isn't released yet. So this is different from the clang revision we use in
chromium (
http://commondatastorage.googleapis.com/chromium-browser-clang/index.html ), or
is their clang cut at the same revisions? How much of chromium's code has to be
buildable with nacl clang? What's their compiler update process?

[Nico, 2012-11-13 23:29:01]

http://codereview.chromium.org/11360238/diff/1/third_party/qcms/src/transform.c
File third_party/qcms/src/transform.c (right):

http://codereview.chromium.org/11360238/diff/1/third_party/qcms/src/transform...
third_party/qcms/src/transform.c:1326: #if defined(__GNUC__) &&
!defined(__x86_64__) && !defined(__amd64__) && !defined(__arm__)
On 2012/11/13 23:24:46, Sam Clegg wrote:
> On 2012/11/13 22:53:49, Nico wrote:
> > Instead of removing all the __has_attribute stuff, I'd keep that and be like
> > 
> > # if __has__atribute(__force_align…) || what you have.
> > 
> > I'd also do the two changes in two CLs, as they aren't related.
> 
> You mean have __has_attribute() default to 0 when
> building with non-clang?
> 
> It seems to me that the __has_attribute() stuff is clang
> only.  What do we gain by including it rather the simple
> single line patch?

It has the advantage that it asks the compiler if it knows about the attribute
(if the compiler supports that, which currently only clang does). Feels a bit
more future-proof.

[Sam Clegg, 2012-11-14 00:36:25]

On 2012/11/13 23:27:23, Nico wrote:
> http://codereview.chromium.org/11360238/diff/1/build/common.gypi
> File build/common.gypi (right):
> 
> http://codereview.chromium.org/11360238/diff/1/build/common.gypi#newcode1497
> build/common.gypi:1497: # same warnings as we do for clang.
> On 2012/11/13 23:24:46, Sam Clegg wrote:
> > On 2012/11/13 22:53:49, Nico wrote:
> > > Which version of clang does pnacl use?
> > 
> > 3.2.   I think they track upstream fairly closely.
> > 
> 
> 3.2 isn't released yet. So this is different from the clang revision we use in
> chromium (
> http://commondatastorage.googleapis.com/chromium-browser-clang/index.html ),
or
> is their clang cut at the same revisions? How much of chromium's code has to
be
> buildable with nacl clang? What's their compiler update process?

nacl clang only needs to be able to build certain parts of the
nacl IRT code.  I'm not sure exactly which sources are compiled
with clang and which with gcc-arm.  I don't know the clang update process
myself, you would need to talk to dschuff@chromium.org.

[Sam Clegg, 2012-11-14 00:36:53]

On 2012/11/13 23:29:01, Nico wrote:
>
http://codereview.chromium.org/11360238/diff/1/third_party/qcms/src/transform.c
> File third_party/qcms/src/transform.c (right):
> 
>
http://codereview.chromium.org/11360238/diff/1/third_party/qcms/src/transform...
> third_party/qcms/src/transform.c:1326: #if defined(__GNUC__) &&
> !defined(__x86_64__) && !defined(__amd64__) && !defined(__arm__)
> On 2012/11/13 23:24:46, Sam Clegg wrote:
> > On 2012/11/13 22:53:49, Nico wrote:
> > > Instead of removing all the __has_attribute stuff, I'd keep that and be
like
> > > 
> > > # if __has__atribute(__force_align…) || what you have.
> > > 
> > > I'd also do the two changes in two CLs, as they aren't related.
> > 
> > You mean have __has_attribute() default to 0 when
> > building with non-clang?
> > 
> > It seems to me that the __has_attribute() stuff is clang
> > only.  What do we gain by including it rather the simple
> > single line patch?
> 
> It has the advantage that it asks the compiler if it knows about the attribute
> (if the compiler supports that, which currently only clang does). Feels a bit
> more future-proof.

Ok. Will upload as separate change.

[Nico, 2012-11-15 18:50:44]

lgtm

[commit-bot: I haz the power, 2012-11-15 19:20:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sbc@chromium.org/11360238/5002

[commit-bot: I haz the power, 2012-11-15 23:28:45]

Change committed as 168069

[Mark Seaborn, 2012-11-15 23:33:27]

https://chromiumcodereview.appspot.com/11360238/diff/5002/build/common.gypi
File build/common.gypi (right):

https://chromiumcodereview.appspot.com/11360238/diff/5002/build/common.gypi#n...
build/common.gypi:1496: # pnacl uses the clang compiler so we need to supress
all the
Nit: 'suppress'