[Bug rtl-optimization/81423] [6/7 Regression] Wrong code at -O2

[davmac at davmac dot org]

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

Davin McCall  changed:

   What|Removed |Added

 CC||davmac at davmac dot org

--- Comment #15 from Davin McCall  ---
Apologies if I'm wrong and just making noise but doesn't the test case involve
a left shift of a value greater than the bit width of the left operand and
therefore invoke UB?

  ll = -5597998501375493990LL;

  ll = (5677365550390624949L - ll) - (ull1 > 0);
  //ull3 = (unsigned int)
  //  (2067854353L <<
  //   (((ll + -2129105131L) ^ 10280750144413668236ULL) -
  //10280750143997242009ULL)) >> ((2873442921854271231ULL | ull2)
  //- 12098357307243495419ULL);

  // Above broken down:

  unsigned long long int t1 = ll + -2129105131L;
  unsigned long long int t2 = t1 ^ 10280750144413668236ULL;
  unsigned long long int t3 = t2 - 10280750143997242009ULL;
  // t3 = 9523455470476460042 !!!
  long t4 = 2067854353L << t3;  // UB!!
  unsigned int t5 = (unsigned int)t4;

  unsigned long long int t6 = 2873442921854271231ULL | ull2;
  unsigned long long int t7 = t6 - 12098357307243495419ULL;
  ull3 = t5 >> t7;

Fixed test case would be:

--- begin ---
unsigned long long int ll = 0;
unsigned long long int ull1 = 1ULL;
unsigned long long int ull2 = 12008284144813806346ULL;
unsigned long long int ull3;

void
foo ()
{
  ll = -5597998501375493990LL;

  ll = (5677365550390624949L - ll) - (ull1 > 0);
  ull3 = (unsigned int)
(2067854353L <<
 (((ll + -2129105131L) ^ 10280750144413668236ULL) +
  17089282532945401191ULL)) >> ((2873442921854271231ULL | ull2)
- 12098357307243495419ULL);
}

int
main ()
{
  foo ();
  printf ("%llu expected 3998784)\n", ull3);
  printf ("%llx expected 3d0440)\n", ull3);
  return 0;
}
--- end ---

This still demonstrates the bug.

[Bug rtl-optimization/81423] [6/7 Regression] Wrong code at -O2

[babokin at gmail dot com]

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

--- Comment #16 from Dmitry Babokin  ---
ll = -5597998501375493990LL;

// result is 2595916314 here.
ll = unsigned(5677365550390624949L - ll) - (ull1 > 0);

So:
  // t1 is 466811183
  unsigned long long int t1 = ll + -2129105131L;
  // t2 is 10280750143997242019
  unsigned long long int t2 = t1 ^ 10280750144413668236ULL;
  // t3 is 10
  unsigned long long int t3 = t2 - 10280750143997242009ULL;

So the test case looks correct to me.

UBSAN also doesn't complain.

[Bug rtl-optimization/81423] [6/7 Regression] Wrong code at -O2

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 14 08:34:11 2017
New Revision: 253749

URL: https://gcc.gnu.org/viewcvs?rev=253749&root=gcc&view=rev
Log:
PR rtl-optimization/81423
* gcc.c-torture/execute/pr81423.c (foo): Add missing cast.  Change L
suffixes to LL.
(main): Punt if either long long isn't 64-bit or int isn't 32-bit.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/pr81423.c

[Bug rtl-optimization/81423] [6/7 Regression] Wrong code at -O2

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Davin McCall from comment #15)
> Apologies if I'm wrong and just making noise but doesn't the test case
> involve a left shift of a value greater than the bit width of the left
> operand and therefore invoke UB?

The test as committed invokes UB, because the #c3 transcription into C omitted
the cast unsigned(5677365550390624949L - ll) from the original testcase.

