Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

[Jeff Law]

On 6/13/19 10:46 AM, Tom Tromey wrote:
>> "Jeff" == Jeff Law  writes:
> 
> Jeff> I'd like to move C-alloca support to the ash heap of history.  But I'm
> Jeff> not sure we can realistically do that.
> 
> Are there still platforms or compilers in use where it's needed?
> 
> For gdb I was planning to just remove these calls.
Probably not that we care about for building gcc, gdb & friends.  I'd be
more hesitant to declare C-alloca dead in the more general sense.

jeff

gcc-7-20190613 is now available

[gccadmin]

Snapshot gcc-7-20190613 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190613/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 272273

You'll find:

 gcc-7-20190613.tar.xzComplete GCC

  SHA256=44f5ba530939996e3db9f8f9db85e0d9f0d21ab0a188b548afcb7c8ac8afe717
  SHA1=e1529efeac511676daec0bf75e447c8fa00c78b1

Diffs from 7-20190606 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Expanding roundeven (Was: Re: About GSOC.)

[Joseph Myers]

On Thu, 13 Jun 2019, Martin Jambor wrote:

> architecture supports it.  (and if IIUC, the intent is to use the 0 mode
> from table 4-8 in
> https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
> in instructions that take a rounding a mode to implement roundeven).

Note that the rounding mode argument to roundss / roundsd should end up as 
8, not 0, so that the inexact exception is not raised.  (8 here is the 
existing ROUND_NO_EXC definition in GCC.  A new definition will need 
adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to 
rounding to nearest with ties to even, evaluating to 0.)

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

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

[Martin Sebor]

On 6/13/19 10:46 AM, Tom Tromey wrote:

"Jeff" == Jeff Law  writes:


Jeff> I'd like to move C-alloca support to the ash heap of history.  But I'm
Jeff> not sure we can realistically do that.

Are there still platforms or compilers in use where it's needed?

For gdb I was planning to just remove these calls.


The only implementation I know about is Doug Gwyn's alloca.
A Google search returns a pointer to QNX CAR that documents it
with the following note:

 *  By default, alloca() is implemented as __builtin_alloca().
If you compile with the -fno-builtin option, you'll use
the libc version of alloca(), which is a cover for malloc()
and behaves in a slightly different manner:
-  It keeps track of all blocks allocated with alloca() and
   reclaims any that are found to be deeper in the stack than
   the current invocation. It therefore doesn't reclaim storage
   as soon as it becomes invalid, but it will do so eventually.
-  As a special case, alloca(0) reclaims storage without
   allocating any. You can use this feature to force garbage
   collection.

The implementation details aren't important.  What matters is
that to call the library implementation one has to prevent GCC
from treating alloca as a built-in and eliminating the zero size
calls.

When the function is not treated as a built-in no warnings for
calls to it are issued and so no problem for us to solve.

Martin

http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%2Fcom.qnx.doc.neutrino.lib_ref%2Ftopic%2Fa%2Falloca.html

Re: [PATCH] Deprecate ia64*-*-*

[Jim Wilson]

On Thu, Jun 13, 2019 at 10:39 AM Joel Sherrill  wrote:
> Ok with me if no one steps up and the downstream projects like Debian gets
> notice. This is just a reflection of this architecture's status in the
> world.

I sent email to the debian-ia64 list half an hour ago.  Just got a
response.  They mentioned that there is also a gentoo group that I
didn't know about, and want to know why exactly we want to deprecate
it.  I can discuss it with them.

Jim

Re: [PATCH] Deprecate ia64*-*-*

[Joel Sherrill]

Ok with me if no one steps up and the downstream projects like Debian gets
notice. This is just a reflection of this architecture's status in the
world.

--joel

On Thu, Jun 13, 2019, 4:13 AM Richard Biener  wrote:

>
> ia64 has no maintainer anymore so the following deprecates it
> with the goal of eliminating the port for GCC 11 if no maintainer
> steps up.
>
> OK?
>
> Thanks,
> Richard.
>
> 2019-06-13  Richard Biener  
>
> * config.gcc: Mark ia64*-*-* targets as deprecated/obsolete.
>
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc  (revision 272239)
> +++ gcc/config.gcc  (working copy)
> @@ -249,6 +249,7 @@ md_file=
>  case ${target} in
>spu*-*-* \
>| tile*-*-*  \
> +  | ia64*-*-*  \
>   )
>  if test "x$enable_obsolete" != xyes; then
>echo "*** Configuration ${target} is obsolete." >&2
>

