[Bug c/79940] [6/7 Regression] OpenMP pragma - internal compiler error with taskloop

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I'll fix this, that said the testcase certainly is not OpenMP compliant, you
have a data race in there, you need to do the taskloop just once, or make sure
that in each thread it will write to different arrays or portions of an array.
So easiest is just add #pragma omp single.  But then, there is not really any
benefit in using taskloop in that case, a normal #pragma omp parallel for would
be faster.

[Bug fortran/79484] Segfault when executing a test in Power8

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to smateo from comment #4)

> 
> Of course using the ISO_C_BINDINGS interoperability module and BIND(C) would
> be a more appropriate way of doing it, but they were introduced in F2003. I
> guess that a code like the one I attached should work in the
> pre-interoperability era (we may need to remove the VALUE attributes since
> this attribute was introduced also in F2003).

Using ISO C binding is the only appropriate way to interface
Fortran and C  All other methods require the user to understand
what they are doing on any particular architecture.  It should
be noted that 2017-2003 is 14 years.  It's not as-if Fortran 
2003 was released 6 month ago.

> I decided to open this ticket because, as you said, this code works nicely
> in x86_64 (I also tried in some ARM machines and also worked), and because
> changing the optimization level flags made it work.

Your code worked because it aligns with a specific target model.
Does power8 have the exact architecture as x86-64?

[Bug testsuite/79867] [cygwin] LD_LIBRARY_PATH ignored, contaminating (nearly?) all test results

[daniel.santos at pobox dot com]

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

--- Comment #1 from Daniel Santos  ---
Minor correction: LD_LIBRARY_PATH is used to resolve lib names when dlopen() is
called, but not for load-time linking.

There are also a few other complications on Cygwin.  DLLs (including libgcc)
are stored in /usr/bin and not /usr/lib.  Windows searches the PATH to find
dlls, and you can't remove /usr/bin from the PATH and have anything work.  So
any type of real solution will likely require Cygwin to change the install
location of gcc's libs, otherwise there is no assurance that we've loaded the
correct library (should something be amiss in the build tree).

Finally, there is no ldconfig on Cygwin at this time.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #31 from Jakub Jelinek  ---
Thus reopening.

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Has there been any resolution for the GB20 vs. LWG2446 conflict in Kona?

[Bug tree-optimization/79955] New: GLIBC build fails after r245840

[doug.gilmore at imgtec dot com]

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

Bug ID: 79955
   Summary: GLIBC build fails after r245840
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doug.gilmore at imgtec dot com
  Target Milestone: ---

Created attachment 40920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40920=edit
CPP output file for mips-mti-linux-gnu target

See:

https://sourceware.org/ml/libc-alpha/2017-03/msg00052.html

We are working around the issue by disabling -Werror in the build.

I'll upload an X86_64 .i file tomorrow.


$ mips-mti-linux-gnu-gcc -mabi=32 fnmatch.i -c -std=gnu11 -fgnu89-inline  -O2
-Wall -Wundef -Wwrite-strings -fmerge-all-constants -fno-stack-protector
-frounding-math \
-g -Wstrict-prototypes -Wold-style-definition -ftls-model=initial-exec
In file included from fnmatch.c:250:0:
fnmatch_loop.c: In function 'internal_fnwmatch':
../locale/weightwc.h:103:28: warning: '*((void *)+4)' may be used
uninitialized in this function [-Wmaybe-uninitialized]

[Bug fortran/79484] Segfault when executing a test in Power8

[sergi.mateo at bsc dot es]

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

--- Comment #4 from smateo  ---
Hi Jerry,

This code is a simplification of a code that our tool generates to support a
tasking programming model. I know that I don't need a derived type to call a C
function. If I recall correctly, I needed to reproduce this problem.

Of course using the ISO_C_BINDINGS interoperability module and BIND(C) would be
a more appropriate way of doing it, but they were introduced in F2003. I guess
that a code like the one I attached should work in the pre-interoperability era
(we may need to remove the VALUE attributes since this attribute was introduced
also in F2003).

I decided to open this ticket because, as you said, this code works nicely in
x86_64 (I also tried in some ARM machines and also worked), and because
changing the optimization level flags made it work.

I also tried to compile this code with XLF and works nicely.

Best regards,
Sergi

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Well, 4.9 did not fix this, on the reduced:

struct A { float x; float y; };
A a, b, c;
int d, e;
A bar ();
void foo (A, A);
inline A operator/ (A, A p2) { if (p2.x) return a; }
struct B { A dval; };
int baz (A, B, A, int);

void
test ()
{
  B q;
  A f, g, h, k;
  h.x = 1.0;
  f = h;
  struct A i, j = f;
  do {
i = bar ();
g = i / j;
foo (g, c);
int l = baz (k, q, b, e);
if (l)
  goto cleanup;
j = i;
  } while (d);
cleanup:;
}

with -O2 -fPIC -fno-schedule-insns -mno-lra I can still reproduce it even with
r219720; GCC 5 is fine, because -mno-lra has been removed in r219734.
GCC 4.9 is not upstream supported either, this note is mainly for those still
maintaining 4.8 or 4.9 aarch64 branches.

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[pavel at zhukoff dot net]

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

Pavel Zhukov  changed:

   What|Removed |Added

 CC||pavel at zhukoff dot net

--- Comment #5 from Pavel Zhukov  ---
(In reply to Eric Botcazou from comment #1)

> Presumably:
> 
> Index: system-linux-ppc.ads
> ===
> --- system-linux-ppc.ads(revision 245767)
> +++ system-linux-ppc.ads(working copy)
> @@ -89,7 +89,8 @@ package System is
> --  Other System-Dependent Declarations
>  
> type Bit_Order is (High_Order_First, Low_Order_First);
> -   Default_Bit_Order : constant Bit_Order := High_Order_First;
> +   Default_Bit_Order : constant Bit_Order :=
> + Bit_Order'Val (Standard'Default_Bit_Order);
> pragma Warnings (Off, Default_Bit_Order); -- kill constant condition
> warning
>  
> --  Priority-related Declarations (RM D.1)

I'm wondering if it will work and not break ppc and ppc64.
ppc64le is exceptional in ppc family. ppc and ppc64 have high_bit_first 

$ gcc -dumpmachine
ppc64-redhat-linux

$ ./bits 
Default byte order is: HIGH_ORDER_FIRST
Order of record is HIGH_ORDER_FIRST

$ gcc -dumpmachine
ppc64le-redhat-linux
$ ./bits
Default byte order is: HIGH_ORDER_FIRST <== SHOULD BE LOW!
Order of record is LOW_ORDER_FIRST

[Bug target/79928] nds32: misspelled diagnostic: not support -fpic

[jasonwucj at gcc dot gnu.org]

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

Chung-Ju Wu  changed:

   What|Removed |Added

 CC||jasonwucj at gcc dot gnu.org

--- Comment #3 from Chung-Ju Wu  ---
(In reply to Martin Sebor from comment #1)
> I'm pretty sure it's no joke, just a mistake.  Let me suggest the following
> wording/patch:
> 
> diff --git a/gcc/config/nds32/nds32.c b/gcc/config/nds32/nds32.c
> index 9313712..705d223 100644
> --- a/gcc/config/nds32/nds32.c
> +++ b/gcc/config/nds32/nds32.c
> @@ -2704,7 +2704,7 @@ nds32_option_override (void)
>  
>/* Currently, we don't support PIC code generation yet.  */
>if (flag_pic)
> -sorry ("not support -fpic");
> +sorry ("position-independent code not supported");
>  }

Hi, Martin & Roland,

Yes, it was indeed a mistake.
Thank both of you to point out this grammar issue.

The patch that Martin provided is OK on mailing list.
Thank you so much. :)


Best regards,
jasonwucj

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Last reconfirmed|2016-12-28 00:00:00 |2017-3-8
   Target Milestone|--- |7.0

[Bug target/79928] nds32: misspelled diagnostic: not support -fpic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Severity|normal  |trivial

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00341.html

[Bug c/79936] [7 Regression] ICE with -Walloc-size-larger-than=32767

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|diagnostic  |patch

--- Comment #7 from Martin Sebor  ---
Patch submitted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00342.html

[Bug preprocessor/79948] _Pragma(“GCC error”) is processed differently inside and outside of a #if directive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.1.3, 4.2.2, 4.3.2, 4.6.0,
   ||5.4.0, 6.3.0, 7.0

--- Comment #2 from Martin Sebor  ---
I'll confirm this as a bug with the test case below which is expected to
compile without an error (and does with other compilers I tested, including
Clang 5.0, EDG eccp 4.13, IBM XLC 13.1.3, Oracle cc 5.13, and Microsoft Visual
C/C++).

It seems to me that in 'return Y (E)' GCC first expands the E macro into the
_Pragma, then executes the _Pragma, and then expands the Y() macro.

I think it should expand all the macros first, i.e., first E, then Y, then X,
and then execute any _Pragmas.

$ cat t.c && gcc -S t.c
#define E  _Pragma ("GCC error \"This is an error\"")

#define X(a) my##a
#define Y(a) X(a)

int my_Pragma (const char*);

int f (void)
{
  return Y (E);
};
t.c: In function ‘f’:
t.c:10:11: error: This is an error
   return Y (E);
   ^ 
t.c:3:14: error: ‘my’ undeclared (first use in this function)
 #define X(a) my##a
  ^
