[Bug rtl-optimization/90168] context-sensitive local register allocation

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
>or to use float type to hold frequency?

This won't work correctly as floating point is different between hosts.  There
has been some usage of floating point inside of GCC which was removed because
of that issue.  I thought that was documented somewhere too.

[Bug middle-end/90345] too pessimistic check whether pointer may alias a local variable

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Related to PR 50262 (and a few others).  Looks like GCC did not notice that
a->digits comes from an argument so therefor cannot alias the local variable.

[Bug middle-end/90345] too pessimistic check whether pointer may alias a local variable

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think there might be a dup of this bug.  Where locals should not be able to
alias incoming arugments.

[Bug driver/42444] "-march=i386 -march=native -mfpmath=sse" problem

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #2 from Sergei Trofimovich  ---
Could it be that https://gcc.gnu.org/PR69471 got this fixed?

[Bug fortran/90350] New: ubound ICE on assumed size array even though explicit bound is specified

[urbanjost at comcast dot net]

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

Bug ID: 90350
   Summary: ubound ICE on assumed size array even though explicit
bound is specified
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

Created attachment 46291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46291=edit
call UBOUND(3f) with an assumed-size array but with an explicit size on the
upper bound

Even an assumed size array should be able to be passed to UBOUND if an explicit
size is specified (well, that is the way I read the standard :>). This problem
only appeared while transitioning some F77 code 
to a modern syntax but it produced an ICE. Once updated completely the code
works great with gfortran, by the way. A reduced reproducer is attached. The
error is

   write(*,*)'UPPER=',ubound(arr(:n))

internal compiler error: in gfc_conv_intrinsic_bound, at
fortran/trans-intrinsic.c:2735
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The test has been reduced to the point where it is redundant to even call
UBOUND
but it still produces the ICE, which is what I assuming you want to look at;
but unless I encounter this in some other form consider this a low priority
request. As always, thanks!

[Bug c++/90349] missing return with turned on 03 causes infinite loop

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
How is it a bug that a broken program yields broken code? -Wall gives a
suitable warning.

[Bug other/63509] Misleading error message when building gcc without C++ compiler installed

[wilson at gcc dot gnu.org]

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

--- Comment #8 from Jim Wilson  ---
I filed an autoconf bug
http://savannah.gnu.org/support/index.php?109676

The problem here is that autoconf only verifies that the first AC_PROG_X
compiler is working.  And since we include AC_PROG_CC before AC_PROG_CXX, only
the C compiler is tested to see if it works.  But since we are using the C++
compiler for all of the configure checks, and for the build, we really should
be verifying that the C++ compiler works.

We can work around the autoconf problem by putting AC_PROG_CXX before
AC_PROG_CC.  This will verify that the C++ compiler works, but will stop
verifying that the C compiler works, which is probably OK.

[Bug c++/90349] New: missing return with turned on 03 causes infinite loop

[volconscious at gmail dot com]

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

Bug ID: 90349
   Summary: missing return with turned on 03 causes infinite loop
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: volconscious at gmail dot com
  Target Milestone: ---

Hello,

I have g++ 8.2.0 (mingw - windows). If I compile this program (notice - program
is not fully correct, there is a missing return statement)

#include 

int test()
{
for (int i = 0; i < 4; i++)
{
printf("i: %d\n", i);
}
//return 0;
}


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

with O3 optimization (g++ test.cpp -O3 -o test.exe), it generates infinite
loop:

.LC0:
.string "i: %d\n"
test():
pushrbx
xor ebx, ebx
.L2:
mov esi, ebx
mov edi, OFFSET FLAT:.LC0
xor eax, eax
add ebx, 1
callprintf
jmp .L2
main:
sub rsp, 8
calltest()

[Bug c/90348] Small inlined function has local variables in invalid stack location

[pieter.wuille at gmail dot com]

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

--- Comment #1 from Pieter Wuille  ---
Created attachment 46290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46290=edit
Un-preprocessed test case C file

Adding the original .c file as well to demonstrate the problem on different
platforms (the .i file is for GCC 8.3, x86_64, -m64).

[Bug c/90348] New: Small inlined function has local variables in invalid stack location

[pieter.wuille at gmail dot com]

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

Bug ID: 90348
   Summary: Small inlined function has local variables in invalid
