[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #11 from Oleg Endo  ---
(In reply to Oleg Endo from comment #10)
> Adding some ARC maintainers, because it is the only thing in libgcc that as
> a reference to FLOAT_BIT_ORDER_MISMATCH.  I don't know what it is supposed
> to do there.

I'm confused.  Who is actually the effective maintainer of ARC?  All the
patches on gcc-patches seem to go like 
  ...
  OK for trunk?

 ... 

  slience, nothing.
  Looks like patches are never acked and applied?

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||andrew.burgess at embecosm dot 
com
   ||, claziss at gmail dot com

--- Comment #10 from Oleg Endo  ---
Adding some ARC maintainers, because it is the only thing in libgcc that as a
reference to FLOAT_BIT_ORDER_MISMATCH.  I don't know what it is supposed to do
there.

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo  ---
Created attachment 41982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41982=edit
Proposed patch

I'd propose to remove the FLOAT_BIT_ORDER_MISMATCH stuff altogether.  It's more
portable to use shift-and-mask than bitfields.  Bitfields depend on too many
things, like BITS_BIG_ENDIAN, BIGGEST_FIELD_ALIGNMENT, 

The patch fixes the issue on RX.

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||joseph at codesourcery dot com

--- Comment #8 from Oleg Endo  ---
It seems this is a problem of byte/bit ordering and the way bitfields are
packed/unpacked in fp-bit.

The above cases use little endian on RX, so in fp-bit.h the following

#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
#define FLOAT_BIT_ORDER_MISMATCH
#endif

will define FLOAT_BIT_ORDER_MISMATCH.

Removing that for 64-bit-double/libgcc fixes the test case.

In fp-bit.c/unpack_d, there is a comment:

  /* We previously used bitfields to store the number, but this doesn't
 handle little/big endian systems conveniently, so use shifts and
 masks */

But then it goes on like

#ifdef FLOAT_BIT_ORDER_MISMATCH
  fraction = src->bits.fraction;
  exp = src->bits.exp;
  sign = src->bits.sign;
#else
# if defined TFLOAT && defined HALFFRACBITS

so for its definition of little endian, it still uses bitfields.
This looks a bit odd and like some unfinished work.

It seems it's not the bitfield order as used in

#ifdef FLOAT_BIT_ORDER_MISMATCH
  struct
{
  unsigned int sign:1 __attribute__ ((packed));
  unsigned int exp:EXPBITS __attribute__ ((packed));
  fractype fraction:FRACBITS __attribute__ ((packed));
}
  bits;
#endif

Trying to reverse the 3 fields doesn't help.

But for some reason, on RX sizeof (bits) is 12, not 8, when fp-bit is built for
DF.  However, when built for SF, sizeof (bits) is 4, which is correct.

So that's where the problem comes from.

There might be some bitfield issue with the RX backend, but this aside, why
can't fp-bit just use the same shift-and-mask approach also for little endian?


Adding Joseph in CC because he's listed as soft-fp maintainer.

[Bug middle-end/81828] Cilkplus performance regression on ARM...

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
>As 48-core ARM chips have just been announced by Qualcomm,

I have been using a 48 core ThunderX which is an ARMv8-a for almost 3 years now
:)  So don't bring this up really.

Cilk+ is deprecated as nobody is using it and Intel seems like added it to GCC
and then disappeared.  

See https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01209.html

> I didn't want to look into cilkplus too deeply as to why we have different
> types, because (a) I don't care (b) we're probably going to deprecate
> Cilk Plus, no?

https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01211.html

> And the more important question is if Intel is willing to maintain Cilk+ in
> GCC, or if we should deprecate it (and, if the latter, if already in GCC7
> deprecate, remove in GCC8, or deprecate in GCC8, remove in GCC9).
> There are various Cilk+ related PRs around on which nothing has been done
> for many months.

https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01220.html

> As discussed on IRC, we will probably deprecate CilkPlus for GCC7 and remove 
> it
> for GCC8 unless someone is interested in maintaining it. So...committing as 
> is.

And then nobody from Intel stepped up.

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
Created attachment 41981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41981=edit
Disassembled DF code of comment #5

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Created attachment 41980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41980=edit
Disassembled SF code of comment #5

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
I have checked with the following simplified test code:

#include 

int main (void)
{
  volatile float testval = 1;
//  volatile double testval = 1;
  testval = testval + 1;

  return ((const uint8_t*))[ sizeof (testval) - 1] == 0x40;
}


This makes it easier to disassemble.  Normally, for float and for double the
program should return 1.

When compiling for RX100 (-mcpu=rx100), all the floating point calculations are
done by soft-fp, because there is no hardware support.  So it's easier to
compare both programs than in RX600.  Even then, the float variant is OK, but
the double variant still fails.

The actual addition is done by the function __fpadd_parts in both cases.
The difference of SF and DF is in ___unpack_d, ___pack_d and ___unpack_f,
___pack_f.  The code of those *_f and *_d functions looks different, so I
assume that the *_d versions are not compiled wrongly as SF.

It must be some wrong code around there.

[Bug middle-end/81828] Cilkplus performance regression on ARM...

[ejolson at unr dot edu]

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

--- Comment #3 from Eric  ---
(In reply to Andrew Pinski from comment #1)
> Note Cilk+ have been deprecated:
> https://gcc.gnu.org/gcc-7/changes.html

As 48-core ARM chips have just been announced by Qualcomm, now seems like the
wrong time to be deprecating built-in support for parallel processing in gcc. 
I'd like to think that gcc is continuing to evolve to support new hardware and
not turning into a retro-computing project.

Presumably OpenMP is still supported and I know new versions of OpenMP support
task barriers which suspend until child tasks are complete in a way similar to
Cilkplus.  Still, the syntax of Cilkplus is easier to read and the vector
notation would be useful if it worked.

While there doesn't appear to be much interest or expertise in maintaining
Cilkplus, my opinion is that parallel programming techniques are essential to
make efficient use of modern hardware and deprecating a convenient way of
programming multi-core hardware at this point is a mistake.  To this end, maybe
it would be a good idea to figure out what is causing the slowdown in gcc
version 7.1 ARM Cilkplus even though it is deprecated.

[Bug middle-end/81828] Cilkplus performance regression on ARM...

[ejolson at unr dot edu]

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

--- Comment #2 from Eric  ---
(In reply to Andrew Pinski from comment #1)
> Note Cilk+ have been deprecated:
> https://gcc.gnu.org/gcc-7/changes.html

As 48-core ARM chips have just been announced by Qualcomm, now seems like the
wrong time to be deprecating built-in support for parallel processing in gcc. 
I'd like to think that gcc is continuing to evolve to support new hardware and
not turning into a retro-computing project.

Presumably OpenMP is still supported and I know new versions of OpenMP support
task barriers which suspend until child tasks are complete in a way similar to
Cilkplus.  Still, the syntax of Cilkplus is easier to read and the vector
notation would be useful if it worked.

While there doesn't appear to be much interest or expertise in maintaining
Cilkplus, my opinion is that parallel programming techniques are essential to
make efficient use of modern hardware and deprecating a convenient way of
programming multi-core hardware at this point is a mistake.  To this end, maybe
it would be a good idea to figure out what is causing the slowdown in gcc
version 7.1 ARM Cilkplus even though it is deprecated.

[Bug c++/81830] missing Wunused-local-typedef on a typedef of an unnamed enum or struct

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-12
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug target/81295] bootstrap broken on powerpc-linux-gnu with --enable-default-pie

[amodra at gcc dot gnu.org]

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

--- Comment #11 from Alan Modra  ---
Author: amodra
Date: Sat Aug 12 00:28:04 2017
New Revision: 251065

URL: https://gcc.gnu.org/viewcvs?rev=251065=gcc=rev
Log:
[RS6000] linux startfile/endfile

These need to match the gnu-user.h definitions to support
--enable-default-pie.  Otherwise we end up linking the wrong startup
files when defaulting to PIE.

PR target/81170
PR target/81295
* config/rs6000/sysv4.h (STARTFILE_LINUX_SPEC): Upgrade to
match gnu-user.h startfile.
(ENDFILE_LINUX_SPEC): Similarly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/sysv4.h

[Bug target/81170] powerpc*-linux --enable-default-pie chooses incorrect startup files

[amodra at gcc dot gnu.org]

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

--- Comment #1 from Alan Modra  ---
Author: amodra
Date: Sat Aug 12 00:28:04 2017
New Revision: 251065

URL: https://gcc.gnu.org/viewcvs?rev=251065=gcc=rev
Log:
[RS6000] linux startfile/endfile

These need to match the gnu-user.h definitions to support
--enable-default-pie.  Otherwise we end up linking the wrong startup
files when defaulting to PIE.

PR target/81170
PR target/81295
* config/rs6000/sysv4.h (STARTFILE_LINUX_SPEC): Upgrade to
match gnu-user.h startfile.
(ENDFILE_LINUX_SPEC): Similarly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/sysv4.h

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[a...@cloudius-systems.com]

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

--- Comment #2 from Avi Kivity  ---
Another instance:

unsigned long clear(unsigned long x) {
return x & ~ ((unsigned long)1 << 63);
}


This compiles to movabs+andq, while it could compile to a single btr
instruction.

[Bug other/81831] -Wno-psabi is not documented

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Hmm, weird:
Wpsabi
C ObjC C++ ObjC++ LTO Var(warn_psabi) Init(1) Warning Undocumented
LangEnabledBy(C ObjC C++ ObjC++,Wabi)

[Bug other/81831] New: -Wno-psabi is not documented

[munroesj at gcc dot gnu.org]

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

Bug ID: 81831
   Summary: -Wno-psabi is not documented
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: munroesj at gcc dot gnu.org
  Target Milestone: ---

The online GCC documentation mentions psABI though out the document, but
section "3.8 Options to Request or Suppress Warning" does not describe or even
mention -Wno-psabi.

This may be an issues for some of the tests I am writing which are consistently
generating the warning:

 In function 'check_union128':
/home/sjmunroe/work/gcc-trunk/gcc/gcc/testsuite/gcc.target/powerpc/m128-check.h:89:1:
note: the ABI of passing aggregates with 16-byte alignment has changed in GCC 5

I am not sure what this will do if someone asserts -Werror.

So it may be appropriate to suppress this warning for ./testsuite/gcc.target/
but when I searched the documentation I could not find any obvious way to do
that.

Segher tells me that -Wno-psabi will suppress this warning, but this is not
documented any where I can find.

[Bug c/81824] Warn for missing attributes with function aliases

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-11
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with the C++ test case below.  I'll look into the warning but I
wonder if in addition it would be worth to add some intrinsics to query and
manipulate attributes.  For instance, if the built-in __builtin_attributes__(X)
extracted all attributes from a declaration or a type it could be used to
easily declare __foo with all the same attributes as foo:

  void foo (void) __attribute__ ((nothrow));
  __typeof__ (foo) __foo __attribute ((__builtin_attributes__ ((foo;

Attributes could be removed by using another built-in, say
__builtin_remove_attribute.


$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wunused
-fdump-tree-optimized=/dev/stdout -xc++ z.c
extern "C" {

void foo (void) __attribute__ ((nothrow));
__typeof__ (foo) __foo;

void bar (void) __attribute__ ((nothrow));
__typeof__ (bar) __bar __attribute__ ((nothrow));

#if DEF

void __foo (void) { }
void __bar (void) { }

void foo (void) __attribute__ ((weak, alias ("__foo")));
void bar (void) __attribute__ ((weak, alias ("__bar")));

#else

void call_foo (void)
{
  try {
__foo ();
  }
  catch (...) {
__builtin_abort ();
  }
}

void call_bar (void)
{
  try {
__bar ();
  }
  catch (...) {
__builtin_abort ();
  }
}

#endif

}

;; Function void call_foo() (call_foo, funcdef_no=0, decl_uid=2282,
cgraph_uid=0, symbol_order=0)

void call_foo() ()
{
  void * _1;

   [100.00%] [count: INV]:
  __foo ();

   [100.00%] [count: INV]:
  return;

   [0.00%] [count: INV]:
:
  _1 = __builtin_eh_pointer (1);
  __cxa_begin_catch (_1);
  __builtin_abort ();

}



;; Function void call_bar() (call_bar, funcdef_no=1, decl_uid=2286,
cgraph_uid=1, symbol_order=1)

void call_bar() ()
{
  void * _1;

   [100.00%] [count: INV]:
  __bar (); [tail call]
  return;

}

[Bug c/80806] gcc does not warn if local array is memset only

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
My patch for this warning causes regressions in Wunused-var-8.c added for bug
44108.  As it turns out, GCC considers it a use of a variable even when it's
just mentioned in an unevaluated context (such as the sizeof expression in the
call to memset in comment #0), without being evaluated.

[Bug c++/81830] missing Wunused-local-typedef on a typedef of an unnamed enum or struct

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
This never seems to have worked correctly going as far back as GCC 4.1.0
(r104500) so it's not a regression.

[Bug c++/81830] New: missing Wunused-local-typedef on a typedef of an unnamed enum or struct

[msebor at gcc dot gnu.org]

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

Bug ID: 81830
   Summary: missing Wunused-local-typedef on a typedef of an
unnamed enum or struct
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC (in C mode) correctly diagnoses the unused typedefs in each of the two
functions below.  G++, however, only diagnoses those in f and misses those in
g.  Clang diagnoses all of them in both modes.

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wunused -xc++ x.c
void f (void)
{
  typedef enum E { e } F;  // -Wunused-local-typedefs
  typedef struct A { int i; } B;   // ditto
}

void g (void)
{
  typedef enum { e } F;  // missing -Wunused-local-typedefs in C++
  typedef struct { int i; } B;   // ditto
}
x.c: In function ‘void f()’:
x.c:3:24: warning: typedef ‘F’ locally defined but not used
[-Wunused-local-typedefs]
   typedef enum E { e } F;  // -Wunused-local-typedefs
^
x.c:4:31: warning: typedef ‘B’ locally defined but not used
[-Wunused-local-typedefs]
   typedef struct A { int i; } B;   // ditto
   ^

[Bug driver/81829] New: [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments

[doko at gcc dot gnu.org]

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

Bug ID: 81829
   Summary: [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault
without arguments
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from http://bugs.debian.org/853537]

[7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments when call
with an absolute name:

$ gdb --args /usr/bin/gcc-ar

Program received signal SIGSEGV, Segmentation fault.
__strcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
296 ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S: No such file or
directory.
(gdb) bt
#0  __strcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x00401a17 in find_a_file (pprefix=0x6061d0 , name=0x4044e6
"ar", mode=1)
at ../../src/gcc/file-find.c:81
#2  0x004016ee in main (ac=1, av=0x7fffe598) at
../../src/gcc/gcc-ar.c:205
(gdb) up
#1  0x00401a17 in find_a_file (pprefix=0x6061d0 , name=0x4044e6
"ar", mode=1)
at ../../src/gcc/file-find.c:81
81  strcpy (temp, pl->prefix);
(gdb) 

pl->prefix is NULL, set by remove_prefix

remove_prefix at the start has:

Breakpoint 1, remove_prefix (prefix=0x6070d0 "/usr/bin/", pprefix=0x6061d0
)
at ../../src/gcc/file-find.c:215
215   struct prefix_list *remove, **prev, **remove_prev = NULL;
(gdb) p *pprefix
$1 = {plist = 0x6070b0, max_len = 22, name = 0x0}
(gdb) p *pprefix->plist
$2 = {prefix = 0x607100 "/home/doko/bin/", next = 0x607120}
(gdb) p *pprefix->plist->next
$3 = {prefix = 0x607140 "/home/doko/.local/bin/", next = 0x607340}
(gdb) p *pprefix->plist->next->next
$4 = {prefix = 0x607360 "/usr/local/bin/", next = 0x607380}
(gdb) p *pprefix->plist->next->next->next
$5 = {prefix = 0x6073a0 "/usr/bin/", next = 0x6073c0}
(gdb) p *pprefix->plist->next->next->next->next
$6 = {prefix = 0x6073e0 "/bin/", next = 0x607400}
(gdb) p *pprefix->plist->next->next->next->next->next
$7 = {prefix = 0x607420 "/usr/local/games/", next = 0x607440}
(gdb) p *pprefix->plist->next->next->next->next->next->next
$8 = {prefix = 0x607460 "/usr/games/", next = 0x0}

and then at the end:

(gdb) p *remove_prev
$1 = (prefix_list *) 0x6073c0
(gdb) p **remove_prev
$2 = {prefix = 0x6073e0 "/bin/", next = 0x607400}

(gdb) p *pprefix->plist
$3 = {prefix = 0x607100 "/home/doko/bin/", next = 0x607120}
(gdb) p *pprefix->plist->next
$4 = {prefix = 0x607140 "/home/doko/.local/bin/", next = 0x607340}
(gdb) p *pprefix->plist->next->next
$5 = {prefix = 0x607360 "/usr/local/bin/", next = 0x607380}
(gdb) p *pprefix->plist->next->next->next
$6 = {prefix = 0x0, next = 0x6073c0}
(gdb) p *pprefix->plist->next->next->next->next
$7 = {prefix = 0x6073e0 "/bin/", next = 0x607400}
(gdb) p *pprefix->plist->next->next->next->next->next
$8 = {prefix = 0x607420 "/usr/local/games/", next = 0x607440}
(gdb) p *pprefix->plist->next->next->next->next->next->next
$9 = {prefix = 0x607460 "/usr/games/", next = 0x0}

looks like the next var of the previous entry is not correctly set.

[Bug fortran/81826] Incorrect handling of directives left by preprocessor

[raullaasner at gmail dot com]

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

Raul Laasner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Raul Laasner  ---
Thank you! This seems to work. Because I had no such issues with ifort, I
assumed it was a gfortran bug.

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Nick Clifton from comment #2)
> 
> So what I suspect is that something is missing from the rx libgcc
> configuration files (libgcc/config/rx/t-rx and/or libgcc/config/rx/rx-lib.h)
> which means that float_to_si() is being mis-compiled, for the 64-bit-doubles
> multilib, with the size of a double set to 32-bits.

I did a bit of digging ...

When the 64-bit-double/libgcc multilib is built, the correct -m64bit-doubles
arg is passed to the compiler.

In libgcc/config/rx/t-rx there is:

FPBIT = true
ifeq ($(double_type_size),64)
DPBIT = true
endif

and double_type_size is set to 64:

config.log:double_type_size='64'
config.log:long_double_type_size='64'
config.status:S["long_double_type_size"]="64"
config.status:S["double_type_size"]="64"
Makefile:double_type_size = 64
Makefile:long_double_type_size = 64

Taking out FPBIT, DPBIT from libgcc/config/rx/t-rx or setting both to true
doesn't make a difference.

The __RX_64BIT_DOUBLES__ check in libgcc/config/rx/rx-lib.h seems to be OK when
building 64-bit-double/libgcc, so FLOAT_ONLY is not defined and DF is not
redefined to SF.

libgcc/fp-bit.c is also compiled with things defined such as L_addsub_df.

When 64-bit-double/libgcc is built, FLOAT_ONLY is not defined in
libgcc/fp-bit.h

...

Any other ideas where or what to check?

[Bug c/81795] Stray "originally defined here" when using -Wc++-compat with #pragma GCC diagnostic push/pop

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Marek Polacek from comment #4)
> Donezo.

Thanks for the quick fix!

[Bug middle-end/81828] Cilkplus performance regression on ARM...

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
Note Cilk+ have been deprecated:
https://gcc.gnu.org/gcc-7/changes.html

[Bug c/81828] New: Cilkplus performance regression on ARM...

[ejolson at unr dot edu]

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

Bug ID: 81828
   Summary: Cilkplus performance regression on ARM...
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ejolson at unr dot edu
  Target Milestone: ---

Created attachment 41979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41979=edit
Graph showing performance regression...

Code for gcc version 7.1 using Cilkplus parallel programming extensions on ARM
is running much slower than the same code with version 6.2.  Details may by
viewed graphically as

http://fractal.math.unr.edu/~ejolson/bench/dotprod/gcc71-8.png

which consistently shows a loss of performance using any combination of 1 to 8
cores on a Samsung/Nexell S5P6818 based SBC.  More information and example code
is available at

https://www.raspberrypi.org/forums/viewtopic.php?p=711196#p1197225

My impression is that this regression affects almost all Cilkplus code on ARM
and is possibly the result unaligned cactus stack additional overhead in
switching tasks that was not present in the 6.2 version.  It is likely that
performance-based tests for ARM Cilkplus are needed to insure such regressions
do not happen in the future.  Note that the performance of serial code is not
affected.

The test code was compiled for 32-bit mode using options

-fcilkplus -O3 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard
-ffast-math

and run under identical circumstances in both cases.

[Bug c/81795] Stray "originally defined here" when using -Wc++-compat with #pragma GCC diagnostic push/pop

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Donezo.

[Bug c/81795] Stray "originally defined here" when using -Wc++-compat with #pragma GCC diagnostic push/pop

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug 11 18:02:18 2017
New Revision: 251056

URL: https://gcc.gnu.org/viewcvs?rev=251056=gcc=rev
Log:
PR c/81795
* c-decl.c (pushtag): Only print inform if the warning was printed.
(grokdeclarator): Likewise.

* gcc.dg/pr81795.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81795.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/60355] [F08] constraint C519 for BIND attribute not enforced

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Fri Aug 11 17:45:36 2017
New Revision: 251054

URL: https://gcc.gnu.org/viewcvs?rev=251054=gcc=rev
Log:
2017-08-11  Thomas Koenig  

PR fortran/60355
* resolve.c (resolve_symbol): Adjust (and reformat)
comment.  Perform check if a BIND(C) is declared
at module level regardless of whether it is typed
implicitly or not.

2017-08-11  Thomas Koenig  

PR fortran/60355
* gfortran.dg (bind_c_usage_30): New test.


Added:
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_30.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3

[andrewm.roberts at sky dot com]

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

--- Comment #4 from Andrew Roberts  ---
Looking at --param ggc-min-expand and --param ggc-min-heapsize

For gcc 8.0.0:
on arm with 1Gb RAM:
GGC heuristics: --param ggc-min-expand=93 --param ggc-min-heapsize=119808
on aarch64 with 1Gb RAM:
GGC heuristics: --param ggc-min-expand=88 --param ggc-min-heapsize=109859

So these are already slightly lower on aarch64, than on arm (presumably due to
less RAM being free after kernel usage, 789M vs 889M on arm).

Looking at individual optimizations:

as -O2 uses much more memory than -O1, I figured out the optimizations that
differed, and tried building at -O2 with each of these optimizations disabled
one by one.
The most any one optimization reduced the memory footprint by was 4%. So no
smoking gun there. The optimizations for -O2 are the same for arm and aarch64.

[Bug fortran/81827] New: Large compile time with derived-type rrays

[tkoenig at gcc dot gnu.org]

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

Bug ID: 81827
   Summary: Large compile time with derived-type rrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

From https://gcc.gnu.org/ml/fortran/2017-08/msg00036.html
by Luke Robinson:

module alloc_stress

type level1
real, allocatable :: var_r1(:), var_r2(:), var_r3(:), var_r4(:), var_r5(:)
integer, allocatable :: var_i1(:), var_i2(:), var_i3(:), var_i4(:),
var_i5(:)
complex, allocatable :: var_c1(:), var_c2(:), var_c3(:), var_c4(:),
var_c5(:)
logical, allocatable :: and_this_makes_sixteen(:)
end type level1

type level2
type(level1), allocatable :: var1(:), var2(:), var3(:), var4(:), var5(:)
end type level2

type level3
type(level2), allocatable :: var1(:), var2(:), var3(:), var4(:), var5(:)
end type level3

type level4
type(level3), allocatable :: var1(:), var2(:), var3(:), var4(:), var5(:)
end type level4

type level5
type(level4), allocatable :: var1(:), var2(:), var3(:), var4(:), var5(:)
end type level5

end module alloc_stress

program main
use alloc_stress
implicit none
! change this to level 5 if your dare!
type (level4), allocatable :: foo(:)
allocate(foo(1))
end program

This has exponential compile times going up the levels.

Some cursory analysis shows that the size of the generated code
is quite large. With level5 and current trunk, we get

[tkoenig@gcc1-power7 Stress]$ wc  alloc_stress.f90.003t.original 
  173492  1997659 29708913 alloc_stress.f90.003t.original

Seems like the long time spent in the later stages of
compilation is simply the result of this enormous code size.

[Bug target/81825] x86_64 stack realignment code is suboptimal

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
BTW, GCC 8 -O2 generates

.file   "foo.i"
.text
.p2align 4,,15
.globl  func
.type   func, @function
func:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   func, .-func
.ident  "GCC: (GNU) 8.0.0 20170810 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug target/81825] x86_64 stack realignment code is suboptimal

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from H.J. Lu  ---
Dup.

*** This bug has been marked as a duplicate of bug 81313 ***

[Bug target/81313] Bad stack realignment code with -mno-accumulate-outgoing-args

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||luto at kernel dot org

--- Comment #7 from H.J. Lu  ---
*** Bug 81825 has been marked as a duplicate of this bug. ***

[Bug fortran/81826] Incorrect handling of directives left by preprocessor

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Try adding -fpreprocessed.

[Bug fortran/81826] New: Incorrect handling of directives left by preprocessor

[raullaasner at gmail dot com]

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

Bug ID: 81826
   Summary: Incorrect handling of directives left by preprocessor
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raullaasner at gmail dot com
  Target Milestone: ---

I am trying to compile a preprocessed Fortran source file that contains a
syntax error:

  $ cat main.f90 
implicit none
a = 5
  end program
  $ gfortran -cpp -E main.f90 -o main.f90.pp.f90
  $ gfortran main.f90.pp.f90 
  main.f90.pp.f90:2:3:

   # 1 ""
 1
  Error: Symbol ‘a’ at (1) has no IMPLICIT type

The problem is that the error message refers to the preprocessed file and not
the original source file. Also, it is showing an incorrect line above the
number "1", which should be the offending line. This is unlike the C compiler:

  $ cat main.c
  int main() // {
return 0;
  }
  $ gcc -E main.c -o main.c.pp.c
  $ gcc main.c.pp.c 
  main.c: In function ‘main’:
  main.c:2:3: error: expected declaration specifiers before ‘return’
 return 0;
 ^~
  main.c:3:1: error: expected declaration specifiers before ‘}’ token
   }
   ^
  main.c:3:1: error: expected ‘{’ at end of input

where the error message refers to the correct source file (main.c:2:3).

This issue was brought up at
https://gitlab.kitware.com/cmake/cmake/issues/17160#note_301744 and it inhibits
the correct behavior of CMake with the Ninja generator.

[Bug target/81825] New: x86_64 stack realignment code is suboptimal

[luto at kernel dot org]

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

Bug ID: 81825
   Summary: x86_64 stack realignment code is suboptimal
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luto at kernel dot org
  Target Milestone: ---

I compiled this:

void func()
{
int var __attribute__((aligned(32)));
asm volatile ("" :: "m" (var));
}

using gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3).  I got (after stripping CFI
stuff):

func:
leaq8(%rsp), %r10
andq$-32, %rsp
pushq   -8(%r10)
pushq   %rbp
movq%rsp, %rbp
pushq   %r10
popq%r10
popq%rbp
leaq-8(%r10), %rsp
ret

I have three objections to this code.

1. The push and immediate pop of %r10 seems pointless.  Maybe it's due to some
weird DWARF limitation?  A register allocation limitation sounds more likely,
though.

2. The addressing modes used for r10 are suboptimal.  Shouldn't the first
instruction be just movq %rsp, %r10?  By my count, this would save 12 bytes of
text.

3. Couldn't the whole thing just be:

pushq %rbp
movq %rsp, %rbp
andq $-32, %rsp

function body here.  rbp can't be used to locate stack variables, but rsp can.

leaveq
ret

[Bug c/81824] New: Warn for missing attributes with function aliases

[jsm28 at gcc dot gnu.org]

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

Bug ID: 81824
   Summary: Warn for missing attributes with function aliases
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

Consider code like the following:

void foo (void) __attribute__ ((nothrow));
void __foo (void);
void
__foo (void)
{
}
void foo (void) __attribute__ ((weak, alias ("__foo")));

Here, the properties of the nothrow attribute are true for __foo as well as
foo, but code calling __foo (seeing the declarations, not the definition) won't
benefit from the attribute.  This is typical of code in glibc: the public
header declares foo with some attributes, the internal header may or may not
have those attributes on the internal version (even if it uses typeof when
declaring the internal function to avoid duplicating the type, that doesn't
replicate function attributes), calls to the internal version don't benefit
from the attributes if missing from the declaration.  When compiling the file
with the implementation, it's possible to see that the two functions are the
same, and so that the attributes are missing from one declaration.  It would be
useful to have a warning for this case.

Note: this warning is only for attributes relating to the function itself, not
to those relating to a particular name for the function.  For example, weak,
alias, visibility attributes are expected to differ between different names and
shouldn't be diagnosed.  It would be necessary to work out which existing
function attributes fall in which category.

Note: some relevant attributes may actually apply to the function's type not
the function itself; it's still useful to diagnose when they are missing on one
of the aliased functions.

Note: I don't know how many false positives this warning might have in glibc,
and so whether it would be possible to enable it for all glibc builds or only
for a manual review of code in glibc to try to reduce the number of such cases
of missing attributes.

[Bug lto/81430] nvptx acceleration compilation broken because of running pass_partition_blocks

[tschwinge at gcc dot gnu.org]

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

--- Comment #10 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Aug 11 15:37:14 2017
New Revision: 251053

URL: https://gcc.gnu.org/viewcvs?rev=251053=gcc=rev
Log:
[PR lto/81430] Revert "Add nvptx_override_options_after_change"

This reverts r250421; properly fixed by r250852.

PR lto/81430
* config/nvptx/nvptx.c (nvptx_override_options_after_change):
Remove function.
(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): Remove definition.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug target/81732] 'Error: Architecture mismatch on "rd".' in libcilkrts when compiling for sparc-linux-gnu

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
Summary|Error: Architecture |'Error: Architecture
   |mismatch on "rd".   |mismatch on "rd".' in
   ||libcilkrts when compiling
   ||for sparc-linux-gnu

--- Comment #2 from Eric Gallager  ---
Updating title to be more specific

[Bug c++/81787] `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-11
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Ben Longbons from comment #0)
> This worked with 4.7, but fails with 4.8 through 7.1.
> 
> 
> Original reports on StackOverflow:
> 
> https://stackoverflow.com/questions/10932479/in-gcc-how-to-mute-the-fpermissive-warning
> 
> https://stackoverflow.com/questions/45600368/how-to-supress-a-fpermissive-error-using-modern-gcc

Could you post any relevant test cases from them here, in case StackOverflow
ever becomes inaccessible?

[Bug c++/81761] assembler error on __func__ et al. on attribute target overloads

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target|powerpc64le-*-linux,|
   |x86_64-*-linux  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-11
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, message for me is:

$ /usr/local/bin/g++ -c -Wall -Wextra 81761.cc
/var/tmp//ccqm9pwP.s:85:FATAL:Symbol __ZZ3foovE8__func__ already defined.
$

Removing targets because it also happens for me on i386-apple-darwin9.8.0, so
it's not specific to the ones you listed.

(also it'd be nice to improve the testcase to have an explicit __func__ in it,
instead of relying on the expansion of assert() to contain one)

[Bug ipa/77732] FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2017-08-11 7:51 AM, jamborm at gcc dot gnu.org wrote:
> Meanwhile, John, since you seem to have access to an hppa machine, can
> you please test and if it works commit the following?

Will do.

[Bug c++/81762] errors defining attribute target overloads of the same function template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target|x86_64-*-linux  |x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-11
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed. Modifying target since it's not Linux-specific.

[Bug target/81823] New: [RX] Improve support for atomics other than SImode

[olegendo at gcc dot gnu.org]

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

Bug ID: 81823
   Summary: [RX] Improve support for atomics other than SImode
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: rx*-*-*

Atomics that perform arithmetic are only implemented for SImode.  It should be
extended to support QImode and HImode in the same way.

Moreover, when doing atomic ior, xor, and operations with constants that
consist of only one bit, the following instructions can be used:

   ior -> bset
   xor -> bnot
   and -> bclr

Although the memory operand of those instructions is always a byte, it can also
be used on wider types by adjusting the byte offset (depending on the current
endian mode).

The bset, bnot and bclr instructions are very useful when dealing with GPIO
port registers.

[Bug c++/81721] precompiled header : internal compiler error: Segmentation fault

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Juro Bystricky from comment #2)
> This patch fixes the issue:
> http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140486.html

patches go to the gcc-patches mailing list

[Bug c++/81718] g++ segfault in tsubst_copy_and_build when creating type alias

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-11
 CC||egallager at gcc dot gnu.org
Summary|g++ segfault when creating  |g++ segfault in
   |type alias  |tsubst_copy_and_build when
   ||creating type alias
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x0016b32c in tsubst_copy_and_build ()
(gdb) bt
#0  0x0016b32c in tsubst_copy_and_build ()
#1  0x00152b11 in tsubst_expr ()
#2  0x0015e1e6 in tsubst_template_arg ()
#3  0x0015e3c8 in tsubst_template_args ()
#4  0x0015ca0b in tsubst ()
#5  0x0015cfe3 in tsubst ()
#6  0x00173898 in lookup_template_class ()
#7  0x0019aa2e in finish_template_type ()
#8  0x00118da8 in cp_parser_template_id ()
#9  0x00118f18 in cp_parser_class_name ()
#10 0x00125fca in cp_parser_nested_name_specifier_opt ()
#11 0x00123af7 in cp_parser_simple_type_specifier ()
#12 0x0011fbe0 in cp_parser_type_specifier ()
#13 0x00121a60 in cp_parser_type_specifier_seq ()
#14 0x00121b27 in cp_parser_type_id_1 ()
#15 0x00122def in cp_parser_alias_declaration ()
#16 0x00133177 in cp_parser_template_declaration_after_parameters ()
#17 0x00133873 in cp_parser_template_declaration_after_export ()
#18 0x00139eba in cp_parser_declaration ()
#19 0x0013a23a in cp_parser_declaration_seq_opt ()
#20 0x0013a52e in c_parse_file ()
#21 0x00238f6b in c_common_parse_file ()
#22 0x00b16425 in compile_file ()
#23 0x01a9e35e in toplev::main ()
#24 0x01a9fa34 in main ()
(gdb)

I would have to rebuild my gcc with debug info to get a better backtrace.

[Bug target/81821] [RX] xchg_mem uses wrong memory operand size

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
A possible fix:

Index: gcc/config/rx/rx.md
===
--- gcc/config/rx/rx.md (revision 251045)
+++ gcc/config/rx/rx.md (working copy)
@@ -2167,6 +2167,7 @@
   [(plus "add") (minus "sub") (ior "ior") (xor "xor") (and "and")])

 (define_mode_iterator QIHI [QI HI])
+(define_mode_attr BW [(QI "B") (HI "W")])

 (define_insn "sync_lock_test_and_setsi"
   [(set (match_operand:SI 0 "register_operand"   "=r,r")
@@ -2208,7 +2209,7 @@
(set (match_dup 1)
(match_operand:QIHI 2 "register_operand""0"))]
   ""
-  "xchg\t%1, %0"
+  "xchg\t%1., %0"
   [(set_attr "length" "6")
(set_attr "timings" "22")]
 )

[Bug c/81756] type attributes silently ignored on type declarations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-11
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug c/81785] Segmentation fault for signed overflow in index expression when -fwrapv is enabled

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-11
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
runs fine for me with GCC 8 on i386-apple-darwin9.8.0 (32-bit), but segfaults
on me when I add -m64 to force 64-bit. -Wall -Wextra -Wstrict-overflow=5
-Warray-bounds=2 all print nothing. So confirmed that the code crashes,
although someone else will have to say if GCC is truly the one at fault here.

[Bug target/81821] [RX] xchg_mem uses wrong memory operand size

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

Summary|[RX] __atomic_test_and_set  |[RX] xchg_mem uses
   |overwrites adjacent memory  |wrong memory operand size

--- Comment #1 from Oleg Endo  ---
As it turns out, the xchg_mem pattern does not output a specifier.  So
this problem is not only restricted to __atomic_test_and_set, but also to 8 bit
and 16 bit atomic exchange builtins.

[Bug target/81822] New: [RX] Should implement __atomic_compare_exchange

[olegendo at gcc dot gnu.org]

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

Bug ID: 81822
   Summary: [RX] Should implement __atomic_compare_exchange
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: rx*-*-*

There are some places which check if the target directly supports SImode atomic
compare and exchange, via the __GCC_ATOMIC_INT_LOCK_FREE macro.  In particular
the C++ std library.

The atomic pattern should be implemented to improve library and user code
compatibility.

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
I see. compute_uninlined_call_time uses counts when they are available and
frequencies when they are not.  It makes sense that dropping count to 0 will
lead to change of compute_uninlined_call_time. I am bit surprised it is that
large (it would be nice to know why).

Otherwise I have WIP path that gets rid of frequencies completely, so it will
fix this problem.  I will try to finish it soon.

Thanks a lot for looking into this!
Honza

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[hubicka at gcc dot gnu.org]

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

--- Comment #23 from Jan Hubicka  ---
determine_unlikely_bbs is intended to propagate known to be cold bbs
(profile_count::zero) rather than guessed_zero so it seems to do the job
correctly here, because we decide to trust the cold attribute (I am still
undecided if we don't want to invent unlikely attribute for that).

I will take a look why this leads to ICE on propagating frequencies.

[Bug target/81821] New: [RX] __atomic_test_and_set overwrites adjacent memory

[olegendo at gcc dot gnu.org]

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

Bug ID: 81821
   Summary: [RX] __atomic_test_and_set overwrites adjacent memory
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---

__atomic_test_and_set is supposed to change only one byte, but on RX it wrongly
overwrites adjacent memory locations:


int test (volatile char* x)
{
  return __atomic_test_and_set (x, 0);
}

__Z4testPVc:
mov #1, r14
xchg[r1], r14 // xchg is 32 bit
movu.B  r14, r1
rts

It seems a .b or .w specifier can be added to the memory operand of xchg.

[Bug tree-optimization/81814] Incorrect behaviour at -O0 (conditional operator)

[d25fe0be at outlook dot com]

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

--- Comment #5 from d25fe0be@  ---
Oops, sorry, I read the 2nd and the 3rd operand of the conditional operator in
wrong order.

A silly mistake..

[Bug ipa/81465] [8 Regression] ICE in estimate_edge_growth at gcc/ipa-inline.h:85 on s390x target

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Jan Hubicka  ---
OK, so now the tests passes when inline clone is either in no comdat group list
(even if function inlined to is in one) or if the comdat groups are the same. 
Does it fail when we test that comdats groups are always the same?  It seems
iffy to allow silently both.  I guess both variants are fine, but lets pick one
of them. Perhaps we want only to remove node from comdat group list while
inlining it.

Honza

[Bug tree-optimization/81814] Incorrect behaviour at -O0 (conditional operator)

[d25fe0be at outlook dot com]

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

--- Comment #4 from d25fe0be@  ---
Per n4659 7.8/[conv.integral]:

```
If the destination type is signed, the value is unchanged if it can be
represented in the destination type;
otherwise, the value is implementation-defined.
```

Isn't `(char)xxx` implementation-defined? (as GCC treats `char` as signed)

And as the following code prints 0, I believe that GCC defines the result of
such casting as 0:

```
#include 
int xxx = 0x0100;
int main() {
printf("%d\n", (char)xxx);
return 0;
}
```

So I think the output should indeed be 0.

[Bug c++/81486] Class template argument deduction fails with (), succeeds with {}

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

 CC||benni.buch at gmail dot com

--- Comment #1 from Benjamin Buch  ---
I did run into the same problem.

[Bug ipa/81465] [8 Regression] ICE in estimate_edge_growth at gcc/ipa-inline.h:85 on s390x target

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 41978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41978=edit
Tested patch candidate

Adding patch candidate that changes cgraph_node::verify_node that verifies
global.inlined_to && same_comdat_group. It believe proper fix is to verify that
node should live in a same comdat group (if belongs to any).

[Bug ipa/81465] [8 Regression] ICE in estimate_edge_growth at gcc/ipa-inline.h:85 on s390x target

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 41977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41977=edit
Tested patch candidate

Adding patch candidate that adds:
!opt_for_fn (edge->caller->decl, optimize)) to estimate_edge_growth. That's
need because the mentioned revision introduced:

  FOR_EACH_DEFINED_FUNCTION (node)
if (!node->alias
&& (flag_generate_lto || flag_generate_offload|| flag_wpa
|| opt_for_fn (node->decl, optimize)))
  inline_analyze_function (node);

which does not calculate ipa_call_summaries->get (edge)->call_stmt_size.
With the patch applied, no other inlining happens as inline_small_functions
skips functions w/o optimize option.

[Bug target/81820] New: -Os may remove debug info

[hjl.tools at gmail dot com]

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

Bug ID: 81820
   Summary: -Os may remove debug info
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

r251028 improves -Os on x86 since -Os implies -fno-omit-frame-pointer
and r251028 removes frame pointer when it is not needed:

[hjl@gnu-tools-1 debug]$ cat y.c
struct S { float f, g; };

void
foo (struct S *p)
{
  struct S s1, s2;
  s1 = *p;
  s2 = s1;
  *(int *)  = 0;
  asm volatile ("nop" : : : "memory");
  asm volatile ("nop" : : : "memory");
  s2 = s1;
  asm volatile ("nop" : : : "memory");
  asm volatile ("nop" : : : "memory");
}
[hjl@gnu-tools-1 debug]$ /usr/gcc-7.1.1-x32/bin/gcc -S -Os -m32 y.c
[hjl@gnu-tools-1 debug]$ cat y.s
.file   "y.c"
.text
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
#APP
# 10 "y.c" 1
nop
# 0 "" 2
# 11 "y.c" 1
nop
# 0 "" 2
# 13 "y.c" 1
nop
# 0 "" 2
# 14 "y.c" 1
nop
# 0 "" 2
#NO_APP
popl%ebp
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 7.1.1 20170724"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 debug]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -S -m32   y.c
[hjl@gnu-tools-1 debug]$ cat y.s
.file   "y.c"
.text
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
#APP
# 10 "y.c" 1
nop
# 0 "" 2
# 11 "y.c" 1
nop
# 0 "" 2
# 13 "y.c" 1
nop
# 0 "" 2
# 14 "y.c" 1
nop
# 0 "" 2
#NO_APP
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 8.0.0 20170811 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 debug]$ 

However with -Os -g, frame pointer is used in debug_insn:

(note 3 4 6 2 NOTE_INSN_FUNCTION_BEG)
(debug_insn 6 3 7 2 (var_location:SF D#4 (mem:SF (mem/f/c:SI (plus:SI (reg/f:SI
6 bp)
(const_int 8 [0x8])) [4 p+0 S4 A32]) [0 MEM[(struct S
*)p_2(D)]+0 S4 A32])) "y.c":7 -1
 (nil))
(debug_insn 7 6 8 2 (var_location:SF s1$f (debug_expr:SF D#4)) "y.c":7 -1
 (nil))
(debug_insn 8 7 9 2 (var_location:SF D#3 (mem:SF (plus:SI (mem/f/c:SI (plus:SI
(reg/f:SI 6 bp)
(const_int 8 [0x8])) [4 p+0 S4 A32])
(const_int 4 [0x4])) [0 MEM[(struct S *)p_2(D) + 4B]+0 S4 A32]))
"y.c":7 -1
 (nil))
(debug_insn 9 8 11 2 (var_location:SF s1$g (debug_expr:SF D#3)) "y.c":7 -1
 (nil))
(debug_insn 11 9 12 2 (var_location:SF s2$g (debug_expr:SF D#3)) "y.c":8 -1
 (nil))
(debug_insn 12 11 13 2 (var_location:SI s2 (const_int 0 [0])) "y.c":9 -1
 (nil))
(insn 13 12 14 2 (parallel [
(asm_operands/v ("nop") ("") 0 []
 []
 [] y.c:10)
(clobber (mem:BLK (scratch) [0  A8]))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) "y.c":10 -1
 (nil))

before frame pointer is eliminated.  After frame pointer is eliminated,
these debug insns are removed and debug info is lost.

We should update debug_insn when frame pointer is removed to ensure that
-g doesn't change codegen.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[marxin at gcc dot gnu.org]

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

--- Comment #22 from Martin Liška  ---
Created attachment 41976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41976=edit
Patch candidate

So I believe that problem is hidden in determine_unlikely_bbs where we set
bb->count = profile_count::zero () for:

b ()
{
   [0.00%] [count: INV]:
  a ();
  return;

}

I think it's not correct and we should set profile_count::guessed_zero ().
Similarly in similar situations in the function. Second problem is at the end
of function where we guard wrongly count assignment with dump_file presence.
That should be also fixed in the patch.
I was able to bootstrap, but ./gcc/testsuite/gcc.dg/compare2.c test-case fails
not. Can you please Honza take a look?

[Bug tree-optimization/81814] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Ugh, I believe fold_cond_expr_with_comparison does Very Bad stuff: it sees
A == 0 ? A : 0 and thinks that it can be optimized to 0, btu it can't, in this
case we have
(signed char) xxx == 0 ? (unsigned long long) xxx : 0
(signed char) xxx is indeed 0 but (unsigned long long) xxx is not.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #20)
> (In reply to Martin Liška from comment #19)
> > (In reply to Markus Trippelsdorf from comment #8)
> > > Reduced Boost testcase:
> > I'm testing patch for this PR. Markus what options are needed to spot ICE
> > with this test-case? Can't reproduce it.
> 
> It was fixed by r250310. Only the comment 10 testcase still ICEs.

Good, thanks.

[Bug target/81801] [PATCH] Difference of two pointers generates signed overflow

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Fri, 11 Aug 2017, oss at malat dot biz wrote:

> One could solve it by dividing both pointers by the size before the
> subtraction, but that would make the operation more expensive.

See also what I said in bug 67999 comment 24.

The combination (subtract to produce a ptrdiff_t result, with modulo 
arithmetic on overflow, then divide in ptrdiff_t) isn't correct for 
objects too large in bytes for ptrdiff_t.  But the following should be 
correct: right shift (logical) both pointers for the power-of-2 factor in 
what you are dividing by, subtract (modulo), multiply (modulo) by the (mod 
2^n) reciprocal of the odd part of what you are dividing by, interpret the 
result as signed.

It's less efficient than code sequences that only work for objects less 
than half the address space, and such large objects can never work if you 
do pointer subtraction of pointers to char that are too far apart to be 
represented in ptrdiff_t.  I think it makes most sense to disallow such 
large objects properly (including in malloc and mmap), but an option to 
support pointer subtraction in them would not be ridiculous.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[trippels at gcc dot gnu.org]

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

--- Comment #20 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #19)
> (In reply to Markus Trippelsdorf from comment #8)
> > Reduced Boost testcase:
> I'm testing patch for this PR. Markus what options are needed to spot ICE
> with this test-case? Can't reproduce it.

It was fixed by r250310. Only the comment 10 testcase still ICEs.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #8)
> Reduced Boost testcase:
> 
> struct A;
> struct B {
>   typedef A *type;
> };
> struct C {
>   B::type operator->();
> };
> struct D {
>   struct F {
> F(void(void *), F *, void());
>   };
>   template  struct J : F {
> FunT m_Function;
> J(FunT) : F(m_fn1, 0, 0) {}
> static void m_fn1(void *) { static_cast(0)->m_Function(); }
>   };
>   F *m_pImpl;
>   template  D(FunT p1) : m_pImpl(new J(p1)) {}
> };
> struct A {
>   void m_fn2(D);
> };
> struct G {
>   void operator()() { throw; }
> };
> struct H {
>   void operator()() try { G()(); } catch (int) {
>   }
> };
> struct I {
>   void operator()() { H()(); }
> };
> void fn1() {
>   I a;
>   C b;
>   b->m_fn2(a);
> }

I'm testing patch for this PR. Markus what options are needed to spot ICE with
this test-case? Can't reproduce it.

[Bug ipa/77732] FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
(In reply to Martin Liška from comment #1)
> So hppa uses invisible reference to pass the struct argument.
> Thus I guess we should not run the test-case on hppa target? Martin can you
> please take a look?

I think your analysis is correct and I think we should XFAIL it on
hppa.  Then we know it is a missing functionality and I may look into
handling invisible references it if I ever have access to a machine
using them.

Meanwhile, John, since you seem to have access to an hppa machine, can
you please test and if it works commit the following?


diff --git a/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
b/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
index 6af8bda6d8e..c06abd1e8fb 100644
--- a/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
+++ b/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
@@ -62,4 +62,4 @@ h (int x)
   return bar (s, x);
 }

-/* { dg-final { scan-ipa-dump-times "Discovered an indirect call to a known
target" 3 "cp" } } */
+/* { dg-final { scan-ipa-dump-times "Discovered an indirect call to a known
target" 3 "cp" { xfail { hppa*-*-* } } } } */

[Bug regression/81819] New: [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311

[olegendo at gcc dot gnu.org]

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

Bug ID: 81819
   Summary: [7 Regression][RX] internal compiler error: in
rx_is_restricted_memory_address, at config/rx/rx.c:311
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---

This error shows up when building a bigger app on RX with LTO.  It is working
OK on GCC 6.

/usr/local/rx-elf/include/c++/7.1.1/bits/char_traits.h: In function
'mount_partition.constprop':
/usr/local/rx-elf/include/c++/7.1.1/bits/char_traits.h:264:41: internal
compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311
  return __builtin_memcmp(__s1, __s2, __n);
 ^
0xb69733 rx_is_restricted_memory_address(rtx_def*, machine_mode)
../../gcc-7-branch/gcc/config/rx/rx.c:311
0xc576f3 rx_restricted_mem_operand(rtx_def*, machine_mode)
../../gcc-7-branch/gcc/config/rx/predicates.md:54
0xc57757 rx_source_operand(rtx_def*, machine_mode)
../../gcc-7-branch/gcc/config/rx/predicates.md:61
0x82aae2 insn_operand_matches(insn_code, unsigned int, rtx_def*)
../../gcc-7-branch/gcc/optabs.c:6874
0x82aae2 prepare_operand(insn_code, rtx_def*, int, machine_mode, machine_mode,
int)
../../gcc-7-branch/gcc/optabs.c:3965
0x82ace5 prepare_cmp_insn
../../gcc-7-branch/gcc/optabs.c:3874
0x82b766 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
../../gcc-7-branch/gcc/optabs.c:4051
0x60a4de do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
../../gcc-7-branch/gcc/dojump.c:1145
0x68086e compare_by_pieces_d::generate(rtx_def*, rtx_def*, machine_mode)
../../gcc-7-branch/gcc/expr.c:1455
0x6819b3 op_by_pieces_d::run()
../../gcc-7-branch/gcc/expr.c:1090
0x68a88b compare_by_pieces
../../gcc-7-branch/gcc/expr.c:1517
0x68a88b emit_block_cmp_hints(rtx_def*, rtx_def*, rtx_def*, tree_node*,
rtx_def*, bool, rtx_def* (*)(void*, long, machine_mode), void*)
../../gcc-7-branch/gcc/expr.c:1970
0x59255a expand_builtin_memcmp
../../gcc-7-branch/gcc/builtins.c:4234
0x59255a expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc-7-branch/gcc/builtins.c:6760
0x686b34 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-7-branch/gcc/expr.c:10821
0x68ee70 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc-7-branch/gcc/expr.c:5552
0x68fbdf expand_assignment(tree_node*, tree_node*, bool)
../../gcc-7-branch/gcc/expr.c:5321
0x5aa03a expand_call_stmt
../../gcc-7-branch/gcc/cfgexpand.c:2656
0x5aa03a expand_gimple_stmt_1
../../gcc-7-branch/gcc/cfgexpand.c:3571
0x5aa03a expand_gimple_stmt
../../gcc-7-branch/gcc/cfgexpand.c:3737


Unfortunately, I don't know how to get a reproducer for that.

The function 'rx_is_restricted_memory_address' gets an 
  (subreg:SI (reg/v:DI 236 [ name ]) 4)

as 'rtx mem' argument, which is not handled by the code.

The following makes the ICE go away, but I haven't tested whether the resulting
code runs properly.

Index: gcc/config/rx/rx.c
===
--- gcc/config/rx/rx.c  (revision 251045)
+++ gcc/config/rx/rx.c  (working copy)
@@ -284,6 +284,9 @@
   /* Simple memory addresses are OK.  */
   return true;

+case SUBREG:
+  return RX_REG_P (SUBREG_REG (mem));
+
 case PRE_DEC:
 case POST_INC:
   return false;

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
I've got it what's responsible. When the edge_badness is called for the first
time, we call compute_uninlined_call_time where:

(gdb) p edge->count.to_gcov_type ()
$25 = 194

Then various clones of the caller (app_disable) are created:

#0  profile_count::operator-= (other=..., this=0x2aaab9c1d270) at
../../gcc/profile-count.h:683
#1  cgraph_edge::clone (this=this@entry=0x2aaab9c1d270,
n=n@entry=0x2aaab8ebee60, call_stmt=, stmt_uid=3, num=...,
den=..., freq_scale=, update_original=true) at
../../gcc/cgraphclones.c:147
#2  0x006a20fc in cgraph_node::create_clone (this=0x2aaab9c038a0,
new_decl=, prof_count=..., freq=freq@entry=94,
update_original=, redirect_callers=...,
redirect_callers@entry=..., call_duplication_hook=, 
new_inlined_to=, args_to_skip=,
suffix=) at ../../gcc/cgraphclones.c:492
#3  0x0127a3ff in clone_inlined_nodes (e=e@entry=0x2aaab9c266e8,
duplicate=duplicate@entry=true, update_original=update_original@entry=true,
overall_size=overall_size@entry=0x1f5c3a0 <_ZL12overall_size>, freq_scale=94)
at ../../gcc/ipa-inline-transform.c:235
#4  0x0127ae61 in inline_call (e=0x2aaab9c266e8,
update_original=, new_edges=,
overall_size=, update_overall_summary=,
callee_removed=) at ../../gcc/ipa-inline-transform.c:462

where counter changes:
Old value = 194
New value = 91

note that in #4 it's shown that callee is app_disable
(gdb) p e->caller->name()
$26 = 0x2e4acef0 "final_scan_insn"
(gdb) p e->callee->name()
$27 = 0x2e6aa1b0 "app_disable"

This repeats various time and we end up eventually with the counter == 0. Then
compute_uninlined_call_time
returns 0.09765625 instead of 2.8684735298156738e-07.

[Bug c++/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3 (memory-hog)

[andrewm.roberts at sky dot com]

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

--- Comment #3 from Andrew Roberts  ---
I've added the test results for the arm and aarch64 builds on Raspberry Pi3.
These show compilation time, memory used, and object file size for:
-O0, -Os, -O1, -O2, -O3
using gcc 5.4.0, 6.4.0, 7.2.0, and 8.0.0

7.2.0 is the rc2 version, 8.0.0 is latest weekly snapshot.

The memory and compilation time issues are not speciific to any of the above
gcc
versions. It seems to have always been an issue with aarch64.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[mpe at ellerman dot id.au]

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

Michael Ellerman  changed:

   What|Removed |Added

 CC||mpe at ellerman dot id.au

--- Comment #18 from Michael Ellerman  ---
Any prospect of getting this fixed? I haven't been able to build Linux for ~a
month now because of this.

[Bug c++/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3 (memory-hog)

[andrewm.roberts at sky dot com]

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

--- Comment #2 from Andrew Roberts  ---
Created attachment 41975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41975=edit
Full test results for aarch64 on Raspberry Pi3

Test results for -O0, -Os, -O1, -O2, -O3 for gcc 5.4.0, 6.4.0, 7.2.0, 8.0.0
on Raspberry Pi3 running 64 bit kernel (aarch64).

[Bug lto/81817] ICE in lto1 with -fopenmp offloading and nested #pragma omp target

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||amonakov at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Alexander Monakov  ---
It seems you've submitted two identical bugs - closing as duplicate of the
earlier one.

*** This bug has been marked as a duplicate of bug 81816 ***

[Bug lto/81816] ICE in lto1 with -fopenmp offloading and nested #pragma omp target

[amonakov at gcc dot gnu.org]

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

--- Comment #1 from Alexander Monakov  ---
*** Bug 81817 has been marked as a duplicate of this bug. ***

[Bug c++/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3 (memory-hog)

[andrewm.roberts at sky dot com]

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

--- Comment #1 from Andrew Roberts  ---
Created attachment 41974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41974=edit
Full test report for Raspberry Pi ARM

Test results for -O0, -Os, -O1, -O2, -O3 for gcc 5.4.0, 6.4.0, 7.2.0, 8.0.0
on Raspberry Pi3 running 32 bit kernel (arm).

[Bug c++/81818] New: aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3 (memory-hog)

[andrewm.roberts at sky dot com]

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

Bug ID: 81818
   Summary: aarch64  uses 2-3x memory and 2x time of arm at -Os,
-O2, -O3 (memory-hog)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewm.roberts at sky dot com
  Target Milestone: ---

Created attachment 41973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41973=edit
System independent test program to demonstrate the issue.

I've run into problems building both gcc its self and my application
on aarch64. The system was running out of memory, and the compliler was
aborting
with an ICE:

g++: internal compiler error: Killed (program cc1plus)

I've raised the issue on the gcc list (gcc behavior on memory exhaustion), and 
people are looking at getting a better error message indicating that out of 
memory may be an issue.

The remaining issue is what can be done about the memory usage of the aarch64 
version of gcc, which seems much worse than arm, and x64.

--
gcc on aarch64 uses 3x the memory of arm, and is 2.2x slower in compiling.
This is apparent at -Os, -O2 and -O3.
--

I've cut my program down and made it system independent (testmap.cpp,
attached).
The program consists of two functions, one of which populates a multimap
with 2400 inserts. Basically it's just doing:

#include 
typedef std::multimap EnumMap_t;
static EnumMap_t EnumMap;
...
EnumMap.insert(EnumMap_t::value_type(0u, "0"));
EnumMap.insert(EnumMap_t::value_type(1u, "1"));
...
EnumMap.insert(EnumMap_t::value_type(2399u, "2399"));
... 

I've built this across x64 (Ryzen), arm (Raspberry Pi3), and aarch64 (Raspbery 
Pi3, and Odroid-C2). x64 is on Fedora, the rest are on Arch Linux Arm. The 
Raspberry Pi's have 1Gb RAM, the ODroid 2Gb, x64 has 32Gb. 

Compiling this single file exhausts most of the RAM on the Raspberry PI, and 
thus any parallel builds fail, or slow right down if swap file is used.

I've attached log files for builds at -O0, -O1, -O2, -O3 and -Os on all the
systems, using gcc 5.4.0, 6.4.0, 7.2.0rc2 and 8.0.0 snapshot.

Here is a summary of the results: 
all build using:
gcc -Ox -c testmap.cpp
where -Ox is one of -O0, -Os, -O1, -O2, -O3

Memory Usage (Kb)
-O05.4.0   6.4.0   7.2rc2  8.0.0
x64223676  223688  223736  223728
arm156204  156336  156336  156292
pi aarch64 224324  224596  224424  224572
od aarch64 217492  217604  217492  217540

-Os5.4.0   6.4.0   7.2rc2  8.0.0
x64392448  392512  392688  392680
arm205724  205792  205896  205664
pi aarch64 422520  422636  422208  422604 <= Higher than x64, 2x arm
od aarch64 416776  416260  416684  416708 <= Higher than x64, 2x arm

-O15.4.0   6.4.0   7.2rc2  8.0.0
x64394596  394568  394352  394232
arm319976  319896  319900  319840
pi aarch64 393944  393996  393836  394000
od aarch64 391636  391652  391636  391640

-O25.4.0   6.4.0   7.2rc2  8.0.0
x64628816  628972  628772  628896
arm267832  267860  267716  267836
pi aarch64 815260  784288  799196  812504  <= Higher than x64, 3x arm
od aarch64 813252  813068  813052  813084  <= Higher than x64, 3x arm

-O35.4.0   6.4.0   7.2rc2  8.0.0
x64629284  629472  629116  629236
arm266364  266264  266240  266412
pi aarch64 724168  723760  724000  724148  <= Higher than x64, 2.7x arm
od aarch64 718628  718388  718608  718608  <= Higher than x64, 2.7x arm

It's a similar story with compile times. I'll just compare apples with apples
here (identical hardware just arm vs aarch64 distibution/compiler):

-Os5.4.0   6.4.0   7.2rc2  8.0.0
arm3:05.82 3:06.41 3:03.30 3:05.58
pi aarch64 5:59.43 6:07.95 6:04.69 5:55.98 <= 2.0x arm

-O35.4.0   6.4.0   7.2rc2  8.0.0
arm2:14.83 2:15.77 2:14.87 2:15.94
pi aarch64 5:02.46 5:02.44 5:02.47 5:02.46 <= 2.2x arm

Both arm and aarch64 versions are using the same binutils:
GNU ld (GNU Binutils) 2.28.0.20170506

I built the compilers myself using same options for all versions:

ARM:
/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/armv7l-unknown-linux-gnueabihf/8.0.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran --disable-libgcj 

[Bug libstdc++/81751] [5/6/7 Regression]__basic_file::sync() may flush _all_ files

[bugzilla.volker at kabelmail dot de]

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

--- Comment #9 from Volker Wehrs  ---
Thank you, I guess that change should fix the bug.

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
So when the edge is insert to the heap we see:

Badness calculation for app_disable/164630 ->
_Z11app_disablev.part.30/166180
  size growth 6, time 16.00 unspec 216.00 
 Wrapper penalty. Increasing growth -4 to 30
  -0.000709: guessed profile. frequency 0.00, count 195 caller count
66781966 time w/o inlining 5.00, time with inlining 5.00 overall growth
-4 (current) -4 (original) 900 (compensated)
  Adjusted by hints -0.002838

and when the ICE happens:

Badness calculation for app_disable/164630 ->
_Z11app_disablev.part.30/166180
  size growth 6, time 16.00 unspec 216.00 
 Wrapper penalty. Increasing growth -4 to 30
  -0.748913: guessed profile. frequency 0.00, count 0 caller count
207383 time w/o inlining 5.105469, time with inlining 5.007812 overall growth
38 (current) -4 (original) 900 (compensated)
  Adjusted by hints -2.995652

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

  Attachment #41970|0   |1
is obsolete||

--- Comment #9 from Tom de Vries  ---
Created attachment 41972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41972=edit
Updated patch

Updated patch, passes check-target-libgomp and check-gcc/gomp.exp.

[Bug lto/81817] New: ICE in lto1 with -fopenmp offloading and nested #pragma omp target

[igor.venevtsev at intel dot com]

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

Bug ID: 81817
   Summary: ICE in lto1 with -fopenmp offloading and nested
#pragma omp target
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, lto, openmp
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.venevtsev at intel dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Nested #pragma omp target regions cause gcc crash with ICE at lto phase.

Yes, this program is ill-formed according OpenMP specification, but ICE is not
a good behavior;)

Simple reproducer:

bash-4.3$ cat target-in-target.c
int main(void)
{
#pragma omp target
{
  int x = 1;
  #pragma omp target
  {
int y = x;
  }
}
return 0;
}


To reproduce using Intel Xeon Phi emulation:

1. Build offload and host compilers as described in
https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC

2. Execute
bash-4.3$ ./gcc -fopenmp target-in-target.c
target-in-target.c: In function ‘main’:
target-in-target.c:6:15: warning: ‘target’ construct inside of ‘target’ region
   #pragma omp target
   ^~~
lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c:1425
0x965fd0 input_varpool_node
../../trunk/gcc/lto-cgraph.c:1423
0x965fd0 input_cgraph_1
../../trunk/gcc/lto-cgraph.c:1547
0x965fd0 input_symtab()
../../trunk/gcc/lto-cgraph.c:1856
0x6151b3 read_cgraph_and_symbols
../../trunk/gcc/lto/lto.c:2857
0x6151b3 lto_main()
../../trunk/gcc/lto/lto.c:3310
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mkoffload-intelmic: fatal error:
./x86_64-pc-linux-gnu-accel-x86_64-intelmicemul-linux-gnu-gcc returned 1 exit
status
compilation terminated.
lto-wrapper: fatal error:
/tmp/LTO-ICE/install/libexec/gcc/x86_64-pc-linux-gnu/8.0.0//accel/x86_64-intelmicemul-linux-gnu/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

3. gcc version:
bash-4.3$ ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/tmp/LTO-ICE/install/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=x86_64-intelmicemul-linux-gnu
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/tmp/LTO-ICE/install
--disable-bootstrap --disable-multilib --disable-libsanitizer
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu
--enable-offload-targets=x86_64-intelmicemul-linux-gnu=/tmp/LTO-ICE/install
--enable-languages=c,c++,fortran,lto
Thread model: posix
gcc version 8.0.0 20170809 (experimental) (GCC)
bash-4.3$

[Bug lto/81816] New: ICE in lto1 with -fopenmp offloading and nested #pragma omp target

[igor.venevtsev at intel dot com]

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

Bug ID: 81816
   Summary: ICE in lto1 with -fopenmp offloading and nested
#pragma omp target
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, lto, openmp
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.venevtsev at intel dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Nested #pragma omp target regions cause gcc crash with ICE at lto phase.

Yes, this program is ill-formed according OpenMP specification, but ICE is not
a good behavior;)

Simple reproducer:

bash-4.3$ cat target-in-target.c
int main(void)
{
#pragma omp target
{
  int x = 1;
  #pragma omp target
  {
int y = x;
  }
}
return 0;
}


To reproduce using Intel Xeon Phi emulation:

1. Build offload and host compilers as described in
https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC

2. Execute
bash-4.3$ ./gcc -fopenmp target-in-target.c
target-in-target.c: In function ‘main’:
target-in-target.c:6:15: warning: ‘target’ construct inside of ‘target’ region
   #pragma omp target
   ^~~
lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c:1425
0x965fd0 input_varpool_node
../../trunk/gcc/lto-cgraph.c:1423
0x965fd0 input_cgraph_1
../../trunk/gcc/lto-cgraph.c:1547
0x965fd0 input_symtab()
../../trunk/gcc/lto-cgraph.c:1856
0x6151b3 read_cgraph_and_symbols
../../trunk/gcc/lto/lto.c:2857
0x6151b3 lto_main()
../../trunk/gcc/lto/lto.c:3310
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mkoffload-intelmic: fatal error:
./x86_64-pc-linux-gnu-accel-x86_64-intelmicemul-linux-gnu-gcc returned 1 exit
status
compilation terminated.
lto-wrapper: fatal error:
/tmp/LTO-ICE/install/libexec/gcc/x86_64-pc-linux-gnu/8.0.0//accel/x86_64-intelmicemul-linux-gnu/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

3. gcc version:
bash-4.3$ ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/tmp/LTO-ICE/install/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=x86_64-intelmicemul-linux-gnu
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/tmp/LTO-ICE/install
--disable-bootstrap --disable-multilib --disable-libsanitizer
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu
--enable-offload-targets=x86_64-intelmicemul-linux-gnu=/tmp/LTO-ICE/install
--enable-languages=c,c++,fortran,lto
Thread model: posix
gcc version 8.0.0 20170809 (experimental) (GCC)
bash-4.3$

[Bug tree-optimization/79987] [CHKP] ICE in gimplify_expr, at gimplify.c:12151

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||5.4.0, 6.3.0, 7.1.0
  Known to fail||8.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug tree-optimization/81815] Invalid conditional reduction

[rsandifo at gcc dot gnu.org]

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Created attachment 41971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41971=edit
Proposed patch

Here's the patch I'm testing.

[Bug tree-optimization/79987] [CHKP] ICE in gimplify_expr, at gimplify.c:12151

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Fri Aug 11 10:01:13 2017
New Revision: 251049

URL: https://gcc.gnu.org/viewcvs?rev=251049=gcc=rev
Log:
Do not instrument void variables with MPX (PR tree-opt/79987).

2017-08-11  Martin Liska  

PR tree-opt/79987
* tree-chkp.c (chkp_get_bounds_for_decl_addr): Do not instrument
variables of void type.
2017-08-11  Martin Liska  

PR tree-opt/79987
* gcc.target/i386/mpx/pr79987.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/mpx/pr79987.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
(In reply to Tom de Vries from comment #7)
> (In reply to Tom de Vries from comment #6)
> > Created attachment 41970 [details]
> > tentative patch for test-case from comment 3
> 
> Works for test-case from comment 2 as well.

But not for test-case from comment 0.

[Bug tree-optimization/81815] New: Invalid conditional reduction

[rsandifo at gcc dot gnu.org]

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

Bug ID: 81815
   Summary: Invalid conditional reduction
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

This code is incorrectly treated as a conditional reduction, so fails on
aarch64-linux-gnu at -O3.

int __attribute__ ((noinline, noclone))
f (int *x, int n)
{
  int b = 13;
  for (int i = 0; i < n; ++i)
{
  int next = x[i];
  b = b < 100 ? next : 200;
}
  return b;
}

static int res[32];

int
main (void)
{
  for (int i = 0; i < 32; ++i)
res[i] = i;
  res[15] = 100;
  if (f (res, 32) != 200)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/81814] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Probably started with r125012.

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> Created attachment 41970 [details]
> tentative patch for test-case from comment 3

Works for test-case from comment 2 as well.

[Bug tree-optimization/81814] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
 That really looks like a bug.  Even gcc34 prints 0!

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Created attachment 41970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41970=edit
tentative patch for test-case from comment 3

[Bug target/81801] [PATCH] Difference of two pointers generates signed overflow

[oss at malat dot biz]

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

--- Comment #3 from Petr Malat  ---
After reading the related part of the standard (actually, N1570 draft), I'm not
so sure about this. The semantics section in 6.5.6 says pointers have to be
from the same object and also the result must fit into the ptrdiff_t, which
range is [PTRDIFF_MIN, PTRDIFF_MAX], which has to be equal or larger than
[-65535, 65535].

So, theoretically it would be fine to use a shorter type for that, however
there is still a problem if the calculation is done as it is now for larger
objects as the difference is computed first at bytes and divided later by the
object size, so the overflow can still happen even the result fits in
[PTRDIFF_MIN, PTRDIFF_MAX].

One could solve it by dividing both pointers by the size before the
subtraction, but that would make the operation more expensive.

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> (gdb) call debug_generic_expr (cond)
> (signed long) i < 0


And the conversion from unsigned to signed comparison is done here in
c_parser_omp_for_loop:
...
(gdb) call debug_generic_expr (cond)
<<< Unknown tree: c_maybe_const_expr

  i >>> > 9223372036854775807
(gdb) n
15030 cond = c_fully_fold (cond, false, NULL);
(gdb) n
15031 switch (cond_expr.original_code)
(gdb) call debug_generic_expr (cond)
(signed long) i < 0
...

[Bug ipa/81261] [8 Regression] ICE with -fno-guess-branch-probability

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Liška  ---
It's fixed.

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Alexander Monakov from comment #3)
> The comparison should have read '(long long)i < 0', no idea how the cast is
> lost.

It seems to be lost here, in c-omp.c:
...
   553/* 2.5.1.  The comparison in the condition is computed in
   554   the type of DECL, otherwise the behavior is undefined.
   555
   556   For example:
   557   long n; int i;
   558   i < n;
   559
   560   according to ISO will be evaluated as:
   561   (long)i < n;
   562
   563   We want to force:
   564   i < (int)n;  */
   565if (TREE_CODE (op0) == NOP_EXPR
   566&& decl == TREE_OPERAND (op0, 0))
   567  {
   568TREE_OPERAND (cond, 0) = TREE_OPERAND (op0, 0);
   569TREE_OPERAND (cond, 1)
   570  = fold_build1_loc (elocus, NOP_EXPR, TREE_TYPE
(decl),
   571 TREE_OPERAND (cond, 1));
   572  }
...

...
568   TREE_OPERAND (cond, 0) = TREE_OPERAND (op0, 0);
(gdb) call debug_generic_expr (cond)
(signed long) i < 0
(gdb) n
569   TREE_OPERAND (cond, 1)
(gdb) call debug_generic_expr (cond)
i < 0
...

[Bug ipa/81213] GCC target_clone support does not work for static functions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Liška  ---
Fixed on trunk, I'm not planning to backport that.

[Bug tree-optimization/81799] [8 Regression] ICE on valid code at -O3: verify_gimple failed

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org

--- Comment #2 from amker at gcc dot gnu.org ---
Thanks for reporting, I will investigate.

[Bug ipa/81213] GCC target_clone support does not work for static functions

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Fri Aug 11 08:10:42 2017
New Revision: 251047

URL: https://gcc.gnu.org/viewcvs?rev=251047=gcc=rev
Log:
Fix ifunc and resolver (PR ipa/81213).

2017-08-11  Martin Liska  

PR ipa/81213
* config/i386/i386.c (make_resolver_func): Do complete
refactoring of the function.
2017-08-11  Martin Liska  

PR ipa/81213
* gcc.target/i386/pr81213.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81213.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81801] [PATCH] Difference of two pointers generates signed overflow

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Related to PR 80998.