[Bug libgomp/90527] alloc.c:72:7: error: implicit declaration of function ‘posix_memalign’

[mfe at live dot de]

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

--- Comment #2 from martin  ---
Sad to hear. The system is quite old.

>uname -a 2.6.17.14
ldd (GNU libc) 2.3.2

[Bug libgomp/90527] alloc.c:72:7: error: implicit declaration of function ‘posix_memalign’

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
libgomp configure checks for posix_memalign:
AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
and uses posix_memalign only if it is found:
#ifdef HAVE_ALIGNED_ALLOC
  ret = aligned_alloc (al, size);
#elif defined(HAVE__ALIGNED_MALLOC)
  ret = _aligned_malloc (size, al);
#elif defined(HAVE_POSIX_MEMALIGN)
  if (posix_memalign (&ret, al, size) != 0)
ret = NULL;
#elif defined(HAVE_MEMALIGN)
  {
extern void *memalign (size_t, size_t);
ret = memalign (al, size);
  }
#else
So your case seems to be that posix_memalign is present in the library, but not
declared, I think AC_CHECK_FUNCS just checks whether it is defined in the
library.  So, either we need additionally AC_CHECK_DECL for posix_memalign, or
for this case perhaps #define _GNU_SOURCE before first header in alloc.c might
be enough, in env.c we already do that.
So, can you try:
--- libgomp/alloc.c 2019-04-25 20:01:50.766232432 +0200
+++ libgomp/alloc.c 2019-05-18 10:10:40.153245345 +0200
@@ -27,6 +27,7 @@
places in the OpenMP API do not make any provision for failure, so in
general we cannot allow memory allocation to fail.  */

+#define _GNU_SOURCE
 #include "libgomp.h"
 #include 

[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function

[m.diehl at mpie dot de]

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

Martin Diehl  changed:

   What|Removed |Added

 CC||m.diehl at mpie dot de

--- Comment #3 from Martin Diehl  ---
Created attachment 46377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46377&action=edit
fortran code for error in submodule

[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function

[m.diehl at mpie dot de]

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

--- Comment #4 from Martin Diehl  ---
The same error occurs for the dimension attribute and real variables

gfortran -c test_module.f90
test_module.f90:20:27:

 real, dimension(2) :: p
   1
Error: Duplicate DIMENSION attribute specified at (1)


module test_module
  interface
module function p(a)
  real, dimension(2) :: p
  real :: a
 end function p

module function p2(a)
  real :: p2
  real :: a
 end function p2
  end interface

end module test_module

submodule(test_module) test_submodule

contains
  module function p(a)
real, dimension(2) :: p ! does not work
real :: a
p = [a,a+1.0]
  end function p

  module function p2(a)
real :: p2
real :: a
p2 = a
  end function p2

end submodule test_submodule

[Bug translation/90528] New: ICE caused b bad format string in gimple-ssa-warn-restrict.c:1803 for 'es' locale

[slyfox at inbox dot ru]

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

Bug ID: 90528
   Summary: ICE caused b bad format string in
gimple-ssa-warn-restrict.c:1803 for 'es' locale
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

Created attachment 46378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46378&action=edit
27_all_es-po.patch

Originally reported as https://bugs.gentoo.org/686076 by Boris Carvajal:

  // test.c
  #include 
  int main()
  {
struct S {
char a[4];
} s;
memset(s.a, 'a', 5);
  }

  $ LANG=es_CL.UTF-8 LANGUAGE=es gcc -c -O2 -Warray-bounds test.c

  during GIMPLE pass: wrestrict
  En la función ‘main’:
  en pp_format, en pretty-print.c:1393
3 | int main()
  | ^~~~
  Por favor, envíe un informe completo de errores,
  con el código preprocesado si es apropiado.
  Véase  para instrucciones.

Caused by %qD/%Qd typo in:

#: gimple-ssa-warn-restrict.c:1803
msgid "%G%qD offset %s from the object at %qE is out of the bounds of
referenced subobject %qD with type %qT at offset %wu"
msgstr "El desplazamiento de %G%qD %s desde el objeto en %qE está fuera de los
límites del subobjeto referenciado %Qd con tipo %qT en el desplazamiento %wu"

Boris Carvajal reported it to transifex. Fix is already incorporated in 
https://translationproject.org/PO-files/es/gcc-9.1.0.es.po

Can it be pulled into gcc?

Attaching minimal fix for illustration:

Thank you!

[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function

[m.diehl at mpie dot de]

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

--- Comment #5 from Martin Diehl  ---
forgot to mention:

1) I have encountered this for gfortran 8.3.0
2) Intel fortran accepts the code
3) Would it be possible to change the title? It is not only related to
characters and allocatable but for general function attributes

