[Bug middle-end/91216] New: [9/10 Regression] OpenMP ICE starting with r265930

[jakub at gcc dot gnu.org]

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

Bug ID: 91216
   Summary: [9/10 Regression] OpenMP ICE starting with r265930
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int r;

void
foo (int *a)
{
  int i;
  #pragma omp for reduction(+:r)
  for (i = 0; i < 64; i++)
a[i] = i;
  #pragma omp for private (r)
  for (i = 0; i < 64; i++)
{
  r = 0;
  #pragma omp parallel shared(r)
  #pragma omp master
  r = r + 1;
}
}

ICEs with -fopenmp starting with r265930, most likely due to the be
passing an address in this case?  Should we simply assert
 this to be false, or should we have a cleanup pass that removes
 these from the list of mappings?  */
-  if (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
+  if (is_global_var (maybe_lookup_decl_in_outer_ctx (decl, shared_ctx)))
return true;

   /* For variables with DECL_HAS_VALUE_EXPR_P set, we cannot tell
omp-low.c hunk.
r is a global decl, initially not TREE_ADDRESSABLE and turned into
TREE_ADDRESSABLE during the reduction handling of the first worksharing loop,
which means that the scaning of the parallel clauses and later lowering
disagree on whether shared(r) is passed by reference or through copy-in/out.

[Bug middle-end/91216] [9/10 Regression] OpenMP ICE starting with r265930

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-20
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

[Bug fortran/88227] ICE in gfc_convert_boz, at fortran/target-memory.c:788

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
The ICE is caused by a bad conversion of REAL(16) BOZ using an integer KIND
that does not exist with -m32 (see comment 2). The ICE is gone with
-fdefault-double-8, but is also present with -freal-8-real-16 -m32:

% gfc pr88227.f90 -fdefault-real-8 -m32 -fdefault-double-8
% ./a.out 
   2.6941399667723174E-320
% gfc pr88227.f90 -freal-8-real-16 -m32
f951: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/91217] New: Returning std::array from lambda results in an extra copy step on return

[milasudril at gmail dot com]

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

Bug ID: 91217
   Summary: Returning std::array from lambda results in an extra
copy step on return
   Product: gcc
   Version: 8.1.0
   URL: https://godbolt.org/z/3zAhtv
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: milasudril at gmail dot com
  Target Milestone: ---
Target: ARM, x86-64

It appears that for GCC versions later than or equal to version 8.1, an extra
copy procedure when an std::array is being returned from a lambda. The problem
does not exist for an immediately created function object.

Not affected: GCC 7.4
Affected: GCC 8.1 up to and including trunk.

[Bug fortran/88227] ICE in gfc_convert_boz, at fortran/target-memory.c:788

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
I get the same ICE for

print *, real(b'1010101001101',16)
end

compiled with -m32.

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
This patch improves things by about a factor 4:

Index: expmed.h
===
--- expmed.h(revision 27)
+++ expmed.h(working copy)
@@ -128,7 +128,7 @@

 /* The number of cache/hash entries.  */
 #if HOST_BITS_PER_WIDE_INT == 64
-#define NUM_ALG_HASH_ENTRIES 1031
+#define NUM_ALG_HASH_ENTRIES 4093
 #else
 #define NUM_ALG_HASH_ENTRIES 307
 #endif

[Bug target/91204] [10 Regression] ICE in expand_expr_real_2, at expr.c:9215 with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jul 20 17:13:00 2019
New Revision: 273629

URL: https://gcc.gnu.org/viewcvs?rev=273629&root=gcc&view=rev
Log:
PR target/91204
* optabs.c (expand_unop): As fallback, expand ~op0 as op0 ^ -1.

* gcc.c-torture/compile/pr91204.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr91204.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug target/91204] [10 Regression] ICE in expand_expr_real_2, at expr.c:9215 with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/53633] __attribute__((naked)) should disable -Wreturn-type

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Sat Jul 20 18:50:20 2019
New Revision: 273635

URL: https://gcc.gnu.org/viewcvs?rev=273635&root=gcc&view=rev
Log:
Fix -Wreturn-type for static naked functions in C

This patch extends the fix for PR53633 to include static functions,
which were giving a bogus -Wreturn-type warning for C but not for C++.

2019-07-20  Richard Sandiford  

gcc/c/
Backport from mainline
2019-07-18  Richard Sandiford  

PR c/53633
* c-decl.c (finish_function): Check targetm.warn_func_return
before issuing a -Wreturn-type warning.

gcc/testsuite/
Backport from mainline
2019-07-18  Richard Sandiford  

* c-c++-common/pr53633-2.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/c-c++-common/pr53633-2.c
Modified:
branches/gcc-9-branch/gcc/c/ChangeLog
branches/gcc-9-branch/gcc/c/c-decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/91218] New: internal compiler error: Segmentation fault compiling concepts and constraints

[ragobria at msu dot edu]

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

Bug ID: 91218
   Summary: internal compiler error: Segmentation fault compiling
concepts and constraints
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ragobria at msu dot edu
  Target Milestone: ---

Created attachment 46615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46615&action=edit
cpp output

I've been checking out the new C++2a features, particularly concepts and
constraints. My attempt to recreate Haskell's Prelude resulted in the attached
code.

I've put some notes in there to help you. Each of my comments is preceded by:
// SUBMITTER'S NOTE


$ g++-8 -v
brian@RAGOBRIAN7490:~/programming/bug$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.3.0-6ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1~18.04.1)

$ g++-8 -std=c++2a -fconcepts src/main.cpp
g++-8: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


This is on WSL. main.cpp and eq.hpp both reside in the src/ directory. Attached
is the output of cpp.

[Bug rtl-optimization/91137] [7/8/9/10 Regression] Wrong code with -O3

