Re: Request for warnings on implicit bool to int conversions

[Franz Sirl]

Am 2012-03-28 00:43, schrieb mathog:

The C99 bool data type, and the similar type in C++, currently (v 4.5.2)
do not generate
warnings for any of these sorts of operations:

bool b;

b = 3;
b++;
b += 2;
if(b == 3)


The last one is PR 44077.

Franz

Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

Hello.

I see that binutils, GCC and GDB still use the Automake's 'cygnus' option
in some of their makefiles:

  $ grep_cygnus() {
  >   grep -r 'cygnus' . \
  >| perl -ne '/(^|[^@])cygnus($|(:!\.com\b))/ and print' \
  >| grep -v '^[^:]*/Makefile\.in:'; \
  > }

  $ (cd ~/src/binutils && grep_cygnus) # BINUTILS
  ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
  ./binutils/doc/Makefile.am:AUTOMAKE_OPTIONS = cygnus
  ./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus
  ./gas/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus

  $ (cd ~/src/gdb && grep_cygnus) # GDB
  ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
  ./etc/configure.info: AUTOMAKE_OPTIONS = cygnus
  ./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus

  $ (cd ~/src/gcc && grep_cygnus) # GCC
  ./zlib/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus

But this option is going to be deprecated in Automake 1.12.1 and removed in
Automake 1.13:

  

I just wanted to give you this head-up so that you won't be unpleasantly
surprised by the change.  Note that the actual removal of the 'cygnus'
option won't take place until Automake 1.13, which will at best be
released five or six months from now (and probably later than that).

Best regards,
  Stefano

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Joseph S. Myers]

On Wed, 28 Mar 2012, Stefano Lattarini wrote:

> But this option is going to be deprecated in Automake 1.12.1 and removed in
> Automake 1.13:
> 
>   

That page isn't very helpful since it doesn't give the non-deprecated way 
to achieve each part of the effect of "cygnus", if still desired (I think 
avoiding info documentation being built in the source directory, so that 
builds could use a non-writable source directory, may have been one part).  
Is there better transition documentation somewhere?

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

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

Hi Joseph, thanks for the feedback.

On 03/28/2012 01:24 PM, Joseph S. Myers wrote:
> On Wed, 28 Mar 2012, Stefano Lattarini wrote:
> 
>> But this option is going to be deprecated in Automake 1.12.1 and removed in
>> Automake 1.13:
>>
>>   
> 
> That page isn't very helpful since it doesn't give the non-deprecated way 
> to achieve each part of the effect of "cygnus" if still desired
>
By reading this:

  

you can see how to emulate part of the 'cygnus' effects by other means.

However, it's also clear that it won't be possible to 100% emulate the effect
of cygnus with other options/hacks; in particular the second, fourth and last
points there:

  - texinfo.tex is not required if a Texinfo source file is specified. The
assumption is that the file will be supplied, but in a place that
Automake cannot find. This assumption is an artifact of how Cygnus
packages are typically bundled.

  - Certain tools will be searched for in the build tree as well as in the
user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.

  - The check target doesn't depend on all.

will basically be impossible to emulate.

> (I think avoiding info documentation being built in the source directory,
> so that builds could use a non-writable source directory, may have been
> one part).
>
There is probably some hack to obtain this effect (it's tested in the testsuite
somewhere), but my opinion is that if you distribute the generated info files
you should also have them generated in the source directory, to avoid nasty
surprises (for a similar issue, involving yacc and lex, see automake bug#10852,
in particular messages 
and ).

> Is there better transition documentation somewhere?
>
Nope, but it would be a good idea to prepare it before starting to deprecate
the 'cygnus' option.  Maybe even for 1.12.  Thanks for the suggestion.

Regards,
  Stefano

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Joseph S. Myers]

On Wed, 28 Mar 2012, Stefano Lattarini wrote:

>   - texinfo.tex is not required if a Texinfo source file is specified. The
> assumption is that the file will be supplied, but in a place that
> Automake cannot find. This assumption is an artifact of how Cygnus
> packages are typically bundled.

texinfo.tex is in a known location, but only a single copy for GDB and 
binutils and a single copy for GCC rather than in each directory needing 
it.  Is the approach used (for example) in libquadmath/Makefile.am

TEXINFO_TEX   = ../gcc/doc/include/texinfo.tex

considered a suitable approach for this case?

>   - Certain tools will be searched for in the build tree as well as in the
> user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.

