[Bug c++/91344] New: Function pointers in templates with restrict semantics may fail to compile.

[a-yee at u dot northwestern.edu]

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

Bug ID: 91344
   Summary: Function pointers in templates with restrict semantics
may fail to compile.
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a-yee at u dot northwestern.edu
  Target Milestone: ---

The following code compiles on Clang, MSVC, and ICC. But it fails on GCC.

https://godbolt.org/z/zHq0qi


#include 
using namespace std;

#ifdef _WIN32
#define RESTRICT __restrict
#else
#define RESTRICT __restrict__
#endif


//  Works
//template  using r_ptr = type *;

//  Fails
template  using r_ptr = type *RESTRICT;


template  ptr)>
void foo(){
int x = 123;
fp();
}

void fp(r_ptr ptr){
cout << ptr[0] << endl;
}

int main(int argc, char* argv[]) {

foo();

}



But on GCC, it gives:

: In function 'int main(int, char**)':

:30:13: error: no matching function for call to 'foo()'

   30 | foo();

  | ^

:19:6: note: candidate: 'template)> void foo()'

   19 | void foo(){

  |  ^~~

:19:6: note:   template argument deduction/substitution failed:

:30:13: error: could not convert template argument 'fp' from
'void(r_ptr)' {aka 'void(int*)'} to 'void (*)(int* __restrict__)'

   30 | foo();

  | ^

ASM generation compiler returned: 1

: In function 'int main(int, char**)':

:30:13: error: no matching function for call to 'foo()'

   30 | foo();

  | ^

:19:6: note: candidate: 'template)> void foo()'

   19 | void foo(){

  |  ^~~

:19:6: note:   template argument deduction/substitution failed:

:30:13: error: could not convert template argument 'fp' from
'void(r_ptr)' {aka 'void(int*)'} to 'void (*)(int* __restrict__)'

   30 | foo();

  |

[Bug c++/91343] New: Spurious strict-aliasing warning with template class inheritance.

[a-yee at u dot northwestern.edu]

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

Bug ID: 91343
   Summary: Spurious strict-aliasing warning with template class
inheritance.
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a-yee at u dot northwestern.edu
  Target Milestone: ---

The following code leads to a strict-aliasing warning. But there is no aliasing
here.

https://godbolt.org/z/m2P_4-

Possibly Related or Duplicate:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89960
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81152


#include 
using namespace std;

struct Parent{
int data = 0;
};

template 
class Child : public Parent{
public:
static int func(){
Child tp;
int x = tp.data;
return x;
}
};

template class Child;


int main(){

}





: In static member function 'static int Child::func()':

:13:17: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]

   13 | int x = tp.data;

  | ^~

ASM generation compiler returned: 0

: In static member function 'static int Child::func()':

:13:17: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]

   13 | int x = tp.data;

  | ^~

[Bug target/91342] New: Incorrect parameter type for AVX512 streaming intrinsics.

[a-yee at u dot northwestern.edu]

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

Bug ID: 91342
   Summary: Incorrect parameter type for AVX512 streaming
intrinsics.
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a-yee at u dot northwestern.edu
  Target Milestone: ---

According to Intel's docs, all 4 of the AVX512 streaming instructions take void
pointers.

void _mm512_stream_ps (void* mem_addr, __m512 a)
void _mm512_stream_pd (void* mem_addr, __m512d a)
void _mm512_stream_si512 (void* mem_addr, __m512i a)
__m512i _mm512_stream_load_si512 (void const* mem_addr)


But GCC's implementation takes typed pointers.

https://godbolt.org/z/Dkte12

[Bug target/91341] New: Missing AVX Intrinsics: load/store u2

[a-yee at u dot northwestern.edu]

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

Bug ID: 91341
   Summary: Missing AVX Intrinsics: load/store u2
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a-yee at u dot northwestern.edu
  Target Milestone: ---

The following intrinsics are missing:
 - _mm256_loadu2_m128()
 - _mm256_storeu2_m128()
 - _mm256_loadu2_m128d()
 - _mm256_storeu2_m128d()
 - _mm256_loadu2_m128i()
 - _mm256_storeu2_m128i()

https://godbolt.org/z/1jj_-e

[Bug target/91340] New: Missing AVX and AVX512 Intrinsics: Zero-Extension

[a-yee at u dot northwestern.edu]

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

Bug ID: 91340
   Summary: Missing AVX and AVX512 Intrinsics: Zero-Extension
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a-yee at u dot northwestern.edu
  Target Milestone: ---

All the zero-extension intrinsics are missing: https://godbolt.org/z/JV8I51

#include 

int main()
{
//  128 -> 256
_mm256_zextps128_ps256(_mm_setzero_ps());
_mm256_zextpd128_pd256(_mm_setzero_pd());
_mm256_zextsi128_si256(_mm_setzero_si128());

//  128 -> 256
_mm512_zextps128_ps512(_mm_setzero_ps());
_mm512_zextpd128_pd512(_mm_setzero_pd());
_mm512_zextsi128_si512(_mm_setzero_si128());

//  256 -> 512
_mm512_zextps256_ps512(_mm256_setzero_ps());
_mm512_zextpd256_pd512(_mm256_setzero_pd());
_mm512_zextsi256_si512(_mm256_setzero_si256());

}

[Bug c++/91338] Implement P1161R3: Deprecate a[b,c]

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00200.html

[Bug d/91339] New: libphobos: ftbfs when the path contains '~'

[syq at debian dot org]

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

Bug ID: 91339
   Summary: libphobos: ftbfs when the path contains '~'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: syq at debian dot org
  Target Milestone: ---

How to reproduce:

In Debian buster:
  apt install \
libc6-dev-mips64-mipsr6el-cross \
libc6-dev-mipsn32-mipsr6el-cross \
libc6-dev-mipsr6el-cross \
libc6-mips64-mipsr6el-cross \
libc6-mipsn32-mipsr6el-cross \
libc6-mipsr6el-cross \
linux-libc-dev-mipsr6el-cross


download official gcc 9 from ftp of gcc

tar xf gcc-9.1.0.tar.xz
mv gcc-9.1.0 gcc-9.1.0~
cd gcc-9.1.0~
mkdir build && cd build
../configure --target mipsisa32r6el-linux-gnu --with-sysroot=/ --prefix=/usr
--libdir=/usr/lib --includedir=/usr/mipsisa32r6el-linux-gnu/include
--enable-libphobos --enable-languages=c,c++,d
make

Then libphobos will fail to configure:

configure:5360: checking If /root/gcc-9/gcc-9.1.0~/build/./gcc/gdc
-B/root/gcc-9/gcc-9.1.0~/build/./gcc/ -B/usr/mipsisa32r6el-linux-gnu/bin/
-B/usr/mipsisa32r6el-linux-gnu/lib/ -isystem
/usr/mipsisa32r6el-linux-gnu/include -isystem
/usr/mipsisa32r6el-linux-gnu/sys-includecan compile D sources
configure:5370: /root/gcc-9/gcc-9.1.0~/build/./gcc/gdc
-B/root/gcc-9/gcc-9.1.0~/build/./gcc/ -B/usr/mipsisa32r6el-linux-gnu/bin/
-B/usr/mipsisa32r6el-linux-gnu/lib/ -isystem
/usr/mipsisa32r6el-linux-gnu/include -isystem
/usr/mipsisa32r6el-linux-gnu/sys-include-c -fno-moduleinfo -nostdinc -I
/root/gcc-9/gcc-9.1.0~/libphobos/libdruntime  -g -O2 conftest.d >&5
d21: error: cannot find source code for runtime library file 'object.d'
d21: note: dmd might not be correctly installed. Run 'dmd -man' for
installation instructions.
d21: note: config file: not found
configure:5370: $? = 1
configure: failed program was:
| module mod;
|
|
| extern(C) int main() {
|   return 0;
| }
configure:5374: result: no
configure:5376: error: can't compile D sources!

[Bug c++/91335] False positive "unused variable" warning with variable initialized in 'if' condition

[zeratul976 at hotmail dot com]

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

--- Comment #2 from Nathan Ridge  ---
I suppose a fair question here is, if I'm not going to use 'f', why don't I
just write:

  if (foo()) {
return 1;
  }

?

That would certainly work in this case. However, in the original code example
that motivated this report, foo() returned a class type which had a templated
conversion operator, and it's the result of that conversion operator
(instantiated with a pointer type) that I wanted to test. In such a case, I
need the declaration form to trigger invoking the conversion operator.

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe  ---
fixed on trunk and for 9.2

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[iains at gcc dot gnu.org]

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

--- Comment #22 from Iain Sandoe  ---
Author: iains
Date: Sat Aug  3 20:16:22 2019
New Revision: 274049

URL: https://gcc.gnu.org/viewcvs?rev=274049=gcc=rev
Log:
Darwin, backport fix for PR87030

273746 , 273749, 273768 [Darwin] Fix PR87030 and tidy config fragments.

This is about 32/64b host and multilib support across the range of Darwin
systems.

Prior to Darwin8 (OS X 10.4), the toolchains support only PowerPC and only 32b.

On Darwin8 it is possible to target a 64b multilib, but with support limited
to a few of the main libraries on the system (not a recommended configuration).

>From Darwin9 to Darwin17 (OSX 10.5 to 10.13) it is possible to have either
32 or 64b hosted toolchains, with support for a 64 or 32b multilib
respectively.

On Darwin9 the kernel is 32b, but with support for 64b executables, so it's
conventional to build a 32b host toolchain supporting a 64b multilib. However
this is not enforced (merely a convention).

There is also some platform hardware supporting Darwin10/11 which is only 32b
and for which the same situation applies. However, from Darwin10 to Darwin17,
the majority of platform hardware supports a 64b kernel and it's conventional
to build a 64b host toolchain with support for a 32b multilib.

On/from Darwin18 (OS X 10.14), the development headers (in the SDK) no longer
expose the interfaces for the 32b multilib support (although sufficient runtime
support remains installed that the testsuite can be run for a 32b multilib).

The PR is raised against this latter situation since the absence of exposed
interfaces causes a 'default' bootstrap fail regardless of the availability of
the runtimes. Given the number of permutations, I felt it warranted a general
solution, especially since the current scheme of target headers and t-make
fragments has become somewhat messy.

The changes here enforce the single 32b PowerPC multilib for Darwin < 8 and the
single X86 64b multilib for Darwin >= 18. This means that there is no longer
any need to configure Darwin18+ '--disable-multilib', but also that if you want
to use the ability to continue to test the compiler's 32b multilib there, you
need to make a configuration targeting an earlier OS version (and using the
SDK from that).

2019-08-03  Iain Sandoe  

Backport from mainline
2019-07-24  Iain Sandoe  

PR bootstrap/87030
* config/i386/darwin.h (REAL_LIBGCC_SPEC): Revert change from r273749.

PR bootstrap/87030
* config/i386/darwin.h (REAL_LIBGCC_SPEC): Move from here...
* config/i386/darwin32-biarch.h .. to here.
* config/i386/darwin64-biarch.h: Adjust comments.
* config/rs6000/darwin32-biarch.h: Likewise.
* config/rs6000/darwin64-biarch.h: Likewise.
* config.gcc: Missed commit from r273746
(*-*-darwin*): Don't include CPU t-darwin here.
(i[34567]86-*-darwin*): Adjust to use biarch files. Produce
an error message if i686-darwin configuration is attempted for
Darwin >= 18.

Backport from mainline
2019-07-23  Iain Sandoe  

PR bootstrap/87030
* config.gcc (*-*-darwin*): Don't include CPU t-darwin here.
(i[34567]86-*-darwin*): Adjust to use biarch files. Produce
an error message if i686-darwin configuration is attempted for
Darwin >= 18.
(x86_64-*-darwin*): Switch to single multilib for Darwin >= 18.
(powerpc-*-darwin*): Use biarch files where needed.
(powerpc64-*-darwin*): Likewise.
* config/i386/darwin.h (REAL_LIBGCC_SPEC): Move to new biarch file.
(DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single
arch case.
* config/i386/darwin32-biarch.h: New.
* config/i386/darwin64.h: Rename.
* gcc/config/i386/darwin64-biarch.h: To this.
* config/i386/t-darwin: Rename.
* gcc/config/i386/t-darwin32-biarch: To this.
* config/i386/t-darwin64: Rename.
* gcc/config/i386/t-darwin64-biarch: To this.
* config/rs6000/darwin32-biarch.h: New.
* config/rs6000/darwin64.h: Rename.
* config/rs6000/darwin64-biarch.h: To this.
(DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single
arch case.
* config/rs6000/t-darwin8: Rename.
* config/rs6000/t-darwin32-biarch: To this.
* config/rs6000/t-darwin64 Rename.
* config/rs6000/t-darwin64-biarch: To this.


Added:
branches/gcc-9-branch/gcc/config/i386/darwin32-biarch.h
branches/gcc-9-branch/gcc/config/i386/darwin64-biarch.h
branches/gcc-9-branch/gcc/config/i386/t-darwin32-biarch
branches/gcc-9-branch/gcc/config/i386/t-darwin64-biarch
branches/gcc-9-branch/gcc/config/rs6000/darwin32-biarch.h
branches/gcc-9-branch/gcc/config/rs6000/darwin64-biarch.h
branches/gcc-9-branch/gcc/config/rs6000/t-darwin32-biarch
branches/gcc-9-branch/gcc/config/rs6000/t-darwin64-biarch

[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.

[chinoune.mehdi at hotmail dot com]

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

Chinoune  changed:

   What|Removed |Added

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

--- Comment #3 from Chinoune  ---
Sorry, It wasn't a bug. the compiler is not skipping the if statement.

-fassociative-math : Allow re-association of operands in series of
floating-point operations. This violates the ISO C and C++ language standard by
possibly changing computation result. NOTE: re-ordering may change the sign of
zero as well as ignore NaNs and inhibit or create underflow or overflow (and
thus cannot be used on code
that relies on rounding behavior like (x + 2**52) - 2**52. May also reorder
floating-point comparisons and thus may not be used when ordered comparisons
are required.

-fassociative-math is enabled by -funsafe-math-optimizations .

[Bug c++/91338] Implement P1161R3: Deprecate a[b,c]

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-03
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/91338] New: Implement P1161R3: Deprecate a[b,c]

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91338
   Summary: Implement P1161R3: Deprecate a[b,c]
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per .

[Bug middle-end/90597] [9/10 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed||2019-8-3

--- Comment #3 from John David Anglin  ---
Probably, this is triggered because alignment of type is set to
MAX_OFILE_ALIGNMENT.

[Bug middle-end/90597] [9/10 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
/* However, if the underlying mode requires a bigger alignment than
   what the target hook provides, we cannot use the mode.  For now,
   simply reject that case.  */
gcc_assert (TYPE_ALIGN (type)
>= GET_MODE_ALIGNMENT (TYPE_MODE (type)));

Breakpoint 1, layout_type (type=0x83fffde98930)
at ../../gcc/gcc/stor-layout.c:2401
2401gcc_assert (TYPE_ALIGN (type)
(gdb) p debug_tree(type)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
83fffddd33f0 precision:8 min  max

pointer_to_this >
BLK
size  constant 1073741824>
unit-size  constant 134217728>
align:32768 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
83fffde98930 nunits:134217728>
$1 = void

(gdb) bt
#0  layout_type (type=0x83fffde98930) at ../../gcc/gcc/stor-layout.c:2401
#1  0x40bee0ac in make_vector_type (innertype=0x7e00, nunits=...,
mode=E_VOIDmode) at ../../gcc/gcc/tree.c:10154
#2  0x40bee354 in build_vector_type (innertype=,
nunits=...) at ../../gcc/gcc/tree.c:11074
#3  0x4042c750 in handle_vector_size_attribute (
node=0x83fffde98930, name=, args=,
flags=, no_add_attrs=)
at ../../gcc/gcc/poly-int.h:671
#4  0x4033ae40 in decl_attributes (node=0x0,
attributes=, flags=, last_decl=0x0)
at ../../gcc/gcc/attribs.c:718
#5  0x40345bcc in c_decl_attributes (node=0x83fffde98930,
attributes=0x7e00, flags=0) at ../../gcc/gcc/c/c-decl.c:4837
#6  0x40358fac in start_decl (declarator=0x83fffddd33f0,
declspecs=0x83fffddc5a20, initialized=,
attributes=) at ../../gcc/gcc/c/c-decl.c:4976
#7  0x403afed8 in c_parser_declaration_or_fndef (
parser=0x83fffdec5000, fndef_ok=false,
static_assert_ok=, empty_ok=,
nested=, start_attr_ok=,
objc_foreach_object_declaration=,
omp_declare_simd_clauses=..., oacc_routine_data=,
---Type  to continue, or q  to quit---
fallthru_attr_p=) at ../../gcc/gcc/c/c-parser.c:2154
#8  0x403b9388 in c_parser_external_declaration (
parser=0x83fffde98930) at ../../gcc/gcc/c/c-parser.c:1653
#9  0x403ba170 in c_parser_translation_unit (parser=)
at ../../gcc/gcc/c/c-parser.c:1534
#10 c_parse_file () at ../../gcc/gcc/c/c-parser.c:19871
#11 0x40412274 in c_common_parse_file ()
at ../../gcc/gcc/c-family/c-opts.c:1160
#12 0x40927c44 in compile_file () at ../../gcc/gcc/toplev.c:456
#13 0x in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Sat, Aug 03, 2019 at 03:14:57PM +, kargl at gcc dot gnu.org wrote:
> --- Comment #1 from kargl at gcc dot gnu.org ---
> (In reply to Chinoune from comment #0)
> > I have encountered some underflows/overflows in my code compiled with
> > -Ofast, and after investigations it seems like the complex abs gives zero
> > with small numbers. So I added a workaround. but it didn't work:
> > 
> 
> (snip)
> 
> > 
> > gfortran-9 -O1 -funsafe-math-optimizations -ffinite-math-only
> > bug_skip_if.f90 -o test.x
> > ./test.x
> 
> (snip)
> 
> > 
> > Q : Why does gfortran skip the if statement?
> 
> What happens if you don't use options that allow
> a compiler to violate the standard?
> 

BTW, with the posted code, I cannot reproduce your results
on either i586-*-freebsd or  x86_64-*-freebsd.

[Bug middle-end/90597] [9/10 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Created attachment 46667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46667=edit
Preproccessed source

[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Severity|normal  |minor

[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Chinoune from comment #0)
> I have encountered some underflows/overflows in my code compiled with
> -Ofast, and after investigations it seems like the complex abs gives zero
> with small numbers. So I added a workaround. but it didn't work:
> 

(snip)

> 
> gfortran-9 -O1 -funsafe-math-optimizations -ffinite-math-only
> bug_skip_if.f90 -o test.x
> ./test.x

(snip)

> 
> Q : Why does gfortran skip the if statement?

What happens if you don't use options that allow
a compiler to violate the standard?


'-Ofast'
 Disregard strict standards compliance.  '-Ofast' enables all '-O3'
 optimizations.  It also enables optimizations that are not valid
 for all standard-compliant programs.  It turns on '-ffast-math' and
 the Fortran-specific '-fstack-arrays', unless
 '-fmax-stack-var-size' is specified, and '-fno-protect-parens'.

'-ffast-math'
 Sets the options '-fno-math-errno', '-funsafe-math-optimizations',
 '-ffinite-math-only', '-fno-rounding-math', '-fno-signaling-nans',
 '-fcx-limited-range' and '-fexcess-precision=fast'.

 This option causes the preprocessor macro '__FAST_MATH__' to be
 defined.

 This option is not turned on by any '-O' option besides '-Ofast'
 since it can result in incorrect output for programs that depend on
 an exact implementation of IEEE or ISO rules/specifications for
 math functions.  It may, however, yield faster code for programs
 that do not require the guarantees of these specifications.

'-funsafe-math-optimizations'

 Allow optimizations for floating-point arithmetic that (a) assume
 that arguments and results are valid and (b) may violate IEEE or
 ANSI standards.  When used at link time, it may include libraries
 or startup files that change the default FPU control word or other
 similar optimizations.

 This option is not turned on by any '-O' option since it can result
 in incorrect output for programs that depend on an exact
 implementation of IEEE or ISO rules/specifications for math
 functions

[Bug tree-optimization/91326] VRP does not handle array value range

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Related to https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01559.html (which
hasn't been applied).

[Bug c++/91230] [9/10 Regression] Template function containing lambda expression that has auto parameter and uses __PRETTY_FUNCTION__ does not compile

[btzy1996 at gmail dot com]

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

--- Comment #6 from Bernard Teo  ---
Thank you.  I've tried and it works on trunk.

[Bug fortran/90786] [7/8 Regression] ICE on procedure pointer assignment to function with class pointer result

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

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

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[tkoenig at gcc dot gnu.org]

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

--- Comment #37 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Aug  3 11:50:39 2019
New Revision: 274038

URL: https://gcc.gnu.org/viewcvs?rev=274038=gcc=rev
Log:
2019-08-03  Thomas Koenig  
Paul Thomas 

Backport from trunk
PR fortran/90786
PR fortran/90813
* trans-expr.c (pointer_assignment_is_proc_pointer) Remove as
it is very simple and only called from one place.
(gfc_trans_pointer_assignment): Rename non_proc_pointer_assign
as non_proc_ptr_assign. Assign to it directly, rather than call
to above, deleted function and use gfc_expr_attr instead of
only checking the reference chain.
* trans-decl.c (sym_identifier): New function.
(mangled_identifier): New function, doing most of the work
of gfc_sym_mangled_identifier.
(gfc_sym_mangled_identifier): Use mangled_identifier.  Add mangled
identifier to global symbol table.
(get_proc_pointer_decl): Use backend decl from global identifier
if present.

2019-08-03  Thomas Koenig  
Paul Thomas 

Backport from trunk
PR fortran/90786
PR fortran/90813
* gfortran.dg/proc_ptr_51.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/proc_ptr_51.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-decl.c
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/90786] [7/8 Regression] ICE on procedure pointer assignment to function with class pointer result

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Aug  3 11:50:39 2019
New Revision: 274038

URL: https://gcc.gnu.org/viewcvs?rev=274038=gcc=rev
Log:
2019-08-03  Thomas Koenig  
Paul Thomas 

Backport from trunk
PR fortran/90786
PR fortran/90813
* trans-expr.c (pointer_assignment_is_proc_pointer) Remove as
it is very simple and only called from one place.
(gfc_trans_pointer_assignment): Rename non_proc_pointer_assign
as non_proc_ptr_assign. Assign to it directly, rather than call
to above, deleted function and use gfc_expr_attr instead of
only checking the reference chain.
* trans-decl.c (sym_identifier): New function.
(mangled_identifier): New function, doing most of the work
of gfc_sym_mangled_identifier.
(gfc_sym_mangled_identifier): Use mangled_identifier.  Add mangled
identifier to global symbol table.
(get_proc_pointer_decl): Use backend decl from global identifier
if present.

2019-08-03  Thomas Koenig  
Paul Thomas 

Backport from trunk
PR fortran/90786
PR fortran/90813
* gfortran.dg/proc_ptr_51.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/proc_ptr_51.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-decl.c
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/91337] New: gfortran skips an if statement with some mathematical optimisations with complex numbers.

[chinoune.mehdi at hotmail dot com]

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

Bug ID: 91337
   Summary: gfortran skips an if statement with some mathematical
optimisations with complex numbers.
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chinoune.mehdi at hotmail dot com
  Target Milestone: ---

I have encountered some underflows/overflows in my code compiled with -Ofast,
and after investigations it seems like the complex abs gives zero with small
numbers. So I added a workaround. but it didn't work:

module m
  implicit none
  !
  integer, parameter :: sp = selected_real_kind(6)
  real(sp), parameter :: tiny_sp = tiny(1._sp), sqrt_tiny = sqrt( tiny_sp )
  !
contains
  subroutine sub(z,y)
complex(sp), intent(in) :: z
real(sp), intent(out) :: y
real(sp) :: az
!
az = abs(z)
if( az

[Bug c++/91336] Missing -Wcast-qual?

[hahnjo at hahnjo dot de]

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

--- Comment #1 from Jonas Hahnfeld  ---
Created attachment 4
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4=edit
Small test case.

I'm attaching another small test case that shows 3 casts, GCC only warns about
the first one. Interestingly the latest Intel Compiler also warns about the
second one.

[Bug sanitizer/91325] [ASAN] ASAN hangs at throw if called via dlopen

[jensseidel at users dot sf.net]

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

--- Comment #4 from Jens Seidel  ---
LLVM was affected by the same bug. They fixed it. But why is it not
reproducable to everyone?

https://bugs.llvm.org/show_bug.cgi?id=39641

[Bug c++/91336] New: Missing -Wcast-qual?

[hahnjo at hahnjo dot de]

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

Bug ID: 91336
   Summary: Missing -Wcast-qual?
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hahnjo at hahnjo dot de
  Target Milestone: ---

Created attachment 46665
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46665=edit
Test case.

If I compile the attached example with
> $ g++ -c -Wall -Wextra -Wcast-qual cast-qual.cpp
I get many (correct) errors, but only one warning enabled by -Wcast-qual.

I think GCC is correct to flag the following:
> static const char cvar[4] = { 0 };
> [...]
> const char **p2 = (const char **)
> *p2 = "bla";
output:
> cast-qual.cpp:20:36: warning: cast from type ‘const char (*)[4]’ to type 
> ‘const char**’ casts away qualifiers [-Wcast-qual]
In this case, cvar is an array and is only cast to a pointer, so you should not
assign to *p2. Instead the correct cast is
> const char * const *p3 = (const char * const *)
and the assignment *p3 = "bla" leads to
> cast-qual.cpp:27:6: error: assignment of read-only location ‘* p3’

If the code instead defines
> static char var[4] = { 0 };
then the cast
> char **p2 = (char **)
does not lead to a warning while assigning to *p2 should still not work.
Similarly to above, I think the correct cast should be
> char * const *p3 = (char * const *)

Do you agree?

[Bug c++/91334] [10 Regression] ICE in propagate_necessity at gcc/tree-ssa-dce.c:813 since r273791

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||9.1.0
   Target Milestone|--- |10.0
Summary|[10 Regression] internal|[10 Regression] ICE in
   |compiler error: |propagate_necessity at
   |Segmentation fault  |gcc/tree-ssa-dce.c:813
   ||since r273791
  Known to fail||10.0

--- Comment #2 from Martin Liška  ---
Reduced test-case:

$ cat ice.cpp
struct Base {
  virtual ~Base();
};
struct Derived : Base {
  void operator delete(void *) {}
};
void foo() { Derived d1; }

$ gcc -O3 -c -fno-ipa-pure-const -fipa-sra -fno-early-inlining ice.cpp
during GIMPLE pass: cddce
ice.cpp: In destructor ‘virtual Derived::~Derived()’:
ice.cpp:7:26: internal compiler error: in gimple_call_arg, at gimple.h:3190
7 | void foo() { Derived d1; }
  |  ^
0x13198ce gimple_call_arg
/home/marxin/Programming/gcc/gcc/gimple.h:3190
0x1319924 gimple_call_arg
/home/marxin/Programming/gcc/gcc/gimple.h:3198
0x131c76a propagate_necessity
/home/marxin/Programming/gcc/gcc/tree-ssa-dce.c:813
0x131f0b1 perform_tree_ssa_dce
/home/marxin/Programming/gcc/gcc/tree-ssa-dce.c:1663
0x131f1f3 tree_ssa_cd_dce
/home/marxin/Programming/gcc/gcc/tree-ssa-dce.c:1707
0x131f360 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-dce.c:1772

I've got a patch candidate for it.

[Bug c++/91334] [10 Regression] internal compiler error: Segmentation fault

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-03
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.