[Bug go/82348] make[4]: Circular runtime.lo <- bytes.gox dependency dropped.

[mfe at live dot de]

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

--- Comment #5 from martin  ---
Created attachment 42266
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42266&action=edit
math.lo.dep

I looked up the required cpu.gox file. It does neither exist in the source
tree, or in the built folder (my built folder is named as gcc-compiled).

>find gcc-trunk/ -name cpu.gox #no result
>find gcc-compiled/ -name cpu.gox #no result

[Bug target/82361] Useless "mov eax, eax" in generated code

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Sep 30 08:10:15 2017
New Revision: 253317

URL: https://gcc.gnu.org/viewcvs?rev=253317&root=gcc&view=rev
Log:
PR target/82361
* config/i386/i386.md
(TARGET_USE_8BIT_IDIV zext divmodsi4 splitter): New define_split.
(divmodsi4_zext_1, divmodsi4_zext_2, *divmodsi4_zext_1,
*divmodsi4_zext_2): New define_insn_and_split.
(*divmodsi4_noext_zext_1, *divmodsi4_noext_zext_2): New define_insn.
(TARGET_USE_8BIT_IDIV zext udivmodsi4 splitter): New define_split.
(udivmodsi4_zext_1, udivmodsi4_zext_2, *udivmodsi4_zext_1,
*udivmodsi4_zext_2, *udivmodsi4_pow2_zext_1, *udivmodsi4_pow2_zext_2):
New define_insn_and_split.
(*udivmodsi4_noext_zext_1, *udivmodsi4_noext_zext_2): New define_insn.
* config/i386/i386.c (ix86_split_idivmod): Handle operands[0] or
operands[1] having DImode when mode is SImode.

* gcc.target/i386/pr82361-1.c: New test.
* gcc.target/i386/pr82361-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82361-1.c
trunk/gcc/testsuite/gcc.target/i386/pr82361-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/81314] [6/7/8 Regression] Undefined reference to a function with -fopenmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/82159] [6/7/8 Regression] ICE: in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Sat Sep 30 08:25:02 2017
New Revision: 253318

URL: https://gcc.gnu.org/viewcvs?rev=253318&root=gcc&view=rev
Log:
Backported from mainline
2017-09-27  Jakub Jelinek  

PR c++/82159
* gimplify.c (gimplify_modify_expr): Don't optimize away zero sized
lhs from calls if the lhs has addressable type.

* g++.dg/opt/pr82159.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/opt/pr82159.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/82340] volatile ignored in compound literal

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Sat Sep 30 08:26:32 2017
New Revision: 253319

URL: https://gcc.gnu.org/viewcvs?rev=253319&root=gcc&view=rev
Log:
Backported from mainline
2017-09-29  Jakub Jelinek  

PR c/82340
* c-decl.c (build_compound_literal): Use c_apply_type_quals_to_decl
instead of trying to set just TREE_READONLY manually.

* gcc.dg/tree-ssa/pr82340.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tree-ssa/pr82340.c
Modified:
branches/gcc-7-branch/gcc/c/ChangeLog
branches/gcc-7-branch/gcc/c/c-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/82372] Rejects valid parenthesis

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-30
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed. IMO should be diagnosed as characters not in the Fortran set.

[Bug c++/82373] New: syntax error in error message

[drepper.fsp+rhbz at gmail dot com]

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

Bug ID: 82373
   Summary: syntax error in error message
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

Compiling the invalid code at the bottom produces the following message:

y.cc: In function ‘auto bar::foo(int))(int)’:
y.cc:7:12: error: inconsistent deduction for auto return type: ‘int (*)(int)’
and then ‘std::nullptr_t’
 return nullptr;
^~~

The function name is wrong.  The parameter list of the inferred return type
should not be printed.

   auto bar::foo(int)

The correct form would have (* before the function name:

   auto (*bar::foo(int))(int)
^^

But then the 'auto' must be replaced as well.  But this is wrong since it does
not correspond to a function in the source.



namespace bar {
  int(*fp)(int);
  auto foo(int a)
  {
if (a)
  return fp;
return nullptr;
  }
}

[Bug tree-optimization/82374] New: #pragma GCC optimize is not applied to openmp-generated functions

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 82374
   Summary: #pragma GCC optimize is not applied to
openmp-generated functions
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization, openmp
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

#pragma GCC optimize (and the function attribute optimize) is not applied to
functions generated with openmp.

This is example code. Compile it with -fopenmp (with or without -O2) and you'll
notice that the function "f_nonomp" is properly vectorized (i.e. it uses the
"addps" instruction) and the function "f" is not vectorized (i.e. the generated
function f._omp_fn.0 performs the addition on single elements using the "addss"
instruction and no vectorization is done).

If we use __attribute((optimize("-O2","-ftree-vectorize"))) on the function
"f", then again, the optimization is not applied to openmp-generated function
"f._omp_fn.0".

If we use "-O3" or "-ftree-vectorize" on the command-line, then both functions
are properly vectorized.


#pragma GCC optimize("-O2", "-ftree-vectorize")

#define SIZE(1024 * 1024 * 1024)

float a[SIZE];
float b[SIZE];
float c[SIZE];

void f(void)
{
int i;
#pragma omp parallel for
for (i = 0; i < SIZE; i++)
c[i] = a[i] + b[i];
}

void f_nonomp(void)
{
int i;
for (i = 0; i < SIZE; i++)
c[i] = a[i] + b[i];
}

[Bug c/47781] warnings from custom printf format specifiers

[daniel.santos at pobox dot com]

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

--- Comment #19 from Daniel Santos  ---
(In reply to Martin Sebor from comment #18)
> The Linux kernel also has a bunch of printf format extensions that GCC
> doesn't know anything about:
> https://www.kernel.org/doc/Documentation/printk-formats.txt.

Further, the printf format extensions in the kernel are designed so as to not
create warnings and so are often two character combinations by using a standard
format specifier followed by a modifying character.  I think that I ran a
script once to count how much extra memory the two bytes vs a single byte take
and it ended up in the 10s of kilobytes.  While this may not sound like much,
remember that the kernel data is never paged out and on some embedded systems,
it actually does make a difference.

Should GCC begin supporting custom printf format specifiers, then I would
propose we begin changing them in the kernel to take advantage of that small
savings.

[Bug fortran/82362] [8 Regression] SPEC CPU2006 436.cactusADM ~7% performance deviation with trunk@251713

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-30
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Is it really a gfortran bug?

[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast

[spamdrop at fodvo dot org]

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

--- Comment #3 from spamdrop at fodvo dot org ---
Thanks, I'll look into, but due to a deadline I have right now, I need to
fallback to 4.9.2 until I get my POC project running.

But thanks for the quick reply.

[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast

[spamdrop at fodvo dot org]

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

--- Comment #4 from spamdrop at fodvo dot org ---
One more comment to add before I forget, If I change the regex string to remove
the []'s, while the program doesn't do the correct thing (obviously), it at
least doesn't throw the exception.  Not sure if that has any significant
meaning.

[Bug fortran/82375] New: PDT error

[ian at rhymneyconsulting dot co.uk]

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

Bug ID: 82375
   Summary: PDT error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at rhymneyconsulting dot co.uk
  Target Milestone: ---

Created attachment 42267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42267&action=edit
these are the three source files. the main program and two included module
files.

I believe that the following program is standard conformant and that the
gfortran compilation error message is incorrect. Here is the main program
source file. 

include 'precision_module.f90'
include 'ch2701_link_module.f90'

program ch2701
  use precision_module
  use link_module
  implicit none
  integer, parameter :: wp = dp
  type (link(real_kind=wp)), pointer :: root, &
current
  integer :: i = 0
  integer :: error = 0
  integer :: io_stat_number = 0
  real (wp), allocatable, dimension (:) :: x

  allocate (root)
  print *, ' type in some numbers'
  read (unit=*, fmt=*, iostat=io_stat_number) &
root%n
  if (io_stat_number>0) then
error = error + 1
  else if (io_stat_number<0) then
nullify (root%next)
  else
i = i + 1
allocate (root%next)
  end if
  current => root
  do while (associated(current%next))
current => current%next
read (unit=*, fmt=*, iostat=io_stat_number) &
  current%n
if (io_stat_number>0) then
  error = error + 1
else if (io_stat_number<0) then
  nullify (current%next)
else
  i = i + 1
  allocate (current%next)
end if
  end do
  print *, i, ' items read'
  print *, error, ' items in error'
  allocate (x(1:i))
  i = 1
  current => root
  do while (associated(current%next))
x(i) = current%n
i = i + 1
print *, current%n
current => current%next
  end do
  print *, x
end program ch2701

I have attached the three source files, ch2701.f90, precision_module.f90 and
ch2701_link_module.f90. here is the error message. 

c:\document\fortran\fourth_edition\examples>gfortran -v ch2701.f90
Driving: gfortran -v ch2701.f90 -l gfortran
Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/8.0.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-8-20170917-mingw/configure --host=x86_64-w64-mingw32
--build=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/gcc/8-20170917
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_64/gcc/8-20170709
--with-gcc --with-gnu-ld --with-gnu-as --with-ld64=no
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpfr
--with-mpc=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpc
--with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/cloog
--with-diagnostics-color=auto-if-env --enable-cloog-backend=isl
--enable-targets=i686-w64-mingw32,x86_64-w64-mingw32 --enable-lto
--enable-languages=c,c++,fortran --enable-threads=win32 --enable-static
--enable-shared=lto-plugin --enable-plugins --enable-ld=yes
--enable-libquadmath --enable-libquadmath-support --enable-libgomp
--disable-checking --disable-nls --disable-tls --disable-win32-registry
Thread model: win32
gcc version 8.0.0 20170917 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 c:/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/8.0.0/f951.exe ch2701.f90 -quiet
-dumpbase ch2701.f90 -mtune=generic -march=x86-64 -auxbase ch2701 -version
-fintrinsic-modules-path
c:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/8.0.0/finclude -o
C:\Users\ian\AppData\Local\Temp\cc8gUhjd.s
GNU Fortran (GCC) version 8.0.0 20170917 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 8.0.0 20170709 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 8.0.0 20170917 (experimental)
(x86_64-w64-mingw32)
compiled by GNU C version 8.0.0 20170709 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ch2701.f90:9:27:

   type (link(real_kind=wp)), pointer :: root, &
   1
Error: The derived parameter ''real_kind'' at (1) does not have a default value
ch2701.f90:16:12:

   allocate (root)
1
Error: Allocate-object at (1) is neither a data pointer nor an allocatable
variable
ch2701.f90:19:9:

 root%n
 1
Error: Symbol 'root' at (1) has no IMPLICIT type
ch2701.f90:23:18:

 nullify (root%next)
  1
Error: Symbol 'root' at (1) has no IMPLICIT type
ch2701.f90:26:19:

 

[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow with a small power-of-2 size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|missing |missing
   |-Wstringop-overflow= on a   |-Wstringop-overflow= on a
   |memcpy overflow |memcpy overflow with a
   ||small power-of-2 size

--- Comment #3 from Martin Sebor  ---
The cause is of the missing warning is the folder
(gimple_fold_builtin_memory_op in gimple-fold.c) folding all copies with
power-of-two sizes less than MOVE_MAX, with no checking (see below).  MOVE_MAX
is typically 8 or 8 but on some targets, including x86_64, it's as much as 16. 
Although some basic simple checking could be done there, e.g., on arrays of
known size, the folder runs before the full object size information is
available and deferring the folding until it apparently isn't desirable.

  /* If we can perform the copy efficiently with first doing all loads
 and then all stores inline it that way.  Currently efficiently
 means that we can load all the memory into a single integer
 register which is what MOVE_MAX gives us.  */
  src_align = get_pointer_alignment (src);
  dest_align = get_pointer_alignment (dest);
  if (tree_fits_uhwi_p (len)
  && compare_tree_int (len, MOVE_MAX) <= 0
  /* ???  Don't transform copies from strings with known length this
 confuses the tree-ssa-strlen.c.  This doesn't handle
 the case in gcc.dg/strlenopt-8.c which is XFAILed for that
 reason.  */
  && !c_strlen (src, 2))
{
  unsigned ilen = tree_to_uhwi (len);
  if (pow2p_hwi (ilen))
{

[Bug libstdc++/41861] [DR 887][C++0x] does not use monotonic_clock

[mac at mcrowe dot com]

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

--- Comment #15 from Mike Crowe  ---
(In reply to Mike Crowe from comment #14)
> I submitted an RFC glibc patch last year:
> http://patchwork.ozlabs.org/project/glibc/list/?submitter=66786

I submitted an updated version earlier this year:

 https://sourceware.org/ml/libc-alpha/2017-06/msg0.html

There are a few minor niggles to address, but it seems that the greater hurdle
now is that two respondents have requested that I raise this with the Austin
Group. So, I have done so at:

 http://austingroupbugs.net/view.php?id=1164

If this attempt fails, then I think it would be preferable to switch libstdc++
std::condition_variable to use std::chrono::steady_clock as its primary clock
(along with the necessary changes in gthreads to support creating a condition
variable using CLOCK_MONOTONIC) and convert all other clocks to that clock. I
personally think it's more surprising that:

 cv.wait_for(std::chrono::seconds(2));

risks waiting for potentially huge amount of time if someone changes the system
clock, than

 cv.wait_until(std::chrono::system_clock::now() + std::chrono::seconds(2));

waiting for two seconds if someone changes the system clock just afterwards so
that the wait should return immediately.

[Bug fortran/82376] New: Duplicate function call using -fcheck=pointer

[jrfsousa at hotmail dot com]

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

Bug ID: 82376
   Summary: Duplicate function call using -fcheck=pointer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at hotmail dot com
  Target Milestone: ---

Created attachment 42268
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42268&action=edit
Code showing the bug

Allocating procedure gets called twice (and leaks) using -fcheck=pointer

$ gfortran -cpp ./bug.f90
$ ./a.out 
 ** typea_new
   3.1410
$ gfortran -DNOBUG -cpp -fcheck=pointer ./bug.f90
$ ./a.out 
 ** typea_new
   3.1410
$ gfortran -cpp -fcheck=pointer ./bug.f90
$ ./a.out 
 ** typea_new
 ** typea_new
   3.1410

$ gfortran --version
GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.

$ gfortran --version
GNU Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.

Best regards,
José Rui

[Bug tree-optimization/82377] New: wrong code at -O1 and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 82377
   Summary: wrong code at -O1 and above on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170930 (experimental) [trunk revision 253320] (GCC)
$
$ gcctk -O0 small.c; ./a.out
0
$ gcc-7.2.0 -O1 small.c; ./a.out
0
$
$ gcctk -O1 small.c
$ ./a.out
1
$


-


int printf (const char *, ...);

struct A
{ 
  int b;
  int c;
  int d;
  int e;
  int f;
  long g;
} h;

int i;

void o (int m)
{ 
  struct A p[9] = { { 1, 0, 0, 0, 0, 0 } };
  h = p[3];
}

void n (int q)
{ 
  o (i);
}

void l ()
{ 
  n (i);
}

void r ()
{ 
  l ();
  if (!i)
return;
  while (1)
;
}

int main ()
{ 
  r ();
  printf ("%d\n", h.b);
  return 0;
}

[Bug c++/68754] Explicitly defaulted constexpr assignment operator fails to compile

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Sep 30 17:00:32 2017
New Revision: 253321

URL: https://gcc.gnu.org/viewcvs?rev=253321&root=gcc&view=rev
Log:
/cp
2017-09-30  Paolo Carlini  

PR c++/68754
* method.c (defaulted_late_check): Early return if the defaulted
declaration does not match the expected signature.

/testsuite
2017-09-30  Paolo Carlini  

PR c++/68754
* g++.dg/cpp1y/constexpr-68754.C: Move...
* g++.dg/cpp0x/constexpr-68754.C: ... here, adjust.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-68754.C
  - copied, changed from r253320,
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-68754.C
Removed:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-68754.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68754] Explicitly defaulted constexpr assignment operator fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #7 from Paolo Carlini  ---
C++11 diagnostic improved in trunk.

[Bug libfortran/82378] New: Data race in libgfortran with OpenMP

[tkoenig at gcc dot gnu.org]

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

Bug ID: 82378
   Summary: Data race in libgfortran with OpenMP
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Building an instrumented gfortran with

make -j4 CFLAGS="-std=gnu99 -g -O2 -fsanitize=thread "  FCFLAGS="-g -O2
-fsanitize=thread" CXXFLAGS="-std=gnu99 -g -O2 -fsanitize=thread "
LDFLAGS="-B`pwd`/../libsanitizer/tsan/.libs/
-Wl,-rpath,`pwd`/../libsanitizer/tsan/.libs/ -fsanitize=thread" && make install

and then compiling the test case

program main
  use omp_lib
  !$OMP PARALLEL NUM_THREADS(100)
  call file_open(OMP_get_thread_num())
  !$OMP END PARALLEL 
contains
  recursive subroutine file_open(i)
  integer :: i
  integer :: nunit
  nunit = i + 20
  write (nunit,*) 'asdf',i
  end subroutine file_open
end program main

with

gfortran -fopenmp -fsanitize=thread open.f90

yields quite a few data races like

==
WARNING: ThreadSanitizer: data race (pid=1719)
  Read of size 4 at 0x3fff48527330 by main thread (mutexes: write M19):
#0 close_unit_1 ../../../trunk/libgfortran/io/unit.c:703
(libgfortran.so.5+0x0019b8e8)
#1 _gfortrani_close_units ../../../trunk/libgfortran/io/unit.c:771
(libgfortran.so.5+0x0019bd64)
#2 cleanup ../../../trunk/libgfortran/runtime/main.c:113
(libgfortran.so.5+0x00036948)
#3   (ld64.so.1+0x00018a9c)

  Previous write of size 4 at 0x3fff48527330 by thread T67 (mutexes: write
M99):
#0 finalize_transfer ../../../trunk/libgfortran/io/transfer.c:3934
(libgfortran.so.5+0x00198e34)
#1 _gfortran_st_write_done ../../../trunk/libgfortran/io/transfer.c:4125
(libgfortran.so.5+0x00199280)
#2   (a.out+0x1e58)
#3   (a.out+0x1000103c)
#4 gomp_thread_start ../../../trunk/libgomp/team.c:120
(libgomp.so.1+0x0001fd84)

  Location is heap block of size 744 at 0x3fff48527300 allocated by thread T67:
#0 calloc ../../../../trunk/libsanitizer/tsan/tsan_interceptors.cc:606
(libtsan.so.0+0x000479d8)
#1 _gfortrani_xcalloc ../../../trunk/libgfortran/runtime/memory.c:83
(libgfortran.so.5+0x0003f76c)
#2 insert_unit ../../../trunk/libgfortran/io/unit.c:230
(libgfortran.so.5+0x0019a1a8)
#3 get_gfc_unit ../../../trunk/libgfortran/io/unit.c:350
(libgfortran.so.5+0x0019a644)
#4 _gfortrani_get_unit ../../../trunk/libgfortran/io/unit.c:568
(libgfortran.so.5+0x0019c238)
#5 data_transfer_init ../../../trunk/libgfortran/io/transfer.c:2680
(libgfortran.so.5+0x001972b0)
#6 _gfortran_st_write ../../../trunk/libgfortran/io/transfer.c:4116
(libgfortran.so.5+0x00198984)
#7   (a.out+0x1e14)
#8   (a.out+0x1000103c)
#9 gomp_thread_start ../../../trunk/libgomp/team.c:120
(libgomp.so.1+0x0001fd84)

  Mutex M19 (0x3fff7fb5fc40) created at:
#0 pthread_mutex_lock
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3608
(libtsan.so.0+0x0006329c)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:748
(libgfortran.so.5+0x0019a390)
#2 get_gfc_unit ../../../trunk/libgfortran/io/unit.c:327
(libgfortran.so.5+0x0019a390)
#3 _gfortrani_get_unit ../../../trunk/libgfortran/io/unit.c:568
(libgfortran.so.5+0x0019c238)
#4 data_transfer_init ../../../trunk/libgfortran/io/transfer.c:2680
(libgfortran.so.5+0x001972b0)
#5 _gfortran_st_write ../../../trunk/libgfortran/io/transfer.c:4116
(libgfortran.so.5+0x00198984)
#6   (a.out+0x1e14)
#7   (a.out+0x1000103c)
#8 GOMP_parallel ../../../trunk/libgomp/parallel.c:168
(libgomp.so.1+0x00016c10)
#9   (a.out+0x1f8c)
#10   (libc.so.6+0x00046be8)

  Mutex M99 (0x3fff485273d8) created at:
#0 pthread_mutex_lock
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3608
(libtsan.so.0+0x0006329c)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:748
(libgfortran.so.5+0x0019a228)
#2 insert_unit ../../../trunk/libgfortran/io/unit.c:240
(libgfortran.so.5+0x0019a228)
#3 get_gfc_unit ../../../trunk/libgfortran/io/unit.c:350
(libgfortran.so.5+0x0019a644)
#4 _gfortrani_get_unit ../../../trunk/libgfortran/io/unit.c:568
(libgfortran.so.5+0x0019c238)
#5 data_transfer_init ../../../trunk/libgfortran/io/transfer.c:2680
(libgfortran.so.5+0x001972b0)
#6 _gfortran_st_write ../../../trunk/libgfortran/io/transfer.c:4116
(libgfortran.so.5+0x00198984)
#7   (a.out+0x1e14)
#8   (a.out+0x1000103c)
#9 gomp_thread_start ../../../trunk/libgomp/team.c:120
(libgomp.so.1+0x0001fd84)

  Thread T67 (tid=1789, running) created by main thread at:
#0 pthread_create
../../../../trunk/libsanitizer/tsan/tsan_interceptors.cc:900
(libtsan

[Bug middle-end/82362] [8 Regression] SPEC CPU2006 436.cactusADM ~7% performance deviation with trunk@251713

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|WAITING |UNCONFIRMED
  Component|fortran |middle-end
 Ever confirmed|1   |0

[Bug libfortran/82378] Data race in libgfortran with OpenMP

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
The races do not happen for

program main
  use omp_lib
  !$OMP PARALLEL NUM_THREADS(100)
  call file_open(OMP_get_thread_num())
  !$OMP END PARALLEL 
contains
  recursive subroutine file_open(i)
  integer :: i
  integer :: nunit
  nunit = i + 20
  write (nunit,*) 'asdf',i
  close (nunit)
  end subroutine file_open
end program main

so it might be advisable to close files local to a thread as
a workaround.

[Bug tree-optimization/81958] spurious -Wmaybe-uninitialized warning in gcc-8, or with -O1

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-30
 CC||law at redhat dot com
 Blocks||19794
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
So I see a couple things here.

In DOM we do catch the fact that eqidx will have the value zero if the loop
does not iterate.  But the equivalence we record is actually eqidx >= maxidx. 
That's because we don't cprop into the conditionals in
record_temporary_equivalences.  We *should* do that, but we have to be careful
about structure sharing and I'd like to avoid creating a lot of unnecessary
tree nodes if it can be avoided.

If we were to fix that, we'd end recording maxidx <= 0.  Given that maxidx is
unsigned that simplifies into maxidx == 0.  Of course we don't those kind of
simplifications when recording the temporary equivalences either and the same
concerns WRT structure sharing come into play.

When things simplify into something like maxidx == 0, instead of recording a
conditional into the equivalency tables, we should record that maxidx = 0 in
the const/copies table.

If we were to fix those 3 issues, then I think we have all the key pieces in
place to see the jump thread.  But we still have to be concerned that jump
threading may be suppressed because of its conservatism WRT not clobbering the
loop structure.  It should be safe in this case, but I don't offhand know if
the  suppression code would kick in or not.

So, anyway, there's several TODO items in here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
[Bug 19794] [meta-bug] Jump threading related bugs

[Bug c++/65870] Explicit function instantiation with default valued lambda causes duplicate symbol

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Paolo Carlini  ---
Dup indeed.

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

[Bug c++/59949] lambda expression as default argument of function template causes "already defined" messages in assembler

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||w.shane.grant at gmail dot com

--- Comment #6 from Paolo Carlini  ---
*** Bug 65870 has been marked as a duplicate of this bug. ***

[Bug c++/65949] Compiler can not deduce auto type in lambda

[paolo at gcc dot gnu.org]

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

--- Comment #1 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Sep 30 20:42:05 2017
New Revision: 253322

URL: https://gcc.gnu.org/viewcvs?rev=253322&root=gcc&view=rev
Log:
2017-09-30  Paolo Carlini  

PR c++/65949
* g++.dg/cpp1y/lambda-generic-variadic5.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic5.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/65949] Compiler can not deduce auto type in lambda

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.3

--- Comment #2 from Paolo Carlini  ---
This is fixed in trunk and gcc-7-branch. To be safe I added a compile-time test
and I'm closing the bug.

[Bug fortran/82376] Duplicate function call using -fcheck=pointer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-30
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.5 up to trunk (8.0). -fcheck=pointer is not available in 4.4.

[Bug c++/67370] Invalid "parameter packs not expanded" error in lambda capture

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-30
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Paolo Carlini  ---
Interestingly, it's still an issue in trunk.

[Bug fortran/82375] PDT error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-30
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Reduced test

module precision_module
  implicit none
  integer, parameter :: sp = selected_real_kind(6, 37)
  integer, parameter :: dp = selected_real_kind(15, 307)
  integer, parameter :: qp = selected_real_kind( 30, 291)
end module precision_module

module link_module
  use precision_module
  type link(real_kind)
integer, kind :: real_kind
real (kind=real_kind) :: n
type (link(real_kind)), pointer :: next
  end type link
end module link_module

program ch2701
  use precision_module
  use link_module
  implicit none
  integer, parameter :: wp = dp
  type (link(real_kind=wp)), pointer :: root, current
end program ch2701

Note the double quote due to 

  gfc_error ("The derived parameter '%qs' at %C does not "
 "have a default value", param->name);

in fortran/decl.c.

[Bug c++/59949] lambda expression as default argument of function template causes "already defined" messages in assembler

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||kirit.saelensminde at gmail 
dot co
   ||m

--- Comment #7 from Paolo Carlini  ---
*** Bug 78919 has been marked as a duplicate of this bug. ***

[Bug c++/78919] Lambdas, default parameters and std::function cause assembly error

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Paolo Carlini  ---
Dup.

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

[Bug sanitizer/82379] New: internal_sigreturn not defined in libasan.so or libubsan.so with -mx32

[steven at uplinklabs dot net]

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

Bug ID: 82379
   Summary: internal_sigreturn not defined in libasan.so or
libubsan.so with -mx32
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven at uplinklabs dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

The symbol "internal_sigreturn" isn't defined when building for the x32 ABI on
x86_64:

$ cat test.c
int main(){ return 0; }

$ gcc -mx32 -fsanitize=address -o test test.c
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../libx32/libasan.so: undefined
reference to `internal_sigreturn'
collect2: error: ld returned 1 exit status

$ gcc -mx32 -fsanitize=undefined -o test test.c
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../libx32/libubsan.so:
undefined reference to `internal_sigreturn'
collect2: error: ld returned 1 exit status

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu 
Configured with: /build/gcc-multilib/src/gcc/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://www.uplinklabs.net/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --disable-libssp
--disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror
--enable-__cxa_atexit --enable-checking=release --enable-clocale=gnu
--enable-gnu-indirect-function --enable-gnu-unique-object
--enable-initfini-array --enable-install-libiberty --enable-libmpx
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --with-isl --with-linker-hash-style=gnu
--with-multilib-list=m32,m64,mx32 --with-system-zlib 
Thread model: posix 
gcc version 7.2.1 20170929 (GCC)

My GCC was built from latest in gcc-7-branch yesterday.


Defining something like this in my application does technically work, but
really shouldn't be necessary:

void (*internal_sigreturn)(void) = 0;

[Bug middle-end/82365] stack locations are consolidated if noreturn function is on the path

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-30
  Component|other   |middle-end
Summary|excessive stack usage with  |stack locations are
   |norreturn attribute |consolidated if noreturn
   ||function is on the path
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
here is a reduced testcase to show the issue a lot better:
#define __noreturn __attribute__((noreturn))

struct i2c_board_info {
char type[20];
char pad[100];
};

#ifdef NONORETURN
void fortify_panic();
#else
void fortify_panic() __noreturn;
#endif


int f(int a)
{
  if (a)
fortify_panic();
}


void i2c_new_device(struct i2c_board_info *);
int em28xx_dvb_init(int model, int a, int b, int c, int d)
{
switch (model) {
case 1:{
struct i2c_board_info info = {};
f(a);
i2c_new_device(&info);
break;
}
case 2:{
struct i2c_board_info info = {};
f(b);
i2c_new_device(&info);
break;
}
case 3:{
struct i2c_board_info info = { };
f(c);
i2c_new_device(&info);
break;
}
case 4:{
struct i2c_board_info info = { };
f(d);
i2c_new_device(&info);
break;
}
}
return 0;
}

Basically the noreturn function is not considered a barrier for the info so the
middle-end thinks all of the info can overlap in scope.

[Bug middle-end/82365] stack locations are consolidated if noreturn function is on the path

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Basically someone needs to look into add_scope_conflicts (in gimplecfg.c) to
see the scope conflict is being added.

[Bug fortran/45513] BOZ kinds differently handled, F2008: BOZ in bit intrinsics

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Related to/duplicate of pr81509.

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
Related to/duplicate of pr81509.

[Bug ipa/77732] FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from John David Anglin  ---
Resolved by xfail.

[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-01
 CC||m.ostapenko at samsung dot com
Summary|internal_sigreturn not  |[7/8 Regression]
   |defined in libasan.so or|internal_sigreturn not
   |libubsan.so with -mx32  |defined in libasan.so or
   ||libubsan.so with -mx32
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
This caused by r241977:

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index 05ead765e62..8d884f4bf52 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -20,12 +20,14 @@

 # Filter out unsupported systems.
 TSAN_TARGET_DEPENDENT_OBJECTS=
+SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS=
 case "${target}" in
   x86_64-*-linux* | i?86-*-linux*)
if test x$ac_cv_sizeof_void_p = x8; then
TSAN_SUPPORTED=yes
LSAN_SUPPORTED=yes
TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_amd64.lo
+  
SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS=sanitizer_linux_x86_64.lo
fi
;;
   powerpc*-*-linux*)

This is wrong for x32.

[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
Created attachment 42269
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42269&action=edit
A patch

I am testing this.

[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-01
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, probably because optimization lets gcc take advantage of knowledge
that f1 doesn't actually use its parameter:

$ /usr/local/bin/gcc -c -Wall -Wextra -O1 80147.c
80147.c: In function ‘f1’:
80147.c:2:21: warning: unused parameter ‘i’ [-Wunused-parameter]
 static void f1 (int i) { }
 ^
80147.c: In function ‘g’:
80147.c:8:2: warning: ‘i1’ is used uninitialized in this function
[-Wuninitialized]
  f1 (i1);
  ^~~
80147.c:9:2: warning: ‘i2’ is used uninitialized in this function
[-Wuninitialized]
  f2 (i2);
  ^~~
80147.c:3:26: warning: ‘j2’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 static void f2 (int i) { f0 (i); }
  ^~
80147.c:7:18: note: ‘j2’ was declared here
  int i1, i2, j1, j2;
  ^~
$

...but if that's the case, then why doesn't the warning go away for i1, too?

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 79768, which changed state.

Bug 79768 Summary: `-Wmaybe-uninitialized' false positive with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768

   What|Removed |Added

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

[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
I can't reproduce the bug with gcc trunk; neither the original nor the
preprocessed source give me any warnings. Feel free to reopen if it still
happens for you.

[Bug middle-end/70246] Spurious -Wmaybe-uninitialized warnings with -O1

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
(In reply to Mike Jarvis from comment #4)
> Created attachment 37984 [details]
> An alternate source that uses a custom Complex class
> 
> OK, here is a version that rolls its own Complex class, rather than using
> the standard library's complex.  I stripped out the parts of that
> that aren't relevant for this, so hopefully this is small enough for you.
> 
> A possible clue is that the warning goes away if Complex is implemented in
> terms of double _x and double _y (as the normal template version of
> std::complex does) rather than __complex__ double _z (as the specialization
> std::complex does).

I can't reproduce this bug with current gcc; this source produces no warnings
for me when I compile it. Feel free to reopen if you still get the warning.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 70246, which changed state.

Bug 70246 Summary: Spurious -Wmaybe-uninitialized warnings with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246

   What|Removed |Added

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

[Bug middle-end/51544] uninitialized variable false positive prevents bootstrap with -fipa-cp-clone

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Eric Gallager  ---
(In reply to David Binderman from comment #5)
> (In reply to comment #3)
> > I've been trying to bootstrap using "-g -O3" in BOOT_CFLAGS. 
> > That doesn't work, but "-g -O2" of course does.
> 
> I am pleased to be able to say that BOOT_CFLAGS= -g -O3
> works for revision 196574 (Sat 09 March 2013).
> 
> I'll use this as my new default build setting,
> so when it stops working I'll be able to put in a bug report.
> 
> This is a long way from -g -O3 being the default
> for all architectures, but it is a good step forward.
> 
> I think this bug is fixed.

OK, closing as FIXED then.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 51544, which changed state.

Bug 51544 Summary: uninitialized variable false positive prevents bootstrap 
with -fipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51544

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/53480] warning "may be used uninitialized" issued with -m32 but not with -m64

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #2)
> In GCC 4.7.0 and above, it does not warn with -m32 or -m64.

Yeah I don't get this warning with current gcc either; I'm going to close it as
WORKSFORME.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 53480, which changed state.

Bug 53480 Summary: warning "may be used uninitialized" issued with -m32 but not 
with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53480

   What|Removed |Added

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

[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32

[steven at uplinklabs dot net]

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

--- Comment #3 from Steven Noonan  ---
Are you sure that patch is sufficient? __x86_64__ is defined on both the normal
x86_64 ABI and on the x32 ABI. The combination most often used to identify x32
is 'defined(__x86_64__) && defined(__ILP32__)'

I've currently got this patch applied locally which allows me to build against
the x32 ABI with -fsanitize=foo:

diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc
b/libsanitizer/sanitizer_common/sanitizer_linux.cc
index 5b6f18602e7..a11592614a4 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
@@ -674,7 +674,7 @@ int internal_sigaction_syscall(int signum, const void *act,
void *oldact) {
 return internal_sigaction_norestorer(signum, act, oldact);
   __sanitizer_sigaction u_adjust;
   internal_memcpy(&u_adjust, act, sizeof(u_adjust));
-#if !SANITIZER_ANDROID || !SANITIZER_MIPS32
+#if (!SANITIZER_ANDROID || !SANITIZER_MIPS32) && !defined(__ILP32__)
 if (u_adjust.sa_restorer == nullptr) {
   u_adjust.sa_restorer = internal_sigreturn;
 }

[Bug c++/82380] New: [concepts] Error when using requires constraint with attributes

[ryan.burn at gmail dot com]

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

Bug ID: 82380
   Summary: [concepts] Error when using requires constraint with
attributes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

I believe the below code should work but it gives me the error:

main.cpp:6:1: error: two consecutive '[' shall only introduce an attribute
before '[' token
 [[nodiscard]] int f(T t) {
 ^

tested with gcc head 8.0.0 201709

///
template 
concept bool C = true;

template 
  requires C
[[nodiscard]] int f(T t) {
  return 22;
}

int main() {
  return 0;
}
///

[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Steven Noonan from comment #3)
> Are you sure that patch is sufficient? __x86_64__ is defined on both the
> normal x86_64 ABI and on the x32 ABI. The combination most often used to
> identify x32 is 'defined(__x86_64__) && defined(__ILP32__)'
> 
> I've currently got this patch applied locally which allows me to build
> against the x32 ABI with -fsanitize=foo:
> 
> diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc
> b/libsanitizer/sanitizer_common/sanitizer_linux.cc
> index 5b6f18602e7..a11592614a4 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
> +++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
> @@ -674,7 +674,7 @@ int internal_sigaction_syscall(int signum, const void
> *act, void *oldact) {
>  return internal_sigaction_norestorer(signum, act, oldact);
>__sanitizer_sigaction u_adjust;
>internal_memcpy(&u_adjust, act, sizeof(u_adjust));
> -#if !SANITIZER_ANDROID || !SANITIZER_MIPS32
> +#if (!SANITIZER_ANDROID || !SANITIZER_MIPS32) && !defined(__ILP32__)
>  if (u_adjust.sa_restorer == nullptr) {
>u_adjust.sa_restorer = internal_sigreturn;
>  }

I don't believe this is correct. Please try my patch.

[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32

[steven at uplinklabs dot net]

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

--- Comment #5 from Steven Noonan  ---
(In reply to H.J. Lu from comment #4)
> (In reply to Steven Noonan from comment #3)
> > Are you sure that patch is sufficient? __x86_64__ is defined on both the
> > normal x86_64 ABI and on the x32 ABI. The combination most often used to
> > identify x32 is 'defined(__x86_64__) && defined(__ILP32__)'
> > 
> > I've currently got this patch applied locally which allows me to build
> > against the x32 ABI with -fsanitize=foo:
> > 
> > diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc
> > b/libsanitizer/sanitizer_common/sanitizer_linux.cc
> > index 5b6f18602e7..a11592614a4 100644
> > --- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
> > +++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
> > @@ -674,7 +674,7 @@ int internal_sigaction_syscall(int signum, const void
> > *act, void *oldact) {
> >  return internal_sigaction_norestorer(signum, act, oldact);
> >__sanitizer_sigaction u_adjust;
> >internal_memcpy(&u_adjust, act, sizeof(u_adjust));
> > -#if !SANITIZER_ANDROID || !SANITIZER_MIPS32
> > +#if (!SANITIZER_ANDROID || !SANITIZER_MIPS32) && !defined(__ILP32__)
> >  if (u_adjust.sa_restorer == nullptr) {
> >u_adjust.sa_restorer = internal_sigreturn;
> >  }
> 
> I don't believe this is correct.

If you mean the patch itself, then I agree. It was just what happened to
unblock me.

> Please try my patch.

I gave your patch a second look and I see why it'd work now
("x$ac_cv_sizeof_void_p = x8" would be false on x32). I'm building GCC with
your patch now, it'll be a while.

[Bug go/82348] make[4]: Circular runtime.lo <- bytes.gox dependency dropped.

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor  ---
The bug is that something is requiring internal/cpu.gox.  Nothing should
require it.

There is only one mention of internal/cpu in the math package, in the
floor_asm.go file, but that file has a build tag that should cause it to be
always ignored.

If you remove math.lo.dep, and then run `make math.lo.dep`, you should see a
command like

/bin/mkdir -p .; dir=`echo math.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh
../../../gccgo/libgo/match.sh --goarch=amd64 --goos=linux
--srcdir=../../../gccgo/libgo/go/$dir --extrafiles="" `; /bin/sh
../../../gccgo/libgo/godeps.sh `echo math.lo.dep | sed -e 's/.dep$//'` $files >
math.lo.dep.tmp; if ! cmp math.lo.dep.tmp math.lo.dep >/dev/null 2>/dev/null;
then rm -f `echo math.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f math.lo.dep.tmp
math.lo.dep

Run the command

/bin/sh ../../../gccgo/libgo/match.sh --goarch=amd64 --goos=linux
--srcdir=../../../gccgo/libgo/go/$dir --extrafiles=""

to see what files is set to.  Then run

/bin/sh ../../../gccgo/libgo/godeps.sh `echo math.lo.dep | sed -e 's/.dep$//'`
$files

to see what winds up in math.lo.dep.  Somewhere in there something has gone
wrong.

On my system math.lo.dep is

math.lo: ../../../gccgo3/libgo/go/math/abs.go
../../../gccgo3/libgo/go/math/acosh.go ../../../gccgo3/libgo/go/math/asin.go
../../../gccgo3/libgo/go/math/asinh.go ../../../gccgo3/libgo/go/math/atan.go
../../../gccgo3/libgo/go/math/atan2.go ../../../gccgo3/libgo/go/math/atanh.go
../../../gccgo3/libgo/go/math/bits.go ../../../gccgo3/libgo/go/math/cbrt.go
../../../gccgo3/libgo/go/math/const.go
../../../gccgo3/libgo/go/math/copysign.go ../../../gccgo3/libgo/go/math/dim.go
../../../gccgo3/libgo/go/math/erf.go ../../../gccgo3/libgo/go/math/exp.go
../../../gccgo3/libgo/go/math/expm1.go ../../../gccgo3/libgo/go/math/floor.go
../../../gccgo3/libgo/go/math/frexp.go ../../../gccgo3/libgo/go/math/gamma.go
../../../gccgo3/libgo/go/math/hypot.go ../../../gccgo3/libgo/go/math/j0.go
../../../gccgo3/libgo/go/math/j1.go ../../../gccgo3/libgo/go/math/jn.go
../../../gccgo3/libgo/go/math/ldexp.go ../../../gccgo3/libgo/go/math/lgamma.go
../../../gccgo3/libgo/go/math/log.go ../../../gccgo3/libgo/go/math/log10.go
../../../gccgo3/libgo/go/math/log1p.go ../../../gccgo3/libgo/go/math/logb.go
../../../gccgo3/libgo/go/math/mod.go ../../../gccgo3/libgo/go/math/modf.go
../../../gccgo3/libgo/go/math/nextafter.go ../../../gccgo3/libgo/go/math/pow.go
../../../gccgo3/libgo/go/math/pow10.go
../../../gccgo3/libgo/go/math/remainder.go
../../../gccgo3/libgo/go/math/signbit.go ../../../gccgo3/libgo/go/math/sin.go
../../../gccgo3/libgo/go/math/sincos.go ../../../gccgo3/libgo/go/math/sinh.go
../../../gccgo3/libgo/go/math/sqrt.go ../../../gccgo3/libgo/go/math/tan.go
../../../gccgo3/libgo/go/math/tanh.go ../../../gccgo3/libgo/go/math/unsafe.go


which has no internal/cpu.gox.

[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32

[steven at uplinklabs dot net]

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

--- Comment #6 from Steven Noonan  ---
Seems to resolve the link issue. Not sure how to test that internal_sigreturn
does what it should, though.