stack location
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pieter.wuille at gmail dot com
  Target Milestone: ---

Created attachment 46289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46289=edit
Source file to reproduce the problem

In attachment is a small source file that seems to be miscompiled with "-O1
-finline-small-functions".

Tested versions/environments where the issue appears:
* GCC 7.3, Ubuntu 18.04.2, x86_64, "gcc -O1 -finline-small-functions test.i -o
test"
* GCC 8.3, Ubuntu 18.04.2, x86_64, "gcc -O1 -finline-small-functions test.i -o
test"
* GCC 8.3, Ubuntu 18.04.2, x86_64, "gcc -m32 -O1 -finline-small-functions
test.i -o test"
* GCC 9.0, Fedora 30, i686, "gcc -O2 test.i -o test"

In a loop, a 4-byte (or larger) char array "in" is created, and then
increasingly long prefixes initialized to zero. A small inlinable function
"set_one_on_stack" is invoked during the loop that should have no effect (it
sets a local variable "buf" to one in a roundabout way), but apparently the
"buf" variable is given the same stack location as the caller's "in" variable,
overwriting the latter. When compiled incorrectly, an unexpected assertion
occurs.

The test file is a reduced version of an issue observed on some platforms in
the Bitcoin Core unit tests. See
https://github.com/bitcoin/bitcoin/issues/14580 for more details.

[Bug sanitizer/90347] New: [UBSAN] __attribute__((weak))__ results in "declared weak after being used" error

[dimhen at gmail dot com]

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

Bug ID: 90347
   Summary: [UBSAN] __attribute__((weak))__ results in "declared
weak after being used" error
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

$ cat x.cpp
struct s { };
extern s var;
// __attribute__ ((weak)) s var; // no error

extern void foo(s&);
void bar()
{
foo(var);
}

__attribute__ ((weak)) s var; // error


$ /usr/local/gcc_current/bin/g++ -fsanitize=undefined -Wall -c x.cpp
x.cpp:2:10: error: 'var' declared weak after being used
2 | extern s var;
  |  ^~~


$ /usr/local/gcc_current/bin/g++ -Wall -c x.cpp


$ $ /usr/local/gcc_current/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --with-tune=native
Thread model: posix
gcc version 10.0.0 20190503 (experimental) [trunk revision 270859] (GCC)

[Bug target/90346] New: gcc generates the "lfence" instruction on CPUs that don't support it

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

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

Bug ID: 90346
   Summary: gcc generates the "lfence" instruction on CPUs that
don't support it
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

The built-in function __builtin_speculation_safe_value generates a "lfence"
instruction. Unfortunatelly, it doesn't check that the target CPU supports the
lfence instruction.