Re: [PATCH] Deprecate ia64*-*-*

[Jim Wilson]

On Thu, 2019-06-13 at 09:09 -0600, Jeff Law wrote:
> On 6/13/19 5:13 AM, Richard Biener wrote:
> > 
> > ia64 has no maintainer anymore so the following deprecates it
> > with the goal of eliminating the port for GCC 11 if no maintainer
> > steps up.

OK with me since I'm not the maintainer anymore.

> Works for me.  James Clarke has been fixing small stuff recently, not
> sure if he wants to step into a larger role though.

There are 3 of them.  See
https://wiki.debian.org/Ports/ia64
It might be useful to send an email to the debian-ia64 list to notify
them.

> ia64 has been failing the qsort checking in the scheduler since the
> day
> that checking was introduced -- it shows up building the kernel IIRC.
> Nobody's shown any interest in addressing those issues :-)

I tried looking at this once.  It looked more difficult than I was
willing to do for IA-64.  There are so many checks in the qsort compare
functions that I don't think you can get a stable sort there.  I think
this is really a sel-sched problem not an IA-64 problem, but the IA-64
port is tied to sel-sched and may not work well without it.  Most other
ports aren't using it by default.

Jim

Re: Expanding roundeven (Was: Re: About GSOC.)

[Martin Jambor]

Hi Tejas,

On Thu, Jun 13 2019, Tejas Joshi wrote:
> Hello.
> As further part of implementing roundeven is inlining, I was studying
> machine descriptions and I have a few questions.
>
> As suggested, builtin functions provided a strong model for
> implementing roundeven. Keeping that in mind, I tried to inspect how
> similar functions (round/ceil) would get inlined. As it is dependent
> on target machine, (mine is i7, so should be x86_64 ? I wonder why
> gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
> itself as extended?),

Yes, the directory with x86_64 specific stuff is i386.

> should *.s file after compilation contain the
> specific instruction if supported? I was unable to see such kind of
> instruction on any -O level.
>

I am not sure I understand your question.  Yes, the intent is that when
the compiler cannot determine the argument of roundeven to be constant,
it should emit the instruction instead of a library call, if the target
architecture supports it.  (and if IIUC, the intent is to use the 0 mode
from table 4-8 in
https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
in instructions that take a rounding a mode to implement roundeven).

Of course the instruction is not present there, that is the next step in
your project :-)

> Different pattern names are available for machine descriptions
> , also for
> round, ceil, etc. Will I have to add such pattern name for roundeven?
> (is it the same as optab defined in optabs.def?)

Yes.

Martin

Re: Committing patches and other conventions (Was: Re: About GSOC)

[Martin Jambor]

Hi Tejas,

On Wed, Jun 12 2019, Tejas Joshi wrote:
> Hello.
> Is this the correct sequence for regression test:
> 1. Revert back all the changes I made and then configure, build along with
> make bootstrap
> make -k check
> collect the *.sum files
> 2. Apply the patch and do the configuration, build as above 1 and then
> collect the *.sum files and compare them.

Yes, exactly  (make sure to pass an appropriate -j parameter to make, of
course).

>
> How do I collect and inspect these *.sum files?

I collect *.sum files with a small script that internally simply does

  cp -vp `find . -name '*.sum' -print` $DEST_DIRECTORY

with different $DEST_DIR for pristine trunk and the patched version.

I admit I have my own script for comparing *.sum files but the usual way
is to use the compare_tests in the contrib directory, so for comparing
the old and new gcc.sum, you would do something like:

  ./src/contrib/compare_tests ../trunk/logs/gcc.sum logs/gcc.sum

with the directories matching your setup, of course.

Writing about scripts in contrib, you might also want to look at
check_GNU_style.sh and/or check_GNU_style.py.  They take a patch file as
they argument and check GNU style (things like two spaces after each
sentence, long lines, these tiny things where we still however try to be
consistent).  Of course, some of the errors given should be ignored,
in your case probably long lines in a *.def file.

Hope this helps,

Martin

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

[Tom Tromey]

> "Jeff" == Jeff Law  writes:

Jeff> I'd like to move C-alloca support to the ash heap of history.  But I'm
Jeff> not sure we can realistically do that.