I did previously suggest removing the existing support for building and 
using these tools in-tree 
, but there was 
pushback on that.  I don't know, however, if it actually depends on 
anything built into automake.

>   - The check target doesn't depend on all.

I'm not aware of a need for that.

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

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 03/28/2012 02:29 PM, Joseph S. Myers wrote:
> On Wed, 28 Mar 2012, Stefano Lattarini wrote:
> 
>>   - texinfo.tex is not required if a Texinfo source file is specified. The
>> assumption is that the file will be supplied, but in a place that
>> Automake cannot find. This assumption is an artifact of how Cygnus
>> packages are typically bundled.
> 
> texinfo.tex is in a known location, but only a single copy for GDB and 
> binutils and a single copy for GCC rather than in each directory needing 
> it.
>
Which makes perfect sense.  So Automake should support this use case.

> Is the approach used (for example) in libquadmath/Makefile.am
> 
> TEXINFO_TEX   = ../gcc/doc/include/texinfo.tex
> 
> considered a suitable approach for this case?
>
This would seem the most sensible approach, yes.  Want to give it a try to
see whether it works in the GCC/GDB/Binutils tree? (What should be verified
particularly carefully is that the idiom works also in VPATH builds).

>>   - Certain tools will be searched for in the build tree as well as in the
>> user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.
> 
> I did previously suggest removing the existing support for building and 
> using these tools in-tree 
> , but there was 
> pushback on that.  I don't know, however, if it actually depends on 
> anything built into automake.
>
Hmm...  Couldn't the issues (if any) be worked around by explicitly
re-defining the $(EXPECT), $(RUNTEST), $(MAKEINFO) and $(TEXI2DVI)
variables in the relevant Makefiles so that they point to the bundled
tools?  E.g.,

  EXPECT = $(top_builddir)/../expect/expect

and so on.

>>   - The check target doesn't depend on all.
> 
> I'm not aware of a need for that.
> 
Glad to hear that.

Regards,
  Stefano

What fixed PR c/51527 "infinite recursion in 'convert_to_integer'"?

[Georg-Johann Lay]

With current trunk this PR has disappeared.

However, with current 4.7 branch I can still reproduce it.

So I wonder what/who fixed the problem -- maybe just as a side
effect of some other work -- and if the change is appropriate
to be back-ported to 4.7?

Thanks for hints; I am not familiar with the front end internals...

Johann



__int24 is a built-in type in avr backend.

Infinite recursion:
__int24 add24 (__int24 a) { return a + 0x1; }

Works:
__int24 add24 (__int24 a) { return a + 0x; }

Works:
__int24 add24 (__int24 a) { return a + (__int24) 0x1; }

Works:
__int24 add24 (__int24 a) { return a ^ 0x1; }

Re: The state of glibc libm

[Joseph S. Myers]

On Wed, 29 Feb 2012, Joseph S. Myers wrote:

> I've reviewed many (not yet all) of glibc's open "math" component bugs.  I 
> hope some actual summary information on what the current state of libm 
> looks like may be of interest to the people involved in the various past 
> discussions of better libm for GCC or glibc - and those interested in 
> fixing things, whether through patches to existing code, new 
> implementations or both.

Here is an update on this analysis 
, having now 
reviewed all the open "math" component bugs and fixed quite a few of them 
(and filed more bugs for issues found in the fixing process).  Any glibc 
libm bugs you know of that don't currently have an open bug filed in 
Bugzilla should be filed there.

> (a) Most libm functions are not correctly rounded - and do not make an 
> attempt at being correctly rounded.

Still present.

> (b) Where functions do make attempts at being correctly rounded 
> (especially the IBM Accurate Mathematical Library functions), they tend to 
> be sufficiently slow that the slowness attracts bug reports.  Again, this 
> would likely be addressed by new implementations that use careful error 
> bounds and information about worst cases to reduce the cost of being 
> correctly rounding.

Still present.

> (c) Various functions do not set errno correctly (many cases) or raise the 
> proper floating-point exceptions (a smaller number of cases - both 
> spurious exceptions where not permitted by ISO C, and failing to raise 
> required overflow/underflow exceptions).  In general this is a separate 
> bug for each function (filed as many separate bugs in glibc Bugzilla) and 
> can be fixed by a separate local patch for each function (adding a 
> testcase, of course - note that glibc's main libm-test.inc presently only 
> tests invalid and divide-by-zero exceptions, so if working on these error 
> handling issues it might be useful to extend it to cover other exceptions 
> as well as errno values).