GCC should use dummy atomic instruction (such as "lock addl $0, (%esp)" - or
some other serializing instruction on CPUs that don't have lfence.

Compile this program with "-O3 -m32 -march=pentium2"

#include 

int array[500];

int f1 (unsigned untrusted_index)
{
if (untrusted_index < 500)
return array[untrusted_index];
return 0;
}

int f2 (unsigned untrusted_index)
{
if (untrusted_index < 500)
return
array[__builtin_speculation_safe_value(untrusted_index)];
return 0;
}

int f3 (unsigned untrusted_index)
{
if (untrusted_index < 500)
return
*__builtin_speculation_safe_value([untrusted_index], NULL);
return 0;
}

The result:

 :
   0:   8b 54 24 04 mov0x4(%esp),%edx
   4:   31 c0   xor%eax,%eax
   6:   81 fa f3 01 00 00   cmp$0x1f3,%edx
   c:   76 02   jbe10 
   e:   c3  ret
   f:   90  nop
  10:   8b 04 95 00 00 00 00mov0x0(,%edx,4),%eax
  17:   c3  ret
  18:   90  nop
  19:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi

0020 :
  20:   31 c0   xor%eax,%eax
  22:   81 7c 24 04 f3 01 00cmpl   $0x1f3,0x4(%esp)
  29:   00
  2a:   76 04   jbe30 
  2c:   c3  ret
  2d:   8d 76 00lea0x0(%esi),%esi
  30:   0f ae e8lfence
  33:   8b 44 24 04 mov0x4(%esp),%eax
  37:   8b 04 85 00 00 00 00mov0x0(,%eax,4),%eax
  3e:   c3  ret
  3f:   90  nop

0040 :
  40:   31 c0   xor%eax,%eax
  42:   81 7c 24 04 f3 01 00cmpl   $0x1f3,0x4(%esp)
  49:   00
  4a:   76 04   jbe50 
  4c:   c3  ret
  4d:   8d 76 00lea0x0(%esi),%esi
  50:   8b 44 24 04 mov0x4(%esp),%eax
  54:   c1 e0 02shl$0x2,%eax
  57:   0f ae e8lfence
  5a:   8b 80 00 00 00 00   mov0x0(%eax),%eax
  60:   c3  ret

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Janne Blomqvist from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Currently, I am leaning towards using an option with a mandatory
> > warning (no way to turn it off) which does not push any string lenghts
> > onto the stack at all, something like -fbroken-character-abi,
> > which we would use for external procedures without an explicit interface.
> 
> Hmm, wouldn't this completely break procedures with "character(len=*)" dummy
> arguments?

Yes :-(

This would be more or less equivalent to a -fbind-c flag.

>Or did mean that it would be used only for length=1 strings?

Unfortunately, the callee does not know the string length
passed by the caller.

> > I can also extend -fc-prototypes so that it also issues prototypes
> > for any global procedures outside of BIND(C), or add a new option.
> 
> This might be useful.

I just noticed that -fc-prototypes does not issue a prototype
for a global BIND(C) procedure. I'll probably fix that one soon.

[Bug middle-end/90345] New: too pessimistic check whether pointer may alias local variable

[vanyacpp at gmail dot com]

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

Bug ID: 90345
   Summary: too pessimistic check whether pointer may alias local
variable
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Consider the following example (reduced from a real program):

#include 
#include 

struct big_integer
{
void push_back(uint32_t const&);
size_t size;
uint32_t* digits;
};

big_integer& operator*=(big_integer& a, uint32_t b)
{
uint64_t const BASE = 1ull << 32;

uint32_t carry = 0;
for (size_t i = 0; i != a.size; i++)
{
uint64_t sum = 1ull * a.digits[i] * b + carry;
carry = static_cast(sum / BASE);
a.digits[i] = static_cast(sum % BASE);
}

if (carry)
{
a.push_back(carry);
//a.push_back(uint32_t(carry));
}

return a;
}

GCC 9.1 compiles the inner loop to this:
.L9:
mov esi, DWORD PTR [rsp+12]  ; load carry
.L5:
mov edx, DWORD PTR [rcx]
add rcx, 4
imulrdx, r8
add rdx, rsi
mov rsi, rdx
shr rsi, 32
mov DWORD PTR [rsp+12], esi  ; store carry
mov DWORD PTR [rcx-4], edx
cmp r9, rcx
jne .L9

As one can see carry is spilled to stack and it is loaded and stored at each
iteration of the loop. Loading and storing carry at each iteration is not
needed: it is a local variable and its address is not taken.

My guess is that GCC believes that it escapes because of the push_back after
the loop. At least if I make a copy of carry before push_back'ing it (as shown
in the comment) the problem goes away.

I think that alias analysis can be improved here: carry may not alias
a.digits[i] because it escapes only after the loop.

[Bug translation/90176] diagnostics should generally contain underscore only inside quotes

[roland.illig at gmx dot de]

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

Roland Illig  changed:

   What|Removed |Added

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

--- Comment #6 from Roland Illig  ---
The linter has been committed in r270704.

[Bug fortran/90344] New: small code that compiles and runs in 7.3.0 but not 7.4.1

[urbanjost at comcast dot net]

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

Bug ID: 90344
   Summary: small code that compiles and runs in 7.3.0 but not
7.4.1
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

Created attachment 46288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46288=edit
minimal test case that still causes segfault

The test case is the minimal code that I could get to reproduce a segmentation
fault at compile time with optimization level >0 on Cygwin with gfortran 7.4.1.
This same code worked in version 7.3.0.  I get

   BUG.f90:19:0:

   write(*,*)all(func1(s2a('ABCDEFG')).or.func2(s2a('ABCDEFG')))

internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Almost any change and the fault goes away. If the WRITE uses just FUNC1 or
FUNC2 or does not call S2A or just about any other change and the segfault goes
away. Goes away with -O0; but occurs with -O1 switch.

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Sat May  4 14:35:33 2019
New Revision: 270874

URL: https://gcc.gnu.org/viewcvs?rev=270874=gcc=rev
Log:
PR libstdc++/90299 make filesystem::absolute overloads consistent

In this implementation it is an error to pass the empty path to absolute,
because the empty path doesn't represent any file in the filesystem so
the function cannot meet its postcondition.

Currently the absolute(const path&, error_code&) overload reports an
error for the empty path, but using errc::no_such_file_or_directory, and
the other overload does not report an error. This patch makes them
consistntly report an errc::invalid_argument error for the empty path.

PR libstdc++/90299
* src/c++17/fs_ops.cc (absolute(const path&)): Report an error if the
argument is an empty path.
(absolute(const path&, error_code&)): Use invalid_argument as error
code instead of no_such_file_or_directory.
* testsuite/27_io/filesystem/operations/absolute.cc: Check handling
of non-existent paths and empty paths with both overloads of absolute.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/fs_ops.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc

[Bug rtl-optimization/90343] New: ICE: in verify_dominators, at dominance.c:1184 (error: dominator of 7 status unknown)

[asolokha at gmx dot com]

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

Bug ID: 90343
   Summary: ICE: in verify_dominators, at dominance.c:1184 (error:
dominator of 7 status unknown)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 46287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46287=edit
Testcase

g++-10.0.0-alpha20190428 snapshot (r270633) ICEs when compiling the attached
partially reduced testcase w/ -Os -fnon-call-exceptions -fstack-protector
-fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop -fno-tree-dse --param
uninlined-function-insns=20:

% g++-10.0.0-alpha20190428 -Os -fnon-call-exceptions -fstack-protector -fno-dce
-fno-forward-propagate -fno-rerun-cse-after-loop -fno-tree-dse --param
uninlined-function-insns=20 -c zx3i3ubt.cc
zx3i3ubt.cc: In function 'int h6()':
zx3i3ubt.cc:120:1: error: dominator of 7 status unknown
  120 | }
  | ^
