That light at the end of the tunnel?

[Eric S. Raymond]

That light at the end of the tunnel turned out to be an oncoming train.

Until recently I thought the conversion was near finished. I'd had
verified clean conversions across trunk and all branches, except for
one screwed-up branch that the management agreed we could discard.

I had some minor issues left with execute-permission propagation and how
to interpret mid-branch deletes  I solved the former and was working
on the latter.  I expected to converge on a final result well before
the end of the year, probably in August or September.

Then, as I reported here, my most recent test conversion produced
incorrect content on trunk.  That's very bad, because the sheer size
of the GCC repository makes bug forensics extremely slow. Just loading
the SVN dump file for examination in reposurgeon takes 4.5 hours; full
conversions are back up to 9 hours now.  The repository is growing
about as fast as my ability to find speed optimizations.

Then it got worse. I backed up to a commit that I remembered as
producing a clean conversion, and it didn't. This can only mean that
the reposurgeon changes I've been making to handle weird branch-copy
cases have been fighting each other.

For those of you late to the party, interpreting the operation
sequences in Subversion dump files is simple and produces results that
are easy to verify - except near branch copy operations. The way those
interact with each other and other operations is extremely murky.

There is *a* correct semantics defined by what the Subversion code
does.  But if any of the Subversion devs ever fully understood it,
they no longer do. The dump format was never documented by them. It is
only partly documented now because I reverse-engineered it.  But the
document I wrote has questions in it that the Subversion devs can't
answer.

It's not unusual for me to trip over a novel branch-copy-related
weirdness while converting a repo.  Normally the way I handle this is
by performing a bisection procedure to pin down the bad commit.  Then I:

(1) Truncate the dump to the shortest leading segment that
reproduces the problem.

(2) Perform a strip operation that replaces all content blobs with
unique small cookies that identify their source commit. Verify that it still
reproduces...

(3) Perform a topological reduce that drops out all uninteresting
commits, that is pure content changes not adjacent to any branch
copies or property changes. Verify that it still reproduces...

(4) Manually remove irrelevant branches with reposurgeon.
Verify that it still reproduces...

At this point I normally have a fairly small test repository (never,
previously, more than 200 or so commits) that reproduces
the issue. I watch conversions at increasing debug levels until I
figure out what is going on. Then I fix it and the reduced dump
becomes a new regression test.

In this way I make monotonic progress towards a dumpfile analyzer
that ever more closely emulates what the Subversion code is doing.
It's not anything like easy, and gets less so as the edge cases I'm
probing get more recondite.  But until now it worked.

The size of the GCC repository defeats this strategy. By back of the
envelope calculation, a single full bisection would take a minimum of
18 days.  Realistically it would probably be closer to a month.

That means that, under present assumptions, it's game over
and we've lost.  The GCC repo is just too large and weird.

My tools need to get a lot faster, like more than an order of
magnitude faster, before digging out of the bad situation the
conversion is now in will be practical.

Hardware improvements won't do that.  Nobody knows how to build a
machine that can crank a single process enough faster than 1.3GHz.
And the problem doesn't parallelize.

There is a software change that might do it.  I have been thinking
about translating reposurgeon from Python to Go. Preliminary
experiments with a Go version of repocutter show that it has a
40x speed advantage over the Python version.  I don't think I'll
get quite that much speedup on reposurgeon, but I'm pretty
optimistic agout getting enough speedup to make debugging the GCC
conversion tractable.  Even at half that, 9 hour test runs would
collapse to 13 minutes.

The problem with this plan is that a full move to Go will be very
difficult.  *Very* difficult.  As in, work time in an unknown and
possibly large number of months.

GCC management will have to make a decision about how patient
it is willing to be.  I am at this point not sure it wouldn't be
better to convert your existing tree state and go from there, jeeping
the Subversion history around for archival purposes
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

..every Man has a Property in his own Person. This no Body has any
Right to but himself.  The Labour of his Body, and the Work of his
Hands, we may say, are properly his.  The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the 

Re: [RFC] Induction variable candidates not sufficiently general

[Bin.Cheng]

On Tue, Jul 17, 2018 at 2:08 AM, Kelvin Nilsen  wrote:
> Thanks for looking at this for me.  In simplifying the test case for a bug 
> report, I've narrowed the "problem" to integer overflow considerations.  My 
> len variable is declared int, and the target has 64-bit pointers.  I'm 
> gathering that the "manual transformation" I quoted below is not considered 
> "equivalent" to the original source code due to different integer overflow 
> behaviors.  If I redeclare len to be unsigned long long, then I automatically 
> get the optimizations that I was originally expecting.
>
> I suppose this is really NOT a bug?
As your test case demonstrates, it is caused by wrapping unsigned int32.
>
> Is there a compiler optimization flag that allows the optimizer to ignore 
> array index integer overflow in considering legal optimizations?
I am not aware of one for unsigned integer, and I guess it won't be
introduced in the future either?

Thanks,
bin
>
>
>
> On 7/13/18 9:14 PM, Bin.Cheng wrote:
>> On Fri, Jul 13, 2018 at 6:04 AM, Kelvin Nilsen  
>> wrote:
>>> A somewhat old "issue report" pointed me to the code generated for a 4-fold 
>>> manually unrolled version of the following loop:
>>>
   while (++len != len_limit) /* this is loop */
   if (pb[len] != cur[len])
   break;
>>>
>>> As unrolled, the loop appears as:
>>>
 while (++len != len_limit) /* this is loop */ {
   if (pb[len] != cur[len])
 break;
   if (++len == len_limit)  /* unrolled 2nd iteration */
 break;
   if (pb[len] != cur[len])
 break;
   if (++len == len_limit)  /* unrolled 3rd iteration */
 break;
   if (pb[len] != cur[len])
 break;
   if (++len == len_limit)  /* unrolled 4th iteration */
 break;
   if (pb[len] != cur[len])
 break;
 }
>>>
>>> In examining the behavior of tree-ssa-loop-ivopts.c, I've discovered the 
>>> only induction variable candidates that are being considered are all forms 
>>> of the len variable.  We are not considering any induction variables to 
>>> represent the address expressions [len] and [len].
>>>
>>> I rewrote the source code for this loop to make the addressing expressions 
>>> more explicit, as in the following:
>>>
   cur++;
   while (++pb != last_pb) /* this is loop */ {
   if (*pb != *cur)
 break;
   ++cur;
   if (++pb == last_pb)  /* unrolled 2nd iteration */
 break;
   if (*pb != *cur)
 break;
   ++cur;
   if (++pb == last_pb)  /* unrolled 3rd iteration */
 break;
   if (*pb != *cur)
 break;
   ++cur;
   if (++pb == last_pb)  /* unrolled 4th iteration */
 break;
   if (*pb != *cur)
 break;
   ++cur;
   }
>>>
>>> Now, gcc does a better job of identifying the "address expression induction 
>>> variables".  This version of the loop runs about 10% faster than the 
>>> original on my target architecture.
>>>
>>> This would seem to be a textbook pattern for the induction variable 
>>> analysis.  Does anyone have any thoughts on the best way to add these 
>>> candidates to the set of induction variables that are considered by 
>>> tree-ssa-loop-ivopts.c?
>>>
>>> Thanks in advance for any suggestions.
>>>
>> Hi,
>> Could you please file a bug with your original slow test code
>> attached?  I tried to construct meaningful test case from your code
>> snippet but not successful.  There is difference in generated
>> assembly, but it's not that fundamental.  So a bug with preprocessed
>> test would be high appreciated.
>> I think there are two potential issues in cost computation for such
>> case: invariant expression and iv uses outside of loop handled as
>> inside uses.
>>
>> Thanks,
>> bin
>>
>>

[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||um at mutluit dot com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=68264,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=68356

--- Comment #3 from Eric Gallager  ---
(In reply to Oleg Endo from comment #2)
> (In reply to Kazumoto Kojima from comment #1)
> > (In reply to Oleg Endo from comment #0)
> > > Kaz, do you know what's going wrong there?  Some silent wrong code related
> > > to fenv maybe?
> > 
> > Maybe, though I have no idea for what is going on.
> > You can see that those tests fail on several other targets:
> > 
> > powerpc-ibm-aix7.1.0.0
> > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00925.html
> > x86_64-unknown-freebsd9.3
> > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00932.html
> > i386-unknown-freebsd10.3
> > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00919.html
> 
> Oh, good to know.  Thanks for checking.  Probably we can close this PR as
> "invalid" after a while...

U.Mutlu says it still fails here:
https://gcc.gnu.org/ml/gcc-help/2018-07/msg00179.html

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[bugzilla-gcc at thewrittenword dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919

--- Comment #35 from The Written Word  
---
I am trying to build 4.9.4 with a patched 4.7.4 and am running into the
following failure:
/opt/build/china/gcc-4.9.4/.obj/./gcc/xgcc
-B/opt/build/china/gcc-4.9.4/.obj/./gcc/
-B/opt/build/gcc49/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc49/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc49/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc49/ia64-hp-hpux11.31/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
 -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-I. -I. -I../.././gcc -I/opt/build/china/gcc-4.9.4/libgcc
-I/opt/build/china/gcc-4.9.4/libgcc/.
-I/opt/build/china/gcc-4.9.4/libgcc/../gcc
-I/opt/build/china/gcc-4.9.4/libgcc/../include  -DHAVE_CC_TLS  -o emutls.o -MT
emutls.o -MD -MP -MF emutls.dep -fexceptions -c
/opt/build/china/gcc-4.9.4/libgcc/emutls.c -fvisibility=hidden -DHIDE_EXPORTS
/opt/build/china/gcc-4.9.4/libgcc/emutls.c: In function '__emutls_get_address':
/opt/build/china/gcc-4.9.4/libgcc/emutls.c:188:1: internal compiler error: in
simplify_subreg, at simplify-rtx.c:5917
 }
 ^

Should I build this with -O0 as well?

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Martin Sebor]

On 07/20/2018 03:11 PM, Bernd Edlinger wrote:

I think I have found a valid test case where the latest patch
does generate invalid code:


This is due to another bug in string_constant() that's latent
on trunk but that's exposed by the patch.  Trunk only "works"
because of a bug/limitation in c_strlen() that the patch fixes
or removes.

The underlying root cause is the handling of POINTER_PLUS
expressions in string_constant().  The original code (before
the handling of aggregates was added) just dealt with string
constants.  The new code does much more but doesn't get it
quite right in these cases.

It shouldn't be too difficult to fix, but as valuable as
the testing you are doing is, I'd really prefer to focus
on one problem at a time and make incremental progress.
It will make it easier to track down and fix regressions
than lumping multiple fixes into a larger patch.

Martin



$ cat part.c
static const char a[3][8] = { "1234", "12345", "123456" };

int main ()
{
   volatile int i = 1;
   int n = __builtin_strlen (*([1]+i));

   if (n != 6)
 __builtin_abort ();
}
$ gcc part.c -fdump-tree-original
$ ./a.out
Aborted (core dumped)
$ cat part.c.004t.original

;; Function main (null)
;; enabled by -tree-original


{
   volatile int i = 1;
   int n = (ssizetype) (SAVE_EXPR <(long unsigned int) i * 8>) <= 5 ? (int) (5 - 
(unsigned int) (SAVE_EXPR <(long unsigned int) i * 8>)) : 0;

 volatile int i = 1;
 int n = (ssizetype) (SAVE_EXPR <(long unsigned int) i * 8>) <= 5 ? (int) (5 - 
(unsigned int) (SAVE_EXPR <(long unsigned int) i * 8>)) : 0;
   if (n != 6)
 {
   __builtin_abort ();
 }
}
return 0;


string_constant is called with arg = (const char *) ([1] + (sizetype) ((long 
unsigned int) i * 8))

Re: Repo conversion troubles.

[Eric S. Raymond]

Joseph Myers :
> On Mon, 9 Jul 2018, Alexandre Oliva wrote:
> 
> > On Jul  9, 2018, Jeff Law  wrote:
> > 
> > > On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
> > >> Jeff Law :
> > >>> I'm not aware of any such merges, but any that occurred most likely
> > >>> happened after mid-April when the trunk was re-opened for development.
> > 
> > >> I'm pretty certain things were still good at r256000.  I've started that
> > >> check running.  Not expecting results in less than twelve hours.
> > 
> > > r256000 would be roughly Christmas 2017.
> > 
> > When was the RAID/LVM disk corruption incident?  Could it possibly have
> > left any of our svn repo metadata in a corrupted way that confuses
> > reposurgeon, and that leads to such huge differences?
> 
> That was 14/15 Aug 2017, and all the SVN revision data up to r251080 were 
> restored from backup within 24 hours or so.  I found no signs of damage to 
> revisions from the 24 hours or so between r251080 and the time of the 
> corruption when I examined diffs for all those revisions by hand at that 
> time.

Agreed. I don't think that incident is at the root of the problems.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Repo conversion troubles.

[Eric S. Raymond]

Joseph Myers :
> On Mon, 9 Jul 2018, Eric S. Raymond wrote:
> 
> > Richard Biener :
> > > 12 hours from remote I guess? The subversion repository is available 
> > > through rsync so you can create a local mirror to work from (we've been 
> > > doing that at suse for years) 
> > 
> > I'm saying I see rsync plus local checkout take 10-12 hours.  I asked Jason
> > about this and his response was basically "Well...we don't do that often."
> 
> Isn't that a local checkout *of top-level of the repository*, i.e. 
> checking out all branches and tags?  Which is indeed something developers 
> would never normally do - they'd just check out the particular branches 
> they're working on.

It is.  I have to check out all tags and branches to validate the conversion.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Good news, bad news on the repository conversion

[Eric S. Raymond]

Joseph Myers :
> I don't see any commits at 
> git://thyrsus.com/repositories/gcc-conversion.git since January.  Are 
> there further changes that haven't been pushed there?  (For example, I 
> sent a few additions to the author map on 13 Feb.)

Yes, that copy is rather stale. I need toi do some annoying sysdamin stuff
on the downstairs mmachine to get it live again.

Anything you sent me by email is merged into the live repo here on the Beast.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: O2 Agressive Optimisation by GCC

[Allan Sandfeld Jensen]

On Samstag, 21. Juli 2018 00:21:48 CEST Jonathan Wakely wrote:
> On Fri, 20 Jul 2018 at 23:06, Allan Sandfeld Jensen wrote:
> > On Freitag, 20. Juli 2018 14:19:12 CEST Umesh Kalappa wrote:
> > > Hi All ,
> > > 
> > > We are looking at the C sample i.e
> > > 
> > > extern int i,j;
> > > 
> > > int test()
> > > {
> > > while(1)
> > > {   i++;
> > > 
> > > j=20;
> > > 
> > > }
> > > return 0;
> > > }
> > > 
> > > command used :(gcc 8.1.0)
> > > gcc -S test.c -O2
> > > 
> > > the generated asm for x86
> > > 
> > > .L2:
> > > jmp .L2
> > > 
> > > we understand that,the infinite loop is not  deterministic ,compiler
> > > is free to treat as that as UB and do aggressive optimization ,but we
> > > need keep the side effects like j=20 untouched by optimization .
> > > 
> > > Please note that using the volatile qualifier for i and j  or empty
> > > asm("") in the while loop,will stop the optimizer ,but we don't want
> > > do  that.
> > 
> > But you need to do that! If you want changes to a variable to be
> > observable in another thread, you need to use either volatile,
> 
> No, volatile doesn't work for that.
> 
It does, but you shouldn't use for that due to many other reasons (though the 
linux kernel still does) But if the guy wants to code primitive without using 
system calls or atomics, he might as well go traditional

'Allan

Re: O2 Agressive Optimisation by GCC

[Jonathan Wakely]

On Fri, 20 Jul 2018 at 23:06, Allan Sandfeld Jensen wrote:
>
> On Freitag, 20. Juli 2018 14:19:12 CEST Umesh Kalappa wrote:
> > Hi All ,
> >
> > We are looking at the C sample i.e
> >
> > extern int i,j;
> >
> > int test()
> > {
> > while(1)
> > {   i++;
> > j=20;
> > }
> > return 0;
> > }
> >
> > command used :(gcc 8.1.0)
> > gcc -S test.c -O2
> >
> > the generated asm for x86
> >
> > .L2:
> > jmp .L2
> >
> > we understand that,the infinite loop is not  deterministic ,compiler
> > is free to treat as that as UB and do aggressive optimization ,but we
> > need keep the side effects like j=20 untouched by optimization .
> >
> > Please note that using the volatile qualifier for i and j  or empty
> > asm("") in the while loop,will stop the optimizer ,but we don't want
> > do  that.
> >
> But you need to do that! If you want changes to a variable to be observable in
> another thread, you need to use either volatile,

No, volatile doesn't work for that.

http://www.isvolatileusefulwiththreads.in/C/

> atomic, or some kind of
> memory barrier implicit or explicit. This is the same if the loop wasn't
> infinite, the compiler would keep the value in register during the loop and
> only write it to memory on exiting the test() function.
>
> 'Allan
>
>

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Martin Sebor]

On 07/20/2018 08:51 AM, Bernd Edlinger wrote:

Martin,

when I look at tree-ssa-forwprop.c:

   str1 = string_constant (src1, );
   if (str1 == NULL_TREE)
 break;
   if (!tree_fits_uhwi_p (off1)
   || compare_tree_int (off1, TREE_STRING_LENGTH (str1) - 1) > 0
   || compare_tree_int (len1, TREE_STRING_LENGTH (str1)
  - tree_to_uhwi (off1)) > 0
   || TREE_CODE (TREE_TYPE (str1)) != ARRAY_TYPE
   || TYPE_MODE (TREE_TYPE (TREE_TYPE (str1)))
  != TYPE_MODE (char_type_node))
 break;

I don't think it is a good idea to let string_constant return
strings which have not necessarily valid content after the first
NUL byte.  It looks like the content has to be valid up to
TREE_STRING_LENGTH.


I'm not sure I understand when this could happen.  From the patch
below it sounds like you are concerned about cases like:

  const char a[4] = "abc\000\000";

where the STRING_CST is bigger than the array.  But the string
constant has valid content here up to TREE_STRING_LENGTH.  Am
I missing something?  (A test case would be helpful.)

In any case, unless the concern is specifically related to
this bug fix let's discuss it separately so I can fix this
bug.  I'm not opposed to making further changes here (in
fact, I have one in the queue and two others that I raised
in Bugzilla in response to our discussion so far), I just
want to avoid mission creep.

Martin



So may I suggest to do something like the following
(diff to your last patch):

