[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code

[paboyle at ph dot ed.ac.uk]

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

--- Comment #5 from Peter Boyle  ---
Hi Jakub,

The difference between these two cases (one maintaining the pragma in right
place, 
the other note) suggested a viable work around in the code.

I can eliminate the extra naked_for macro and (with some undesired code
replication)
get a working solution.

However, that doesn't mean it isn't a bug, and it should of course be fixed,  !

Thanks for the pointer - I will make the change to the code to tolerate the
issue,
because GCC is clearly an important target for us.

Best wishes,

Peter

[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code

[paboyle at ph dot ed.ac.uk]

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

--- Comment #4 from Peter Boyle  ---
Hi Jakob, 

thanks for looking at this.

I'm trying to cut down a fail in 100k line of code package to the minimal thing
that I can submit.

www.github.com/paboyle/Grid

Is the original package;

WITH -fopenmp the following larger example still fails

#define DO_PRAGMA_(x) _Pragma (#x)
#define DO_PRAGMA(x) DO_PRAGMA_(x)
#define thread_num(a) omp_get_thread_num()
#define thread_max(a) omp_get_max_threads()

#define naked_for(i,num,...) for ( uint64_t i=0;i
inline void blockProject(Lattice > &coarseData,
 const Lattice   &fineData,
 const std::vector > &Basis)
{
  GridBase * fine  = fineData.Grid();
  GridBase * coarse= coarseData.Grid();
  int  _ndimension = coarse->_ndimension;

  // checks
  assert( nbasis == Basis.size() );
  subdivides(coarse,fine); 
  for(int i=0;i_rdimensions[d] / coarse->_rdimensions[d];
assert(block_r[d]*coarse->_rdimensions[d] == fine->_rdimensions[d]);
  }

  coarseData=Zero();

  auto fineData_   = fineData.View();
  auto coarseData_ = coarseData.View();
  // Loop over coars parallel, and then loop over fine associated with coarse.
  thread_for( sf, fine->oSites(), {
int sc;
Coordinate coor_c(_ndimension);
Coordinate coor_f(_ndimension);
Lexicographic::CoorFromIndex(coor_f,sf,fine->_rdimensions);
for(int d=0;d<_ndimension;d++) coor_c[d]=coor_f[d]/block_r[d];
Lexicographic::IndexFromCoor(coor_c,sc,coarse->_rdimensions);

thread_critical {
  for(int i=0;i"
# 1 ""
# 1 "tmp.cc"
# 19 "tmp.cc"
template
inline void blockProject(Lattice > &coarseData,
const Lattice &fineData,
const std::vector > &Basis)
{
  GridBase * fine = fineData.Grid();
  GridBase * coarse= coarseData.Grid();
  int _ndimension = coarse->_ndimension;

  assert( nbasis == Basis.size() );
  subdivides(coarse,fine);
  for(int i=0;i_rdimensions[d] / coarse->_rdimensions[d];
assert(block_r[d]*coarse->_rdimensions[d] == fine->_rdimensions[d]);
  }

  coarseData=Zero();

  auto fineData_ = fineData.View();
  auto coarseData_ = coarseData.View();


# 61 "tmp.cc"

# 61 "tmp.cc"
#pragma omp parallel for schedule(static)
# 47 "tmp.cc"
# 61 "tmp.cc"

# 61 "tmp.cc"
#pragma omp critical
# 55 "tmp.cc"
# 47 "tmp.cc"
  for ( uint64_t sf=0;sfoSites();sf++) { {{ int sc; Coordinate
coor_c(_ndimension); Coordinate coor_f(_ndimension);
Lexicographic::CoorFromIndex(coor_f,sf,fine->_rdimensions); for(int
d=0;d<_ndimension;d++) coor_c[d]=coor_f[d]/block_r[d];
Lexicographic::IndexFromCoor(coor_c,sc,coarse->_rdimensions); { for(int
i=0;i

[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code

[paboyle at ph dot ed.ac.uk]

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

--- Comment #2 from Peter Boyle  ---
GCC preprocessor moves location of _Pragma operator in sequence in a variadic
macro:
Simpler case:

#define thread_for( i, num, ... )  for ( uint64_t i=0;i"
# 1 ""
# 1 "tmp.cc"

#pragma omp critical
# 3 "tmp.cc"
for ( uint64_t i=0;i" 1
# 1 "" 3
# 374 "" 3
# 1 "" 1
# 1 "" 2
# 1 "tmp.cc" 2

for ( uint64_t i=0;i

[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code

[paboyle at ph dot ed.ac.uk]

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

--- Comment #1 from Peter Boyle  ---
Also occurs on 7.4.0, 8.3.0

gcc-7 (Homebrew GCC 7.4.0_2) 7.4.0
gcc-8 (Homebrew GCC 8.3.0) 8.3.0

[Bug preprocessor/91517] New: Pragma expansion in variadic macro reorders pragmas and breaks code

[paboyle at ph dot ed.ac.uk]

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

Bug ID: 91517
   Summary: Pragma expansion in variadic macro reorders pragmas
and breaks code
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paboyle at ph dot ed.ac.uk
  Target Milestone: ---

Pragma expansion in variadic macro reorders pragmas and breaks code

Simple test code 

#define DO_PRAGMA(x) DO_PRAGMA_(x)
#define DO_PRAGMA_(x) _Pragma (#x)
#define thread_for( i, num, ... )  DO_PRAGMA(omp parallel for schedule(static))
for ( uint64_t i=0;i"
# 1 ""
# 1 "tmp.cc"
#pragma omp critical
# 8 "tmp.cc"
#pragma omp parallel for schedule(static)
# 8 "tmp.cc"
 for ( uint64_t i=0;i" 1
# 1 "" 3
# 374 "" 3
# 1 "" 1
# 1 "" 2
# 1 "tmp.cc" 2
#pragma omp parallel for schedule(static)
# 8 "tmp.cc"
 for ( uint64_t i=0;i

[Bug tree-optimization/80652] [5 Regression] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

--- Comment #6 from Peter Boyle  ---
Just a comment -- suggest a warning thrown if union access from
two views is made. AFAIK g++ is the only compiler not implementing the
defacto type pun use.

http://en.cppreference.com/w/cpp/language/union

"Many compilers implement, as a non-standard language extension, the ability to
read inactive members of a union."

i.e. warn on attempted use of the above behaviour.

[Bug tree-optimization/80652] [5 Regression] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

Peter Boyle  changed:

   What|Removed |Added

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

--- Comment #5 from Peter Boyle  ---
Withdrawing bug report. 

I think this is my misunderstanding of union guarantees in C++ vs C.

I have my own views on the standards committee, but this is not a G++ bug.

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

--- Comment #7 from Peter Boyle  ---
Signature of fail in 8.0.0 (head) is:

  ^~~~
prog.cc: In substitution of 'template Container(arg.data[0]))> function(const Container&) [with int N = 1;
obj = ]':
prog.cc:43:101:   recursively required by substitution of 'template Container(arg.data[0]))> function(const
Container&) [with int N = 1; obj = ]'
prog.cc:43:101:   required by substitution of 'template
Container(arg.data[0]))> function(const Container&)
[with int N = 1; obj = ]'
prog.cc:45:33:   required from 'Container(arg.data[0]))>
function(const Container&) [with int N = 1; obj =
Recursive > >]'
prog.cc:58:26:   required from here
prog.cc:43:101: fatal error: template instantiation depth exceeds maximum of
900 (use -ftemplate-depth= to increase the maximum)
 template auto function(const Container & arg)->
Container(arg.data[0]))>
   
  ~~~^
compilation terminated.

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

--- Comment #6 from Peter Boyle  ---
Just an update:
Still fails in G++ 7.1.0 and in 8.0.0 (head) on Wandbox.
Still passes in Clang 4.0.0 and 5.0.0(head).

[Bug c++/80652] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

--- Comment #3 from Peter Boyle  ---
Can confirm (5.4) that -O2 also fails, 
   -O1 passes.

[Bug c++/80652] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

--- Comment #2 from Peter Boyle  ---
Thanks for the quick response. Hope this more complete info is helpful.

Should give (1,0) but does give (0,0) under G++ 5.0-6.2 under -O3.

peterboyle$ g++-mp-5 --version
g++-mp-5 (MacPorts gcc5 5.4.0_0) 5.4.0

Under -O3: I THINK THIS IS WRONG AND A COMPILER ERROR

c010200:~ peterboyle$ g++-mp-5 Gcc-test.cc -std=c++11 -O3 
c010200:~ peterboyle$ ./a.out 
(0,0) 

c010200:~ peterboyle$ g++-mp-5 Gcc-test.cc -std=c++11 
c010200:~ peterboyle$ ./a.out 
(1,0) 

Under g++4.9
c010200:~ peterboyle$ g++-4.9 Gcc-test.cc -std=c++11 -O3 
c010200:~ peterboyle$ ./a.out 
(1,0) 

Under llvm xcode
c010200:~ peterboyle$ g++ Gcc-test.cc -std=c++11 -O3 
c010200:~ peterboyle$ ./a.out 
(1,0) 

I also used wandbox to to test many versions, and filed an issue
on my own codebase where I first hit it (prior to small example reduction).

Here is my issue report: https://github.com/paboyle/Grid/issues/100



https://wandbox.org/permlink/tzssJza6R9XnqANw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80652

Getting Travis fails under gcc-5 for Test_simd, now that I added more
comprehensive testing to the
CI test suite. The limitations of Travis runtime limits & weak cores are being
shown.

Travis uses 5.4.1 for g++-5.

We are going to move to a new CI server we bought for the purpose soon.

Working (-) Broken (X):
4.9.0 -
4.9.1 -
5.1.0 X
5.2.0 X
5.3.0 X
5.4.0 X
6.1.0 X
6.2.0 X
6.3.0 -
7.1.0 -
8.0.0 (HEAD) -

Clang 3.5 through 5.0 are good on this test.

Options:
a) Drop to -O2 under broken G++ versions
b) Refuse to build with broken G++ versions.

Opinions sought.

Attempting to work around with

#if (GNUC == 5 ) || ( ( GNUC == 6 ) && GNUC_MINOR < 3 )
#pragma GCC push_options
#pragma GCC optimize ("O0")
#endif

and same to pop options around the SimdApply in Grid_vector_types.

But, I now have very, very, VERY poor confidence in these compiler versions.

e.g. Where else do we hit this? It is dangerous to not apply this globally
(which we could force) but that will cripple performance.

Do we unsupport a whole swathe of G++ versions?

I posted on stack overflow to try to get a double check on the legality of the
union use.

http://stackoverflow.com/questions/2906365/gcc-strict-aliasing-and-casting-through-a-union/43820916#43820916

But, I think this is legal code.

[Bug c++/80652] New: Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

Bug ID: 80652
   Summary: Union conversion between __m128d and double array does
not work under 5.0 through 6.2
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paboyle at ph dot ed.ac.uk
  Target Milestone: ---

Union conversion between __m128d and double array does not work under 
-O3 for g++ versions 5.0 to 6.2. Compiled with -std=c++11 -O3 .

https://wandbox.org/permlink/tzssJza6R9XnqANw

Code:

#include 
#include 
#include 

template 
class simd {
 public:
  typedef Vector_type vector_type;
  typedef Scalar_type scalar_type;
  typedef union conv_t_union {
Vector_type v;
Scalar_type s[sizeof(Vector_type) / sizeof(Scalar_type)];
conv_t_union(){};
  } conv_t;

  static inline constexpr int Nsimd(void) {
return sizeof(Vector_type) / sizeof(Scalar_type);
  }

  Vector_type v;

  template 
  friend inline simd SimdApply(const functor &func, const simd &v) {
simd ret;
simd::conv_t conv;

conv.v = v.v;
for (int i = 0; i < simd::Nsimd(); i++) {
  conv.s[i] = func(conv.s[i]);
}
ret.v = conv.v;
return ret;
  }

};

template 
struct RealFunctor {
  scalar operator()(const scalar &a) const {
return std::real(a);
  }
};

template 
inline simd real(const simd &r) {
  return SimdApply(RealFunctor(), r);
}

typedef simd, __m128d> vcomplexd;

int main(int argc, char **argv)
{
  vcomplexd a,b;
  a.v=_mm_set_pd(2.0,1.0);
  b = real(a);

  vcomplexd::conv_t conv;
  conv.v = b.v;
  for(int i=0;i

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

Peter Boyle  changed:

   What|Removed |Added

Version|5.1.0   |6.0

--- Comment #4 from Peter Boyle  ---
Also fails in HEAD

prog.cc:53:14: warning: unused parameter 'argc' [-Wunused-parameter]
 int main(int argc,char **argv)
  ^
prog.cc:53:26: warning: unused parameter 'argv' [-Wunused-parameter]
 int main(int argc,char **argv)
  ^
'
Internal compiler error: Error reporting routines re-entered.
0x5ccf96 push_tinst_level_loc(tree_node*, unsigned int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:8464
0x5e8409 push_tinst_level(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:8448
0x5e8409 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16238
0x5a5be9 add_template_candidate_real
/home/heads/gcc/gcc-source/gcc/cp/call.c:3057
0x5a626c add_template_candidate
/home/heads/gcc/gcc-source/gcc/cp/call.c:3154
0x5a626c add_candidates
/home/heads/gcc/gcc-source/gcc/cp/call.c:5281
0x5a8843 perform_overload_resolution
/home/heads/gcc/gcc-source/gcc/cp/call.c:3999
0x5a9d0a build_new_function_call(tree_node*, vec**, bool, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:4076
0x67114a finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/heads/gcc/gcc-source/gcc/cp/semantics.c:2410
0x5d478d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15201
0x5d5308 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:12512
0x60dd50 dump_template_bindings
/home/heads/gcc/gcc-source/gcc/cp/error.c:369
0x60dd50 dump_substitution
/home/heads/gcc/gcc-source/gcc/cp/error.c:1448
0x60f866 decl_to_string
/home/heads/gcc/gcc-source/gcc/cp/error.c:2910
0x60f866 cp_printer
/home/heads/gcc/gcc-source/gcc/cp/error.c:3491
0xfd6a10 pp_format(pretty_printer*, text_info*)
/home/heads/gcc/gcc-source/gcc/pretty-print.c:613
0xfd7780 pp_format_verbatim(pretty_printer*, text_info*)
/home/heads/gcc/gcc-source/gcc/pretty-print.c:672
0xfd7854 pp_verbatim(pretty_printer*, char const*, ...)
/home/heads/gcc/gcc-source/gcc/pretty-print.c:873
0x609eda print_instantiation_partial_context_line
/home/heads/gcc/gcc-source/gcc/cp/error.c:3290
0x609eda print_instantiation_partial_context
/home/heads/gcc/gcc-source/gcc/cp/error.c:3400
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++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

--- Comment #3 from Peter Boyle  ---
http://stackoverflow.com/questions/30411079/counting-template-recursion-nest-depth

Appears to affect all versions of g++ with various errors.

Used:
http://melpon.org/wandbox/permlink/eK2AVfZXXss0ZDu6

All versions of clang after 3.1 accept the code.

Disambiguating "function(Container)" from function
manually by renaming function(Container) to ffunction(Container) makes it
operate in the same way as ICPC and Clang.

However, this should not have been necessary because substitution failure
should have caused it to select the right "function" in every case 

At least, I believe it should work as original, clang believes and icpc
believes, but g++ does not.

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

--- Comment #2 from Peter Boyle  ---
p.s. in case anyone is wondering this recursive construct is 
a simplification of a construct I'm using in an expression
template framework, so this is not simply a convoluted test case.

Rather, I distilled the fail down to a small case from a much larger code.

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

--- Comment #1 from Peter Boyle  ---
Created attachment 35547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35547&action=edit
unprocessed source code.

[Bug c++/66153] New: Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

Bug ID: 66153
   Summary: Internal compiler error in nested template function
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paboyle at ph dot ed.ac.uk
  Target Milestone: ---

Created attachment 35543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35543&action=edit
Preprocessed source

Peters-MacBook-Pro:gcc5_debug pab$ g++-5 -std=c++11 broken.cc -o broken
'
Internal compiler error: Error reporting routines re-entered.

broken.cc: In substitution of 'template Container(arg.data[0]))> function(const Container&) [with int N = 1;
obj = ]':
broken.cc:43:101:   recursively required by substitution of 'template Container(arg.data[0]))> function(const
Container&) [with int N = 1; obj = ]'
broken.cc:43:101:   required by substitution of 'template
Container(arg.data[0]))> function(const Container&)
[with int N = 1; obj = ]'
broken.cc:45:33:   Abort trap: 6
 template auto function(const Container & arg)->
Container(arg.data[0]))>
   
 ^
g++-5: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/Homebrew/homebrew-versions/issues> for instructions.

==
#include 
#include 
#include 
#include 

typedef std::complex ComplexD;

template  class TypeMapper {
public:
  enum { NestLevel = T::NestLevel };
};

template<> class TypeMapper {
public:
  enum { NestLevel = 0 };
};

template class Container {
 public:
  std::vector data;
  Container(int size) : data (size){};
};

template class Recursive {
public:
  enum { NestLevel = TypeMapper::NestLevel + 1};
  obj internal;
};

template::type * =
nullptr > auto function(const obj &arg)-> obj
{
  std::cout<<"Leaf "<::type * =
nullptr > auto function(const obj &arg)-> obj
{
  std::cout<<"Node "<(arg.internal);
  return ret;
}

template auto function(const Container & arg)->
Container(arg.data[0]))>
{
  Container(arg.data[0]))> ret(arg.data.size());
  for(int ss=0;ss(arg.data[ss]);
  }
  return ret;
}


int main(int argc,char **argv)
{
  Container > > array(10);
  Container > > ret(10);

  ret = function<1>(array);
}
==

For reference, works on Intel 15, Clang++ multiple versions.

Peters-MacBook-Pro:gcc5_debug pab$ icpc -std=c++11 broken.cc -o broken
Peters-MacBook-Pro:gcc5_debug pab$ clang++  -std=c++11 broken.cc -o broken
Peters-MacBook-Pro:gcc5_debug pab$ clang++ --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
Peters-MacBook-Pro:gcc5_debug pab$ icpc --version
icpc (ICC) 15.0.3 20150408
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Output with both icpc and clang++ is:

Peters-MacBook-Pro:gcc5_debug pab$ ./broken 
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1
Node 2
Leaf 1