t.c:4:14: note: in expansion of macro ‘X’
 #define Y(a) X(a)
  ^
t.c:10:10: note: in expansion of macro ‘Y’
   return Y (E);
  ^
t.c:3:14: note: each undeclared identifier is reported only once for each
function it appears in
 #define X(a) my##a
  ^
t.c:4:14: note: in expansion of macro ‘X’
 #define Y(a) X(a)
  ^
t.c:10:10: note: in expansion of macro ‘Y’
   return Y (E);
  ^

[Bug preprocessor/79948] _Pragma(“GCC error”) is processed differently inside and outside of a #if directive

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I have not read the standard in this area but I know somethings are interesting
in this area that most folks won't expect.  Inside #if undefined macros are
considered as 0.

[Bug target/79928] nds32: misspelled diagnostic: not support -fpic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I'm pretty sure it's no joke, just a mistake.  Let me suggest the following
wording/patch:

diff --git a/gcc/config/nds32/nds32.c b/gcc/config/nds32/nds32.c
index 9313712..705d223 100644
--- a/gcc/config/nds32/nds32.c
+++ b/gcc/config/nds32/nds32.c
@@ -2704,7 +2704,7 @@ nds32_option_override (void)

   /* Currently, we don't support PIC code generation yet.  */
   if (flag_pic)
-sorry ("not support -fpic");
+sorry ("position-independent code not supported");
 }

[Bug c++/71543] [concepts] ICE on ill-formed declaration of a parameter with a constrained-type-specifier in a requires expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  The ICE seems to have been there since the introduction of
-fconcepts.