[Bug c++/60531] template function not resolved when comparing functions

[harald at gigawatt dot nl]

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

--- Comment #3 from Harald van Dijk  ---
I posted a patch 
over a month ago; I am including the link here in case I end up forgetting to
keep pinging.

[Bug libgomp/90527] alloc.c:72:7: error: implicit declaration of function ‘posix_memalign’

[mfe at live dot de]

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

martin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from martin  ---
Thanks, the applied patch works.

[Bug tree-optimization/89713] Optimize away an empty loop whose finiteness can not be analytically determined

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Related:
PR 89134
PR 82776
PR 67809

[Bug c++/60531] template function not resolved when comparing functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
(In reply to Harald van Dijk from comment #3)
> I posted a patch 
> over a month ago; I am including the link here in case I end up forgetting
> to keep pinging.

Sorry about that and thanks for the patch.  It looked fine to me but I'll try
to take a closer look at it next week (but won't be able to approve it anyway.)

FGM提%%供%%税%%栗%qj

[李老师]

gcc-bugs@gcc.gnu.org
+
栋忙
 
可  办 税 票，认 证 后 付  歀。
  详   电：李 生，136—6075— 4190，
   业   q：157— 533— 2698
---

[Bug c++/90529] New: suggest struct or class

[jg at jguk dot org]

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

Bug ID: 90529
   Summary: suggest struct or class
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Perhaps g++ could suggest the missing 'struct' or 'class for the following?

typedef a
{
int a;
} a_t;


gcc trunk
#1 with x86-64 gcc (trunk)
./example.cpp:1:9: error: 'a' does not name a type
1 | typedef a
  | ^
./example.cpp:4:3: error: 'a_t' does not name a type
4 | } a_t;
  |   ^~~
Compiler returned: 1


clang trunk
#1 with x86-64 clang (trunk)
./example.cpp:1:9: error: C++ requires a type specifier for all declarations
typedef a
~~~ ^
./example.cpp:3:9: error: expected '(' for function-style cast or type
construction
int a;
~~~ ^
./example.cpp:4:2: error: expected ';' after top level declarator
} a_t;
 ^
 ;
3 errors generated.
Compiler returned: 1



Another variation, could still suggest for ?

typedef
{
int a;
} a_t;

[Bug fortran/90506] rejects-valid: function with polymorphic return type

[fortranfan at outlook dot com]

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

Vipul Parekh  changed:

   What|Removed |Added

 CC||fortranfan at outlook dot com

--- Comment #2 from Vipul Parekh  ---
Here is a variant of the submitted case that also might be of interest here on
account of the internal compiler error (ICE) that occurs; an ICE makes it very
difficult for users. 

--- begin console output --- 
C:\Temp>type m.f90 
module m 
   type :: t 
   end type 
   abstract interface 
  function Ifun() result(r) 
 import :: t 
 class(t), allocatable :: r 
  end function 
   end interface 
   procedure(Ifun), pointer :: pfun => null() 
contains 
   function my_fun() result(r) 
  class(t), allocatable :: r 
  r = t() 
   end function 
   subroutine sub() 
  pfun => my_fun 
   end subroutine 
end 

C:\Temp>gfortran -c -Wall m.f90 
m.f90:17:0: 

   17 |   pfun => my_fun 
  | 
internal compiler error: Segmentation fault 
libbacktrace could not find executable to open 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See  for instructions. 

C:\Temp> 
--- end console output ---

[Bug target/90419] RISCV --with-multilib-list support is somewhat incomplete

[dilfridge at gentoo dot org]

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