Are there still platforms or compilers in use where it's needed?

For gdb I was planning to just remove these calls.

Tom

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

[Jakub Jelinek]

On Thu, Jun 13, 2019 at 03:59:33PM +, Michael Matz wrote:
> without running the risk of unlimited stack use.  But of course this would 
> promote a programming style that'd only work with our alloca (and not even 
> C-alloca), and we want to avoid that.  I thought it a cute idea, but was 
> carried away by the cuteness ;-)
> 
> I like the suggestion of setting (and carrying through the pipeline) the 
> TREE_NO_WARNING flag on an source 'alloca(0)'.

Ditto, though it would be nice one day to implement
TREE_NO_WARNING/gimple_no_warning_p as a bit indicating on the side
sets of disabled warnings rather than the current big hammer where
that bit disables all warnings.

Jakub

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

[Michael Matz]

Hi,

On Thu, 13 Jun 2019, Jeff Law wrote:

> > (In fact I think our builtin_alloca implementation could benefit when we 
> > added that behaviour as well; it's a natural wish to be able to free 
> > memory that you allocated).
> 
> Also note that simply sprinkling alloca(0) calls won't magically release
> memory.  In a stack implementation releasing happens when the frame is
> removed.  Doing something more complex than that seems unwise.

Yeah, on reconsideration I think I'm pedaling back on this suggestion 
(which really was to do something more complex).  We have the necessary 
support for this in GCC (for VLAs), and then we'd be able to support code 
like this:

  for () {
dostuff (alloca (size));
morestuff (alloca (size2));
alloca(0);   // free all allocas
  }

without running the risk of unlimited stack use.  But of course this would 
promote a programming style that'd only work with our alloca (and not even 
C-alloca), and we want to avoid that.  I thought it a cute idea, but was 
carried away by the cuteness ;-)

I like the suggestion of setting (and carrying through the pipeline) the 
TREE_NO_WARNING flag on an source 'alloca(0)'.


Ciao,
Michael.

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

[Jeff Law]

On 6/12/19 10:40 AM, Jakub Jelinek wrote:
> On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
>> But GCC doesn't support such an implementation, does it?
> 
> Why would that be relevant?  The warning would cause people to make portable
> code less portable (by removing the alloca (0) calls that were added there
> for portability reasons), or add hacks to work around the warning (whether
> #pragma GCC diagnostic or something else).  That is something we do not
> want people to do.
I'd like to move C-alloca support to the ash heap of history.  But I'm
not sure we can realistically do that.  Given that reality I think we
need to honor the intent of alloca(0).

I also understand Martin's point that not warning on it could easily
miss programming errors.

I wonder if we could set TREE_NOWARNING on the CALL_EXPR early in the
front-end of the argument is a constant 0 (before simplification,
folding, etc).

That way we'd be able to support alloca(0), but also capture cases where
0 flows into alloca via other mechansisms (which are likely programming
errors).

Jeff

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

[Jeff Law]

On 6/12/19 9:25 AM, Michael Matz wrote:
> Hi,
> 
> On Wed, 12 Jun 2019, Martin Sebor wrote:
> 
>>> Otherwise LGTM as the patch, but I'd like to hear from others whether 
>>> it is kosher to add such a special case to the warn_unused_result 
>>> attribute warning.  And if the agreement is yes, I think it should be 
>>> documented somewhere that alloca (0) will not warn even when the call 
>>> has such an attribute (probably in the description of 
>>> warn_unused_result attribute).
>>
>> I'm not very happy about adding another special case to alloca
>> (on top of not diagnosing zero allocation by -Walloc-zero).
>> There is no valid use case for the zero argument, whether or not
>> the return value is used.
> 
> That's the thing, there _is_ a valid use case for supplying a zero 
> argument and then the returned value should _not_ be used.  There are 
> alloca implementations that do something (freeing memory) when 
> called with a zero size, so some (older) programs contain such calls.  
> Warning on those calls for the unused results is exactly the wrong thing 
> to do, if anything if the result is used we'd have to warn.  (That's of 
> course non-standard, but so is alloca itself)  And just removing these 
> calls isn't correct either except if it's ensured to not use an alloca 
> implementation with that behaviour.
Agreed.  Removing those calls simply can't be right unless you're
dropping support for the old C-alloca implementations completely.