--- expr.c.jj   2018-07-20 10:51:51.983605588 +0200
+++ expr.c  2018-07-20 15:07:29.769423479 +0200
@@ -11277,6 +11277,7 @@ tree
  string_constant (tree arg, tree *ptr_offset)
  {
tree array;
+  tree array_size;
STRIP_NOPS (arg);

/* Non-constant index into the character array in an ARRAY_REF
@@ -11295,9 +11296,11 @@ string_constant (tree arg, tree *ptr_off

arg = TREE_OPERAND (arg, 0);
tree ref = arg;
+  tree reftype = TREE_TYPE (ref);
if (TREE_CODE (arg) == ARRAY_REF)
{
  tree idx = TREE_OPERAND (arg, 1);
+ reftype = TREE_TYPE (TREE_OPERAND (arg, 0));
  if (TREE_CODE (idx) != INTEGER_CST
  && TREE_CODE (argtype) == POINTER_TYPE)
{
@@ -11313,6 +11316,11 @@ string_constant (tree arg, tree *ptr_off
return NULL_TREE;
}
}
+  if (TREE_CODE (reftype) != ARRAY_TYPE)
+   return NULL_TREE;
+  while (TREE_CODE (TREE_TYPE (reftype)) == ARRAY_TYPE)
+   reftype = TREE_TYPE (reftype);
+  array_size = TYPE_SIZE_UNIT (reftype);
array = get_addr_base_and_unit_offset (ref, _off);
if (!array
  || (TREE_CODE (array) != VAR_DECL
@@ -11345,7 +11353,10 @@ string_constant (tree arg, tree *ptr_off
return NULL_TREE;
  }
else if (DECL_P (arg))
-array = arg;
+{
+  array = arg;
+  array_size = DECL_SIZE_UNIT (array);
+}
else
  return NULL_TREE;

@@ -11410,24 +11421,18 @@ string_constant (tree arg, tree *ptr_off
if (!init || TREE_CODE (init) != STRING_CST)
  return NULL_TREE;

-  tree array_size = DECL_SIZE_UNIT (array);
if (!array_size || TREE_CODE (array_size) != INTEGER_CST)
  return NULL_TREE;

/* Avoid returning a string that doesn't fit in the array
- it is stored in, like
+ it is stored in, like:
   const char a[4] = "abcde";
- but do handle those that fit even if they have excess
- initializers, such as in
- const char a[4] = "abc\000\000";
- The excess elements contribute to TREE_STRING_LENGTH()
- but not to strlen().  */
-  unsigned HOST_WIDE_INT charsize
-= tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (init;
+ ... or:
+ const char a[4] = "abc\000";
+ ... because some callers access the string up to the limit
+ imposed by TREE_STRING_LENGTH.  */
unsigned HOST_WIDE_INT length = TREE_STRING_LENGTH (init);
-  length = string_length (TREE_STRING_POINTER (init), charsize,
- length / charsize);
-  if (compare_tree_int (array_size, length + 1) < 0)
+  if (compare_tree_int (array_size, length) < 0)
  return NULL_TREE;

*ptr_offset = offset;


Considering Richard's last comment, I don't know if TYPE_SIZE_UNIT
of the ARRAY_TYPE is the correct way to get the size of the
innermost arrayhere, but I think we will need it.



Bernd.

[Bug c/86617] New: Volatile qualifier is ignored sometimes for unsigned char

[yso at melexis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617

Bug ID: 86617
   Summary: Volatile qualifier is ignored sometimes for unsigned
char
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yso at melexis dot com
  Target Milestone: ---

I'm using http://gcc.godbolt.org/ to reproduce this issue.

Compiler: x86-64 gcc (trunk); gcc (GCC-Explorer-Build) 9.0.0 20180719 
Options: -Os

Test code:  
```
volatile unsigned char u8;

void test (void)
{
u8 = u8 + u8;
u8 = u8 - u8;
}
```

Disassembly:  
```
test:
mov al, BYTE PTR u8[rip]
add eax, eax
mov BYTE PTR u8[rip], al

mov al, BYTE PTR u8[rip]
mov BYTE PTR u8[rip], 0
ret
```

In the addition expression `u8 + u8`, volatile variable u8 is copied to the
register only once and then register is doubled. This seems incorrect, as
volatile variable shall be read out from the memory also for the second term of
the sum.

In the subtraction expression `u8 - u8`, result (0) is calculated at compile
time without explicit subtraction.

Also can be reproduced in:
- x86-64 gcc 8.1; gcc (GCC-Explorer-Build) 8.1.0
- x86-64 gcc 7.3; gcc (GCC-Explorer-Build) 7.3.0
- x86-64 gcc 6.3; gcc (GCC-Explorer-Build) 6.3.0
- x86-64 gcc 5.4; gcc (GCC-Explorer-Build) 5.4.0

When g++ is used to compile the same code, everything is fine!

Compiler: x86-64 gcc (trunk); g++ (GCC-Explorer-Build) 9.0.0 20180719 
Options: -Os

Disassembly:
```
_Z3foov:
mov al, BYTE PTR u8[rip]
mov dl, BYTE PTR u8[rip]
add eax, edx
mov BYTE PTR u8[rip], al

mov al, BYTE PTR u8[rip]
mov dl, BYTE PTR u8[rip]
sub eax, edx
mov BYTE PTR u8[rip], al
ret
u8:
.zero   1
```

[PATCH] Adjust offsets for present data clauses

[Cesar Philippidis]

This is another old gomp4 patch that corrects a bug where the runtime
was passing the wrong offset for subarray data to the accelerator. The
original description of this patch can be found here


I bootstrapped and regtested on x86_64/nvptx. Is it OK for trunk?

Thanks,
Cesar
>From fb743d8a45193c177cb0082400d140949e8c1e6d Mon Sep 17 00:00:00 2001
From: Cesar Philippidis 
Date: Wed, 24 Aug 2016 00:02:50 +
Subject: [PATCH 5/5] [libgomp, OpenACC] Adjust offsets for present data
 clauses

2018-XX-YY  Cesar Philippidis  

	libgomp/
	* oacc-parallel.c (GOACC_parallel_keyed): Add offset to devaddrs.
	* testsuite/libgomp.oacc-c-c++-common/data_offset.c: New test.
	* testsuite/libgomp.oacc-fortran/data_offset.f90: New test.

(cherry picked from gomp-4_0-branch r239723, 00c2585)
---
 libgomp/oacc-parallel.c   | 10 -
 .../libgomp.oacc-c-c++-common/data_offset.c   | 41 ++
 .../libgomp.oacc-fortran/data_offset.f90  | 43 +++
 3 files changed, 92 insertions(+), 2 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/data_offset.c
 create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/data_offset.f90

diff --git a/libgomp/oacc-parallel.c b/libgomp/oacc-parallel.c
index b80ace58590..20e9ab2e251 100644
--- a/libgomp/oacc-parallel.c
+++ b/libgomp/oacc-parallel.c
@@ -231,8 +231,14 @@ GOACC_parallel_keyed (int device, void (*fn) (void *),
 
   devaddrs = gomp_alloca (sizeof (void *) * mapnum);
   for (i = 0; i < mapnum; i++)
-devaddrs[i] = (void *) (tgt->list[i].key->tgt->tgt_start
-			+ tgt->list[i].key->tgt_offset);
+{
+  if (tgt->list[i].key != NULL)
+	devaddrs[i] = (void *) (tgt->list[i].key->tgt->tgt_start
++ tgt->list[i].key->tgt_offset
++ tgt->list[i].offset);
+  else
+	devaddrs[i] = NULL;
+}
 
   acc_dev->openacc.exec_func (tgt_fn, mapnum, hostaddrs, devaddrs,
 			  async, dims, tgt);
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/data_offset.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/data_offset.c
new file mode 100644
index 000..ccbbfcab87b
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/data_offset.c
@@ -0,0 +1,41 @@
+/* Test present data clauses in acc offloaded regions when the
+   subarray inside the present clause does not have the same base
+   offset value as the subarray in the enclosing acc data or acc enter
+   data variable.  */
+
+#include 
+
+void
+offset (int *data, int n)
+{
+  int i;
+
+#pragma acc parallel loop present (data[0:n])
+  for (i = 0; i < n; i++)
+data[i] = n;
+}
+
+int
+main ()
+{
+  const int n = 30;
+  int data[n], i;
+
+  for (i = 0; i < n; i++)
+data[i] = -1;
+
+#pragma acc data copy(data[0:n])
+  {
+offset (data+10, 10);
+  }
+
+  for (i = 0; i < n; i++)
+{
+  if (i < 10 || i >= 20)
+	assert (data[i] == -1);
+  else
+	assert (data[i] == 10);
+}
+
+  return 0;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/data_offset.f90 b/libgomp/testsuite/libgomp.oacc-fortran/data_offset.f90
new file mode 100644
index 000..ff8ee39f964
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/data_offset.f90
@@ -0,0 +1,43 @@
+! Test present data clauses in acc offloaded regions when the subarray
+! inside the present clause does not have the same base offset value
+! as the subarray in the enclosing acc data or acc enter data variable.
+
+program test
+  implicit none
+
+  integer, parameter :: n = 30, m = 10
+  integer :: i
+  integer, allocatable :: data(:)
+  logical bounded
+
+  allocate (data(n))
+
+  data(:) = -1
+
+  !$acc data copy (data(5:20))
+  call test_data (data, n, m)
+  !$acc end data
+
+  do i = 1, n
+ bounded = i < m .or. i >= m+m
+ if (bounded .and. (data(i) /= -1)) then
+call abort
+ else if (.not. bounded .and. data(i) /= 10) then
+call abort
+ end if
+  end do
+
+  deallocate (data)
+end program test
+
+subroutine test_data (data, n, m)
+  implicit none
+
+  integer :: n, m, data(n), i
+
+  !$acc parallel loop present (data(m:m))
+  do i = m, m+m-1
+ data(i) = m
+  end do
+  !$acc end parallel loop
+end subroutine test_data
-- 
2.17.1

Re: O2 Agressive Optimisation by GCC

[Allan Sandfeld Jensen]

On Freitag, 20. Juli 2018 14:19:12 CEST Umesh Kalappa wrote:
> Hi All ,
> 
> We are looking at the C sample i.e
> 
> extern int i,j;
> 
> int test()
> {
> while(1)
> {   i++;
> j=20;
> }
> return 0;
> }
> 
> command used :(gcc 8.1.0)
> gcc -S test.c -O2
> 
> the generated asm for x86
> 
> .L2:
> jmp .L2
> 
> we understand that,the infinite loop is not  deterministic ,compiler
> is free to treat as that as UB and do aggressive optimization ,but we
> need keep the side effects like j=20 untouched by optimization .
> 
> Please note that using the volatile qualifier for i and j  or empty
> asm("") in the while loop,will stop the optimizer ,but we don't want
> do  that.
> 
But you need to do that! If you want changes to a variable to be observable in 
another thread, you need to use either volatile, atomic, or some kind of 
memory barrier implicit or explicit. This is the same if the loop wasn't 
infinite, the compiler would keep the value in register during the loop and 
only write it to memory on exiting the test() function.

'Allan

[PATCH] Enable firstprivate OpenACC reductions

[Cesar Philippidis]

At present, all reduction variables are transferred via an implicit
'copy' clause. As shown the the recent patches I've been posting, that
causes a lot of problems when the reduction variables are used by
multiple workers or vectors. This patch teaches the gimplifier to
transfer reduction variable as firstprivate in OpenACC parallel regions,
if the are in an inner loop. This matches the behavior of reductions in
OpenACC 2.6.

Is this patch OK for trunk? I bootstrapped and regtested on x86_64/nvptx.

Thanks,
Cesar
>From 035be51a795ad8bed5342ba181220bf3102bcd6d Mon Sep 17 00:00:00 2001
From: Cesar Philippidis 
Date: Wed, 31 Jan 2018 07:21:53 -0800
Subject: [PATCH 4/5] Enable firstprivate OpenACC reductions

2018-XX-YY  Cesar Philippidis  

	gcc/
	* gimplify.c (omp_add_variable): Allow certain OpenACC reduction
	variables to remain firstprivate.

	gcc/testsuite/
	* c-c++-common/goacc/reduction-8.c: New test.

(cherry picked from openacc-gcc-7-branch commit
441621739e2a067c97409f8b0e3e30362a7905be, cec00212ad8)
---
 gcc/gimplify.c| 30 --
 .../c-c++-common/goacc/reduction-8.c  | 94 +++
 2 files changed, 117 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/goacc/reduction-8.c

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 737a280cfe9..bcfb029275c 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -6858,9 +6858,16 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
   else
 splay_tree_insert (ctx->variables, (splay_tree_key)decl, flags);
 
-  /* For reductions clauses in OpenACC loop directives, by default create a
- copy clause on the enclosing parallel construct for carrying back the
- results.  */
+  /* For OpenACC loop directives, when a reduction is immediately
+ enclosed within an acc parallel or kernels construct, it must
+ have an implied copy data mapping. E.g.
+
+   #pragma acc parallel
+	 {
+	   #pragma acc loop reduction (+:sum)
+
+ a copy clause for sum should be added on the enclosing parallel
+ construct for carrying back the results.  */
   if (ctx->region_type == ORT_ACC && (flags & GOVD_REDUCTION))
 {
   struct gimplify_omp_ctx *outer_ctx = ctx->outer_context;
@@ -6876,8 +6883,11 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
 	vector = true;
 	}
 
-  /* Set new copy map as 'private' if sure we're not gang-partitioning.  */
-  bool map_private;
+  /* Reduction data maps need to be marked as private for worker
+	 and vector loops, in order to ensure that value of the
+	 reduction carried back to the host.  Set new copy map as
+	 'private' if sure we're not gang-partitioning.  */
+  bool map_private, update_data_map = false;
 
   if (gang)
 	map_private = false;
@@ -6886,6 +6896,10 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
   else
 	map_private = oacc_privatize_reduction (ctx->outer_context);
 
+  if (ctx->outer_context
+	  && ctx->outer_context->region_type == ORT_ACC_PARALLEL)
+	update_data_map = true;
+
   while (outer_ctx)
 	{
 	  n = splay_tree_lookup (outer_ctx->variables, (splay_tree_key)decl);
@@ -6902,7 +6916,8 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
 		  gcc_assert (!(n->value & GOVD_FIRSTPRIVATE)
 			  && (n->value & GOVD_MAP));
 		}
-	  else if (outer_ctx->region_type == ORT_ACC_PARALLEL)
+	  else if (update_data_map
+		   && outer_ctx->region_type == ORT_ACC_PARALLEL)
 		{
 		  /* Remove firstprivate and make it a copy map.  */
 		  n->value &= ~GOVD_FIRSTPRIVATE;
@@ -6914,7 +6929,8 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
 		n->value |= GOVD_MAP_PRIVATE;
 		}
 	}
-	  else if (outer_ctx->region_type == ORT_ACC_PARALLEL)
+	  else if (update_data_map
+		   && outer_ctx->region_type == ORT_ACC_PARALLEL)
 	{
 	  unsigned f = GOVD_MAP | GOVD_SEEN;
 
diff --git a/gcc/testsuite/c-c++-common/goacc/reduction-8.c b/gcc/testsuite/c-c++-common/goacc/reduction-8.c
new file mode 100644
index 000..8a0283f4ac3
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc/reduction-8.c
@@ -0,0 +1,94 @@
+/* { dg-additional-options "-fdump-tree-gimple" } */
+
+#define n 1000
+
+int
+main(void)
+{
+  int i, j;
+  int result, array[n];
+
+#pragma acc parallel loop reduction (+:result)
+  for (i = 0; i < n; i++)
+result ++;
+
+#pragma acc parallel
+#pragma acc loop reduction (+:result)
+  for (i = 0; i < n; i++)
+result ++;
+
+#pragma acc parallel
+#pragma acc loop
+  for (i = 0; i < n; i++)
+{
+  result = i;
+
+#pragma acc loop reduction(+:result)
+  for (j = 0; j < n; j++)
+	result ++;
+
+  array[i] = result;
+}
+
+#pragma acc parallel
+#pragma acc loop
+  for (i = 0; i < n; i++)
+{
+  result = i;
+
+#pragma acc loop worker vector reduction(+:result)
+  for (j = 0; j < n; j++)
+	

[PATCH] Privatize independent OpenACC reductions

[Cesar Philippidis]

This is another OpenACC reduction patch to privatize reduction variables
used inside inner acc loops. For some reason, I can't find the original
email announcement on the gcc-patches mailing list. But according to the
ChangeLog, I committed that change to og7 back on Jan 26, 2018.

I bootstrapped and regtested on x86_64/nvptx. Is it OK for trunk?

Thanks,
Cesar
>From a4753e2b40cf3d707aabd7c9d5bad7d8f9be8b6f Mon Sep 17 00:00:00 2001
From: Cesar Philippidis 
Date: Fri, 26 Jan 2018 08:30:13 -0800
Subject: [PATCH 3/5] Privatize independent OpenACC reductions

2018-XX-YY  Cesar Philippidis  

	gcc/
	* gimplify.c (oacc_privatize_reduction): New function.
	(omp_add_variable): Use it to determine if a reduction variable
	needs to be privatized.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/inner-reduction.c: New test.

(cherry picked from openacc-gcc-7-branch commit
330ba2316fabd0e5525c99fdacedb0bfae270244, 133f3a8fb5c)
---
 gcc/gimplify.c| 35 ++-
 .../inner-reduction.c | 23 
 2 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/inner-reduction.c

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 7dadf69b758..737a280cfe9 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -6722,6 +6722,32 @@ omp_firstprivatize_type_sizes (struct gimplify_omp_ctx *ctx, tree type)
   lang_hooks.types.omp_firstprivatize_type_sizes (ctx, type);
 }
 
+/* Determine if CTX might contain any gang partitioned loops.  During
+   oacc_dev_low, independent loops are assign gangs at the outermost
+   level, and vectors in the innermost.  */
+
+static bool
+oacc_privatize_reduction (struct gimplify_omp_ctx *ctx)
+{
+  if (ctx == NULL)
+return false;
+
+  if (ctx->region_type != ORT_ACC)
+return false;
+
+  for (tree c = ctx->clauses; c; c = OMP_CLAUSE_CHAIN (c))
+switch (OMP_CLAUSE_CODE (c))
+  {
+  case OMP_CLAUSE_SEQ:
+	return oacc_privatize_reduction (ctx->outer_context);
+  case OMP_CLAUSE_GANG:
+	return true;
+  default:;
+  }
+
+  return true;
+}
+
 /* Add an entry for DECL in the OMP context CTX with FLAGS.  */
 
 static void
@@ -6851,7 +6877,14 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
 	}
 
   /* Set new copy map as 'private' if sure we're not gang-partitioning.  */
-  bool map_private = !gang && (worker || vector);
+  bool map_private;
+
+  if (gang)
+	map_private = false;
+  else if (worker || vector)
+	map_private = true;
+  else
+	map_private = oacc_privatize_reduction (ctx->outer_context);
 
   while (outer_ctx)
 	{
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/inner-reduction.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/inner-reduction.c
new file mode 100644
index 000..0c317dcf8a6
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/inner-reduction.c
@@ -0,0 +1,23 @@
+#include 
+
+int
+main ()
+{
+  const int n = 1000;
+  int i, j, temp, a[n];
+
+#pragma acc parallel loop
+  for (i = 0; i < n; i++)
+{
+  temp = i;
+#pragma acc loop reduction (+:temp)
+  for (j = 0; j < n; j++)
+	temp ++;
+  a[i] = temp;
+}
+
+  for (i = 0; i < n; i++)
+assert (a[i] == i+n);
+
+  return 0;
+}
-- 
2.17.1

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
FWIW, it would be safer and more deterministic to fold these invalid calls to
some non-zero value that it is to emit the invalid library call.  With a small
string, the risk that the call will crash is small but the result could still
be different depending on how strings are laid out in memory.  With larger
strings, the risk is greater as will be the non-determinism.

Re: Repo conversion troubles.

[Joseph Myers]

On Tue, 10 Jul 2018, Jonathan Wakely wrote:

> > Large-scale, I'm afraid.  The context diff is about a GLOC.
> 
> I don't see how that's possible. Most of those files are tiny, or
> change very rarely, so I don't see how that large a diff can happen.

Concretely, the *complete GCC source tree* (trunk, that is) is under 1 GB.  
A complete diff generating the whole source tree from nothing would only 
be about 15 MLOC.

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

[PATCH] Add support for making maps 'private' inside OpenACC offloaded regions

[Cesar Philippidis]

Due to the different levels of parallelism available in OpenACC, it is
useful to mark certain variables as GOMP_MAP_PRIVATE so that they can be
used in reductions. This patch was introduced in openacc-gcc-7-branch
here .


I bootstrapped and regtested on x86_64/nvptx. Is it OK for trunk?

Thanks,
Cesar

>From b0e7fb09bf3a3f853e77c2712b6f85ad21472e72 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang 
Date: Tue, 5 Sep 2017 22:09:34 +0800
Subject: [PATCH 2/5] [OpenACC] Add support for making maps 'private' inside
 offloaded regions

2018-XX-YY Chung-Lin Tang  
	   Cesar Philippidis  

	gcc/
	* tree.h (OMP_CLAUSE_MAP_PRIVATE): Define macro.
	* gimplify.c (enum gimplify_omp_var_data): Add GOVD_MAP_PRIVATE enum value.
	(omp_add_variable): Add GOVD_MAP_PRIVATE to reduction clause flags if
	not a gang-partitioned loop directive.
	(gimplify_adjust_omp_clauses_1): Set OMP_CLAUSE_MAP_PRIVATE of new map
	clause to 1 if GOVD_MAP_PRIVATE flag is present.
	* omp-low.c (lower_oacc_reductions): Handle map clauses with
	OMP_CLAUSE_MAP_PRIVATE set in same matter as firstprivate/private.
	(lower_omp_target): Likewise. Add copy back code for map clauses with
	OMP_CLAUSE_MAP_PRIVATE set.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/reduction-9.c: New test.

(cherry picked from openacc-gcc-7-branch commit
2dc21f336368889c1ebf031801a7613f65899ef1, e17bb2068f9)
---
 gcc/gimplify.c| 34 ++-
 gcc/omp-low.c | 28 +++--
 gcc/tree.h|  3 ++
 .../libgomp.oacc-c-c++-common/reduction-9.c   | 41 +++
 4 files changed, 101 insertions(+), 5 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-9.c

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index cf8977c8508..7dadf69b758 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -105,6 +105,9 @@ enum gimplify_omp_var_data
   /* Flag for GOVD_MAP: must be present already.  */
   GOVD_MAP_FORCE_PRESENT = 524288,
 
+  /* Flag for GOVD_MAP, copy to/from private storage inside offloaded region.  */
+  GOVD_MAP_PRIVATE = 1048576,
+
   GOVD_DATA_SHARE_CLASS = (GOVD_SHARED | GOVD_PRIVATE | GOVD_FIRSTPRIVATE
 			   | GOVD_LASTPRIVATE | GOVD_REDUCTION | GOVD_LINEAR
 			   | GOVD_LOCAL)
@@ -6835,6 +6838,21 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
   if (ctx->region_type == ORT_ACC && (flags & GOVD_REDUCTION))
 {
   struct gimplify_omp_ctx *outer_ctx = ctx->outer_context;
+
+  bool gang = false, worker = false, vector = false;
+  for (tree c = ctx->clauses; c; c = OMP_CLAUSE_CHAIN (c))
+	{
+	  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_GANG)
+	gang = true;
+	  else if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_WORKER)
+	worker = true;
+	  else if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_VECTOR)
+	vector = true;
+	}
+
+  /* Set new copy map as 'private' if sure we're not gang-partitioning.  */
+  bool map_private = !gang && (worker || vector);
+
   while (outer_ctx)
 	{
 	  n = splay_tree_lookup (outer_ctx->variables, (splay_tree_key)decl);
@@ -6856,12 +6874,21 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
 		  /* Remove firstprivate and make it a copy map.  */
 		  n->value &= ~GOVD_FIRSTPRIVATE;
 		  n->value |= GOVD_MAP;
+
+		  /* If not gang-partitioned, add MAP_PRIVATE on the map
+		 clause.  */
+		  if (map_private)
+		n->value |= GOVD_MAP_PRIVATE;
 		}
 	}
 	  else if (outer_ctx->region_type == ORT_ACC_PARALLEL)
 	{
-	  splay_tree_insert (outer_ctx->variables, (splay_tree_key)decl,
- GOVD_MAP | GOVD_SEEN);
+	  unsigned f = GOVD_MAP | GOVD_SEEN;
+
+	  /* If not gang-partitioned, add MAP_PRIVATE on the map clause.  */
+	  if (map_private)
+		f |= GOVD_MAP_PRIVATE;
+	  splay_tree_insert (outer_ctx->variables, (splay_tree_key)decl, f);
 	  break;
 	}
 	  outer_ctx = outer_ctx->outer_context;
@@ -8904,6 +8931,9 @@ gimplify_adjust_omp_clauses_1 (splay_tree_node n, void *data)
 	  gcc_unreachable ();
 	}
   OMP_CLAUSE_SET_MAP_KIND (clause, kind);
+  if ((flags & GOVD_MAP_PRIVATE)
+	  && TREE_CODE (OMP_CLAUSE_DECL (clause)) == VAR_DECL)
+	OMP_CLAUSE_MAP_PRIVATE (clause) = 1;
   tree c2 = gomp_needs_data_present (decl);
   /* Handle OpenACC pointers that were declared inside acc data
 	 regions.  */
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 714490d6921..ef3c7651c74 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -4907,7 +4907,9 @@ lower_oacc_reductions (location_t loc, tree clauses, tree level, bool inner,
 		  goto has_outer_reduction;
 		}
 		  else if ((OMP_CLAUSE_CODE (cls) == OMP_CLAUSE_FIRSTPRIVATE
-			|| OMP_CLAUSE_CODE (cls) == OMP_CLAUSE_PRIVATE)
+			|| OMP_CLAUSE_CODE (cls) == OMP_CLAUSE_PRIVATE
+			|| (OMP_CLAUSE_CODE (cls) == OMP_CLAUSE_MAP
+&& OMP_CLAUSE_MAP_PRIVATE (cls)))
 			   && 

Re: Repo conversion troubles.

[Joseph Myers]

On Mon, 9 Jul 2018, Alexandre Oliva wrote:

> On Jul  9, 2018, Jeff Law  wrote:
> 
> > On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
> >> Jeff Law :
> >>> I'm not aware of any such merges, but any that occurred most likely
> >>> happened after mid-April when the trunk was re-opened for development.
> 
> >> I'm pretty certain things were still good at r256000.  I've started that
> >> check running.  Not expecting results in less than twelve hours.
> 
> > r256000 would be roughly Christmas 2017.
> 
> When was the RAID/LVM disk corruption incident?  Could it possibly have
> left any of our svn repo metadata in a corrupted way that confuses
> reposurgeon, and that leads to such huge differences?

That was 14/15 Aug 2017, and all the SVN revision data up to r251080 were 
restored from backup within 24 hours or so.  I found no signs of damage to 
revisions from the 24 hours or so between r251080 and the time of the 
corruption when I examined diffs for all those revisions by hand at that 
time.

(If anyone rsynced corrupted old revisions from the repository during the 
window of corruption, those corrupted old revisions might remain in their 
rsynced repository copy because the restoration preserved file times and 
size, just fixing corrupted contents.)

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

[PATCH] Fix PR70828 - broken array-type subarrays inside acc data, in OpenACC

[Cesar Philippidis]

Attached is an old gomp-4_0-branch that fixes PR70828. Besides for
fixing the PR, it also introduces some changes which will enable the
forthcoming nvptx vector length enhancements. More details on the patch
can be found here 

I bootstrapped and regtested on x86_64/nvptx. Is it OK for trunk?

Thanks,
Cesar
>From 3a58144cfaca8f6e3a889346e736e68a9ed17e6a Mon Sep 17 00:00:00 2001
From: Cesar Philippidis 
Date: Thu, 18 Aug 2016 01:12:15 +
Subject: [PATCH 1/5] Fix PR70828s "broken array-type subarrays inside acc data
 in openacc"

2018-XX-YY  Cesar Philippidis  

	gcc/
	* gimplify.c (struct gimplify_omp_ctx): Add tree clauses member.
	(new_omp_context): Initialize clauses to NULL_TREE.
	(gimplify_scan_omp_clauses): Set clauses in the gimplify_omp_ctx.
	(omp_clause_matching_array_ref): New function.
	(gomp_needs_data_present): New function.
	(gimplify_adjust_omp_clauses_1): Use preset or pointer omp clause map
	kinds when creating implicit data clauses for OpenACC offloaded
	variables defined used an acc data region as necessary.  Link ACC
	new clauses with the old ones.

	gcc/testsuite/
	* c-c++-common/goacc/acc-data-chain.c: New test.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/pr70828.c: New test.
	* testsuite/libgomp.oacc-fortran/pr70828.f90: New test.
	* testsuite/libgomp.oacc-fortran/lib-13.f90: Remove XFAIL.
---
 gcc/gimplify.c| 101 +-
 .../c-c++-common/goacc/acc-data-chain.c   |  24 +
 .../libgomp.oacc-c-c++-common/pr70828.c   |  25 +
 .../testsuite/libgomp.oacc-fortran/lib-13.f90 |   1 -
 .../libgomp.oacc-fortran/pr70828.f90  |  24 +
 5 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/goacc/acc-data-chain.c
 create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/pr70828.c
 create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/pr70828.f90

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 4a109aee27a..cf8977c8508 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -191,6 +191,7 @@ struct gimplify_omp_ctx
   bool target_map_scalars_firstprivate;
   bool target_map_pointers_as_0len_arrays;
   bool target_firstprivatize_array_bases;
+  tree clauses;
 };
 
 static struct gimplify_ctx *gimplify_ctxp;
@@ -409,6 +410,7 @@ new_omp_context (enum omp_region_type region_type)
   c->privatized_types = new hash_set;
   c->location = input_location;
   c->region_type = region_type;
+  c->clauses = NULL_TREE;
   if ((region_type & ORT_TASK) == 0)
 c->default_kind = OMP_CLAUSE_DEFAULT_SHARED;
   else
@@ -7501,6 +7503,7 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
   tree *prev_list_p = NULL;
 
   ctx = new_omp_context (region_type);
+  ctx->clauses = *list_p;
   outer_ctx = ctx->outer_context;
   if (code == OMP_TARGET)
 {
@@ -8696,6 +8699,58 @@ struct gimplify_adjust_omp_clauses_data
   gimple_seq *pre_p;
 };
 
+/* Return true if clause contains an array_ref of DECL.  */
+
+static bool
+omp_clause_matching_array_ref (tree clause, tree decl)
+{
+  tree cdecl = OMP_CLAUSE_DECL (clause);
+
+  if (TREE_CODE (cdecl) != ARRAY_REF)
+return false;
+
+  return TREE_OPERAND (cdecl, 0) == decl;
+}
+
+/* Inside OpenACC parallel and kernels regions, the implicit data
+   clauses for arrays must respect the explicit data clauses set by a
+   containing acc data region.  Specifically, care must be taken
+   pointers or if an subarray of a local array is specified in an acc
+   data region, so that the referenced array inside the offloaded
+   region has a present data clasue for that array with an
+   approporiate subarray argument.  This function returns the tree
+   node of the acc data clause that utilizes DECL as an argument.  */
+
+static tree
+gomp_needs_data_present (tree decl)
+{
+  gimplify_omp_ctx *ctx = NULL;
+  bool found_match = false;
+  tree c = NULL_TREE;
+
+  if (TREE_CODE (TREE_TYPE (decl)) != ARRAY_TYPE)
+return NULL_TREE;
+
+  if (gimplify_omp_ctxp->region_type != ORT_ACC_PARALLEL
+  && gimplify_omp_ctxp->region_type != ORT_ACC_KERNELS)
+return NULL_TREE;
+
+  for (ctx = gimplify_omp_ctxp->outer_context; !found_match && ctx;
+   ctx = ctx->outer_context)
+{
+  if (ctx->region_type != ORT_ACC_DATA)
+	break;
+
+  for (c = ctx->clauses; c; c = OMP_CLAUSE_CHAIN (c))
+	if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
+	&& (omp_clause_matching_array_ref (c, decl)
+		|| OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_POINTER))
+	  return c;
+}
+
+  return NULL_TREE;
+}
+
 /* For all variables that were not actually used within the context,
remove PRIVATE, SHARED, and FIRSTPRIVATE clauses.  */
 