Fixed thusly, I've additionally replaced all spots using L suffixes with LL for
consistent behavior on 32-bit targets, and add a test that int is 32-bit, for
say 16-bit int and 64-bit long long the testcase would have UB again (as well
as end up with a different than expected value anyway, as 3998784 doesn't fit
into 16-bit int.

[Bug libgcj/82540] gcc 6.4.0 bootstrap with java core dump in file with illumos ld

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
  Component|target  |libgcj
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Botcazou  ---
Java was deprecated and has been removed since then.  No fix planned.

[Bug libgcj/82540] gcc 6.4.0 bootstrap with java core dump in file with illumos ld

[ikozhukhov at gmail dot com]

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

--- Comment #3 from Igor Kozhukhov  ---
but some components in Debian mainstream are using gcj for builds - how to do
it ?
i'm using Debian stretch repo for my ports to DilOS.

[Bug libgcj/82540] gcc 6.4.0 bootstrap with java core dump in file with illumos ld

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
> but some components in Debian mainstream are using gcj for builds - how to
> do it ?

You need to ask the Debian maintainers - they are presumably well aware of the
decision by now.

[Bug fortran/82550] New: program using submodules fails to link

[Bader at lrz dot de]

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

Bug ID: 82550
   Summary: program using submodules fails to link
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Bader at lrz dot de
  Target Milestone: ---

Created attachment 42365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42365&action=edit
reproducer

The attached example implements a separate module procedure returning a
procedure pointer. gfortran 7,2 compiles the code, but issues the following
error message at the linking stage:
/gpfs/scratch/pr28fa/a2832ba/a2832ba/ccmqzru6.o: In function
`__m_subm_18_pos_MOD_foo':
subm_18_pos.f90:(.text+0x20): undefined reference to `p.3503'

It seems that host association to the module procedure p() fails, because
linking works if an external procedure is used.

[Bug ada/82529] Missing warning on with_clause for predefined unit

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-14
 CC||ebotcazou at gcc dot gnu.org
Summary|Warning on unreferenced |Missing warning on
   |"with" is not produced  |with_clause for predefined
   ||unit
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Botcazou  ---
It's because Ada.Unchecked_Conversion is a predefined unit.

[Bug fortran/79864] Implicit type conversion on assignment of unallocated array to unallocated array variable segfaults.

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Note, there is a small difference to pr78963

Should be 79863.

Compiling the test with '-Wall -Wextra -fcheck=all -Ofast -m32
-fsanitize=address' gives

pr79864.f90:4:0:

   si = ssi

Warning: 'ssi.dim[0].ubound' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr79864.f90:2:0:

   integer(kind=1), allocatable :: ssi(:)

note: 'ssi.dim[0].ubound' was declared here
pr79864.f90:4:0:

   si = ssi

Warning: 'ssi.dim[0].lbound' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr79864.f90:2:0:

   integer(kind=1), allocatable :: ssi(:)

note: 'ssi.dim[0].lbound' was declared here
pr79864.f90:4:0:

   si = ssi

Warning: 'si.dim[0].ubound' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr79864.f90:1:0:

   integer, allocatable :: si(:)

note: 'si.dim[0].ubound' was declared here
pr79864.f90:4:0:

   si = ssi

Warning: 'si.dim[0].lbound' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr79864.f90:1:0:

   integer, allocatable :: si(:)

note: 'si.dim[0].lbound' was declared here

unless the patch in pr52162 comment 8 is applied.

Note that I don't see any segfault at run time.

[Bug fortran/79863] Assignment of unallocated array to unallocated array variable leads to access of unallocated memory

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Same result as in pr79863 comment 3.

[Bug fortran/79863] Assignment of unallocated array to unallocated array variable leads to access of unallocated memory

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Same result as in pr79863 comment 3.

I mean 'Same result as in pr79864 comment 3'.

[Bug other/82551] New: msp430-toolchain imported to eclipse

[zceeykk at ucl dot ac.uk]

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

Bug ID: 82551
   Summary: msp430-toolchain imported to eclipse
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zceeykk at ucl dot ac.uk
  Target Milestone: ---

Created attachment 42366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42366&action=edit
Screenshot

I am currently trying to use TelosB on MAC which is based on MSP430F1611, I
have used TinyOs to program it. However, I want to program the mote using the
Eclipse. Therefore, I have followed this instruction from this link:
"https://openwsn.atlassian.net/wiki/spaces/OW/pages/11534370/msp430gcc+on+Eclipse+with+mspdebug+Preferred";.

When I build the project I get this error "make: *** [main.o] Error 4"
Then I tried to upload to the mote I get this error too "
/opt/local/msp430-toolchain-mac_os_x-x86_64-2.2/bin/mspdebug-wrapper: line 7:
17954 Abort trap: 6   `dirname $0`/mspdebug "$@"
dyld: Library not loaded: /opt/local/lib/libreadline.6.2.dylib
  Referenced from: /opt/local/msp430-toolchain-mac_os_x-x86_64-2.2/bin/mspdebug
  Reason: image not found
/opt/local/msp430-toolchain-mac_os_x-x86_64-2.2/bin/mspdebug-wrapper: line 7:
17954 Abort trap: 6   `dirname $0`/mspdebug "$@"

is there something I can do to fix this?

If I gave a lack of information please tell me! 

Thank you!

[Bug other/82551] msp430-toolchain imported to eclipse

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
We don't support binary builds.  Please ask the site where you downloaded the
binaries from.

>dyld: Library not loaded: /opt/local/lib/libreadline.6.2.dylib

The error message is clear what the problem is though, the binaries are
dependent on a library which is not installed on your system.  You have to ask
the site where you can download the required library binaries from since we
don't know the exact binaries which can be used here.

[Bug fortran/81344] Can't disable -ffpe-trap (or not documented)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement

--- Comment #2 from Dominique d'Humieres  ---
Without feed-back I'll close the file as WONTFIX.

[Bug fortran/82550] program using submodules fails to link

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-14
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 6.4 up to trunk (8.0).

[Bug tree-optimization/82549] [6/7/8 Regression] ICE at -O1 and above: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-14
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|ICE at -O1 and above:   |[6/7/8 Regression] ICE at
   |verify_gimple failed|-O1 and above:
   ||verify_gimple failed
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Most likely started with my r142484 (r142464 works, r142514 already ICEs).
I'll have a look.

[Bug fortran/81344] Can't disable -ffpe-trap (or not documented)

[jellby at yahoo dot com]

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

--- Comment #3 from Ignacio Fernández Galván  ---
Do you expect any feedback from me?

#1 would of course work, but the point is that I'd like to set
'-ffpe-trap=set1,set2' as the default for all files, and then disable set2 only
for some files. This would be simpler than setting '-ffpe-trap=set1' for some
files and '-ffpe-trap=set1,set2' for the "other" files, since I may not know
which are the other files.

About #2... yes, "do it yourself" is always an option, but what's the purpose
of bug reports and feature requests then?

[Bug libgcj/82540] gcc 6.4.0 bootstrap with java core dump in file with illumos ld

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Botcazou from comment #2)
> Java was deprecated and has been removed since then.  No fix planned.

This bug is for the gcc-6-branch though which still had it.

[Bug libgcj/82540] gcc 6.4.0 bootstrap with java core dump in file with illumos ld

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> This bug is for the gcc-6-branch though which still had it.

Sure, it's hard to report a Java bug for later releases since it's gone. ;-)