> 
> (In fact I think our builtin_alloca implementation could benefit when we 
> added that behaviour as well; it's a natural wish to be able to free 
> memory that you allocated).
But do we really want to cater to alloca more than we already are?  I'd
argue that programmers simply aren't capable of using alloca
appropriately :-)  That's based on seeing mis-uses exploited repeatedly
through the years.

Also note that simply sprinkling alloca(0) calls won't magically release
memory.  In a stack implementation releasing happens when the frame is
removed.  Doing something more complex than that seems unwise.

In a C implementation, allocations (or groups of allocations) carry
additional information -- specifically the stack pointer at the time the
object was allocated.   Deallocation of the areas only occurs at
subsequent calls to alloca when the current stack pointer is larger than
the saved stack pointer (or if you're on a PA, the opposite :-)

So something like this

for (...)  {
alloca (space);
}
alloca (0);

Won't release anything because the saved stack pointer for the
allocations in the loop is the same as the stack pointer at the point of
the alloca(0) call.

Where alloca(0) is useful is in something like this:

for (...) {
   somefunc ();
}

Where somefunc allocates space with alloca.  If you think about the
implementation details here, you'll realize that calls to alloca from
within somefunc called in this loop will all have the same stack
pointer.  Thus garbage will keep accumulating on the stack across
iterations of the loop.  To avoid that you put an alloca(0) in the loop
like this:

for (...) {
  somefunc ();
  alloca (0);
}

Now when we call alloca (0) the stack pointer will indicate that the
alloca calls that occurred within somefunc are all dead and thus the
alloca(0) will release memory.

Jeff

Re: [PATCH] Deprecate ia64*-*-*

[Jeff Law]

On 6/13/19 5:13 AM, Richard Biener wrote:
> 
> ia64 has no maintainer anymore so the following deprecates it
> with the goal of eliminating the port for GCC 11 if no maintainer
> steps up.
> 
> OK?
> 
> Thanks,
> Richard.
> 
> 2019-06-13  Richard Biener  
> 
>   * config.gcc: Mark ia64*-*-* targets as deprecated/obsolete.
Works for me.  James Clarke has been fixing small stuff recently, not
sure if he wants to step into a larger role though.

ia64 has been failing the qsort checking in the scheduler since the day
that checking was introduced -- it shows up building the kernel IIRC.
Nobody's shown any interest in addressing those issues :-)

jeff

Re: About GSOC.

[Tejas Joshi]

Hello.
As further part of implementing roundeven is inlining, I was studying
machine descriptions and I have a few questions.

As suggested, builtin functions provided a strong model for
implementing roundeven. Keeping that in mind, I tried to inspect how
similar functions (round/ceil) would get inlined. As it is dependent
on target machine, (mine is i7, so should be x86_64 ? I wonder why
gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
itself as extended?), should *.s file after compilation contain the
specific instruction if supported? I was unable to see such kind of
instruction on any -O level.

Different pattern names are available for machine descriptions
, also for
round, ceil, etc. Will I have to add such pattern name for roundeven?
(is it the same as optab defined in optabs.def?)

Thanks,
-Tejas


On Thu, 13 Jun 2019 at 00:27, Tejas Joshi  wrote:
>
> Hello.
>
> > I don't think you should have the unreachable "return false;" in is_even.
> > The last "else if" can just be "else".
>
> I don't think return false in is_even is unreachable. As per my
> understanding, when one else if is true in the else if ladder, all the
> subsequent "else ifs" including "else" are ignored. When REAL_EXP is
> less than SIGNIFICAND_BITS, but the number is odd, the inner "if" for
> even-odd will not return true in which case should return false. That
> case will ignore next "else if" and will reach return false.
>
> > Suppose REAL_EXP (r) > SIGNIFICAND_BITS.  Then the number is definitely
> > even, so you should return true, not false.
>
> for this condition, else if can be modified to just else and return true.
> PATCH:
>
> gcc/ChangeLog:
>
> 2019-06-12  Tejas Joshi  
>
> * builtins.c (mathfn_built_in_2): Added CASE_MATHFN for ROUNDEVEN.
> * builtins.def: Added function definitions for roundeven function
> variants.
> * fold-const-call.c (fold_const_call_ss): Added case for function
> call and fold_const_conversion call for roundeven function.
> * fold-const.c (negate_mathfn_p): Added case for roundeven function.
> (tree_call_nonnegative_warnv_p): Added case for roundeven function.
> (integer_valued_real_call_p): Added case for roundeven function.
> * real.c (is_even): New function. Returns true if real number is
> even, otherwise returns false.
> (is_halfway_below): New function. Returns true if real number is
> halfway between two integers, else return false.
> (real_roundeven): New function. Round real number to nearest
> integer, rounding halfway cases towards even.
> * real.h (real_value): Added descriptive comments.
> Added function declaration for roundeven function.
>
> gcc/testsuite/ChangeLog:
>
> 2019-06-12  Tejas Joshi  
>
> * gcc.dg/torture/builtin-round-roundeven.c: New test.
> * gcc.dg/torture/builtin-round-roundevenf128.c: New test.
>
>
>
> On Tue, 11 Jun 2019 at 01:56, Joseph Myers  wrote:
> >
> > On Sun, 9 Jun 2019, Tejas Joshi wrote:
> >
> > > Hello.
> > > I have created another patch which addresses the above points,
> > > attached herewith.
> >
> > I don't think you should have the unreachable "return false;" in is_even.
> > The last "else if" can just be "else".
> >
> > > > a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> > > > least significant bit has value 1 and the number must be an integer).
> > >
> > > The number is integer because of the whole word spaces is occupied by
> > > integer part?
> > > Also, why would the least significant bit will have value 1 if
> > > REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
> > > position (even or odd)?
> >
> > My understanding is that the significand is, as per the comments in
> > real.c, in the range [0.5, 1.0).  There are SIGNIFICAND_BITS bits.  The
> > bit above the most significant one has value 2^REAL_EXP.  The most
> > significant one has value 2^(REAL_EXP-1).  The least significant one has
> > value 2^(REAL_EXP-SIGNIFICAND_BITS).  If REAL_EXP == SIGNIFICAND_BITS,
> > that means the least significant bit has value 2^0 = 1, and there are no
> > bits with value 0.5 or below, so the number is an integer.
> >
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com