during RTL pass: ce2
zx3i3ubt.cc:120:1: internal compiler error: in verify_dominators, at
dominance.c:1184
0x6a6cf8 verify_dominators(cdi_direction)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190428/work/gcc-10-20190428/gcc/dominance.c:1184
0xba6cad checking_verify_dominators
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190428/work/gcc-10-20190428/gcc/dominance.h:76
0xba6cad calculate_dominance_info(cdi_direction)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190428/work/gcc-10-20190428/gcc/dominance.c:746
0xb3e1b2 flow_loops_find(loops*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190428/work/gcc-10-20190428/gcc/cfgloop.c:431
0xde156e loop_optimizer_init(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190428/work/gcc-10-20190428/gcc/loop-init.c:93
0x17efc33 if_convert
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190428/work/gcc-10-20190428/gcc/ifcvt.c:5374
0x17f262d execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190428/work/gcc-10-20190428/gcc/ifcvt.c:5553

clang, icc, and msvc actually reject this code.

[Bug c++/90342] Misleading #include system fixit when using an older C++ version

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-04
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed (make_unique was added in C++14).

[Bug c++/90342] New: Misleading #include system fixit when using an older C++ version

[blitzrakete at gmail dot com]

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

Bug ID: 90342
   Summary: Misleading #include system fixit when using an older
C++ version
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blitzrakete at gmail dot com
  Target Milestone: ---

#include 

int main() {
  std::make_unique();
}

If I compile this with -std=c++11, I get:

: In function 'int main()':

:4:8: error: 'make_unique' is not a member of 'std'

4 |   std::make_unique();

  |^~~

:2:1: note: 'std::make_unique' is defined in header ''; did you
forget to '#include '?

1 | #include 

  +++ |+#include 

2 | 

:4:20: error: expected primary-expression before 'int'

4 |   std::make_unique();

  |^~~

Compiler returned: 1

That note is very misleading, since failing to include that header is not the
reason why std::make_unique doesn't exist.

[Bug c++/90339] Change default c++ dialect to -std=gnu++17 in gcc 10 ?

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> But bugzilla is not the place for that discussion, it's not a bug.

I probably should have said that I think the g...@gcc.gnu.org mailing list is
the right place.

[Bug c++/90339] Change default c++ dialect to -std=gnu++17 in gcc 10 ?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I've suggested this in private too, and we should consider it at some point
during gcc-10 stage 1. I think now is too soon to do it though.

But bugzilla is not the place for that discussion, it's not a bug.

[Bug libstdc++/90277] Debug Mode test failures

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
François, are you sure this is the right PR number for commit r270868?

[Bug fortran/90111] Placement of Fortran OpenACC 'routine' directive inside 'specification-part'

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-04
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I see in the F2018 draft:

R504 specification-part is [ use-stmt ] ...
[ import-stmt ] ...
[ implicit-part ]
[ declaration-construct ] ...

AFAIU it, I expect the directive

  !$acc routine seq

have to go into the [ declaration-construct ].

[Bug fortran/90112] internal procedure using module procedure instead of "sibling" internal procedure

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-04
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (10.0).

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  ---
(In reply to Thomas Koenig from comment #4)
> (In reply to Janne Blomqvist from comment #3)
> > 1) When compiling an external procedure, for character(len=1) arguments we
> > don't generate the hidden string length argument. And similarly when calling
> > an external procedure, if a len=1 character is passed, we omit the hidden
> > string length argument. This, I believe, is what Paul is suggesting in the
> > previous comment?
> 
> Unfortunately, this would not work :-(
> 
> While looking at the R source, I have also found some occurences
> where 'F' was spelled out 'Full'.

Ah, indeed. 

> Also, what could be done with CALL FOO ('a', 'bcd') ?

My idea would be to not pass the hidden string length for the 'a' argument, but
pass it for the 'bcd' argument.

But as you mention above, there are indeed several ways in which his heuristic
can be broken.

I have a vague memory that other Fortran compilers have special-cased length-1
string arguments, though.

> > 2) External procedures with character arguments are compiled and called as
> > varargs functions. This is what Thomas is suggesting, except unconditionally
> > and not controlled by an option.
> 
> Not an option, unfortunately :-(
> 
> This would bring back PR 87689, and this was an ABI breakage on
> a primary GCC platform (POWER) with perfectly standard-compliant
> code.

Wasn't the problem here that the caller was using varargs, while the callee was
compiled as a normal function, thus causing the mismatch?

So my suggestion was that external procedures be compiled as varargs as well,
which would make the caller and callee ABI's to match.

But now that I think about it, it wouldn't help this LAPACK case, as here the C
side has a non-varargs prototype so the C caller will in any case not use the
varargs convention. And I've never seen any C code defining prototypes to
Fortran procedures as varargs either, so I guess this option is a non-starter.

Bluh.

> > I'm not really happy with either of these, but the third option, of fixing
> > all Fortran-calling code out there isn't realistic either.
> 
> Currently, I am leaning towards using an option with a mandatory
> warning (no way to turn it off) which does not push any string lenghts
> onto the stack at all, something like -fbroken-character-abi,
> which we would use for external procedures without an explicit interface.

Hmm, wouldn't this completely break procedures with "character(len=*)" dummy
arguments? Or did mean that it would be used only for length=1 strings?

> I can also extend -fc-prototypes so that it also issues prototypes
> for any global procedures outside of BIND(C), or add a new option.

This might be useful.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Janne Blomqvist from comment #3)
> Ooof!
> 
> (Just for the record, I don't think we should revert to the previous
> behavior. Whatever we do should be robust in the face of LTO etc.)

I concur.

> I'd rather not see extra command-line arguments. For something which
> modifies the ABI and somehow works by accident part of the time, this is
> just too difficult to keep track of for end users, IMHO.
> 
> My suggestions:
> 
> 1) When compiling an external procedure, for character(len=1) arguments we
> don't generate the hidden string length argument. And similarly when calling
> an external procedure, if a len=1 character is passed, we omit the hidden
> string length argument. This, I believe, is what Paul is suggesting in the
> previous comment?

Unfortunately, this would not work :-(

While looking at the R source, I have also found some occurences
where 'F' was spelled out 'Full'.

Also, what could be done with CALL FOO ('a', 'bcd') ?

> 2) External procedures with character arguments are compiled and called as
> varargs functions. This is what Thomas is suggesting, except unconditionally
> and not controlled by an option.

Not an option, unfortunately :-(

This would bring back PR 87689, and this was an ABI breakage on
a primary GCC platform (POWER) with perfectly standard-compliant
code.

> I'm not really happy with either of these, but the third option, of fixing
> all Fortran-calling code out there isn't realistic either.

Currently, I am leaning towards using an option with a mandatory
warning (no way to turn it off) which does not push any string lenghts
onto the stack at all, something like -fbroken-character-abi,
which we would use for external procedures without an explicit interface.

The warning would have to be mandatory to a) point people towards what's
wrong with their code, and b) avoid questions of "why does my code
no longer work".

I can also extend -fc-prototypes so that it also issues prototypes
for any global procedures outside of BIND(C), or add a new option.

[Bug c++/90341] pcsx2-git: "At global scope: cc1plus: internal compiler error: Segmentation fault"

[kyle.devir at mykolab dot com]

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

--- Comment #2 from Kyle De'Vir  ---
I hope this amount of info is sufficient to debug the issue. :)

[Bug c++/90341] pcsx2-git: "At global scope: cc1plus: internal compiler error: Segmentation fault"

[kyle.devir at mykolab dot com]

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

--- Comment #1 from Kyle De'Vir  ---
Created attachment 46286
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46286=edit
Required preprocessed files

[Bug c++/90341] New: pcsx2-git: "At global scope: cc1plus: internal compiler error: Segmentation fault"

[kyle.devir at mykolab dot com]

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

Bug ID: 90341
   Summary: pcsx2-git: "At global scope: cc1plus: internal
compiler error: Segmentation fault"
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyle.devir at mykolab dot com
  Target Milestone: ---

Created attachment 46285
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46285=edit
command line and error output

gcc -v output:

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/run/media/valmar/Data/Packages/AUR/IndependentGit/gcc-git/src/gcc/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto
Thread model: posix
gcc version 9.1.1 20190503 (GCC)

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-04
 Ever confirmed|0   |1

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #3 from Janne Blomqvist  ---
Ooof!

(Just for the record, I don't think we should revert to the previous behavior.
Whatever we do should be robust in the face of LTO etc.)

I'd rather not see extra command-line arguments. For something which modifies
the ABI and somehow works by accident part of the time, this is just too
difficult to keep track of for end users, IMHO.

My suggestions:

1) When compiling an external procedure, for character(len=1) arguments we
don't generate the hidden string length argument. And similarly when calling an
external procedure, if a len=1 character is passed, we omit the hidden string
length argument. This, I believe, is what Paul is suggesting in the previous
comment?

