[Bug tree-optimization/88666] New: GCC 8.2.- gets Internal Compiler Error: seg fault; GCC 8.1.0 works fine

[geir at cray dot com]

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

Bug ID: 88666
   Summary: GCC 8.2.- gets Internal Compiler Error: seg fault;
GCC 8.1.0 works fine
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com
  Target Milestone: ---

Simple reproducer code causes a seg fault during compile with gcc 8.2.0. The
reproducer does not seg fault for gcc 8.1.0

$ cat repro.c
#include 
#include 
#include 
#include 

int64_t foo (int64_t max, FILE *in)

{
  int64_t count = 0;
  const int64_t MAXLINE  = 1024;
  char buff[MAXLINE];

  while (!feof(in) && count < max) {
if (fgets(buff, sizeof(buff), in) != NULL) {

  // gcc 8.2 segfaults !!
  if (strncmp (&buff[0], "QUIT", 4) == 0)
break;

  // this is OK:
  if (strncmp (buff, "QUIT", 4) == 0)
break;

}
  }

  return count;
}
$ gcc --version
gcc (GCC) 8.1.0 20180502 (Cray Inc.)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c repro.c
$ module swap gcc/8.1.0 gcc/8.2.0
$ gcc --version
gcc (GCC) 8.2.0 20180726 (Cray Inc.)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c repro.c
during RTL pass: expand
repro.c: In function 'foo':
repro.c:17:11: internal compiler error: Segmentation fault
   if (strncmp (&buff[0], "QUIT", 4) == 0)
   ^
0xa8de4f crash_signal
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/toplev.c:325
0x6eeb25 wi::extended_tree<192>::get_len() const
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/tree.h:5572
0x6eeb25 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:934
0x6eeb25 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:983
0x6eeb25 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:758
0x6eeb25 bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:1849
0x6eeb25 wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
 >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:3170
0x6eeb25 tree_int_cst_lt(tree_node const*, tree_node const*)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/tree.h:5728
0x6eeb25 maybe_warn_nonstring_arg(tree_node*, tree_node*)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/calls.c:1716
0x6f053a maybe_warn_nonstring_arg(tree_node*, tree_node*)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/calls.c:1627
0x6f053a initialize_argument_information
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/calls.c:2321
0x6f053a expand_call(tree_node*, rtx_def*, int)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/calls.c:3713
0x6e4286 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/builtins.c:6656
0x7f1679 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/expr.c:11005
0x7fa35b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/expr.c:5635
0x7fb5b3 expand_assignment(tree_node*, tree_node*, bool)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/expr.c:5403
0x7015d8 expand_call_stmt
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/cfgexpand.c:2688
0x7015d8 expand_gimple_stmt_1
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/cfgexpand.c:3624
0x7015d8 expand_gimple_stmt
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/cfgexpand.c:3790
0x70287f expand_gimple_basic_block
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/cfgexpand.c:5819
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$

[Bug tree-optimization/83440] Internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:8692

[geir at cray dot com]

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

--- Comment #2 from Geir Johansen  ---
Created attachment 42906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42906&action=edit
thr.i

[Bug tree-optimization/83440] New: Internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:8692

[geir at cray dot com]

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

Bug ID: 83440
   Summary: Internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:8692
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com
  Target Milestone: ---

At -O3 optimization (and 'march=corei7-avx') getting an ICE with the attached
test case.  Works OK with -O2.



$ g++ --version   
g++ (GCC) 7.2.0 20170814 (Cray Inc.) 
Copyright (C) 2017 Free Software Foundation, Inc. 
This is free software; see the source for copying conditions.  There is NO 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 
$ g++ -march=corei7-avx -c -std=c++17 -O2 thr.i 
$ g++ -march=corei7-avx -c -std=c++17 -O3 thr.i 
In file included from
/opt/gcc/7.2.0/snos/include/g++/bits/shared_ptr_atomic.h:33:0,
 from /opt/gcc/7.2.0/snos/include/g++/memory:82,
 from /opt/gcc/7.2.0/snos/include/g++/functional:4375,
 from
/opt/gcc/7.2.0/snos/lib/gcc/x86_64-suse-linux/7.2.0/include-fixed/limits.h:746,
 from /opt/gcc/7.2.0/snos/include/g++/cstdlib:2310,
 from
/opt/gcc/7.2.0/snos/include/g++/bits/stream_iterator.h:3060,
 from /opt/gcc/7.2.0/snos/include/g++/istream:993,
 from /opt/gcc/7.2.0/snos/include/g++/bits/basic_ios.h:519,
 from
/opt/gcc/7.2.0/snos/include/g++/x86_64-suse-linux/bits/ctype_base.h:73,
 from /opt/gcc/7.2.0/snos/include/g++/streambuf:850,
 from /opt/gcc/7.2.0/snos/include/g++/bits/ios_base.h:1079,
 from
/opt/gcc/7.2.0/snos/include/g++/bits/locale_classes.h:857,
 from
/opt/gcc/7.2.0/snos/include/g++/ext/string_conversions.h:166,
 from /opt/gcc/7.2.0/snos/include/g++/bits/basic_string.h:6159,
 from /opt/gcc/7.2.0/snos/include/g++/string:52,
 from /opt/gcc/7.2.0/snos/include/g++/bits/locale_classes.h:40,
 from /opt/gcc/7.2.0/snos/include/g++/bits/ios_base.h:41,
 from /opt/gcc/7.2.0/snos/include/g++/ios:42,
 from /opt/gcc/7.2.0/snos/include/g++/istream:38,
 from
/opt/gcc/7.2.0/snos/lib/gcc/x86_64-suse-linux/7.2.0/include/stddef.h:943,
 from /opt/gcc/7.2.0/snos/include/g++/cstddef:1218,
 from /opt/gcc/7.2.0/snos/include/g++/vector:69,
 from thr.cpp:1:
/opt/gcc/7.2.0/snos/include/g++/backward/auto_ptr.h: In function 'void
thrust::system::detail::sequential::radix_sort_detail::radix_sort(thrust::system::detail::sequential::execution_policy&,
RandomAccessIterator1, RandomAccessIterator2, RandomAccessIterator3,
RandomAccessIterator4, size_t) [with unsigned int RadixBits = 8; bool HasValues
= true; DerivedPolicy = thrust::system::cpp::detail::par_t;
RandomAccessIterator1 = thrust::detail::normal_iterator
>; RandomAccessIterator2 = thrust::detail::normal_iterator
>; RandomAccessIterator3 =
thrust::zip_iterator > >, thrust::detail::normal_iterator > > > >; RandomAccessIterator4 =
thrust::detail::normal_iterator, thrust::tuple >, thrust::system::cpp::detail::par_t,
thrust::use_default, thrust::use_default> >]':
/opt/gcc/7.2.0/snos/include/g++/backward/auto_ptr.h:12660:6: internal compiler
error: in vect_transform_stmt, at tree-vect-stmts.c:8692
0xd01186 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
   
../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/gcc/tree-vect-stmts.c:8692
0xd1a6ca vect_schedule_slp_instance
   
../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/gcc/tree-vect-slp.c:3712
0xd1a44d vect_schedule_slp_instance
   
../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/gcc/tree-vect-slp.c:3590
0xd1d845 vect_schedule_slp(vec_info*)
   
../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/gcc/tree-vect-slp.c:3783
0xd05333 vect_transform_loop(_loop_vec_info*)
   
../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/gcc/tree-vect-loop.c:7054
0xd2179b vectorize_loops()
   
../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/gcc/tree-vectorizer.c:687
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$

[Bug libgomp/55691] Setting OMP_NESTED increases the runtime dramatically for GCC compiled executable

[geir at cray dot com]

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

Geir Johansen  changed:

   What|Removed |Added

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

--- Comment #5 from Geir Johansen  ---
I find the GCC 4.8 no longer has this issue.

[Bug preprocessor/69869] New: internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[geir at cray dot com]

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

Bug ID: 69869
   Summary: internal compiler error: Segmentation fault in call to
skip_macro_block_comment when using '-traditional-cpp'
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com
  Target Milestone: ---

The following test case fails in all versions of GCC I tried (4.7.3 through
5.3,0)


$ gcc --version
gcc (GCC) 5.3.0 20151204 (Cray Inc.)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat test.c
#define Concat2(a,b)a/**/b

all:
$(RM)  Concat2(./bin/,*)
$ gcc -E -traditional-cpp test.c >/dev/null
test.c:1:0: internal compiler error: Segmentation fault
 #define Concat2(a,b)a/**/b
 ^