[amker at gcc dot gnu.org]

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

--- Comment #11 from bin cheng  ---
Hi, suppose this patch should be backported to 8/7 if no further issues.

[Bug middle-end/91219] New: missing warning on a past-the-end power of access by memcpy

[msebor at gcc dot gnu.org]

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

Bug ID: 91219
   Summary: missing warning on a past-the-end power of access by
memcpy
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The past-the-end access in f0 and g0 are diagnosed as expected (the specific
warning could be debated) but the equivalent invalid accesses in f1 and g1 are
not.  The problem is due to the difference between memcpy and MEM_REF.


$ cat a.c && gcc -O2 -S -Wall -fdump-tree-lower=/dev/stdout a.c
char a[4], b[4];

void f0 (void)
{
  __builtin_memcpy (a, b + 1, 4);   // warning (good)
}

void g0 (void)
{
  __builtin_memcpy (a + 1, b, 4);   // warning (good)
}

void f1 (void)
{
  char *p = a, *q = b + 1;
  __builtin_memcpy (p, q, 4);   // missing warning
}

void g1 (void)
{
  char *p = a + 1, *q = b;
  __builtin_memcpy (p, q, 4);   // missing warning
}


;; Function f0 (f0, funcdef_no=0, decl_uid=1910, cgraph_uid=1, symbol_order=2)

f0 ()
{
  _1 = &b + 1;
  __builtin_memcpy (&a, _1, 4);
  return;
}



;; Function g0 (g0, funcdef_no=1, decl_uid=1913, cgraph_uid=2, symbol_order=3)

g0 ()
{
  _1 = &a + 1;
  __builtin_memcpy (_1, &b, 4);
  return;
}



;; Function f1 (f1, funcdef_no=2, decl_uid=1916, cgraph_uid=3, symbol_order=4)

f1 ()
{
  unsigned int D.1926;
  char * q;
  char * p;

  p = &a;
  q = &b + 1;
  D.1926 = MEM  [(char * {ref-all})q];
  MEM  [(char * {ref-all})p] = D.1926;
  return;
}



;; Function g1 (g1, funcdef_no=3, decl_uid=1921, cgraph_uid=4, symbol_order=5)

g1 ()
{
  unsigned int D.1927;
  char * q;
  char * p;

  p = &a + 1;
  q = &b;
  D.1927 = MEM  [(char * {ref-all})q];
  MEM  [(char * {ref-all})p] = D.1927;
  return;
}


a.c: In function ‘f0’:
a.c:5:3: warning: ‘__builtin_memcpy’ forming offset 5 is out of the bounds [0,
4] of object ‘b’ with type ‘char[4]’ [-Warray-bounds]
5 |   __builtin_memcpy (a, b + 1, 4);   // warning (good)
  |   ^~
a.c:1:12: note: ‘b’ declared here
1 | char a[4], b[4];
  |^
a.c: In function ‘g0’:
a.c:10:3: warning: ‘__builtin_memcpy’ forming offset 5 is out of the bounds [0,
4] of object ‘a’ with type ‘char[4]’ [-Warray-bounds]
   10 |   __builtin_memcpy (a + 1, b, 4);   // warning (good)
  |   ^~
a.c:1:6: note: ‘a’ declared here
1 | char a[4], b[4];
  |  ^

[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #8)
> Hi. As you can see, the patch itself seems simple, but a while ago I noticed
> that quite a few testcases would need adjusting and that made me a little
> nervous. In particular those testcases (both C and C++) which are doing more
> than one check and would have to be split, because the compilation ends
> after the first #error. 

Which testcases are these?

> Anyway, probably that's just boring work to do, what about the other 
> compilers?
> For sure some are following the current gcc behaviour, for compatibility, I
> suspect ICC for example. Should we also have a command line switch? Probably
> missing #includes just unconditionally end the compilation on most compilers,
> though. Well, it's also true that the so called workaround which I mentioned 
> in
> Comment #1 works pretty well and we do have *very* few fatal errors in the 
> front ends...

[Bug c++/91217] Returning std::array from lambda results in an extra copy step on return

[milasudril at gmail dot com]

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

--- Comment #1 from milasudril at gmail dot com ---
For reference, here is a MWE:

#include 
#include 

template
struct CreateArray
{
using value_type = typename TargetArray::value_type;

auto operator()()
{
TargetArray ret;
for(int k = 0 ; k < std::size(src) - 1; ++k)
{ret[k] = value_type{src[k]};}
return ret;
}

SourceArray const& src;
};

class TestA
{
public:
using value_type = char;

static constexpr size_t npos = 255;
template
TestA(SrcType const (&src)[N]
, std::enable_if_t<(N>=1 && N x = 0)
: m_size{N - 1}
, m_data{CreateArray{src}()}
{}
private:
size_t m_size;
std::array m_data;
};

class TestB
{
public:
using value_type = char;

static constexpr size_t npos = 255;
template
TestB(SrcType const (&src)[N]
, std::enable_if_t<(N>=1 && N x = 0)
: m_size{N - 1}
, m_data
{
[&src]()
{
std::array ret;
for(int k = 0 ; k < std::size(src) - 1; ++k)
{ret[k] = value_type{src[k]};}
return ret;
}()
}
{}
private:
size_t m_size;
std::array m_data;
};

TestB hello_2()
{return TestB{"Hello, World! This is a very long string that the compiler
probably will not inline"};}

TestA hello_1()
{return TestA{"Hello, World! This is a very long string that the compiler
probably will not inline"};}

[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code

[segher at gcc dot gnu.org]

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

--- Comment #17 from Segher Boessenkool  ---
Yup, those testcases work fine for powerpc, too; and the signed versions of
those
do as well.  (I couldn't find vector-types.h; I did "#define VECTOR_SIZE 16").