--- Comment #5 from Andreas K. Huettel  ---
Created attachment 46379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46379&action=edit
patch: disable 32bit riscv abis in gcc multilib

OK thanks. This is roughly what I suspected. 

Not for upstreaming but for our own purposes (and for whoever else stumbles
across this bug) - could you please have a look at attached patch, whether this
is the "correct temporary workaround" to build multi-abi multilib with current
FSF glibc?

[Bug middle-end/90530] New: [10 Regression] Invalid SUBREG insn generated by reload

[danglin at gcc dot gnu.org]

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

Bug ID: 90530
   Summary: [10 Regression] Invalid SUBREG insn generated by
reload
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

In stage2,

/test/gnu/gcc/objdir/./prev-gcc/xg++ -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/g
nu64/gcc/gcc-10/hppa64-hp-hpux11.11/bin/ -nostdinc++
-B/test/gnu/gcc/objdir/prev
-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/test/gnu/gcc/objdir/prev-hppa64-h
p-hpux11.11/libstdc++-v3/libsupc++/.libs 
-I/test/gnu/gcc/objdir/prev-hppa64-hp-
hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 
-I/test/gnu/gcc/objdir/prev-
hppa64-hp-hpux11.11/libstdc++-v3/include 
-I/test/gnu/gcc/gcc/libstdc++-v3/libsu
pc++ -L/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/t
est/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-fno-PI
E -c   -g -O2 -fno-checking -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronou
s-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wmissing-fo
rmat-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macro
s -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../g
cc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I./../intl
-I../../gcc/gcc/
../libcpp/include -I/opt/gnu64/gcc/gmp/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/gcc/../libback
trace   -o expmed.o -MT expmed.o -MMD -MP -MF ./.deps/expmed.TPo
../../gcc/gcc/e
xpmed.c
../../gcc/gcc/expmed.c: In function 'void init_expmed()':
../../gcc/gcc/expmed.c:326:1: error: unrecognizable insn:
  326 | }
  | ^
(insn 3285 3284 3286 4 (set (reg:SI 52 %fr24)
(subreg:SI (reg:DI 50 %fr22) 4)) -1
 (nil))
during RTL pass: reload
../../gcc/gcc/expmed.c:326:1: internal compiler error: in extract_insn, at
recog.c:2310
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.

This ICE was introduced in r270902:

2019-05-06  Richard Biener  

PR tree-optimization/90316
* tree-ssa-alias.c (maybe_skip_until): Pass in target BB,
compute target on demand.
(get_continuation_for_phi): Remove code walking stmts to
get to a target virtual operand which could end up being
quadratic.

At first I thought this was a latent target issue, but
pa_can_change_mode_class() doesn't allow mode changes for for floating
point registers and it doesn't help to try to generate a secondary reload
in pa_secondary_reload() for SUBREGs.  There's already code in
pa_emit_sequence() to handle reloading SUBREGs.