0xa1c58f crash_signal
../../cray-gcc-5.3.0/gcc/toplev.c:383
0x1002b30 skip_macro_block_comment
../../cray-gcc-5.3.0/libcpp/traditional.c:129
0x1002b30 copy_comment
../../cray-gcc-5.3.0/libcpp/traditional.c:161
0x100336e _cpp_scan_out_logical_line
../../cray-gcc-5.3.0/libcpp/traditional.c:489
0x1003fcb _cpp_read_logical_line_trad
../../cray-gcc-5.3.0/libcpp/traditional.c:310
0x6bbe77 scan_translation_unit_trad
../../cray-gcc-5.3.0/gcc/c-family/c-ppoutput.c:326
0x6bbe77 preprocess_file(cpp_reader*)
../../cray-gcc-5.3.0/gcc/c-family/c-ppoutput.c:108
0x6ba6f0 c_common_init()
../../cray-gcc-5.3.0/gcc/c-family/c-opts.c:1033
0x62e9cc lang_dependent_init
../../cray-gcc-5.3.0/gcc/toplev.c:1836
0x62e9cc do_compile
../../cray-gcc-5.3.0/gcc/toplev.c:2053
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$

[Bug debug/60812] gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted

[geir at cray dot com]

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

--- Comment #2 from Geir Johansen  ---
(In reply to Jakub Jelinek from comment #1)
> You haven't said which target it is, and we need preprocessed source as well.
> Couldn't reproduce this on x86_64-linux.

Problem does not occur in GCC 4.9.0, so this bug can be closed.

[Bug target/68261] GCC needs to use optimized version of memcpy

[geir at cray dot com]

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

--- Comment #6 from Geir Johansen  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Geir Johansen from comment #4)
> > (In reply to Andrew Pinski from comment #1)
> > > Note glibc does provide a memcpy which is optimized for each target via
> > > ifuncs. What version of glibc are you running.
> > 
> > 2.11.3
> 
> That is a very old release which was released before most of the modern
> v2/v3 were relased so no wonder you are having performance issues.

Okay, tried GLIBC 2.19 and that version appears to have addressed the issue.

[Bug target/68261] GCC needs to use optimized version of memcpy

[geir at cray dot com]

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

--- Comment #4 from Geir Johansen  ---
(In reply to Andrew Pinski from comment #1)
> Note glibc does provide a memcpy which is optimized for each target via
> ifuncs. What version of glibc are you running.

2.11.3

[Bug target/68261] New: GCC needs to use optimized version of memcpy

[geir at cray dot com]

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

Bug ID: 68261
   Summary: GCC needs to use optimized version of memcpy
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com
  Target Milestone: ---

The memcpy routine for GCC needs to be faster.  The following test case shows
that the Intel compiler implementation of memcpy is over twice as fast as GCC. 
I realize that memcpy is a part of GLIBC, but the GCC compiler should take
advantage of the targetting information being provided and the context of the
memcpy in order to provide more optimal code:

$ cat test_memcpy.cpp 
#include   
#include  
#include 
#include

extern "C" void memcpy_custom(double* out, double* in, int length);

int main(int argn, char** argv)
{  
int repeat = 200;  
int N = (1 << 20); 
std::vector inp(N, 1);
std::vector out(N, 2);

double t = -omp_get_wtime();
if (argn == 1)  
{   
for (int i = 0; i < repeat; i++)
{   
memcpy(&out[0], &inp[0], N * sizeof(double));
}
}
else 
{
for (int i = 0; i < repeat; i++) 
{
memcpy_custom(&out[0], &inp[0], N);  
}
}
t += omp_get_wtime();

printf("performance: %.4f MB/sec.\n", repeat * N * sizeof(double) / t / (1
<< 20)); 
}   
$ cat memcpy_custom.cpp
extern "C" void memcpy_custom(double* out, double* in, int length)  
{   
for (int i = 0; i < length; i++) out[i] = in[i];
} 
$

  GCC g++ performance:

$ g++ --version
g++ (GCC) 5.1.0 20150422 (Cray Inc.)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -march=corei7-avx -o gcc.out -O3 -fopenmp memcpy_custom.cpp
test_memcpy.cpp
$  ./gcc.out
performance: 6977.5857 MB/sec.
$


 Intel icpc performance:

$ icpc --version
icpc (ICC) 15.0.3 20150407
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

$ icpc -mavx -o intel.out -O3 -qopenmp memcpy_custom.cpp test_memcpy.cpp
$ ./intel.out   
performance: 13055.0563 MB/sec.
$


Performance of GCC can be improved by implementing a simple "custom"
version of memcpy:

$ ./gcc.out 1   
performance: 11619.4630 MB/sec. 
$ ./intel.out 1 
performance: 13068.3777 MB/sec. 
$

[Bug libgomp/64719] New: omp_get_num_procs should not account for cpu affinity

[geir at cray dot com]

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

Bug ID: 64719
   Summary: omp_get_num_procs should not account for cpu affinity
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com
CC: jakub at gcc dot gnu.org

Created attachment 34525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34525&action=edit
omp.c

The description for the routine omp_get_num_procs is stated as:

  Returns the number of processors online on that device. 

The GCC implementation behavior of omp_get_num_procs does not follow this
description, but rather does the following:

  Returns the number of processors that have affinity to the calling
process/thread.

The Cray and PGI versions of omp_get_num_procs will return the actual number of
processors available on the device without regard to affinity. [I suppose there
could be some interpretation what is meant by the term "online", but then this
should be further explained in the description of omp_get_num_procs.]


Our job launcher will set affinity to optimize performance of parallel programs
(MPI, SHMEM, Gloab Arrays, UPC, Coarray Fortran, ...).  In the following
example two processes that have three OpenMP threads are being invoked:

  GCC compiled program:

$ export OMP_NUM_THREADS=3
$ aprun -n 2 -d 3 ./omp.gcc
Sysconf get nprocs reports  24 processors
Sysconf get nprocs reports  24 processors
Hello from pid 14544, thread 0 (core affinity = 0) (Available OpenMP processors
= 1)
Hello from pid 14544, thread 2 (core affinity = 2) (Available OpenMP processors
= 1)
Hello from pid 14544, thread 1 (core affinity = 1) (Available OpenMP processors
= 1)
Hello from pid 14545, thread 0 (core affinity = 3) (Available OpenMP processors
= 1)
Hello from pid 14545, thread 2 (core affinity = 5) (Available OpenMP processors
= 1)
Hello from pid 14545, thread 1 (core affinity = 4) (Available OpenMP processors
= 1)
$


  Cray compiler compiled program:

$ export OMP_NUM_THREADS=3
$ aprun -n 2 -d 3 ./omp.cray
Sysconf get nprocs reports  24 processors
Sysconf get nprocs reports  24 processors
Hello from pid 14620, thread 2 (core affinity = 2) (Available OpenMP processors
= 24)
Hello from pid 14620, thread 0 (core affinity = 0) (Available OpenMP processors
= 24)
Hello from pid 14620, thread 1 (core affinity = 1) (Available OpenMP processors
= 24)
Hello from pid 14621, thread 0 (core affinity = 3) (Available OpenMP processors
= 24)
Hello from pid 14621, thread 2 (core affinity = 5) (Available OpenMP processors
= 24)
Hello from pid 14621, thread 1 (core affinity = 4) (Available OpenMP processors
= 24)
$

   Here is the GCC compiled version with CPU affinity turned off:

$ aprun -cc none -n 2 -d 3 ./omp.gcc
Sysconf get nprocs reports  24 processors
Sysconf get nprocs reports  24 processors
Hello from pid 15044, thread 1 (core affinity = 0-23) (Available OpenMP
processors = 24)
Hello from pid 15044, thread 2 (core affinity = 0-23) (Available OpenMP
processors = 24)
Hello from pid 15044, thread 0 (core affinity = 0-23) (Available OpenMP
processors = 24)
Hello from pid 15045, thread 2 (core affinity = 0-23) (Available OpenMP
processors = 24)
Hello from pid 15045, thread 0 (core affinity = 0-23) (Available OpenMP
processors = 24)
Hello from pid 15045, thread 1 (core affinity = 0-23) (Available OpenMP
processors = 24)
$

--

I realize that this bug will very likely be closed as INVALID or WONTFIX, but
the documentation needs to be fixed to make clear the behavior of
omp_get_num_procs.

[Bug middle-end/61781] Overflow of signed integer causing incorrect execution of a program

[geir at cray dot com]

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

--- Comment #2 from Geir Johansen  ---
Longer version of the test case, along with notes from the original user.  T


I believe you have an overaggressive optimizer. Which I have turned into the
following somewhat  block of code (simple-instrumented.c):



/**

   Demo for a gcc 4.8.1 bug

   Built with:  gcc -O3 -std=c99 simple-instrumented.c
*/

#include 
#include 

#ifdef myrand_unsigned
unsigned long myrand (unsigned long x)
#else
long myrand( long x )
#endif
{
#ifdef myrand_constants_ul
   unsigned long c = 6824061905351802757UL;  // prime
   unsigned long d = 5001297291839117257UL;  // prime, p - 1 divisible by 4
#else
   long c = 6824061905351802757L;  // prime
   long d = 5001297291839117257L;  // prime, p - 1 divisible by 4
#endif

#ifdef printf_sub_start
   printf(" x-ss: 0x%016ld\n", x);
#endif

#ifdef simpler
   x = d*x;
#else
   x = d*x + c;
#endif

#ifdef printf_sub_end
   printf(" x-se: 0x%016ld\n", x);
#endif

   return( x );
}


int main( int argc, char *argv[] ) {
#ifdef unsigned_loop
   unsigned long x;
#else
   long x;
#endif
   long len;
   long count = 0;

   x = 1;
   len = 1e2;

   if( argc > 1 ) {
 len = atof( argv[1] ) + 0.5;
   }
   if( argc > 2 ) {
 x = strtol( argv[2], 0, 0 );
   }

   printf("len = %ld, seed = 0x%016lx\n", len, x);

#ifdef unsigned_loop
   for(unsigned long i=0; i

[Bug middle-end/61781] New: Overflow of signed integer causing incorrect execution of a program

[geir at cray dot com]

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

Bug ID: 61781
   Summary: Overflow of signed integer causing incorrect execution
of a program
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com

User identified a test case that may indicate an over aggressive optimizer. In
the following test case, compiler with '-O1' will result in correct execution,
while compiling with '-O2' and above results in incorrect behavior.

Here is the short version of the test case.  Duplicated bug with 4.8.[012] and
4.9.0 compilers:

$ cat simple.c
#include   
#include  

long myrand( long x )
{
   long c = 6824061905351802757L;  // prime
   long d = 5001297291839117257L;  // prime, p - 1 divisible by 4

   x = d*x + c;
   return( x );
}

int main( int argc, char *argv[] ) {
   long x, len;
   long count = 0;

   x = 1;
   len = 1e2;

   if( argc > 1 ) {
 len = atof( argv[1] ) + 0.5;
   }
   if( argc > 2 ) {
 x = strtol( argv[2], 0, 0 );
   }

   printf("len = %ld, seed = 0x%016lx\n", len, x);

   for( long i=0; i

[Bug debug/60812] New: gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60812

Bug ID: 60812
   Summary: gcc -g -gpubnames statically linked produces a
.debug_pubnames that is wrong or corrupted
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com

gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or
corrupted:

$ gcc --version
gcc (GCC) 4.8.2 20131016 (Cray Inc.)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat getpid.c
#include 

int main() {
return getpid();
}
$ gcc -c -g -gpubnames getpid.c
$ gcc -o getpid getpid.o -static
$ readelf -wp getpid
Contents of the .debug_pubnames section:

  Length:  33
  Version: 2
  Offset into .debug_info section: 0x77
  Size of area in .debug_info section: 139

Offset  Name
6f  _IO_stdin_used
  Length:  7091
  Version: 2
  Offset into .debug_info section: 0x102
  Size of area in .debug_info section: 145

Offset  Name
73  main
readelf: Warning: .debug_info offset of 0x6e65706f in .debug_pubnames section
does not point to a CU header.
readelf: Warning: Only DWARF 2 and 3 pubnames are currently supported

$


   The .debug_pubnames section of the getpid.o object file is fine:

$ readelf -wp getpid.o
Contents of the .debug_pubnames section:

  Length:  7091
  Version: 2
  Offset into .debug_info section: 0x0
  Size of area in .debug_info section: 145

Offset  Name
73  main

$


   The .debug_pubnames section of a dynamically linked executable is also fine:

$ gcc -o getpid-dynamic getpid.o
$ readelf -wp getpid-dynamic
Contents of the .debug_pubnames section:

  Length:  33
  Version: 2
  Offset into .debug_info section: 0x77
  Size of area in .debug_info section: 139

Offset  Name
6f  _IO_stdin_used
  Length:  7091
  Version: 2
  Offset into .debug_info section: 0x102
  Size of area in .debug_info section: 145

Offset  Name
73  main

$


Problem is severely impacting the operation of performance analysis tools that
need to use this information.

[Bug libgomp/33720] A negative value in OpenMP clause num_threads is not detected at runtime

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33720

--- Comment #6 from Geir Johansen  ---
Fails in GCC 4.8.0:

$ gcc --version
gcc (GCC) 4.8.0 20130322 (Cray Inc.)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -o x -fopenmp bug2883.c -lm
$ ./x
pi   3.1416 n_thread -7

libgomp: Out of memory allocating 481036337712 bytes
$

[Bug c/45784] gcc OpenMP - error: invalid controlling predicate

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45784

--- Comment #2 from Geir Johansen  ---
Fails in GCC 4.8.0:

$ gcc --version
gcc (GCC) 4.8.0 20130322 (Cray Inc.)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c -fopenmp -std=c99 ISU3417.c
ISU3417.c: In function 'vla_test':
ISU3417.c:24:25: error: invalid controlling predicate
 for (ptr = vla; ptr < vla + sizeof(vla)/sizeof(vla[0]);
 ^
$

[Bug c/42979] OpenMP #pragma omp taskwait after a label is not permitted - should fail at compile time

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42979

Geir Johansen  changed:

   What|Removed |Added

  Known to fail||4.7.3

--- Comment #1 from Geir Johansen  2013-05-08 21:57:20 
UTC ---
Problem still fails in 4.7.3:

$ gcc --version
gcc (GCC) 4.7.3 20130411 (Cray Inc.)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -fopenmp ISU3243.c ; ./a.out
ISU3243.c:14: FAIL - negative test case should not compile
$

[Bug c/45784] gcc OpenMP - error: invalid controlling predicate

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45784

Geir Johansen  changed:

   What|Removed |Added

  Known to fail||4.7.3

--- Comment #1 from Geir Johansen  2013-05-08 21:54:55 
UTC ---
Fails in GCC 4.7.3:

$ gcc --version
gcc (GCC) 4.7.3 20130411 (Cray Inc.)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c -fopenmp -std=c99 ISU3417.c
ISU3417.c: In function 'vla_test':
ISU3417.c:23:25: error: invalid controlling predicate
$

[Bug libgomp/55691] Setting OMP_NESTED increases the runtime dramatically for GCC compiled executable

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55691



--- Comment #4 from Geir Johansen  2012-12-14 17:14:56 
UTC ---

Created attachment 28959

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28959

Build instructions

[Bug libgomp/55691] Setting OMP_NESTED increases the runtime dramatically for GCC compiled executable

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55691



--- Comment #3 from Geir Johansen  2012-12-14 17:13:55 
UTC ---

Created attachment 28958

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28958

input data

[Bug libgomp/55691] Setting OMP_NESTED increases the runtime dramatically for GCC compiled executable

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55691



--- Comment #2 from Geir Johansen  2012-12-14 17:12:48 
UTC ---

Created attachment 28957

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28957

program data

[Bug libgomp/55691] Setting OMP_NESTED increases the runtime dramatically for GCC compiled executable

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55691



--- Comment #1 from Geir Johansen  2012-12-14 17:08:53 
UTC ---

Created attachment 28956

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28956

test case

[Bug libgomp/55691] New: Setting OMP_NESTED increases the runtime dramatically for GCC compiled executable

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55691



 Bug #: 55691

   Summary: Setting OMP_NESTED increases the runtime dramatically

for GCC compiled executable

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgomp

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: g...@cray.com

CC: ja...@gcc.gnu.org





The attached test case runs significantly slower when setting OMP_NESTED =

true, compared to setting OMP_NESTED.

[Bug c++/52527] When using '-g', get an ICE: seg fault in add_name_attribute (called by modified_type_die)

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52527

Geir Johansen  changed:

   What|Removed |Added

  Known to work||4.5.3
  Known to fail||4.6.0, 4.6.1, 4.6.2, 4.6.3

--- Comment #1 from Geir Johansen  2012-03-08 21:19:42 
UTC ---
Fails with GCC 4.6.0, 4.6.1, 4.6.2, 4.6.3

Works with GCC 4.5.3

[Bug c++/52527] New: When using '-g', get an ICE: seg fault in add_name_attribute (called by modified_type_die)

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52527

 Bug #: 52527
   Summary: When using '-g', get an ICE: seg fault in
add_name_attribute (called by modified_type_die)
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


Compiling a program that uses the Boost libraries, I see an ICE when using '-g'
option.  Unfortunately (or fortunately) the problem does NOT occur when I
compile a preprocessed version of the code.

$ g++ --version
g++ (GCC) 4.6.2 20111026 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -dH -c -g -O3 -DNDEBUG -DCPU_FREQ=2.8e9 -DHAVE_U1 -DHAVE_TwoU1
-DDISABLE_MATRIX_ELEMENT_ITERATOR_WARNING -DUseTwoU1 -I. -I../../framework
-I../../../../boost_1_47_0 te_nn.cpp 
In file included from ../../framework/dmrg/mp_tensors/mps.hpp:14:0,
 from ../../framework/dmrg/mp_tensors/mps.h:94,
 from te_nn.cpp:28:
../../framework/dmrg/mp_tensors/contractions.h: In static member function
'static block_matrix
contraction::multiply_with_twosite(const block_matrix&,
const block_matrix&, const Index&, const
Index&, const Index&) [with Matrix =
maquis::types::dense_matrix >, SymmGroup = NU1<2>]':
../../framework/dmrg/mp_tensors/contractions.h:778:5: internal compiler error:
Segmentation fault
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$

   Here's the traceback:

(gdb) bt
#0  0x7f21a8ca3945 in raise () from /lib64/libc.so.6
#1  0x7f21a8ca4f21 in abort () from /lib64/libc.so.6
#2  0x0060cf95 in real_abort ()
at ../../xt-gcc-4.6.2/gcc/diagnostic.c:903
#3  diagnostic_action_after_output (context=0x1166d80, 
diagnostic=) at ../../xt-gcc-4.6.2/gcc/diagnostic.c:247
#4  0x0060d13f in diagnostic_report_diagnostic (context=0x1166d80, 
diagnostic=0x7fff3dff2480) at ../../xt-gcc-4.6.2/gcc/diagnostic.c:546
#5  0x0060e020 in internal_error (gmsgid=)
at ../../xt-gcc-4.6.2/gcc/diagnostic.c:839
#6  0x007bbbd0 in crash_signal (signo=11)
at ../../xt-gcc-4.6.2/gcc/toplev.c:359
#7  
#8  0x0062842e in add_name_attribute (die=0x7f218b75d8c0, 
name_string=0x13 )
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:17435
#9  0x006356c8 in modified_type_die (type=0x7f21a62a32a0, 
is_const_type=0, is_volatile_type=, 
context_die=0x7f21a8b97000) at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:13057
#10 0x00636070 in force_type_die (type=0x7f21a62a32a0)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:20949
#11 0x00630541 in dwarf2out_imported_module_or_decl_1 (
---Type  to continue, or q  to quit---
decl=0x7f21a633b450, name=0x0, lexical_block=0x7f2195a60f78, 
lexical_block_die=0x7f218b75d870)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:21307
#12 0x00630a98 in decls_for_scope (stmt=0x7f2195a60f78, 
context_die=0x7f218b75d870, depth=1)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:20788
#13 0x0063b6eb in gen_lexical_block_die (depth=1, 
context_die=, stmt=0x7f2195a60f78)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:19886
#14 gen_block_die (stmt=0x7f2195a60f78, context_die=, depth=1)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:20738
#15 0x00630af6 in decls_for_scope (stmt=0x7f2195a9d000, 
context_die=0x7f218b75d500, depth=0)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:20802
#16 0x00630d91 in gen_subprogram_die (decl=0x7f2197110e00, 
context_die=) at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:19494
#17 0x006335d8 in gen_decl_die (decl=0x7f2197110e00, 
origin=0x7f219a55f3f0, context_die=0x7f21a8b97000)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:21152
#18 0x0063c239 in dwarf2out_function_decl (decl=)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:21534
#19 0x0067150d in rest_of_handle_final ()
---Type  to continue, or q  to quit---
at ../../xt-gcc-4.6.2/gcc/final.c:4301
#20 0x0072c669 in execute_one_pass (pass=0x115c560)
at ../../xt-gcc-4.6.2/gcc/passes.c:1556
#21 0x0072c915 in execute_pass_list (pass=0x115c560)
at ../../xt-gcc-4.6.2/gcc/passes.c:1611
#22 0x0072c927 in execute_pass_list (pass=0x115ce40)
at ../../xt-gcc-4.6.2/gcc/passes.c:1612
#23 0x0072c927 in execute_pass_list (pass=0x115cea0)
at ../../xt-gcc-4.6.2/gcc/passes.c:1612
#24 0x007f9681 in tree_rest_of_compilation (fndecl=0x7f2197110e00)
at ../../xt-gcc-4.6.2/gcc/tree-optimize.c:422
#25 0x0093ab0f in cgraph_expand_function (node=0x7f2195a5cc60)
at ../../xt-gcc-4.6.2/gcc/cgraphunit.c:1576
#26 0x