[Bug fortran/81344] Can't disable -ffpe-trap (or not documented)

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Do you expect any feedback from me?

Yes, I did!-(

> #1 would of course work, but the point is that I'd like to set
> '-ffpe-trap=set1,set2' as the default for all files, and then disable set2
> only for some files. This would be simpler than setting '-ffpe-trap=set1'
> for some files and '-ffpe-trap=set1,set2' for the "other" files, since I may
> not know which are the other files.

Common guy! FLAGS1="-ffpe-trap=set1,set2 ..." for most files, and
FLAGS2="-ffpe-trap=set1 ..." for the files you are asking for a
-fno-fpe-trap=set2 or whatever syntax you like.

> About #2... yes, "do it yourself" is always an option, but what's the purpose
> of bug reports and feature requests then?

As for today there are 907 Pos opened, with between 200 and 300 of them fixed
per year and ~300 new ones per year. Knowing that probably more than half of
the opened PRs have a much higher priority than yours, how many years will it
take to get this PR fixed?

[Bug tree-optimization/82549] [6/7/8 Regression] ICE at -O1 and above: verify_gimple failed

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 42367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42367&action=edit
gcc8-pr82549.patch

Untested fix.

[Bug bootstrap/82548] After -r 253646 GCC 8.0 can't build cross compiler for mingw32

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 14 12:32:17 2017
New Revision: 253753

URL: https://gcc.gnu.org/viewcvs?rev=253753&root=gcc&view=rev
Log:
PR bootstrap/82548
* config.gcc (*-*-solaris2*, i[34567]86-*-cygwin*,
x86_64-*-cygwin*, i[34567]86-*-mingw* | x86_64-*-mingw*): Append
objects to extra_objs instead of overwriting it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc

[Bug other/82551] msp430-toolchain imported to eclipse

[zceeykk at ucl dot ac.uk]

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

--- Comment #2 from Yong  ---
Thank you for your reply.
I will have a look into that,

THank you

[Bug fortran/81758] [OOP] Broken vtab

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Do you have access to a recent revision of trunk (8.0)? If yes, do you still
see the problem?

I understand that you are not willing to reduce your code. If yes, I have
managed to compile gfc_vector.F90, could you provide at least a driver showing
the problem?

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

--- Comment #9 from asmwarrior  ---
I see this crash issue again, but still it happens in another place of the wx's
source code, add the

__attribute__((optimize("O0")))

To the function which cause the crash can workaround this issue. Note that the
-O0 option does not cause this issue.

wxString __attribute__((optimize("O0"))) wxCommandEvent::GetString() const
{
// This is part of the hack retrieving the event string from the control
// itself only when/if it's really needed to avoid copying potentially huge
// strings coming from multiline text controls. For consistency we also do
// it for combo boxes, even though there are no real performance advantages
// in doing this for them.
if (m_eventType == wxEVT_TEXT && m_eventObject)
{
#if wxUSE_TEXTCTRL
wxTextCtrl *txt = wxDynamicCast(m_eventObject, wxTextCtrl);
if ( txt )
return txt->GetValue();
#endif // wxUSE_TEXTCTRL

#if wxUSE_COMBOBOX
wxComboBox* combo = wxDynamicCast(m_eventObject, wxComboBox);
if ( combo )
return combo->GetValue();
#endif // wxUSE_COMBOBOX
}

return m_cmdString;
} 

Please see discussions here in wx-user's maillist and Code::Blocks's forum:

https://groups.google.com/d/msg/wx-users/LUxm6fUhirk/FJRFNIt6AAAJ

and 

http://forums.codeblocks.org/index.php/topic,22198.0.html

The original wx's workaround is here: https://trac.wxwidgets.org/ticket/17483

[Bug tree-optimization/70455] spurious "assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow]"

[vindrg at gmail dot com]

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

Vincas Dargis  changed:

   What|Removed |Added

 CC||vindrg at gmail dot com

--- Comment #3 from Vincas Dargis  ---
This warning occurred when building qTox [qtox] on Debian 9 (stretch) i686 with
gcc (Debian 6.3.0-18) 6.3.0 20170516 when built with -Wstrict-overflow. 

It *does not* reproduce on amd64 build.

Here's output:

/somewhere/qTox.git/src/persistence/settingsserializer.cpp:267: error: assuming
signed overflow does not occur when simplifying conditional to constant
[-Werror=strict-overflow]
 if (g != -1) {
 ^~

Context [context]:

for (int g = -1; g < groups.size(); ++g) {
// Save the group name, if any
if (g != -1) {
 writeStream(stream, RecordTag::GroupStart);
 writeStream(stream, groups[g].toUtf8());
}

// ...
}


I could workaround it with:

if (static_cast(g) != -1) {

Although maybe there is different solution?


[qtox] https://github.com/qTox/qTox
[context]
https://github.com/qTox/qTox/blob/084f3b06262b2ca8272238b2ec450d11840d7551/src/persistence/settingsserializer.cpp#L267

[Bug c++/82552] New: No warning when using uninitialized values in initializer list

[s-beyer at gmx dot net]

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

Bug ID: 82552
   Summary: No warning when using uninitialized values in
initializer list
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s-beyer at gmx dot net
  Target Milestone: ---

Hi,

the following code example is pretty harmless but the underlying issue
took me quite some time to debug in real code (where the constructors
are really doing stuff):

8<
struct bar {
bar() {}
bar(bar&) {}
};

class foo {
bar first;
bar second;

public:
foo() : first(second) {}
};
>8

The interesting thing is the foo constructor.
It initializes "first" with "second", but the initializer list
is going in order of the attributes, so "first" is initialized
before "second" is.

I'd expect either an -Wreorder warning ("second" will be initialized after
"first") or an -Wuninitialized ("second" will be used uninitialized) warning
(which is what clang++ does).

I tested this with g++ 4.9.3, 5.4.1, 6.4.0, and 7.2.0. None of it raised
alarm :(

Thanks.

[Bug c++/82552] No warning when using uninitialized values in initializer list

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is a duplicate of an existing bug report.

[Bug c++/82552] No warning when using uninitialized values in initializer list

[s-beyer at gmx dot net]

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

--- Comment #2 from Stephan Beyer  ---
I had expected this but I could not find the specific one.
(I found a few related ones that were resolved as FIXED.)

[Bug bootstrap/82548] After -r 253646 GCC 8.0 can't build cross compiler for mingw32

[mateuszb at poczta dot onet.pl]

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

mateuszb at poczta dot onet.pl changed:

   What|Removed |Added

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

--- Comment #2 from mateuszb at poczta dot onet.pl ---
Thanks for fix!

[Bug bootstrap/82553] New: memory_blockage breaks bootstrap on powerpc

[dje at gcc dot gnu.org]

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

Bug ID: 82553
   Summary: memory_blockage breaks bootstrap on powerpc
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: blocker
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, segher at gcc dot gnu.org,
seurer at gcc dot gnu.org, uros at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

The recent memory_blockage named insn pattern patch breaks bootstrap on PowerPC

during RTL pass: expand
/home/dje/src/src/libgcc/emutls.c: In function ‘__emutls_get_address’:
/home/dje/src/src/libgcc/emutls.c:139:11: internal compiler error: in
invalid_void, at config/rs6000/rs6000.md:10804
   pointer offset = __atomic_load_n (&obj->loc.offset, __ATOMIC_ACQUIRE);
   ^~

0x11401a13 invalid_void
/home/dje/src/src/gcc/config/rs6000/rs6000.md:10804
0x10c22263 expand_memory_blockage
/home/dje/src/src/gcc/optabs.c:6301
0x10c225cb expand_atomic_load(rtx_def*, rtx_def*, memmodel)
/home/dje/src/src/gcc/optabs.c:6365
0x1056a14b expand_builtin_atomic_load
/home/dje/src/src/gcc/builtins.c:5951
0x1056fd87 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/dje/src/src/gcc/builtins.c:7280
0x107ecf9f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/dje/src/src/gcc/expr.c:10866
0x107de5c7 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/dje/src/src/gcc/expr.c:8084
0x107d2d9b store_expr_with_bounds(tree_node*, rtx_def*, int, bool,
bool, tree_node*)
/home/dje/src/src/gcc/expr.c:5554
0x107d14e3 expand_assignment(tree_node*, tree_node*, bool)
/home/dje/src/src/gcc/expr.c:5319
0x105bb9c3 expand_call_stmt
/home/dje/src/src/gcc/cfgexpand.c:2664
0x105bf95b expand_gimple_stmt_1
/home/dje/src/src/gcc/cfgexpand.c:3585
0x105c025b expand_gimple_stmt
/home/dje/src/src/gcc/cfgexpand.c:3751
0x105c9dbf expand_gimple_basic_block
/home/dje/src/src/gcc/cfgexpand.c:5754
0x105cbf73 execute
/home/dje/src/src/gcc/cfgexpand.c:6361
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [emutls.o] Error 1

[Bug bootstrap/82553] memory_blockage breaks bootstrap on powerpc

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/82553] memory_blockage breaks bootstrap on powerpc

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
The patch does only:

+expand_memory_blockage (void)
+{
+  if (targetm.have_memory_blockage)
+emit_insn (targetm.gen_memory_blockage ());
+  else
+expand_asm_memory_blockage ();
+}

So, if the target doesn't declare memory_blockage pattern, as is the
case with rs6000, I really fail to see what could go wrong here.

[Bug bootstrap/82553] memory_blockage breaks bootstrap on powerpc

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Ouch...

Index: optabs.c
===
--- optabs.c(revision 253752)
+++ optabs.c(working copy)
@@ -6297,7 +6297,7 @@
 static void
 expand_memory_blockage (void)
 {
-  if (targetm.have_memory_blockage)
+  if (targetm.have_memory_blockage ())
 emit_insn (targetm.gen_memory_blockage ());
   else
 expand_asm_memory_blockage ();

[Bug bootstrap/82553] memory_blockage breaks bootstrap on powerpc

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Oct 14 17:46:49 2017
New Revision: 253759

URL: https://gcc.gnu.org/viewcvs?rev=253759&root=gcc&view=rev
Log:
PR bootstrap/82553
* optabs.c (expand_memory_blockage): Fix call of
targetm.have_memory_blockage.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c

[Bug bootstrap/82553] memory_blockage breaks bootstrap on powerpc

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #5 from Uroš Bizjak  ---
Should be fixed now.

[Bug tree-optimization/70455] spurious "assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow]"

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Vincas Dargis from comment #3)
> This warning occurred when building qTox [qtox] on Debian 9 (stretch) i686
> with gcc (Debian 6.3.0-18) 6.3.0 20170516 when built with -Wstrict-overflow. 
> 
> It *does not* reproduce on amd64 build.

Can you file a separate bug with the preprocessed source, I suspect the issue
there is different from the original issue listed here.  

Also the trunk has changed how the warnings are handled in this case but I have
not looked into if it changes the warning in the original case or the new one
which you are listing.

[Bug libstdc++/82554] New: uniform_real_distribution can generate the upper endpoint

[b.r.longbons at gmail dot com]

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

Bug ID: 82554
   Summary: uniform_real_distribution can generate the upper
endpoint
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

This is related to #64351 and #63176, for which a totally-bogus fix was
applied.

There is actually a defect in the standard: it requires `generate_canonical` to
return at *least* `bits` (e.g. 53), but correct operation is only possible when
it generates *exactly* `bits` since floating-point math rounds rather than
truncating like integer math.

Furthermore, when `std::uniform_real_distribution`'s parameters have different
exponents, the difference must be *subtracted* from the number of bits
requested (not possible since `bits` is only a template parameter).

I have not considered *all* the details when uniform_real_distribution crosses
0 or its parameters are not exact powers of 2, but the principle of requesting
less-than-53 bits certainly still applies.

Consider the following horrible, but valid RNG (for easy testing):

#include 
#include 
#include 
#include 


int main()
{
// seed with -2 instead of -1 because it returns the post-advance state
// produces -1, 0, 1, 2, ...
std::linear_congruential_engine engine(-2ULL);

std::cout << std::setprecision(std::numeric_limits::max_digits10);

std::uniform_real_distribution dist(1.0, 2.0);

for (int i = 0; i < 2; ++i)
std::cout << dist(engine) << std::endl;
// just to prove that yes, they are exact, here are the next values
// the different discards are because 1.0 has a different exponent
engine.discard(1 << 11);
std::cout << dist(engine) << std::endl;
engine.discard(1 << 12);
std::cout << dist(engine) << std::endl;
}

[Bug c++/82531] ICE: Segmentation fault (-std=c++1z -fconcepts)

[gcc-bugs at deta dot lv]

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

Arturs Zoldners  changed:

   What|Removed |Added

  Attachment #42363|0   |1
is obsolete||

--- Comment #3 from Arturs Zoldners  ---
Created attachment 42368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42368&action=edit
testcase archive

Correction: it was still an invalid code in my previous post. Substitution
"auto" -> [some concept] creates invalid code in variadic context.

While trying to create a test case with a valid code, I encountered another
ICE, I believe on a valid code (at least to my understanding of N3580 section
4.5.1). The substitution typename -> [some concept] triggers an ICE, but with a
back-trace similar to bug #68372:



testcase.cpp: In instantiation of ‘struct _map_impl >’:
testcase.cpp:29:56:   required from here
testcase.cpp:17:34: internal compiler error: in tsubst_constraint, at
cp/constraint.cc:1956
  static constexpr decltype(auto) function(auto const& fun, TUPLES const&...
tuples)
  ^~~~
0x71ba6d tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/constraint.cc:1956
0x71bb19 tsubst_constraint_info(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/constraint.cc:1918
0x628070 tsubst_decl
../../gcc/cp/pt.c:12440
0x6145df tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13404
0x627ad0 tsubst_decl
../../gcc/cp/pt.c:12214
0x6145df tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13404
0x62f2e0 instantiate_class_template_1
../../gcc/cp/pt.c:10546
0x62f2e0 instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:10880
0x6926e5 complete_type(tree_node*)
../../gcc/cp/typeck.c:133
0x67a092 cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:6158
0x67ce55 cp_parser_simple_type_specifier
../../gcc/cp/parser.c:16849
0x673dc8 cp_parser_postfix_expression
../../gcc/cp/parser.c:6704
0x67499d cp_parser_unary_expression
../../gcc/cp/parser.c:8108
0x675743 cp_parser_cast_expression
../../gcc/cp/parser.c:8786
0x675eb7 cp_parser_binary_expression
../../gcc/cp/parser.c:8887
0x676584 cp_parser_assignment_expression
../../gcc/cp/parser.c:9174
0x67977a cp_parser_expression
../../gcc/cp/parser.c:9343
0x66b864 cp_parser_jump_statement
../../gcc/cp/parser.c:12160
0x66b864 cp_parser_statement
../../gcc/cp/parser.c:10594
0x66be4d cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11040
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



If this is related and relevant to bug #68372, please forward.

[Bug tree-optimization/70455] spurious "assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow]"

[vindrg at gmail dot com]

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

--- Comment #5 from Vincas Dargis  ---
(In reply to Andrew Pinski from comment #4) 
> Can you file a separate bug with the preprocessed source, I suspect the
> issue there is different from the original issue listed here.  

Could you elaborate that "preprocessed source"?

> Also the trunk has changed how the warnings are handled in this case but I
> have not looked into if it changes the warning in the original case or the
> new one which you are listing.

Well, I could try on Debian Sid VMs with "latest" GCC I can get, if that would
help.

[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 14 18:47:14 2017
New Revision: 253760

URL: https://gcc.gnu.org/viewcvs?rev=253760&root=gcc&view=rev
Log:
PR middle-end/62263
PR middle-end/82498
* tree-ssa-forwprop.c (simplify_rotate): Allow def_arg1[N]
to be any operand_equal_p operands.  For & (B - 1) require
B to be power of 2.  Recognize
(X << (Y & (B - 1))) | (X >> ((-Y) & (B - 1))) and similar patterns.

* c-c++-common/rotate-5.c (f2): New function.  Move old
function to ...
(f4): ... this.  Use 127 instead of 128.
(f3, f5, f6): New functions.
(main): Test all f[1-6] functions, with both 0 and 1 as
second arguments.
* c-c++-common/rotate-6.c: New test.
* c-c++-common/rotate-6a.c: New test.
* c-c++-common/rotate-7.c: New test.
* c-c++-common/rotate-7a.c: New test.
* c-c++-common/rotate-8.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/rotate-6.c
trunk/gcc/testsuite/c-c++-common/rotate-6a.c
trunk/gcc/testsuite/c-c++-common/rotate-7.c
trunk/gcc/testsuite/c-c++-common/rotate-7a.c
trunk/gcc/testsuite/c-c++-common/rotate-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/rotate-5.c
trunk/gcc/tree-ssa-forwprop.c

[Bug target/82498] Missed optimization for x86 rotate instruction

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 14 18:47:14 2017
New Revision: 253760

URL: https://gcc.gnu.org/viewcvs?rev=253760&root=gcc&view=rev
Log:
PR middle-end/62263
PR middle-end/82498
* tree-ssa-forwprop.c (simplify_rotate): Allow def_arg1[N]
to be any operand_equal_p operands.  For & (B - 1) require
B to be power of 2.  Recognize
(X << (Y & (B - 1))) | (X >> ((-Y) & (B - 1))) and similar patterns.

* c-c++-common/rotate-5.c (f2): New function.  Move old
function to ...
(f4): ... this.  Use 127 instead of 128.
(f3, f5, f6): New functions.
(main): Test all f[1-6] functions, with both 0 and 1 as
second arguments.
* c-c++-common/rotate-6.c: New test.
* c-c++-common/rotate-6a.c: New test.
* c-c++-common/rotate-7.c: New test.
* c-c++-common/rotate-7a.c: New test.
* c-c++-common/rotate-8.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/rotate-6.c
trunk/gcc/testsuite/c-c++-common/rotate-6a.c
trunk/gcc/testsuite/c-c++-common/rotate-7.c
trunk/gcc/testsuite/c-c++-common/rotate-7a.c
trunk/gcc/testsuite/c-c++-common/rotate-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/rotate-5.c
trunk/gcc/tree-ssa-forwprop.c

[Bug target/82498] Missed optimization for x86 rotate instruction

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 14 18:48:38 2017
New Revision: 253761

URL: https://gcc.gnu.org/viewcvs?rev=253761&root=gcc&view=rev
Log:
PR middle-end/62263
PR middle-end/82498
* tree-ssa-phiopt.c (value_replacement): Comment fix.  Handle
up to 2 preparation statements for ASSIGN in MIDDLE_BB.

* c-c++-common/rotate-8.c: Expect no PHIs in optimized dump.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/rotate-8.c
trunk/gcc/tree-ssa-phiopt.c

[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Sat Oct 14 18:48:38 2017
New Revision: 253761

URL: https://gcc.gnu.org/viewcvs?rev=253761&root=gcc&view=rev
Log:
PR middle-end/62263
PR middle-end/82498
* tree-ssa-phiopt.c (value_replacement): Comment fix.  Handle
up to 2 preparation statements for ASSIGN in MIDDLE_BB.

* c-c++-common/rotate-8.c: Expect no PHIs in optimized dump.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/rotate-8.c
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/70455] spurious "assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow]"

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Vincas Dargis from comment #5)
> (In reply to Andrew Pinski from comment #4) 
> > Can you file a separate bug with the preprocessed source, I suspect the
> > issue there is different from the original issue listed here.  
> 
> Could you elaborate that "preprocessed source"?

Yes please read https://gcc.gnu.org/bugs/ :
"the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below)."

[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure

[fritzoreese at gmail dot com]

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

--- Comment #5 from Fritz Reese  ---
Nice! That should probably not compile. There is some trickiness because it
is valid to create a RECORD variable with the same name as a STRUCTURE.
I’ll get on that as well.

On Fri, Oct 13, 2017, 13:49 sgk at troutmask dot apl.washington.edu <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511
>
> --- Comment #4 from Steve Kargl 
> ---
> On Fri, Oct 13, 2017 at 01:39:26AM +, foreese at gcc dot gnu.org
> wrote:
> >
> > Fritz Reese  changed:
> >
> > Under other DEC compilers, it seems STRUCTUREs are to be treated
> consistently
> > with derived types in regards to I/O lists. That is to say, a structure
> > variable is treated as if each of its named components was listed on the
> I/O
> > list. (Even with UNIONs/MAPs, each named component is to be treated as
> having
> > been listed in place of the DEC RECORD containing it, so that the last
> > component written to within overlapping MAPs takes effect. Yikes.)
> >
> > I believe both the code in the attachment and the "intended code"
> (writing to
> > bucket.c16 instead of bucket) should be accepted, whereas they both ICE
> > currently.
> >
> > I will look into it.
>
> I actually misread the code.  I thought it was
>
>   program bug
>   structure /bckt/
>  union
> map
>character*16 c16
> end map
>  end union
>   end structure
>   record /bckt/ bucket
>   character(len=16) :: rec1 = 'ABCDEFGHIJKLMNOP'
>   100 format(A16)
>   read(rec1, 100) bckt
>   end program bug
>
> where one is trying read into the definition of the structure.
> Is the above suppose to compile?  Because it does.  A simple
> program with a Fortran derived type fails.
>
>   type bar
> integer i
>   end type bar
>   character(len=10) :: str ='123'
>   read(str,*) bar
>   end
>
> # gfcx -c b.f
> b.f:5:21:
>
>read(str,*) bar
>  1
> Error: Derived type 'bar' cannot be used as a variable at (1)
>
> I was thinking the bckt should be handled in the same manner
> as bar.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Sat, Oct 14, 2017 at 07:33:28PM +, fritzoreese at gmail dot com wrote:
> 
> --- Comment #5 from Fritz Reese  ---
> Nice! That should probably not compile. There is some trickiness because it
> is valid to create a RECORD variable with the same name as a STRUCTURE.
> I’ll get on that as well.
> 

Perhaps, you can add a attr.record (and .union and .map if needed)
to distinguish a record a from a structure.

[Bug c++/81016] [7/8 Regression] ICE: segfault with template struct specialisation

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Oct 14 20:06:08 2017
New Revision: 253762

URL: https://gcc.gnu.org/viewcvs?rev=253762&root=gcc&view=rev
Log:
2017-10-14  Paolo Carlini  

PR c++/81016
* g++.dg/cpp1z/pr81016.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/pr81016.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/81016] [7/8 Regression] ICE: segfault with template struct specialisation

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.3 |7.2

--- Comment #3 from Paolo Carlini  ---
Fixed in 7.2.0.

[Bug c++/81054] [7/8 Regression] ICE with volatile variable in constexpr function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  ---
Let's add Jakub in CC, then.

[Bug tree-optimization/80511] [8 Regression] gcc.dg/Wstrict-overflow-18.c gcc.dg/Wstrict-overflow-7.c gcc.dg/pragma-diag-3.c

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

Summary|[8 Regression]  |[8 Regression]
   |gcc.dg/Wstrict-overflow-18. |gcc.dg/Wstrict-overflow-18.
   |c   |c
   ||gcc.dg/Wstrict-overflow-7.c
   ||gcc.dg/pragma-diag-3.c

--- Comment #3 from Marc Glisse  ---
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=253642

2 more testcases got xfailed: gcc.dg/Wstrict-overflow-7.c and
gcc.dg/pragma-diag-3.c.

Some possibilities:
- add the warning in match.pd: users keep complaining about those
strict-overflow warnings, so we would have to take it out of Wall.
- add the warning in match.pd, restricted to GENERIC: that gets us close to the
gcc-7 situation.
- reimplement the warning in the front-end. In general, telling users that we
simplified x+1

[Bug libgomp/82555] New: SPECcpu201 Wrf_s deadlock

[kugan at gcc dot gnu.org]

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

Bug ID: 82555
   Summary: SPECcpu201 Wrf_s deadlock
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Wrf_s is hanging or deadlocks when run on 48 threads (cores). It doesnt always
happen and I have to run with --iterations=111 and it will eventually happens.
Sometimes in the 2nd iterations and some times much later.

I attached the process to gdb and the back trace is:
(gdb) bt
#0  0x01019924 in __lll_lock_wait (futex=futex@entry=0x2c3b1e0
<_gfortrani_unit_lock>, private=0) at lowlevellock.c:43
#1  0x01012cbc in __pthread_mutex_lock (mutex=0x2c3b1e0
<_gfortrani_unit_lock>) at pthread_mutex_lock.c:80
#2  0x00fd20ac in __gthread_mutex_lock (__mutex=0x2c3b1e0
<_gfortrani_unit_lock>) at ../libgcc/gthr-default.h:748
#3  _gfortrani_close_units () at ../../../gcc-exp2/libgfortran/io/unit.c:835
#4  0x0103950c in __libc_csu_fini ()
#5  0x0103f068 in __run_exit_handlers ()
#6  0x0103f0b0 in exit ()
#7  0x00fc6e60 in _gfortrani_exit_error (status=1, status@entry=3) at
../../../gcc-exp2/libgfortran/runtime/error.c:196
#8  0x00fc7314 in _gfortrani_internal_error
(cmp=cmp@entry=0xcdf23d00, 
message=message@entry=0x11548a8 "stash_internal_unit(): Stack Size
Exceeded") at ../../../gcc-exp2/libgfortran/runtime/error.c:422
#9  0x00fd1a84 in _gfortrani_stash_internal_unit (dtp=0xcdf23d00)
at ../../../gcc-exp2/libgfortran/io/unit.c:549
#10 0x00fd0f6c in _gfortran_st_write_done (dtp=0xcdf23d00) at
../../../gcc-exp2/libgfortran/io/transfer.c:4168
#11 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#12 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#13 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#14 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#15 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#16 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#17 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#18 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#19 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#20 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#21 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#22 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#23 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#24 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#25 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#26 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#27 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#28 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#29 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#30 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#31 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#32 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#33 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#34 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#35 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#36 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#37 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#38 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#39 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#40 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#41 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#42 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#43 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#44 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#45 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()
#46 0x00db933c in __module_ra_rrtm_MOD_rrtmlwrad ()

I am running this on AArch64 but I dont think this is an AArch64 specific
issue. Is anyone else seeing this?

[Bug c++/80908] [c++1z] ICE on instantiating a template deducing the noexcept-ness of a function pointer

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Oct 14 20:35:36 2017
New Revision: 253763

URL: https://gcc.gnu.org/viewcvs?rev=253763&root=gcc&view=rev
Log:
2017-10-14  Paolo Carlini  

PR c++/80908
* g++.dg/cpp1z/noexcept-type18.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/noexcept-type18.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/82555] SPECcpu201 Wrf_s deadlock

[kugan at gcc dot gnu.org]

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

--- Comment #1 from kugan at gcc dot gnu.org ---
My gcc is slightly old. 
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/kugan.vivekanandarajah/install/test/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc-exp2/configure : (reconfigured) ../gcc-exp2/configure
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
gcc version 8.0.0 20170822 (experimental) (GCC)

I will try with the latest version.

[Bug c++/80908] [c++1z] ICE on instantiating a template deducing the noexcept-ness of a function pointer

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.2

--- Comment #4 from Paolo Carlini  ---
Essentially a Dup of that bug, thus fixed in 7.2.0. I added the testcase
anyway.

[Bug libgomp/82555] SPECcpu201 Wrf_s deadlock

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||81195

--- Comment #2 from Andrew Pinski  ---
Interesting this should have been fixed with PR 81195 but was not.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81195
[Bug 81195] SPEC CPU2017 621.wrf_s failure with 40+ openmp threads

[Bug libgomp/82555] SPECcpu201 Wrf_s deadlock

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Also related to PR 78387.

[Bug libfortran/82555] SPECcpu201 Wrf_s deadlock

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-10-14
  Component|libgomp |libfortran
 Depends on||78387
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Actually PR 78387 seems exactly this issue.  Please test with a newer version
of gfortran.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387
[Bug 78387] OpenMP segfault/stack size exceeded writing to internal file

[Bug libstdc++/82554] uniform_real_distribution can generate the upper endpoint

[b.r.longbons at gmail dot com]

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

--- Comment #1 from Ben Longbons  ---
Ugh, part of my explanation was wrong: it's not the difference of exponents,
it's the number of common bits between the min and the (inclusive) max. That
just happens to both be 1 bit when the (exclusive) max is twice the min.

[Bug c++/71832] [7/8 Regression] ICE on invalid C++11 code with incorrect decltype use for non-type template parameter: Segmentation fault

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
Related to PR71169.

[Bug c++/82552] No warning when using uninitialized values in initializer list

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #1)
> This is a duplicate of an existing bug report.

bug 19808 perhaps?

[Bug libfortran/82555] SPECcpu201 Wrf_s deadlock

[kugan at gcc dot gnu.org]

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

--- Comment #5 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #4)
> Actually PR 78387 seems exactly this issue.  Please test with a newer
> version of gfortran.

Thanks Andrew. Looks like this is the issue. So far, current trunk is
continuing without error.