[Bug fortran/90498] [8/9/10 Regression] ICE with select type/associate and derived type argument containing class(*)

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
(In reply to Paul Thomas from comment #2)
> Created attachment 46375 [details]
> Patch for the problem
> 
> I very much doubt that this was revision r257065. The problem looks to have
> Andre's signature on it. Nevertheless, I have the fix attached and have
> taken it.
> 
>   type field_names_a
> class(*), pointer :: var(:) =>null()
>   end type
> 
>   type(field_names_a),pointer :: a(:)
>   allocate (a(1))
> 
>   allocate (a(1)%var(2), source = ["hello"," baby"])
>   call s(a)
>   deallocate (a(1)%var)
>   deallocate (a)
> contains
>   subroutine s(a)
> 
> type(field_names_a) :: a(:)
> 
> select type (var => a(1)%var)
>   type is (character(*))
> print *, var
>   class default
> stop
> end select
> associate (var => a(i)%var)
>   select type (var2 => a(1)%var)
> type is (character(*))
>   print *, var2
> class default
>   stop
>   end select
> end associate
>   end
> end
> 
> Does the right thing mostly but sometimes, after recompilation, segfaults at
> runtime - I will check out why before submitting.
> 
> Paul

The segfaults were a fingers problem on my part - 'i' instead of '1' in the
subscript.

Have submitted to the list with the testcase.
Paul

[Bug target/90419] RISCV --with-multilib-list support is somewhat incomplete

[wilson at gcc dot gnu.org]

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

--- Comment #6 from Jim Wilson  ---
Comment on attachment 46379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46379
patch: disable 32bit riscv abis in gcc multilib

You are missing the g aliases.  And you still have 32-bit dirnames.  We have a
generator script that is used to generate this file.  It gives the command line
at the top.  You can just rerun this without the 32-bit arches and abis.

Try rynning:
./multilib-generator
rv64imac-lp64-rv64ima,rv64imaf,rv64imafd,rv64imafc,rv64imafdc-
rv64imafdc-lp64d-rv64imafd-
that should be on a single line.  Then pipe that into a file to use.

[Bug target/90419] RISCV --with-multilib-list support is somewhat incomplete

[dilfridge at gentoo dot org]

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

Andreas K. Huettel  changed:

   What|Removed |Added

  Attachment #46379|0   |1
is obsolete||

--- Comment #7 from Andreas K. Huettel  ---
Created attachment 46380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46380&action=edit
patch: disable 32bit riscv abis in gcc multilib

(In reply to Jim Wilson from comment #6)
> You are missing the g aliases.  And you still have 32-bit dirnames.  We have
> a generator script that is used to generate this file.  It gives the command
> line at the top.  You can just rerun this without the 32-bit arches and abis.
> 
> Try rynning:
> ./multilib-generator
> rv64imac-lp64-rv64ima,rv64imaf,rv64imafd,rv64imafc,rv64imafdc-
> rv64imafdc-lp64d-rv64imafd-
> that should be on a single line.  Then pipe that into a file to use.

Thank you, will use that now. 

For completeness the resulting patch is attached.

[Bug tree-optimization/81163] error: ‘snprintf’ output may be truncated before the last format character [-werror=format-truncation=] note: ‘snprintf’ output between 2 and 266 bytes into a destination

[mcroce at redhat dot com]

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

Matteo Croce  changed:

   What|Removed |Added

 CC||mcroce at redhat dot com

--- Comment #11 from Matteo Croce  ---
Hi,

when compiling this snippet:

void f()
{
const char *dir = "a";
const char file[50] = "b";
char buf[4];
snprintf(buf, sizeof(buf), "%s/%s", dir, file);
}

I get:

buf.c: In function ‘f’:
buf.c:19:33: warning: ‘%s’ directive output may be truncated writing up to 49
bytes into a region of size 3 [-Wformat-truncation=]
   19 |  snprintf(buf, sizeof(buf), "%s/%s", dir, file);
  | ^~
buf.c:19:2: note: ‘snprintf’ output 2 or more bytes (assuming 51) into a
destination of size 4
   19 |  snprintf(buf, sizeof(buf), "%s/%s", dir, file);
  |  ^~


While I agree with the first warning (directive output may be truncated writing
up to 49 bytes into a region of size 3) I'm not fully convinced about
"‘snprintf’ output 2 or more bytes (assuming 51) into a destination of size 4".
snprintf will output up to 4 bytes, NULL terminator included according to the
documentation:

The functions snprintf() and vsnprintf() write at most size bytes
(including the terminating null byte ('\0')) to str.

I'm using GCC 9.1.1

Regards,
Matteo Croce

[Bug middle-end/90530] [10 Regression] Invalid SUBREG insn generated by reload

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Created attachment 46381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46381&action=edit
Preproccessed source

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc |powerpc*-*-*
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-18
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
What does "32<->64" mean?

[Bug c++/33661] template methods forget explicit local register asm vars

[gdelugre.gcc at subvert dot technology]

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

--- Comment #16 from Guillaume Delugré  
---
Tested on g++ 9.1.0, the bug is still present. Is there any chance of having
the Andreas' fix pushed upstream?

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

[slandden at gmail dot com]

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

--- Comment #2 from Shawn Landden  ---
vector unsigned long long unpacked;
vector unsigned int packedl, packedr;

unpacked = vec_pack(packedl, packedr);
packedl = vec_unpackh(unpacked);
packedr = vec_unpackl(unpacked);

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
What should the semantics of this be?  There are four 32-bit elts each
in packedl and packedr, which of those go where in unpacked?

I think what you want to do can be expressed with just two or maybe three
existing builtins, but it's not clear to me exactly what you want.

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

[slandden at gmail dot com]

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

--- Comment #4 from Shawn Landden  ---
Oh my bad, I got it backwards

vector unsigned long long unpackedl, unpackedr;
vector unsigned int packed;

packed = vec_pack(unpackedl, unpackedr);
unpackedl = vec_unpackh(packed);
unpackedr = vec_unpackl(packed);

The point is that it is similar to the other pack/unpack unfunctions. Yet
somehow this one doesn't exist (probably because there is no hardware
instruction for it).

[Bug libstdc++/90531] New: is_trivailly_copyable_v should be 'true'

[alisdairm at me dot com]

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

Bug ID: 90531
   Summary: is_trivailly_copyable_v should be
'true'
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

This is a tale of woe in the standard, but boils down to the following simple
test program, which compiles and passes with the current Microsoft and Clang
compiler/library combinations:

#include 

int main()
{
   static_assert( std::is_trivially_copyable_v< int[5]>);
   static_assert( std::is_trivially_copyable_v);  // valid?
}


The line marked '// valid?' fails only for libstdc++.

Doing a standards dive, there were a couple of core issues for C++11 and C++14
that mandate libstdc++'s interpretation.  However, Core Defect 2094 reversed
that decision for C++17:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2094

This appears to have been adopted as a DR against C++14 at the November 2016
meeting.

While I am filing as a library bug, I suspect the issue is actually an
intrinsic in the compiler, and may extend to the compiler's treatment of
volatile scalars and arrays.

[Bug libstdc++/90532] New: is_constructible_v and is_default_constructible_v should agree

[alisdairm at me dot com]

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

Bug ID: 90532
   Summary: is_constructible_v and
is_default_constructible_v should agree
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

According to the current standard, is_default_constructible_v is true if
is_constructible_v is true.  The current libstdc++ disagrees for arrays of
unknown bound.

Take the following program:

#include 

int main()
{
   static_assert( std::is_constructible_v);
   static_assert( std::is_default_constructible_v);// fail

   static_assert( std:: is_trivially_constructible_v );
   static_assert( std::is_trivially_default_constructible_v);  // pass?!
}


I would expect consistency between all 4 traits.  For Microsoft and LLVM libc++
libraries, all 4 tests fail.  For libstdc++, 3 out of the 4 pass, with only the
'is_defult_constructible_v' test failing.


According to the standard, the trait should be true if an invented variable
initialized as follows (ignoring vexing parses) would be valid:

   T t();  // parsed as variable declaration, not function

So my first thought was that this might be related to the new rules for
parenthetical aggregate initialization, as gcc is may be implementing that
first.  However, the behavior would still be inconsistent, and does not change
with the language dialect.

Then I realized that even with aggregate initialization, arrays of length zero
are ill-formed, so would deduce an invalid array size.

Finally, I note that the is_nothrow_constructible traits are returning the
expected 'false'.

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Segher Boessenkool  ---
vec_unpack* works on vectors of signed integers only, not unsigned.

You need to target at least power8 (-mcpu=power8) to get the long long
versions of this, i.e. the vpkudum and vupk[hl]sw instructions.

This is all documented correctly, as far as I see?  In the ISA doc,
in the ABI doc, and in the GCC docs?  (Power8 is ISA 2.07, we could add
some clarification for that).

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

[slandden at gmail dot com]

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

--- Comment #6 from Shawn Landden  ---
Ahh, sorry for wasting your time. I didn't notice the signed requirement, which
is why it didn't work.

[Bug target/90522] unrecognizable insn (V8SF)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|rtl-optimization|target
   Target Milestone|--- |10.0

[Bug c++/90531] is_trivailly_copyable_v should be 'true'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
  Component|libstdc++   |c++
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes this is a compiler issue. We might already have a bug about it. I haven't
bothered pushing for the intrinsic to change, because the standard will
probably change the rule again as soon as we catch up. A take of woe indeed.