[Bug debug/50497] gcc 4.6.x '-g' option no longer emits the .debug_pubnames section

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50497

--- Comment #1 from Geir Johansen  2011-09-23 17:20:49 
UTC ---
If there is some workaround that will enable previous behavior please add
that to this bug.

[Bug debug/50497] New: gcc 4.6.x '-g' option no longer emits the .debug_pubnames section

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50497

 Bug #: 50497
   Summary: gcc 4.6.x '-g' option no longer emits the
.debug_pubnames section
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


Our performance tool collection relies on the DWARF .debug_pubnames
section to quickly find global symbols. As of GCC 4.6.0 this section is no
longer emitted when -g is specified, imposing an unnecessary hardship upon the
performance tools. Signification problems it causes includes:

1. preventing users of the tool to instrument entry points in user-defined
source code (although -finstrument-functions can circumvent this it requires a
re-compilation of source not previously required)

2. imposing a severe processing overhead penalty if using other means to gather
subprogram details for all globally defined entry points

This bug requests that the .debug_pubnames section again be emitted when -g is
specified. Otherwise, an option should be provided that will allow this as I am
sure other tools have experienced this imposition of a seemingly short-sided
decision (and least I can not find any logical reason why this section was
removed)


Test case:

$ cat abc.c

void a () { }
void b () { }
void c () { }