Still present.  libm-test.inc now tests for overflow exceptions as well as 
invalid and divide-by-zero.

> (d) There are some specific bugs filed for functions such as nexttoward 
> whose results are precisely specified by ISO C; in general these should be 
> fixable by local patches.

Still present (some fixed, some other such bugs found).

> (e) Various functions, mainly IBM Accurate Mathematical Library ones, 
> produce wildly wrong results or crash in non-default rounding modes.  I 
> have a patch for exp pending review at 
>  and I expect 
> others can be fixed similarly.

Fixed.

> (f) Various trigonometrical functions are inaccurate on x86 and x86_64 
> (see glibc bug 13658 and recent discussions).

Fixed.

> (g) Bessel function implementations handle large inputs in different ways 
> to other functions, as I discuss at 
> .

Fixed.

> (h) Various complex functions have problems such as inaccuracy or wrong 
> branch cuts.

Some fixed, others still present (though I don't think there are any wrong 
branch cut issues after all).

> (i) Some real functions have particular issues (which should be fixable by 
> local changes short of new correctly rounded implementations):
> 
>   - erfc (my patch 
>  is pending 
> review).

Fixed.

>   - pow (bugs 369, 706, 2678, 3866).  The assembly implementations may 
> complicate fixing these issues, though it's probably possible to fix 
> only some bugs (in all relevant implementations, with plenty of 
> testcases) rather than a patch needing to fix both all issues and all 
> implementations at once.

Parts fixed, parts pending (bugs 706 and 13881).

>   - lgamma, in cases where the result is close to 0 and there is a lot of 
> cancellation in the present calculations.
> 
>   - tgamma, in cases of results of large magnitude (where the approach of 
> using exp (lgamma) leads to large errors).

Still present.  Some other issues with particular functions have also been 
found since then.

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

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[Michael Witten]

On Tue, 27 Mar 2012 19:20:52 -0700, Russ Allbery wrote:

> (For example, b++ could easily wrap, and unexpectedly fast
> depending on the size of bool on a platform.)