[PATCH] Deprecate ia64*-*-*

[Richard Biener]

ia64 has no maintainer anymore so the following deprecates it
with the goal of eliminating the port for GCC 11 if no maintainer
steps up.

OK?

Thanks,
Richard.

2019-06-13  Richard Biener  

* config.gcc: Mark ia64*-*-* targets as deprecated/obsolete.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 272239)
+++ gcc/config.gcc  (working copy)
@@ -249,6 +249,7 @@ md_file=
 case ${target} in
   spu*-*-* \
   | tile*-*-*  \
+  | ia64*-*-*  \
  )
 if test "x$enable_obsolete" != xyes; then
   echo "*** Configuration ${target} is obsolete." >&2

Re: gcc: -ftest-coverage and -auxbase

[Richard Biener]

On Wed, Jun 12, 2019 at 10:17 PM  wrote:
>
> When doing a build, we use a pipe between GCC and GAS.
> And because we wish to do some analysis of the assembly code,
> we do not use -pipe but instead do '-S -c -'.  And this has worked
> fine for many years.

Can you please show us complete command-lines here?  -S -c -
will only assemble (and require source from standard input
and produce output in -.s).

> I was recently looking into collecting some coverage information.
> To that end, I added --coverage to the invocation line.  And it slowed
> things down by more than an order of magnitude!
>
> Investigating, it appears that the problem is the writing of the GCNO
> files.
>
> We do our builds on a build cluster with a lot of parallelism.
> With the result that a dozen machines are each doing a bunch
> of writes to the file '-.gcno' in an NFS mounted directory.
>
> Rather than have a full, not incremental, build take 5-10 minutes,
> It takes 4 hours.  And rather than have each of several thousand
> compiles produce their own GCNO file, they all get overwritten...
>
> Grep'ing around, I found '-auxbase'.  If I correctly understand it,
> when compiling
>
> some/path/name.c
>
> into
>
> bin/some-product/some/path/name.o,
>
> I could simply say
>
> -auxbase $(@:%.o=%)
>
> The problem is that in common.opt, auxbase is marked RejectDriver.
>
> It looks like removing it would some my problem.  Anyone have a reason
> why removing that would be a bad idea?  Or have a different solution?
>
> Thanks.
>
> David