$

 ** Here is GCC 4.5.3 working: **

$ gcc --version
gcc (GCC) 4.5.3 20110428 (Cray Inc.)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ dwarfdump abc.o   

 

.debug_pubnames
global a   die-in-sect 45, cu-in-sect 11, die-in-cu 45,
cu-header-in
-sect 0
global b   die-in-sect 71, cu-in-sect 11, die-in-cu 71,
cu-header-in
-sect 0
global c   die-in-sect 97, cu-in-sect 11, die-in-cu 97,
cu-header-in
-sect 0

.debug_macinfo

  



 ** Here is GCC 4.6.1 not working: **


$ gcc --version
gcc (GCC) 4.6.1 20110627 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -c -g abc.c
$ dwarfdump abc.o

 

.debug_pubnames

.debug_macinfo

 

[Bug c++/50464] New: Using -Ofast -march=bdver1 results in internal compiler error: in extract_insn, at recog.c:2109

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50464

 Bug #: 50464
   Summary: Using -Ofast -march=bdver1 results in internal
compiler error: in extract_insn, at recog.c:2109
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


Compiling following reduced test case gets the compiler error:

DataspaceIdentifier.cpp: In function 'void createDataspaceIdentifier()':
DataspaceIdentifier.cpp:172:1: error: unrecognizable insn:
(insn 88 87 89 11 (set:V2DI (reg:V2DI 144)
(if_then_else:V2DI (reg:V2DI 146)
(const_vector:V2DI [
(const_int -1 [0x])
(const_int -1 [0x])
])
(reg:V2DI 122 [ vect_var_.44 ]))) DataspaceIdentifier.cpp:155 -1
 (nil))
DataspaceIdentifier.cpp:172:1: internal compiler error: in extract_insn, at
recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


$ g++ --version
g++ (GCC) 4.6.1 20110627 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat DataspaceIdentifier.cpp

typedef long unsigned int size_t;
typedef unsigned long ulong_t;
typedef signed long slong_t;

extern "C++" {
  void* operator new(size_t);
}

  template
struct iterator_traits
{
  typedef typename _Iterator::reference reference;
};

  template
struct iterator_traits<_Tp*>
{
  typedef _Tp& reference;
};

  template
class __normal_iterator
{
protected:
  _Iterator _M_current;
  typedef iterator_traits<_Iterator> __traits_type;

public:
  typedef typename __traits_type::reference reference;

  explicit
  __normal_iterator(const _Iterator& __i) : _M_current(__i) { }

  reference
  operator*() const
  { return *_M_current; }

  __normal_iterator&
  operator++()
  {
 ++_M_current;
 return *this;
  }

  const _Iterator&
  base() const
  { return _M_current; }
};

  template
inline bool
operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
const __normal_iterator<_Iterator, _Container>& __rhs)
{ return __lhs.base() != __rhs.base(); }

  template
class allocator
{
public:
  typedef _Tp* pointer;
  typedef _Tp value_type;

  template
struct rebind
{ typedef allocator<_Tp1> other; };

   pointer allocate(size_t __n, const void* = 0)
   {
  return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
   }
};

  template
struct _Vector_base
{
  typedef typename _Alloc::template rebind<_Tp>::other _Tp_alloc_type;