Actually, it would appear that a bool (or a _Bool) can't wrap
on increment, but it CAN wrap on decrement (and strangely,
when the operand is a bool, C++ not only deprecates the prefix
and postfix `++' operators, but also forbids the prefix and
postfix `--' operators; this is particularly strange given
that similar semantics are still to be had with the `+='
and `-=' compound assignments).  

I'm going to deal with the prefix operators rather than the
postfix operators, in order to concentrate on the value that
is newly assigned to the variable in question.

Firstly, the C++ standard is very explicit and concise.
According to C++11.5.3.2 "Increment and decrement":

  1 The operand of prefix ++ is modified by adding 1, or set to
true if it is bool (this use is deprecated). The operand
shall be a modifiable lvalue. The type of the operand shall
be an arithmetic type or a pointer to a completely-defined
object type. The result is the updated operand; it is an
lvalue, and it is a bit-field if the operand is a bit-field.
If x is not of type bool, the expression ++x is equivalent
to x+=1...

  2 The operand of prefix -- is modified by subtracting 1. The
operand shall not be of type bool. The requirements on the
operand of prefix -- and the properties of its result are
otherwise the same as those of prefix ++...

As for C99, indulge me for a moment.

According to C99.6.5.3.1 "Prefix increment and decrement operators":

...

  2 The value of the operand of the prefix ++ operator is
incremented. The result is the new value of the operand after
incrementation. The expression ++E is equivalent to (E+=1).
See the discussions of additive operators and compound
assignment for information on constraints, types, side
effects, and conversions and the effects of operations on
pointers.

...

and according to C99.6.5.16.2 "Compound Assignment":

...

  3 A compound assignment of the form E1 op= E2 differs from the
simple assignment expression E1 = E1 op (E2) only in that the
lvalue E1 is evaluated only once.


and according to C99.6.5.6 "Additive operators":

...

  2 For addition, either both operands shall have arithmetic
type, or one operand shall be a pointer to an object type
and the other shall have integer type. (Incrementing is
equivalent to adding 1.)

...

  4 If both operands have arithmetic type, the usual arithmetic
conversions are performed on them.

  5 The result of the binary + operator is the sum of the
operands.

...

and according to C99.6.2.5 "Types":

...

  6 ... The type _Bool and the unsigned integer types that correspond
to the standard signed integer types are the standard unsigned
integer types... The standard and extended unsigned integer types
are collectively called unsigned integer types.

...

 17 The type char, the signed and unsigned integer types, and the
enumerated types are collectively called integer types...

 18 Integer and floating types are collectively called arithmetic
types.


...

and according to C99.6.3.1.8 "Usual arithmetic conversions":

  1 ...

Otherwise, the integer promotions are performed on both
operands. Then the following rules are applied to the
promoted operands:

If both operands have the same type, then no further
conversion is needed.

...
...
...

and according to C99.6.3.1.1 "Boolean, characters, and integers"

 2  ... If an int can represent all values of the original
type, the value is converted to an int; otherwise, it is
converted to an unsigned int. These are called the integer
promotions...

and according to C99.6.3.1.2 "Boolean type":

  1 When any scalar value is converted to _Bool,
the result is 0 if the value compares equal
to 0; otherwise, the result is 1.

and according to C99.7.16 "Boolean type and values ":

  1 The header  defines four macros.

  2 The macro

bool

expands to _Bool.

...

So, the prefix `++' operator expression in the following:

  bool b = 1;
  ++b;

should assign to `b' the value of the following expression:

  (bool)((int)b + (int)1)
  (bool)((int)1 + (int)1)
  (bool)2
  1

That is, the value of `b' should remain `1', which is corroborated
when the following program:

  #include 
  int main(void)
  {
bool b = 1;
for (;;) ++b;
  }

is compiled with:

  gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c

thereby yield the following GIMPLE representation:

  main ()
  {
int D.1090;

{
  _Bool b;

  b = 1;
  :
  b = 1;
  goto ;
}
D.1090 = 0;
return D.1090;
  }

As you can see, the loop simply keeps assigning to `b' the value `1':

  :
  b = 1;

Re: status of GCC & C++

[Eric Botcazou]

> Really?  To start *writing* in C++, sure we want at least an initial
> version of the coding guidelines.  I pointed to those, because they
> look like a reasonable start.
>
> To start *building* in C++, I do not think we need to agree on the
> coding guidelines.  We are already doing stages 2 and 3, doing stage 1
> is a straightforward next step.

If we start building in C++, then this would mean that you can start to use
C++ in the code.  And we agreed to settle on a set of coding guidelines before 
starting to use C++ in the code.

Building stage 1 with a C++ compiler has zero value if you don't use C++ in 
the code.  It probably even has a negative value, since it gratuitously makes 
it harder to build the compiler on exotic platforms.

-- 
Eric Botcazou

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[mathog]

On 28-Mar-2012 12:18, Michael Witten wrote:

Wow, that was thorough!

The behavior of b++ vs. b-- was interesting, but is yet one more reason 
why the warning is needed.  Since
b-- is equivalent to !b, and b++ is equivalent to 1, if that action is 
intended, there is no reason to

use either the increment or decrement operators on a bool.


  gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c


That's a trick worth knowing. Thanks!
Ran that on a test program and in every case but one there was an 
implicit


   (int) b

on sections of code which I though should generate warnings.  (Math ops 
on bools, comparison operations of

bool with ints.) The one exception in that little program was:

  b=2;

which came out as

  b=1;

In that case the compiler must have performed an implicit

  1 = (bool) 2

Also these forms all generated implicit int conversions

  if(b==1)
  if(b==2)
  if(b==0)

whereas

  if(b)

did not.

So let's turn this around.  If the compiler warned on all implicit 
conversions of bool <-> int,
what program lines would it warn on that it shouldn't?  It would warn 
on:


  if(b==1)
  if(b==0)

but I would argue that line is inappropriate for a bool type, and 
should be written as:


  if(b)

With two bool variables, this also did not generate an implicit 
conversion (and so would not warn,

which is appropriate):

  if(b1 || b2)

Whereas this less preferred form would have generated an implicit (int) 
[and a well deserved warning]


  if(b1 + b2)

Regards,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[Michael Witten]

On Wed, Mar 28, 2012 at 20:30, mathog  wrote:

> Since b-- is equivalent to [assigning] !b,
> and b++ is equivalent to [assigning] 1, if
> that action is intended, there is no reason
> to use either the increment or decrement
> operators on a bool.

However, it seems to me that toggling the value with the idiom:

 --b;

is aesthetically preferable to the more elaborate:

  b = !b;

In fact, I've seen at least one person make this complaint in
freenode's ##c++ IRC channel.

Given the potential usefulness of `--b' and the relative uselessness
of `++b', it would seem more practical for the C++ standard to have
deprecated (if not allowed) `--b' and instead forbidden `++b' (rather
than the other way around).

