[Bug tree-optimization/83043] [8 Regression] FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 (found 0 times)

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-regression/2018-01/msg00362.html :
...
New passes:
  ...
FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2
loops carried no dependency" 1 (found 0 times)
FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times optimized
"loopfn" 8 (found 12 times)
...

[Bug c/71589] Atomic operation on a non-atomic variable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes this happens because the functions in  are defined as macros
which use the __atomic_xxx built-in functions, and they can operate on normal
non-atomic variables.

[Bug target/84431] Suboptimal code for masked shifts (x86/x86-64)

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Ruslan Nikolaev from comment #4)
> Thanks! I was wondering if the patch also fixes the same thing for x86-64
> (i.e., -m64); in which case we would have something like this:
> 
> __uint128_t func(__uint128_t a, unsigned shift)
> {
>return a << (shift & 63);
> }

Yes, the patch also handles __int128.

[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Reverting the resolve.c part of r254427 makes the problem go away.

[Bug tree-optimization/83126] [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
Created attachment 43476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43476=edit
Tentative patch

(In reply to rguent...@suse.de from comment #3)

> This is the usual "you should not repeat analysis during transform" issue.
> The vectorizer gets around this by caching relevant scalar evolution
> but obviously that's difficult if using generic stuff like
> canonicalize_loop_ivs ...

This patch caches affine_iv info before calling loop_version, and then uses
that cached info in canonicalize_loop_ivs. This fixes the ICE.

[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
r254426 works, r254427 crashes.

Paul, do you have any idea what could be causing this?

[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g

[aoliva at gcc dot gnu.org]

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

--- Comment #11 from Alexandre Oliva  ---
FYI, the patch I'm working on for PR 84404 will add forced view resets at
function entry points, which should alleviate this somewhat, assuming there's
more than one function in the testcase.

[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-21
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Alexandre Oliva  ---
On it.  At least in the x86_64 testcase in c3, the problem is that we have a
gomp function without line info, but with var loc bindings.  The bindings end
up as locview lists referencing a view that is never emitted, because there's
no line info to attach it to.

[Bug target/84431] Suboptimal code for masked shifts (x86/x86-64)

[nruslan_devel at yahoo dot com]

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

--- Comment #4 from Ruslan Nikolaev  ---
(In reply to Uroš Bizjak from comment #3)
> Created attachment 43471 [details]
> Prototype patch
> 
> Prototype patch, compiles the testcase to:
> 
> movl4(%esp), %eax
> movl12(%esp), %ecx
> movl8(%esp), %edx
> shldl   %eax, %edx
> sall%cl, %eax
> ret
> 
> The patch also handles right shifts and cases where mask is less than 31
> bits.

Thanks! I was wondering if the patch also fixes the same thing for x86-64
(i.e., -m64); in which case we would have something like this:

__uint128_t func(__uint128_t a, unsigned shift)
{
   return a << (shift & 63);
}

[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g

[aoliva at gcc dot gnu.org]

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

--- Comment #10 from Alexandre Oliva  ---
I forgot to mention, compiling with -ginternal-reset-location-views will issue
view resets where GCC would place them if the hook were defined so as to just
return zero, so we can easily confirm whether my guess as to the source of the
problem is correct, and whether insn lengths, as defined in GCC, are defined
correctly, at least as far as the current testcase goes.

[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g

[aoliva at gcc dot gnu.org]

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

--- Comment #9 from Alexandre Oliva  ---
Pardom for taking so long to chime in.

I suspect the source of the problem is the lack of internal view reset
computations.  Without that, the assembler gets an uninterrupted chain of
symbolic views, in which each view is computed based on the view before it and
the offset between the addresses in which they were issued.  Depending on the
order in which the assembler attempts to resolve each view to a constant, it
could get expensive.  It was never meant for this kind of use: it was expected
that most views would be zero-asserts, so this wouldn't arise.

This also points at the solution: to define the target hook that tells the
compiler which insns are reset points, so that the compiler can use the
assembler .loc view support in the way it was designed to be used.

If insn lengths, as computed by gcc, are enough to determine whether or not an
insn takes up any code space, defining the reset_location_view target hook to
just return zero will do; otherwise, if more elaborate decisions are needed, it
may return 1 or -1 to override the length-based computation.

[Bug middle-end/21161] [6/7/8 Regression] "clobbered by longjmp" warning ignores the data flow

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
Just to record some thoughts.

The implementation of the "clobbered by longjmp" warning essentially looks at
the objects that are live at the setjmp point.  In theory we can do better when
we're dealing with setjmp/sigsetjmp (but not getcontext for example).

In theory we can look at the code after the setjmp for this kind of pattern:

(insn 15 14 21 2 (set (reg:SI 91 [  ])
(reg:SI 0 ax)) "j.c":18 86 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 0 ax)
(nil)))
(insn 21 15 22 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 91 [  ])
(const_int 0 [0]))) "j.c":18 7 {*cmpsi_ccno_1}
 (nil))
(jump_insn 22 21 23 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 28)
(pc))) "j.c":18 672 {*jcc}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 719407028 (nil)))
 -> 28)

Since in the longjmp case, we know this will fallthru, we look at the what's
live-in in the fallthru successor.  If the test were inverted we'd (of course)
look at the live in of the target of the branch.  THat live-in set is what we
want to use to compute setjmp_crosses rather than what's actually live at the
setjmp (which is overly-conservative as it is the union of what's live on both
paths after the setjmp, only one of which we care about).

The implementation would be somewhat gross.  It'd have to account for the
differences between setjmp/sigsetjmp and things like savectx, vfork, and
getcontext.  It might be somewhat fragile since we'd be matching a series of
insns which could look radically different on some targets.  *But* a proof of
concept does seem to work.  I'm going to try to polish that up.

I haven't check if that addresses any of Florian's concerns from 61118. 
There's a reasonable chance it will.

Alternately this could be done on gimple, but I suspect factoring of the
abnormal dispatcher as well as the inaccurate CFG will kill us.

[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-20
 CC||kargl at gcc dot gnu.org
  Known to work||8.0
 Ever confirmed|0   |1
  Known to fail||6.4.1, 7.3.1

--- Comment #1 from kargl at gcc dot gnu.org ---
David,

This appears to be fixed on trunk, and broken on the
6 and 7 branches.  I don't have older versions lying
around to test.

 gfcx -o z a.f90 && ./z
 123456789
 123A6789
troutmask:sgk[205] gfc7 -o z a.f90 && ./z
 123456789
 123A678 
troutmask:sgk[206] gfc6 -o z a.f90 && ./z
 123456789
 123A678 

I'm not sure if a back port of the patch (if one can even
be identified) can be applied to branches due to changes
in how strings are handled.

I'll mark this as NEW and hopefully others can chime in.

[Bug target/84475] pthread doesn't define _REENTRANT in preprocessor on riscv-linux

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Note that _REENTRANT is a no-op with glibc 2.25 or later unless you 
specifically select an old standard version (in which case it's an alias 
for _POSIX_C_SOURCE=199506L).

