Configure mistakenly thinks that clang doesn't support __attribute__((...))

[p5pRT]

Migrated from rt.perl.org#111090 (status was 'open')

Searchable as RT111090$

[p5pRT]

From @nwc10

When I Configure Perl with clang as the compiler, Configure thinks​:

$ grep d_attribute config.sh
d_attribute_deprecated='undef'
d_attribute_format='undef'
d_attribute_malloc='undef'
d_attribute_nonnull='undef'
d_attribute_noreturn='undef'
d_attribute_pure='undef'
d_attribute_unused='undef'
d_attribute_warn_unused_result='undef'

This isn't actually true. The tests are of the form​:

echo "Checking whether your compiler can handle __attribute__((unused)) ..." >&4
$cat >attrib.c <<'EOCP'
#include <stdio.h>
int do_something( int dummy __attribute__((unused)), int n );
EOCP
if $cc $ccflags -c attrib.c >attrib.out 2>&1 ; then
  if $contains 'warning' attrib.out >/dev/null 2>&1; then
  echo "Your C compiler doesn't support __attribute__((unused))."
  val="$undef"

so if any warnings are spotted, it's assumed that it's a bad plan. The
problem is, that the compiler flags *by default* have warnings - if I hack
Configure to sspit out "attrib.out" above, it's 1 line​:

clang​: warning​: argument unused during compilation​: '-I /opt/local/include'

/opt/local/include exists and contains headers that might be useful soon.
So we don't want drop it. But I'm not quite sure what the right fix is here.

I *think* we might need to capture the output with and without the
__attribute__((...)), diff the two, and look for 'warning' in the extra lines.
But is diff available to Configure?

Is this over-engineering?

But it would be rather useful to fix this detection somehow (without getting
it wrong) because right now clang is issuing spurious warnings that wouldn't
be there if we got it right, and these are distracting us from real warnings.

Nicholas Clark

[p5pRT]

From @doughera88

On Sun, 19 Feb 2012, Nicholas Clark wrote​:

When I Configure Perl with clang as the compiler, Configure thinks​:

[ attributes are undefined because the compiler spits out unrelated
warnings. ]

I *think* we might need to capture the output with and without the
__attribute__((...)), diff the two, and look for 'warning' in the extra lines.
But is diff available to Configure?

Currently, Configure doesn't test for diff; the usual idiom is to use cmp
instead. I imagine that it would be fairly easy to add diff detection,
but . . .

Is this over-engineering?

Yes, I think so. Some time ago, for a variety of reasons, we started
moving this stuff away from Configure and into perl.h. I'd try adding the
appropriate __clang__ (or whatever) defines to perl.h starting around line
2770 and see how far that gets you.

--
  Andy Dougherty doughera@​lafayette.edu

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[doughera88]

This problem has gone away for clang (tested with clang version 7.0.1-8 on perl v5.33.0-211-g43b79bef34) but is still present for clang++. clang++ emits a warning message:
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]