  struct _Vector_impl
  : public _Tp_alloc_type
  {
typename _Tp_alloc_type::pointer _M_start;
typename _Tp_alloc_type::pointer _M_finish;
typename _Tp_alloc_type::pointer _M_end_of_storage;

_Vector_impl(_Tp_alloc_type const& __a) { }
  };

public:
  typedef _Alloc allocator_type;

  _Vector_base(size_t __n, const allocator_type& __a)
  : _M_impl(__a)
  {
this->_M_impl._M_start = this->_M_allocate(__n);
this->_M_impl._M_finish = this->_M_impl._M_start;
this->_M_impl._M_end_of_storage = this->_M_impl._M_start + __n;
  }

public:
  _Vector_impl _M_impl;

  typename _Tp_alloc_type::pointer
  _M_allocate(size_t __n)
  { return __n != 0 ? _M_impl.allocate(__n) : 0; }

};

  template >
class vector : protected _Vector_base<_Tp, _Alloc>
{
  typedef _Vector_base<_Tp, _Alloc> _Base;
  typedef typename _Base::_Tp_alloc_type _Tp_alloc_type;

public:
  typedef _Tp value_type;
  typedef typename _Tp_alloc_type::pointer pointer;
  typedef __normal_iterator iterator;
  typedef _Alloc allocator_type;

protected:
  using _Base::_M_allocate;
  using _Base::_M_impl;

public:

  explicit
  vector(size_t __n, const value_type& __value = value_type(),
  const allocator_type& __a = allocator_type())
  : _Base(__n, __a)
  { _M_fill_initialize(__n, __value); }

  iterator begin()
  { return iterator(this->_M_impl._M_start); }

  iterator end()
  { return iterator(this->_M_impl._M_finish); }

protected:
  void
  _M_fill_initialize(size_t __n, const value_type& __value)
  {
 this->_M_impl._M_finish = this->_M_impl._M_end_of_storage;
  }
};

  template
