[Bug c/85696] New: OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

Bug ID: 85696
   Summary: OpenMP with variably modified and default(none) won't
compile
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at zulan dot net
  Target Milestone: ---

Created attachment 44085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44085&action=edit
gcc -v (Archlinux)

The following trivial code

void foo(int n, int a[][n])
{
#pragma omp parallel shared(a) default(none)
a[23][0] = 42;
}

fails to compile:

$ gcc -c -fopenmp minimal.c 
minimal.c: In function ‘foo’:
minimal.c:3:6: error: ‘n.0’ not specified in enclosing ‘parallel’
 a[23][0] = 42;
  ^
minimal.c:2:9: error: enclosing ‘parallel’
 #pragma omp parallel shared(a) default(none)
 ^~~

It appears that there is an internal copy n.0 of n to compute the index to any
further access to a. This internal copy is not handled properly in the
default(none) parallel region.

Interestingly in the 004t.gimple pass, it is actually listed as shared(n.0):

#pragma omp parallel default(none) shared(a) shared(n.0)


The bug exists at least since 4.8 and was first reported at
https://stackoverflow.com/q/47081274/620382

[Bug c/85696] OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

gcc-bugzilla at zulan dot net changed:

   What|Removed |Added

  Attachment #44085|0   |1
is obsolete||

--- Comment #1 from gcc-bugzilla at zulan dot net ---
Created attachment 44086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44086&action=edit
pologies, wrong gcc version. The error of 8.1.0 is exactly the same though.

[Bug c/85696] OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

--- Comment #2 from gcc-bugzilla at zulan dot net ---
Created attachment 44087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44087&action=edit
minimal example

[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list

[gcc-bugzilla at zulan dot net]

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

gcc-bugzilla at zulan dot net changed:

   What|Removed |Added

 CC||gcc-bugzilla at zulan dot net

--- Comment #12 from gcc-bugzilla at zulan dot net ---
This shows the same error (tested with gcc 6.1.1):

#include

template
void foo(T bar) {
constexpr auto baz = std::array{{1}};
}

int main() {
foo(13);
}

[Bug c++/71173] [6/7 regression] Qualified name lookup

[gcc-bugzilla at zulan dot net]

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

--- Comment #6 from gcc-bugzilla at zulan dot net ---
As far as I can tell it is fixed. Tested with Archlinux "6.1.1" which seems to
be git/1bbd3999).

[Bug libstdc++/110970] New: clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

[gcc-bugzilla at zulan dot net via Gcc-bugs]

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

Bug ID: 110970
   Summary: clang / c++23 missing 'typename' prior to dependent
type name 'iterator_traits<_It>::iterator_category'
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
      Reporter: gcc-bugzilla at zulan dot net
  Target Milestone: ---

Using clang with the current libstdc++ and c++23 (2b) fails:

echo "#include " | clang++ -std=c++2b -stdlib=libstdc++ -c -x c++ -
In file included from :1:
In file included from
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/algorithm:60:
In file included from
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_algobase.h:67:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_iterator.h:2618:35:
error: missing 'typename' prior to dependent type name
'iterator_traits<_It>::iterator_category'
  { using iterator_category = iterator_traits<_It>::iterator_category; };


The line is unchanged in the current git, so I presume this is not fixed yet.

Simply adding `typename` to the line does fix the issue with clang.

This is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900. I won't
try to language lawyer what is technically correct here. In the other issue it
was decided to be nice and support other implementations even though it is a
(very low cost) workaround.

[Bug libstdc++/110970] clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

[gcc-bugzilla at zulan dot net via Gcc-bugs]

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

--- Comment #2 from gcc-bugzilla at zulan dot net ---
Yes, apologies for the missing information

clang version 15.0.7
g++ (GCC) 13.2.1 20230801
(Arch)

According to https://clang.llvm.org/cxx_status.html
P0634R3 / "Down with typename!" is implemented since Clang 16 (released in
March). So maybe this is actually not a problem for much longer. Might only
affect the combination of a very recent GCC with slightly outdated Clang.