2) External procedures with character arguments are compiled and called as
varargs functions. This is what Thomas is suggesting, except unconditionally
and not controlled by an option.


I'm not really happy with either of these, but the third option, of fixing all
Fortran-calling code out there isn't realistic either.

[Bug fortran/90093] Extended C interop: optional argument incorrectly identified as PRESENT

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
I'll take it. I do not think that it is a regression but I will backport the
fix, when it exists :-)

Cheers

Paul

[Bug tree-optimization/89595] [8 Regression] DOM miscompiles code

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #8 from Mikael Pettersson  ---
Seems like the backport to gcc-8 didn't include the test case.  At least two of
the test cases mentioned in r270841 aren't actually in the svn repo on
gcc-8-branch.  An unintentional omission?

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Hi Thomas and Tomas,

I am investigating a problem with the ISO_Fortran_binding implementation and
discovered that the hidden string length disappears when the procedure is
declared as bind(C). This obviously correct.

Would this problem be fixed if all external procedure calls without an explicit
interface, where a single character is being passed, were treated likewise?

Cheers

Paul

[Bug libstdc++/90277] Debug Mode test failures

[fdumont at gcc dot gnu.org]

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

--- Comment #1 from François Dumont  ---
Author: fdumont
Date: Sat May  4 07:41:39 2019
New Revision: 270870

URL: https://gcc.gnu.org/viewcvs?rev=270870=gcc=rev
Log:
Add missing PR libstdc++/90277 reference.

Modified:
trunk/libstdc++-v3/ChangeLog