[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
This happened somewhere between r254362 (OK) and r254430 (not OK).

Bisection is running.

[Bug fortran/84495] New: Incorrect result for concatenation of Fortran allocatable string

[david.sagan at gmail dot com]

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

Bug ID: 84495
   Summary: Incorrect result for concatenation of Fortran
allocatable string
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.sagan at gmail dot com
  Target Milestone: ---

Using gfortran 7.3.0:

Davids-Mac-mini:~/Bmad> gfortran --version
GNU Fortran (MacPorts gcc7 7.3.0_0) 7.3.0


Test program is:

program test
character(:), allocatable :: str
allocate(character(3) :: str)
str = '123456789'
print *, str
str = str(1:3) // 'A' // str(6:)
print *, str
end program


Running gives:

Davids-Mac-mini:~/Bmad> gfortran test.f90
Davids-Mac-mini:~/Bmad> ./a.out 
 123456789
 123A678 

Notice that the second line is missing a "9" at the end. That is, it should be
"123A6789".

[Bug c++/84494] New: Invalid constexpr with default assignment operator

[pigman46 at gmail dot com]

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

Bug ID: 84494
   Summary: Invalid constexpr with default assignment operator
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pigman46 at gmail dot com
  Target Milestone: ---

$ cat test.cpp
#include 

struct X
{
constexpr X() = default;
constexpr X(int x) : m_value(x) {}
constexpr X& operator=(const X ) = default;

int m_value {};
};

int main ()
{
constexpr int x = (X() = X(10)).m_value;
std::cout << x << std::endl;
std::cout << (X() = X(10)).m_value << std::endl;
}




g++ -v -save-temps -o test test.cpp -Wall -Wextra
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180130 (Red Hat 7.3.1-2) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/7/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -Wall -Wextra -fpch-preprocess -o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/7/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/7/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7

/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/backward
 /usr/lib/gcc/x86_64-redhat-linux/7/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/7/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -Wall -Wextra
-version -o test.s
GNU C++14 (GCC) version 7.3.1 20180130 (Red Hat 7.3.1-2) (x86_64-redhat-linux)
compiled by GNU C version 7.3.1 20180130 (Red Hat 7.3.1-2), GMP version
6.1.2, MPFR version 3.1.5, MPC version 1.0.2, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.3.1 20180130 (Red Hat 7.3.1-2) (x86_64-redhat-linux)
compiled by GNU C version 7.3.1 20180130 (Red Hat 7.3.1-2), GMP version
6.1.2, MPFR version 3.1.5, MPC version 1.0.2, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 41dde25dbc62f10f0477c356c02ccf33
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o test.o test.s
GNU assembler version 2.29 (x86_64-redhat-linux) using BFD version version
2.29-6.fc27
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/7/:/usr/libexec/gcc/x86_64-redhat-linux/7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/7/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/7/:/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/7/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/7/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
-plugin-opt=-fresolution=test.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o test
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o

[Bug c/80502] Provide macro to indicate OpenMP SIMD support

[e...@coeus-group.com]

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

--- Comment #3 from Evan Nemerson  ---
(In reply to Jakub Jelinek from comment #2)
> _OPENMP_SIMD is a bad idea, that namespace is reserved for OpenMP, so unless
> it shows up in the OpenMP standard, it shouldn't be added.

Fair enough, I'll propose it to the OpenMP people:
http://forum.openmp.org/forum/viewtopic.php?f=23=2031

> Why do you need a macro?  Just use #pragma omp simd etc. unconditionally,
> compilers that don't have support for such pragmas will just ignore those.

Not necessarily; often they'll emit warnings (for GCC, -Wall even includes
-Wunknown-pragmas). I'd much rather use the preprocessor in my code than teach
people to disable warnings.

I need to support alternatives in my code. For example, for SIMDe
(), I try to support OpenMP SIMD and Cilk
Plus, as well as compiler-specific pragmas for GCC (GCC ivdep), ICC (simd), and
clang (clang loop ...), and I'd be happy to add more as necessary. I'd rather
not end up with something like

  #pragma omp simd
  #pragma simd
  #pragma GCC ivdep
  #pragma clang loop vectorize(enable)
  for (...) { ... }

I'd much rather just have a few macros which will expand to the right pragma
based on preprocessor macros. Right now I'm stuck using the much less
expressive ivdep syntax for GCC unless *full* OpenMP support is enabled (or
someone defines a macro manually to indicate OpenMP SIMD support).

[Bug fortran/83980] Various issues with character length in array constructors

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
(In reply to Dominique d'Humieres from comment #4)
> The ICEs have replaced with errors between revisions r256574 (2018-01-12,
> ICE) and r256917 (2018-01-20, errors). What is surprising is that pr83823
> uses a similar construct, but does not give any error.

The fix for pr83823 seems to have fixed the problems reported in
comment #0 and comment #2 for 8.0 trunk.  The issues persist up to
7.2 (haven't checked 7.3).

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0

--- Comment #27 from Martin Liška  ---
Let me decrypt how clang generates the red zones. I can probably quickly come
up with a patch that will do the dynamic red zone size allocation. Having that
you'll be able to rebuild kernel and catch remaining issues.

[Bug c++/84493] New: [8 Regression] ICE with invalid cast

[reichelt at gcc dot gnu.org]

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

Bug ID: 84493
   Summary: [8 Regression] ICE with invalid cast
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE on trunk:

=
void foo()
{
  (struct {}x){};
}
=

bug.cc: In function 'void foo()':
bug.cc:3:13: error: expected ')' before 'x'
   (struct {}x){};
   ~ ^
 )
bug.cc:3:13: internal compiler error: in consume_open, at cp/parser.c:4711
0x6250d2 token_pair::consume_open(cp_parser*)
../../gcc/gcc/cp/parser.c:4711
0x626972 token_pair::consume_open(cp_parser*)
../../gcc/gcc/tree.h:3246
0x626972 cp_parser_braced_list
../../gcc/gcc/cp/parser.c:21928
0x930d90 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6989
0x931010 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91139f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
0x911baa cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x9133e4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9482
0x913af8 cp_parser_expression
../../gcc/gcc/cp/parser.c:9651
0x9157b8 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:8
0x91bb2d cp_parser_statement
../../gcc/gcc/cp/parser.c:10922
0x91d040 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d117 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933890 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933890 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
0x934140 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26694
0x934e74 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26610
0x934e74 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19482
0x93bf08 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13044
0x93cd18 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
Please submit a full bug report, [etc.]

The regression was introduced between 2017-08-10 and 2017-08-19.

[Bug c++/84492] New: [8 Regression] ICE with statement expression

[reichelt at gcc dot gnu.org]

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

Bug ID: 84492
   Summary: [8 Regression] ICE with statement expression
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following (invalid?) code snippet triggers an ICE on trunk:

=
template int foo()
{
  return ({ foo; });
}
=

bug.cc: In function 'int foo()':
bug.cc:3:19: internal compiler error: in instantiate_type, at cp/class.c:8012
   return ({ foo; });
   ^
0x5dacc3 instantiate_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/class.c:8009
0x9e2f4a convert_for_assignment
../../gcc/gcc/cp/typeck.c:8779
0x9e442a check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:9372
0x99efce finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:891
0x91c2c4 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12411
0x91c2c4 cp_parser_statement
../../gcc/gcc/cp/parser.c:10816
0x91d040 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d117 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933890 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933890 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
0x934140 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26694
0x934e74 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26610
0x934e74 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19482
0x93b02a cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:27150
0x93b16c cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26752
0x93ba2c cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:26989
0x93ba2c cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:27008
0x940d99 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12716
0x941081 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12643
0x941374 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
Please submit a full bug report, [etc.]

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #26 from Arnd Bergmann  ---
(In reply to Martin Liška from comment #25)
> (In reply to Arnd Bergmann from comment #24)
> 
> Ok, I don't have problem to implement the similar behavior in GCC 9. Looks
> most
> of warnings are in drivers. That should not be problem as I guess KASAN
> build is
> mainly used in a qemu machine (with syzkaller)? Thus exotic drivers should
> not
> be needed?

I actually have no idea in what other ways it may be used, though I didn't
think that running syzkaller was the only use case. It always feels like most
bugs in the kernel are in obscure drivers, but then most of the kernel code
consists of obscure drivers ;-)

Here are some warnings in code that is actually being run. For the full output
I see on linux-next, have a look at https://pastebin.com/CMJiUsuR. There
are a couple of other warnings mixed in there as well that I'm working on
addressing, but it's mainly the stack overflow once I turn on
CONFIG_KASAN_EXTRA.

arch/x86/kernel/cpu/mshyperv.c:261:1: warning: the frame size of 2704 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
arch/x86/kvm/emulate.c:2552:1: warning: the frame size of 2128 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
drivers/acpi/nfit/core.c:3168:1: warning: the frame size of 3952 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
drivers/firmware/efi/test/efi_test.c:688:1: warning: the frame size of 2400
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:83:1: warning:
the frame size of 3760 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/md/md.c:8561:1: warning: the frame size of 2544 bytes is larger than
2048 bytes [-Wframe-larger-than=]
drivers/net/bonding/bond_netlink.c:677:1: warning: the frame size of 2096 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
fs/btrfs/relocation.c:1202:1: warning: the frame size of 4272 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than
2048 bytes [-Wframe-larger-than=]
fs/jbd2/commit.c:1128:1: warning: the frame size of 3728 bytes is larger than
2048 bytes [-Wframe-larger-than=]
fs/nfs/pnfs.c:1892:1: warning: the frame size of 2672 bytes is larger than 2048
bytes [-Wframe-larger-than=]
fs/ntfs/mft.c:2756:1: warning: the frame size of 2352 bytes is larger than 2048
bytes [-Wframe-larger-than=]
fs/userfaultfd.c:1824:1: warning: the frame size of 2256 bytes is larger than
2048 bytes [-Wframe-larger-than=]
fs/xfs/libxfs/xfs_rmap.c:1334:1: warning: the frame size of 2384 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
kernel/rcu/tree.c:2282:1: warning: the frame size of 3160 bytes is larger than
2048 bytes [-Wframe-larger-than=]
lib/rbtree.c:481:1: warning: the frame size of 2520 bytes is larger than 2048
bytes [-Wframe-larger-than=]
mm/khugepaged.c:1560:1: warning: the frame size of 2976 bytes is larger than
2048 bytes [-Wframe-larger-than=]
mm/migrate.c:2129:1: warning: the frame size of 2104 bytes is larger than 2048
bytes [-Wframe-larger-than=]
mm/page_alloc.c:3247:1: warning: the frame size of 4584 bytes is larger than
2048 bytes [-Wframe-larger-than=]
mm/vmscan.c:1350:1: warning: the frame size of 5072 bytes is larger than 2048
bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1446:1: warning: the frame size of 2592 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/core/ethtool.c:2832:1: warning: the frame size of 3376 bytes is larger than
2048 bytes [-Wframe-larger-than=]
net/core/rtnetlink.c:1631:1: warning: the frame size of 2272 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/mac80211/util.c:2188:1: warning: the frame size of 2464 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/rxrpc/recvmsg.c:603:1: warning: the frame size of 2424 bytes is larger than
2048 bytes [-Wframe-larger-than=]
net/sctp/socket.c:7271:1: warning: the frame size of 2704 bytes is larger than
2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1938:1: warning: the frame size of 4248 bytes is larger
than 2048 bytes [-Wframe-larger-than=]

> The middle red zone is only 32B. So I don't understand why 'Size' not used
> for red zone
> calculation?

No idea.

[Bug libffi/84410] libffi doesn't support riscv now, but not disabled in configure.ac

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
The latest commit in  is working
well.

[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from Aldy Hernandez  ---
This is not a GCC bug.  Reported in binutils land, as per Jeff's suggestion in
comment #6.

https://sourceware.org/bugzilla/show_bug.cgi?id=22870

Oracle E-Business Suite Users List.

[Amy Hodge]

Hello there,



I would like to know if you are interested in acquiring Oracle E-Business Suite 
Users List.



Information fields: Names, Title, Email, Phone, Company Name, Company URL, 
Company physical address, SIC Code, Industry, Company Size (Revenue and 
Employee).



Let me know if you are interested and I will get back to you with the counts 
and pricing.



Regards,

Amy HodgeJ

Marketing Executive



To opt out, please reply with Leave Out in the Subject Line.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #19 from Martin Sebor  ---
Fixed in r257860.  (The remaining false positives are being tracked in bug
83456.)

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

--- Comment #18 from Martin Sebor  ---
Author: msebor
Date: Tue Feb 20 20:22:01 2018
New Revision: 257860

URL: https://gcc.gnu.org/viewcvs?rev=257860=gcc=rev
Log:
PR middle-end/84095 - false-positive -Wrestrict warnings for memcpy within
array

gcc/ChangeLog:

PR middle-end/84095
* gimple-ssa-warn-restrict.c (builtin_memref::extend_offset_range):
New.
(builtin_memref::set_base_and_offset): Same.  Handle inner references.
(builtin_memref::builtin_memref): Factor out parts into
set_base_and_offset and call it.

gcc/testsuite/ChangeLog:

PR middle-end/84095
* c-c++-common/Warray-bounds-3.c: Adjust text of expected warnings.
* c-c++-common/Wrestrict.c: Same.
* gcc.dg/Wrestrict-6.c: Same.
* gcc.dg/Warray-bounds-27.c: New test.
* gcc.dg/Wrestrict-8.c: New test.
* gcc.dg/Wrestrict-9.c: New test.
* gcc.dg/pr84095.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-27.c
trunk/gcc/testsuite/gcc.dg/Wrestrict-8.c
trunk/gcc/testsuite/gcc.dg/Wrestrict-9.c
trunk/gcc/testsuite/gcc.dg/pr84095.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-3.c
trunk/gcc/testsuite/c-c++-common/Wrestrict.c
trunk/gcc/testsuite/gcc.dg/Wrestrict-6.c

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
FWITW, here's a shorter test case:

PROGRAM main

TYPE :: test_typ
REAL, ALLOCATABLE :: a(:)
END TYPE

TYPE(test_typ) :: yy
TYPE(test_typ), ALLOCATABLE :: conc(:)

conc = [ yy ]

END PROGRAM main

[Bug c++/12333] [DR 272] Explicit call to MyClass::~MyClass() not allowed

[hiraditya at msn dot com]

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

--- Comment #17 from AK  ---
The following workarounds do not emit compiler errors, although I'm not sure if
second option is a correct workaround.

1. this->~X();
2. X::~X(0);

FYI,
ICC 18 also has the same bug. The first workaround works for ICC but not the
second one.

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed, closing.

[Bug fortran/48890] [F95] Wrong length of a character component of named constant derived-type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #9 from Thomas Koenig  ---
Resolved on trunk, closing.

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[tkoenig at gcc dot gnu.org]

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

Bug 48890 Summary: [F95] Wrong length of a character component of named 
constant derived-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48890

   What|Removed |Added

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

[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures

[tkoenig at gcc dot gnu.org]

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

Bug 48890 Summary: [F95] Wrong length of a character component of named 
constant derived-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48890

   What|Removed |Added

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

[Bug target/84479] [8 Regression] cryptopp miscompilation on powerpc64le starting with r256656

[kelvin at gcc dot gnu.org]

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

--- Comment #3 from kelvin at gcc dot gnu.org ---
I had begun to look at this before Segher resolved it as invalid.

One thing I had observed that their are some questionable practices in the
rijndael-simd.cpp code.  I had not yet dug deeply enough to confirm that these
would actually cause problems.

A patch that I merged with the trunk about the time this code began to fail
changed the Power8 back-end to select more efficient instructions whenever
vectors are "known" to be aligned.  This patch also became more aggressive in
its assessment of which vectors are aligned.  In some cases, the instructions
generated under the assumption that vectors are properly aligned in memory will
"fail silently", producing undefined or unexpected results, when supplied with
an address that is not properly aligned.

While we were previously very conservative, we now consider that any pointer
declared to refer to a vector is aligned on a multiple of the vector size. 
This means you cannot "safely" coerce "int *" to "vector int *", as happens,
for example, around line 715 of rijndael-simd.cpp.

There are various other places in this same source file that look suspicious to
me.

[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #9 from Paolo Carlini  ---
Note that the ICE in PR82410 happens in exactly the same way and Jakub's few
lines avoid that one too. Shall we further pursue the approach? Jason?

[Bug go/84484] libgo configure tests fail to find -latomic

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-20
 CC||wilson at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libffi/84410] libffi doesn't support riscv now, but not disabled in configure.ac

[wilson at gcc dot gnu.org]

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

--- Comment #2 from Jim Wilson  ---
FYI There is a libffi port at
https://github.com/riscv/riscv-libffi
but it is for an old ABI.  There are comments in issue 1 pointing at more up to
date but still not complete ports.

[Bug fortran/84487] [8 Regression] Large rodate section increase in 465.tonto with r257233

[jb at gcc dot gnu.org]

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

--- Comment #3 from Janne Blomqvist  ---
I suspect it's working as intended. From the patch there is this comment which
explains in equivalent C code the code which is generated:

   /* The string copy algorithm below generates code like

- if (dlen > 0) {
- memmove (dest, src, min(dlen, slen));
- if (slen < dlen)
- memset([slen], ' ', dlen - slen);
- }
+ if (destlen > 0)
+   {
+ if (srclen < destlen)
+   {
+ memmove (dest, src, srclen);
+ // Pad with spaces.
+ memset ([srclen], ' ', destlen - srclen);
+   }
+ else
+   {
+ // Truncate if too long.
+ memmove (dest, src, destlen);
+   }
+   }
   */

So with the new (or old, if you prefer, since this code was previously there
too, IIRC I changed it sometime in vicinity of January 2017) code, if either
srclen or destlen is a compile time constant, the compiler can inline expand
one of the memmove calls.

Does r257233 cause any change in performance for spec?

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #14 from Jeffrey A. Law  ---
Fixed by Richard's patch on the trunk.

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[law at gcc dot gnu.org]

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

--- Comment #13 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 19:11:34 2018
New Revision: 257858

URL: https://gcc.gnu.org/viewcvs?rev=257858=gcc=rev
Log:
PR middle-end/84406
* optabs-query.c (find_widening_optab_handler_and_mode): If from_mode
is a scalar_int_mode, assert that to_mode is a scalar_int_mode with
greater precision.  If to_mode is a MODE_PARTIAL_INT, stop the
search at the associated MODE_INT.

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

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[law at gcc dot gnu.org]

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

--- Comment #14 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:59:22 2018
New Revision: 257857

URL: https://gcc.gnu.org/viewcvs?rev=257857=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (format_integer): Query EVRP range analyzer
for range data rather than using global data.

* gcc.dg/pr81592.c: New test.
* gcc.dg/pr82123.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81592.c
trunk/gcc/testsuite/gcc.dg/pr82123.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[law at gcc dot gnu.org]

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

--- Comment #15 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:59:22 2018
New Revision: 257857

URL: https://gcc.gnu.org/viewcvs?rev=257857=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (format_integer): Query EVRP range analyzer
for range data rather than using global data.

* gcc.dg/pr81592.c: New test.
* gcc.dg/pr82123.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81592.c
trunk/gcc/testsuite/gcc.dg/pr82123.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:59:22 2018
New Revision: 257857

URL: https://gcc.gnu.org/viewcvs?rev=257857=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (format_integer): Query EVRP range analyzer
for range data rather than using global data.

* gcc.dg/pr81592.c: New test.
* gcc.dg/pr82123.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81592.c
trunk/gcc/testsuite/gcc.dg/pr82123.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/48890] [F95] Wrong length of a character component of named constant derived-type

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Feb 20 18:57:34 2018
New Revision: 257856

URL: https://gcc.gnu.org/viewcvs?rev=257856=gcc=rev
Log:
2018-02-20  Thomas Koenig  

PR fortran/48890
PR fortran/83823
* primary.c (gfc_convert_to_structure_constructor):
For a constant string constructor, make sure the length
is correct.

2018-02-20  Thomas Koenig  

PR fortran/48890
PR fortran/83823
* gfortran.dg/structure_constructor_14.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/structure_constructor_14.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Feb 20 18:57:34 2018
New Revision: 257856

URL: https://gcc.gnu.org/viewcvs?rev=257856=gcc=rev
Log:
2018-02-20  Thomas Koenig  

PR fortran/48890
PR fortran/83823
* primary.c (gfc_convert_to_structure_constructor):
For a constant string constructor, make sure the length
is correct.

2018-02-20  Thomas Koenig  

PR fortran/48890
PR fortran/83823
* gfortran.dg/structure_constructor_14.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/structure_constructor_14.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[law at gcc dot gnu.org]

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

--- Comment #13 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:56:56 2018
New Revision: 257855

URL: https://gcc.gnu.org/viewcvs?rev=257855=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (get_int_range): Query EVRP range analyzer for
range data rather than using global data.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:56:56 2018
New Revision: 257855

URL: https://gcc.gnu.org/viewcvs?rev=257855=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (get_int_range): Query EVRP range analyzer for
range data rather than using global data.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[law at gcc dot gnu.org]

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

--- Comment #14 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:56:56 2018
New Revision: 257855

URL: https://gcc.gnu.org/viewcvs?rev=257855=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (get_int_range): Query EVRP range analyzer for
range data rather than using global data.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:56:01 2018
New Revision: 257854

URL: https://gcc.gnu.org/viewcvs?rev=257854=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (get_int_range): Accept vr_values parameter
pass it to children as needed.
(struct directive::fmtresult): Similarly.
(struct directive::set_width): Similarly.
(struct directive::set_precision): Similarly.
(format_integer, format_directive, parse_directive): Similarly.
(format_none): Accept unnamed vr_values parameter.
(format_percent, format_floating, format_character): Similarly.
(format_string, format_plain): Similarly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[law at gcc dot gnu.org]

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

--- Comment #13 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:56:01 2018
New Revision: 257854

URL: https://gcc.gnu.org/viewcvs?rev=257854=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (get_int_range): Accept vr_values parameter
pass it to children as needed.
(struct directive::fmtresult): Similarly.
(struct directive::set_width): Similarly.
(struct directive::set_precision): Similarly.
(format_integer, format_directive, parse_directive): Similarly.
(format_none): Accept unnamed vr_values parameter.
(format_percent, format_floating, format_character): Similarly.
(format_string, format_plain): Similarly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:56:01 2018
New Revision: 257854

URL: https://gcc.gnu.org/viewcvs?rev=257854=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (get_int_range): Accept vr_values parameter
pass it to children as needed.
(struct directive::fmtresult): Similarly.
(struct directive::set_width): Similarly.
(struct directive::set_precision): Similarly.
(format_integer, format_directive, parse_directive): Similarly.
(format_none): Accept unnamed vr_values parameter.
(format_percent, format_floating, format_character): Similarly.
(format_string, format_plain): Similarly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:53:29 2018
New Revision: 257853

URL: https://gcc.gnu.org/viewcvs?rev=257853=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (sprintf_dom_walker::handle_gimple_call): Query
the EVRP range analyzer for range data rather than using global data.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:53:29 2018
New Revision: 257853

URL: https://gcc.gnu.org/viewcvs?rev=257853=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (sprintf_dom_walker::handle_gimple_call): Query
the EVRP range analyzer for range data rather than using global data.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:53:29 2018
New Revision: 257853

URL: https://gcc.gnu.org/viewcvs?rev=257853=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c (sprintf_dom_walker::handle_gimple_call): Query
the EVRP range analyzer for range data rather than using global data.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:52:07 2018
New Revision: 257852

URL: https://gcc.gnu.org/viewcvs?rev=257852=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c: Include alloc-pool.h, vr-values.h and
gimple-ssa-evrp-analyze.h
(class sprintf_dom_walker): Add after_dom_children member function.
Add evrp_range_analyzer member.
(sprintf_dom_walker::before_dom_children): Call into the EVRP
range analyzer as needed.
(sprintf_dom_walker::after_dom_children): New member function.

* gcc.dg/builtin-unreachable-6.c: Turn off VRP.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/builtin-unreachable-6.c

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:52:07 2018
New Revision: 257852

URL: https://gcc.gnu.org/viewcvs?rev=257852=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c: Include alloc-pool.h, vr-values.h and
gimple-ssa-evrp-analyze.h
(class sprintf_dom_walker): Add after_dom_children member function.
Add evrp_range_analyzer member.
(sprintf_dom_walker::before_dom_children): Call into the EVRP
range analyzer as needed.
(sprintf_dom_walker::after_dom_children): New member function.

* gcc.dg/builtin-unreachable-6.c: Turn off VRP.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/builtin-unreachable-6.c

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:52:07 2018
New Revision: 257852

URL: https://gcc.gnu.org/viewcvs?rev=257852=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-sprintf.c: Include alloc-pool.h, vr-values.h and
gimple-ssa-evrp-analyze.h
(class sprintf_dom_walker): Add after_dom_children member function.
Add evrp_range_analyzer member.
(sprintf_dom_walker::before_dom_children): Call into the EVRP
range analyzer as needed.
(sprintf_dom_walker::after_dom_children): New member function.

* gcc.dg/builtin-unreachable-6.c: Turn off VRP.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/builtin-unreachable-6.c

[Bug target/84479] [8 Regression] cryptopp miscompilation on powerpc64le starting with r256656

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
It was a bug in the original reporter's code.

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:49:46 2018
New Revision: 257851

URL: https://gcc.gnu.org/viewcvs?rev=257851=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-evrp-analyze.c (evrp_range_analyzer::enter): Do nothing
if not optimizing.
(evrp_range_analyzer::record_ranges_from_stmt): Likewise.
(evrp_range_analyzer::pop_to_marker): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-evrp-analyze.c

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:49:46 2018
New Revision: 257851

URL: https://gcc.gnu.org/viewcvs?rev=257851=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-evrp-analyze.c (evrp_range_analyzer::enter): Do nothing
if not optimizing.
(evrp_range_analyzer::record_ranges_from_stmt): Likewise.
(evrp_range_analyzer::pop_to_marker): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-evrp-analyze.c

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 20 18:49:46 2018
New Revision: 257851

URL: https://gcc.gnu.org/viewcvs?rev=257851=gcc=rev
Log:
PR middle-end/82123
PR tree-optimization/81592
PR middle-end/79257
* gimple-ssa-evrp-analyze.c (evrp_range_analyzer::enter): Do nothing
if not optimizing.
(evrp_range_analyzer::record_ranges_from_stmt): Likewise.
(evrp_range_analyzer::pop_to_marker): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-evrp-analyze.c

[Bug target/84481] [8 Regression] 429.mcf with -O2 regresses by ~6% and ~4%, depending on tuning, on Zen compared to GCC 7.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |8.0
Summary|429.mcf with -O2 regresses  |[8 Regression] 429.mcf with
   |by ~6% and ~4%, depending   |-O2 regresses by ~6% and
   |on tuning, on Zen compared  |~4%, depending on tuning,
   |to GCC 7.2  |on Zen compared to GCC 7.2

[Bug fortran/83319] [7/8 Regression] ICE on use of allocatable component in derived type coarray defined in module

[mexas at bristol dot ac.uk]

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

Anton Shterenlikht  changed:

   What|Removed |Added

 CC||mexas at bristol dot ac.uk

--- Comment #5 from Anton Shterenlikht  ---
I get the same error:

caf -c -O2 -Wall -fPIC -g -fbacktrace -fall-intrinsics
-fcheck-array-temporaries -fopenmp -I/usr/local/include cgca_m3pfem.f90
cgca_m3pfem.f90:1407:0:

 end module cgca_m3pfem

internal compiler error: in gfc_conv_descriptor_token, at
fortran/trans-array.c:305

20474701626e> caf -w
caf wraps /usr/local/bin/gfortran7
20474701626e> gfortran7 --version
GNU Fortran (FreeBSD Ports Collection) 7.3.0

I think this is a regression from 7.2 to 7.3.

This was building ok a couple weeks ago with 7.2.

It will take me a while to narrow down the problem code.

[Bug c++/84491] New: Multiple inheritance and covariant return types causes internal compiler error

[christopher.hood at gtri dot gatech.edu]

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

Bug ID: 84491
   Summary: Multiple inheritance and covariant return types causes
internal compiler error
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christopher.hood at gtri dot gatech.edu
  Target Milestone: ---

With respect to GCC 7.3.0, but I have tested on other GCCs down to 4.7 with the
same result.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/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 --enable-libmpx --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
Thread model: posix
gcc version 7.3.0 (GCC) 

This example using multiple inheritance and two branches of covariant virtual
functions causes the internal compiler error: 

test-thunk-error.cc: In instantiation of ‘struct Parents
>’:
test-thunk-error.cc:8:8:   required from ‘struct InterfaceBase >’
test-thunk-error.cc:37:24:   required from here
test-thunk-error.cc:4:8: internal compiler error: in make_thunk, at
cp/method.c:115
 struct Parents : P::Interface...
^~~

Judicious commenting of certain seemingly non-offensive lines will cause
compilation to succeed (any of lines commented a,b,c,d). The code which breaks
GCC does compile without error on Clang.


Example listing:

template 
struct Parents : P::Interface...
{};

template 
struct InterfaceBase : Parents
{
virtual T* Model ()=0; // a
};

struct Foo
{
struct Interface : InterfaceBase
{};
virtual Interface* Iface ()=0; // b
};

struct Bar
{
struct Interface : InterfaceBase
{};
virtual Interface* Iface ()=0; // c
};

template 
struct Constituent : T, U
{
struct Interface : InterfaceBase
{};
virtual Interface* Iface ()=0; // d
};

struct FooWithBar : Constituent
{
struct Interface : InterfaceBase
{};
};

int main ()
{
return 0;
}

[Bug go/84484] libgo configure tests fail to find -latomic

[ian at airs dot com]

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

--- Comment #8 from Ian Lance Taylor  ---
Odd.  In any case, the patch is simple:

diff --git a/libgo/configure b/libgo/configure
index aba4dc39..1b61c9ba 100755
--- a/libgo/configure
+++ b/libgo/configure
@@ -14210,6 +14210,9 @@ if test "${libgo_cv_lib_pthread+set}" = set; then :
 else
   CFLAGS_hold=$CFLAGS
 CFLAGS="$CFLAGS -pthread"
+if test -n "$LIBATOMIC"; then
+  CFLAGS="$CFLAGS -L../libatomic/.libs"
+fi
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 int i;
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 1264a1d2..aea47a42 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -494,6 +494,9 @@ AC_CACHE_CHECK([whether -pthread is supported],
 [libgo_cv_lib_pthread],
 [CFLAGS_hold=$CFLAGS
 CFLAGS="$CFLAGS -pthread"
+if test -n "$LIBATOMIC"; then
+  CFLAGS="$CFLAGS -L../libatomic/.libs"
+fi
 AC_COMPILE_IFELSE([[int i;]],
 [libgo_cv_lib_pthread=yes],
 [libgo_cv_lib_pthread=no])

[Bug target/84490] New: 436.cactusADM regressed by 6-8% percent with -Ofast on Zen, compared to gcc 7.2

[jamborm at gcc dot gnu.org]

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

Bug ID: 84490
   Summary: 436.cactusADM regressed by 6-8% percent with -Ofast on
Zen, compared to gcc 7.2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
  Target Milestone: ---

Compared to gcc 7.2, 436.cactusADM is about 8% and 6% slower when run
on an AND Ryzen and an AMD EPYC respectively after compiling it on
trunk with -Ofast (and generic march and tuning).

So far I have not done any bisecting, only verified that this is most
probably unrelated to PR 82362 because r251713 does not seem to have
any effect on the benchmark (the benchmark is already slow with that
revision).

[Bug go/84484] libgo configure tests fail to find -latomic

[sch...@linux-m68k.org]

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

--- Comment #7 from Andreas Schwab  ---
The patch file link.

[Bug c++/84489] New: Non-type template parameter dependency

[vince.rev at gmail dot com]

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

Bug ID: 84489
   Summary: Non-type template parameter dependency
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vince.rev at gmail dot com
  Target Milestone: ---

Created attachment 43475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43475=edit
Example code of the bug

Consider the following code in C++11.
=
#include 

template > 1)>
constexpr T f0() {return 0;}

template > 1)>
constexpr T f1() {return 0;}

int main()
{
f0(); // No bug
f1(); // Bug here
return 0;
}
=

It compiles well under g++ 4.7, 4.8, 4.9, 5.X but fails to compile under 6.X
and 7.X. It also compiles well under clang. The returned error is:

=
gcc_bug_template_bool.cpp: In function 'int main()':
gcc_bug_template_bool.cpp:12:8: error: no matching function for call to 'f1()'
 f1();
^
gcc_bug_template_bool.cpp:7:13: note: candidate: template
constexpr T f1()
 constexpr T f1() {return 0;}
 ^~
gcc_bug_template_bool.cpp:7:13: note:   template argument
deduction/substitution failed:
gcc_bug_template_bool.cpp:6:49: error: invalid use of template type parameter
'T'
 template > 1)>
  ~~~^
gcc_bug_template_bool.cpp:6:53: error: could not convert template argument
'' from '' to 'bool'
 template > 1)>
=

[Bug debug/83935] DWARF for a variant part is incorrect

[tromey at gcc dot gnu.org]

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

--- Comment #9 from Tom Tromey  ---
(In reply to Pierre-Marie de Rodat from comment #8)
> Understood, thank you for the notice! As we have to tweak the spec one way
> or another for Ada, I suggest indeed we keep the way things are implemented
> in GCC today, waiting for the DWARF committee to state on this. This will
> probably take a while, so I’m not sure what to do with this PR. ;-)

I suppose we could leave it open pending resolution.

> Can you please tell me when you managed to update GDB to work with variant?
> It could be interesting to see how it deals with GCC’s, and if it does not,
> how much work will be needed. Thank you in advance!

It is here: https://github.com/tromey/gdb/tree/variant-parts
I plan to submit it to gdb soon, like probably today.  There are 3 patches;
the first one introduces some minor changes to add discriminated unions
to gdb's type system, and the third one adds the DWARF reading parts.

I imagine there are some gaps between what I did and what Ada requires.
Since I don't know Ada I'm not really sure how big the gaps are.
I'd suggest reading it, then commenting on the gdb-patches post so that
it can be discussed there.

Dealing with the particular location of the discriminant might not be
too awful.  One simple idea would be to make a new artificial discriminant
in the discriminated union, essentially copying the member from the outer
struct.

There are two missing bits I know about: one is that I didn't need
DW_AT_discr_list, so I didn't add this.  This should be straightforward.
The other is that in Rust, a variant can only have a single member.
Multiple members could be dealt with in the current model by interposing
a new anonymous structure type, perhaps.

[Bug c/84483] powerpc sub-optimal code generation - conditional relative branch to and over blr

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
There is an empty asm right before the blr, so there is nothing the compiler
can do about this.

[Bug go/84484] libgo configure tests fail to find -latomic

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor  ---
Give me a hint: what doesn't work?

[Bug target/82096] [6 Regression] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE in |[6 Regression] ICE in
   |int_mode_for_mode, at   |int_mode_for_mode, at
   |stor-layout.c:403 with  |stor-layout.c:403 with
   |arm-linux-gnueabi   |arm-linux-gnueabi

--- Comment #12 from ktkachov at gcc dot gnu.org ---
Fixed on GCC 7 branch too.
Sudi, do you plan on backporting to GCC 6 as well?

[Bug c++/84488] Incorrect "set but not used" warning for static_cast(double)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 20 17:00:23 2018
New Revision: 257850

URL: https://gcc.gnu.org/viewcvs?rev=257850=gcc=rev
Log:
PR c++/84488
* g++.dg/warn/Wunused-var-30.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-30.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/84488] Incorrect "set but not used" warning for static_cast(double)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This got fixed with r257155 for GCC 8+.

[Bug c++/84488] New: Incorrect "set but not used" warning for static_cast(double)

[will at benfold dot com]

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

Bug ID: 84488
   Summary: Incorrect "set but not used" warning for
static_cast(double)
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: will at benfold dot com
  Target Milestone: ---

Test case:


int main ()
{
  enum Foo {};
  double one = 1.0;
  return static_cast(one);
}


Output:


$ g++ -Wall -Wextra -o minimal minimal.cpp && (./minimal; echo $?)
minimal.cpp: In function ‘int main()’:
minimal.cpp:4:10: warning: variable ‘one’ set but not used
[-Wunused-but-set-variable]
 double one  = 1.0;
  ^
1


Changing the (one) to (+one) is enough to silence the warning.

[Bug fortran/29616] Run-time check using nullified pointers and deallocated variables

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Compiling the test in comment 0 with -fcheck=all gives

At line 5 of file pr29616.f90
Fortran runtime error: Pointer actual argument 'r' is not associated

since at least 4.8.

[Bug fortran/84487] [8 Regression] Large rodate section increase in 465.tonto with r257233

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-reduction

--- Comment #2 from Martin Liška  ---
(In reply to Dominique d'Humieres from comment #1)
> Reproducer?

Unfortunately SPEC2006 benchmark. I'll try to reduce that to a single object
file.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
(In reply to Arnd Bergmann from comment #24)
> (In reply to Martin Liška from comment #23)
> 
> > That's definitely possible for GCC 9. Question is whether such change will
> > be sufficient for you. Do you expect it will reduce stack usage in the
> > desired way?
> 
> I've recreated my original finding, comparing a clang-5 release against a
> recent gcc-8 snapshot. Building an x86 allmodconfig kernel with clang, I get
> 78 -fsanitize-address-use-after-scope warnings against a 2048 byte limit,
> the largest ones are:
> 
> drivers/usb/misc/sisusbvga/sisusb.c:1880:12: warning: stack frame size of
> 6776 bytes in function 'sisusb_init_gfxcore' [-Wframe-larger-than=]
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c:1521:1: warning: stack
> frame size of 5176 bytes in function 'gk104_ram_new_' [-Wframe-larger-than=]
> drivers/usb/misc/sisusbvga/sisusb.c:1750:12: warning: stack frame size of
> 5112 bytes in function 'sisusb_set_default_mode' [-Wframe-larger-than=]
> drivers/net/wireless/atmel/atmel.c:1307:5: warning: stack frame size of 5016
> bytes in function 'atmel_open' [-Wframe-larger-than=]
> net/core/ethtool.c:2549:5: warning: stack frame size of 4568 bytes in
> function 'dev_ethtool' [-Wframe-larger-than=]
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:19216:6:
> warning: stack frame size of 4312 bytes in function 'wlc_phy_init_nphy'
> [-Wframe-larger-than=]
> drivers/media/usb/em28xx/em28xx-dvb.c:1129:12: warning: stack frame size of
> 3992 bytes in function 'em28xx_dvb_init' [-Wframe-larger-than=]
> drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c:6802:24:
> warning: stack frame size of 3960 bytes in function 'load_capture_binaries'
> [-Wframe-larger-than=]
> drivers/staging/wlan-ng/cfg80211.c:454:12: warning: stack frame size of 3864
> bytes in function 'prism2_connect' [-Wframe-larger-than=]
> drivers/staging/wilc1000/host_interface.c:2480:13: warning: stack frame size
> of 3704 bytes in function 'host_if_work' [-Wframe-larger-than=]
> 
> 
> With gcc-8, the same configuration has 179 warnings, including:
> 
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame
> size of 23632 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4515:1: warning: the frame
> size of 14056 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3879:1: warning: the frame
> size of 11504 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> lib/atomic64_test.c:250:1: warning: the frame size of 11192 bytes is larger
> than 2048 bytes [-Wframe-larger-than=]
> lib/atomic64_test.c:148:1: warning: the frame size of 10360 bytes is larger
> than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt73usb.c:1294:1: warning: the frame size
> of 8680 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger
> than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:8655:1: warning: the frame
> size of 6456 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:3090:1: warning: the frame size of
> 5872 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt61pci.c:1647:1: warning: the frame size
> of 5792 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:1595:1: warning: the frame size of
> 5304 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/scsi/fnic/fnic_trace.c:451:1: warning: the frame size of 5000 bytes
> is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:2417:1: warning: the frame
> size of 4912 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:4265:1: warning: the frame size of
> 4840 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> 
> Comparing against a 3072 byte limit, I get 18 warnings for clang vs 54 for
> gcc-8. The detailed analysis of some of those warnings last year had shown
> that the difference can be traced almost entirely to simple scalar variables
> that use 64 bytes redzone with gcc but only 16 bytes with clang.

Ok, I don't have problem to implement the similar behavior in GCC 9. Looks most
of warnings are in drivers. That should not be problem as I guess KASAN build
is
mainly used in a qemu machine (with syzkaller)? Thus exotic drivers should not
be needed?

I have question about clang where they use for instance:
else if (Size <= 128) Res = Size + 32;

So:

$ cat test.c
int
main (void)
{
  char my_char[N];
  char *ptr, *ptr2;
  {
char my_char2[N];
ptr = _char[N - 1];
ptr2 = _char2[N - 1];
  }

  return *(ptr2+8);
}

$ clang -v
clang version 5.0.1 (tags/RELEASE_501/final 312548)

$ clang test.c  

[Bug fortran/82814] ICE from submodule character function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING
  Known to work||8.0

--- Comment #5 from Dominique d'Humieres  ---
Any plan to back port the fix or should this PR be closed?

[Bug fortran/78990] [6/7/8 Regression] ICE when assigning polymorphic array function result

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Dominique d'Humieres  ---
Any plan to back port the fix or should this PR be closed?

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING
  Known to work||7.3.0, 8.0

--- Comment #21 from Dominique d'Humieres  ---
Shouldn't this PR be closed?

[Bug fortran/84487] [8 Regression] Large rodate section increase in 465.tonto with r257233

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-20
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Reproducer?

[Bug fortran/84487] New: [8 Regression] Large rodate section increase in 465.tonto with r257233

[marxin at gcc dot gnu.org]

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

Bug ID: 84487
   Summary: [8 Regression] Large rodate section increase in
465.tonto with r257233
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jb at gcc dot gnu.org
  Target Milestone: ---

After the revision:

 VM SIZE FILE SIZE
 ++ GROWING   ++
   +31%  +119Ki .rodata+119Ki   +31%
  +2.8% +92.5Ki .text +92.5Ki  +2.8%
  [ = ]   0 .debug_line   +41.0Ki  +9.5%
  [ = ]   0 .debug_info   +9.52Ki  +0.4%
  [ = ]   0 .debug_abbrev+669  +0.9%
  +0.1%+304 .eh_frame+304  +0.1%
  [ = ]   0 [Unmapped]   +166   +35%
  +0.0%  +8 .eh_frame_hdr  +8  +0.0%

 -- SHRINKING --
  [ = ]   0 .debug_loc -129Ki  -5.1%
  [ = ]   0 .debug_ranges-960  -1.0%
  [ = ]   0 .strtab  -250  -0.2%
  [ = ]   0 .debug_str-53  -0.0%

  +5.1%  +211Ki TOTAL  +132Ki  +1.3%

So .rodata is larger of 31%.

[Bug go/84484] libgo configure tests fail to find -latomic

[sch...@linux-m68k.org]

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

--- Comment #5 from Andreas Schwab  ---
That doesn't work.

[Bug target/84371] test case gcc.target/powerpc/builtins-3.c fails on power9

[carll at gcc dot gnu.org]

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

--- Comment #5 from Carl Love  ---
Will, I am guessing the recent changes that I made to the vec_neg builtin might
be getting you.  The vec_neg was orignially using P7 expansion macros but it
used P8 rtl so when compiled with -mcpu=power7 the vec_neg builtin would give
an ICE.  The macro expansions for vec_neg, vec_float2, vec_signed2 and
vec_unsigned2 are all being changed from P7 expansion macros to P8 expansion
macros to fix GCC internal compiler errors when compiled with -mcpu=power7.

See  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 for the list of test
cases that fail with -mcpu=power7.

[Bug go/84484] libgo configure tests fail to find -latomic

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
To get the change from https://golang.org/cl/95436 in the form of a patch,
click on the download link (middle of the screen on the right) then click on
one of the "patch file" links at the bottom of the pop-up window.

[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g

[aldyh at redhat dot com]

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

--- Comment #7 from Aldy Hernandez  ---
Ok. Will do.

On Feb 20, 2018 15:12, "law at redhat dot com" 
wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
>
> Jeffrey A. Law  changed:
>
>What|Removed |Added
> 
> 
>  CC||law at redhat dot com
>
> --- Comment #6 from Jeffrey A. Law  ---
> ISTM that we ought to take the generated .s file and file a bug report
> against
> gas/binutils.  There really isn't anything GCC can do here.
>
> Aldy, want to run with that?  Obviously close this out once the
> gas/binutils
> report is filed...
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
Ok, so the PR is still marked as P1, so we should probably focus on it.
If I'm reading the discussion correctly, there's no consensus about what to do?

[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386

[jakub at gcc dot gnu.org]

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

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

Untested fix.  Sadly the warning code for some weird reason relies on the bogus
PHI handling (strangely COND_EXPR is handled differently), but obviously in
code generation we can't allow that, if there is any PHI argument or any
COND_EXPR we don't know anything about, we can't use it for range info.

[Bug tree-optimization/84486] New: code hoisting removes alignment assumption

[krebbel at gcc dot gnu.org]

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

Bug ID: 84486
   Summary: code hoisting removes alignment assumption
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43473=edit
Autoreduced testcase

The __atomic_compare_exchange_n builtin on s390 uses the cdsg (compare and swap
double) instruction for 16 byte aligned operands and falls back to a library
call otherwise. Since the code hoisting change r238242 alignment hints applied
with __builtin_assume_aligned appear to get lost and we get a library call for
the attached testcase.

hardware instruction: -O1
libatomic call with: -O1 -fcode-hoisting

[Bug tree-optimization/84485] New: [6/7 Regression] Vectorising zero-stride rmw operation

[rsandifo at gcc dot gnu.org]

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

Bug ID: 84485
   Summary: [6/7 Regression] Vectorising zero-stride rmw operation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

r223486 meant that we could vectorise:

void
f (unsigned long incx, unsigned long incy,
   float *restrict dx, float *restrict dy)
{
  unsigned long ix = 0, iy = 0;
  for (unsigned long i = 0; i < 512; ++i)
{
  dy[iy] += dx[ix];
  ix += incx;
  iy += incy;
}
}

without first proving that incy is nonzero.  At the time this
particular testcase needed -fno-vect-cost-model on both x86_64 and
aarch64, but by the time of the GCC 6 and 7 releases, the aarch64
vectorisation costs allowed it to be vectorised at -O3.

This was fixed for GCC 8 with r256644, but that's obviously
much too invasive to backport.

[Bug go/84484] libgo configure tests fail to find -latomic

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
https://golang.org/cl/95436 doesn't contain any patch.

[Bug c/84229] A valid code rejected with -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
For reference, this is open implementation from Jessie version of glibc that
trigeers the issue
__fortify_function int  
open (const char *__path, int __oflag, ...) 
{   
  if (__va_arg_pack_len () > 1) 
__open_too_many_args ();

  if (__builtin_constant_p (__oflag))   
{   
  if (__OPEN_NEEDS_MODE (__oflag) && __va_arg_pack_len () < 1)  
{   
  __open_missing_mode ();   
  return __open_2 (__path, __oflag);
}   
  return __open_alias (__path, __oflag, __va_arg_pack ());  
}   

  if (__va_arg_pack_len () < 1) 
return __open_2 (__path, __oflag);  

  return __open_alias (__path, __oflag, __va_arg_pack ());  
}   

I am testing patch to prevent signature changes here. I suppose that those
functions are meant to be inlined and thus function signature changes are not
that important.

Still it would be nice to error on use in nonvariadic functions.

[Bug go/84484] libgo configure tests fail to find -latomic

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---

contains a preliminary patch to add support for riscv, you also need

for libffi.

[Bug c/84229] A valid code rejected with -flto

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka  ---
This bug also triggers with firefox build where open is variadic function.  I
suppose we want to prevent signature changes here?

[Bug go/84484] libgo configure tests fail to find -latomic

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Does the patch in https://golang.org/cl/95436 fix the problem?

Note that there will be other problems building libgo for riscv: it will need
to be added to goarch.sh, match.sh, and testsuite/gotest, and a bunch of files
will need build constraints added.

[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
ISTM that we ought to take the generated .s file and file a bug report against
gas/binutils.  There really isn't anything GCC can do here.

Aldy, want to run with that?  Obviously close this out once the gas/binutils
report is filed...

[Bug tree-optimization/84419] [8 Regression] SPEC CPU2017/CPU2006 521/621, 527/627, 554/654, 445, 454, 481, 416 runfails after r256628 with march=skylake-avx512

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Fixed by Richard's commit on the trunk.

[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Hmm, seems like the attribute-less variant isn't being found by type_hash_canon
for some reason.  I guess because nothing actually uses it, so GC discards it,
because the type table has been marked as "cache".

For GCC 8 we can probably just drop the assert.