[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Removing --enable-checking=all from the set of configure options or replacing
it with --enable-checking=release allows the build to complete.

[Bug c++/79954] New: [C++17] Explicit deduction guide not rejected when defined outside inline namespace enclosing the type

[redi at gcc dot gnu.org]

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

Bug ID: 79954
   Summary: [C++17] Explicit deduction guide not rejected when
defined outside inline namespace enclosing the type
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

inline namespace x
{
  template
struct X
{
  template
X(U&&) { };
};
}

template X(T) -> X;

I believe this is invalid and should be rejected.

If I'm wrong, then the deduction guide should be used by:

X obj(1);

but it fails to deduce the template argument.

[Bug c++/79501] member deduction guide not recognized

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 Ever confirmed|0   |1

[Bug target/79942] Wrong declaration of __builtin_cpu_init

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed, although I think it's actually a documentation bug.  The built-in
calls the __cpu_indicator_init() function and returns what that function
returns.  __cpu_indicator_init() is declared to return int and defined in
libgcc/config/i386/cpuinfo.c where it's documented as follows:

/* A constructor function that is sets __cpu_model and __cpu_features with
   the right values.  This needs to run only once.  This constructor is
   given the highest priority and it should run before constructors without
   the priority set.  However, it still runs after ifunc initializers and
   needs to be called explicitly there.  */

int __attribute__ ((constructor CONSTRUCTOR_PRIORITY))
__cpu_indicator_init (void)
...

The function returns 0 on success and -1 on failure (e.g., when the cpuid
instruction is not supported).

[Bug debug/79953] New: ICE in expand_debug_locations when attribute target is used

[dmarion at me dot com]

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

Bug ID: 79953
   Summary: ICE in expand_debug_locations when attribute target is
used
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmarion at me dot com
  Target Milestone: ---

$ gcc -march=nehalem -O3 -o a.o a.c -c -g2 -Wall -Wextra

a.c: In function ‘foo_avx2’:
a.c:15:38: internal compiler error: in expand_debug_locations, at
cfgexpand.c:5304
 void __attribute__((target("avx2"))) foo_avx2(void *dst, void *src) {

$ cat a.c
typedef unsigned char u8;
typedef u8 u8x32 __attribute__((vector_size(32)));

static inline void __attribute__((always_inline))
foo(void *dst, void *src) {
  u8x32 x;
  u8x32 *ps = (u8x32 *)src;
  u8x32 *pd = (u8x32 *)dst;
  //*pd = *ps;
  x = *ps;
  *pd = x;
}

void __attribute__((target("avx2"))) foo_avx2(void *dst, void *src) {
  foo(dst, src);
}

Comments:
1. Observed in different gcc version including 7.0 snapshot
2. It doesn't happen with -g1
3. It doesn't happen when vector variable is not used, uncomment "*pd = *ps;"
in the code above, comment out "u8x32 x;" and further references to x.

[Bug bootstrap/79952] New: [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting for hppa2.0w-hp-hpux11.11

[msebor at gcc dot gnu.org]

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

Bug ID: 79952
   Summary: [7 Regression] ICE in test_loading_cfg in
read-rtl-function.c:2016 targeting for
hppa2.0w-hp-hpux11.11
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A build of the top of GCC 7.0 trunk for the hppa2.0w-hp-hpux11.11 target fails
on x86_64-*-linux in the following self test.

The following options were used to configure GCC:

--enable-languages=c,c++ --enable-checking=all --enable-valgrind-annotations
--prefix=/build/sysroot/hppa2.0w-hp-hpux11.11 --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=hppa2.0w-hp-hpux11.11 --without-headers

/build/hppa2.0w-hp-hpux11.11/gcc-trunk/./gcc/xgcc
-B/build/hppa2.0w-hp-hpux11.11/gcc-trunk/./gcc/ -nostdinc -x c /dev/null -S -o
/dev/null -fself-test=/src/gcc/trunk/gcc/testsuite/selftests
In function ‘cfg_test’:
cc1: internal compiler error: Segmentation fault
0x101199e crash_signal
/src/gcc/trunk/gcc/toplev.c:337
0x8b4013 lookup_page_table_entry
/src/gcc/trunk/gcc/ggc-page.c:635
0x8b5564 ggc_set_mark(void const*)
/src/gcc/trunk/gcc/ggc-page.c:1532
0x7881b5 gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:49
0x78a008 gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:401
0x789e70 gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:382
0x7882b7 gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:68
0xb6a1ff ggc_mark_root_tab
/src/gcc/trunk/gcc/ggc-common.c:77
0xb6a290 ggc_mark_roots()
/src/gcc/trunk/gcc/ggc-common.c:94
0x8b6aa7 ggc_collect()
/src/gcc/trunk/gcc/ggc-page.c:2202
0x97d419 cgraph_node::finalize_function(tree_node*, bool)
/src/gcc/trunk/gcc/cgraphunit.c:480
0xe73fce function_reader::create_function()
/src/gcc/trunk/gcc/read-rtl-function.c:520
0xe73bf5 function_reader::parse_function()
/src/gcc/trunk/gcc/read-rtl-function.c:425
0xe73ba3 function_reader::handle_unknown_directive(file_location, char const*)
/src/gcc/trunk/gcc/read-rtl-function.c:411
0x18bf972 md_reader::handle_file()
/src/gcc/trunk/gcc/read-md.c:1158
0x18bfa2c md_reader::handle_toplevel_file()
/src/gcc/trunk/gcc/read-md.c:1180
0x18bfb27 md_reader::read_file(char const*)
/src/gcc/trunk/gcc/read-md.c:1325
0xe76c3c read_rtl_function_body(char const*)
/src/gcc/trunk/gcc/read-rtl-function.c:1597
0xfa30e2 selftest::rtl_dump_test::rtl_dump_test(selftest::location const&,
char*)
/src/gcc/trunk/gcc/selftest-rtl.c:69
0xe7bbfa test_loading_cfg
/src/gcc/trunk/gcc/read-rtl-function.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:1939: recipe for target 's-selftest' failed
make[1]: *** [s-selftest] Error 1
make[1]: *** Waiting for unfinished jobs
rm gcov-tool.pod gpl.pod gfdl.pod fsf-funding.pod gcov.pod cpp.pod gcc.pod
make[1]: Leaving directory '/build/hppa2.0w-hp-hpux11.11/gcc-trunk/gcc'
Makefile:4236: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2
make: Leaving directory '/build/hppa2.0w-hp-hpux11.11/gcc-trunk'

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
That's strange, cc1plus command line has nothing special as I can see:

$ 
/home/marxin/BIG/buildbot/slave/install/gcc-dda535fd9490e3e8f31bacc6678e0c734ff59212/bin/../lib/gcc/ppc64le-linux-gnu/7.0.1/cc1plus
-quiet -v -iprefix
/home/marxin/BIG/buildbot/slave/install/gcc-dda535fd9490e3e8f31bacc6678e0c734ff59212/bin/../lib64/gcc/ppc64le-linux-gnu/7.0.1/
-D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux
-D__linux -Asystem=linux -Asystem=unix -Asystem=posix
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return-6_x.C
-quiet -dumpbase return-6_x.C -mno-popcntd -auxbase return-6_x -Og -version -o
/tmp/ccsVo0KI.s

[Bug target/79951] New: ICE in extract_insn, at recog.c:2311 on ppc64le with -mno-cmpb

[marxin at gcc dot gnu.org]

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

Bug ID: 79951
   Summary: ICE in extract_insn, at recog.c:2311 on ppc64le with
-mno-cmpb
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Following test-case ICE with cross compiler (on x86_64-linux-gnu):

$ ppc64le-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/backprop-5.c
-mno-cmpb

/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/backprop-5.c: In
function ‘testf’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/backprop-5.c:16:1:
error: unrecognizable insn:
 TEST_FUNCTION (float, f)
 ^
(insn 13 12 14 2 (set (reg:SF 164)
(unspec:SF [
(reg:SF 165)
(reg:SF 166)
] UNSPEC_COPYSIGN))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/backprop-5.c":16 -1
 (nil))
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/backprop-5.c:16:1:
internal compiler error: in extract_insn, at recog.c:2311
0xb08718 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.././../gcc/rtl-error.c:108
0xb08749 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.././../gcc/rtl-error.c:116
0xada041 extract_insn(rtx_insn*)
.././../gcc/recog.c:2311
0x89dad3 instantiate_virtual_regs_in_insn
.././../gcc/function.c:1589
0x89dad3 instantiate_virtual_regs
.././../gcc/function.c:1957
0x89dad3 execute
.././../gcc/function.c:2006

[Bug c/79936] [7 Regression] ICE with -Walloc-size-larger-than=32767

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|ICE with|[7 Regression] ICE with
   |-Walloc-size-larger-than=32 |-Walloc-size-larger-than=32
   |767 |767

--- Comment #6 from Martin Sebor  ---
The problem turned out to be caused by calls.c (the file that implements the
warning) missing from the GTFILES variable (which lets the garbage collector
know about files that define objects that should not be garbage-collected). 
https://gcc.gnu.org/onlinedocs/gccint/Files.html

Testing a patch.

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
I also have trouble reproducing this. Rather than the g++ commandline, please
post what is passed to cc1plus.

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Same happens here:

$ s390x-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-p-19.c
-O2
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-p-19.c:
In function ‘t112_2mul’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-p-19.c:63:1:
internal compiler error: Max. number of generated reload insns per insn is
achieved (90)

 TESTS
 ^
0x9f06b3 lra_constraints(bool)
.././../gcc/lra-constraints.c:4695
0x9da1fc lra(_IO_FILE*)
.././../gcc/lra.c:2392
0x990d3f do_reload
.././../gcc/ira.c:5451
0x990d3f execute
.././../gcc/ira.c:5635

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Btw. GCC 5 and GCC 6 work fine.

[Bug c++/79950] New: G++ cannot detect simple off by one error in STL classes

[dcb314 at hotmail dot com]

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

Bug ID: 79950
   Summary: G++ cannot detect simple off by one error in STL
classes
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Given the following C++ source code

# include 

using namespace std;

extern void g( int);

void f1( const vector < int > & v)
{
for (size_t i = 0; i <= v.size(); ++i)
{
g( v[i]);
}
}

int a[ 10];

void f2()
{
for (int i = 0; i <= 10; ++i)
{
g( a[i]);
}
}

then current trunk gcc can detect a problem in f2, but not f1.

$ ~/gcc/results/bin/g++ -g -O2 -D_FORTIFY_SOURCE=2 -Wall -Wextra -c mar7a.cc
mar7a.cc: In function ‘void f2()’:
mar7a.cc:22:4: warning: iteration 10 invokes undefined behavior
[-Waggressive-loop-optimizations]
   g( a[i]);
   ~^~~
mar7a.cc:20:20: note: within this loop
  for (int i = 0; i <= 10; ++i)
  ~~^
$

[Bug rtl-optimization/79949] New: ICE in Max. number of generated reload insns per insn is achieved (90)

[marxin at gcc dot gnu.org]

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

Bug ID: 79949
   Summary: ICE in Max. number of generated reload insns per insn
is achieved (90)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: bernds at gcc dot gnu.org, vmakarov at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: s390x-linux-gnu

Very similar bug on s390x:

$ s390x-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/pr56790-1.C

/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/pr56790-1.C: In function
‘vec f()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/pr56790-1.C:13:1:
internal compiler error: Max. number of generated reload insns per insn is
achieved (90)

 }
 ^
0xbe62b3 lra_constraints(bool)
.././../gcc/lra-constraints.c:4695
0xbcfdfc lra(_IO_FILE*)
.././../gcc/lra.c:2392
0xb8693f do_reload
.././../gcc/ira.c:5451
0xb8693f execute
.././../gcc/ira.c:5635

Looks both GCC 5 and 6 work fine.

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
There's how I created the cross-compiler:

$ configure --target=ppc64le-linux-gnu
--with-as=/usr/bin/powerpc64le-suse-linux-as --disable-bootstrap

$ ppc64le-linux-gnu-g++ -v
...
gcc version 7.0.1 20170307 (experimental) (GCC)

[Bug c++/64236] [c++11] last alignas overrides stricter on a class definition

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
Still reproducible on gcc-7 (r243972).

[Bug fortran/79484] Segfault when executing a test in Power8

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Using LOC is not the right way to do these things. You should use bind(c) on
the fortran side.

I think you can google help with this.

Power8 systems are less forgiving then others. I dont get any errors on my
system here which is x86_64 linux.

Also ask on comp.lang.fortran and explain what you are actually trying to do.
You do not need your derived type at all to pass arguments to a C function.

[Bug c/79936] ICE with -Walloc-size-larger-than=32767

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
After spending some more time debugging this I don't think it's a bug in the
warning after all.  The ICE comes and goes with different arguments to
-Walloc-size-larger-than.  It's as if the block the pointer points to was
getting deallocated accidentally.

[Bug preprocessor/79948] New: _Pragma(“GCC error”) is processed differently inside and outside of a #if directive

[duparq at free dot fr]

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

Bug ID: 79948
   Summary: _Pragma(“GCC error”) is processed differently inside
and outside of a #if directive
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: duparq at free dot fr
  Target Milestone: ---

Created attachment 40919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40919=edit
Source file that produces the unexpected behavior

I process this with gcc -E -std=c1x -Wall -Wextra -Wpedantic main.c >output.

I get this on the command line (almost normal):

'''
main.c:16:11: error: This is an error
 "ISVOID(E):" ISVOID(E)
   ^
'''

I get that in the output:

'''
# 1 "main.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "main.c"
# 14 "main.c"
"ISVOID(something):" 0
"ISVOID():" 1
"ISVOID(E):"
# 16 "main.c"

# 16 "main.c"
 1





"ISVOID(something)==1: false"



"ISVOID()==1: true"







"ISVOID(E)==1: false"
'''

Then, ISVOID(E) expands to 1 outside the #if directive and it expands to 0
inside, meaning that _Pragma("GCC error") is processed differently inside and
outside a #if directive.

Moreover, there is no emission of a "This is an error" related to the #if
ISVOID(E) == 1.

Is that behavior normal?

[Bug target/79946] Suboptimal code with AVX2 copying all arguments to stack

[adam at aphirst dot karoo.co.uk]

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

--- Comment #2 from Adam Hirst  ---
Just for clarification: is this only occuring for the case where one does 

Dx = D%x
tmp = matmul(NU,Dx);
tensorproduct%x = dot_product(tmp,NV)

or is it also applicable to

tmp = matmul(NU,D%x);
tensorproduct%x = dot_product(tmp,NV)

? The distinction between the two came up in the discussion for PR79930, and at
least on my machine, the code for the former performed much worse than the
latter at -O2, only getting any performance back once using -Ofast and -flto.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #30 from Jonathan Wakely  ---
The code in comment 20 still fails even with attribute((may_alias)), so I'm not
sure how the boost code can be fixed:

inline void* operator new(__SIZE_TYPE__, void *p) { return p; }
struct A { A (float x) : f (x) {} float f; };
static_assert(sizeof(A) == sizeof(float), "");
struct B
{
  int x;
  union __attribute__((__may_alias__)) U
  {
int a;
char b[sizeof (float)];
  } u;
  int y;
};

__attribute__((noinline, noclone)) void
bar (B , B )
{
  if (x.x != 0)
__builtin_abort ();
  if (x.y != 3)
__builtin_abort ();
  if (y.x != 0)
__builtin_abort ();
  if (y.y != 3)
__builtin_abort ();
  float f;
  __builtin_memcpy (, x.u.b, sizeof (float));
  if (f != 3.5f)
__builtin_abort ();
  __builtin_memcpy (, y.u.b, sizeof (float));
  if (f != 3.5f)
__builtin_abort ();
}

__attribute__((noinline, noclone)) 
B *
baz (B )
{
  return 
}

__attribute__((noinline, noclone)) void
foo (float x)
{
  B b { 0, {}, 3 }, c;
  B *p = baz (b);
  new (b.u.b) A (x);
  c = *p;
  bar (*p, c);
}

int
main ()
{
  foo (3.5f);
}

[Bug c/79936] ICE with -Walloc-size-larger-than=32767

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
I can reproduce an ICE with a cross-compiler configured with
--enable-checking=all,valgrind.  I don't know yet if it's the same problem but
it does suggest a bug in the implementation of the warning.  The same ICE can
be reproduced with the following small test case.  For some reason, in the
second call to maybe_warn_alloc_args_overflow, the object pointed to by the
alloc_object_size_limit pointer has been trashed.  By the looks of it, the
block of memory it points to has been garbage-collected.  The pointer is
declared as 'static GTY(()) tree alloc_object_size_limit;' which, AFAIK, means
that it should be left alone by the garbage collector.

$ cat t.c && /build/x86_64-apple-darwin10.8.0/gcc-trunk/gcc/xgcc -B
/build/x86_64-apple-darwin10.8.0/gcc-trunk/gcc -S
-Walloc-size-larger-than=32767 t.c

void* f (void)
{
  return __builtin_malloc (1234);
}

void* g (void)
{
  return __builtin_malloc (1234);
}
==32458== Invalid read of size 2
==32458==at 0x81E145: contains_struct_check (tree.h:3433)
==32458==by 0x81E145: extended_tree (tree.h:5286)
==32458==by 0x81E145: generic_wide_int (wide-int.h:745)
==32458==by 0x81E145: to_widest (tree.h:5263)
==32458==by 0x81E145: tree_int_cst_lt (tree.h:5375)
==32458==by 0x81E145: maybe_warn_alloc_args_overflow(tree_node*,
tree_node*, tree_node**, int*) (calls.c:1392)
==32458==by 0x81F112: initialize_argument_information(int, arg_data*,
args_size*, int, tree_node*, tree_node*, tree_node*, tree_node*,
cumulative_args_t, int, rtx_def**, int*, int*, int*, bool*, bool)
(calls.c:1940)
==32458==by 0x82268A: expand_call(tree_node*, rtx_def*, int) (calls.c:3275)
==32458==by 0x80FB71: expand_builtin(tree_node*, rtx_def*, rtx_def*,
machine_mode, int) (builtins.c:7471)
==32458==by 0x954B10: expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) (expr.c:10822)
==32458==by 0x964186: store_expr_with_bounds(tree_node*, rtx_def*, int,
bool, bool, tree_node*) (expr.c:5552)
==32458==by 0x965DA0: expand_assignment(tree_node*, tree_node*, bool)
(expr.c:5321)
==32458==by 0x839B6A: expand_call_stmt (cfgexpand.c:2656)
==32458==by 0x839B6A: expand_gimple_stmt_1 (cfgexpand.c:3571)
==32458==by 0x839B6A: expand_gimple_stmt(gimple*) (cfgexpand.c:3737)
==32458==by 0x83B9FE: expand_gimple_basic_block(basic_block_def*, bool)
(cfgexpand.c:5744)
==32458==by 0x84165E: (anonymous
namespace)::pass_expand::execute(function*) (cfgexpand.c:6357)
==32458==by 0xBD5C5C: execute_one_pass(opt_pass*) (passes.c:2465)
==32458==by 0xBD6527: execute_pass_list_1(opt_pass*) [clone .constprop.84]
(passes.c:2554)
==32458==  Address 0xc7023c0 is in a rw- anonymous segment
==32458== 
==32458== Invalid read of size 1
==32458==at 0x81E14F: contains_struct_check (tree.h:3433)
==32458==by 0x81E14F: extended_tree (tree.h:5286)
==32458==by 0x81E14F: generic_wide_int (wide-int.h:745)
==32458==by 0x81E14F: to_widest (tree.h:5263)
==32458==by 0x81E14F: tree_int_cst_lt (tree.h:5375)
==32458==by 0x81E14F: maybe_warn_alloc_args_overflow(tree_node*,
tree_node*, tree_node**, int*) (calls.c:1392)
==32458==by 0x81F112: initialize_argument_information(int, arg_data*,
args_size*, int, tree_node*, tree_node*, tree_node*, tree_node*,
cumulative_args_t, int, rtx_def**, int*, int*, int*, bool*, bool)
(calls.c:1940)
==32458==by 0x82268A: expand_call(tree_node*, rtx_def*, int) (calls.c:3275)
==32458==by 0x80FB71: expand_builtin(tree_node*, rtx_def*, rtx_def*,
machine_mode, int) (builtins.c:7471)
==32458==by 0x954B10: expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) (expr.c:10822)
==32458==by 0x964186: store_expr_with_bounds(tree_node*, rtx_def*, int,
bool, bool, tree_node*) (expr.c:5552)
==32458==by 0x965DA0: expand_assignment(tree_node*, tree_node*, bool)
(expr.c:5321)
==32458==by 0x839B6A: expand_call_stmt (cfgexpand.c:2656)
==32458==by 0x839B6A: expand_gimple_stmt_1 (cfgexpand.c:3571)
==32458==by 0x839B6A: expand_gimple_stmt(gimple*) (cfgexpand.c:3737)
==32458==by 0x83B9FE: expand_gimple_basic_block(basic_block_def*, bool)
(cfgexpand.c:5744)
==32458==by 0x84165E: (anonymous
namespace)::pass_expand::execute(function*) (cfgexpand.c:6357)
==32458==by 0xBD5C5C: execute_one_pass(opt_pass*) (passes.c:2465)
==32458==by 0xBD6527: execute_pass_list_1(opt_pass*) [clone .constprop.84]
(passes.c:2554)
==32458==  Address 0x2806161 is not stack'd, malloc'd or (recently) free'd
==32458== 
t.c: In function ‘g’:
t.c:8:10: internal compiler 