@@ -8849,7 +8904,51 @@ gimplify_adjust_omp_clauses_1 (splay_tree_node n, void *data)
 	  gcc_unreachable ();
 	}
   OMP_CLAUSE_SET_MAP_KIND (clause, kind);
-  if (DECL_SIZE (decl)
+  tree c2 = gomp_needs_data_present (decl);
+  /* Handle OpenACC pointers that 

[committed] libcpp: remove redundant parameter from rich_location::set_range

[David Malcolm]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

Committed to trunk as r262913.

gcc/c-family/ChangeLog:
* c-common.c (c_cpp_error): Remove redundant "line_table"
parameter from call to rich_location::set_range.
(maybe_suggest_missing_token_insertion): Likewise.

gcc/ChangeLog:
* pretty-print.c (text_info::set_location): Remove redundant
"line_table" parameter from call to rich_location::set_range.

libcpp/ChangeLog:
* include/line-map.h (rich_location::set_range): Remove redundant
line_maps * parameter.
* line-map.c (rich_location::set_range): Likewise.
---
 gcc/c-family/c-common.c   | 4 ++--
 gcc/pretty-print.c| 2 +-
 libcpp/include/line-map.h | 3 +--
 libcpp/line-map.c | 4 ++--
 4 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index f5e..422d668 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -6133,7 +6133,7 @@ c_cpp_error (cpp_reader *pfile ATTRIBUTE_UNUSED, int 
level, int reason,
   gcc_unreachable ();
 }
   if (done_lexing)
-richloc->set_range (line_table, 0, input_location, true);
+richloc->set_range (0, input_location, true);
   diagnostic_set_info_translated (, msg, ap,
  richloc, dlevel);
   diagnostic_override_option_index (,
@@ -8174,7 +8174,7 @@ maybe_suggest_missing_token_insertion (rich_location 
*richloc,
   location_t hint_loc = hint->get_start_loc ();
   location_t old_loc = richloc->get_loc ();
 
-  richloc->set_range (line_table, 0, hint_loc, true);
+  richloc->set_range (0, hint_loc, true);
   richloc->add_range (old_loc, false);
 }
 }
diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c
index df3ee81..dc7791a 100644
--- a/gcc/pretty-print.c
+++ b/gcc/pretty-print.c
@@ -699,7 +699,7 @@ void
 text_info::set_location (unsigned int idx, location_t loc, bool show_caret_p)
 {
   gcc_checking_assert (m_richloc);
-  m_richloc->set_range (line_table, idx, loc, show_caret_p);
+  m_richloc->set_range (idx, loc, show_caret_p);
 }
 
 location_t
diff --git a/libcpp/include/line-map.h b/libcpp/include/line-map.h
index ba1750d..a4baa49 100644
--- a/libcpp/include/line-map.h
+++ b/libcpp/include/line-map.h
@@ -1639,8 +1639,7 @@ class rich_location
   add_range (source_location loc,  bool show_caret_p);
 
   void
-  set_range (line_maps *set, unsigned int idx, source_location loc,
-bool show_caret_p);
+  set_range (unsigned int idx, source_location loc, bool show_caret_p);
 
   unsigned int get_num_locations () const { return m_ranges.count (); }
 
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 1051022..a1a765f 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -2104,8 +2104,8 @@ rich_location::add_range (source_location loc, bool 
show_caret_p)
- the "%C" and "%L" format codes in the Fortran frontend.  */
 
 void
-rich_location::set_range (line_maps * /*set*/, unsigned int idx,
- source_location loc, bool show_caret_p)
+rich_location::set_range (unsigned int idx, source_location loc,
+ bool show_caret_p)
 {
   /* We can either overwrite an existing range, or add one exactly
  on the end of the array.  */
-- 
1.8.5.3

[Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize

[Janus Weil]

Hi all,

here is a follow-up patch to my recent commit for PR 85599, also
dealing with the short-circuiting of logical operators. In the course
of the extensive discussion of that PR it became clear that the
Fortran standard allows the short-circuiting of .AND. and .OR.
operators, but does not mandate it.

gfortran currently does short-circuiting, and after my patch for PR
85599 warns about cases where this might remove an impure function
call (which potentially can change results).

Now, this PR (57160) is about code which relies on the
short-circuiting behavior. Since short-circuiting is not guaranteed by
the standard, such code is invalid. Generating a warning or an error
at compile-time is a bit harder here, though, since there are multiple
variations of such a situation, e.g.:
* ASSOCIATED(p) .AND. p%T
* ALLOCATED(a) .AND. a%T
* i

PR fortran/57160
* trans-expr.c (gfc_conv_expr_op): Use short-circuiting operators only
with -ffrontend-optimize. Without that flag, make sure that both
operands are evaluated.


2018-07-20  Janus Weil  

PR fortran/57160
* gfortran.dg/actual_pointer_function_1.f90: Fix invalid test case.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c	(revision 262908)
+++ gcc/fortran/trans-expr.c	(working copy)
@@ -3348,12 +3348,12 @@ gfc_conv_expr_op (gfc_se * se, gfc_expr * expr)
   return;
 
 case INTRINSIC_AND:
-  code = TRUTH_ANDIF_EXPR;
+  code = flag_frontend_optimize ? TRUTH_ANDIF_EXPR : TRUTH_AND_EXPR;
   lop = 1;
   break;
 
 case INTRINSIC_OR:
-  code = TRUTH_ORIF_EXPR;
+  code = flag_frontend_optimize ? TRUTH_ORIF_EXPR : TRUTH_OR_EXPR;
   lop = 1;
   break;
 
Index: gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90
===
--- gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90	(revision 262908)
+++ gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90	(working copy)
@@ -17,7 +17,11 @@ CONTAINS
 
   logical function cp_logger_log(logger)
 TYPE(cp_logger_type), POINTER ::logger
-cp_logger_log = associated (logger) .and. (logger%a .eq. 42)
+if (associated (logger)) then
+  cp_logger_log = (logger%a .eq. 42)
+else
+  cp_logger_log = .false.
+end if
   END function
 
   FUNCTION cp_get_default_logger(v) RESULT(res)

Re: Repo conversion troubles.

[Joseph Myers]

On Mon, 9 Jul 2018, Eric S. Raymond wrote:

> Richard Biener :
> > 12 hours from remote I guess? The subversion repository is available 
> > through rsync so you can create a local mirror to work from (we've been 
> > doing that at suse for years) 
> 
> I'm saying I see rsync plus local checkout take 10-12 hours.  I asked Jason
> about this and his response was basically "Well...we don't do that often."

Isn't that a local checkout *of top-level of the repository*, i.e. 
checking out all branches and tags?  Which is indeed something developers 
would never normally do - they'd just check out the particular branches 
they're working on.

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

[Bug testsuite/86616] [9 regression] c-c++-common/Warray-bounds-2.c fails starting with r262893

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86616

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #1 from Martin Sebor  ---
I committed r262906 earlier today to fix a number of failures in some of the
-Warray-bounds tests (see
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01198.html).  The
c-c++-common/Warray-bounds-2.c test passes for me now with a powerpc64le
cross-compiler so these failures should be resolved by that commit.

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #14 from Martin Sebor  ---
All the issues here should be addressed now.  Resolving as fixed.

Re: Good news, bad news on the repository conversion

[Joseph Myers]

I don't see any commits at 
git://thyrsus.com/repositories/gcc-conversion.git since January.  Are 
there further changes that haven't been pushed there?  (For example, I 
sent a few additions to the author map on 13 Feb.)

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

committed: remove redundant -Wall from -Warray-bounds (PR 82063)

[Martin Sebor]

As the last observation in PR 82063 Jim points out that

  Both -Warray-bounds and -Warray-bounds= are listed in the c.opt
  file as being enabled by -Wall, but they are the same option,
  and it causes this one option to be processed twice in the
  C_handle_option_auto function in the generated options.c file.
  It gets set to the same value twice, so it does work as intended,
  but this is wasteful.

I have removed the redundant -Wall from the first option and
committed the change as obvious in r262912.

Martin

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063

--- Comment #13 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 21:19:49 2018
New Revision: 262912

URL: https://gcc.gnu.org/viewcvs?rev=262912=gcc=rev
Log:
PR middle-end/82063 - issues with arguments enabled by -Wall

gcc/c-family/ChangeLog:
* gcc/c-family/c.opt (-Warray-bounds): Remove redundant -Wall.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt

Re: gcc-gnat for Linux/MIPS-32bit-be, and HPPA2

[Florian Weimer]

* Jeff Law:

> On 07/19/2018 02:19 PM, Carlo Pisani wrote:
>> hi
>> is there any chance someone has a working gcc-ada compiler? for
>> - Linux/MIPS (big endian, MIPS3, MIPS4 or MIPS32)
>> - Linux/HPPA2
>> 
>> I have successfully compiled gcc-ada for SGI_IRIX (MIPS4/BE)
>> but ... every attempt to create a cross-compiler(1) fails
>> 
>> on HPPA I have never seen an Ada compiler
> We certainly had it on PA HPUX.  Of course that platform is long dead.
>
> It looks like Debian's PA port has had an Ada compiler in the past.  I'd
> be surprised if they still don't -- once you've built it once it's
> fairly easy to carry forward.

Right, it's still building:



However, I'm not sure if it qualifies as a PA-RISC 2.0 port.  There's
certainly no 64-bit userspace.

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063

--- Comment #12 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 21:18:31 2018
New Revision: 262911

URL: https://gcc.gnu.org/viewcvs?rev=262911=gcc=rev
Log:
PR middle-end/82063

gcc/testsuite/ChangeLog:

* gcc/testsuite/c-c++-common/pr68833-1.c: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr68833-1.c

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

I think I have found a valid test case where the latest patch
does generate invalid code:

$ cat part.c
static const char a[3][8] = { "1234", "12345", "123456" };

int main ()
{
   volatile int i = 1;
   int n = __builtin_strlen (*([1]+i));

   if (n != 6)
 __builtin_abort ();
}
$ gcc part.c -fdump-tree-original
$ ./a.out
Aborted (core dumped)
$ cat part.c.004t.original

;; Function main (null)
;; enabled by -tree-original


{
   volatile int i = 1;
   int n = (ssizetype) (SAVE_EXPR <(long unsigned int) i * 8>) <= 5 ? (int) (5 
- (unsigned int) (SAVE_EXPR <(long unsigned int) i * 8>)) : 0;

 volatile int i = 1;
 int n = (ssizetype) (SAVE_EXPR <(long unsigned int) i * 8>) <= 5 ? (int) 
(5 - (unsigned int) (SAVE_EXPR <(long unsigned int) i * 8>)) : 0;
   if (n != 6)
 {
   __builtin_abort ();
 }
}
return 0;


string_constant is called with arg = (const char *) ([1] + (sizetype) ((long 
unsigned int) i * 8))



Bernd.

Re: ChangeLog's: do we have to?

[Joseph Myers]

On Thu, 5 Jul 2018, Aldy Hernandez wrote:

> However, even if you could "git log --grep" the commit messages, I assume your
> current use is grepping for function names and such, right? Being able to grep
> a commit message won't solve that problem, or am I missing something?

If you know what function and file you're interested in, you can use git 
log -L to find changes to it (I've used that in the GCC context before), 
or of course other tools such as git blame.

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

Re: ChangeLog's: do we have to?

[Joseph Myers]

As far as I am concerned, the problem with ChangeLogs is one with the 
format rather than one with having files called ChangeLog.  (The GNU 
Coding Standards have permitted automatic generation of ChangeLog at 
release time from version control information since 1996.)

The main issues I see with the format are:

(a) It's a format designed for pre-VCS days and thus involves writing 
descriptions that duplicate what's plain from reading the change itself, 
rather than descriptions that are written on the basis that readers have 
access to the change itself and so the description can better concentrate 
on a higher-level overview of the changes and information that isn't 
obvious simply from reading them.

(b) It forces all descriptions to be at the level of describing what 
changed in each individual named entity in the source code, whether or not 
that is the most helpful level for understanding that particular change 
(and whether or not entity names either exist or are convenient for the 
ChangeLog - a convention designed for C function names works less well for 
C++).

I think that for many projects these outweigh the benefits from forcing 
someone to read through all their changes carefully to write the ChangeLog 
entry.

In the discussions on bug-standards, RMS was amenable to removing the 
requirement for ChangeLog format and the per-entity descriptions of what 
changed - *if* a sufficiently good tool is provided to produce a list of 
the names of the entities changed by a commit.  I don't see such a tool as 
being useful - I think the cases where people might use such lists can all 
be adequately addressed using existing git facilities to e.g. search for 
changes to an entity rather than list entities involved in a change.  But 
I haven't managed to persuade RMS of that.

So, if someone write the entity-listing tool, we should be able to get the 
GNU Coding Standards requirement for ChangeLog format removed (whether or 
not it's still necessary to generate some kind of log of changes at 
release time and put it in a file called ChangeLog).  The tool should be 
able to handle, at least, the main cases where diff hunk headers get the 
name of the changed entity wrong (when the relevant funcname line is 
inside the hunk rather than before it, when the changed entity is a 
#define, at least).

https://lists.gnu.org/archive/html/bug-standards/2018-05/msg00011.html

If the requirement is removed from the GNU Coding Standards, individual 
GNU packages can then make their own decisions about whether to keep using 
ChangeLog format or not.

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

Re: [PATCH] specify large command line option arguments (PR 82063)

[Martin Sebor]

On 07/19/2018 04:31 PM, Jeff Law wrote:

On 06/24/2018 03:05 PM, Martin Sebor wrote:

Storing integer command line option arguments in type int
limits options such as -Wlarger-than= or -Walloca-larger-than
to at most INT_MAX (see bug 71905).  Larger values wrap around
zero.  The value zero is considered to disable the option,
making it impossible to specify a zero limit.

To get around these limitations, the -Walloc-size-larger-than=
option accepts a string argument that it then parses itself
and interprets as HOST_WIDE_INT.  The option also accepts byte
size suffixes like KB, MB, GiB, etc. to make it convenient to
specify very large limits.

The int limitation is obviously less than ideal in a 64-bit
world.  The treatment of zero as a toggle is just a minor wart.
The special treatment to make it work for just a single option
makes option handling inconsistent.  It should be possible for
any option that takes an integer argument to use the same logic.

The attached patch enhances GCC option processing to do that.
It changes the storage type of option arguments from int to
HOST_WIDE_INT and extends the existing (although undocumented)
option property Host_Wide_Int to specify wide option arguments.
It also introduces the ByteSize property for options for which
specifying the byte-size suffix makes sense.

To make it possible to consider zero as a meaningful argument
value rather than a flag indicating that an option is disabled
the patch also adds a CLVC_SIZE enumerator to the cl_var_type
enumeration, and modifies how options of the kind are handled.

Warning options that take large byte-size arguments can be
disabled by specifying a value equal to or greater than
HOST_WIDE_INT_M1U.  For convenience, aliases in the form of
-Wno-xxx-larger-than have been provided for all the affected
options.

In the patch all the existing -larger-than options are set
to PTRDIFF_MAX.  This makes them effectively enabled, but
because the setting is exceedingly permissive, and because
some of the existing warnings are already set to the same
value and some other checks detect and reject such exceedingly
large values with errors, this change shouldn't noticeably
affect what constructs are diagnosed.

Although all the options are set to PTRDIFF_MAX, I think it
would make sense to consider setting some of them lower, say
to PTRDIFF_MAX / 2.  I'd like to propose that in a followup
patch.

To minimize observable changes the -Walloca-larger-than and
-Wvla-larger-than warnings required more extensive work to
make of the new mechanism because of the "unbounded" argument
handling (the warnings trigger for arguments that are not
visibly constrained), and because of the zero handling
(the warnings also trigger


Martin


gcc-82063.diff


PR middle-end/82063 - issues with arguments enabled by -Wall

gcc/ada/ChangeLog:

PR middle-end/82063
* gcc-interface/misc.c (gnat_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/brig/ChangeLog:
* brig/brig-lang.c (brig_langhook_handle_option): Change function
argument to HOST_WIDE_INT.

gcc/c-family/ChangeLog:

PR middle-end/82063
* c-common.h (c_common_handle_option): Change function argument
to HOST_WIDE_INT.
* c-opts.c (c_common_init_options): Same.
(c_common_handle_option): Same.  Remove special handling of
OPT_Walloca_larger_than_ and OPT_Wvla_larger_than_.
* c.opt (-Walloc-size-larger-than, -Walloca-larger-than): Change
options to take a HOST_WIDE_INT argument and accept a byte-size
suffix.  Initialize.
(-Wvla-larger-than): Same.
(-Wno-alloc-size-larger-than, -Wno-alloca-larger-than): New.
(-Wno-vla-larger-than): Same.


gcc/fortran/ChangeLog:

PR middle-end/82063
* gfortran.h (gfc_handle_option): Change function argument
to HOST_WIDE_INT.
* options.c (gfc_handle_option): Same.

gcc/go/ChangeLog:

PR middle-end/82063
* go-lang.c (go_langhook_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/lto/ChangeLog:

PR middle-end/82063
* lto-lang.c (lto_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/testsuite/ChangeLog:

PR middle-end/82063
* gcc.dg/Walloc-size-larger-than-16.c: Adjust.
* gcc.dg/Walloca-larger-than.c: New test.
* gcc.dg/Wframe-larger-than-2.c: New test.
* gcc.dg/Wlarger-than3.c: New test.
* gcc.dg/Wvla-larger-than-3.c: New test.

gcc/ChangeLog:

PR middle-end/82063
* builtins.c (expand_builtin_alloca): Adjust.
* calls.c (alloc_max_size): Simplify.
* cgraphunit.c (cgraph_node::expand): Adjust.
* common.opt (larger_than_size, warn_frame_larger_than): Remove
variables.
(frame_larger_than_size): Same.
(-Wframe-larger-than, -Wlarger-than, -Wstack-usage): Change options
to take a HOST_WIDE_INT argument and 

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063

--- Comment #11 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 20:51:20 2018
New Revision: 262910

URL: https://gcc.gnu.org/viewcvs?rev=262910=gcc=rev
Log:
PR middle-end/82063 - issues with arguments enabled by -Wall

gcc/ada/ChangeLog:

PR middle-end/82063
* gcc-interface/misc.c (gnat_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/brig/ChangeLog:

PR middle-end/82063
* brig/brig-lang.c (brig_langhook_handle_option): Change function
argument to HOST_WIDE_INT.

gcc/c-family/ChangeLog:

PR middle-end/82063
* c-common.h (c_common_handle_option): Change function argument
to HOST_WIDE_INT.
* c-opts.c (c_common_init_options): Same.
(c_common_handle_option): Same.  Remove special handling of
OPT_Walloca_larger_than_ and OPT_Wvla_larger_than_.
* c.opt (-Walloc-size-larger-than, -Walloca-larger-than): Change
options to take a HOST_WIDE_INT argument and accept a byte-size
suffix.  Initialize.
(-Wvla-larger-than): Same.
(-Wno-alloc-size-larger-than, -Wno-alloca-larger-than): New.
(-Wno-vla-larger-than): Same.

gcc/fortran/ChangeLog:

PR middle-end/82063
* gfortran.h (gfc_handle_option): Change function argument
to HOST_WIDE_INT.
* options.c (gfc_handle_option): Same.

gcc/go/ChangeLog:

PR middle-end/82063
* go-lang.c (go_langhook_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/lto/ChangeLog:

PR middle-end/82063
* lto-lang.c (lto_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/testsuite/ChangeLog:

PR middle-end/82063
* gcc/testsuite/c-c++-common/pr68657-1.c: Adjust.
* gcc/testsuite/c-c++-common/pr68657-2.c: Same.
* gcc/testsuite/c-c++-common/pr68657-3.c: Same.
* gcc.dg/Walloc-size-larger-than-16.c: Same.
* gcc.dg/Walloca-larger-than.c: New test.
* gcc.dg/Walloca-larger-than-2.c: New test.
* gcc.dg/Wframe-larger-than-2.c: New test.
* gcc.dg/Wlarger-than3.c: New test.
* gcc.dg/Wvla-larger-than-3.c: New test.
* gcc.dg/pr42611.c: Adjust.
* gnat.dg/frame_overflow.adb: Same.

gcc/ChangeLog:

PR middle-end/82063
* builtins.c (expand_builtin_alloca): Adjust.
* calls.c (alloc_max_size): Simplify.
* cgraphunit.c (cgraph_node::expand): Adjust.
* common.opt (larger_than_size, warn_frame_larger_than): Remove
variables.
(frame_larger_than_size): Same.
(-Wframe-larger-than, -Wlarger-than, -Wstack-usage): Change options
to take a HOST_WIDE_INT argument and accept a byte-size suffix.
Initialize.
* doc/invoke.texi (GCC Command Options): Document option arguments.
Explain byte-size arguments and suffixes.
(-Wvla-larger-than, -Wno-alloc-size-larger-than): Update.
(-Wno-alloca-larger-than, -Wno-vla-larger-than): Same.
(-Wframe-larger-than, -Wlarger-than, -Wstack-usage): Same.
* doc/options.texi (UInteger): Expand.
(Host_Wide_Int, ByteSize): Document new properties.
* final.c (final_start_function_1): Include sizes in an error message.
* function.c (frame_offset_overflow): Same.
* gimple-ssa-warn-alloca.c (pass_walloca::gate): Adjust.
(alloca_call_type_by_arg): Change function argument to HOST_WIDE_INT.
Diagnose unbounded alloca calls only for limits of less than
PTRDIFF_MAX.
(alloca_call_type): Adjust.  Diagnose possibly out-of-bounds alloca
calls and VLA size only for limits of less than PTRDIFF_MAX.  Same
for alloca(0).
(pass_walloca::execute): Adjust.  Diagnose alloca calls in loops
only for limits of less than PTRDIFF_MAX.
* langhooks-def.h (lhd_handle_option): Change function argument
to HOST_WIDE_INT.
* langhooks.c (lhd_handle_option): Same.
* langhooks.h (handle_option): Same.
* opt-functions.awk (switch_bit_fields): Handle Host_Wide_Int and
ByteSize flags.
(var_type, var_type_struct): Same.
(var_set): Handle ByteSize flag.
* optc-gen.awk: Add comments to output to ease debugging.  Make
use of HOST_WIDE_INT where appropriate.
* opts-gen-save.awk:  Use %lx to format unsigned long.
* opth-gen.awk: Change function argument to HOST_WIDE_INT.
* opts-common.c (integral_argument): Return HOST_WIDE_INT and add
arguments.  Parse bytes-size suffixes.
(enum_arg_to_value): Change function argument to HOST_WIDE_INT.
(enum_value_to_arg): Same.
(decode_cmdline_option): Handle cl_host_wide_int.  Adjust.
(handle_option): Adjust.
(generate_option): Change function argument to HOST_WIDE_INT.
(cmdline_handle_error): Adjust.

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[qinzhao at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519

--- Comment #7 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is:

for the following call to memcmp:   __builtin_memcmp (s->s, "a", 3);

the specified length 3 is larger than the length of "a", it's clearly a
out-of-bound access. This new testing case is try to claim that, For such
out-of-bound access, we should NOT expand this call at all. 

The new added in-lining expansion was prohibited under such situation, However,
the expansion to hardware compare insn (old code) is NOT prohibited under such
situation. 

on powerPC, the above call to memcmp is expanded to hardware compare insn.
therefore, the testing case failed.

[Bug testsuite/86616] New: [9 regression] c-c++-common/Warray-bounds-2.c fails starting with r262893

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86616

Bug ID: 86616
   Summary: [9 regression] c-c++-common/Warray-bounds-2.c fails
starting with r262893
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This test cases needs updating with this revision

> FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat  (test for excess errors)
> FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11 (test for excess errors)
> FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14 (test for excess errors)
> FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98 (test for excess errors)

One example:

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -O2 -Warray-bounds -Wno-stringop-overflow -S -o Warray-bounds-2.s
In function 'void wrap_memcpy_src_xsize(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void call_memcpy_src_xsize(char*, size_t)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:37:25:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:30:10:
warning: 'void* memcpy(void*, const void*, size_t)' offset 46 is out of the
bounds [0, 45] of object 'ar' with type 'Array' [-Warray-bounds]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c: In
function 'void call_memcpy_src_xsize(char*, size_t)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:35:16:
note: 'ar' declared here
In function 'void wrap_memcpy_src_diff_max(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void call_memcpy_src_diff_max(char*, const char*, size_t)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:51:28:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:46:10:
warning: 'void* memcpy(void*, const void*, size_t)' pointer overflow between
offset 9223372036854775807 and size 3 [-Warray-bounds]
In function 'void wrap_memcpy_dst_xsize(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void call_memcpy_dst_xsize(const char*, size_t)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:64:25:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:57:10:
warning: 'void* memcpy(void*, const void*, size_t)' offset 47 is out of the
bounds [0, 45] of object 'ar1' with type 'Array' [-Warray-bounds]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c: In
function 'void call_memcpy_dst_xsize(const char*, size_t)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:62:16:
note: 'ar1' declared here
In function 'void wrap_memcpy_dst_diff_max(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void call_memcpy_dst_diff_max(const char*, size_t)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:78:28:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:71:10:
warning: 'void* memcpy(void*, const void*, size_t)' offset -9223372036854775796
is out of the bounds [0, 45] of object 'ar2' with type 'Array' [-Warray-bounds]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c: In
function 'void call_memcpy_dst_diff_max(const char*, size_t)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:76:16:
note: 'ar2' declared here
In function 'void wrap_strcat_src_xsize(char*, const char*, ptrdiff_t)',
inlined from 'void call_strcat_src_xsize(char*)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:92:25:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:85:10:
warning: 'char* strcat(char*, const char*)' offset 46 is out of the bounds [0,
45] of object 'ar3' with type 'Array' [-Warray-bounds]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c: In
function 'void call_strcat_src_xsize(char*)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:90:16:
note: 'ar3' declared here
In function 'void wrap_strcat_dst_xsize(char*, const char*, ptrdiff_t)',
inlined from 'void call_strcat_dst_xsize(const char*)' at

[PATCH] libsanitizer: Mark REAL(swapcontext) with indirect_return attribute on x86

[H.J. Lu]

Cherry-pick compiler-rt revision 337603:

When shadow stack from Intel CET is enabled, the first instruction of all
indirect branch targets must be a special instruction, ENDBR.

lib/asan/asan_interceptors.cc has

...
  int res = REAL(swapcontext)(oucp, ucp);
...

REAL(swapcontext) is a function pointer to swapcontext in libc.  Since
swapcontext may return via indirect branch on x86 when shadow stack is
enabled, as in this case,

int res = REAL(swapcontext)(oucp, ucp);
    This function may be
returned via an indirect branch.

Here compiler must insert ENDBR after call, like

call *bar(%rip)
endbr64

I opened an LLVM bug:

https://bugs.llvm.org/show_bug.cgi?id=38207

to add the indirect_return attribute so that it can be used to inform
compiler to insert ENDBR after REAL(swapcontext) call.  We mark
REAL(swapcontext) with the indirect_return attribute if it is available.

This fixed:

https://bugs.llvm.org/show_bug.cgi?id=38249

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D49608

OK for trunk?

H.J.
---
PR target/86560
* asan/asan_interceptors.cc (swapcontext): Call REAL(swapcontext)
with indirect_return attribute on x86 if indirect_return attribute
is available.
* sanitizer_common/sanitizer_internal_defs.h (__has_attribute):
New.
---
 libsanitizer/asan/asan_interceptors.cc  | 8 
 libsanitizer/sanitizer_common/sanitizer_internal_defs.h | 5 +
 2 files changed, 13 insertions(+)

diff --git a/libsanitizer/asan/asan_interceptors.cc 
b/libsanitizer/asan/asan_interceptors.cc
index a8f4b72723f..552cf9347af 100644
--- a/libsanitizer/asan/asan_interceptors.cc
+++ b/libsanitizer/asan/asan_interceptors.cc
@@ -267,7 +267,15 @@ INTERCEPTOR(int, swapcontext, struct ucontext_t *oucp,
   uptr stack, ssize;
   ReadContextStack(ucp, , );
   ClearShadowMemoryForContextStack(stack, ssize);
+#if __has_attribute(__indirect_return__) && \
+(defined(__x86_64__) || defined(__i386__))
+  int (*real_swapcontext)(struct ucontext_t *, struct ucontext_t *)
+__attribute__((__indirect_return__))
+= REAL(swapcontext);
+  int res = real_swapcontext(oucp, ucp);
+#else
   int res = REAL(swapcontext)(oucp, ucp);
+#endif
   // swapcontext technically does not return, but program may swap context to
   // "oucp" later, that would look as if swapcontext() returned 0.
   // We need to clear shadow for ucp once again, as it may be in arbitrary
diff --git a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h 
b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
index edd6a21c122..4413a88bea0 100644
--- a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
+++ b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
@@ -104,6 +104,11 @@
 # define __has_feature(x) 0
 #endif
 
+// Older GCCs do not understand __has_attribute.
+#if !defined(__has_attribute)
+# define __has_attribute(x) 0
+#endif
+
 // For portability reasons we do not include stddef.h, stdint.h or any other
 // system header, but we do need some basic types that are not defined
 // in a portable way by the language itself.
-- 
2.17.1

RE: [RFC] Adding Python as a possible language and it's usage

[Konovalov, Vadim]

> From: Matthias Klose 
> To: Konovalov, Vadim; Segher Boessenkool;
> On 20.07.2018 20:53, Konovalov, Vadim wrote:
> > Sometimes those are not behind, those could have no python for other 
> > reasons - 
> > maybe those are too forward? They just don't have python yet?
> > 
> >>> it is straightforward.
> >>
> >> Installing it is not straightforward at all.
> > 
> > I also agree with this;
> 
> all == "Installing it is not straightforward" ?
> 
> I do question this. I mentioned elsewhere what is needed.

What is needed - not always presented.

> > Please consider that both Python - 2 and 3 - they both do not 
> > support build chain on Windows with GCC
> > 
> > for me, it is a showstopper
> 
> This seems to be a different issue.  However I have to say
> that I'm not booting
> Windows on a regular basis.  Does build chain on Windows
> means Cygwin?  If yes,
> there surely is Python available prebuilt.

Cygwin is very different platform, 
python rebuild on Cygwin is supported here, yes, but this is very 
different matter.

But I was talking about Windows, not Cygwin,

Rebuild of Python on windows (without Cygwin) not supported,
I was surprised to discover that and I will be gladly accept and use it
When it eventually will support GCC+Windows rebuild.

There are some blogs on Internet about someone who eventually 
did a build on windows with GCC, but - 
why this effort wasn't propagated into python mainstream?

Most of those mentioned blogs are from 2006 or 2008; rather obsolete and could 
not be easily reused

https://wiki.python.org/moin/WindowsCompilers

mentions
GCC - MinGW (x86)
MinGW is an alternative C/C++ compiler that works with all Python versions up 
to 3.4.

BUT this is just fake - no, the instruction is unfinished and does not work 
even supposed to work

> Matthias

[Bug c/86615] gcc build failure: auto-host.h error: declaration does not declare anything [-fpermissive]

[mdenber at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86615

--- Comment #1 from Michele Denber  ---
Forgot to add I'm already using:

# echo $CFLAGS
-fpermissive
# echo $CXXFLAGS
-fpermissive
#

Then just "gmake".

Go patch committed: Fix order of evaluation of boolean expressions

[Ian Lance Taylor]

This patch by Cherry Zhang changes the Go frontend to run the
order_evaluations before the remove_shortcuts pass.

In remove_shortcuts, the shortcut expressions (&&, ||) are rewritten
to if statements, which are lifted out before the statement containing
the shortcut expression.  If the containing statement has other
(sub)expressions that should be evaluated before the shortcut
expression, which has not been lifted out, this will result in
incorrect evaluation order.

For example, F() + G(A() && B()), the evaluation order per the
language spec is F, A, B (if A returns true), G. If we lift A() and
B() out first, they will be called before F, which is wrong.

To fix this, this patch splits order_evaluations to two phases.  The
first phase, which runs before remove_shortcuts, skips shortcut
expressions' components.  So it won't lift out subexpressions that are
evaluated conditionally.  The shortcut expression itself is ordered,
since it may have side effects.  Then we run remove_shortcuts.  At
this point the subexpressions that should be evaluated before the
shortcut expression are already lifted out.  The remove_shortcuts pass
also runs the second phase of order_evaluations to order the
components of shortcut expressions, which were skipped during the
first phase.

This reorders the code blocks of remove_shortcuts and
order_evaluations, since remove_shortcuts now calls Order_eval.

This fixes https://golang.org/issue/26495.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 262833)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-38850073f25f9de4f3daa33d799def3a33c942ab
+39d4d755db7d71b5e770ca435a8b1d1f08f53185
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/go.cc
===
--- gcc/go/gofrontend/go.cc (revision 262658)
+++ gcc/go/gofrontend/go.cc (working copy)
@@ -143,12 +143,12 @@ go_parse_input_files(const char** filena
   // Export global identifiers as appropriate.
   ::gogo->do_exports();
 
-  // Turn short-cut operators (&&, ||) into explicit if statements.
-  ::gogo->remove_shortcuts();
-
   // Use temporary variables to force order of evaluation.
   ::gogo->order_evaluations();
 
+  // Turn short-cut operators (&&, ||) into explicit if statements.
+  ::gogo->remove_shortcuts();
+
   // Convert named types to backend representation.
   ::gogo->convert_named_types();
 
Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc   (revision 262658)
+++ gcc/go/gofrontend/gogo.cc   (working copy)
@@ -3432,210 +3432,6 @@ Gogo::check_types_in_block(Block* block)
   block->traverse();
 }
 
-// A traversal class used to find a single shortcut operator within an
-// expression.
-
-class Find_shortcut : public Traverse
-{
- public:
-  Find_shortcut()
-: Traverse(traverse_blocks
-  | traverse_statements
-  | traverse_expressions),
-  found_(NULL)
-  { }
-
-  // A pointer to the expression which was found, or NULL if none was
-  // found.
-  Expression**
-  found() const
-  { return this->found_; }
-
- protected:
-  int
-  block(Block*)
-  { return TRAVERSE_SKIP_COMPONENTS; }
-
-  int
-  statement(Block*, size_t*, Statement*)
-  { return TRAVERSE_SKIP_COMPONENTS; }
-
-  int
-  expression(Expression**);
-
- private:
-  Expression** found_;
-};
-
-// Find a shortcut expression.
-
-int
-Find_shortcut::expression(Expression** pexpr)
-{
-  Expression* expr = *pexpr;
-  Binary_expression* be = expr->binary_expression();
-  if (be == NULL)
-return TRAVERSE_CONTINUE;
-  Operator op = be->op();
-  if (op != OPERATOR_OROR && op != OPERATOR_ANDAND)
-return TRAVERSE_CONTINUE;
-  go_assert(this->found_ == NULL);
-  this->found_ = pexpr;
-  return TRAVERSE_EXIT;
-}
-
-// A traversal class used to turn shortcut operators into explicit if
-// statements.
-
-class Shortcuts : public Traverse
-{
- public:
-  Shortcuts(Gogo* gogo)
-: Traverse(traverse_variables
-  | traverse_statements),
-  gogo_(gogo)
-  { }
-
- protected:
-  int
-  variable(Named_object*);
-
-  int
-  statement(Block*, size_t*, Statement*);
-
- private:
-  // Convert a shortcut operator.
-  Statement*
-  convert_shortcut(Block* enclosing, Expression** pshortcut);
-
-  // The IR.
-  Gogo* gogo_;
-};
-
-// Remove shortcut operators in a single statement.
-
-int
-Shortcuts::statement(Block* block, size_t* pindex, Statement* s)
-{
-  // FIXME: This approach doesn't work for switch statements, because
-  // we add the new statements before the whole switch when we need to
-  // instead add them just before the switch expression.  The right
-  // fix is probably to lower switch statements 

[Bug c/86615] New: gcc build failure: auto-host.h error: declaration does not declare anything [-fpermissive]

[mdenber at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86615

Bug ID: 86615
   Summary: gcc build failure:  auto-host.h error: declaration
does not declare anything [-fpermissive]
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdenber at gmx dot com
  Target Milestone: ---

On a Sun Enterprise M3000 SPARC64 VII running Solaris 10U11 with opencsw build
tools, I am trying to build gcc 6.4.0 using gcc 4.9.2.  I get the following
errors.  There seems to be two other references here to this "fpermissive"
stuff, bugs 56954 and 82590.  One of these got no replies, the other did not
apply to 6.4.0 and the suggestion was to just comment out the offending lines
in the source code.

I'm also getting two other "conflicting declaration" errors.


gmake[3]: Entering directory
'/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/gcc'
/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/prev-gcc/xg++
-B/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/prev-gcc/
-B/usr/local/sparc-sun-solaris2.10/bin/ -nostdinc++
-B/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-B/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
-I/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10
-I/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include
-I/export/home/michele/gcc-6.4.0/libstdc++-v3/libsupc++
-L/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-L/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
-c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../.././gcc -I../.././gcc/build
-I../.././gcc/../include -I./../intl -I../.././gcc/../libcpp/include \
-o build/genmddeps.o ../.././gcc/genmddeps.c
In file included from ./bconfig.h:3:0,
from ../.././gcc/genmddeps.c:18:
./auto-host.h:2321:16: error: declaration does not declare anything
[-fpermissive]
#define rlim_t long
^
In file included from ../.././gcc/genmddeps.c:19:0:
../.././gcc/system.h:496:48: error: ‘char* strstr(const char*, const char*)’
conflicts with a previous declaration
extern char strstr (const char , const char *);
^
In file included from /usr/include/string.h:18:0,
from
/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/cstring:42,
from ../.././gcc/system.h:235,
from ../.././gcc/genmddeps.c:19:
/usr/include/iso/string_iso.h:119:20: note: previous declaration ‘const char*
std::strstr(const char*, const char*)’
extern const char strstr(const char , const char *);
^~
In file included from ../.././gcc/genmddeps.c:19:0:
../.././gcc/system.h:540:20: error: conflicting declaration of C function
‘const char* strsignal(int)’
extern const char *strsignal (int);
^
In file included from
/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/cstring:42:0,
from ../.././gcc/system.h:235,
from ../.././gcc/genmddeps.c:19:
/usr/include/string.h:79:14: note: previous declaration ‘char* strsignal(int)’
extern char *strsignal(int);
^
gmake[3]: *** [Makefile:2497: build/genmddeps.o] Error 1
gmake[3]: Leaving directory
'/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/gcc'
gmake[2]: *** [Makefile:4425: all-stage2-gcc] Error 2
gmake[2]: Leaving directory '/export/home/michele/gcc-6.4.0'
gmake[1]: *** [Makefile:21971: stage2-bubble] Error 2
gmake[1]: Leaving directory '/export/home/michele/gcc-6.4.0'
gmake: *** [Makefile:909: all] Error 2
#

[PATCH,rs6000] AIX test fixes 2

[Carl Love]

GCC maintainers:

The following patch fixes errors on AIX for the "vector double" tests
in altivec-1-runnable.c file.  The type "vector double" requires the
use of the GCC command line option -mvsx. The vector double tests
in altivec-1-runnable.c should be in altivec-2-runnable.c.  It looks
like my Linux testing of the original patch worked because I configured
GCC by default with -mcpu=power8.  AIX is not using that as the default
processor thus causing the compile of altivec-1-runnable.c to fail.

The vec_or tests in builtins-1.c were moved to another file by a
previous patch.  The vec_or test generated the xxlor instruction.  The
count of the xxlor instruction varies depending on the target as it is
used as a move instruction.  No other tests generate the xxlor
instruction. Hence, the count check was removed.

The patch has been tested on 

powerpc64le-unknown-linux-gnu (Power 8 LE) 
powerpc64-unknown-linux-gnu (Power 8 BE)
AIX (Power 8)

With no regressions.

Please let me know if the patch looks OK for trunk.

 Carl Love



gcc/testsuite/ChangeLog:

2018-07-20  Carl Love  

* gcc.target/powerpc/altivec-1-runnable.c: Move vector double tests to
file altivec-2-runnable.c.
* gcc.target/powerpc/altivec-2-runnable.c: Add vector double tests.
* gcc.target/powerpc/buitlins-1.c: Remove check for xxlor.  Add linux 
and AIX
targets for divdi3 and udivdi3 instructions.
---
 .../gcc.target/powerpc/altivec-1-runnable.c| 50 --
 .../gcc.target/powerpc/altivec-2-runnable.c| 49 -
 gcc/testsuite/gcc.target/powerpc/builtins-1.c  |  9 ++--
 3 files changed, 52 insertions(+), 56 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c 
b/gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c
index bb913d2..da8ebbc 100644
--- a/gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c
@@ -31,16 +31,9 @@ int main ()
   vector signed int vec_si_result, vec_si_expected;
   vector signed char vec_sc_arg;
   vector signed char vec_sc_result, vec_sc_expected;
-  vector float vec_float_arg;
-  vector double vec_double_result, vec_double_expected;
   vector pixel vec_pixel_arg;
   vector unsigned int vec_ui_result, vec_ui_expected;
 
-  union conv {
-     double d;
-     unsigned long long l;
-  } conv_exp, conv_val;
-
   vec_bs_arg = (vector bool short){ 0, 101, 202, 303,
    404, 505, 606, 707 };
   vec_bi_expected = (vector bool int){ 0, 101, 202, 303 };
@@ -209,49 +202,6 @@ int main ()
abort();
 #endif
   }
-  
-
-  vec_float_arg = (vector float){ 0.0, 1.5, 2.5, 3.5 };
-
-  vec_double_expected = (vector double){ 0.0, 1.5 };
-
-  vec_double_result = vec_unpackh (vec_float_arg);
-
-  for (i = 0; i < 2; i++) {
-if (vec_double_expected[i] != vec_double_result[i])
-  {
-#if DEBUG
-    printf("ERROR: vec_unpackh(), vec_double_expected[%d] = %f does not 
match vec_double_result[%d] = %f\n",
-   i, vec_double_expected[i], i, vec_double_result[i]);
-    conv_val.d = vec_double_result[i];
-    conv_exp.d = vec_double_expected[i];
-    printf(" vec_unpackh(), vec_double_expected[%d] = 0x%llx does not 
match vec_double_result[%d] = 0x%llx\n",
-   i, conv_exp.l, i,conv_val.l);
-#else
-    abort();
-#endif
-}
-  }
-
-  vec_double_expected = (vector double){ 2.5, 3.5 };
-
-  vec_double_result = vec_unpackl (vec_float_arg);
-
-  for (i = 0; i < 2; i++) {
-if (vec_double_expected[i] != vec_double_result[i])
-  {
-#if DEBUG
- printf("ERROR: vec_unpackl() vec_double_expected[%d] = %f does not 
match vec_double_result[%d] = %f\n",
-   i, vec_double_expected[i], i, vec_double_result[i]);
-    conv_val.d = vec_double_result[i];
-    conv_exp.d = vec_double_expected[i];
-    printf(" vec_unpackh(), vec_double_expected[%d] = 0x%llx does not 
match vec_double_result[%d] = 0x%llx\n",
-   i, conv_exp.l, i,conv_val.l);
-#else
- abort();
-#endif
-  }
-  }
 
   return 0;
 }
diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c 
b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
index 9d8aad4..041edcb 100644
--- a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
@@ -23,8 +23,15 @@ int main ()
 
   vector signed int vec_si_arg;
   vector signed long long int vec_slli_result, vec_slli_expected;
+  vector float vec_float_arg;
+  vector double vec_double_result, vec_double_expected;
 
-  /*  use of ‘long long’ in AltiVec types requires -mvsx */
+  union conv {
+     double d;
+     unsigned long long l;
+  } conv_exp, conv_val;
+
+  /* Use of 'double' and ‘long long’ in AltiVec types requires -mvsx */
   /* 

Re: [RFC] Adding Python as a possible language and it's usage

[Matthias Klose]

On 20.07.2018 20:53, Konovalov, Vadim wrote:
>> From: Segher Boessenkool
>> On Fri, Jul 20, 2018 at 12:54:36PM -0400, Paul Koning wrote:
> Fully agree with that. Coming up with a new scripts written in python2 
> really
> makes no sense.

 Then python cannot be a build requirement for GCC, since some of our
 primary targets do not ship python3.
>>>
>>> Is it required that GCC must build with only the stock
>>> support elements on the primary target platforms?
>>
>> Not that I know.  But why
>> should we make it hugely harder for essentially
>> no benefit?
>>
>> All the arguments
>> against awk were arguments against *the current scripts*.
>>
>> And yes, we can (and
>> perhaps should) rewrite those build scripts as C code,
>> just like all the other
>> gen* we have.
> 
> +1 
> 
>>> Or is it allowed to require installing prerequisites?  Yes,
>>> some platforms are so far behind they still don't ship Python 3, but 
>>> installing
> 
> Sometimes those are not behind, those could have no python for other reasons 
> - 
> maybe those are too forward? They just don't have python yet?
> 
>>> it is straightforward.
>>
>> Installing it is not straightforward at all.
> 
> I also agree with this;

all == "Installing it is not straightforward" ?

I do question this. I mentioned elsewhere what is needed.

> Please consider that both Python - 2 and 3 - they both do not 
> support build chain on Windows with GCC
> 
> for me, it is a showstopper

This seems to be a different issue.  However I have to say that I'm not booting
Windows on a regular basis.  Does build chain on Windows means Cygwin?  If yes,
there surely is Python available prebuilt.

Matthias

Re: O2 Agressive Optimisation by GCC

[Martin Sebor]

On 07/20/2018 12:17 PM, Richard Biener wrote:

On July 20, 2018 7:59:10 PM GMT+02:00, Martin Sebor  wrote:

On 07/20/2018 06:19 AM, Umesh Kalappa wrote:

Hi All ,

We are looking at the C sample i.e

extern int i,j;

int test()
{
while(1)
{   i++;
j=20;
}
return 0;
}

command used :(gcc 8.1.0)
gcc -S test.c -O2

the generated asm for x86

.L2:
jmp .L2

we understand that,the infinite loop is not  deterministic ,compiler
is free to treat as that as UB and do aggressive optimization ,but we
need keep the side effects like j=20 untouched by optimization .

Please note that using the volatile qualifier for i and j  or empty
asm("") in the while loop,will stop the optimizer ,but we don't want
do  that.

Anyone from the community ,please share their insights why above
transformation is right ?


The loop isn't necessarily undefined (and compilers don't look
for undefined behavior as opportunities to optimize code), but


The variable i overflows.


Good point!

It doesn't change the answer or the behavior of any compiler
I tested (although ICC and Oracle cc both emit the assignment
as well as the increment regardless of whether the variables
are signed).  I don't think it should change it either.

Going further, and as much value as I put on diagnosing bugs,
I also wouldn't see it as helpful to diagnose this kind of
eliminated undefined behavior (so long as the result of
the overflow wasn't used).  What might be helpful, though,
is diagnosing the infinite loop similarly to IBM xlc and
Oracle cc.  Maybe not in the constant case but in the non-
constant cases if might help catch bugs.

Martin




because it doesn't terminate it's not possible for a conforming
C program to detect the side-effects in its body.  The only way
to detect it is to examine the object code as you did.


I'm not sure we perform this kind of dead code elimination but yes, we could. 
Make i unsigned and check whether that changes behavior.


Compilers are allowed (and expected) to transform source code
into efficient object code as long as the transformations don't
change the observable effects of the program.  That's just what
happens in this case.

Martin

RE: [RFC] Adding Python as a possible language and it's usage

[Konovalov, Vadim]

> From: Segher Boessenkool
> On Fri, Jul 20, 2018 at 12:54:36PM -0400, Paul Koning wrote:
> > >> Fully agree with that. Coming up with a new scripts written in python2 
> > >> really
> > >> makes no sense.
> > > 
> > > Then python cannot be a build requirement for GCC, since some of our
> > > primary targets do not ship python3.
> > 
> > Is it required that GCC must build with only the stock
> > support elements on the primary target platforms?
> 
> Not that I know.  But why
> should we make it hugely harder for essentially
> no benefit?
> 
> All the arguments
> against awk were arguments against *the current scripts*.
> 
> And yes, we can (and
> perhaps should) rewrite those build scripts as C code,
> just like all the other
> gen* we have.

+1 

> > Or is it allowed to require installing prerequisites?  Yes,
> > some platforms are so far behind they still don't ship Python 3, but 
> > installing

Sometimes those are not behind, those could have no python for other reasons - 
maybe those are too forward? They just don't have python yet?

> > it is straightforward.
> 
> Installing it is not straightforward at all.

I also agree with this;

Please consider that both Python - 2 and 3 - they both do not 
support build chain on Windows with GCC

for me, it is a showstopper

[Bug middle-end/78809] Inline strcmp with small constant strings

[qinzhao at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809

--- Comment #42 from qinzhao at gcc dot gnu.org ---
just checked in the patch for fixing the unsigned char issue as:
https://gcc.gnu.org/viewcvs/gcc?view=revision=262907

Re: [PATCH][Middle-end][version 2]change char type to unsigned char type when expanding strcmp/strncmp

[Qing Zhao]

the patch was committed as:

https://gcc.gnu.org/viewcvs/gcc?view=revision=262907 


thanks.

Qing
> On Jul 20, 2018, at 9:59 AM, Jakub Jelinek  wrote:
> 
> On Fri, Jul 20, 2018 at 09:53:24AM -0500, Qing Zhao wrote:
>> +2018-07-20  Qing Zhao  
>> +
>> +   * builtins.c (expand_builtin_memcmp): Delete the last parameter for
>> +   call to inline_expand_builtin_string_cmp.
>> +   (expand_builtin_strcmp): Likewise.
>> +   (expand_builtin_strncmp): Likewise.
>> +   (inline_string_cmp): Delete the last parameter, change char_type_node
>> +   to unsigned_char_type_node for strcmp/strncmp, add conversions to the
>> +   two operands.
>> +   (inline_expand_builtin_string_cmp): Delete the last parameter, give 
>> up
>> +   the inlining expansion on target where the type of the call has same 
>> or 
>> +   narrower presicion than unsigned char.
> 
> s/presicion/precision/
> 
> Also in the patch, where there is another typo, s/of/or/.
> 
> Ok for trunk with that fixed.
> 
>   Jakub

Re: O2 Agressive Optimisation by GCC

[Richard Biener]

On July 20, 2018 7:59:10 PM GMT+02:00, Martin Sebor  wrote:
>On 07/20/2018 06:19 AM, Umesh Kalappa wrote:
>> Hi All ,
>>
>> We are looking at the C sample i.e
>>
>> extern int i,j;
>>
>> int test()
>> {
>> while(1)
>> {   i++;
>> j=20;
>> }
>> return 0;
>> }
>>
>> command used :(gcc 8.1.0)
>> gcc -S test.c -O2
>>
>> the generated asm for x86
>>
>> .L2:
>> jmp .L2
>>
>> we understand that,the infinite loop is not  deterministic ,compiler
>> is free to treat as that as UB and do aggressive optimization ,but we
>> need keep the side effects like j=20 untouched by optimization .
>>
>> Please note that using the volatile qualifier for i and j  or empty
>> asm("") in the while loop,will stop the optimizer ,but we don't want
>> do  that.
>>
>> Anyone from the community ,please share their insights why above
>> transformation is right ?
>
>The loop isn't necessarily undefined (and compilers don't look
>for undefined behavior as opportunities to optimize code), but

The variable i overflows.

>because it doesn't terminate it's not possible for a conforming
>C program to detect the side-effects in its body.  The only way
>to detect it is to examine the object code as you did.

I'm not sure we perform this kind of dead code elimination but yes, we could. 
Make i unsigned and check whether that changes behavior. 

>Compilers are allowed (and expected) to transform source code
>into efficient object code as long as the transformations don't
>change the observable effects of the program.  That's just what
>happens in this case.
>
>Martin

[PATCH] i386: Remove _Unwind_Frames_Increment

[H.J. Lu]

Tested on CET SDV using the CET kernel on cet branch at:

https://github.com/yyu168/linux_cet/tree/cet

OK for trunk and GCC 8 branch?

Thanks.


H.J.
---
The CET kernel has been changed to place a restore token on shadow stack
for signal handler to enhance security.  It is usually transparent to user
programs since kernel will pop the restore token when signal handler
returns.  But when an exception is thrown from a signal handler, now
we need to remove _Unwind_Frames_Increment to pop the the restore token
from shadow stack.  Otherwise, we get

FAIL: g++.dg/torture/pr85334.C   -O0  execution test
FAIL: g++.dg/torture/pr85334.C   -O1  execution test
FAIL: g++.dg/torture/pr85334.C   -O2  execution test
FAIL: g++.dg/torture/pr85334.C   -O3 -g  execution test
FAIL: g++.dg/torture/pr85334.C   -Os  execution test
FAIL: g++.dg/torture/pr85334.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test

PR libgcc/85334
* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
Removed.
---
 libgcc/config/i386/shadow-stack-unwind.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libgcc/config/i386/shadow-stack-unwind.h 
b/libgcc/config/i386/shadow-stack-unwind.h
index a32f3e74b52..40f48df2aec 100644
--- a/libgcc/config/i386/shadow-stack-unwind.h
+++ b/libgcc/config/i386/shadow-stack-unwind.h
@@ -49,8 +49,3 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
}   \
 }  \
 while (0)
-
-/* Increment frame count.  Skip signal frames.  */
-#undef _Unwind_Frames_Increment
-#define _Unwind_Frames_Increment(context, frames) \
-  if (!_Unwind_IsSignalFrame (context)) frames++
-- 
2.17.1

Re: O2 Agressive Optimisation by GCC

[Martin Sebor]

On 07/20/2018 06:19 AM, Umesh Kalappa wrote:

Hi All ,

We are looking at the C sample i.e

extern int i,j;

int test()
{
while(1)
{   i++;
j=20;
}
return 0;
}

command used :(gcc 8.1.0)
gcc -S test.c -O2

the generated asm for x86

.L2:
jmp .L2

we understand that,the infinite loop is not  deterministic ,compiler
is free to treat as that as UB and do aggressive optimization ,but we
need keep the side effects like j=20 untouched by optimization .

Please note that using the volatile qualifier for i and j  or empty
asm("") in the while loop,will stop the optimizer ,but we don't want
do  that.

Anyone from the community ,please share their insights why above
transformation is right ?


The loop isn't necessarily undefined (and compilers don't look
for undefined behavior as opportunities to optimize code), but
because it doesn't terminate it's not possible for a conforming
C program to detect the side-effects in its body.  The only way
to detect it is to examine the object code as you did.

Compilers are allowed (and expected) to transform source code
into efficient object code as long as the transformations don't
change the observable effects of the program.  That's just what
happens in this case.

Martin

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590

--- Comment #27 from Jakub Jelinek  ---
Created attachment 44415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44415=edit
gcc9-p0595r1.patch

Untested patch that passes the testcase in P0595R1.

[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510

[willschm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592

Will Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

[Bug c++/86610] [8/9 Regression] non-const operator erroneously called in lambda in templated function

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86610

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||rejects-valid
   Last reconfirmed||2018-07-20
 CC||nathan at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|non-const operator  |[8/9 Regression] non-const
   |erroneously called in   |operator erroneously called
   |lambda in templated |in lambda in templated
   |function|function
  Known to fail||8.1.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
Seems to have started with r255605

[PR C++/15272] lookups with ambiguating dependent base

https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00766.html
PR c++/15272
* pt.c (tsubst_baselink): Don't repeat the lookup for
non-dependent baselinks.

PR c++/15272
* g++.dg/template/pr71826.C: Adjust for 15272 fix.

Re: [RFC] Adding Python as a possible language and it's usage

[Segher Boessenkool]

On Fri, Jul 20, 2018 at 12:54:36PM -0400, Paul Koning wrote:
> 
> 
> > On Jul 20, 2018, at 12:37 PM, Segher Boessenkool 
> >  wrote:
> > 
> > On Fri, Jul 20, 2018 at 11:49:05AM +0200, Martin Liška wrote:
> >> Fully agree with that. Coming up with a new scripts written in python2 
> >> really
> >> makes no sense.
> > 
> > Then python cannot be a build requirement for GCC, since some of our
> > primary targets do not ship python3.
> 
> Is it required that GCC must build with only the stock support elements on 
> the primary target platforms?

Not that I know.  But why should we make it hugely harder for essentially
no benefit?

All the arguments against awk were arguments against *the current scripts*.

And yes, we can (and perhaps should) rewrite those build scripts as C code,
just like all the other gen* we have.

> Or is it allowed to require installing prerequisites?  Yes, some platforms 
> are so far behind they still don't ship Python 3, but installing it is 
> straightforward.

Installing it is not straightforward at all.


Segher

Re: [PATCH] restore -Warray-bounds for string literals (PR 83776)

[Martin Sebor]

On 07/20/2018 05:34 AM, Rainer Orth wrote:

Hi Martin,


On 07/19/2018 03:51 PM, Jeff Law wrote:

On 07/13/2018 05:45 PM, Martin Sebor wrote:


+  offset_int ofr[] = {
+   wi::to_offset (fold_convert (ptrdiff_type_node, vr->min)),
+   wi::to_offset (fold_convert (ptrdiff_type_node, vr->max))
+  };

huh.  Do you maybe want to use widest_int for ofr[]?  What's
wrong with wi::to_offset (vr->min)?  Building another intermediate
tree node here looks just bogus.


I need to convert size_type indices to signed to keep their sign
if it's negative and include it in warnings.  I've moved the code
into a conditional where it's used to minimize the cost but other
than that I don't know how else to convert it.



What are you trying to do in this loop anyways?


The loop It determines the range of the final index/offset for
a series of POINTER_PLUS_EXPRs.  It handles cases like this:

  int g (int i, int j, int k)
  {
if (i < 1) i = 1;
if (j < 1) j = 1;
if (k < 1) k = 1;

const char *p0 = "123";
const char *p1 = p0 + i;
const char *p2 = p1 + j;
const char *p3 = p2 + k;

// p2[3] and p3[1] are out of bounds
return p0[4] + p1[3] + p2[2] + p3[1];
  }


I suppose
look at

  p_1 = [i_2];  // already bounds-checked, but with ignore_off_by_one
  ... = MEM[p_1 + CST];

?  But then

+  if (TREE_CODE (varoff) != SSA_NAME)
+   break;

you should at least handle INTEGER_CSTs here?


It's already handled (and set in CSTOFF).  There should be no
more constant offsets after that (I haven't come across any.)



+  if (!vr || vr->type == VR_UNDEFINED || !vr->min || !vr->max)
+   break;

please use positive tests here, VR_RANGE || VR_ANTI_RANGE.  As usual
the anti-range handling looks odd.  Please add comments so we can follow
what you were thinking when writing range merging code.  Even better if you

can stick to use existing code rather than always re-inventing the wheel...



The anti-range handling is to conservatively add
[-MAXOBJSIZE -1, MAXOBJSIZE] to OFFRANGE.  I've added comments
to make it clear.  I'd be more than happy to reuse existing
code if I knew where to find it (if it exists).  It sure would
save me lots of work to have a library of utility functions to
call instead of rolling my own code each time.

Finding stuff is never easy :(  GCC's just gotten so big it's virtually
impossible for anyone to know all the APIs.

The suggestion I'd have would be to (when possible) factor this stuff
into routines you can reuse.  We (as a whole) have this tendency to
open-code all kinds of things rather than factoring the code into
reusable routines.

In addition to increasing the probability that you'll be able to reuse
code later, just reading a new function's header tends to make me (as a
reviewer) internally ask if there's already a routine we should be using
instead.  When it's open-coded it's significantly harder to spot those
cases (at least for me).






I think I commented on earlier variants but this doesn't seem to resemble
any of them.


I've reworked the patch (sorry) to also handle arrays.  For GCC
9 it seems I might as well do both in one go.

Attached is an updated patch with these changes.

Martin

gcc-83776.diff


PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds
index into an array
PR tree-optimization/83776 - missing -Warray-bounds indexing past the
end of a string literal

gcc/ChangeLog:

PR tree-optimization/84047
PR tree-optimization/83776
* tree-vrp.c (vrp_prop::check_mem_ref): New function.
(check_array_bounds): Call it.
* /gcc/tree-sra.c (get_access_for_expr): Fail for out-of-bounds
array offsets.

gcc/testsuite/ChangeLog:

PR tree-optimization/83776
PR tree-optimization/84047
* gcc.dg/Warray-bounds-29.c: New test.
* gcc.dg/Warray-bounds-30.c: New test.
* gcc.dg/Warray-bounds-31.c: New test.
* gcc.dg/Warray-bounds-32.c: New test.




diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 3e30f6b..8221a06 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -3110,6 +3110,19 @@ get_access_for_expr (tree expr)
   || !DECL_P (base))
 return NULL;

+  /* Fail for out-of-bounds array offsets.  */
+  tree basetype = TREE_TYPE (base);
+  if (TREE_CODE (basetype) == ARRAY_TYPE)
+{
+  if (offset < 0)
+   return NULL;
+
+  if (tree size = DECL_SIZE (base))
+   if (tree_fits_uhwi_p (size)
+   && tree_to_uhwi (size) < (unsigned HOST_WIDE_INT) offset)
+ return NULL;
+}
+
   if (!bitmap_bit_p (candidate_bitmap, DECL_UID (base)))
 return NULL;

So I'm a bit curious about this hunk.  Did we end up creating an access
structure that walked off the end of the array?  Presumably  you
suppressing SRA at this point so that you can see the array access later
and give a suitable warning.  Right?


Yes, but I didn't make a note of the test case that triggered
it and I'm not able to trigger the code path 

[Bug tree-optimization/86614] New: duplicate -Warray-bounds for a strncpy call with out-of-bounds offset

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86614

Bug ID: 86614
   Summary: duplicate -Warray-bounds for a strncpy  call with
out-of-bounds offset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With the recent enhancement to -Warray-bounds (bug 84047) GCC issues duplicate
instances of the warning for calls to some built-in functions with out-of-bound
offsets.  The following test case was isolated from
c-c++-common/Warray-bounds-2.c (r262906 prunes these duplicates from the test
to avoid spurious failures).

$ cat c.c && gcc -O2 -S -Warray-bounds c.c
extern char* strncpy (char*, const char*, __SIZE_TYPE__);

void sink (void*);

struct { char b[17]; } a[2];

void g (const char *s, unsigned n)
{
  int i = (char*)a[1].b - (char*)a + 1;
  char *d = a[1].b;
  strncpy (d + i, s, n);
}
c.c: In function ‘g’:
c.c:11:3: warning: array subscript 35 is outside array bounds of ‘struct
[2]’ [-Warray-bounds]
   strncpy (d + i, s, n);
   ^
c.c:11:3: warning: ‘strncpy’ offset 35 is out of the bounds [0, 34] of object
‘a’ with type ‘struct [2]’ [-Warray-bounds]
c.c:5:24: note: ‘a’ declared here
 struct { char b[17]; } a[2];
^

Re: [RFC] Adding Python as a possible language and it's usage

[Paul Koning]

> On Jul 20, 2018, at 12:37 PM, Segher Boessenkool  
> wrote:
> 
> On Fri, Jul 20, 2018 at 11:49:05AM +0200, Martin Liška wrote:
>> Fully agree with that. Coming up with a new scripts written in python2 really
>> makes no sense.
> 
> Then python cannot be a build requirement for GCC, since some of our
> primary targets do not ship python3.

Is it required that GCC must build with only the stock support elements on the 
primary target platforms?  Or is it allowed to require installing 
prerequisites?  Yes, some platforms are so far behind they still don't ship 
Python 3, but installing it is straightforward.

paul

[PATCH 2/2] condition_variable: Use steady_clock to implement wait_for

[Mike Crowe]

I believe[1][2] that the C++ standard says that
std::condition_variable::wait_for should be implemented to be equivalent
to:

 return wait_until(lock, chrono::steady_clock::now() + rel_time);

But the existing implementation uses chrono::system_clock. Now that
wait_until has potentially-different behaviour for chrono::steady_clock,
let's at least try to wait using the correct clock.

[1] https://en.cppreference.com/w/cpp/thread/condition_variable/wait_for
[2] https://github.com/cplusplus/draft/blob/master/source/threads.tex
---
 libstdc++-v3/ChangeLog  | 3 +++
 libstdc++-v3/include/std/condition_variable | 5 +++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 4657af7..432cb84 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,4 +1,7 @@
 2018-07-20  Mike Crowe 
+   * include/std/condition_variable (wait_for): Use steady_clock.
+
+2018-07-20  Mike Crowe 
* include/std/condition_variable (wait_until): Only report timeout
if we really have timed out when measured against the
caller-supplied clock.
diff --git a/libstdc++-v3/include/std/condition_variable 
b/libstdc++-v3/include/std/condition_variable
index a2d146a..ce58399 100644
--- a/libstdc++-v3/include/std/condition_variable
+++ b/libstdc++-v3/include/std/condition_variable
@@ -65,6 +65,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   class condition_variable
   {
 typedef chrono::system_clock   __clock_t;
+typedef chrono::steady_clock   __steady_clock_t;
 typedef __gthread_cond_t   __native_type;

 #ifdef __GTHREAD_COND_INIT
@@ -142,11 +143,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   wait_for(unique_lock& __lock,
   const chrono::duration<_Rep, _Period>& __rtime)
   {
-   using __dur = typename __clock_t::duration;
+   using __dur = typename __steady_clock_t::duration;
auto __reltime = chrono::duration_cast<__dur>(__rtime);
if (__reltime < __rtime)
  ++__reltime;
-   return wait_until(__lock, __clock_t::now() + __reltime);
+   return wait_until(__lock, __steady_clock_t::now() + __reltime);
   }

 template
--
git-series 0.9.1
BrightSign considers your privacy to be very important. The emails you send to 
us will be protected and secured. Furthermore, we will only use your email and 
contact information for the reasons you sent them to us and for tracking how 
effectively we respond to your requests.

[PATCH 1/2] condition_variable: Report early wakeup of wait_until as no_timeout

[Mike Crowe]

As currently implemented, condition_variable always ultimately waits
against std::chrono::system_clock. This clock can be changed in arbitrary
ways by the user which may result in us waking up too early or too late
when measured against the caller-supplied clock.

We can't (yet) do much about waking up too late[1], but
if we wake up too early we must return cv_status::no_timeout to indicate a
spurious wakeup rather than incorrectly returning cv_status::timeout.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
---
 libstdc++-v3/ChangeLog|  7 +++
 libstdc++-v3/include/std/condition_variable   |  8 +++-
 libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc | 52 

 3 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index c9cd62a..4657af7 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,10 @@
+2018-07-20  Mike Crowe 
+   * include/std/condition_variable (wait_until): Only report timeout
+   if we really have timed out when measured against the
+   caller-supplied clock.
+   * testsuite/30_threads/condition_variable/members/2.cc: Add test
+   case to confirm above behaviour.
+
 2018-07-20  Jonathan Wakely  

PR libstdc++/86595
diff --git a/libstdc++-v3/include/std/condition_variable 
b/libstdc++-v3/include/std/condition_variable
index 84863a1..a2d146a 100644
--- a/libstdc++-v3/include/std/condition_variable
+++ b/libstdc++-v3/include/std/condition_variable
@@ -116,7 +116,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
const auto __delta = __atime - __c_entry;
const auto __s_atime = __s_entry + __delta;

-   return __wait_until_impl(__lock, __s_atime);
+   // We might get a timeout when measured against __clock_t but
+   // we need to check against the caller-supplied clock to tell
+   // whether we should return a timeout.
+   if (__wait_until_impl(__lock, __s_atime) == cv_status::timeout)
+ return _Clock::now() < __atime ? cv_status::no_timeout : 
cv_status::timeout;
+   else
+ return cv_status::no_timeout;
   }

 template
diff --git a/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc 
b/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc
index 6f9724b..16850a4 100644
--- a/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc
+++ b/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc
@@ -52,8 +52,60 @@ void test01()
 }
 }

+struct slow_clock
+{
+  using rep = std::chrono::system_clock::rep;
+  using period = std::chrono::system_clock::period;
+  using duration = std::chrono::system_clock::duration;
+  using time_point = std::chrono::time_point;
+  static constexpr bool is_steady = false;
+
+  static time_point now()
+  {
+auto real = std::chrono::system_clock::now();
+return time_point{real.time_since_epoch() / 3};
+  }
+};
+
+
+void test01_alternate_clock()
+{
+  try
+{
+  std::condition_variable c1;
+  std::mutex m;
+  std::unique_lock l(m);
+  auto const expire = slow_clock::now() + std::chrono::seconds(1);
+
+  while (slow_clock::now() < expire)
+   {
+ auto const result = c1.wait_until(l, expire);
+
+ // If wait_until returns before the timeout has expired when
+ // measured against the supplied clock, then wait_until must
+ // return no_timeout.
+ if (slow_clock::now() < expire)
+   VERIFY(result == std::cv_status::no_timeout);
+
+ // If wait_until returns timeout then the timeout must have
+ // expired.
+ if (result == std::cv_status::timeout)
+   VERIFY(slow_clock::now() >= expire);
+   }
+}
+  catch (const std::system_error& e)
+{
+  VERIFY( false );
+}
+  catch (...)
+{
+  VERIFY( false );
+}
+}
+
 int main()
 {
   test01();
+  test01_alternate_clock();
   return 0;
 }

base-commit: 3052e4ec519e4f5456ab63f4954ae098524316ce
--
git-series 0.9.1
BrightSign considers your privacy to be very important. The emails you send to 
us will be protected and secured. Furthermore, we will only use your email and 
contact information for the reasons you sent them to us and for tracking how 
effectively we respond to your requests.

[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86611

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 16:38:43 2018
New Revision: 262906

URL: https://gcc.gnu.org/viewcvs?rev=262906=gcc=rev
Log:
PR tree-optimization/86613 - missing -Warray-bounds on a wide string access due
to ccp folding
PR tree-optimization/86611 - missing -Warray-bounds on a large negative index
into a string in lp64

gcc/testsuite/ChangeLog:
* gcc/testsuite/c-c++-common/Warray-bounds-2.c: Undefine macros and
prune duplicate warnings.
* gcc/testsuite/gcc.dg/Warray-bounds-31.c: Xfail test cases with
data-model-dependencies.
* gcc/testsuite/gcc.dg/Warray-bounds-32.c: Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-31.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-32.c

[Bug tree-optimization/86613] missing -Warray-bounds on a wide string access due to ccp folding

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86613

--- Comment #1 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 16:38:43 2018
New Revision: 262906

URL: https://gcc.gnu.org/viewcvs?rev=262906=gcc=rev
Log:
PR tree-optimization/86613 - missing -Warray-bounds on a wide string access due
to ccp folding
PR tree-optimization/86611 - missing -Warray-bounds on a large negative index
into a string in lp64

gcc/testsuite/ChangeLog:
* gcc/testsuite/c-c++-common/Warray-bounds-2.c: Undefine macros and
prune duplicate warnings.
* gcc/testsuite/gcc.dg/Warray-bounds-31.c: Xfail test cases with
data-model-dependencies.
* gcc/testsuite/gcc.dg/Warray-bounds-32.c: Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-31.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-32.c

Re: [RFC] Adding Python as a possible language and it's usage

[Segher Boessenkool]

On Fri, Jul 20, 2018 at 11:49:05AM +0200, Martin Liška wrote:
> Fully agree with that. Coming up with a new scripts written in python2 really
> makes no sense.

Then python cannot be a build requirement for GCC, since some of our
primary targets do not ship python3.


Segher

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Wilco Dijkstra]

Umesh Kalappa wrote:

> We tried some of the normalisation numbers and the fix works and please
> could you help us with the input ,where  if you see that fix breaks down.

Well try any set of inputs which require normalisation. You'll find these no
longer get normalised and so will get incorrect results. Try basic cases like
1.0 - 0.75 which I think will return 0.625...

A basic test would be to run old vs new on a large set of inputs to verify
there aren't any obvious differences.

Wilco
   

[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86611

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86613
 Blocks||56456

--- Comment #3 from Martin Sebor  ---
See also bug 86613 for a similar problem but with a different root cause.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/86613] New: missing -Warray-bounds on a wide string access due to ccp folding

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86613

Bug ID: 86613
   Summary: missing -Warray-bounds on a wide string access due to
ccp folding
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 86611 but with a different root cause, GCC fails to diagnose the
out-of-bounds array index in the following test case, in both ilp32 and lp64. 
According to the dumps, the underlying root cause appears to be that the
invalid array dereference is folded in ccp1.

$ cat c.c && gcc -O2 -S -Warray-bounds -Wno-stringop-overflow
-fdump-tree-objsz=/dev/stdout -fdump-tree-ccp1=/dev/stdout c.c -m32
void f (int);

void h (void)
{
  __PTRDIFF_TYPE__ i = -__PTRDIFF_MAX__ - 1;
  f (L"123456789"[i]);
}


;; Function h (h, funcdef_no=0, decl_uid=1841, cgraph_uid=1, symbol_order=0)

h ()
{
  int i;
  long int _1;

   :
  i_2 = -2147483648;
  _1 = "1"[i_2];
  f (_1);
  return;

}



;; Function h (h, funcdef_no=0, decl_uid=1841, cgraph_uid=1, symbol_order=0)

h ()
{
  int i;
  long int _1;

   :
  _1 = "1"[-2147483648];
  f (_1);
  return;

}



;; Function h (h, funcdef_no=0, decl_uid=1841, cgraph_uid=1, symbol_order=0)

h ()
{
   [local count: 1073741825]:
  f (49);
  return;

}

[PATCH] -fsave-optimization-record: add contrib/optrecord.py

[David Malcolm]

This patch adds a Python 3 module to "contrib" for reading the output of
-fsave-optimization-record.

It can be imported from other Python code, or run standalone as a script,
in which case it prints the saved messages in a form resembling GCC
diagnostics.

OK for trunk?

contrib/ChangeLog:
* optrecord.py: New file.
---
 contrib/optrecord.py | 295 +++
 1 file changed, 295 insertions(+)
 create mode 100755 contrib/optrecord.py

diff --git a/contrib/optrecord.py b/contrib/optrecord.py
new file mode 100755
index 000..b07488e
--- /dev/null
+++ b/contrib/optrecord.py
@@ -0,0 +1,295 @@
+#!/usr/bin/env python3
+#
+# Python module for working with the result of -fsave-optimization-record
+# Contributed by David Malcolm .
+#
+# Copyright (C) 2018 Free Software Foundation, Inc.
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 3, or (at your option) any later
+# version.
+#
+# GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+# WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+# for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .  */
+
+import argparse
+import json
+import os
+import sys
+
+class TranslationUnit:
+"""Top-level class for containing optimization records"""
+@staticmethod
+def from_filename(filename):
+with open(filename) as f:
+root_obj = json.load(f)
+return TranslationUnit(filename, root_obj)
+
+def __init__(self, filename, json_obj):
+self.filename = filename
+self.pass_by_id = {}
+
+# Expect a 3-tuple
+metadata, passes, records = json_obj
+
+self.format = metadata['format']
+self.generator = metadata['generator']
+self.passes = [Pass(obj, self) for obj in passes]
+self.records = [Record(obj, self) for obj in records]
+
+def __repr__(self):
+return ('TranslationUnit(%r, %r, %r, %r)'
+% (self.filename, self.generator, self.passes, self.records))
+
+class Pass:
+"""An optimization pass"""
+def __init__(self, json_obj, tu):
+self.id_ = json_obj['id']
+self.name = json_obj['name']
+self.num = json_obj['num']
+self.optgroups = set(json_obj['optgroups']) # list of strings
+self.type = json_obj['type']
+tu.pass_by_id[self.id_] = self
+self.children = [Pass(child, tu)
+ for child in json_obj.get('children', [])]
+
+def __repr__(self):
+return ('Pass(%r, %r, %r, %r)'
+% (self.name, self.num, self.optgroups, self.type))
+
+def from_optional_json_field(cls, jsonobj, field):
+if field not in jsonobj:
+return None
+return cls(jsonobj[field])
+
+class ImplLocation:
+"""An implementation location (within the compiler itself)"""
+def __init__(self, json_obj):
+self.file = json_obj['file']
+self.line = json_obj['line']
+self.function = json_obj['function']
+
+def __repr__(self):
+return ('ImplLocation(%r, %r, %r)'
+% (self.file, self.line, self.function))
+
+class Location:
+"""A source location"""
+def __init__(self, json_obj):
+self.file = json_obj['file']
+self.line = json_obj['line']
+self.column = json_obj['column']
+
+def __str__(self):
+return '%s:%i:%i' % (self.file, self.line, self.column)
+
+def __repr__(self):
+return ('Location(%r, %r, %r)'
+% (self.file, self.line, self.column))
+
+class Count:
+"""An execution count"""
+def __init__(self, json_obj):
+self.quality = json_obj['quality']
+self.value = json_obj['value']
+
+def __repr__(self):
+return ('Count(%r, %r)'
+% (self.quality, self.value))
+
+def is_precise(self):
+return self.quality in ('precise', 'adjusted')
+
+class Record:
+"""A optimization record: success/failure/note"""
+def __init__(self, json_obj, tu):
+self.kind = json_obj['kind']
+if 'pass' in json_obj:
+self.pass_ = tu.pass_by_id[json_obj['pass']]
+else:
+self.pass_ = None
+self.function = json_obj.get('function', None)
+self.impl_location = from_optional_json_field(ImplLocation, json_obj,
+  'impl_location')
+self.message = [Item.from_json(obj) for obj in json_obj['message']]
+self.count = from_optional_json_field(Count, json_obj, 'count')
+self.location = from_optional_json_field(Location, json_obj, 
'location')
+

[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86611

--- Comment #2 from Martin Sebor  ---
Another test case, except this one triggers a warning in lp64 but not in ilp32,
because of the same folding in fre1:

void f (int);

void g (void)
{
  f (L"123456789"[-__PTRDIFF_MAX__ - 1]); 
}

[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86611

--- Comment #1 from Martin Sebor  ---
Ditto for the following (distilled from gcc.dg/Warray-bounds-31.c:

void f (int);

void g (void)
{
  const char *q = "12345678" + 4;
  __PTRDIFF_TYPE__ i = __PTRDIFF_MAX__ - 3;
  f (q[i]);
}

[Bug target/86612] New: __strdup problem on power 9

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86612

Bug ID: 86612
   Summary: __strdup problem on power 9
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Note that this occurs with gcc 7 and gcc 8 as well and goes back quite far in
revisions (at least to where gcc 8 was split off trunk).

On a power 9 system with a fresh tree built from trunk (specifically r262905):

seurer:~/gcc/build/gcc-test$ /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O3
-funroll-loops -S -o pr58673-2.s
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c: In
function 'pr_ff':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c:143:14:
warning: implicit declaration of function '__strdup'; did you mean 'strdup'?
[-Wimplicit-function-declaration]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c:143:8:
warning: pointer/integer type mismatch in conditional expression
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c:168:8:
warning: pointer/integer type mismatch in conditional expression
seurer:~/gcc/build/gcc-test$ 


On a power 8 system with the same revision there are no warnings for either BE
or LE.

[Bug tree-optimization/86611] New: missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86611

Bug ID: 86611
   Summary: missing -Warray-bounds on a large negative index into
a string in lp64
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With bug 84047 fixed, the out-of-bounds index in the following test case is
still diagnosed in ilp32 but not in lp64.  In ilp32 the MEM_REF makes it all
the way to VRP where it's diagnosed, but in lp64 it's folded in fre1:

$ cat c.c && gcc -O2 -S -Warray-bounds -Wno-stringop-overflow
-fdump-tree-ealias=/dev/stdout -fdump-tree-fre1=/dev/stdout c.c
void f (int);

void g (void)
{
  const char *p = "123";
  __PTRDIFF_TYPE__ i = -__PTRDIFF_MAX__ - 1;
  f (p[i + 1]);
}

;; Function g (g, funcdef_no=0, decl_uid=1900, cgraph_uid=1, symbol_order=0)

Points-to analysis

Constraints:

ANYTHING = 
ESCAPED = *ESCAPED
ESCAPED = ESCAPED + UNKNOWN
*ESCAPED = NONLOCAL
NONLOCAL = 
NONLOCAL = 
INTEGER = 
_5 = _4
ESCAPED = _5

Collapsing static cycles and doing variable substitution
Building predecessor graph
Detecting pointer and location equivalences
Rewriting constraints and unifying variables
Uniting pointer but not location equivalent variables
Finding indirect cycles
Solving graph

Points-to sets

ANYTHING = { ANYTHING }
ESCAPED = { }
NONLOCAL = { ESCAPED NONLOCAL }
STOREDANYTHING = { }
INTEGER = { ANYTHING }
f = { }
_4 = { }
_5 = { }


Alias information for g

Aliased symbols


Call clobber information

ESCAPED, points-to vars: { }

Flow-insensitive points-to information


g ()
{
  long int i;
  const char * p;
  char _4;
  int _5;

   :
  _4 = MEM[(const char *)"123" + -9223372036854775807B];
  _5 = (int) _4;
  f (_5);
  return;

}



;; Function g (g, funcdef_no=0, decl_uid=1900, cgraph_uid=1, symbol_order=0)

g ()
{
  long int i;
  const char * p;

   :
  f (50);
  return;

}

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Umesh Kalappa]

Thank you all for your comments .

Wilco,
We tried some of the normalisation numbers and the fix works and please
could you help us with the input ,where  if you see that fix breaks down.

Thank you again
~Umesh
On Fri, Jul 20, 2018, 7:07 PM Wilco Dijkstra  wrote:

> Hi Umesh,
>
> Looking at your patch, this would break all results which need to be
> normalized.
>
>
> Index: libgcc/config/arm/ieee754-df.S
> ===
> --- libgcc/config/arm/ieee754-df.S  (revision 262850)
> +++ libgcc/config/arm/ieee754-df.S  (working copy)
> @@ -203,8 +203,11 @@
>  #endif
>
> @ Determine how to normalize the result.
> +   @ if result is denormal i.e (exp)=0,then don't normalise the
> result,
>  LSYM(Lad_p):
> cmp xh, #0x0010
> +   blt LSYM(Lad_e)
> +   cmp xh, #0x0010
> bcc LSYM(Lad_a)
> cmp xh, #0x0020
> bcc LSYM(Lad_e)
>
> It seems Lad_a doesn't correctly handle the case where the result is a
> denormal. For this case
> the result is correct so nothing else needs to be done. This requires an
> explicit test that the
> exponent is zero - other cases still need to be renormalized as usual.
> This code looks overly
> complex so any change will require extensive testing of all the corner
> cases.
>
> Wilco
>

Re: [PATCH 2/2] Add "-fsave-optimization-record"

[David Malcolm]

On Thu, 2018-07-19 at 14:39 +0200, Richard Biener wrote:
> On Wed, Jul 11, 2018 at 12:53 PM David Malcolm 
> wrote:
> > 
> > This patch implements a -fsave-optimization-record option, which
> > leads to a JSON file being written out, recording the dump_* calls
> > made (via the optinfo infrastructure in the previous patch).
> > 
> > The patch includes a minimal version of the JSON patch I posted
> > last
> > year, with just enough support needed for optimization records (I
> > removed all of the parser code, leaving just the code for building
> > in-memory JSON trees and writing them to a pretty_printer).
> > 
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > 
> > OK for trunk?
> 
> +@item -fsave-optimization-record
> +@opindex fsave-optimization-record
> +Write a SRCFILE.opt-record.json file detailing what optimizations
> +were performed.
> +
> 
> I guess this should note that it is experimental and in no way
> complete.  Maybe list areas where reports will be generated,
> like vectorization?

Indeed. I also noticed that for some reason my patch had this option
between
  @item -frounding-math
and
  @item -fsignaling-nans
in the section on floating-point arithmetic options, so I've moved it
to the "GCC Developer Options" section for now, immediately after the
documentation of -fopt-info.

Here's what I've committed to invoke.texi (r262905):

BEGIN QUOTE:

@item -fsave-optimization-record
@opindex fsave-optimization-record
Write a SRCFILE.opt-record.json file detailing what optimizations
were performed, for those optimizations that support @option{-fopt-info}.

This option is experimental and the format of the data within the JSON
file is subject to change.

It is roughly equivalent to a machine-readable version of
@option{-fopt-info-all}, as a collection of messages with source file,
line number and column number, with the following additional data for
each message:

@itemize @bullet

@item
the execution count of the code being optimized, along with metadata about
whether this was from actual profile data, or just an estimate, allowing
consumers to prioritize messages by code hotness,

@item
the function name of the code being optimized, where applicable,

@item
the ``inlining chain'' for the code being optimized, so that when
a function is inlined into several different places (which might
themselves be inlined), the reader can distinguish between the copies,

@item
objects identifying those parts of the message that refer to expressions,
statements or symbol-table nodes, which of these categories they are, and,
when available, their source code location,

@item
the GCC pass that emitted the message, and

@item
the location in GCC's own code from which the message was emitted

@end itemize

Additionally, some messages are logically nested within other
messages, reflecting implementation details of the optimization
passes.

END QUOTE


> Did you check what happens with -flto -fsave-optimization-record?
> Will the compile-phase emit a json file for each source (expected,
> like with early inlining decisions)?  Will the WPA phase emit one
> (IPA decisions?) or will IPA decisions be recorded in the LTRANS
> one?  How will the LTRANS ones be named and where can they
> be found?  You don't need to solve all the issues with this patch
> but they should be eventually addressed somehow.

I'm looking at that now.

> I don't question the use or implementation of JSON, I'll just
> approve it.
> 
> The rest looks obvious enough, thus OK.

> 
> Some overall blurb in the documentation or changes.html
> on how to use this would be nice of course.

Thanks; will do.

Dave

> Thanks,
> Richard.
> 
> 
> > gcc/ChangeLog:
> > * Makefile.in (OBJS): Add json.o and optinfo-emit-json.o.
> > (CFLAGS-optinfo-emit-json.o): Define TARGET_NAME.
> > * common.opt (fsave-optimization-record): New option.
> > * coretypes.h (struct kv_pair): Move here from dumpfile.c.
> > * doc/invoke.texi (-fsave-optimization-record): New option.
> > * dumpfile.c: Include "optinfo-emit-json.h".
> > (struct kv_pair): Move to coretypes.h.
> > (optgroup_options): Make non-static.
> > (dump_context::end_scope): Call
> > optimization_records_maybe_pop_dump_scope.
> > * dumpfile.h (optgroup_options): New decl.
> > * json.cc: New file.
> > * json.h: New file.
> > * optinfo-emit-json.cc: New file.
> > * optinfo-emit-json.h: New file.
> > * optinfo.cc: Include "optinfo-emit-json.h".
> > (optinfo::emit): Call
> > optimization_records_maybe_record_optinfo.
> > (optinfo_enabled_p): Check optimization_records_enabled_p.
> > (optinfo_wants_inlining_info_p): Likewise.
> > * optinfo.h: Update comment.
> > * profile-count.c (profile_quality_as_string): New
> > function.
> > * profile-count.h (profile_quality_as_string): New decl.
> > (profile_count::quality): New 

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Tamar Christina]

> 
> On 07/20/2018 05:03 AM, Tamar Christina wrote:
> >> Understood.  Thanks for verifying.  I wonder if we could just bury
> >> this entirely in the aarch64 config files and not expose the default into
> params.def?
> >>
> >
> > Burying it in config.gcc isn't ideal because if your C runtime is
> > configurable (like uClibc) it means you have to go and modify this
> > file every time you change something. If the argument is against
> > having these defines in the params and not the configure flag itself then I
> can just have an aarch64 specific configure flag and just use the created
> define directly in the AArch64 back-end.
> Not config.gcc, but in a .h/.c file for the target.
> 
> If we leave the generic option, but override the default in the target files.
> Would that work?

So leaving the generic configure option? Yes that would work too. The only 
downside is
that if we have want to do any validation on the value at configure time it 
would need to
be manually kept in sync with those in params.def. Or we'd just have to not do 
any checking
at configure time.  This would mean you can get to the end of your build and 
only when you
try to use the compiler would it complain. 

Both aren't a real deal breaker to me.

Shall I then just leave the configure flag but remove the params plumbing?

Thanks,
Tamar

> 
> Jeff

[Bug c++/86610] New: non-const operator erroneously called in lambda in templated function

[daibane at sandia dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86610

Bug ID: 86610
   Summary: non-const operator erroneously called in lambda in
templated function
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daibane at sandia dot gov
  Target Milestone: ---

The following code fails to compile, saying that the non-const operator[] is
being called. GCC 7.3, Clang 6.0.0, Intel 18, and MSVC 2018 Pre all compile
this code without error. Removing either the templatization of the classify2
function or the lambda around the statement allows the code to compile without
error.


#include 
#include 

template 
class Few {
  T array_[n];

 public:
  inline T& operator[](int i) { return array_[i]; }
  inline T const& operator[](int i) const { return array_[i]; }
  Few(std::initializer_list l) {
int i = 0;
for (auto it = l.begin(); it != l.end(); ++it) {
  new (array_ + (i++)) T(*it);
}
  }
  inline Few() {}
  inline ~Few() {}
  inline Few(Few const& rhs) {
for (int i = 0; i < n; ++i) new (array_ + i) T(rhs[i]);
  }
};

template 
void classify2(Few l) {
  double* p = new double[1];
  auto f = [=]() {
p[0] = l[0];
  };
  f();
  delete [] p;
}

static void classify_box(double x, double y, double z) {
  Few l({x, y, z});
  classify2<3>(l);
}

int main() {
  classify_box(1.0, 1.0, 1.0);
}



Here is the compile error:


bug.cpp: In instantiation of ‘void classify2(Few) [with int dim =
3]’:
bug.cpp:36:17:   required from here
bug.cpp:28:10: error: passing ‘const Few’ as ‘this’ argument
discards qualifiers [-fpermissive]
 p[0] = l[0];
bug.cpp:9:13: note:   in call to ‘T& Few::operator[](int) [with T =
double; int n = 3]’
   inline T& operator[](int i) { return array_[i]; }
 ^~~~

Re: [PATCH][Middle-end][version 2]change char type to unsigned char type when expanding strcmp/strncmp

[Qing Zhao]

> On Jul 20, 2018, at 9:59 AM, Jakub Jelinek  wrote:
> 
> On Fri, Jul 20, 2018 at 09:53:24AM -0500, Qing Zhao wrote:
>> +2018-07-20  Qing Zhao  
>> +
>> +   * builtins.c (expand_builtin_memcmp): Delete the last parameter for
>> +   call to inline_expand_builtin_string_cmp.
>> +   (expand_builtin_strcmp): Likewise.
>> +   (expand_builtin_strncmp): Likewise.
>> +   (inline_string_cmp): Delete the last parameter, change char_type_node
>> +   to unsigned_char_type_node for strcmp/strncmp, add conversions to the
>> +   two operands.
>> +   (inline_expand_builtin_string_cmp): Delete the last parameter, give 
>> up
>> +   the inlining expansion on target where the type of the call has same 
>> or 
>> +   narrower presicion than unsigned char.
> 
> s/presicion/precision/
> 
> Also in the patch, where there is another typo, s/of/or/.

Okay.
> 
> Ok for trunk with that fixed.

thanks a lot for the review.

Qing
> 
>   Jakub

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 83776, which changed state.

Bug 83776 Summary: [6/7/8 Regression] missing -Warray-bounds indexing past the 
end of a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
Per bug 84047, comment 10, will not be backporting to release branches.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 84047, which changed state.

Bug 84047 Summary: [6/7/8 Regression] missing -Warray-bounds on an 
out-of-bounds index into an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Martin Sebor  ---
Per comment 10, will not be backporting to release branches.

Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]

[Jeff Law]

On 07/20/2018 05:03 AM, Tamar Christina wrote:
>> Understood.  Thanks for verifying.  I wonder if we could just bury this 
>> entirely
>> in the aarch64 config files and not expose the default into params.def?
>>
> 
> Burying it in config.gcc isn't ideal because if your C runtime is 
> configurable (like uClibc) it means you
> have to go and modify this file every time you change something. If the 
> argument is 
> against having these defines in the params and not the configure flag itself 
> then I can just
> have an aarch64 specific configure flag and just use the created define 
> directly in the AArch64 back-end.
Not config.gcc, but in a .h/.c file for the target.

If we leave the generic option, but override the default in the target
files.  Would that work?

Jeff

Re: RFC: Patch to implement Aarch64 SIMD ABI

[Steve Ellcey]

On Fri, 2018-07-20 at 11:11 +, Wilco Dijkstra wrote:

> Steve Ellcey wrote:
> 
> > Yes, I see where I missed this in aarch64_push_regs
> > and aarch64_pop_regs.  I think that is why the second of
> > Wilco's two examples (f2) is wrong.  I am unclear about
> > exactly what is meant by writeback and why we have it and
> > how that and callee_adjust are used.  Any chance someone
> > could help me understand this part of the prologue/epilogue
> > code better?  The comments in aarch64.c/aarch64.h aren't
> > really helping me understand what the code is doing or
> > why it is doing it.

> Writeback is the same as a base update in a load or store. When
> creating the frame there are 3 stack adjustments to be made:
> creating stack for locals, pushing callee-saves and reserving space
> for outgoing arguments. We merge these stack adjustments as much as
> possible and use load/store with writeback for codesize and performance.
> See the last part in layout_frame for the different cases.

OK, I think I understand this a bit better now.  I think my main
problem is with the  term 'writeback' which I am not used to seeing.
But if I understand things correctly we are saving one or two registers
and (possibly) updating the stack pointer using auto-increment/auto-
decrement in one instruction and that the updating of SP is what you
mean by 'writeback'.  Correct?

Steve Ellcey
sell...@cavium.com

Re: [PATCH][Middle-end][version 2]change char type to unsigned char type when expanding strcmp/strncmp

[Jakub Jelinek]

On Fri, Jul 20, 2018 at 09:53:24AM -0500, Qing Zhao wrote:
> +2018-07-20  Qing Zhao  
> +
> +   * builtins.c (expand_builtin_memcmp): Delete the last parameter for
> +   call to inline_expand_builtin_string_cmp.
> +   (expand_builtin_strcmp): Likewise.
> +   (expand_builtin_strncmp): Likewise.
> +   (inline_string_cmp): Delete the last parameter, change char_type_node
> +   to unsigned_char_type_node for strcmp/strncmp, add conversions to the
> +   two operands.
> +   (inline_expand_builtin_string_cmp): Delete the last parameter, give up
> +   the inlining expansion on target where the type of the call has same 
> or 
> +   narrower presicion than unsigned char.

s/presicion/precision/

Also in the patch, where there is another typo, s/of/or/.

Ok for trunk with that fixed.

Jakub

[PATCH][Middle-end][version 2]change char type to unsigned char type when expanding strcmp/strncmp

[Qing Zhao]

Hi,

this is the 2nd version of the change, mainly addressed Jakub’s comments:

1. Give up the inlining expansion for strcmp/strncmp/memcmp on a target
where the type of the call has same or narrower presicion than unsigned
char.
2.  add conversions before expand_simple_binop to the two operands.

and
3. also updated comments of routine inline_string_cmp to reflect the conversions
in the expanded code.

have tested on X86 and aarch64. No regressions.

Okay for thunk?

Qing

gcc/ChangeLog:

+2018-07-20  Qing Zhao  
+
+   * builtins.c (expand_builtin_memcmp): Delete the last parameter for
+   call to inline_expand_builtin_string_cmp.
+   (expand_builtin_strcmp): Likewise.
+   (expand_builtin_strncmp): Likewise.
+   (inline_string_cmp): Delete the last parameter, change char_type_node
+   to unsigned_char_type_node for strcmp/strncmp, add conversions to the
+   two operands.
+   (inline_expand_builtin_string_cmp): Delete the last parameter, give up
+   the inlining expansion on target where the type of the call has same or 
+   narrower presicion than unsigned char.
+



78809C_uchar.patch
Description: Binary data


> On Jul 19, 2018, at 12:31 PM, Jakub Jelinek  wrote:
> 
> If you expand it as (int) ((unsigned char *)p)[n] - (int) ((unsigned char 
> *)q)[n]
> then aren't you relying on int type to have wider precision than unsigned char
> (or unit_mode being narrower than mode)?  I don't see anywhere where you'd
> give up on doing the inline expansion on targets where e.g. lowest
> addressable unit would be 16-bit and int would be 16-bit too.
> On targets where int is as wide as char, one would need to expand it instead
> as something like:
> if (((unsigned char *)p)[n] == ((unsigned char *)q)[n]) loop;
> ret = ((unsigned char *)p)[n] < ((unsigned char *)q)[n] ? -1 : 1;
> or similar or just use the library routine.
> 
> Also:
>  var_rtx
>= adjust_address (var_rtx_array, TYPE_MODE (unit_type_node), offset);
>  const_rtx = c_readstr (const_str + offset, unit_mode);
>  rtx op0 = (const_str_n == 1) ? const_rtx : var_rtx;
>  rtx op1 = (const_str_n == 1) ? var_rtx : const_rtx;
> 
>  result = expand_simple_binop (mode, MINUS, op0, op1,
>result, is_memcmp ? 1 : 0, OPTAB_WIDEN);
> doesn't look correct to me, var_rtx and const_rtx here are in unit_mode,
> you need to convert those to mode before you can use those in
> expand_simple_binop, using
>  op0 = convert_modes (mode, unit_mode, op0, 1);
>  op1 = convert_modes (mode, unit_mode, op1, 1);
> before the expand_simple_binop.
> While expand_simple_binop is called with an unsignedp argument, that is
> meant for the cases where the expansion needs to widen it further, not for
> calling expand_simple_binop with arguments with known incorrect mode;
> furthermore, one of them being CONST_INT which has VOIDmode.

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)

[Bernd Edlinger]

Martin,

when I look at tree-ssa-forwprop.c:

   str1 = string_constant (src1, );
   if (str1 == NULL_TREE)
 break;
   if (!tree_fits_uhwi_p (off1)
   || compare_tree_int (off1, TREE_STRING_LENGTH (str1) - 1) > 0
   || compare_tree_int (len1, TREE_STRING_LENGTH (str1)
  - tree_to_uhwi (off1)) > 0
   || TREE_CODE (TREE_TYPE (str1)) != ARRAY_TYPE
   || TYPE_MODE (TREE_TYPE (TREE_TYPE (str1)))
  != TYPE_MODE (char_type_node))
 break;

I don't think it is a good idea to let string_constant return
strings which have not necessarily valid content after the first
NUL byte.  It looks like the content has to be valid up to
TREE_STRING_LENGTH.

So may I suggest to do something like the following
(diff to your last patch):

--- expr.c.jj   2018-07-20 10:51:51.983605588 +0200
+++ expr.c  2018-07-20 15:07:29.769423479 +0200
@@ -11277,6 +11277,7 @@ tree
  string_constant (tree arg, tree *ptr_offset)
  {
tree array;
+  tree array_size;
STRIP_NOPS (arg);
  
/* Non-constant index into the character array in an ARRAY_REF
@@ -11295,9 +11296,11 @@ string_constant (tree arg, tree *ptr_off
  
arg = TREE_OPERAND (arg, 0);
tree ref = arg;
+  tree reftype = TREE_TYPE (ref);
if (TREE_CODE (arg) == ARRAY_REF)
{
  tree idx = TREE_OPERAND (arg, 1);
+ reftype = TREE_TYPE (TREE_OPERAND (arg, 0));
  if (TREE_CODE (idx) != INTEGER_CST
  && TREE_CODE (argtype) == POINTER_TYPE)
{
@@ -11313,6 +11316,11 @@ string_constant (tree arg, tree *ptr_off
return NULL_TREE;
}
}
+  if (TREE_CODE (reftype) != ARRAY_TYPE)
+   return NULL_TREE;
+  while (TREE_CODE (TREE_TYPE (reftype)) == ARRAY_TYPE)
+   reftype = TREE_TYPE (reftype);
+  array_size = TYPE_SIZE_UNIT (reftype);
array = get_addr_base_and_unit_offset (ref, _off);
if (!array
  || (TREE_CODE (array) != VAR_DECL
@@ -11345,7 +11353,10 @@ string_constant (tree arg, tree *ptr_off
return NULL_TREE;
  }
else if (DECL_P (arg))
-array = arg;
+{
+  array = arg;
+  array_size = DECL_SIZE_UNIT (array);
+}
else
  return NULL_TREE;
  
@@ -11410,24 +11421,18 @@ string_constant (tree arg, tree *ptr_off
if (!init || TREE_CODE (init) != STRING_CST)
  return NULL_TREE;
  
-  tree array_size = DECL_SIZE_UNIT (array);
if (!array_size || TREE_CODE (array_size) != INTEGER_CST)
  return NULL_TREE;
  
/* Avoid returning a string that doesn't fit in the array
- it is stored in, like
+ it is stored in, like:
   const char a[4] = "abcde";
- but do handle those that fit even if they have excess
- initializers, such as in
- const char a[4] = "abc\000\000";
- The excess elements contribute to TREE_STRING_LENGTH()
- but not to strlen().  */
-  unsigned HOST_WIDE_INT charsize
-= tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (init;
+ ... or:
+ const char a[4] = "abc\000";
+ ... because some callers access the string up to the limit
+ imposed by TREE_STRING_LENGTH.  */
unsigned HOST_WIDE_INT length = TREE_STRING_LENGTH (init);
-  length = string_length (TREE_STRING_POINTER (init), charsize,
- length / charsize);
-  if (compare_tree_int (array_size, length + 1) < 0)
+  if (compare_tree_int (array_size, length) < 0)
  return NULL_TREE;
  
*ptr_offset = offset;


Considering Richard's last comment, I don't know if TYPE_SIZE_UNIT
of the ARRAY_TYPE is the correct way to get the size of the
innermost arrayhere, but I think we will need it.



Bernd.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590

--- Comment #26 from Jakub Jelinek  ---
I'm also wondering about cxx_constant_init using !ctx->strict, shouldn't we in
those cases really require strict constant expressions, i.e.
let maybe_constant_init_1 call cxx_eval_outermost_constant_expr with
allow_non_constant, !allow_non_constant rather than allow_non_constant, false ?

[Bug target/86589] [8 regression] gcc.target/powerpc/altivec-7-le.c and gcc.target/powerpc/vsx-7-be.c fail starting with r262440

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86589

--- Comment #2 from seurer at gcc dot gnu.org ---
I just checked and 8.1.0 was OK

[Bug tree-optimization/86609] New: Reassociate (int) round sequences

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86609

Bug ID: 86609
   Summary: Reassociate (int) round sequences
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

Not entirely sure what to call this optimisation.
Consider:
int f(double x, double *p)
{
  double r = __builtin_round (x);
  *p = r;
  return (int) r;
}

For aarch64 GCC with -O2 -fno-math-errno generates:
f:
frinta  d0, d0  // 7[c=8 l=4]  rounddf2
str d0, [x0]// 8[c=4 l=4]  *movdf_aarch64/7
fcvtzs  w0, d0  // 14   [c=8 l=4]  fix_truncdfsi2
ret // 29   [c=0 l=4]  *do_return


The problem here is that the two FRINT* operations cannot be done in parallel.
Clang can break the chain like so:
f:  // @f
// %bb.0:   // %entry
frinta  d1, d0
fcvtas  w8, d0
str d1, [x0]
mov w0, w8
ret

Note how the two expensive operations are now independent.
I think in C terms this means transforming the above to:
int f2 (double x, double *p)
{
  double r = __builtin_round (x);
  *p = r;
  return (int)__builtin_iround (x);
}

Would this be something for the reassociation pass to do?

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590

--- Comment #25 from Jakub Jelinek  ---
So, apparently the first bullet is wherever the constant-expression
non-terminal appears in the grammar rather than that e is a constant
expression.

So the above patch really needs to be:
+  if (ctx->quiet && !ctx->maybe_constant_init)
+   {
+ *non_constant_p = true;
+ return t;
+   }
where ctx->maybe_constant_init flag would be set in some special variant of
maybe_constant_init_1.  store_init_value has:
  /* In C++11 constant expression is a semantic, not syntactic, property.
 In C++98, make sure that what we thought was a constant expression at
 template definition time is still constant and otherwise perform this
 as optimization, e.g. to fold SIZEOF_EXPRs in the initializer.  */
  if (decl_maybe_constant_var_p (decl) || TREE_STATIC (decl))
{
  bool const_init;
  tree oldval = value;
  value = fold_non_dependent_expr (value);
  if (DECL_DECLARED_CONSTEXPR_P (decl)
  || (DECL_IN_AGGR_P (decl)
  && DECL_INITIALIZED_IN_CLASS_P (decl)
  && !DECL_VAR_DECLARED_INLINE_P (decl)))
{
  /* Diagnose a non-constant initializer for constexpr variable or
 non-inline in-class-initialized static data member.  */
  if (!require_constant_expression (value))
value = error_mark_node;
  else
value = cxx_constant_init (value, decl);
}
  else
value = maybe_constant_init (value, decl);
and the cxx_constant_init call there already sets ctx->quiet to false, so the
maybe_constant_init call here is probably the one that would need to be
changed.
There are tons of other maybe_constant_init calls in the C++ FE though, and it
is unclear if any other would need changes (wonder e.g. about aggregate
initializers or initializer-list etc. that contain many separate expressions;
if we need is_constant_evaluated to be true sometimes in there, it would need
to check if they are all constant expressions).

[Bug target/86547] s390x: Maximum number of LRA assignment passes is achieved (30) when compiling a small inline assembler snippet

[iii at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86547

--- Comment #1 from Ilya Leoshkevich  ---
I did a bisect and found two relevant commits:

1) c312b100: PR target/83712

Before: error: ‘asm’ operand has impossible constraints
After:  internal compiler error: Segmentation fault

2) eaefe34f: PR target/84876

Before: internal compiler error: Segmentation fault
After:  internal compiler error: Maximum number of LRA assignment passes is
achieved (30)

Re: GCC 8.2 Release Candidate available from gcc.gnu.org

[Bill Seurer]

On 07/19/18 07:28, Richard Biener wrote:


A release candidate for GCC 8.2 is available from

  ftp://gcc.gnu.org/pub/gcc/snapshots/8.2.0-RC-20180719/

and shortly its mirrors.  It has been generated from SVN revision 262876.

I have so far bootstrapped and tested the release candidate on
x86_64-unknown-linux-gnu.  Please test it and report any issues to
bugzilla.

If all goes well I'd like to release 8.2 on Thursday, July 26th.



I bootstrapped and tested this on power 7 and power 8 big endian and 
power 8 and power 9 little endian and saw no problems.


--

-Bill Seurer

Re: Optimization for std::to_string()

[Jonathan Wakely]

On 20/07/18 13:51 +0300, niXman wrote:

Jonathan Wakely 2018-07-20 13:05:

On 20/07/18 12:44 +0300, niXman wrote:



Thanks. How did you verify it's an optimization?

Optimization is that there is no superfluous copying into string.


The to_string functions always pass at least __n=16 to __to_xstring,
which is larger than the SSO buffer in std::__cxx11::string, and so
forces a memory allocation.

I didn't think about this...


Avoiding an unconditional dynamic allocation is the main advantage of
using alloca.

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Wilco Dijkstra]

Hi Umesh,

Looking at your patch, this would break all results which need to be normalized.


Index: libgcc/config/arm/ieee754-df.S
===
--- libgcc/config/arm/ieee754-df.S  (revision 262850)
+++ libgcc/config/arm/ieee754-df.S  (working copy)
@@ -203,8 +203,11 @@
 #endif
 
@ Determine how to normalize the result.
+   @ if result is denormal i.e (exp)=0,then don't normalise the result,
 LSYM(Lad_p):
cmp xh, #0x0010
+   blt LSYM(Lad_e)
+   cmp xh, #0x0010
bcc LSYM(Lad_a)
cmp xh, #0x0020
bcc LSYM(Lad_e)

It seems Lad_a doesn't correctly handle the case where the result is a 
denormal. For this case
the result is correct so nothing else needs to be done. This requires an 
explicit test that the
exponent is zero - other cases still need to be renormalized as usual. This 
code looks overly
complex so any change will require extensive testing of all the corner cases.

Wilco

[PATCH] Don't create non zero terminated string constant

[Bernd Edlinger]

Hi!

This fixes a not NUL terminated STRING_CST object.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2018-07-20  Bernd Edlinger  

* gimple-fold.c (gimple_fold_builtin_printf): Don't create a not NUL
	terminated STRING_CST object.


--- gimple-fold.c.jj	2018-07-20 11:59:42.384727747 +0200
+++ gimple-fold.c	2018-07-20 12:19:45.195342409 +0200
@@ -3433,23 +3433,13 @@ gimple_fold_builtin_printf (gimple_stmt_
 	  && (int) len > 0)
 	{
 	  char *newstr;
-	  tree offset_node, string_cst;
 
 	  /* Create a NUL-terminated string that's one char shorter
 		 than the original, stripping off the trailing '\n'.  */
-	  newarg = build_string_literal (len, str);
-	  string_cst = string_constant (newarg, _node);
-	  gcc_checking_assert (string_cst
-   && (TREE_STRING_LENGTH (string_cst)
-   == (int) len)
-   && integer_zerop (offset_node)
-   && (unsigned char)
-  TREE_STRING_POINTER (string_cst)[len - 1]
-  == target_newline);
-	  /* build_string_literal creates a new STRING_CST,
-		 modify it in place to avoid double copying.  */
-	  newstr = CONST_CAST (char *, TREE_STRING_POINTER (string_cst));
+	  newstr = xstrdup (str);
 	  newstr[len - 1] = '\0';
+	  newarg = build_string_literal (len, newstr);
+	  free (newstr);
 	  if (fn_puts)
 		{
 		  gcall *repl = gimple_build_call (fn_puts, 1, newarg);

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Szabolcs Nagy]

On 18/07/18 13:31, Umesh Kalappa wrote:

Hi Nagy/Ramana,

Please help us to review the attached patch and do let me know your comments .

No regress in the  gcc.target  suite for arm target.



have you submitted a copyright assignment form yet?
https://gcc.gnu.org/contribute.html


Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 262850)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2018-07-18  Umesh Kalappa
+
+   PR libgcc/86512
+   * gcc.target/arm/pr86512.c :New test.
+


normally changelog should be part of the mail message and
not included in the diff as it will conflict with other changes
and the whitespace formatting around : and before the email
address is wrong.


Index: gcc/testsuite/gcc.target/arm/pr86512.c
===
--- gcc/testsuite/gcc.target/arm/pr86512.c  (nonexistent)
+++ gcc/testsuite/gcc.target/arm/pr86512.c  (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do run } */
+/* { dg-options "-O0 -msoft-float" } */
+
+#include
+#include
+#define PRIx64"llx"


this macro is not needed.


+
+typedef union
+{
+double d;
+uint64_t i;
+} u;
+
+int main()
+{
+  u smallestPositiveNormal, smallesPositiveSubnormal, expectedResult, result;
+
+  smallesPositiveSubnormal.i = 1;
+
+  smallestPositiveNormal.i = 0x0010;
+  expectedResult.i = 0x000f;
+  result.d = smallestPositiveNormal.d - smallesPositiveSubnormal.d;
+
+
+  if (result.i != expectedResult.i)
+   abort();
+   
+  return 0;
+}
+
Index: libgcc/ChangeLog
===
--- libgcc/ChangeLog(revision 262850)
+++ libgcc/ChangeLog(working copy)
@@ -1,3 +1,9 @@
+2018-07-18  Umesh Kalappa
+   
+   PR libgcc/86512
+   * config/arm/ieee754-df.S :Don't normalise the denormal result.
+


same as above.


--- libgcc/config/arm/ieee754-df.S  (revision 262850)
+++ libgcc/config/arm/ieee754-df.S  (working copy)
@@ -203,8 +203,11 @@
  #endif
  
  	@ Determine how to normalize the result.

+   @ if result is denormal i.e (exp)=0,then don't normalise the result,
  LSYM(Lad_p):
cmp xh, #0x0010
+   blt LSYM(Lad_e)
+   cmp xh, #0x0010
bcc LSYM(Lad_a)


i think you don't need to retest the same thing,
blt won't clobber the condition codes.

as for the technical contents, sorry i have not
reviewed it in detail, the blt might not be the
right check since it's signed compare..
(but i'm not even sure why is there an assembly
implementation for this, generic c code should do
a good job.)


cmp xh, #0x0020
bcc LSYM(Lad_e)

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Just for the record: according to gcc-testresults, the test also FAILs
on hppa64-hp-hpux11.11.

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I haven't yet gotten around to looking closer, sorry.

I'll report once I've found something.

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656

--- Comment #9 from Martin Liška  ---
Rainer?

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85759

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Martin Liška  ---
Fixed now.