Re: Request for warnings on implicit bool to int conversions

[Michael Witten]

On Wed, Mar 28, 2012 at 20:30, David Mathog wrote:

> ...
>
>>  gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c
>
>
> That's a trick worth knowing. Thanks!
> Ran that on a test program and in every case but one there was an implicit
>
>   (int) b
>
> on sections of code which I though should generate warnings.  (Math ops on
> bools, comparison operations of
> bool with ints.) The one exception in that little program was:
>
>  b=2;
>
> which came out as
>
>  b=1;
>
> In that case the compiler must have performed an implicit
>
>  1 = (bool) 2
>
> Also these forms all generated implicit int conversions
>
>  if(b==1)
>  if(b==2)
>  if(b==0)
>
> whereas
>
>  if(b)
>
> did not.
>
> So let's turn this around.  If the compiler warned on all implicit
> conversions of bool <-> int,
> what program lines would it warn on that it shouldn't?  It would warn on:
>
>  if(b==1)
>  if(b==0)
>
> but I would argue that line is inappropriate for a bool type, and should be
> written as:
>
>  if(b)
>
> With two bool variables, this also did not generate an implicit conversion
> (and so would not warn,
> which is appropriate):
>
>  if(b1 || b2)
>
> Whereas this less preferred form would have generated an implicit (int) [and
> a well deserved warning]
>
>  if(b1 + b2)


Your suggestion is probably a good idea, but as with all good ideas,
it will probably not get implemented because most people don't care.

Therefore, I'd suggest writing a patch and submitting it; people will
no doubt be a lot more receptive when you convey your thoughts in
hard-nosed, precise code, ESPECIALLY because that means the work has
already been done!

Sincerely,
Michael Witten

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[mathog]

On 28-Mar-2012 15:20, Michael Witten wrote:


However, it seems to me that toggling the value with the idiom:

 --b;

is aesthetically preferable to the more elaborate:

  b = !b;


Aesthetically, not logically.  Neither of these makes the least bit of 
sense:


   one less than False
   one less than True

A better solution for the aesthetics would have been (it is a bit late 
now) to implement the missing unary negation operator:


  !!b;  //T->F, F->T

That operator would save even more program characters for the other int 
types, where it would be equivalent to:


  (i==0 ? 1 : 0);


Regards,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Ian Lance Taylor]

Stefano Lattarini  writes:

>> (I think avoiding info documentation being built in the source directory,
>> so that builds could use a non-writable source directory, may have been
>> one part).
>>
> There is probably some hack to obtain this effect (it's tested in the 
> testsuite
> somewhere), but my opinion is that if you distribute the generated info files
> you should also have them generated in the source directory, to avoid nasty
> surprises (for a similar issue, involving yacc and lex, see automake 
> bug#10852,
> in particular messages 
> and ).

It's important that it be possible to build with the sources on a
read-only disk.

It's useful to be able to include .info files in releases so that people
can build the releases without having to have makeinfo installed.

Ian

Copyright assignment

[David Stone]

I would like to get a form to assign all future contributions to the FSF.

Re: Copyright assignment

[Ian Lance Taylor]

David Stone  writes:

> I would like to get a form to assign all future contributions to the FSF.

Sent off-list.

Ian

David Stone

[David Stone]

[What is the name of the program or package you're contributing to?]
GCC

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]
No. I have not yet made any contributions.

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]
No.

[For the copyright registration, what country are you a citizen of?]
USA

[What year were you born?]
1989

[Please write your email address here.]
da...@doublewise.net

[Please write your snail address here.]
13567 Raritan Way
Westminster CO, 80234
USA




[Which files have you changed so far, and which new files have you written
so far?]
None

[GCC Steering Committee] Android sub-port reviewer

[Maxim Kuvyrkov]

I volunteer as the reviewer for Android sub-port.

Android/Bionic support is an extension over Linux port and is being gradually 
added for more and more architectures.  I wrote the original Android GCC 
support for ARM (under a watchful design eye of Joseph Myers), and know how the 
bits fit together.

As adding Android support to a new architecture requires changes to that 
architecture, the architecture maintainer will have the power of veto for the 
Android-related changes.

Thank you,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics