[Bug fortran/66089] [7/8 Regression] elemental dependency mishandling when class array are involved

[tkoenig at gcc dot gnu.org]

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

--- Comment #40 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 14:03:00 2019
New Revision: 269725

URL: https://gcc.gnu.org/viewcvs?rev=269725=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/66089
Backport from trunk
* trans-array.c (gfc_scalar_elemental_arg_saved_as_reference):
Return false if a scalar tempoary is needed.
(gfc_walk_variable_expr): Fix up class refs.

2019-03-16  Thomas Koenig  

PR fortran/66089
Backport from trunk
* gfortran.dg/dependency_53.f90: New test.
* gfortran.dg/assumed_type_2.f90: Adapted tree dumps.
* gfortran.dg/no_arg_check_2.f90: Likewise.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dependency_53.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-array.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/assumed_type_2.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/no_arg_check_2.f90

[Bug fortran/66089] [7/8 Regression] elemental dependency mishandling when class array are involved

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #41 from Thomas Koenig  ---
Fixed on all open branches, closing.

[Bug target/89736] New: New test pr87532-mc.c fails on compiler not defaulting to VSX

[segher at gcc dot gnu.org]

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

Bug ID: 89736
   Summary: New test pr87532-mc.c fails on compiler not defaulting
to VSX
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

Hi Kelvin,

The test does not only run on VSX on purpose:

/* This test should run the same on any target that supports altivec/dfp
   instructions.  Intentionally not specifying cpu in order to test
   all code generation paths.  */

OTOH, it does use "vector long long", which requires VSX.  And vector int128.
DFP seems to be a red herring?

I'm not sure what best to do here; maybe cut the test in two?

[Bug target/89736] New test pr87532-mc.c fails on compiler not defaulting to VSX

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target||powerpc*-*-*
   Priority|P3  |P5
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-16
   Assignee|unassigned at gcc dot gnu.org  |kelvin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[janisozaur+gcc at gmail dot com]

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

janisozaur+gcc at gmail dot com changed:

   What|Removed |Added

 CC||janisozaur+gcc at gmail dot com

--- Comment #37 from janisozaur+gcc at gmail dot com ---
Hi, I ran into what I think is a variant of this bug.

Here's the problem presented with godbolt: https://godbolt.org/z/SP-4uG

And the contents of that link, as reproduced on my machine, are:

#include 
#include 
static const std::wstring_view foo = L"foo";
static constexpr std::wstring_view bar = L"bar";

$ g++ --version
g++ (GCC) 8.2.1 20181127
$ g++ -c test.cpp -Wall -Wextra -std=c++17 # exit code 0
$ gcc9/bin/g++ --version
g++ (GCC) 9.0.1 20190225 (experimental)
$ gcc9/bin/g++ -c test.cpp -Wall -Wextra -std=c++17 # exit code 0
$ clang++ --version
clang version 7.0.1 (tags/RELEASE_701/final)
$ clang++ -c -Wall -Wextra test.cpp -std=c++17 -Wno-unused-const-variable
-stdlib=libc++ # exit code 0
$ clang++ -c -Wall -Wextra test.cpp -std=c++17
test.cpp:4:36: error: constexpr variable 'bar' must be initialized by a
constant expression
static constexpr std::wstring_view bar = L"bar";
   ^ ~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/char_traits.h:431:11:
note: non-constexpr function 'wcslen' cannot be used in a constant expression
  return wcslen(__s);
 ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/string_view:100:39:
note: in call to 'length("bar"[0])'
  : _M_len{__str == nullptr ? 0 : traits_type::length(__str)},
  ^
test.cpp:4:42: note: in call to 'basic_string_view("bar"[0])'
static constexpr std::wstring_view bar = L"bar";
 ^
1 error generated.

Relevant piece of code from libstdc++:
https://github.com/gcc-mirror/gcc/blob/9fb89fa845c1b2e0a18d85ada0b077c84508ab78/libstdc%2B%2B-v3/include/bits/char_traits.h#L426-L431

Unfortunately, I can't really test clang with libstdc++ trunk. Please let me
know if it is sufficient to leave this comment here or should I open another
ticket?

[Bug testsuite/89393] [9 Regression] FAIL: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ZGR1bIvE

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #4 from John David Anglin  ---
// { dg-require-weak "" }
doesn't work on this target.  There is partial weak support using comdat.

So, I skipped test on 32-bit hppa*-*-hpux*.

[Bug c/89738] New: Warn for unused macro arguments

[david.bolvansky at gmail dot com]

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

Bug ID: 89738
   Summary: Warn for unused macro arguments
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

I found a nasty bug in my code which was related to unused macro arguments.

#define PARENT_NODE(x) ((id - 1) / 2)

As you can see, the "id" macro argument was unused. The code worked fine, since
id matched id in the code. 

Then I reused this macro in the other project and bum, the "id" variable
unfortunely existed too, but now I used the macro as eg. PARENT_NODE(idx).

Any changes for diagnostics for this case?

[Bug fortran/77746] [7/8 Regression] [F03] Wrong subroutine called, clash of specific procedure name and binding-name

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 13:24:40 2019
New Revision: 269723

URL: https://gcc.gnu.org/viewcvs?rev=269723=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.h (gfc_symbol): Add bind_c component.
(gfc_get_gsymbol): Add argument bind_c.
* decl.c (add_global_entry): Add bind_c argument to
gfc_get_symbol.
* parse.c (parse_block_data): Likewise.
(parse_module): Likewise.
(add_global_procedure): Likewise.
(add_global_program): Likewise.
* resolve.c (resolve_common_blocks): Likewise.
(resolve_global_procedure): Likewise.
(gfc_verify_binding_labels): Likewise.
* symbol.c (gfc_get_gsymbol): Add argument bind_c. Set bind_c
in gsym.
* trans-decl.c (gfc_get_module_backend_decl): Add bind_c argument
to gfc_get_symbol.
(gfc_get_extern_function_decl): If the sym has a binding label
and it cannot be found in the global symbol tabel, it is the wrong
one and vice versa.

2019-03-16 Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.dg/binding_label_tests_30.f90: New test.
* gfortran.dg/binding_label_tests_31.f90: New test.
* gfortran.dg/binding_label_tests_32.f90: New test.
* gfortran.dg/binding_label_tests_33.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_30.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_31.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_32.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_33.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/fortran/gfortran.h
branches/gcc-7-branch/gcc/fortran/parse.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/symbol.c
branches/gcc-7-branch/gcc/fortran/trans-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/66695] [7/8 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 13:24:40 2019
New Revision: 269723

URL: https://gcc.gnu.org/viewcvs?rev=269723=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.h (gfc_symbol): Add bind_c component.
(gfc_get_gsymbol): Add argument bind_c.
* decl.c (add_global_entry): Add bind_c argument to
gfc_get_symbol.
* parse.c (parse_block_data): Likewise.
(parse_module): Likewise.
(add_global_procedure): Likewise.
(add_global_program): Likewise.
* resolve.c (resolve_common_blocks): Likewise.
(resolve_global_procedure): Likewise.
(gfc_verify_binding_labels): Likewise.
* symbol.c (gfc_get_gsymbol): Add argument bind_c. Set bind_c
in gsym.
* trans-decl.c (gfc_get_module_backend_decl): Add bind_c argument
to gfc_get_symbol.
(gfc_get_extern_function_decl): If the sym has a binding label
and it cannot be found in the global symbol tabel, it is the wrong
one and vice versa.

2019-03-16 Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.dg/binding_label_tests_30.f90: New test.
* gfortran.dg/binding_label_tests_31.f90: New test.
* gfortran.dg/binding_label_tests_32.f90: New test.
* gfortran.dg/binding_label_tests_33.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_30.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_31.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_32.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_33.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/fortran/gfortran.h
branches/gcc-7-branch/gcc/fortran/parse.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/symbol.c
branches/gcc-7-branch/gcc/fortran/trans-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/79485] [7/8 Regression] Bind(c) and module procedure renaming causes wrong procedure to be called

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 13:24:40 2019
New Revision: 269723

URL: https://gcc.gnu.org/viewcvs?rev=269723=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.h (gfc_symbol): Add bind_c component.
(gfc_get_gsymbol): Add argument bind_c.
* decl.c (add_global_entry): Add bind_c argument to
gfc_get_symbol.
* parse.c (parse_block_data): Likewise.
(parse_module): Likewise.
(add_global_procedure): Likewise.
(add_global_program): Likewise.
* resolve.c (resolve_common_blocks): Likewise.
(resolve_global_procedure): Likewise.
(gfc_verify_binding_labels): Likewise.
* symbol.c (gfc_get_gsymbol): Add argument bind_c. Set bind_c
in gsym.
* trans-decl.c (gfc_get_module_backend_decl): Add bind_c argument
to gfc_get_symbol.
(gfc_get_extern_function_decl): If the sym has a binding label
and it cannot be found in the global symbol tabel, it is the wrong
one and vice versa.

2019-03-16 Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.dg/binding_label_tests_30.f90: New test.
* gfortran.dg/binding_label_tests_31.f90: New test.
* gfortran.dg/binding_label_tests_32.f90: New test.
* gfortran.dg/binding_label_tests_33.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_30.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_31.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_32.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/binding_label_tests_33.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/fortran/gfortran.h
branches/gcc-7-branch/gcc/fortran/parse.c
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/symbol.c
branches/gcc-7-branch/gcc/fortran/trans-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug testsuite/84174] FAIL: gcc.dg/Wattributes-6.c (test for warnings, line 404)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
Fixed on trunk.

[Bug testsuite/84174] FAIL: gcc.dg/Wattributes-6.c (test for warnings, line 404)

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Author: danglin
Date: Sat Mar 16 16:39:49 2019
New Revision: 269728

URL: https://gcc.gnu.org/viewcvs?rev=269728=gcc=rev
Log:
PR testsuite/84174
* gcc.dg/Wattributes-6.c: Skip warning check at line 404 on
hppa*64*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wattributes-6.c

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[ibuclaw at gdcproject dot org]

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

--- Comment #6 from Iain Buclaw  ---
(In reply to John David Anglin from comment #5)
> There's also an unaligned accesses here:
> 
> (gdb) bt
> #0  rt.minfo.ModuleGroup.sortCtors(immutable(char)[]) (this=...,
> cycleHandling=...) at
> ../../../../gcc/libphobos/libdruntime/rt/minfo.d:259

[... snip ...]

> 
> and a few more.


Still all related to the same ModuleInfo generated by gdc compiler.

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[redi at gcc dot gnu.org]

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

--- Comment #38 from Jonathan Wakely  ---
char_traits now uses either __builtin_constant_p or
__builtin_is_constant_evaluated to avoid using wcslen in constant expressions.

If that isn't working with clang for some reason that's a separate issue (and
maybe something clang needs to fix, e.g. by implementing
__builtin_is_constant_evaluated).

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #7 from dave.anglin at bell dot net ---
On 2019-03-16 1:10 p.m., ibuclaw at gdcproject dot org wrote:
> Still all related to the same ModuleInfo generated by gdc compiler.
I just did "make" after applying patch.  Then, I rebuilt application.  Could it
be
that full rebuild is needed?

Otherwise, maybe TYPE_ALIGN_UNIT (type) still yields 1.

Dave

[Bug testsuite/89471] FAIL: gcc.dg/pr84941.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #1 from John David Anglin  ---
Fixed on trunk.

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[ibuclaw at gdcproject dot org]

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

--- Comment #8 from Iain Buclaw  ---
(In reply to dave.anglin from comment #7)
> On 2019-03-16 1:10 p.m., ibuclaw at gdcproject dot org wrote:
> > Still all related to the same ModuleInfo generated by gdc compiler.
> I just did "make" after applying patch.  Then, I rebuilt application.  Could
> it be
> that full rebuild is needed?
> 
> Otherwise, maybe TYPE_ALIGN_UNIT (type) still yields 1.
> 

All modules would need rebuilding, so clean and rebuild the target libphobos
library too.

[Bug fortran/77746] [7/8 Regression] [F03] Wrong subroutine called, clash of specific procedure name and binding-name

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 13:16:11 2019
New Revision: 269722

URL: https://gcc.gnu.org/viewcvs?rev=269722=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.h (gfc_symbol): Add bind_c component.
(gfc_get_gsymbol): Add argument bind_c.
* decl.c (add_global_entry): Add bind_c argument to
gfc_get_symbol.
* parse.c (parse_block_data): Likewise.
(parse_module): Likewise.
(add_global_procedure): Likewise.
(add_global_program): Likewise.
* resolve.c (resolve_common_blocks): Likewise.
(resolve_global_procedure): Likewise.
(gfc_verify_binding_labels): Likewise.
* symbol.c (gfc_get_gsymbol): Add argument bind_c. Set bind_c
in gsym.
* trans-decl.c (gfc_get_module_backend_decl): Add bind_c argument
to gfc_get_symbol.
(gfc_get_extern_function_decl): If the sym has a binding label
and it cannot be found in the global symbol tabel, it is the wrong
one and vice versa.

2019-03-16 Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.dg/binding_label_tests_30.f90: New test.
* gfortran.dg/binding_label_tests_31.f90: New test.
* gfortran.dg/binding_label_tests_32.f90: New test.
* gfortran.dg/binding_label_tests_33.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_30.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_31.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_32.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_33.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/decl.c
branches/gcc-8-branch/gcc/fortran/gfortran.h
branches/gcc-8-branch/gcc/fortran/parse.c
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/symbol.c
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/79485] [7/8 Regression] Bind(c) and module procedure renaming causes wrong procedure to be called

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 13:16:11 2019
New Revision: 269722

URL: https://gcc.gnu.org/viewcvs?rev=269722=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.h (gfc_symbol): Add bind_c component.
(gfc_get_gsymbol): Add argument bind_c.
* decl.c (add_global_entry): Add bind_c argument to
gfc_get_symbol.
* parse.c (parse_block_data): Likewise.
(parse_module): Likewise.
(add_global_procedure): Likewise.
(add_global_program): Likewise.
* resolve.c (resolve_common_blocks): Likewise.
(resolve_global_procedure): Likewise.
(gfc_verify_binding_labels): Likewise.
* symbol.c (gfc_get_gsymbol): Add argument bind_c. Set bind_c
in gsym.
* trans-decl.c (gfc_get_module_backend_decl): Add bind_c argument
to gfc_get_symbol.
(gfc_get_extern_function_decl): If the sym has a binding label
and it cannot be found in the global symbol tabel, it is the wrong
one and vice versa.

2019-03-16 Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.dg/binding_label_tests_30.f90: New test.
* gfortran.dg/binding_label_tests_31.f90: New test.
* gfortran.dg/binding_label_tests_32.f90: New test.
* gfortran.dg/binding_label_tests_33.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_30.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_31.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_32.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_33.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/decl.c
branches/gcc-8-branch/gcc/fortran/gfortran.h
branches/gcc-8-branch/gcc/fortran/parse.c
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/symbol.c
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/66695] [7/8 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 13:16:11 2019
New Revision: 269722

URL: https://gcc.gnu.org/viewcvs?rev=269722=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.h (gfc_symbol): Add bind_c component.
(gfc_get_gsymbol): Add argument bind_c.
* decl.c (add_global_entry): Add bind_c argument to
gfc_get_symbol.
* parse.c (parse_block_data): Likewise.
(parse_module): Likewise.
(add_global_procedure): Likewise.
(add_global_program): Likewise.
* resolve.c (resolve_common_blocks): Likewise.
(resolve_global_procedure): Likewise.
(gfc_verify_binding_labels): Likewise.
* symbol.c (gfc_get_gsymbol): Add argument bind_c. Set bind_c
in gsym.
* trans-decl.c (gfc_get_module_backend_decl): Add bind_c argument
to gfc_get_symbol.
(gfc_get_extern_function_decl): If the sym has a binding label
and it cannot be found in the global symbol tabel, it is the wrong
one and vice versa.

2019-03-16 Thomas Koenig  

PR fortran/66695
PR fortran/77746
PR fortran/79485
Backport from trunk
* gfortran.dg/binding_label_tests_30.f90: New test.
* gfortran.dg/binding_label_tests_31.f90: New test.
* gfortran.dg/binding_label_tests_32.f90: New test.
* gfortran.dg/binding_label_tests_33.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_30.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_31.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_32.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/binding_label_tests_33.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/decl.c
branches/gcc-8-branch/gcc/fortran/gfortran.h
branches/gcc-8-branch/gcc/fortran/parse.c
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/symbol.c
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/66089] [7/8 Regression] elemental dependency mishandling when class array are involved

[tkoenig at gcc dot gnu.org]

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

--- Comment #39 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 13:52:19 2019
New Revision: 269724

URL: https://gcc.gnu.org/viewcvs?rev=269724=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/66089
Backport from trunk
* trans-array.c (gfc_scalar_elemental_arg_saved_as_reference):
Return false if a scalar tempoary is needed.
(gfc_walk_variable_expr): Fix up class refs.

2019-03-16  Thomas Koenig  

PR fortran/66089
Backport from trunk
* gfortran.dg/dependency_53.f90: New test.
* gfortran.dg/assumed_type_2.f90: Adapted tree dumps.
* gfortran.dg/no_arg_check_2.f90: Likewise.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dependency_53.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-array.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_type_2.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/no_arg_check_2.f90

[Bug c/89737] New: internal compiler error: Floating point exception

[gsocshubham at gmail dot com]

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

Bug ID: 89737
   Summary: internal compiler error: Floating point exception
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gsocshubham at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 45980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45980=edit
Preprocessed code of file named "crash1.c"

COMPILER CONFIGURATION-

$ ~/gcc-9-trunk/build/gcc/xgcc -v

Using built-in specs.
COLLECT_GCC=/home/extended_csmith/gcc-9-trunk/build/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-lto
--disable-bootstrap : (reconfigured) ../gcc/configure --enable-languages=c,c++
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190314 (experimental) (GCC)

--COMMAND USED FOR COMPILATION

~/gcc-9-trunk/build/gcc/xgcc -B ~/gcc-9-trunk/build/gcc/ -w -O2 crash1.i
-I../../shubham/csmith-scripts/csmith/runtime/
during GIMPLE pass: profile_estimate
crash1.c: In function ‘func_2.isra.0’:
crash1.c:3857:1: internal compiler error: Floating point exception
 3857 | }
  | ^
0xca8eaf crash_signal
../../gcc/gcc/toplev.c:326
0x7fbfedb5205f ???
   
/build/glibc-yWQXbR/glibc-2.24/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x8224bd safe_scale_64bit(unsigned long, unsigned long, unsigned long, unsigned
long*)
../../gcc/gcc/profile-count.h:81
0x8224bd profile_probability::apply_scale(long, long) const
../../gcc/gcc/profile-count.h:497
0xbd99c5 set_even_probabilities
../../gcc/gcc/predict.c:893
0xbde889 combine_predictions_for_bb
../../gcc/gcc/predict.c:1239
0xbdec83 tree_estimate_probability(bool)
../../gcc/gcc/predict.c:3093
0xbdf464 execute
../../gcc/gcc/predict.c:4030
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


-REDUCED CODE USING CREDUCE-

a, b;
c() {
  &
  void *e = &, *g = &
f:
  __attribute__((hot)) h : __attribute__((cold)) for (; a;) goto *g;
d:
  for (; b;)
goto *e;
}

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
There's also an unaligned accesses here:

(gdb) bt
#0  rt.minfo.ModuleGroup.sortCtors(immutable(char)[]) (this=...,
cycleHandling=...) at ../../../../gcc/libphobos/libdruntime/rt/minfo.d:259
#1  0x00111f70 in rt.minfo.ModuleGroup.sortCtors() (this=...)
at ../../../../gcc/libphobos/libdruntime/rt/minfo.d:533
#2  __foreachbody1 (this=, sg=...)
at ../../../../gcc/libphobos/libdruntime/rt/minfo.d:795
#3  0x001164ac in rt.sections_elf_shared.DSO.opApply(scope int(ref
rt.sections_elf_shared.DSO) delegate) (dg=...)
at ../../../../gcc/libphobos/libdruntime/rt/sections_elf_shared.d:61
#4  0x00110f04 in rt_moduleCtor ()
at ../../../../gcc/libphobos/libdruntime/rt/minfo.d:793
#5  0x0010931c in rt_init ()
at ../../../../gcc/libphobos/libdruntime/rt/dmain2.d:189
#6  0x00109544 in runAll (this=0xf8d02778)
at ../../../../gcc/libphobos/libdruntime/rt/dmain2.d:484
#7  0x00108ea4 in tryExec (this=0xf8d02778, dg=...)
at ../../../../gcc/libphobos/libdruntime/rt/dmain2.d:460
#8  0x0010912c in _d_run_main (argc=2308240, argv=,
mainFunc=)
at ../../../../gcc/libphobos/libdruntime/rt/dmain2.d:493
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0x11167c to 0x11169c:
   0x0011167c <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1692>: copy r4,r19
   0x00111680 <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1696>: ldw 4(r17),ret1
   0x00111684 <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1700>: ldi 0,ret0
   0x00111688 <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1704>: ldi 0,r18
=> 0x0011168c <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1708>: ldw,s
ret0(ret1),r20
   0x00111690 <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1712>: cmpb,=,n
r20,r8,0x1117a4 <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1988>
   0x00111694 <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1716>: ldw 0(r3),rp
   0x00111698 <_D2rt5minfo11ModuleGroup9sortCtorsMFAyaZv+1720>: ldw 4(r3),r31
End of assembler dump.
(gdb) p/x $ret0
$5 = 0x0
(gdb) p/x $ret1
$6 = 0x21f471

and a few more.

[Bug testsuite/89393] [9 Regression] FAIL: g++.dg/abi/ref-temp1.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ZGR1bIvE

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Sat Mar 16 18:10:31 2019
New Revision: 269732

URL: https://gcc.gnu.org/viewcvs?rev=269732=gcc=rev
Log:
PR testsuite/89393
* g++.dg/abi/ref-temp1.C: Skip on 32-bit hppa*-*-hpux*.
* g++.dg/cpp0x/pr84497.C: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/abi/ref-temp1.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr84497.C

[Bug fortran/84394] [7/8/9 Regression] compiler error when using modules with derived types in block data subprograms

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Mar 16 11:50:03 2019
New Revision: 269721

URL: https://gcc.gnu.org/viewcvs?rev=269721=gcc=rev
Log:
2019-03-16  Thomas Koenig  

PR fortran/84394
* symbol.c (gfc_add_subroutine): If we are encountering a
subrtoutine within a BLOCK DATA and the name starts with an
underscore, do not check.

2019-03-16  Thomas Koenig  

PR fortran/84394
* gfortran.dg/blockdata_11.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/blockdata_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[Bug c/89667] initializers for character string arrays (char *[]) appear to reside in protected storage

[rick at regreer dot net]

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

--- Comment #5 from Rick Greer  ---
OK, now I get it.  The array of pointers is, indeed, static but the compiler is
trying to allocate the data that those pointers reference on the stack!  I was
confused by the fact that C++ lets me do this:

   void foo () { static char *bar[] = { (const char []){"xxx"} };

whereas C does not (of course, C++ allows stuff like:

switch (x) { case "abc"[0]: ... }

as well).  C++ is assuming that 'const' implies static, which isn't necessarily
the case.  While the simplest way to implement 'const' data is to stick it at
the end of the protected code space, you could also have a function prologue
that allocates automatic 'const' data on an appropriate page boundary,
initializes it as indicated, and then asks the operating system to dink with
the page tables to make the data read-only.  Not the most efficient
implementation, perhaps, but pedantically more correct than what C++ actually
does!

What I was (unknowingly) looking for was a way of explicitly specifying a
literal's storage class.  Something like:

 (static char []) {"foo"}

which is, of course, syntactically bogus.

Thanks again for the enlightenment, sensei.

[Bug debug/86593] [8 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272

[ssbssa at yahoo dot de]

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

Domani Hannes  changed:

   What|Removed |Added

 CC||ssbssa at yahoo dot de

--- Comment #16 from Domani Hannes  ---
Is there a reason why this wasn't backported to the gcc-8-branch?

[Bug fortran/79485] [7/8 Regression] Bind(c) and module procedure renaming causes wrong procedure to be called

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed on all open branches, closing.

Also thanks for the bug report!

[Bug fortran/77746] [7/8 Regression] [F03] Wrong subroutine called, clash of specific procedure name and binding-name

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #9 from Thomas Koenig  ---
Fixed on all open branches, closing.

... and for this one, too.

[Bug fortran/66695] [7/8 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #14 from Thomas Koenig  ---
Fixed on all open branches, closing.

Thanks for the bug report!

[Bug fortran/32630] [meta-bug] ISO C binding

[tkoenig at gcc dot gnu.org]

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

Bug 66695 Summary: [7/8 Regression] [F03] ICE with binding-name equal to the 
name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695

   What|Removed |Added

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

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2019-03-15 9:02 p.m., ibuclaw at gdcproject dot org wrote:
>> Might add that there are quite a few unaligned accesses:
> I guess that forcing the ModuleInfo type alignment to 1 is not helping (see
> patch).
I think the patch helps but there is at least one more:

Breakpoint 2, object.ModuleInfo.flags() const (this=...)
    at ../../../../gcc/libphobos/libdruntime/object.d:1523
1523    @property uint flags() nothrow pure @nogc { return _flags; }
(gdb) p/x $r26
$7 = 0x1d080d
(gdb) bt
#0  object.ModuleInfo.flags() const (this=...)
    at ../../../../gcc/libphobos/libdruntime/object.d:1523
#1  object.ModuleInfo.importedModules() const (this=...)
    at ../../../../gcc/libphobos/libdruntime/object.d:1562
#2  0x0011166c in rt.minfo.ModuleGroup.sortCtors(immutable(char)[]) (this=...,
    cycleHandling=...) at ../../../../gcc/libphobos/libdruntime/rt/minfo.d:259
#3  0x00111f70 in rt.minfo.ModuleGroup.sortCtors() (this=...)
    at ../../../../gcc/libphobos/libdruntime/rt/minfo.d:533
#4  __foreachbody1 (this=, sg=...)
    at ../../../../gcc/libphobos/libdruntime/rt/minfo.d:795
#5  0x001164ac in rt.sections_elf_shared.DSO.opApply(scope int(ref
rt.sections_elf_shared.DSO) delegate) (dg=...)
    at ../../../../gcc/libphobos/libdruntime/rt/sections_elf_shared.d:61
#6  0x00110f04 in rt_moduleCtor ()
    at ../../../../gcc/libphobos/libdruntime/rt/minfo.d:793
#7  0x0010931c in rt_init ()
    at ../../../../gcc/libphobos/libdruntime/rt/dmain2.d:189
#8  0x00109544 in runAll (this=0xf8d02778)
    at ../../../../gcc/libphobos/libdruntime/rt/dmain2.d:484
#9  0x00108ea4 in tryExec (this=0xf8d02778, dg=...)
    at ../../../../gcc/libphobos/libdruntime/rt/dmain2.d:460
#10 0x0010912c in _d_run_main (argc=2307488, argv=,
    mainFunc=)
--Type  for more, q to quit, c to continue without paging--
    at ../../../../gcc/libphobos/libdruntime/rt/dmain2.d:493

(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0x100344 to 0x100364:
   0x00100344 <_D6object10ModuleInfo8unitTestMxFNaNbNdNiZPFZv+136>: ldw
0(ret0),ret0
   0x00100348 <_D6object10ModuleInfo8unitTestMxFNaNbNdNiZPFZv+140>: bv,n
r0(rp)
   0x0010034c
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+0>: 
  ldo 40(sp),sp
   0x00100350
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+4>: 
  stw r19,-20(sp)
=> 0x00100354
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+8>: 
  ldw 0(r26),ret0
   0x00100358
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+12>:
  bb,<,n ret0,15,0x100374
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+40>
   0x0010035c
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+16>:
  stw r0,-38(sp)
   0x00100360
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+20>:
  ldw -38(sp),ret0
End of assembler dump.

runnable.exe(7936): unaligned access to 0x001d080d at
ip=0x00100357

Some but not all calls to "object.ModuleInfo.flags() const (this=...)" have an
unaligned value in %r26.

[Bug middle-end/78915] missing -Wuninitialized accessing allocated memory

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #2)
> Possibly a dup of PR87209

Or vice versa.

[Bug testsuite/83453] FAIL: c-c++-common/Wattributes.c -std=gnu++98 (test for warnings, line 404)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #7 from John David Anglin  ---
Fixed on hppa64-hp-hpux11.11.

[Bug testsuite/83453] FAIL: c-c++-common/Wattributes.c -std=gnu++98 (test for warnings, line 404)

[danglin at gcc dot gnu.org]

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

--- Comment #6 from John David Anglin  ---
Author: danglin
Date: Sat Mar 16 15:44:25 2019
New Revision: 269727

URL: https://gcc.gnu.org/viewcvs?rev=269727=gcc=rev
Log:
PR testsuite/83453
* c-c++-common/Wattributes.c: Skip a warning check on hppa*64*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wattributes.c

[Bug c/39985] Type qualifiers not actually ignored on function return type

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Which is PR 89734, right?

[Bug inline-asm/84941] [6/7 Regression] internal compiler error: in reg_overlap_mentioned_p, at rtlanal.c:1870 (reg_overlap_mentioned_p()/match_asm_constraints_1())

[danglin at gcc dot gnu.org]

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

--- Comment #11 from John David Anglin  ---
Author: danglin
Date: Sat Mar 16 17:31:30 2019
New Revision: 269730

URL: https://gcc.gnu.org/viewcvs?rev=269730=gcc=rev
Log:
PR testsuite/84941
* gcc.dg/pr84941.c: Skip on hppa*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr84941.c

[Bug c/26732] different argument type not rejected for K style function definitions

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Harald van Dijk from comment #8)
> (In reply to Eric Gallager from comment #7)
> > (In reply to Andrew Pinski from comment #6)
> > > Now we don't even error out at -O3.
> > 
> > Why would the -O3 matter?
> 
> -O3 enables inlining, which up until GCC 4.2 triggered an error on the
> parameter/argument type mismatch.
> 
> But GCC is correct to not report an error for that. This is only undefined
> at runtime, so the compiler is required to allow this unless it can prove
> the execution will reach that point of the code.
> 
> What's missing as of GCC 4.0 is GCC 3.4's default-enabled warning "warning:
> structure defined inside parms".

ah ok gotcha

[Bug target/89739] pessimizing vectorization at -O3 to load two u64 objects

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
PR 84101.

[Bug libstdc++/89740] reading from cin & writing to cout sync_with_stdio(false) has race conditions

[ahu at ds9a dot nl]

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

--- Comment #2 from bert hubert  ---
Created attachment 45982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45982=edit
reproduction that actually shows the bug

This is the version of the reproduction that exhibits the problem. The other
version had the "fix" included, cin.tie(nullptr), and thus did not have the
problem.

[Bug target/85915] ABI incompatibility (multiple definition of `__x86_return_thunk') for static libraries, between GCC 7.3.0 and GCC >=7.4.0, caused by -mfunction-return=thunk

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  ---
(In reply to Luke Dashjr from comment #13)
> I run Gentoo, so it compiled it for me (2.27)

You should report it to Gentoo.

[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #6 from Volker Reichelt  ---
Here's a related testcase that ICEs in a different location
(and also regressed in February):


struct A
{
  int i = ;
  A() noexcept = default;
};


bug.cc:3:9: error: expected primary-expression at end of input
3 |   int i = ;
  | ^
bug.cc:5:2: internal compiler error: tree check: expected tree_list, have
error_mark in comp_except_specs, at cp/typeck.c:1048
5 | };
  |  ^
0x7ebe52 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9859
0x6999e0 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3432
0x6999e0 comp_except_specs(tree_node const*, tree_node const*, int)
../../gcc/gcc/cp/typeck.c:1048
0x990ad6 after_nsdmi_defaulted_late_checks(tree_node*)
../../gcc/gcc/cp/method.c:2277
0x9bf206 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:23611
0x9c038d cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:23652
0x9c038d cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:17397
0x9c12b4 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:14090
0x9c1aa1 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13385
0x9e4590 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13204
0x9e4d0c cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4698
0x9e4d0c c_parse_file()
../../gcc/gcc/cp/parser.c:41148
0xaeb18b c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1156
Please submit a full bug report, [etc.]

[Bug preprocessor/89738] Warn for unused macro arguments

[david.bolvansky at gmail dot com]

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

--- Comment #2 from Dávid Bolvanský  ---
#define PARENT_NODE(x) ((id - 1) / 2)

int id = 0;
int idx = 1;
PARENT_NODE(idx); // macro contais id, but id is defined, warn?


But probably such analysis is not so easy...

[Bug libstdc++/89740] New: reading from cin & writing to cout sync_with_stdio(false) has race conditions

[ahu at ds9a dot nl]

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

Bug ID: 89740
   Summary: reading from cin & writing to cout
sync_with_stdio(false) has race conditions
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ahu at ds9a dot nl
  Target Milestone: ---

Created attachment 45981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45981=edit
a small reproduction for this bug.

Reading lots of lines from cin in main() and writing to cout from an additional
thread usually works fine. However, when doing sync_with_stdio(false),
duplicate output appears on the terminal. No C stdio is performed by the
program. No two threads are attempting simultaneous output. 

Output of attached 25 line reproduction:

$ yes | ./repro
HHi 0
Hi Hi 1
Hi Hi 2

Verification with strace shows that the main thread is doing writes to file
descriptor 1 that are also happening in the output thread.

The problem goes away when setting 'cin.tie(nullptr)' or when removing
sync_with_stdio(false):
$ yes | ./repro
Hi 0
Hi 1
Hi 2

A trivial reproduction is attached.

The hypothesis is that cin/cout tying is somehow relying on sync_with_stdio to
prevent race conditions.

Bug #70276 touches on slightly similar material, but it looks like something
different.

[Bug ada/89742] New: Ada2020 target assignment in generic renders a type invisible

[nicolas at debian dot org]

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

Bug ID: 89742
   Summary: Ada2020 target assignment in generic renders a type
invisible
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas at debian dot org
  Target Milestone: ---

Hello.
This issue affects the @ target assignement in Ada, which is not yet officially
released, but supported with the appropriate options.

This program is legal, but if the indicated Ref is replaced with @,
GCC reports an error.

cat > main.adb < Ref.all.I);
  --   ^ this Ref.
   end Generic_P;
   procedure P is new Generic_P;
begin
   null;
end Main;
EOF

echo 'Produces sensible warnings.'
gnatgcc -c -gnat2020 main.adb

sed -i 's/=> Ref/=> @/' main.adb

echo 'Now says "Rec" is undefined.'
gnatgcc -c -gnat2020 main.adb

[Bug fortran/89724] [9 Regression] Fortran diagnostics give wrong line number because of math-vector-fortran.h header file

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85915] ABI incompatibility (multiple definition of `__x86_return_thunk') for static libraries, between GCC 7.3.0 and GCC >=7.4.0, caused by -mfunction-return=thunk

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Luke Dashjr from comment #9)
> Is there a solution or workaround for this? I already rebuilt glibc more
> than once, but keep running into it... (GCC 8.2.0 on a system that was
> mostly built by 7.3.0)

What exactly have you done?

[Bug preprocessor/89738] Warn for unused macro arguments

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |preprocessor

--- Comment #1 from Andrew Pinski  ---
One of the issue is that some macro functions are designed to ignore the
argument; e.g. assert.

[Bug fortran/89724] [9 Regression] Fortran diagnostics give wrong line number because of math-vector-fortran.h header file

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sat Mar 16 21:18:49 2019
New Revision: 269734

URL: https://gcc.gnu.org/viewcvs?rev=269734=gcc=rev
Log:
PR fortran/89724
* scanner.c (load_line): Remove linenum and current_line static
variables, add warned_tabs automatic variable.  Use current_file->line
instead of current_line and warned_tabs boolean to avoid diagnosing
tabs multiple times on the same line.

* gfortran.dg/continuation_15.f90: New test.
* gfortran.dg/continuation_16.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/continuation_15.f90
trunk/gcc/testsuite/gfortran.dg/continuation_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85915] ABI incompatibility (multiple definition of `__x86_return_thunk') for static libraries, between GCC 7.3.0 and GCC >=7.4.0, caused by -mfunction-return=thunk

[luke-jr+gccbugs at utopios dot org]

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

Luke Dashjr  changed:

   What|Removed |Added

 CC||luke-jr+gccbugs at utopios dot 
org

--- Comment #9 from Luke Dashjr  ---
Is there a solution or workaround for this? I already rebuilt glibc more than
once, but keep running into it... (GCC 8.2.0 on a system that was mostly built
by 7.3.0)

[Bug libstdc++/89740] reading from cin & writing to cout sync_with_stdio(false) has race conditions

[ahu at ds9a dot nl]

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

--- Comment #3 from bert hubert  ---
Note that in
https://stackoverflow.com/questions/12605725/basic-thread-locking-in-c11/12608911#12608911
we read the calling flush() from two threads at the same time is not legal if
the streams are unsynchronised.

The tie() may be causing this unexpectedly.

[Bug rtl-optimization/89487] [7/8 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993

[amker at gcc dot gnu.org]

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

--- Comment #9 from bin cheng  ---
(In reply to Jakub Jelinek from comment #8)
> *** Bug 89731 has been marked as a duplicate of this bug. ***

Hi Jakub, is this (and the duplication) fixed by the previous patches or the
issue is still there?  Thanks.

[Bug d/88724] FAIL: gdc.dg/compilable.d -O0 (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2019-03-15 12:48 p.m., ibuclaw at gdcproject dot org wrote:
> The system headers (stdlib.h, time.h, stdint.h, etc...) will need to be ported
> to druntime, are these available anywhere?
Nominally, these headers are posix compliant.

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2019-03-16 1:51 p.m., ibuclaw at gdcproject dot org wrote:
> All modules would need rebuilding, so clean and rebuild the target libphobos
> library too.
After library rebuild, there are no more unaligned accesses.

[Bug target/85915] ABI incompatibility (multiple definition of `__x86_return_thunk') for static libraries, between GCC 7.3.0 and GCC >=7.4.0, caused by -mfunction-return=thunk

[luke-jr+gccbugs at utopios dot org]

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

--- Comment #11 from Luke Dashjr  ---
Simply upgrading to GCC 8.2.0 failed due to the multiple-definition of
__x86_return_thunk, so I successfully built only the C compiler with the
non-thunking defaults; from there, I rebuilt glibc again without thunking, then
rebuilt the full GCC with thunking re-enabled, and glibc again with thunking
re-enabled.

My most recent issue was with building distcc and libiberty.a, which I solved
by removing binutils-libs and installing it again from scratch (a simple
rebuild failed due to the multiple-definition of __x86_return_thunk in the
existing library).

[Bug target/85915] ABI incompatibility (multiple definition of `__x86_return_thunk') for static libraries, between GCC 7.3.0 and GCC >=7.4.0, caused by -mfunction-return=thunk

[luke-jr+gccbugs at utopios dot org]

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

--- Comment #13 from Luke Dashjr  ---
I run Gentoo, so it compiled it for me (2.27)

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #7)
> (In reply to Eric Gallager from comment #6)
> > (In reply to Eric Gallager from comment #5)
> > > (In reply to René J.V. Bertin from comment #4)
> > > > Any news on this front?
> > > 
> > > Last I heard from Iain he was still having to deal with water damage to 
> > > his
> > > office...
> > 
> > He seems to be back now, but dealing with lower-hanging fruit in his backlog
> > at the moment. 
> 
> The focus is on wrong-code and regression bugs at the moment (not
> necessarily lowest-hanging fruit)

As it ought to be for stage 4... 

> 
> Apropos this enhancement:
> 1) My last set of working patches was against 4.9/5 - so they need to be
> forward-ported.
> 2) There is a design ;-) the reason this is assigned...
> 3) This would involve changes to c-family FE and some ME additions, so you
> can be sure it is not relevant until 10 stage 1 at the earliest.
> 
> > (I really wish I knew as much about the Darwin port as he
> > does so I could help reduce its "bus factor", but unfortunately I haven't
> > been able to focus hard enough to sit down and really learn it)
> 
> There is a lot of testsuite noise some of which probably *is* low-hanging
> fruit (places where there are Linux-isms in the test cases which simply need
> the Darwin equivalent) - Darwin folks *you* can test/analyse/categorise
> these, whereas the folks without a Darwin box cannot - so please go at it! 
> JFTR, I started with testsuite fixes ..

my latest testsuite results are here:
https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg01042.html

A diff from my previous run can be found here:
https://github.com/cooljeanius/gcc_bugs/blob/master/testsuite_logs/SnowLeopard/180905_to_190209.diff

Some of the noise in the diff is from switching to bootstrapping using your
patched cctools and your gcc 5 binaries, instead of my previous build of gcc
trunk.

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > (In reply to Eric Gallager from comment #6)
> > > (In reply to Eric Gallager from comment #5)
> > > > (In reply to René J.V. Bertin from comment #4)
> > > > > Any news on this front?

> > There is a lot of testsuite noise some of which probably *is* low-hanging
> > fruit (places where there are Linux-isms in the test cases which simply need
> > the Darwin equivalent) - Darwin folks *you* can test/analyse/categorise
> > these, whereas the folks without a Darwin box cannot - so please go at it! 
> > JFTR, I started with testsuite fixes ..
> 
> my latest testsuite results are here:
> https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg01042.html

looks "about right" (I have fixes for some of the fails - just need to get some
cycles on it).

> A diff from my previous run can be found here:
> https://github.com/cooljeanius/gcc_bugs/blob/master/testsuite_logs/
> SnowLeopard/180905_to_190209.diff
> 
> Some of the noise in the diff is from switching to bootstrapping using your
> patched cctools and your gcc 5 binaries, instead of my previous build of gcc
> trunk.

Well, there's a very large interval in the test-diff, so it's quite hard to
draw too much conclusion - but the newer cctools *does* report more diagnostics
than the Xcode 3.2.6 set.

- this isn't an ideal place for general test discussion - perhaps identify if
test fails have already been seen and update the "last reconfirmed" if they
have, or file a new PR if none exists.

[Bug target/89739] pessimizing vectorization at -O3 to load two u64 objects

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64
  Component|middle-end  |target

--- Comment #1 from Andrew Pinski  ---
SLP gone wrong.  I think there might be a duplicate of this bug already.

[Bug middle-end/89739] New: pessimizing vectorization at -O3 to load two u64 objects

[redbeard0531 at gmail dot com]

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

Bug ID: 89739
   Summary: pessimizing vectorization at -O3 to load two u64
objects
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/8vIGZ3

using u64 = unsigned long long;
struct u128 {u64 a, b;};

inline u64 load8(void* ptr) {
u64 out;
__builtin_memcpy(, ptr, 8);
return out;
}

u128 load(char* basep, u64 n) {
return {load8(basep), load8(basep+n-8)};
}

At -O2 this emits ideal asm:
mov rax, QWORD PTR [rdi]
mov rdx, QWORD PTR [rdi-8+rsi]
ret


At -O3 it is comical:
movqxmm0, QWORD PTR [rdi]
movhps  xmm0, QWORD PTR [rdi-8+rsi]
movaps  XMMWORD PTR [rsp-24], xmm0
mov rax, QWORD PTR [rsp-24]
mov rdx, QWORD PTR [rsp-16]
ret

This seems to have been introduced in gcc7

[Bug libstdc++/89740] reading from cin & writing to cout sync_with_stdio(false) has race conditions

[ahu at ds9a dot nl]

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

--- Comment #1 from bert hubert  ---
Comment on attachment 45981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45981
a small reproduction for this bug.

>#include 
>#include 
>#include 
>#include 
>
>using namespace std;
>
>void theThread()
>{
>  for(int counter = 0 ;; ++counter) {
>usleep(25);
>cout << "Hi "<< counter << endl;
>  }
>}
>
>int main()
>{
>  std::ios_base::sync_with_stdio(false);
>  // cin.tie(nullptr);
>  
>  string line;
>  thread t(theThread);
>  while(getline(cin, line))
>;
>}

[Bug target/85915] ABI incompatibility (multiple definition of `__x86_return_thunk') for static libraries, between GCC 7.3.0 and GCC >=7.4.0, caused by -mfunction-return=thunk

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Luke Dashjr from comment #11)
> Simply upgrading to GCC 8.2.0 failed due to the multiple-definition of
> __x86_return_thunk, so I successfully built only the C compiler with the
> non-thunking defaults; from there, I rebuilt glibc again without thunking,
> then rebuilt the full GCC with thunking re-enabled, and glibc again with
> thunking re-enabled.
> 
> My most recent issue was with building distcc and libiberty.a, which I
> solved by removing binutils-libs and installing it again from scratch (a
> simple rebuild failed due to the multiple-definition of __x86_return_thunk
> in the existing library).

Where did you get your glibc?

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[redi at gcc dot gnu.org]

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

--- Comment #39 from Jonathan Wakely  ---
It seems that clang doesn't support using __builtin_constant_p this way, so
using char_traits in constant expressions isn't going to work until
they implement is_constant_evaluated.

The __constant_string_p function does work with the Intel compiler though
(since icc 17.0.0 by the look of it), so is worth keeping.

[Bug c++/89741] New: [Regression] static_assert fires when template not instantiated

[tadeus.prastowo at unitn dot it]

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

Bug ID: 89741
   Summary: [Regression] static_assert fires when template not
instantiated
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tadeus.prastowo at unitn dot it
  Target Milestone: ---

Consider the following MWE:
-- 8< 
template
struct Y {
  static constexpr bool value = false;
};

template<>
struct Y {
  static constexpr bool value = true;
};

template
struct X {
  static_assert(Y::value, "1");
};

int main() {
}
-- 8< 

Compiling it with GCC 8.3, GCC 7.4, GCC 6.3, GCC 5.5, GCC 4.9.4, Clang 6.0, and
Clang 7.0 gives no error (see https://www.godbolt.org/z/t8Dkw7).

Compiling it with GCC 9.0 (trunk) gives an error.

[Bug c++/89743] New: [concepts] ICE when using decltype(requires-expr) as type template parameter

[jason.e.cobb at gmail dot com]

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

Bug ID: 89743
   Summary: [concepts] ICE when using decltype(requires-expr) as
type template parameter
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.e.cobb at gmail dot com
  Target Milestone: ---

Example code:

template
struct use_type {};

template // needed to fulfill requirement that requires appears only
in templates
using type = typename use_type;

Example compiler output:

:7:3: internal compiler error: tree check: expected tree that contains
'typed' structure, have 'simple_req' in strip_typedefs_expr, at cp/tree.c:1855

7 | })>;

On Compiler Explorer: https://godbolt.org/z/CsgSH7

Note: tested with both struct and templated alias-declaration, ICE occurs with
both.

[Bug c/89734] const qualifier on return type not erased inside __typeof__

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This changed with r236231 aka DR#423.