_OutputIterator
replace_copy(_InputIterator __first, _InputIterator __last,
   _OutputIterator __result,
   const _Tp& __

[Bug c/48966] gcc 4.5 gets wrong answer at -O2

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48966

--- Comment #1 from Geir Johansen  2011-05-11 15:24:05 
UTC ---
(In reply to comment #0)
> The following test gets the wrong answer for optimization level -O2 (and -O3)
> for GCC 4.5.3.  The correct answer occurs when -O1 is used.  The problem does
> occur in GCC 4.6.0:

The problem does NOT occur in GCC 4.6.0

[Bug c/48966] New: gcc 4.5 gets wrong answer at -O2

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48966

   Summary: gcc 4.5 gets wrong answer at -O2
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


The following test gets the wrong answer for optimization level -O2 (and -O3)
for GCC 4.5.3.  The correct answer occurs when -O1 is used.  The problem does
occur in GCC 4.6.0:


$ cat ptest.c

#include 

double d0 = 0.4;
double d1 = 0.99320549518091861;
double d2 = 0.00674833952334470;
double d3 = 0.00679450481908144;

int main() {
   double  tmp;
   int answer = 0;

   tmp = d3 - d2/(d1-d0) - d0;
   answer = (*(((int *)&tmp)+1) >> 31) & 1;
   printf("answer = %d\n",answer);
   return answer;
}

$ gcc --version
gcc (GCC) 4.5.3 20110428 (Cray Inc.)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -O1 ptest.c && ./a.out
answer = 1
$ gcc -O2 ptest.c && ./a.out
answer = 0   <--- Wrong answer!!!
$ module swap gcc/4.5.3 gcc/4.6.0
$ gcc --version
gcc (GCC) 4.6.0 20110325 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

geir@kaibab:/lus/scratch/geir/ISU/ISU3475> gcc -O2 ptest.c && ./a.out
answer = 1
$

The processor being used is:

$ grep "model name" /proc/cpuinfo
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
$

[Bug c/48716] New: gcc OpenMP static variable declared in scope inside construct is predetermined shared

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48716

   Summary: gcc OpenMP static variable declared in scope inside
construct is predetermined shared
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


A static variable is declared inside a task construct having a
default(none) clause.  The OpenMP API says that this variable is
predetermined shared.  Currently the GNU gcc compiler wants this
variable to appear in a SHARED clause.

The OpenMP API version 3.0 (May 2008) on p. 78 lines 10 & 20 states:

"The following variables have predetermined data-sharing attributes:
 . . .
 * Static variables which are declared in a scope inside the construct
   are shared."

On p. 87 lines 22-25 the following appears:

"The default(none) clause requires that each variable that is referenced
in the construct, and that does not have a predetermined data-sharing 
attribute, must have its data-sharing attribute explicitly determined by 
being listed in a data-sharing attribute clause."

In Section 2.7 task Construct on p. 59, line 17, we see that the
default(none) clause may appear on the #pragma omp task construct.


Test case:

$ cat ISU3305.c
//  derived from OpenMP test omp3c/c03_2_9_3_1_3k.c
//  REFERENCES : OpenMP 3.0, p. 59, line 17
//   OpenMP 3.0, p. 78, line 20
//   OpenMP 3.0, p. 87, lines 22-25
int main(void) {
#pragma omp task default(none)
{
static int shared_var;
shared_var = 1;
}
return 0;
}
$ gcc --version
gcc (GCC) 4.6.0 20110325 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c -fopenmp ISU3305.c
ISU3305.c: In function 'main':
ISU3305.c:9:20: error: 'shared_var' not specified in enclosing parallel
ISU3305.c:6:13: error: enclosing task
$

Expected results from Intel and PGI compilers:

$ pgcc -c -mp ISU3305.c
$ icc -c -openmp ISU3305.c
$

[Bug tree-optimization/48172] New: incorrect vectorization of loop in GCC 4.5.* with -O3

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172

   Summary: incorrect vectorization of loop in GCC 4.5.* with -O3
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


When the following test case is compiled with -O3, the program fails to compute
correct array values.  Compiling with -O2 allows the program to execute
correctly.

Looking at the disassembly of the program, the compiler appears to be
vectorizing a loop (lines 25-27 in this example) incorrectly.  Turning off loop
vectorization allows correct code generation ("cc -O3 -fno-tree-vectorize"
works)

Problem was duplicated using gcc 4.5.0, 4.5.1, and 4.5.2.  Problem does not
occur using gcc 4.4.4 or 4.3.1.

The CPU being used is a 12-core Magny-Cours Opteron.

test case:

$ cat vec.c
// Compile with gcc -O3 to see failures
// Compile with gcc -O3 -fno-tree-vectorize to get correct results
#include 
#include 
#include 

#define ASIZE 1028
#define HALF (ASIZE/2)

int main() {
  uint32_t array[ASIZE];
  int failures;
  int i;

  memset(array, 0, sizeof(array));

  // initialize first half of the array
  for (i = 0; i < HALF; i++) {
array[i] = i;
  }

  // fill second half of array in by summing earlier elements of the array
  // gcc 4.5.1 and 4.5.2 incorrectly vectorize this loop!  aray[1025] is left
  // at 0 for ASIZE=1028
  for (i = 0; i < HALF-1; i++) {
array[HALF+i] = array[2*i] + array[2*i + 1];
  }

  // see if we have any failures
  failures = 0;
  for (i = 0; i < HALF - 1; i++) {
if (array[HALF+i] != array[2*i] + array[2*i + 1]) {
  printf("COMPILER BUG: array[%d] should be %d but is %d\n",
 HALF+i, array[2*i] + array[2*i + 1], array[HALF+i]);
  ++failures;
}
  }

  if (failures == 0) {
printf("pass\n");
  }

  return 0;
}

$$ gcc --version
gcc (GCC) 4.5.2 20101216 (Cray Inc.)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -O3 vec.c ; ./a.out
COMPILER BUG: array[1025] should be 98177 but is 0
$ gcc -O3 -fno-tree-vectorize vec.c ; ./a.out 
pass
$ gcc -O2 vec.c ; ./a.out
pass
$

  GCC 4.4.4 works:

$ gcc --version
gcc (GCC) 4.4.4 20100429 (Cray Inc.)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -O3 vec.c ; ./a.out
pass
$

[Bug c/45784] New: gcc OpenMP - error: invalid controlling predicate

[geir at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45784

   Summary: gcc OpenMP - error: invalid controlling predicate
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


The test is verifying that the parallel for loop construct may use
a variable of a pointer type in C.  

The OpenMP API Version 3.0 (May 2008) describes this usage on page
39 of the document.

Currently the GNU gcc compiler produces the following messages for
this test case:

ISU3417.c: In function 'vla_test':
ISU3417.c:23:25: error: invalid controlling predicate

The PGI, Intel, and Cray compilers compile this test case successfully.

$ cat ISU3417.c
//  derived from OpenMP test omp3c/c03_2_5_1_2c.c
#include 
#include 
#include 
#define NT 4
#define INCREMENT 2
#define ARRAY_SIZE INCREMENT*NT

// VLAs are standard only in C99; might as well use a C99-specific data type
// (long long int) while we're testing C99-specific features
void vla_test(int num_threads) {
long long int *ptr, vla[INCREMENT*num_threads];
//long long int *ptr, vla[INCREMENT*40];
int i;

// variable-length array initialized to -1
for (i = 0; i < sizeof(vla)/sizeof(vla[0]); i++) {
vla[i] = -1;
}

#pragma omp parallel shared(vla)
{
#pragma omp for schedule(static, 1)
for (ptr = vla; ptr < vla + sizeof(vla)/sizeof(vla[0]); 
 ptr = ptr + INCREMENT)
 *ptr = omp_get_thread_num();
}

for (i = 0; i < sizeof(vla)/sizeof(vla[0]); i++) {
if (vla[i] != (i % INCREMENT == 0 ? (i/INCREMENT) % num_threads : -1))
{
fprintf(stderr, "%s:%i: FAIL - vla[%i] == %lli != %i\n", 
__FILE__, __LINE__, i, vla[i], 
   (i % INCREMENT == 0 ? (i/INCREMENT) % num_threads : -1));
exit(1);
}
}
}

int main(void) {
omp_set_dynamic(0);
omp_set_num_threads(NT);

vla_test(NT);

return 0;
}
$ gcc -c -fopenmp -std=c99 ISU3417.c
ISU3417.c: In function 'vla_test':
ISU3417.c:24:25: error: invalid controlling predicate
$

Other compilers working:

$ pgcc -mp -c ISU3417.c
$ icc -c -openmp ISU3417.c
$ cc -c -omp -V ISU3417.c
/opt/cray/xt-asyncpe/4.4.9/bin/cc: INFO: Compiling for compute nodes running
CLE.
Cray C : Version 7.2.7 (u7267c72242i72182p72540a72002e60006z72540)
Cray C :   (x7205r72009w71001t7207)
Cray C : Fri Sep 24, 2010  14:34:26
$

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug c/42979] New: OpenMP #pragma omp taskwait after a label is not permitted - should fail at compile time

[geir at cray dot com]

OpenMP #pragma omp taskwait after a label is not permitted - should fail at
compile time  [Cray Bug 755983]

The test checks that the #pragma omp taskwait may not be used after a label.
Currently the GNU gcc compiler fails to produce any error message at
compile time.

The OpenMP API version 3 (May 2008) p. 68 lines 16-19 state:

"The taskwait directive may be placed only at a point where a base 
 language statement is allowed.  The taskwait directive may not be
 used in place of the statement following an if, while, do, switch,
 or label."

$ cat ISU3243.c
/*  derived from OpenMP test omp3c/Nc03_2_8_4_2e.c  */
// REFERENCESOpenMP 3.0, p. 68, lines 16-19
#include 
int main(void)
{
#pragma omp parallel
{
goto mylabel;
mylabel:
#pragma omp taskwait
;
}
fprintf(stderr, "%s:%i: FAIL - negative test case should not compile\n",
__FILE__, __LINE__);
return 1;
}

$ gcc --version
gcc (GCC) 4.4.3 20100121 (Cray Inc.)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -fopenmp ISU3243.c
$ ./a.out
ISU3243.c:14: FAIL - negative test case should not compile
$


-- 
   Summary: OpenMP #pragma omp taskwait after a label is not
permitted - should fail at compile time
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42979

[Bug fortran/33439] OpenMP: Incorrect error message for chunksize variable

[geir at cray dot com]

--- Comment #8 from geir at cray dot com  2009-09-18 18:41 ---
Here is how other compilers process this code:

PGI:

$ pgf90 -mp test.f90
$ ./a.out
Warning: omp_set_num_threads (4) greater than available cpus (2)
 tmp, fsize3.141592653589793-7
 s =0.000
$ pgf90 test.f90
$ ./a.out
 tmp, fsize3.141592653589793-7
 s =100.0
$

Intel:

$ ifort -openmp test.f90
$ ./a.out
 tmp, fsize   3.14159265358979   -7
 s =   100.
$ ifort test.f90
/tmp/pbs.1871075.sdb/ifortE1EQWX.o: In function `MAIN__':
test.f90:(.text+0x3e): undefined reference to `omp_set_num_threads_'
$

Cray:

$ ftn -target=native -Oomp test.f90
/opt/cray/xt-asyncpe/3.3/bin/ftn: INFO: native target is being used
$ ./a.out
 tmp, fsize 3.1415926535897931,  -7
 s = 0.
$ ftn -target=native -Onoomp test.f90
/opt/cray/xt-asyncpe/3.3/bin/ftn: INFO: native target is being used
$ ./a.out
 tmp, fsize 3.1415926535897931,  -7
 s = 100.
$

I would say that none of the above are desired behavior, but rather a runtime
error message should be printed out.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33439

[Bug libgomp/33720] A negative value in OpenMP clause num_threads is not detected at runtime

[geir at cray dot com]

--- Comment #5 from geir at cray dot com  2009-09-14 19:59 ---
(In reply to comment #4)
> Geir, have you run the testcase with other compilers? What is the result?
> 

Changed test cast to use 2 threads ("omp_set_num_threads(2);")

  PGI 9.0-3

$ pgcc -mp bug2883.c
$ ./a.out
pi   3.1416 n_thread -7
Error: omp_set_num_threads value (-7) is invalid
$

  Pathscale 3.2.99:

$ pathcc -mp bug2883.c
$ ./a.out
pi   3.1416 n_thread -7
actual_num_threads = 1
$

  Intel/11.1.046:

$ icc -openmp bug2883.c
$ ./a.out
pi   3.1416 n_thread -7
actual_num_threads = 2
$

  Cray 7.1.3:

$ cc -target=native bug2883.c
$ ./a.out
pi   3.1416 n_thread -7
actual_num_threads = 2
$

$


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33720

[Bug other/36368] Fixincludes corrupts sysmacros.h

[geir at cray dot com]

--- Comment #3 from geir at cray dot com  2009-06-15 20:47 ---
For another point of reference, I see this problem in our GCC 4.3.1 build; but
the problem did not occur in our gcc 4.3.0 and 4.3.2 versions.  I assume this
was an error on our part.

$ diff
/opt/gcc/4.3.1/snos/lib/gcc/x86_64-suse-linux/4.3.1/include-fixed/sys/sysmacros.h
/opt/gcc/4.3.0/snos/lib/gcc/x86_64-suse-linux/4.3.0/include-fixed/sys/sysmacros.h
11c11
<Copyright (C) 1996, 1997, 1999, 2003 Free Software Foundation, Inc.
---
>Copyright (C) 1996, 1997, 1999, 2003, 2004 Free Software Foundation, Inc.
51c51
< gnu_dev_major (unsigned long long int __dev) __THROW
---
> __NTH (gnu_dev_major (unsigned long long int __dev))
57c57
< gnu_dev_minor (unsigned long long int __dev) __THROW
---
> __NTH (gnu_dev_minor (unsigned long long int __dev))
63c63
< gnu_dev_makedev (unsigned int __major, unsigned int __minor) __THROW
---
> __NTH (gnu_dev_makedev (unsigned int __major, unsigned int __minor))
$ diff
/opt/gcc/4.3.1/snos/lib/gcc/x86_64-suse-linux/4.3.1/include-fixed/sys/sysmacros.h
/opt/gcc/4.3.2/snos/lib/gcc/x86_64-suse-linux/4.3.2/include-fixed/sys/sysmacros.h
11c11
<Copyright (C) 1996, 1997, 1999, 2003 Free Software Foundation, Inc.
---
>Copyright (C) 1996, 1997, 1999, 2003, 2004 Free Software Foundation, Inc.
51c51
< gnu_dev_major (unsigned long long int __dev) __THROW
---
> __NTH (gnu_dev_major (unsigned long long int __dev))
57c57
< gnu_dev_minor (unsigned long long int __dev) __THROW
---
> __NTH (gnu_dev_minor (unsigned long long int __dev))
63c63
< gnu_dev_makedev (unsigned int __major, unsigned int __minor) __THROW
---
> __NTH (gnu_dev_makedev (unsigned int __major, unsigned int __minor))
$ diff
/opt/gcc/4.3.0/snos/lib/gcc/x86_64-suse-linux/4.3.0/include-fixed/sys/sysmacros.h
/opt/gcc/4.3.2/snos/lib/gcc/x86_64-suse-linux/4.3.2/include-fixed/sys/sysmacros.h
$


-- 

geir at cray dot com changed:

   What|Removed |Added

         CC|    |geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368

[Bug c/37764] New: Macro is not passed to openmp pragma when preprocessor is used

[geir at cray dot com]

The following openmp test case will not compile when it is first separating
processed by the preprocessor:

$ cat bug2885b.c
#include 
#include 
#define NT 4
int actual_num_threads;

int main(){
  #pragma omp parallel default(none) shared(actual_num_threads) num_threads(NT)
  {
  #pragma omp master
  {
  actual_num_threads = omp_get_num_threads();
  }
  }

  printf("actual_num_threads: %d\n",actual_num_threads);
  printf("num_threads NT: %d\n",NT);
  return 0;
}
$ gcc --version
gcc (GCC) 4.3.1 20080606 (rpm:5)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$



$ gcc -fopenmp bug2885b.c; ./a.out
actual_num_threads: 4
num_threads NT: 4
$



$ gcc -E -fopenmp bug2885b.c > bug.c
$ gcc -fopenmp bug.c
bug2885b.c: In function 'main':
bug2885b.c:7: error: 'NT' undeclared (first use in this function)
bug2885b.c:7: error: (Each undeclared identifier is reported only once
bug2885b.c:7: error: for each function it appears in.)
bug2885b.c:7: error: expected integer expression before end of line
$


-- 
   Summary: Macro is not passed to openmp pragma when preprocessor
is used
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37764

[Bug c/37023] New: Macro replacement not working if file is preprocessed then compiler

[geir at cray dot com]

The following program shows two cases where macro replacement works if the
program is compiled, but does NOT work if the program is preprocessed and then
compiled.  Either the preprocessed program should be able to be compiled, or
gcc should return an error when the non-preprocessed code is compiled.


$ cat ISU3006.c

/*  derived from ISU's RTED_OpenMP/C/Col7_Imp_Dep_Errs/c_G_1_1_a.c  */
/*  Trying c99 _Pragma possibility  */
#include 
#include 
#include 
#define NT 4
#define N 17

#ifdef TEST3
#define NTM(x) #x
#define PRAGMA(x) NTM(omp parallel default(none) shared(vara,
actual_num_threads) num_threads(x) )
#define LISTING(x) _Pragma(x)
#endif

int actual_num_threads;

int main(){
int vara=0;

#ifdef TEST3
  LISTING(PRAGMA(NT))
#elif TEST2
  _Pragma ( "omp parallel default(none) shared(vara, actual_num_threads)
num_threads(NT)" )
#else /*TEST1*/
 #pragma omp parallel default(none) shared(vara, actual_num_threads)
num_threads(NT)
#endif
{
#pragma omp master
{
actual_num_threads = omp_get_num_threads();
vara = 10 + actual_num_threads;
}
}
printf("calculate vara: %d\n",vara);
return 0;
}

$ gcc --version
gcc (GCC) 4.3.1 20080606 (rpm:5)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -fopenmp ISU3006.c
$ gcc -DTEST2 -fopenmp ISU3006.c
$ gcc -E -fopenmp ISU3006.c >i1.i
$ gcc -fopenmp i1.i
ISU3006.c: In function 'main':
ISU3006.c:26: error: 'NT' undeclared (first use in this function)
ISU3006.c:26: error: (Each undeclared identifier is reported only once
ISU3006.c:26: error: for each function it appears in.)
ISU3006.c:26: error: expected integer expression before end of line
$ grep parallel i1.i
extern int omp_in_parallel (void) __attribute__((__nothrow__));
#pragma omp parallel default(none) shared(vara, actual_num_threads)
num_threads(NT)
$ gcc -DTEST2 -E -fopenmp ISU3006.c >i2.i
$ gcc -fopenmp i2.i
ISU3006.c: In function 'main':
ISU3006.c:24: error: 'NT' undeclared (first use in this function)
ISU3006.c:24: error: (Each undeclared identifier is reported only once
ISU3006.c:24: error: for each function it appears in.)
ISU3006.c:24: error: expected integer expression before end of line
$ grep parallel i2.i
extern int omp_in_parallel (void) __attribute__((__nothrow__));
#pragma omp parallel default(none) shared(vara, actual_num_threads)
num_threads(NT)
$

   Here is code that allows the program to be compiled when first running it
through the preprocessor:

$ gcc -DTEST3 -fopenmp ISU3006.c
$ gcc -DTEST3 -E -fopenmp ISU3006.c >i3.i
$ gcc -fopenmp i3.i
$ grep parallel i3.i
extern int omp_in_parallel (void) __attribute__((__nothrow__));
#pragma omp parallel default(none) shared(vara, actual_num_threads)
num_threads(4)
$


-- 
   Summary: Macro replacement not working if file is preprocessed
then compiler
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37023

[Bug c++/34303] New: C++ class variable gets compiler error "declared 'threadprivate' after first use"

[geir at cray dot com]

+++ This bug was initially created as a clone of Bug #27557 +++

This bug presented here is likely the same as Bug #27557, but this test case
does not involve a non-POD type.

Following program gets a compile time error with g++, but is able to compile
and execute using PGI and PathScale compilers.  


$ cat bug2907.cpp
/*  derived from OpenMP API Ver 2.5 p. 159 Example A.22.3c  */
#include 
#include 
#define NT 4

class T {
 public:
  int val;
  T (int);
  T (const T&);
};
T :: T (int v){
  val = v;
}
T :: T (const T& t) {
  val = t.val;
}

int x = 1;
const T b_aux(x);
T b(b_aux);

#pragma omp threadprivate(b)

int main()
{
  int save_val;
  omp_set_num_threads(NT);
  x++;

#pragma omp parallel default(none) shared(save_val)
  {
if (omp_get_thread_num()==0)  save_val = b.val;
  }

  printf("save_val=%d\n",save_val);
  return 0;
}

$ g++ -fopenmp bug2907.cpp
bug2907.cpp:23: error: 'b' declared 'threadprivate' after first use
bug2907.cpp: In function 'int main()':
bug2907.cpp:33: error: 'b' not specified in enclosing parallel
bug2907.cpp:31: error: enclosing parallel
$ pathCC -mp bug2907.cpp; ./a.out
save_val=1
$ pgCC -mp=nonuma bug2907.cpp; ./a.out
Warning: omp_set_num_threads (4) greater than available cpus (1)
save_val=1
$


-- 
   Summary: C++ class variable gets compiler error "declared
'threadprivate' after first use"
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34303

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[geir at cray dot com]

--- Comment #24 from geir at cray dot com  2007-10-23 19:11 ---
> State-Changed-From-To: open->suspended

What is the status of this bug?  Will the proposed patches be implemented?
(Note: http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#status does not
describe "SUSPENDED" status).


-- 

geir at cray dot com changed:

   What|Removed |Added

 CC|        |geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291

[Bug c/33720] New: A negative value in OpenMP clause num_threasds is not detected at runtime

[geir at cray dot com]

The 'num_threads' clause in a OpenMP pragma is not being checked to see if it
is a positive integer.  An error should be return if it is not.

The OpenMP API Version 2.5 May 2005 on p. 28 lines 29-30 offers the following
restriction:

" * ... The num_threads expression must evaluate to a positive integer value."


$ cat bug2883.c
/* derived from ISU's RTED_OpenMP/C/Col3_Env_and_Claus_Errs/c_C_1_1_a.c test */
#include 
#include 
#include 
int main() {
  double s, pi;
  int n_thread;
  int actual_num_threads;
  omp_set_num_threads(4);

  s = 0;
  pi = 4.0*atan(1.0);
  n_thread = (int) (sin(-0.25*pi)*10.0);

  printf("pi % 12.4f n_thread %d \n", pi, n_thread);
#pragma omp parallel default(none) shared(actual_num_threads)
num_threads(n_thread)
 {
#pragma omp single
   {
 actual_num_threads = omp_get_num_threads();
   }
 }

 printf("actual_num_threads = %d\n", actual_num_threads);
 return 0;
}

$ gcc -o x -fopenmp bug2883.c -lm
$ ./x 
pi   3.1416 n_thread -7

libgomp: Out of memory allocating 34359738400 bytes
$


-- 
   Summary: A negative value in OpenMP clause num_threasds is not
detected at runtime
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33720

[Bug c/33719] New: "#pragma omp for firstprivate(shared_var)" in function labelled 'shared_var' as private

[geir at cray dot com]

This case involves a function containing only a '#pragma omp for' directive and
a 'for' loop to go with it.  The invoking routine is the one that determines
whether the variable is shared or private.  There is no way to supply this
information within the function without expanding what the function does. 

$ cat >bug2874.c
/*  derived from ISU's tests RTED_OpenMP/C/SECTION_B/c_B_7_3_e_D_s.c
c_B_7_3_f_D_s.c, c_B_7_3_g_D_s.c   */
#include 
#define N 17

void sub(double *shared_var,double result_var[],int thread_num){
int i = 0;

#pragma omp for firstprivate(shared_var)
for (i=0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=33719

[Bug c/33718] New: CHUNKSIZE IN SCHEDULE CLAUSE SHOULD NOT NEED SCOPING IF DEFAULT(NONE) PRESENT

[geir at cray dot com]

The GNU C/C++ compiler is asking that when a default(none) clause is present on
the '#pragma omp parallel for', and a chunk-size expression (in this case just
the variable csize) appears in a schedule clause, that the variable must appear
in a shared or private clause.  Other compilers do not require that this be
done.

$ cat bug2873.c
/* derived from RTED_OpenMP/C/SECTION_C/c_C_3_2_b.c
  c_C_3_2_c.c, c_C_3_2_e.c, c_C_3_2_f.c,
  c_E_5_k.c, c_E_5_l.c, c_E_5_m.c */
#include 
#include 
int main() {
  double s, tmp;
  int n_thread,i, csize;
  int nt=4;
  double arr[100];

  omp_set_dynamic(0);
  omp_set_num_threads(nt);
  for (i=0;i<100;i++) arr[i]=(double) i;
  s = 0.0;
  tmp =  4.0*atan(1.0);
  tmp = sin(-0.25*tmp);
  csize = (int) (tmp*10.0);
  printf("tmp % 12.4f n_thread %d \n", tmp, csize);
#pragma omp parallel for default(none) shared(arr) reduction(+:s)
schedule(dynamic,csize)
  for (i=0;i<100;i++) s += arr[i];
  printf("s = %12.4f\n", s);
  return 0;
}

$ gcc --version
gcc (GCC) 4.2.1 20070719 (rpm:3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -fopenmp -c bug2873.c
bug2873.c: In function 'main':
bug2873.c:21: error: 'csize' not specified in enclosing parallel
bug2873.c:20: error: enclosing parallel
$


-- 
   Summary: CHUNKSIZE IN SCHEDULE CLAUSE SHOULD NOT NEED SCOPING IF
DEFAULT(NONE) PRESENT
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33718

[Bug c/32799] Multiple definitions of __flockfile when compiling an openMP program

[geir at cray dot com]

--- Comment #2 from geir at cray dot com  2007-07-17 19:22 ---
Pressing refresh on my browser mistakenly opened up a new bug for the problem
described in bug 32798


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32799

[Bug c/32799] Multiple definitions of __flockfile when compiling an openMP program

[geir at cray dot com]

--- Comment #1 from geir at cray dot com  2007-07-17 19:21 ---


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


-- 

geir at cray dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32799

[Bug c/32798] Multiple definitions of __flockfile when compiling an openMP program

[geir at cray dot com]

--- Comment #1 from geir at cray dot com  2007-07-17 19:21 ---
*** Bug 32799 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32798

[Bug c/32799] New: Multiple definitions of __flockfile when compiling an openMP program

[geir at cray dot com]

I see the following behavior when compiling an OpenMP program:

$ cat omp.c

extern void omp_set_num_threads (int);
#define NT 4

int main() {
omp_set_num_threads(NT);
return(0);
}

$ gcc --version
gcc (GCC) 4.2.0 20070514 (rpm:4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -static -fopenmp omp.c -lc
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function
`__flockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple
definition of `_IO_flockfile'
/usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `_IO_flockfile' changed from 24 in
/usr/lib/../lib64/libc.a(flockfile.o) to 12 in
/usr/lib/../lib64/libc.a(flockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function
`__flockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple
definition of `__flockfile'
/usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `__flockfile' changed from 24 in
/usr/lib/../lib64/libc.a(flockfile.o) to 12 in
/usr/lib/../lib64/libc.a(flockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xa0): In function
`__funlockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:39: multiple
definition of `_IO_funlockfile'
/usr/lib/../lib64/libc.a(funlockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/funlockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `_IO_funlockfile' changed from 24 in
/usr/lib/../lib64/libc.a(funlockfile.o) to 12 in
/usr/lib/../lib64/libc.a(funlockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xa0): In function
`__funlockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:39: multiple
definition of `__funlockfile'
/usr/lib/../lib64/libc.a(funlockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/funlockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `__funlockfile' changed from 24 in
/usr/lib/../lib64/libc.a(funlockfile.o) to 12 in
/usr/lib/../lib64/libc.a(funlockfile.o)collect2: ld returned 1 exit status
$

Problem does NOT occur if I don't include '-lc'.  I don't quite understand why
this is a factor, since gcc automatically specifies '-lc' when linking the
program.  Please enlighten me as to why adding this to the command line causes
the error.

Here is the version of Linux I am using:

$ uname -a
Linux guppy2 2.6.5-7.286-ss #6 SMP Wed Jul 11 14:28:20 PDT 2007 x86_64 x86_64
x86_64 GNU/Linux
$ cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (x86_64)
VERSION = 9
PATCHLEVEL = 2
$

I am building a program for the Cray XT3, so static libraries must be used.


-- 
   Summary: Multiple definitions of __flockfile when compiling an
openMP program
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
     Component: c
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32799

[Bug c/32798] New: Multiple definitions of __flockfile when compiling an openMP program

[geir at cray dot com]

I see the following behavior when compiling an OpenMP program:

$ cat omp.c

extern void omp_set_num_threads (int);
#define NT 4

int main() {
omp_set_num_threads(NT);
return(0);
}

$ gcc --version
gcc (GCC) 4.2.0 20070514 (rpm:4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -static -fopenmp omp.c -lc
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function
`__flockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple
definition of `_IO_flockfile'
/usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `_IO_flockfile' changed from 24 in
/usr/lib/../lib64/libc.a(flockfile.o) to 12 in
/usr/lib/../lib64/libc.a(flockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xb0): In function
`__flockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:29: multiple
definition of `__flockfile'
/usr/lib/../lib64/libc.a(flockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/flockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `__flockfile' changed from 24 in
/usr/lib/../lib64/libc.a(flockfile.o) to 12 in
/usr/lib/../lib64/libc.a(flockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xa0): In function
`__funlockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:39: multiple
definition of `_IO_funlockfile'
/usr/lib/../lib64/libc.a(funlockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/funlockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `_IO_funlockfile' changed from 24 in
/usr/lib/../lib64/libc.a(funlockfile.o) to 12 in
/usr/lib/../lib64/libc.a(funlockfile.o)
/usr/lib/../lib64/libpthread.a(lockfile.o)(.text+0xa0): In function
`__funlockfile':
/usr/src/packages/BUILD/glibc-2.3/linuxthreads/lockfile.c:39: multiple
definition of `__funlockfile'
/usr/lib/../lib64/libc.a(funlockfile.o)(.text+0x0):../linuxthreads/sysdeps/pthread/funlockfile.c:30:
first defined here
/usr/bin/ld: Warning: size of symbol `__funlockfile' changed from 24 in
/usr/lib/../lib64/libc.a(funlockfile.o) to 12 in
/usr/lib/../lib64/libc.a(funlockfile.o)collect2: ld returned 1 exit status
$

Problem does NOT occur if I don't include '-lc'.  I don't quite understand why
this is a factor, since gcc automatically specifies '-lc' when linking the
program.  Please enlighten me as to why adding this to the command line causes
the error.

Here is the version of Linux I am using:

$ uname -a
Linux guppy2 2.6.5-7.286-ss #6 SMP Wed Jul 11 14:28:20 PDT 2007 x86_64 x86_64
x86_64 GNU/Linux
$ cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (x86_64)
VERSION = 9
PATCHLEVEL = 2
$

I am building a program for the Cray XT3, so static libraries must be used.


-- 
   Summary: Multiple definitions of __flockfile when compiling an
openMP program
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
     Component: c
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32798

[Bug middle-end/30132] [4.1/4.2/4.3 Regression] ICE in find_lattice_value, at tree-complex.c:133

[geir at cray dot com]

--- Comment #10 from geir at cray dot com  2007-01-22 19:24 ---
Here is a Fortran test case:

$ cat bug2737.f90
  PROGRAM get_tst_inc_complex
  implicit none
  external subrrg, checkrr

  complex :: vrr, trr

  vrr=cmplx(1.,2.);
  call subrr ( )

  contains

subroutine subrr ()
  trr=vrr-(1.0,0.0)
  call checkrr (trr)
  return
end subroutine subrr

END

$ gfortran --version
GNU Fortran 95 (GCC) 4.1.1 20060524 (rpm:5)
Copyright (C) 2006 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

$ gfortran -c -O0 bug2737.f90
$ gfortran -c -O1 bug2737.f90
bug2737.f90: In function 'MAIN__':
bug2737.f90:1: internal compiler error: in find_lattice_value, at
tree-complex.c:133
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$


-- 

geir at cray dot com changed:

   What|Removed |Added

 CC|    |geir at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30132