[Bug fortran/79484] Segfault when executing a test in Power8

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
Looking

[Bug c++/79899] ICE in ctor_omit_inherited_parms at gcc/cp/method.c:576 on ARM target

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Same happens on ppc64-linux-gnu target:

$ ppc64-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/friend5.C -Os

[Bug target/79947] New: [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

[marxin at gcc dot gnu.org]

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

Bug ID: 79947
   Summary: [6/7 Regression] ICE in rs6000_emit_swsqrt at
gcc/config/rs6000/rs6000.c:37570
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64-linux-gnu

Using cross-compiler for ppc64-linux-gnu (on x86_64-linux-gnu) I see:

ppc64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/vsx-mass-1.c
-Ofast -mno-powerpc-gfxopt -mcmpb -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/vsx-mass-1.c: In
function ‘test_float_sqrt’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/vsx-mass-1.c:518:13:
internal compiler error: Segmentation fault
 f1[i] = __builtin_sqrtf (f2[i]);
 ^~~
0xb7b6cf crash_signal
.././../gcc/toplev.c:337
0x845b9d emit_move_insn(rtx_def*, rtx_def*)
.././../gcc/expr.c:3697
0xed6c7c rs6000_emit_swsqrt(rtx_def*, rtx_def*, bool)
.././../gcc/config/rs6000/rs6000.c:37570
0x104722a gen_sqrtsf2(rtx_def*, rtx_def*)
.././../gcc/config/rs6000/rs6000.md:4612
0xa85ac8 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
.././../gcc/optabs.c:7078
0xa85ac8 expand_insn(insn_code, unsigned int, expand_operand*)
.././../gcc/optabs.c:7109
0x95cb84 expand_direct_optab_fn
.././../gcc/internal-fn.c:2550
0x735a6d expand_call_stmt
.././../gcc/cfgexpand.c:2584
0x735a6d expand_gimple_stmt_1
.././../gcc/cfgexpand.c:3571
0x735a6d expand_gimple_stmt
.././../gcc/cfgexpand.c:3737
0x73729e expand_gimple_basic_block
.././../gcc/cfgexpand.c:5744
0x73d0b6 execute
.././../gcc/cfgexpand.c:6357

GCC 5 works fone.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[andrew at sifive dot com]

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

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #14 from Andrew Waterman  ---
(In reply to mpf from comment #13)
> (In reply to Palmer Dabbelt from comment #12)
> > I believe this is a problem in the RISC-V port, so you're welcome to assign
> > the bug to me.  I might not have time to fix this today, this way I won't
> > lose it.
> 
> Thanks Palmer, glad I could find something specific to try and resolve this
> as it could have easily been much harder! Sorry to have exposed a bug so
> late in the release but I suspect there were other ways to hit this already
> so it may just have caught it early.

I suspect you are correct; and if so, it is we who should thank you :)

> 
> Matthew

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[dvyukov at google dot com]

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

--- Comment #4 from Dmitry Vyukov  ---
Attached second minimized reproducer.
Build it with:
gcc dmaengine2.c -fsanitize=address -O2 -lasan -g

It produces:

==57662==ERROR: AddressSanitizer: unknown-crash on address 0x00601321 at pc
0x00400729 bp 0x7ffdd78835b0 sp 0x7ffdd78835a8
WRITE of size 8 at 0x00601321 thread T0
#0 0x400728 in clear_bit /tmp/dmaengine2.c:10
#1 0x400728 in dma_channel_table_init /tmp/dmaengine2.c:130
#2 0x400728 in main /tmp/dmaengine2.c:207

On the following line:

  __atomic_fetch_and((char *)addr + (nr / 8), (char)(~(1 << (nr % 8))), 0);

This is access of size 1, not 8.

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[dvyukov at google dot com]

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

--- Comment #3 from Dmitry Vyukov  ---
Created attachment 40918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40918=edit
reproducer2

[Bug c/79834] c/c-parser.c: make code more i18n-friendly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|mpf at gcc dot gnu.org |palmer at dabbelt dot 
com

--- Comment #13 from mpf at gcc dot gnu.org ---
(In reply to Palmer Dabbelt from comment #12)
> I believe this is a problem in the RISC-V port, so you're welcome to assign
> the bug to me.  I might not have time to fix this today, this way I won't
> lose it.

Thanks Palmer, glad I could find something specific to try and resolve this as
it could have easily been much harder! Sorry to have exposed a bug so late in
the release but I suspect there were other ways to hit this already so it may
just have caught it early.

Matthew

[Bug c++/79896] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:11950 on non-int128 target

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #3 from Marek Polacek  ---
*** Bug 79785 has been marked as a duplicate of this bug. ***

[Bug ipa/79776] [7 Regression] ICE on valid code in insert_vi_for_tree, at tree-ssa-structalias.c:2807

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 Blocks|65530   |
Summary|[7 Regression][CHKP] ICE on |[7 Regression] ICE on valid
   |valid code in   |code in insert_vi_for_tree,
   |insert_vi_for_tree, at  |at
   |tree-ssa-structalias.c:2807 |tree-ssa-structalias.c:2807
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
It's not related to CHKP, happens even with normal thunks:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr71146.C -fipa-pta
-O3 -c

g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr71146.C -fipa-pta
-O3 -c
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr71146.C:20:11: internal
compiler error: in insert_vi_for_tree, at tree-ssa-structalias.c:2807
   foo->fn (0, 0, 0);
   ^
0xfd68bc insert_vi_for_tree
.././../gcc/tree-ssa-structalias.c:2807
0xfd74ac associate_varinfo_to_alias
.././../gcc/tree-ssa-structalias.c:7620
0x9e2dc6 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool, bool)
.././../gcc/cgraph.c:2354
0x9e2e37 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool, bool)
.././../gcc/cgraph.c:2375
0x9e2ed8 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool, bool)
.././../gcc/cgraph.c:2362
0xfe3420 ipa_pta_execute
.././../gcc/tree-ssa-structalias.c:7822


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530
[Bug 65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[Bug c++/79785] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:11950

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Marek Polacek  ---
Actually, a dup.

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

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[palmer at dabbelt dot com]

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

Palmer Dabbelt  changed:

   What|Removed |Added

 CC||palmer at dabbelt dot com

--- Comment #12 from Palmer Dabbelt  ---
We actually _can't_ allow integer modes in FPRs on RISC-V because it's
undefined behavior in the ISA spec (this allows flexibility in the internal
representation of FP registers, which can help the hardware).  Our simulators
don't model this right now, so I'm going to go fix them, and then fix the bugs
that fall out.

If I understand this all correctly then mpf's riscv_preferred_reload_class fix
is the right way to go about it, I'm going to start running some test suites to
make sure nothing blows up.

Nobody knows why we have the f modes in movqi and friends.  Andrew and I
suspect it's vestigial (probably a workaround for a bug in our port), so I'm
going to try and remove them and fix the fallout.

I believe this is a problem in the RISC-V port, so you're welcome to assign the
bug to me.  I might not have time to fix this today, this way I won't lose it.

Thanks for all the info!

[Bug c/79834] c/c-parser.c: make code more i18n-friendly

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  7 19:07:44 2017
New Revision: 245959

URL: https://gcc.gnu.org/viewcvs?rev=245959=gcc=rev
Log:
PR c/79834
c/
* c-parser.c (c_parser_pragma): Use error_at instead of c_parser_error
for "may only be used in compound statements" diagnostics, change it
such that the same translatable string is used for all pragmas.  For
PRAGMA_OACC_WAIT use "acc wait" rather than "acc enter data" in the
diagnostics.
(c_parser_omp_cancellation_point, c_parser_omp_target_update,
c_parser_omp_target_enter_data, c_parser_omp_target_exit_data): Change
"may only be used in compound statements" diagnostics, such that the
same translatable string is used for all pragmas.
cp/
* parser.c (cp_parser_omp_cancellation_point,
cp_parser_omp_target_enter_data, cp_parser_omp_target_exit_data,
cp_parser_omp_target_update): Change "may only be used in compound
statements" diagnostics, such that the same translatable string is
used for all pragmas.
(cp_parser_pragma): Likewise.  Use error_at instead of
cp_parser_error for that diagnostics.
testsuite/
* c-c++-common/goacc/pragma_context.c (f2): Adjust expected
diagnostics.

Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/pragma_context.c

[Bug target/79946] Suboptimal code with AVX2 copying all arguments to stack

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Created attachment 40917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40917=edit
Assembly output for ifort

[Bug target/79946] New: Suboptimal code with AVX2 copying all arguments to stack

[tkoenig at gcc dot gnu.org]

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

Bug ID: 79946
   Summary: Suboptimal code with AVX2 copying all arguments to
stack
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40916=edit
Assembly output for gfortran

I looked at a reduced version of the code in PR 79930:

module foo
  use, intrinsic :: iso_fortran_env
  implicit none
  integer, parameter :: dp = real64 ! KIND for double precision
  type Vect3D
real(dp) :: x,y,z
  end type
contains
  type(Vect3D) recursive pure function TP_LEFT(NU, D, NV) result(tensorproduct)
real(dp), intent(in) :: NU(4), NV(4)
type(Vect3D), intent(in) :: D(4,4)
real(dp) :: Dx(4,4), Dy(4,4), Dz(4,4)
real(dp) :: tmp(4)
Dx = D%x
Dy = D%y
Dz = D%z
tmp = matmul(NU,Dx);
tensorproduct%x = dot_product(tmp,NV)
tmp = matmul(NU,Dy);
tensorproduct%y = dot_product(tmp,NV)
tmp = matmul(NU,Dz);
tensorproduct%z = dot_product(tmp,NV)
  end function
end module foo

Translating with 

$ gfortran -mavx2 -mfma -S -Ofast -o tp_o_gfortran.s tp_o.f90

led to code at the beginning of the function where all of the
arguments appear to be copied to the stack:

_foo_MOD_tp_left:
.LFB0:
.cfi_startproc
leaq8(%rsp), %r10
.cfi_def_cfa 10, 0
andq$-32, %rsp
movq%rdi, %rax
pushq   -8(%r10)
pushq   %rbp
.cfi_escape 0x10,0x6,0x2,0x76,0
movq%rsp, %rbp
pushq   %r10
.cfi_escape 0xf,0x3,0x76,0x78,0x6
subq$304, %rsp
vmovsd  (%rdx), %xmm0
vmovsd  %xmm0, -400(%rbp)
vmovsd  24(%rdx), %xmm0
vmovsd  %xmm0, -392(%rbp)
vmovsd  48(%rdx), %xmm0
vmovsd  %xmm0, -384(%rbp)
vmovsd  72(%rdx), %xmm0
vmovsd  %xmm0, -376(%rbp)
vmovsd  96(%rdx), %xmm0
vmovsd  %xmm0, -368(%rbp)
vmovsd  120(%rdx), %xmm0
vmovsd  %xmm0, -360(%rbp)
vmovsd  144(%rdx), %xmm0

... and so on. The code appears to unload all of the arguments onto
the stack, then operate from there.

This results in 96 vmovsd instructions and a total of 211 instructions
overall.

By comparision, ifort starts out its code with

pushq %rbp  #12.40
movq  %rsp, %rbp#12.40
andq  $-32, %rsp#12.40
movq  %rdi, %rax#27.3
vmovups   (%rdx), %xmm4 #18.5
vmovups   16(%rdx), %xmm10  #18.5
vmovups   32(%rdx), %xmm11  #18.5
vinsertf128 $1, 48(%rdx), %ymm4, %ymm15 #18.5
vinsertf128 $1, 64(%rdx), %ymm10, %ymm1 #18.5
vblendpd  $10, %ymm1, %ymm15, %ymm2 #18.5

resulting in hardly any memory use and only 136 instructions.

[Bug c/72783] Fortify scanf %s, %[ conversion specifiers

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
(In reply to felix from comment #4)
> 
> By the way: in my report, I suggested making -Wformat-security enable this
> warning. Will -Wformat-length be implied by -Wformat-security?

I think the role of -Wformat-security and its impact on the overflow/truncation
options is worth considering.  (For finer control the -Wformat-length option
has been split into two: -Wformat-overflow and -Wformat-truncation, and the
original has been removed).

[Bug c/79816] -Wformat-security should warn about missing or excess precision/width in %s specifiers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79554
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
I agree that detecting the scanf-type problems would be useful and in line with
the goal of the -Wformat-overflow warnings recently added to GCC 7.  This
feature request is being tracked in bug 72783.

Detecting non-string arguments to %s (i.e., character arrays that are known not
to be nul-terminated) is an enhancement I would like to make to the
-Wformat-overflow/-truncation warnings in GCC 8.  (For non-string functions
like fprintf this might involve introducing a new option.)  I don't think there
is a bug tracking this request so I'll use this one.

There is an open question (in my mind) of whether to integrate aspects of
-Wformat-security with the -Wformat-overflow/-truncation warnings and how.  The
two sets of warnings are implemented very differently, each with different
capabilities and limitations, and so the integration could be quite intrusive.

See bug 79554 for an example of an inherent limitation of the -Wformat-security
implementation.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
(In reply to Richard Biener from comment #9)
> If dot_product (matmul (...), ..) can be implemented more optimally (is
> there a blas/lapack primitive for it?) then the best course of action is to
> pattern
> match that inside the frontend and emit a library call to an optimized
> routine
> (which means eventually adding one to libfortran or using/extending
> -fexternal-blas.

Experience from inlining matmul shows that library routines have
a very hard time beating an inline version for small problem sizes.
This is why we currently implement inline matmul up to a matrix
size of 30.

This example, with 4*4 matrices / vectors, is a prime candidate
for inlining.

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #4 from Eric Botcazou  ---
Fixing.

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
It's already present in system.ads so it should.

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
If it works, even better.

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[dvyukov at google dot com]

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

--- Comment #2 from Dmitry Vyukov  ---
I've shutup that bug with dest = NULL, but then I immediately got this:

BUG: KASAN: global-out-of-bounds in clear_bit
include/linux/bitops_compiler.h:15 [inline]
BUG: KASAN: global-out-of-bounds in dma_channel_table_init+0x81/0x18c
drivers/dma/dmaengine.c:334
Write of size 8 at addr 84d5e921 by task swapper/0/1

which looks like another bug because clear_bit is defined as:

static inline void
clear_bit(long nr, volatile unsigned long *addr)
{
__atomic_fetch_and((char *)addr + (nr / 8), ~(1 << (nr % 8)),
__ATOMIC_RELAXED);
}

Unless I am missing something, type of the first arg to __atomic_fetch_and s
char* so this should be a 1 byte access.

Extracting and minimizing this is quite time consuming, so maybe you will just
spot something else in that code.

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> Shall we
> cp -a gcc/ada/system-linux-ppc{,le}.ads
> sed -i -e 's/:= High_Order/:= Low_Order/' gcc/ada/system-linux-ppcle.ads
> and tweak gcc/ada/gcc-interface/Makefile.in, something else?

Presumably:

Index: system-linux-ppc.ads
===
--- system-linux-ppc.ads(revision 245767)
+++ system-linux-ppc.ads(working copy)
@@ -89,7 +89,8 @@ package System is
--  Other System-Dependent Declarations

type Bit_Order is (High_Order_First, Low_Order_First);
-   Default_Bit_Order : constant Bit_Order := High_Order_First;
+   Default_Bit_Order : constant Bit_Order :=
+ Bit_Order'Val (Standard'Default_Bit_Order);
pragma Warnings (Off, Default_Bit_Order); -- kill constant condition
warning

--  Priority-related Declarations (RM D.1)

[Bug ada/79945] New: ppc64le Default_Bit_Order in Ada

[jakub at gcc dot gnu.org]

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

Bug ID: 79945
   Summary: ppc64le Default_Bit_Order in Ada
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Just forwarding the https://bugzilla.redhat.com/show_bug.cgi?id=1429214
report here, if Ada Default_Bit_Order actually stands for byte order, then it
probably should be Default_Bit_Order : constant Bit_Order := Low_Order_First;
Shall we
cp -a gcc/ada/system-linux-ppc{,le}.ads
sed -i -e 's/:= High_Order/:= Low_Order/' gcc/ada/system-linux-ppcle.ads
and tweak gcc/ada/gcc-interface/Makefile.in, something else?

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
I'll have a look tomorrow.

[Bug c++/79785] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:11950

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
enum E {
  e1 = 0x,
  e2
} e = e2;

is enough to provoke the ICE.  The gimplifier gets "e = <<< error >>>" and
crashes at that error_mark.  It doesn't ICE with -fsyntax-only.

[Bug sanitizer/79944] New: asan: incorrect instrumentation of atomic operations

[dvyukov at google dot com]

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

Bug ID: 79944
   Summary: asan: incorrect instrumentation of atomic operations
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dvyukov at google dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40915=edit
reproducer

Reduced from kernel miscompilation, but reproduces with user-space asan as
well.

gcc version 7.0.1 20170307 (experimental) (GCC)
Last Changed Rev: 245952
Last Changed Date: 2017-03-07 15:13:10 +0100 (Tue, 07 Mar 2017)

The program is attached. It prints:

==138034==ERROR: AddressSanitizer: unknown-crash on address 0x61b006c0 at
pc 0x004009b0 bp 0x7ffef6db2af0 sp 0x7ffef6db2ae8
WRITE of size 1640 at 0x61b006c0 thread T0
#0 0x4009af in atomic_add /tmp/reduced-delta4.c:4
#1 0x4009af in cpupri_set /tmp/reduced-delta4.c:34
#2 0x4007d3 in cpupri_set /tmp/reduced-delta4.c:19
#3 0x4007d3 in main /tmp/reduced-delta4.c:40

Note the 1640 size. It's bogus. 1640 is size of whole struct cpupri, but the
access happens only to 'int counter'.

I've localized it to this part of get_mem_refs_of_builtin_call:

else if (TREE_CODE (dest) == SSA_NAME || TREE_CODE (dest) ==
INTEGER_CST)
  dest = build2 (MEM_REF, TREE_TYPE (TREE_TYPE (dest)),
 dest, build_int_cst (TREE_TYPE (dest), 0));

before that line int_size_in_bytes (TREE_TYPE (dest)) == 8, after 1640.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> I recommend that on balance for all targets the current behavior is a
> reasonable compromise. I have said elsewhere that I am happy to continue
> working in this area and would welcome any further help to evaluate the
> effects of further work. EricB has offered his assistance and any additional
> help would also be good as this issue affects targets in different ways.

Yes, I don't think that we want to revert r245655 now, since it is necessary
for MIPS and doesn't really hurt ARM.  Its only effect is to widen some subword
loads to word loads, which shouldn't really matter in most cases.

[Bug c/72783] Fortify scanf %s, %[ conversion specifiers

[felix.von.s at posteo dot de]

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

felix  changed:

   What|Removed |Added

 CC||felix.von.s at posteo dot de

--- Comment #4 from felix  ---
A few days ago I've filed PR 79816, which would cover this and also passing
character arrays to printf-style functions. Good to know someone's working on
this.

By the way: in my report, I suggested making -Wformat-security enable this
warning. Will -Wformat-length be implied by -Wformat-security?

[Bug c++/79796] [5 Regression] ICE with NSDMI and this pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[5/6 Regression] ICE with   |[5 Regression] ICE with
   |NSDMI and this pointer  |NSDMI and this pointer

--- Comment #9 from Marek Polacek  ---
Fixed in GCC 6 too.

[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> I have read people complaining about very low OMP stack sizes
> on OSX.

What is setting the limit?

> Should we set this to a more reasonable default value in libgfortran?
> Less than 800k is quite ridiculous.

If possible, it would be a great idea.

> Alternatively, is there a way to detect stack overrun in a case like
> this, and abort with something more helpful?

Indeed, but is it worth the pain?

Final note, it would be interesting to understand why r242391 is OK, but not
r242872.

[Bug c++/79796] [5/6 Regression] ICE with NSDMI and this pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Tue Mar  7 17:42:30 2017
New Revision: 245957

URL: https://gcc.gnu.org/viewcvs?rev=245957=gcc=rev
Log:
PR c++/79796 - ICE with NSDMI and this pointer
* call.c (build_over_call): Handle NSDMI with a 'this' by calling
replace_placeholders.

* g++.dg/cpp0x/nsdmi13.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/nsdmi13.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/call.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/79809] ICE in alloca_call_type, at gimple-ssa-warn-alloca.c:282

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Fixed.

[Bug middle-end/79809] ICE in alloca_call_type, at gimple-ssa-warn-alloca.c:282

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Tue Mar  7 17:30:53 2017
New Revision: 245955

URL: https://gcc.gnu.org/viewcvs?rev=245955=gcc=rev
Log:
PR middle-end/79809
* gimple-ssa-warn-alloca.c (pass_walloca::gate): Use HOST_WIDE_INT.
(alloca_call_type): Likewise.

* g++.dg/Walloca1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/Walloca1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-alloca.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/79943] New: Loop splitting breaks with loops of pointer type

[aph at gcc dot gnu.org]

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

Bug ID: 79943
   Summary: Loop splitting breaks with loops of pointer type
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aph at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40914=edit
GCC test case,

If a loop index has POINTER_TYPE, splitting generates incorrect splits because
(end-beg) is incorrectly negated.  Patch to follow.

[Bug fortran/79888] ICE in gfc_warning with -Warray-temporaries

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.4 up to trunk (7.0). -Warray-temporaries is not implemented in
4.3.6.

[Bug fortran/79484] Segfault when executing a test in Power8

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
  Component|target  |fortran

--- Comment #1 from Segher Boessenkool  ---
Could someone who knows about Fortran please look at this?

[Bug target/79623] error building a cross compiler for powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #7 from Segher Boessenkool  ---
Please try with a supported version of GCC; reopen this bug if the problem
still happens for you, then.

If you want to ask questions about ancient versions of GCC, bugzilla is
not the place for that; you can try gcc-help@ for example (but keep in
mind that not very many people will be interested in questions about
no longer supported GCC versions there, either).  Thanks.

[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
I have read people complaining about very low OMP stack sizes
on OSX.

Should we set this to a more reasonable default value in libgfortran?
Less than 800k is quite ridiculous.

Alternatively, is there a way to detect stack overrun in a case like
this, and abort with something more helpful?

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #29 from Jakub Jelinek  ---
Jonathan said he'll file upstream boost bugreport about this.
So closing.

[Bug c/79942] New: Wrong declaration of __builtin_cpu_init

[barannikov88 at gmail dot com]

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

Bug ID: 79942
   Summary: Wrong declaration of __builtin_cpu_init
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barannikov88 at gmail dot com
  Target Milestone: ---

According to documentation, __builtin_cpu_init has return type 'void', but is
created as returning 'int'.

gcc/config/i386/i386.c

static void
ix86_init_platform_type_builtins (void)
{
  make_cpu_type_builtin ("__builtin_cpu_init", IX86_BUILTIN_CPU_INIT,
 INT_FTYPE_VOID, false);
  make_cpu_type_builtin ("__builtin_cpu_is", IX86_BUILTIN_CPU_IS,
 INT_FTYPE_PCCHAR, true);
  make_cpu_type_builtin ("__builtin_cpu_supports", IX86_BUILTIN_CPU_SUPPORTS,
 INT_FTYPE_PCCHAR, true);
}

This is probably a typo.

[Bug c++/79937] [5/6/7 Regression] ICE in replace_placeholders_r

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #3 from Marek Polacek  ---
Testing a fix.

[Bug target/79935] DJGPP: misaligned stack in static constructors

[dj at redhat dot com]

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

DJ Delorie  changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #3 from DJ Delorie  ---
More likely, DJGPP just doesn't support more than 8-byte alignment.  Either
way, this is something that should be investigated on the djgpp list first, and
brought back here only if it's proven to be a gcc problem.

[Bug target/79941] [7 Regression] Altivec vec_vmuleub regression

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #1 from Bill Schmidt  ---
CCing patch author... (it is easy to confuse the two of us).

[Bug c/79940] [6/7 Regression] OpenMP pragma - internal compiler error with taskloop

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|OpenMP pragma - internal|[6/7 Regression] OpenMP
   |compiler error with |pragma - internal compiler
   |taskloop|error with taskloop
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r228777.

[Bug target/79845] rs6000: make code in rd6000.c more i18n-friendly

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
These errors (and the options) are not meant for users anyway, and/or the
message should say something like "requires a subtarget that supports DFP"
or similar.  We certainly don't want users enabling -mhard-dfp if they are
using a -mcpu= that does not already enable it, etc.

[Bug target/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #9 from PeteVine  ---
So, with the whole -mfix-fix-cortex-a53-843419 debacle out of the way, there's
probably not much left to worry about:

http://openbenchmarking.org/result/1703071-RI-1609258LO61

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #2 from Jeffrey A. Law  ---
Note, this triggers at O2 and above, but not at O1.

This really looks like bogus code coming out of the Fortran front-end.  I've
got no clue why it's generating this code:

[ ... ]
  _32 = _yerrmsg_19(D) + 5;
  _33 = _yerrmsg_19(D);
[ ... ]

;;   basic block 6, loop depth 0, count 0, freq 0, maybe hot
;;prev block 5, next block 7, flags: (NEW, REACHABLE)
;;pred:   5 (TRUE_VALUE)
  _7 = (unsigned long) _33;
  _8 = (unsigned long) _32;
  _9 = MIN_EXPR <_7, _8>;
  __builtin_memmove (yerrmsg_25(D), pstr.0_29, _9);
  _10 = (unsigned long) _32;
  _11 = (unsigned long) _33;
  if (_10 < _11)
goto ; [0.00%]
  else
goto ; [0.00%]
;;succ:   7 (TRUE_VALUE)
;;8 (FALSE_VALUE)

;;   basic block 7, loop depth 0, count 0, freq 0, maybe hot
;;prev block 6, next block 8, flags: (NEW, REACHABLE)
;;pred:   6 (TRUE_VALUE)
  _12 = (unsigned long) _33;
  _13 = (unsigned long) _32;
  _14 = _12 - _13;
  _15 = (sizetype) _32;
  _16 = yerrmsg_25(D) + _15;
  __builtin_memset (_16, 32, _14);
;;succ:   8 (FALLTHRU)

So the test at the end of bb6 is really an overflow test.  (x + 5 < x).  

The assignment to _14 is going to overflow.   We end up in this match.pd
pattern:

 /* (T)P - (T)(P + A) -> -(T) A */
  (for add (plus pointer_plus)
   (simplify
(minus (convert @0)
 (convert (add @@0 @1)))
(if (element_precision (type) <= element_precision (TREE_TYPE (@1))
 /* For integer types, if A has a smaller type
than T the result depends on the possible
overflow in P + A.
E.g. T=size_t, A=(unsigned)429497295, P>0.
However, if an overflow in P + A would cause
undefined behavior, we can assume that there
is no overflow.  */
 || (INTEGRAL_TYPE_P (TREE_TYPE (@0))
 && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
 /* For pointer types, if the conversion of A to the
final type requires a sign- or zero-extension,
then we have to punt - it is not defined which
one is correct.  */
 || (POINTER_TYPE_P (TREE_TYPE (@0))
 && TREE_CODE (@1) == INTEGER_CST
 && tree_int_cst_sign_bit (@1) == 0))
 (negate (convert @1)

Which results in:

  __builtin_memset (_16, 32, 18446744073709551611);

Which we quite reasonably warn for.

AFAICT this looks like bogus code coming out of the Fortran front-end to me.  I
don't see any way to mitigate in the optimization pipeline.

[Bug target/79941] [7 Regression] Altivec vec_vmuleub regression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Target||powerpc*-*
   Priority|P3  |P1
 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug target/79941] New: [7 Regression] Altivec vec_vmuleub regression

[jakub at gcc dot gnu.org]

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

Bug ID: 79941
   Summary: [7 Regression] Altivec vec_vmuleub regression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1429961,
vec_vmul{e,o}u{b,h} as well as vec_vmul{e,o} with unsigned vector arguments
regressed, most likely with r243807.

Short testcase:

#include 

int
main ()
{
  vector unsigned char v0 = {1, 0, 0, 0, 0, 0, 0, 0};
  vector unsigned char v1 = {0xff, 0, 0, 0, 0, 0, 0, 0};
  vector unsigned short res = vec_vmuleub (v0, v1);
  if (res[0] != (unsigned short)v0[0] * (unsigned short)v1[0])
__builtin_abort ();
  return 0;
}

The problem is that for e.g. __builtin_vec_vmuleub, for some strange reason the
builtin function type is using signed vector arguments and result.
There is also VMULEUB_UNS and similar stuff, but the corresponding builtin
doesn't seem to work either (and nothing in altivec.h uses it).
That unexpected function prototype results in VIEW_CONVERT_EXPRs being added
for the arguments and return value, and then it is folded by
rs6000_gimple_fold_builtin into
VEC_WIDEN_MULT_EVEN_EXPR/VEC_WIDEN_MULT_ODD_EXPR, but as the arguments are
signed vectors, in the end it works as the *sb builtin instead.

So, either the weird builtin function prototypes are bugs, then likely the
VMULEUB_UNS etc. stuff should be removed and rs6000.c (builtin_function_type)
should treat the non-UNS suffixed UB/UH mule/mulo builtins as unsigned.

Or rs6000_gimple_fold_builtin needs to VIEW_CONVERT_EXPR the arguments again to
unsigned and back if there is signedness mismatch.

[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
(In reply to Zdenek Sojka from comment #0)
> Trying 27, 28 -> 33:
> ...
> Successfully matched this instruction:
> (set (reg:QI 128 [ _6 ])
> (plus:QI (subreg:QI (reg:DI 111 [ p1D.1798 ]) 0)
> (subreg:QI (reg/v:DI 100 [ bD.1802 ]) 0)))
> Successfully matched this instruction:
> (set (reg:QI 123 [ p1D.1798 ])
> (plus:QI (reg:QI 128 [ _6 ])
> (subreg:QI (reg:DI 92 [ _6 ]) 0)))
> allowing combination of insns 27, 28 and 33

It looks like this combination introduces a new use of reg 100 into insn 28 (it
was previously used in insn 33). Thus, it becomes the first use of reg 100, but
the other use in insn 32 still has the LOG_LINKS pointer, allowing the second
combination which makes the code incorrect.

This looks like a pretty serious hole in the combiner. Not sure yet how best to
fix it.

[Bug c/79940] OpenMP pragma - internal compiler error with taskloop

[aidan.chalk at gmail dot com]

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

Aidan Chalk  changed:

   What|Removed |Added

 CC||aidan.chalk at gmail dot com

--- Comment #1 from Aidan Chalk  ---
Missed the output from command line with gcc-7:
> gcc-7 -fopenmp mainbroke.c
mainbroke.c: In function ‘main’:
mainbroke.c:12:11: internal compiler error: in extract_omp_for_data, at
omp-low.c:636
   #pragma omp taskloop default(none) shared(a, b, c) private(i)
   ^~~
0x91ae63 extract_omp_for_data
../.././gcc/omp-low.c:636
0x9371c8 lower_omp_for
../.././gcc/omp-low.c:15161
0x92d81e lower_omp_1
../.././gcc/omp-low.c:17043
0x92d81e lower_omp
../.././gcc/omp-low.c:17180
0x9355a2 lower_omp_taskreg
../.././gcc/omp-low.c:15662
0x92d2be lower_omp_1
../.././gcc/omp-low.c:17036
0x92d2be lower_omp
../.././gcc/omp-low.c:17180
0x92e0c0 lower_omp_1
../.././gcc/omp-low.c:17019
0x92e0c0 lower_omp
../.././gcc/omp-low.c:17180
0x92d97d lower_omp_1
../.././gcc/omp-low.c:17028
0x92d97d lower_omp
../.././gcc/omp-low.c:17180
0x931bf1 execute_lower_omp
../.././gcc/omp-low.c:17915
0x931bf1 execute
../.././gcc/omp-low.c:17952
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/79940] New: OpenMP pragma - internal compiler error with taskloop

[aidan.chalk at gmail dot com]

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

Bug ID: 79940
   Summary: OpenMP pragma - internal compiler error with taskloop
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aidan.chalk at gmail dot com
  Target Milestone: ---

Created attachment 40913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40913=edit
The .i file produced by the compiler for the bug desribed here.

Using taskloop with an iterator declared prior to an OpenMP parallel region
causes an internal compiler error:

Compiled with: gcc-7 -fopenmp x.c

>> gcc-7 -v
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/opt/gcc/7.20160925/lib/gcc/x86_64-suse-linux/7.0.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ./configure --prefix=/opt/gcc/7.20160925
--with-pkgversion='openSUSE Linux' --enable-languages=c,c++,fortran
--enable-checking=release --enable-ssp --disable-libssp --disable-libvtv
--disable-libcc1 --enable-plugin -with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-7 --without-system-libunwind
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
--enable-bootstrap --disable-multilib
Thread model: posix
gcc version 7.0.0 20160925 (experimental) (openSUSE Linux)

I've attached the relevant .i file produced by 7.0. I have not checked if this
occurs with gfortran at this time.

This error can be avoided if removing the pragma omp parallel (which is
apparently fixed in bug 71371, but without the parallel this is not a useful
code). Also by replacing:
for(i =0; i < with for(int i = 0; i < ...) the bug disappears, however both
are OpenMP compliant.


I've also found the identical bug when compiling with gcc 6.3 on a different
machine:
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/gpfs/stfc/local/apps/gcc/gcc/6.3.0/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/gpfs/stfc/local/apps/gcc/gcc/6.3.0
--disable-multilib --with-system-zlib --disable-bootstrap
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu
--enable-offload-targets=x86_64-intelmic-linux=/gpfs/stfc/local/apps/mic/gcc/6.3.0
--enable-languages=c,c++,fortran,lto : (reconfigured) ../configure
--prefix=/gpfs/stfc/local/apps/gcc/gcc/6.3.0 --disable-multilib
--with-system-zlib --disable-bootstrap --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--enable-languages=c,c++,fortran,lto
Thread model: posix
gcc version 6.3.0 (GCC)

> gcc -fopenmp main.c
main.c: In function 'main':
main.c:12:11: internal compiler error: in extract_omp_for_data, at
omp-low.c:635
   #pragma omp taskloop default(none) shared(a, b, c) private(i)
   ^~~
0x925815 extract_omp_for_data
../../gcc/omp-low.c:635
0x94178e lower_omp_for
../../gcc/omp-low.c:15149
0x93834e lower_omp_1
../../gcc/omp-low.c:17027
0x93834e lower_omp
../../gcc/omp-low.c:17164
0x93fc95 lower_omp_taskreg
../../gcc/omp-low.c:15650
0x938416 lower_omp_1
../../gcc/omp-low.c:17020
0x938416 lower_omp
../../gcc/omp-low.c:17164
0x9380f0 lower_omp_1
../../gcc/omp-low.c:17003
0x9380f0 lower_omp
../../gcc/omp-low.c:17164
0x9383a5 lower_omp_1
../../gcc/omp-low.c:17012
0x9383a5 lower_omp
../../gcc/omp-low.c:17164
0x93c2ca execute_lower_omp
../../gcc/omp-low.c:17899
0x93c2ca execute
../../gcc/omp-low.c:17936

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

--- Comment #10 from mpf at gcc dot gnu.org ---
(In reply to Kito Cheng from comment #8)
> [1]
> diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
> index 89567f7..148967b 100644
> --- a/gcc/config/riscv/riscv.c
> +++ b/gcc/config/riscv/riscv.c
> @@ -3581,10 +3581,6 @@ riscv_hard_regno_mode_ok_p (unsigned int regno, enum
> machine_mode mode)
>if (!FP_REG_P (regno + nregs - 1))
> return false;
>  
> -  if (GET_MODE_CLASS (mode) != MODE_FLOAT
> - && GET_MODE_CLASS (mode) != MODE_COMPLEX_FLOAT)
> -   return false;
> -
>/* Only use callee-saved registers if a potential callee is guaranteed
>  to spill the requisite width.  */
>if (GET_MODE_UNIT_SIZE (mode) > UNITS_PER_FP_REG
> @@ -3634,7 +3630,7 @@ riscv_class_max_nregs (reg_class_t rclass, enum
> machine_mode mode)
>  static reg_class_t
>  riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
>  {
> -  return reg_class_subset_p (FP_REGS, rclass) ? FP_REGS :
> +  return reg_class_subset_p (FP_REGS, rclass) && TARGET_HARD_FLOAT ?
> FP_REGS :
>  reg_class_subset_p (GR_REGS, rclass) ? GR_REGS :
>  rclass;
>  }

I don't think you want to do this really.  Allowing integer modes in FPRs can
make a real mess and lead to extra cost moving to and from FPRs which can be
slow as well as using additional register banks that would not normally be
required. I.e. consider code that only uses integer types hitting the FPU
registers.  Assuming the FPRs can be managed in a lazy context fashion then
this means you can introduce additional context switch overhead for
non-floating-point processes which is additional waste.

Doesn't my original fix work for you? It should just lead to the loads being a
different width but not using FPRs; I guess it could break something else
though.

The problem here is that WORD_REGISTER_OPERATIONS allows a subreg and a reg of
the same hard-register to be used without need for sign/zero extension but
instead relying on the LOAD_EXTEND_OP rules. The 'true' value is that of the
inner mode and there can be loads/stores in that inner-mode elsewhere that
expect the full width of the inner-mode to be valid in memory. If you do an
output reload in the outer-mode and only store outer-mode-width in memory then
any inner mode consumer will get junk in the upper bits.  There are of course
occasions where this does not matter. In particular that means input reloads
could be done in the outer-mode (when that is narrower) as long as and output
reloads for the same instruction are done in the inner-mode i.e. keeping memory
content consistent but reducing the size of loads. Doing that kind of
optimisation and getting it correct is far too invasive for stage 4 and the
aspects of the current behavior are necessary for correctness.

I recommend that on balance for all targets the current behavior is a
reasonable compromise. I have said elsewhere that I am happy to continue
working in this area and would welcome any further help to evaluate the effects
of further work. EricB has offered his assistance and any additional help would
also be good as this issue affects targets in different ways.

[Bug c/79938] gcc unnecessarily spills xmm register to stack when inserting vector items

[postmaster at raasu dot org]

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

--- Comment #3 from postmaster at raasu dot org ---
With -mssse3 instead of -msse4.1, the issue gets even worse:

---
...
pxor%xmm1, %xmm1
movl$.LC0, %esi
movl$1, %edi
movd%eax, %xmm0
movdqa  %xmm0, %xmm4
pshufb  %xmm1, %xmm4
movaps  %xmm4, (%rsp)
movzbl  (%rsp), %eax
movaps  %xmm4, 224(%rsp)
movzbl  225(%rsp), %edx
movaps  %xmm4, 208(%rsp)
movaps  %xmm4, 192(%rsp)
movaps  %xmm4, 176(%rsp)
addl%edx, %eax
movzbl  210(%rsp), %edx
movaps  %xmm4, 160(%rsp)
movaps  %xmm4, 144(%rsp)
movaps  %xmm4, 128(%rsp)
movaps  %xmm4, 112(%rsp)
addl%edx, %eax
movzbl  195(%rsp), %edx
movaps  %xmm4, 96(%rsp)
movzbl  105(%rsp), %ecx
movaps  %xmm4, 80(%rsp)
movaps  %xmm4, 64(%rsp)
movaps  %xmm4, 48(%rsp)
addl%edx, %eax
movzbl  165(%rsp), %edx
movaps  %xmm4, 32(%rsp)
movd%eax, %xmm0
movzbl  180(%rsp), %eax
movaps  %xmm4, 16(%rsp)
movaps  %xmm4, 240(%rsp)
addl%edx, %eax
movzbl  150(%rsp), %edx
addl%edx, %eax
movzbl  135(%rsp), %edx
addl%eax, %edx
movzbl  120(%rsp), %eax
movd%edx, %xmm6
punpckldq   %xmm6, %xmm0
addl%ecx, %eax
movzbl  90(%rsp), %ecx
addl%ecx, %eax
movzbl  75(%rsp), %ecx
addl%ecx, %eax
movzbl  45(%rsp), %ecx
movd%eax, %xmm1
movzbl  60(%rsp), %eax
addl%ecx, %eax
movzbl  30(%rsp), %ecx
addl%ecx, %eax
movzbl  15(%rsp), %ecx
addl%ecx, %eax
movd%eax, %xmm5
xorl%eax, %eax
punpckldq   %xmm5, %xmm1
punpcklqdq  %xmm1, %xmm0
movdqa  %xmm0, %xmm2
movd%xmm0, %edx
pshufd  $255, %xmm0, %xmm3
punpckhdq   %xmm0, %xmm2
pshufd  $85, %xmm0, %xmm1
...
---

Notice all the lines starting with "movaps  %xmm4,"
Same register contents are polluted all over the stack.

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[marxin at gcc dot gnu.org]

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

Bug 79762 Summary: [6/7 Regression][CHKP] ICE in verify_cgraph_node failed 
(node is weakref but not an transparent_alias)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79762

   What|Removed |Added

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

[Bug middle-end/79415] [6/7 Regression] -fcheck-pointer-bounds results in internal compiler error weakref attributes

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
*** Bug 79762 has been marked as a duplicate of this bug. ***

[Bug ipa/79762] [6/7 Regression][CHKP] ICE in verify_cgraph_node failed (node is weakref but not an transparent_alias)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Dup.

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

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #14 from Martin Liška  ---
I'll prepare backport to active branches.

[Bug middle-end/78339] -fsuggest-attribute=noreturn should not warn on -fcheck-pointer-bounds clones

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I've got patch for that.