[Bug rtl-optimization/84682] [6/7/8 Regression] internal compiler error: Segmentation fault (process_address_1)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||aoliva at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #4 from Alexandre Oliva  ---
Mine

[Bug target/84757] New: Useless MOVs and PUSHes to store results of MUL

[b7.10110111 at gmail dot com]

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

Bug ID: 84757
   Summary: Useless MOVs and PUSHes to store results of MUL
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

Consider the following C code:

#ifdef __SIZEOF_INT128__
typedef __uint128_t Longer;
#else
typedef unsigned long long Longer;
#endif
typedef unsigned long Shorter;

Shorter mulSmarter(Shorter a, Shorter b, Shorter* upper)
{
const Longer ab=(Longer)a*b;
*upper=ab >> 8*sizeof(Shorter);
return ab;
}

On amd64 with -m64 option I get identical assembly on both gcc 7.x and 6.3. But
on x86 (or amd64 with -m32) assembly is different, and on gcc 7.x is less
efficient. See to compare:

# gcc 6.3
mulSmarter:
  mov eax, DWORD PTR [esp+8]
  mul DWORD PTR [esp+4]
  mov ecx, edx
  mov edx, DWORD PTR [esp+12]
  mov DWORD PTR [edx], ecx
  ret

# gcc 7.3
mulSmarter:
  push esi
  push ebx
  mov eax, DWORD PTR [esp+16]
  mul DWORD PTR [esp+12]
  mov esi, edx
  mov edx, DWORD PTR [esp+20]
  mov ebx, eax
  mov eax, ebx
  mov DWORD PTR [edx], esi
  pop ebx
  pop esi
  ret

The gcc 6.3 version is already not perfect, but it's much better than that of
7.3.

[Bug tree-optimization/84740] [8 Regression] ICE in build_constructors, at tree-switch-conversion.c:965

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/84740] [8 Regression] ICE in build_constructors, at tree-switch-conversion.c:965

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  8 07:29:42 2018
New Revision: 258354

URL: https://gcc.gnu.org/viewcvs?rev=258354=gcc=rev
Log:
PR tree-optimization/84740
* tree-switch-conversion.c (process_switch): Call build_constructors
only if info.phi_count is non-zero.

* gcc.dg/torture/pr84740.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr84740.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-switch-conversion.c

[Bug target/84756] New: Multiplication done twice just to get upper and lower parts of product

[b7.10110111 at gmail dot com]

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

Bug ID: 84756
   Summary: Multiplication done twice just to get upper and lower
parts of product
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

Consider the following C code valid for both x86 and amd64 targets:

#ifdef __SIZEOF_INT128__
typedef __uint128_t Longer;
#else
typedef unsigned long long Longer;
#endif
typedef unsigned long Shorter;

Shorter mul(Shorter a, Shorter b, Shorter* upper)
{
*upper=(Longer)a*b >> 8*sizeof(Shorter);
return (Longer)a*b;
}

Longer lmul(Shorter a, Shorter b)
{
return (Longer)a*b;
}

From lmul function I get the expected good assembly:

lmul:
mov eax, DWORD PTR [esp+8]
mul DWORD PTR [esp+4]
ret

But for mul gcc generates two multiplications instead of one:

mul:
pushebx
mov ecx, DWORD PTR [esp+8]
mov ebx, DWORD PTR [esp+12]
mov eax, ecx
mul ebx
mov eax, DWORD PTR [esp+16]
mov DWORD PTR [eax], edx
mov eax, ecx
imuleax, ebx
pop ebx
ret

Here 'mul ebx' is used to get the upper part of the result, and `imul eax, ebx`
is supposed to ge the lower part, although it has already been present right
after `mul ebx` in eax register.

Similar problem happens when I use -m64 option for gcc to get amd64 code.

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
What configure flags for that specially configured gcc?
Can you in a debugger pt whatever tree_operand_hash::hash is called on?
I certainly can't reproduce this with a cross to powerpc64-linux, even under
valgrind it is clear.

[Bug tree-optimization/84739] [6/7 Regression] ICE in get_value_for_expr, at tree-ssa-ccp.c:649

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |get_value_for_expr, at  |get_value_for_expr, at
   |tree-ssa-ccp.c:649  |tree-ssa-ccp.c:649

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/84739] [6/7/8 Regression] ICE in get_value_for_expr, at tree-ssa-ccp.c:649

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  8 06:56:59 2018
New Revision: 258351

URL: https://gcc.gnu.org/viewcvs?rev=258351=gcc=rev
Log:
PR tree-optimization/84739
* tree-tailcall.c (find_tail_calls): Check call arguments against
DECL_ARGUMENTS (current_function_decl) rather than
DECL_ARGUMENTS (func) when checking for tail recursion.

* gcc.dg/pr84739.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84739.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-tailcall.c

[Bug c/84755] GCC 4.6.0 build error with GCC-4.8.5 in Ubuntu 16.04 LTS

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
gcc 4.6 and 4.8 branches are old and not supported anymore. Besides, trying
4.6.0  (with unidentified patches!) instead of 4.6.N with the largest possible
N is just asking for trouble (the problem may already be fixed in 4.6.N).
Google also has plenty of hits for your error, some may be relevant.

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/77296] [F03] Compiler Error with allocatable string and associate

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Matt Thompson from comment #6)
> (In reply to Thomas Koenig from comment #5)
> > This has been fixed by Paul's patch, closing.
> > 
> > Thanks for the bug report!
> 
> Will this patch appear in GCC 8?

Yes, it has been committed to trunk, so it will be included in the next major
release, which is GCC 8.


> 7.4?

Probably not, since it has not been backported to the 7-branch (which usually
is only done for regressions).


> Is there a way to query which version bugs are fixed in?

That's what the "target milestone" field is for. I just updated that.

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #23 from Andrew Roberts  ---
RPI Zero still looks ok with latest snapshot. 

/usr/local/gcc/bin/gcc -mfpu=auto -O3 -o matrix matrix.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU

/usr/local/gcc/bin/gcc -mcpu=native -mfpu=auto -O3 -o matrix matrix.c
Is ok.

/usr/local/gcc/bin/gcc -march=native -mcpu=native -Q --help=target | grep
"mcpu\|mfpu\|march"
  -march=   armv6zk+fp
  -mcpu=arm1176jzf-s
  -mfpu=vfp

/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/armv6l-unknown-linux-gnueabihf/8.0.1/lto-wrapper
Target: armv6l-unknown-linux-gnueabihf
Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu
--disable-libstdcxx-pch --enable-install-libiberty --disable-multilib
--disable-libssp --enable-default-pie --enable-default-ssp
--host=armv6l-unknown-linux-gnueabihf --build=armv6l-unknown-linux-gnueabihf
--with-arch=armv6 --with-float=hard --with-fpu=vfp --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180304 (experimental) (GCC)

[Bug c++/84596] [8 Regression] internal compiler error: unexpected expression '(bool)c' of kind implicit_conv_expr (cxx_eval_constant_expression)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Priority|P4  |P3
 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---

--- Comment #7 from Alexandre Oliva  ---
Vegard, this PR is already resolved, I suggest filing a new PR for the bug you
detected with the testcase in comment 6, and linking back to this one there,
for reference.

[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961

[aoliva at gcc dot gnu.org]

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

Bug 84596 Summary: [8 Regression] internal compiler error: unexpected 
expression '(bool)c' of kind implicit_conv_expr (cxx_eval_constant_expression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84596

   What|Removed |Added

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

[Bug inline-asm/84677] [6/7/8 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2205

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-03-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|internal compiler error: in |[6/7/8 Regression] internal
   |extract_constrain_insn, at  |compiler error: in
   |recog.c:2205|extract_constrain_insn, at
   ||recog.c:2205
  Known to fail||6.4.0, 7.3.0, 8.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  My bisection also points to r229470 (gcc 6.0.0):

r229470 | law | 2015-10-27 21:05:53 -0400 (Tue, 27 Oct 2015) | 184 lines

[PATCH 7/9] ENABLE_CHECKING refactoring: middle-end, LTO FE
gcc/lto/ChangeLog:
2015-10-27  Mikhail Maltsev  

* lto.c (unify_scc): Use flag_checking and remove ENABLE_CHECKING
conditionals.
(lto_fixup_state): Likewise.
(do_whole_program_analysis): Use
symtab_node::checking_verify_symtab_nodes and remove ENABLE_CHECKING
conditionals.
...

Before that GCC accepted the code so I'm assuming it's ice-on-valid-code.

[Bug inline-asm/84679] [6/7/8 Regression] internal compiler error: in lra_eliminate_reg_if_possible, at lra-eliminations.c:1382

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 CC||msebor at gcc dot gnu.org
  Known to work||4.9.4
Summary|internal compiler error: in |[6/7/8 Regression] internal
   |lra_eliminate_reg_if_possib |compiler error: in
   |le, at  |lra_eliminate_reg_if_possib
   |lra-eliminations.c:1382 |le, at
   ||lra-eliminations.c:1382
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r211475 (gcc 4.10.0):

r211475 | rsandifo | 2014-06-11 12:59:17 -0400 (Wed, 11 Jun 2014) | 34 lines

gcc/
* common.md: New file.
* doc/md.texi: Update description of generic, machine-independent
constraints.
* config/s390/constraints.md (e): Delete.
* Makefile.in (md_file): Include common.md.
* config/m32c/t-m32c (md_file): Likewise.
* genpreds.c (general_mem): New array.
(generic_constraint_letters): Remove constraints now defined by
common.md.
(add_constraint): Map TARGET_MEM_CONSTRAINT to general_mem.
Allow the first character to be '<' or '>' as well.
* genoutput.c (general_mem): New array.
(indep_constraints): Remove constraints now defined by common.md.
(note_constraint): Map TARGET_MEM_CONSTRAINT to general_mem.
Remove special handling of 'm'.
* ira-costs.c (record_reg_classes): Remove special handling of
constraints now defined by common.md.
* ira.c (ira_setup_alts, ira_get_dup_out_num): Likewise.
* ira-lives.c (single_reg_class): Likewise.
(ira_implicitly_set_insn_hard_regs): Likewise.
* lra-constraints.c (reg_class_from_constraints): Likewise.
(process_alt_operands, process_address, curr_insn_transform): Likewise.
* postreload.c (reload_cse_simplify_operands): Likewise.
* reload.c (push_secondary_reload, scratch_reload_class)
(find_reloads, alternative_allows_const_pool_ref): Likewise.
* reload1.c (maybe_fix_stack_asms): Likewise.
* targhooks.c (default_secondary_reload): Likewise.
* stmt.c (parse_output_constraint): Likewise.
* recog.c (preprocess_constraints): Likewise.
(constrain_operands, peep2_find_free_register): Likewise.
(asm_operand_ok): Likewise, but add a comment saying why 'o'
must be handled specially.

[Bug inline-asm/84680] [6/7/8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 CC||msebor at gcc dot gnu.org
  Known to work||4.8.4
Summary|internal compiler error:|[6/7/8 Regression] internal
   |Max. number of generated|compiler error: Max. number
   |reload insns per insn is|of generated reload insns
   |achieved (90)   |per insn is achieved (90)
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.3.0,
   ||8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to:

r201915 (gcc 4.9.0):

r201915 | kyukhin | 2013-08-22 02:06:03 -0400 (Thu, 22 Aug 2013) | 135 lines

* common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX512F_SET): New.
...

Before that, GCC would fail with:

pr84680.C: In function ‘void a()’:
pr84680.C:4:56: error: impossible constraint in ‘asm’
   asm volatile("" : "=vp" (b) : "0" (__builtin_alloca));
^

[Bug c++/84698] ICE when using noexcept(noexcept()) declaration on global friend function of template class

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r209907 (gcc 4.10.0):

r209907 | jason | 2014-04-29 14:04:50 -0400 (Tue, 29 Apr 2014) | 27 lines

DR 1351
Represent the unevaluated exception specification of an implicitly
declared or deleted function with a simple placeholder, not a list
of functions.

Before then GCC errors out with:

pr84698.C: In instantiation of ‘struct X’:
pr84698.C:15:14:   required from here
pr84698.C:7:14: error: declaration of ‘template void
swap(X&, X&) noexcept ()’ has a different
exception specifier
  friend void swap(X& a, X& b) noexcept(noexcept(a.swap(b)));
  ^
pr84698.C:11:13: error: from previous declaration ‘template
void swap(X&, X&) noexcept (noexcept (a.swap(b)))’
 inline void swap(X& a, X& b) noexcept(noexcept(a.swap(b))) {
 ^

[Bug inline-asm/84742] internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I have reproduced it (intermittently) with revisions as recent as r258160, but
only with ASLR enabled.  The valgrind errors for sparseset_bit_p are expected
and go away --with-enable-valgrind-annotations.  I don't see any other errors
in my report and I can't reproduce it without ASLR or under GDB so there isn't
much to go on.

$ /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.258160 -quiet -O3 -fpermissive
-fno-toplevel-reorder -std=c++14 -o/dev/null t.C
during RTL pass: reload
t.C: In function ‘void a()’:
t.C:10:1: internal compiler error: in process_alt_operands, at
lra-constraints.c:2112
 }
 ^
0x1013ddb process_alt_operands
../../gcc/lra-constraints.c:2112
0x10187ca curr_insn_transform
../../gcc/lra-constraints.c:3860
0x101c13f lra_constraints(bool)
../../gcc/lra-constraints.c:4877
0x1004f6f lra(_IO_FILE*)
../../gcc/lra.c:2419
0xfac579 do_reload
../../gcc/ira.c:5465
0xfaca6c execute
../../gcc/ira.c:5649

[Bug other/44035] internals documentation cannot be fixed without new GFDL license grants

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44032

--- Comment #4 from Eric Gallager  ---
Does this really need to have "blocker" importance? It has gone several years
without actually blocking any releases.

[Bug driver/84749] -w does not work with option property Warn

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I recently noticed this too.  For instance, here -w suppresses -Wreturn-type
but doesn't suppress the warning about -Wmudflap being no longer supported:

$ grep -B1 "Warn(" /src/gcc/svn/gcc/c-family/c.opt | head -n2
Wmudflap
C ObjC C++ ObjC++ Ignore Warn(switch %qs is no longer supported)

$ echo "f() { }" | gcc -S -Wall -Wextra -Wmudflap -Wreturn-type -w -xc -
xgcc: warning: switch ‘-Wmudflap’ is no longer supported

[Bug bootstrap/21547] GMP/MPFR shared libraries not in LD_LIBRARY_PATH: failure to build libgfortran

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44425

--- Comment #10 from Eric Gallager  ---
Possibly related to bug 44425

[Bug middle-end/26061] error and warning count

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||egallager at gcc dot gnu.org

--- Comment #21 from Eric Gallager  ---
(In reply to Kevin André from comment #20)
> (In reply to comment #19)
> 
> > I really don't want to make it default off as it's really useful. I hope to 
> > fix
> > the patch and make it default on for gcc 4.4 at least.
> 
> I agree. What's the status for getting it into 4.4?
> 
> People complain that changing GCC's output will break tools that parse that
> output. I can understand why they're complaining, but IMHO this reveals a
> more fundamental problem. The current diagnostic output tries to serve two
> purposes: being readable for humans and being parseable by tools. And I
> think those two should be separated. Why not have the default output be
> human-friendly, and introduce a separate option, say
> "-fparseable-diagnostics" to switch to an easily parseable output format?

clang has had an error and warning count for a really long time now and tools
work with it. gcc 7 added -fdiagnostics-parseable-fixits but fixits are only
part of diagnostics.

[Bug libgomp/35614] libgomp info documentation file is in the wrong category

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation, easyhack,
   ||patch
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Sahak Petrosyan from comment #3)
> I posted the patch to the mailing list:
> http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01639.html

Adding "patch" keyword (among others)

[Bug target/20802] mmix-knuth-mmixware testsuite failure: gcc.dg/builtin-apply4.c execution

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
  Known to work||4.1.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=20076
  Known to fail||3.4.0, 4.2.0, 4.3.0

--- Comment #8 from Eric Gallager  ---
(In reply to Rob from comment #7)
> I tried this on i686-pc-linux-gnu using gcc-3.4 (from Debian), gcc-4.1 (from
> Debian), gcc version 4.2.0 20070501 (prerelease) (from SVN), and gcc version
> 4.3.0 20070607 (experimental) (from SVN):
> 
> I modified as follows:
> 
> /* PR tree-optimization/20076 */
> /* { dg-options "-O2" } */
> /* { dg-do run } */
> 
> extern void abort (void);
> 
> double
> foo (int arg)
> {
> printf("foo1  - arg = %u \n", arg);
>   if (arg != 116)
> abort();
> printf("foo2  - arg = %u \n", arg);
>   return arg + 1;
> }
> 
> inline double
> bar (int arg)
> {
> printf("bar1  - arg = %u \n", arg);
>   foo (arg);
> printf("bar2  - arg = %u \n", arg);
>   __builtin_return (__builtin_apply ((void (*) ()) foo, __builtin_apply_args
> (), 128));
>   __builtin_return (__builtin_apply ((void (*) ()) foo, __builtin_apply_args
> (), 32));
>   __builtin_return (__builtin_apply ((void (*) ()) foo, __builtin_apply_args
> (), 16));
> printf("bar3  - arg = %u \n", arg);
> }
> 
> int
> main (int argc, char **argv)
> {
> printf("main1 - pre   bar\n");
>   if (bar (116) != 117.0) {
> printf("main2 - post  bar - abort\n");
> abort ();
>   }
> printf("main2 - post  bar - no abort\n");
>   return 0;
> }
> 
> 
> The printf statments are the only changes, everything else is the same as
> 4.3.0.
> 
> Here is what the .exe's print for each version of gcc:
> 
> # ./builtin-apply4_gcc3.4.exe
> main1 - pre   bar
> bar1  - arg = 116 
> foo1  - arg = 116 
> foo2  - arg = 116 
> bar2  - arg = 116 
> foo1  - arg = 1 
> Aborted
> 
> # ./builtin-apply4_gcc4.1.exe
> main1 - pre   bar
> bar1  - arg = 116 
> foo1  - arg = 116 
> foo2  - arg = 116 
> bar2  - arg = 116 
> foo1  - arg = 116 
> foo2  - arg = 116 
> main2 - post  bar - no abort
> 
> # ./builtin-apply4_gcc4.2.exe
> main1 - pre   bar
> bar1  - arg = 116 
> foo1  - arg = 116 
> foo2  - arg = 116 
> bar2  - arg = 116 
> foo1  - arg = 116 
> foo2  - arg = 116 
> main2 - post  bar - abort
> Aborted
> 
> # ./builtin-apply4_4.3.exe
> main1 - pre   bar
> bar1  - arg = 116 
> foo1  - arg = 116 
> foo2  - arg = 116 
> bar2  - arg = 116 
> foo1  - arg = 116 
> foo2  - arg = 116 
> main2 - post  bar - abort
> Aborted
> 
> 
> GCC 3.4 prints "foo1  - arg = 1" - which is way off.
> 
> GCC 4.1 prints "main2 - post  bar - no abort" - which means it is OK
> 
> The others are incorrect. I do not have 4.0.0 to confirm this report but you
> might says it was fixed in 4.1 - only to re-occur in later versions :( .
> 
> I'd change the known to fail field but I don't have permission.

I changed it for you.

[Bug target/35365] dlopen fails because of missing _Jv_RegisterClasses under HP-UX 11.11

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Eric Gallager  ---
_Jv_RegisterClasses is a Java thing, and Java has been removed from newer
versions of GCC, so I'm going to close this.

[Bug target/28508] Assembler Error: operand out of range (145 not between -128 and 127) form m32r-target

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #9 from Eric Gallager  ---
(In reply to Debian GCC Maintainers from comment #8)
> please mark it as closed, if it is not a candidate for a backport.
> 
>   Matthias

OK.

[Bug middle-end/34516] trivial sentinels

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> And why don't you submit it

I'm assuming it has something to do with this bug being filed around the time
of the GPL3 transition...

[Bug target/34452] Multiply-by-constant pessimation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=30354,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=28417

--- Comment #5 from Eric Gallager  ---
(In reply to Bernhard Reutner-Fischer from comment #4)
> Is this realted to PR30354 and/or PR28417 ?

Possibly, let's find out by putting them under "See Also" and seeing if anyone
confirms.

[Bug c/84755] GCC 4.6.0 build error with GCC-4.8.5 in Ubuntu 16.04 LTS

[lux1075 at naver dot com]

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

--- Comment #1 from June,Lim  ---
Created attachment 43591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43591=edit
make all-gcc log

[Bug c/84755] GCC 4.6.0 build error with GCC-4.8.5 in Ubuntu 16.04 LTS

[lux1075 at naver dot com]

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

--- Comment #2 from June,Lim  ---
Created attachment 43592
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43592=edit
GCC-4.6.0 configure log

[Bug c/84755] New: GCC 4.6.0 build error with GCC-4.8.5 in Ubuntu 16.04 LTS

[lux1075 at naver dot com]

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

Bug ID: 84755
   Summary: GCC 4.6.0 build error with GCC-4.8.5 in Ubuntu 16.04
LTS
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lux1075 at naver dot com
  Target Milestone: ---

Created attachment 43590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43590=edit
make all-target-libgcc error log

Hello, gcc

I have an compile error when building GCC 4.6.0


My host env is Ubuntu 16.04 64bit LTS (kernel was installed 4.13.0-36-generic)
and
gcc-4.8.5
=
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.5-4ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.5 (Ubuntu 4.8.5-4ubuntu2)
=


I downloaded, compiled and installed : M4(1.4.18), GMP(5.0.3), MPFR(3.0.1),
MPC(0.9), PPL(0.11.2), CLoog-PPL(0.15.11), BinUtils(2.21.1a)


Before GCC-4.6.0 Configuring, I patched 3 files : (attached file)
 - gcc-4.6.0-branch_update-1.patch
 - gcc-4.6.0-pure64_specs-1.patch
 - gcc-4.6.0-jslim.patch


I GCC-4.6.0 configured like this:
AR=ar LDFLAGS="-Wl,-rpath,/home/jslim/toolchain/cross-tools/lib"
../gcc-4.6.0/configure --prefix=/home/jslim/toolchain/cross-tools
--build=x86_64-cross-linux-gnu --host=x86_64-cross-linux-gnu
--target=x86_64-unknown-linux-gnu --with-sysroot=/home/jslim/toolchain
--with-local-prefix=/home/jslim/toolchain/tools --disable-nls --disable-shared
--with-mpfr=/home/jslim/toolchain/cross-tools
--with-gmp=/home/jslim/toolchain/cross-tools
--with-ppl=/home/jslim/toolchain/cross-tools
--with-cloog=/home/jslim/toolchain/cross-tools --without-headers --with-newlib
--disable-decimal-float --disable-libgomp --disable-libmudflap --disable-libssp
--disable-threads --enable-languages=c --disable-multilib

* I attached "config.log" file


GCC-4.6.0 Configuring done, and I followed make steps like this:
make all-gcc// This step seemed fine. (attached
"compile_all-gcc.log" file)
make all-target-libgcc  // This step failed. I attached
"compile_all-target-libgcc.log" file


Please help me.

I hope let me know what was fault and how to do.

Thanks.

PS. this bug reporting can attachment only one file. So, I attached
"compile_all-target-libgcc.log" file only. If you want more files(config.log,
patch files ...), plz request for me.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[juergen.reuter at desy dot de]

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

--- Comment #16 from Jürgen Reuter  ---
In addition to what Tobias remarked, NAG now gives a clear error message:

NAG Fortran Compiler Release 6.1(Tozai) Build 6138
Error: data.f90, line 13: Object TRLKOLD of type ACTIVE is default-initialised,
therefore subobject TRLKOLD%V is not permitted in a DATA statement

Intel in v18.0.1 still does not give a compilation or runtime error.

[Bug c/60256] No -Wuninitialized warning for strcpy copying to self

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83456

--- Comment #11 from Martin Sebor  ---
I should mention that even the -Wrestrict warning runs into problems this early
-- see bug 83456.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #15 from Jürgen Reuter  ---
I just stumbled over this again while reading c.l.f. This still is ICEing with
8.0.1. If it is inconsistent code as the c.l.f. discussion and the J3 answer to
the interpretation request point out, this should be caught with an exception.

[Bug c/60256] No -Wuninitialized warning for strcpy copying to self

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|7.0 |7.3.0, 8.0

--- Comment #10 from Martin Sebor  ---
GCC 8 issues a -Wrestrict warning for the test case in comment #0 but still no
-Wuninitialized.  I agree that issuing -Wuninitialized will be difficult
because (as noted in comment #5) the call is folded too early to tell whether
the argument is valid (either initialized or assigned to) prior to the call. 
The only way I can think of is to delay the folding until it is known and that
has not been a popular idea in the past.

$ cat pr60256.c && gcc -O2 -S -Wall pr60256.c
#include 
void f(void) {
  char* s;
  strcpy(s, s);
}
pr60256.c: In function ‘f’:
pr60256.c:4:3: warning: ‘strcpy’ source argument is the same as destination
[-Wrestrict]
   strcpy(s, s);
   ^~~~

[Bug c/81269] wrong color highlighting in -Wrestrict warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
The -Wrestrict patch for sprintf wasn't approved for GCC 8 so this is not
really an issue at the moment.  Resolving as invalid based on comment #2.

[Bug tree-optimization/83519] missing -Wrestrict on an overlapping strcpy to a non-member array

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Author: msebor
Date: Thu Mar  8 00:56:07 2018
New Revision: 258348

URL: https://gcc.gnu.org/viewcvs?rev=258348=gcc=rev
Log:
PR tree-optimization/83519 - missing -Wrestrict on an overlapping strcpy to a
non-member array

gcc/testsuite/ChangeLog:

* gcc.dg/Wrestrict-13.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Wrestrict-13.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83519] missing -Wrestrict on an overlapping strcpy to a non-member array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
This was fixed by r256180:

r256180 | prathamesh3492 | 2018-01-03 11:07:32 -0500 (Wed, 03 Jan 2018) | 9
lines

2018-01-03  Prathamesh Kulkarni  

PR tree-optimization/83501
* tree-ssa-strlen.c (get_string_cst): New.
(handle_char_store): Call get_string_cst.

[Bug tree-optimization/84754] New: missing -Wrestrict on a possible strcpy overlap with constant offset

[msebor at gcc dot gnu.org]

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

Bug ID: 84754
   Summary: missing -Wrestrict on a possible strcpy overlap with
constant offset
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

-Wrestrict triggers for a strcpy call from a string of unknown length and
unknown offset but not the same call with a constant offset, even though the
latter seems more likely to overlap than the former (the smaller the offset the
more likely the cooy is to overlap).  In any case, unlike for memcpy, for
string functions -Wrestrict is specifically meant to warn even for possible
overlaps (i.e., when copying into the same array) so this is a bug, not just a
missing feature or design choice.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-wrestrict=/dev/stdout z.c
char a[32];

void f (int i)
{
  __builtin_strcpy (a, a + i);   // -Wrestrict (good)
}

void g (void)
{
  __builtin_strcpy (a, a + 1);   // missing -Wrestrict
}


;; Function f (f, funcdef_no=0, decl_uid=1959, cgraph_uid=0, symbol_order=1)

z.c: In function ‘f’:
z.c:5:3: warning: ‘__builtin_strcpy’ accessing 1 byte at offsets 0 and [0, 32]
may overlap 1 byte at offset 0 [-Wrestrict]
   __builtin_strcpy (a, a + i);   // -Wrestrict (good)
   ^~~
f (int i)
{
  sizetype _1;
  const char * _2;

   [local count: 1073741825]:
  _1 = (sizetype) i_3(D);
  _2 =  + _1;
  __builtin_strcpy (, _2);
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1962, cgraph_uid=1, symbol_order=2)

g ()
{
   [local count: 1073741825]:
  __builtin_strcpy (, [(void *) + 1B]);
  return;

}

[Bug fortran/70409] Silent truncation of character parameters with len=huge()

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Mar  8 00:42:41 2018
New Revision: 258347

URL: https://gcc.gnu.org/viewcvs?rev=258347=gcc=rev
Log:
2018-03-07  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

2018-03-07  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* gfortran.dg/pr64124.f90: New tests.
* gfortran.dg/pr70409.f90: New tests.

Added:
trunk/gcc/testsuite/gfortran.dg/pr64124.f90
trunk/gcc/testsuite/gfortran.dg/pr70409.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/64124] [F95] Valid constant expr rejected

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Mar  8 00:42:41 2018
New Revision: 258347

URL: https://gcc.gnu.org/viewcvs?rev=258347=gcc=rev
Log:
2018-03-07  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

2018-03-07  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* gfortran.dg/pr64124.f90: New tests.
* gfortran.dg/pr70409.f90: New tests.

Added:
trunk/gcc/testsuite/gfortran.dg/pr64124.f90
trunk/gcc/testsuite/gfortran.dg/pr70409.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
s/this loop/this function

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #4 from Bill Schmidt  ---
OK, I see.  We optimize swapped vperm in most cases as part of a general
swap-optimization algorithm.  However, this algorithm is defeated when there is
a mix of loads/stores accompanied by swaps and loads/stores that are not
accompanied by swaps.  The "big-endian" loads that are used with vshasigmaw and
friends are the problem here.  (This problem goes away with Power9, but doesn't
help you here.)

There is a slight possibility we can address this in GCC 8, but it is unlikely,
as the code base is closed except for regression fixes.  In any case, a
solution would still keep some swap instructions in place, and thus would not
be ideal.  (I.e., we can fold a swap and a vperm when the result of the swap is
not used elsewhere, but other swaps associated with loads and stores will still
be present.)  So I don't think we should go this route.

The best performance will be achieved by writing this loop entirely using
inline asm code, with all data loaded/stored using lxvd2x and stxvd2x (no
swaps), thus in "big-endian element order" (element 0 in the high-order
position of the register).  Because of the big-endian nature of vshasigmaw,
this is always going to be the best approach.

I am still poking the bushes for a reference implementation; I thought of
another person to ask while writing this note.  Will let you know what I find
out.

[Bug target/83712] [6/7/8 Regression] "Unable to find a register to spill" when compiling for thumb1

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
I've decided to fix it in RA because it could help to fix analogous bugs when
existing hard reg splitting code fails. This particular bug is more complicated
because it happens for non-small reg class.  It requires a lot of changes in
LRA and changing its sub-pass flow.

I've been working on this PR for some time and now I can say that it will
probably fixed on this week.

[Bug tree-optimization/83456] -Wrestrict false positive on a non-overlapping memcpy in an inline function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00358.html

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[noloader at gmail dot com]

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

--- Comment #3 from Jeffrey Walton  ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to Bill Schmidt from comment #1)
> > GCC 4.8.5 is out of service.  This is fixed in all in-service versions of
> > GCC (6.4 and later).
> 
> Interesting. I'm seeing it in GCC 7.2.0. Are you certain of this?

Here's an example to make sure we are on the same page.

$ /opt/cfarm/gcc-latest/bin/g++ --version
g++ (GCC) 7.2.0

$ /opt/cfarm/gcc-latest/bin/g++ -g3 -O3 -Wall -DTEST_MAIN -mcpu=power8
sha256-p8.cxx -o sha256-p8.exe

$ objdump --disassemble sha256-p8.exe | c++filt

1880 :
1880:   03 10 40 3c lis r2,4099
1884:   00 81 42 38 addir2,r2,-32512
1888:   f0 ff c1 fb std r30,-16(r1)
188c:   f8 ff e1 fb std r31,-8(r1)
1890:   fe ff 22 3d addis   r9,r2,-2
1894:   10 00 c4 3b addir30,r4,16
1898:   70 8e 29 39 addir9,r9,-29072
189c:   10 00 e3 3b addir31,r3,16
18a0:   20 00 84 39 addir12,r4,32
18a4:   20 00 63 39 addir11,r3,32
18a8:   99 4e 00 7c lxvd2x  vs32,0,r9
18ac:   30 00 a3 38 addir5,r3,48
18b0:   40 00 23 39 addir9,r3,64
18b4:   c4 ff c0 38 li  r6,-60
18b8:   c0 ff e0 38 li  r7,-64
18bc:   99 26 20 7c lxvd2x  vs33,0,r4
18c0:   30 00 84 38 addir4,r4,48
18c4:   f8 ff 00 39 li  r8,-8
18c8:   e4 ff 40 39 li  r10,-28
18cc:   57 02 00 f0 xxswapd vs32,vs32
18d0:   57 0a 21 f0 xxswapd vs33,vs33
18d4:   97 05 00 f0 xxlnand vs32,vs32,vs32
18d8:   2b 08 21 10 vperm   v1,v1,v1,v0
18dc:   57 0a 21 f0 xxswapd vs33,vs33
18e0:   99 1f 20 7c stxvd2x vs33,0,r3
18e4:   18 00 60 38 li  r3,24
18e8:   a6 03 69 7c mtctr   r3
18ec:   99 f6 20 7c lxvd2x  vs33,0,r30
18f0:   57 0a 21 f0 xxswapd vs33,vs33
18f4:   2b 08 21 10 vperm   v1,v1,v1,v0
18f8:   57 0a 21 f0 xxswapd vs33,vs33
18fc:   99 ff 20 7c stxvd2x vs33,0,r31
1900:   99 66 20 7c lxvd2x  vs33,0,r12
1904:   57 0a 21 f0 xxswapd vs33,vs33
1908:   2b 08 21 10 vperm   v1,v1,v1,v0
190c:   57 0a 21 f0 xxswapd vs33,vs33
1910:   99 5f 20 7c stxvd2x vs33,0,r11
1914:   99 26 20 7c lxvd2x  vs33,0,r4
1918:   57 0a 21 f0 xxswapd vs33,vs33
191c:   2b 08 01 10 vperm   v0,v1,v1,v0
1920:   57 02 00 f0 xxswapd vs32,vs32
1924:   99 2f 00 7c stxvd2x vs32,0,r5
1928:   00 00 00 60 nop
192c:   00 00 42 60 ori r2,r2,0
1930:   99 36 09 7c lxvd2x  vs32,r9,r6
1934:   99 3e 89 7d lxvd2x  vs44,r9,r7
1938:   99 56 a9 7d lxvd2x  vs45,r9,r10
193c:   99 46 29 7c lxvd2x  vs33,r9,r8
1940:   82 06 00 10 vshasigmaw v0,v0,0,0
1944:   82 7e 21 10 vshasigmaw v1,v1,0,15
1948:   80 60 00 10 vadduwm v0,v0,v12
194c:   80 68 00 10 vadduwm v0,v0,v13
1950:   80 08 00 10 vadduwm v0,v0,v1
1954:   99 4f 00 7c stxvd2x vs32,0,r9
1958:   08 00 29 39 addir9,r9,8
195c:   d4 ff 00 42 bdnz1930 
1960:   f0 ff c1 eb ld  r30,-16(r1)
1964:   f8 ff e1 eb ld  r31,-8(r1)
1968:   20 00 80 4e blr
196c:   00 00 00 00 .long 0x0
1970:   00 09 00 00 .long 0x900
1974:   00 02 00 00 attn
1978:   00 00 00 60 nop
197c:   00 00 42 60 ori r2,r2,0

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  ---
(In reply to Bill Schmidt from comment #1)
> GCC 4.8.5 is out of service.  This is fixed in all in-service versions of
> GCC (6.4 and later).

Interesting. I'm seeing it in GCC 7.2.0. Are you certain of this?

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||wschmidt at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Bill Schmidt  ---
GCC 4.8.5 is out of service.  This is fixed in all in-service versions of GCC
(6.4 and later).

[Bug rtl-optimization/84753] New: GCC does not fold xxswapd followed by vperm

[noloader at gmail dot com]

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

Bug ID: 84753
   Summary: GCC does not fold xxswapd followed by vperm
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

I'm working on GCC112 from the compile farm. It is ppc64-le machine. It has
both GCC 4.8.5 and GCC 7.2.0 installed. The issue is present on both.

We are trying to recover missing 1 to 2 cpb performance when using Power8 SHA
built-ins. Part of the code to load a message into the message schedule looks
like so:

   uint8_t msg[64] = {...};
   __vector unsigned char mask = {3,2,1,0, 7,6,5,4, 11,10,9,8, 15,14,13,12};

   __vector unsigned int t = vec_vsx_ld(0, msg);
   t = vec_perm(t, t, mask);

When I compile at -O3 and disassemble it, I see:

18bc:   99 26 20 7c lxvd2x  vs33,0,r4
...
18d0:   57 0a 21 f0 xxswapd vs33,vs33
18d8:   2b 08 21 10 vperm   v1,v1,v1,v0

Calling xxswapd followed by vperm seems to be a lot like calling shuffle_epi32
followed by shuffle_epi8 on an x86 machine. It feels like the two permutes
should be folded into one.

On x86 I would manually fold the two shuffles. On PPC I cannot because xxswapd
is generated as part of the load, and then I call vperm. I have not figured out
how to avoid the xxswapd. (I even tried to issue my own xxswapd to cancel out
the one being generated by the compiler).

**

Here's a minimal case, but the optimizer is removing the code of interest. The
real code suffers it, and it can be found at
https://github.com/noloader/SHA-Intrinsics/blob/master/sha256-p8.cxx .

$ cat test.cxx
#include 
#if defined(__ALTIVEC__)
# include 
# undef vector
# undef pixel
# undef bool
#endif

typedef __vector unsigned char uint8x16_p8;
typedef __vector unsigned int  uint32x4_p8;

// Unaligned load
template  static inline
uint32x4_p8 VectorLoad32x4u(const T* data, int offset)
{
  return vec_vsx_ld(offset, (uint32_t*)data);
}

// Unaligned store
template  static inline
void VectorStore32x4u(const uint32x4_p8 val, T* data, int offset)
{
  vec_vsx_st(val, offset, (uint32_t*)data);
}

static inline
uint32x4_p8 VectorPermute32x4(const uint32x4_p8 val, const uint8x16_p8 mask)
{
  return (uint32x4_p8)vec_perm(val, val, mask);
}

int main(int argc, char* argv[])
{
  uint8_t M[64];
  uint32_t W[64];

  uint8_t* m = M;
  uint32_t* w = W;

  const uint8x16_p8 mask = {3,2,1,0, 7,6,5,4, 11,10,9,8, 15,14,13,12};
  for (unsigned int i=0; i<16; i+=4, m+=4, w+=4)
VectorStore32x4u(VectorPermute32x4(VectorLoad32x4u(m, 0), mask), w, 0);

  return 0;
}

[Bug target/82411] const is not always read-only

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Segher Boessenkool  ---
Done on trunk; backports pending.

[Bug target/82411] const is not always read-only

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Wed Mar  7 20:27:11 2018
New Revision: 258340

URL: https://gcc.gnu.org/viewcvs?rev=258340=gcc=rev
Log:
rs6000: -mreadonly-in-sdata (PR82411)

This adds a new option -mreadonly-in-sdata (on by default) that
controls whether readonly data can be put in sdata.  (For EABI this
does nothing, readonly data is put in sdata2 as usual).


PR target/82411
* config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Don't put
readonly data in sdata, if that is disabled.
* config/rs6000/sysv4.opt (mreadonly-in-sdata): New option.
* doc/invoke.texi (RS/6000 and PowerPC Options): Document
-mreadonly-in-sdata option.

gcc/testsuite/
PR target/82411
* gcc.target/powerpc/ppc-sdata-2.c: Skip if -mno-readonly-in-sdata.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/sysv4.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/ppc-sdata-2.c

[Bug c++/84744] cannot use glibc 2.27 with gcc 7.3

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #9 from Jim Wilson  ---
Building and using glibc is complicated.  It is best to refer to a FAQ if you
haven't done this before.  You can find some info on the glibc wiki about this
here:
   https://sourceware.org/glibc/wiki/Testing/Builds
You probably want item 5.

It is a little simpler if you build a gcc that is set up to use your glibc
build, which requires building a complete toolchain from scratch.  If you want
to learn how to do this, it is best to look at someone else's scripts showing
how to do it.  Every linux distro has scripts for this.  I like to use
crosstools-ng.  You can find some info on how to build a toolchain here:
 https://crosstool-ng.github.io/docs/toolchain-construction/
and look at the scripts if you want the details of how this works.

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen  ---
(In reply to Martin Liška from comment #1)
> Isn't that dup of 84149? Can you please tweak --param ipa-cp-eval-threshold
> to value to 200, 300, 400? Can you please attach -fdump-ipa-cp-details file?

I tried the param with the 3 different values and none made any difference to
execution time.

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen  ---
Created attachment 43589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43589=edit
ipa-cp dump

[Bug c++/59704] Wrong overload chosen, compiler errornously thinks non-constant zero expression is implicitly castable to null pointer

[arthur.j.odwyer at gmail dot com]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #2 from Arthur O'Dwyer  ---
Here is another example:
https://wandbox.org/permlink/UYsLyMaLcBb6sjJa

GCC incorrectly considers `int()` to be a null pointer constant.
Notice that GCC correctly handles `int{}` with curly braces; it gets confused
only about `int()` with parens.

#include 

void foo(const char *) {}

template decltype(foo(T())) red(T) { puts("yes"); }
void red(...) { puts("no"); }

int main() {
foo(int());  // should not compile
red(1);  // should print "no", not "yes"
}

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #18 from Martin Sebor  ---
Fixed with r258339 on trunk.  For GCC 9 I'll look into something more
sophisticated.

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor  ---
Author: msebor
Date: Wed Mar  7 19:30:31 2018
New Revision: 258339

URL: https://gcc.gnu.org/viewcvs?rev=258339=gcc=rev
Log:
PR tree-optimization/84468 - bogus -Wstringop-truncation despite assignment
after conditional strncpy

gcc/ChangeLog:

PR tree-optimization/84468
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Consider successor
basic block when looking for nul assignment.

gcc/testsuite/ChangeLog:

PR tree-optimization/84468
* g++.dg/warn/Wstringop-truncation-2.C: New test.
* gcc.dg/Wstringop-truncation.c: New test.
* gcc.dg/Wstringop-truncation-2.c: New test.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wstringop-truncation-2.C
trunk/gcc/testsuite/gcc.dg/Wstringop-truncation-2.c
trunk/gcc/testsuite/gcc.dg/Wstringop-truncation.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wstringop-truncation-1.C
trunk/gcc/tree-ssa-strlen.c

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Created attachment 43588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43588=edit
Prototype patch

I have to leave the office now but this is the (only very very lightly tested)
prototype patch that fixes the regression as described above.  It still needs a
bit of care before submitting, however.

[Bug c++/84752] [8 Regression] ICE with constexpr array referenced in lambda

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-07
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r253266.

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Martin Jambor  ---
In my (more recent) checkout of trunk, the estimated benefit is even
lower, only 270.  Raising devirtualization hint to compensate seems
excessive, I need:

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index ee41a8d55b7..09ba92ef14d 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -2612,6 +2612,25 @@ devirtualization_time_bonus (struct cgraph_node *node,
res += 7 / ((int)speculative + 1);
 }

+  if (res)
+/*  Devirtualization is likely more important in recursive callers because
+   those cannot be entirely inlined themselves.  */
+for (cgraph_edge *e = node->callees; e; e = e->next_callee)
+  {
+   enum availability avail;
+   cgraph_node *callee = e->callee->function_symbol ();
+   if (e->caller == callee
+   && avail >= AVAIL_AVAILABLE)
+ {
+   res = 8 * res;
+
+   if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, "Recursive devirtualization bohus %i\n",
+  res);
+   break;
+ }
+  }
+
   return res;
 }

Which is excessive (but it may make sense to boost IPA-CP bonuses for
self-recursive functions a bit since those cannot be dealt with
completely by inlining).  Nevertless I already have a prototype patch which
can explain to IPA-CP that only there is only one remaining value in the
contexts for which we did not clone and replace it there too.

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug c++/84752] New: [8 Regression] ICE with constexpr array referenced in lambda

[reichelt at gcc dot gnu.org]

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

Bug ID: 84752
   Summary: [8 Regression] ICE with constexpr array referenced in
lambda
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-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 valid code snippet triggers an ICE on trunk:

===
void foo()
{
  constexpr int x[1] = {};
  []{ return (bool)x; };
}
===

bug.cc: In lambda function:
bug.cc:4:22: internal compiler error: in build_address, at cp/typeck.c:5744
   []{ return (bool)x; };
  ^
0x66a78b build_address(tree_node*)
../../gcc/gcc/tree.h:3332
0x9dcaca cp_build_addr_expr_1
../../gcc/gcc/cp/typeck.c:5974
0x9ddede cp_build_addr_expr(tree_node*, int)
../../gcc/gcc/cp/typeck.c:6020
0x9ddede decay_conversion(tree_node*, int, bool)
../../gcc/gcc/cp/typeck.c:2082
0x8236df convert_like_real
../../gcc/gcc/cp/call.c:7087
0x823045 convert_like_real
../../gcc/gcc/cp/call.c:6912
0x82cbe2 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../../gcc/gcc/cp/call.c:10665
0x9e3b36 build_static_cast_1
../../gcc/gcc/cp/typeck.c:7035
0x9e7dc7 cp_build_c_cast(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:7796
0x9e807a build_c_cast(unsigned int, tree_node*, cp_expr)
../../gcc/gcc/cp/typeck.c:7704
0x915d21 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9079
0x91628a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9191
0x917ac4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9486
0x9181d8 cp_parser_expression
../../gcc/gcc/cp/parser.c:9655
0x920a26 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12415
0x920a26 cp_parser_statement
../../gcc/gcc/cp/parser.c:10829
0x9217f0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11274
0x9222c7 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:10685
0x9222c7 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10186
0x9222c7 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5261
Please submit a full bug report, [etc.]

The regression was introduced between 2017-09-26 and 2017-10-07.

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

[tkoenig at gcc dot gnu.org]

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

--- Comment #17 from Thomas Koenig  ---
Here's a problem with maxval:

$ cat maxval_parameter_2.f90
! { dg-do run }
program main
  integer, dimension(0,3), parameter :: i = 0
  integer, dimension(0,3) :: j = 0
  print *,maxval(i,dim=1)
  print *,maxval(j,dim=1)
end program main
$ gfortran maxval_parameter_2.f90
$ ./a.out
 -2147483648
 -2147483648 -2147483648 -2147483648

The run-time result is correct, the simplified version isn't.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[sudi at gcc dot gnu.org]

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

--- Comment #17 from sudi at gcc dot gnu.org ---
I looked up what other targets were doing and one thing found to be interesting
was that a lot of them are defining the target hook
TARGET_BUILTIN_SETJMP_FRAME_VALUE. In AArch64 case I am suggesting to define it
to return the hard frame pointer. That seems to solve the issue with both the
attached test case and the test that Wilco mentioned.

Does this look like it solves "mid-end versus back-end : who fixes this issue"
problem?

I am still pretty new to knowing how the stack should actually look. So calling
for some help!

Sudi

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #16 from Thomas Koenig  ---
I'll take a look at what's left (maxval for strings, at least)
and fix what is necessary to fix.

[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #15 from kargl at gcc dot gnu.org ---
(In reply to Matt Thompson from comment #14)
> Query: What version of GCC will fix this? It was reported fixed last year,
> but GCC 7.3.0 still ICEs out.

If you follow the links, you find

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640#c35

that is a fairly large intrusive patch.  I suspect that
Paul did not backport to the 7-branch because of this.
So, the fix will be in 8.0 (or 8.1 can't remember what
the releasing scheme is).

[Bug target/84209] [avr] Don't split SP in split2

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #4 from Georg-Johann Lay  ---
Fixed in v7.4+

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-07
 CC||dmalcolm at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
Summary|internal compiler error:|[8 Regression] internal
   |Segmentation fault  |compiler error:
   |(check_local_shadow())  |Segmentation fault
   ||(check_local_shadow())
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed with trunk.  gcc 7 and 6 show the output quoted above for 5.5.0,
with:

"confused by earlier errors, bailing out"

The trunk ICE is here:

Program received signal SIGSEGV, Segmentation fault.
check_local_shadow (decl=decl@entry=0x719d5b48) at
../../src/gcc/cp/name-lookup.c:2682
2682if (scope->kind == sk_class
(gdb) p scope
$1 = (cp_binding_level *) 0x0

The segfault started somewhere between r248121 (unaffected) and r248123
(affected), probably r248123, so CCing Nathan.

Prior to that, the:

  "confused by earlier errors, bailing out"

comes from this assertion failing in pop_local_binding:

405   gcc_assert (binding->type == decl);

masked in release builds by the "confused by earlier errors, bailing out"
post-error-ICE-handler.  This failure started somewhere between r180695
(unaffected) and r180713 (affected).

[Bug c++/84745] internal compiler error: Segmentation fault (main_block_label())

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-07
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed with trunk, gcc7 and gcc 6, and all the way back to at least 4.8.3
(using -std=c++11).

Program received signal SIGSEGV, Segmentation fault.
main_block_label (label=label@entry=0x718d5100) at
../../src/gcc/tree-cfg.c:1496
1496  tree main_label = label_for_bb[bb->index].label;

(gdb) p bb
$1 = 

[Bug middle-end/84747] alias analysis reports may-conflict for references to disjoint address spaces

[stefan at reservoir dot com]

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

--- Comment #3 from Stefan M Freudenberger  ---
In this case I would have expected that TARGET_ADDR_SPACE_SUBSET_P will return
TRUE, as appropriate.

Granted, it would render my example invalid for x86.

[Bug middle-end/84747] alias analysis reports may-conflict for references to disjoint address spaces

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
On some targets where the address spaces are really separate, one kind of
memory and another kind of memory, I can see why assuming non-aliasing is fine.
But exactly on x86_64 I don't see how that could be safe, %fs/%gs simply are
the given addresses plus the segment base.  You can access the same memory both
with
%gs:ptr1 and ptr2 where ptr2 is ptr1 + gs_segment_base, e.g. glibc uses for TLS
heavily both kinds of accesses.

[Bug target/84751] New: ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

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

Bug ID: 84751
   Summary: ICE  with debug build of gcc  GIMPLE pass:
store-merging or IPA pass: cp
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

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

This was noticed during investigation into pr82982 on powerpc64-*-linux-gnu* ,
but believed to be a separate issue.

With a 'debug' build of gcc, where $CPU_COUNT is any value, and the assorted
CFLAGS values are set like in the following. 

make -j $CPU_COUNT CFLAGS="-O0 -g3 -fno-inline" CXXFLAGS="-O0 -g3 -fno-inline"
CFLAGS_FOR_BUILD="-O0 -g3 -fno-inline" CFLAGS_FOR_TARGET="-O0 -g3 -fno-inline"
CXXFLAGS_FOR_BUILD="-O0 -g3 -fno-inline" CXXFLAGS_FOR_TARGET="-O0 -g3
-fno-inline" 

the resulting gcc will ICE when building the testcase with -O2 or higher. 

# driver with -O2
~/gcc/generic.noprereqs.noconfig.debug> ./gcc/cc1 ../pr82982.c  -O2
 km
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   

  
 Assembling functions:
  kmduring GIMPLE pass: store-merging

../pr82982.c: In function ‘km’:
../pr82982.c:4:1: internal compiler error: Segmentation fault
 km (void)
 ^~
0x10f2da87 crash_signal
/home/willschm/gcc/trunk.svn/gcc/toplev.c:325
0x11f76638 trim_filename(char const*)
/home/willschm/gcc/trunk.svn/gcc/diagnostic.c:1023
0x11f78517 fancy_abort(char const*, int, char const*)
/home/willschm/gcc/trunk.svn/gcc/diagnostic.c:1509
0x114b56df inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
/home/willschm/gcc/trunk.svn/gcc/tree.c:7425
0x10f82493 iterative_hash_expr
/home/willschm/gcc/trunk.svn/gcc/tree.h:4934
0x10f89467 tree_operand_hash::hash(tree_node* const&)
/home/willschm/gcc/trunk.svn/gcc/tree-hash-traits.h:34
0x11d73dbb hash
/home/willschm/gcc/trunk.svn/gcc/hash-map-traits.h:49
0x11d7497b get
/home/willschm/gcc/trunk.svn/gcc/hash-map.h:161
0x11d84fab process_store
/home/willschm/gcc/trunk.svn/gcc/gimple-ssa-store-merging.c:4171
0x11d85697 execute
/home/willschm/gcc/trunk.svn/gcc/gimple-ssa-store-merging.c:4279
Please submit a full bug report,
with preprocessed source if appropriate.

# gcc with -O2
/home/willschm/gcc/install/gcc-mainline-pr82982/bin/gcc ~/gcc/pr82982.c -c -O2
during GIMPLE pass: store-merging
/home/willschm/gcc/pr82982.c: In function ‘km’:
/home/willschm/gcc/pr82982.c:4:1: internal compiler error: Segmentation fault
 km (void)
 ^~
0x10f76343 crash_signal
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/toplev.c:325
0x11fd5d98 internal_error(char const*, ...)
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/diagnostic.c:1433
0x11fd5e3f fancy_abort(char const*, int, char const*)
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/diagnostic.c:1500
0x114fd4cb inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree.c:7425
0x10fcad2f iterative_hash_expr
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree.h:4934
0x10fd1d03 tree_operand_hash::hash(tree_node* const&)
   
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree-hash-traits.h:34
0x11da7caf hash
   
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/hash-map-traits.h:49
0x11da886f get
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/hash-map.h:161
0x11db8e9f process_store
   
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/gimple-ssa-store-merging.c:4171
0x11db958b execute
   
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/gimple-ssa-store-merging.c:4279
Please submit a full bug report,

# gcc with -O3
# looks like the failure shows up during IPA pass: cp with -O3.
/home/willschm/gcc/install/gcc-mainline-pr82982/bin/gcc ~/gcc/pr82982.c -c -O3
during IPA pass: cp
/home/willschm/gcc/pr82982.c:31:1: internal compiler error: Segmentation fault
 }
 ^
0x10f76343 crash_signal
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/toplev.c:325
0x103de144 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree.h:3131
0x10daaa6f opts_for_fn
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/tree.h:5319
0x10dbec43 cgraph_node::optimize_for_size_p()
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/cgraph.h:3152
0x11e526bf ipcp_cloning_candidate_p
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/ipa-cp.c:727
0x11e52ab7 initialize_node_lattices
/home/willschm/gcc/gcc-mainline-pr82982/gcc.git/gcc/ipa-cp.c:1195
0x11e5fd3f ipcp_propagate_stage

[Bug c++/80598] [7/8 regression] -Wunused triggers for functions used in uninstantiated templates

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Started with r245643.

I wonder if we couldn't do something like following, still set TREE_USED on
where we've previously called mark_used but not really do the rest.
--- gcc/cp/semantics.c.jj   2018-03-06 21:40:35.717360176 +0100
+++ gcc/cp/semantics.c  2018-03-07 18:31:35.782132830 +0100
@@ -3740,10 +3740,15 @@ finish_id_expression (tree id_expression
 But only mark it if it's a complete postfix-expression; in a call,
 ADL might select a different function, and we'll call mark_used in
 build_over_call.  */
- if (done
- && !really_overloaded_fn (decl)
- && !mark_used (first_fn))
-   return error_mark_node;
+  if (!really_overloaded_fn (decl))
+   {
+ if (done && !mark_used (first_fn))
+   return error_mark_node;
+ /* Otherwise in templates mark first_fn as potentially used
+for the benefit of -Wunused, see PR80598.  */
+ else if (!done && processing_template_decl)
+   TREE_USED (first_fn) = 1;
+   }

  if (!template_arg_p
  && TREE_CODE (first_fn) == FUNCTION_DECL
--- gcc/testsuite/g++.dg/warn/Wunused-function4.C.jj2018-03-07
18:34:30.463176743 +0100
+++ gcc/testsuite/g++.dg/warn/Wunused-function4.C   2018-03-07
18:33:20.484159148 +0100
@@ -0,0 +1,21 @@
+// PR c++/80598
+// { dg-do compile }
+// { dg-options "-Wunused-function" }
+
+static void
+foo () // { dg-bogus "defined but not used" }
+{
+}
+
+static void
+bar () // { dg-warning "defined but not used" }
+{
+}
+
+template 
+int
+baz (T x)
+{
+  foo ();
+  return 0;
+}

[Bug c++/80452] [DR 1579] incorrect value category deduced for return value

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
(In reply to Martin Liška from comment #4)
> As the code snippet is also rejected in GCC 7, do you plan to backport that?

I wasn't planning to, since it isn't a regression, but I could be convinced.

[Bug target/84277] [8 Regression] A lot of new acats testsuite failures

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #14 from Eric Botcazou  ---
Results for 8.x should be on par with those for 7.3.x now.

[Bug target/84277] [8 Regression] A lot of new acats testsuite failures

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Mar  7 15:54:59 2018
New Revision: 258338

URL: https://gcc.gnu.org/viewcvs?rev=258338=gcc=rev
Log:
PR target/84277
* except.h (output_function_exception_table): Adjust prototype.
* except.c (output_function_exception_table): Remove FNNAME parameter
and add SECTION parameter.  Ouput one part of the table at a time.
* final.c (final_scan_insn_1) : Output
the first part of the exception table and emit unwind directives.
* config/i386/i386-protos.h (i386_pe_end_cold_function): Declare.
(i386_pe_seh_cold_init): Likewise.
* config/i386/cygming.h (ASM_DECLARE_COLD_FUNCTION_NAME): New macro.
(ASM_DECLARE_COLD_FUNCTION_SIZE): Likewise.
* config/i386/i386.c (x86_expand_epilogue): Fix wording in comment.
(ix86_output_call_insn): Emit a nop in one more case for SEH.
* config/i386/winnt.c: Include except.h.
(struct seh_frame_state): Add reg_offset, after_prologue and
in_cold_section fields.
(i386_pe_seh_end_prologue): Set seh->after_prologue.
(i386_pe_seh_cold_init): New function.
(i386_pe_seh_fini): Add COLD parameter and bail out if it is not equal
to seh->in_cold_section.
(seh_emit_push): Record the offset of the push.
(seh_emit_save): Record the offet of the save.
(i386_pe_seh_unwind_emit): Deal with NOTE_INSN_SWITCH_TEXT_SECTIONS.
Test seh->after_prologue to disregard the epilogue.
(i386_pe_end_function): Pass FALSE to i386_pe_seh_fini.
(i386_pe_end_cold_function): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cygming.h
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/winnt.c
trunk/gcc/except.c
trunk/gcc/except.h
trunk/gcc/final.c

[Bug fortran/77296] [F03] Compiler Error with allocatable string and associate

[matthew.thompson at nasa dot gov]

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

--- Comment #6 from Matt Thompson  ---
(In reply to Thomas Koenig from comment #5)
> This has been fixed by Paul's patch, closing.
> 
> Thanks for the bug report!

Will this patch appear in GCC 8? 7.4? I only ask because I had another bug (bug
59093) which was marked FIXED in 2017 but still isn't fixed in 7.3.

Is there a way to query which version bugs are fixed in?

[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment

[matthew.thompson at nasa dot gov]

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

--- Comment #14 from Matt Thompson  ---
Query: What version of GCC will fix this? It was reported fixed last year, but
GCC 7.3.0 still ICEs out.

[Bug target/84743] default widths for parallel reassociation now hurt rather than help

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
Yes I'm digging into this now and omnetpp is at the top of the list. I can see
if there is a difference between cpu2006 and 2017 as well. For gcc7 I used 2006
to determine the widths.

[Bug libstdc++/78420] [6/7/8 Regression] std::less<T*> is not a total order with -O2 enabled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug rtl-optimization/84748] [8 Regression] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I see the problem. Testing a patch.
Combine ends up moving the CC-using instruction over a
*compare_cstore_insn pattern because *compare_cstore_insn is not
marked as clobbering the CC reg, though it does so during post-reload
splitting.

[Bug c++/84699] discarded value expression of volatile class type shall materialize a temporary

[jens.maurer at gmx dot net]

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

Jens Maurer  changed:

   What|Removed |Added

 CC||jens.maurer at gmx dot net

--- Comment #2 from Jens Maurer  ---
This is core issue 1054.

[Bug c++/79271] Internal compiler error (ICE) in 'tsubst_copy' when combining constexpr array and higher order functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
Fixed by r251433.  Not backportable.

[Bug rtl-optimization/84748] [8 Regression] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-07
 CC||ktkachov at gcc dot gnu.org
  Known to work||7.2.1
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug c++/77869] ICE on a code piece

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
Fixed by r255780.

[Bug c++/80452] [DR 1579] incorrect value category deduced for return value

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
As the code snippet is also rejected in GCC 7, do you plan to backport that?

[Bug c++/70938] [5 only] internal compiler error: in tsubst_copy, at cp/pt.c:13008

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
GCC 5 is not supported anymore, closing.

[Bug c++/68451] internal compiler error: Segmentation fault when using decltype with friend inside a class template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Still ICEs:

$ ./cc1plus -quiet 68451.C
68451.C: In instantiation of ‘struct C’:
68451.C:21:12:   required from here
68451.C:12:7: internal compiler error: Segmentation fault
 A a;
   ^
0x1230d5b crash_signal
/home/marek/src/gcc/gcc/toplev.c:325
0xa2c870 instantiate_class_template_1
/home/marek/src/gcc/gcc/cp/pt.c:10926
0xa2cd6b instantiate_class_template(tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:11055
0xae51f4 complete_type(tree_node*)
/home/marek/src/gcc/gcc/cp/typeck.c:136
0x8c5cf7 start_decl_1(tree_node*, bool)
/home/marek/src/gcc/gcc/cp/decl.c:5241
0x8c5af9 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
/home/marek/src/gcc/gcc/cp/decl.c:5204
0x9c0aa6 cp_parser_init_declarator
/home/marek/src/gcc/gcc/cp/parser.c:19598
0x9b4527 cp_parser_simple_declaration
/home/marek/src/gcc/gcc/cp/parser.c:13057
0x9b4090 cp_parser_block_declaration
/home/marek/src/gcc/gcc/cp/parser.c:12882
0x9b3480 cp_parser_declaration_statement
/home/marek/src/gcc/gcc/cp/parser.c:12476
0x9af7d6 cp_parser_statement
/home/marek/src/gcc/gcc/cp/parser.c:10925
0x9b0565 cp_parser_statement_seq_opt
/home/marek/src/gcc/gcc/cp/parser.c:11274
0x9b045b cp_parser_compound_statement
/home/marek/src/gcc/gcc/cp/parser.c:11228
0x9c4e18 cp_parser_function_body
/home/marek/src/gcc/gcc/cp/parser.c:21776
0x9c50db cp_parser_ctor_initializer_opt_and_function_body
/home/marek/src/gcc/gcc/cp/parser.c:21813
0x9ced83 cp_parser_function_definition_after_declarator
/home/marek/src/gcc/gcc/cp/parser.c:26818
0x9ceba9 cp_parser_function_definition_from_specifiers_and_declarator
/home/marek/src/gcc/gcc/cp/parser.c:26734
0x9c07c8 cp_parser_init_declarator
/home/marek/src/gcc/gcc/cp/parser.c:19502
0x9b4527 cp_parser_simple_declaration
/home/marek/src/gcc/gcc/cp/parser.c:13057
0x9b4090 cp_parser_block_declaration
/home/marek/src/gcc/gcc/cp/parser.c:12882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/68180] [ICE] at cp/constexpr.c:2768 in initializing __vector in a loop

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Testcase is now rejected with
error: modification of ‘(float [4])v’ is not a constant-expression
   constexpr float32x4_t v = fill(1.f);
since r236630.  ICE is gone.  Closing.

[Bug c++/67724] internal compiler error in stl_vector.h

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
The testcase contains binary data.  GCC 4.9 is no longer supported.  I'll close
this, please reopen if you still see the bug.

[Bug c++/64751] internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:19486

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Marek Polacek  ---
All active branches seem to reject this and don't ICE.

[Bug c++/61228] noexcept(expression) causes internal compiler error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Marek Polacek  ---
Fixed by r254022.

[Bug driver/84750] New: Both the driver and cc1 warn for Target Warn option properties

[segher at gcc dot gnu.org]

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

Bug ID: 84750
   Summary: Both the driver and cc1 warn for Target Warn option
properties
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

Try rs6000 with -mstring for example:

$ powerpc-linux-gcc -Wall -W -O2 -S 0.c -mstring   
powerpc-linux-gcc: warning: '-mstring' is deprecated
cc1: warning: '-mstring' is deprecated


Or on another target:

$ arc-elf-gcc -Wall -W -O2 -S 0.c -mcrc
arc-elf-gcc: warning: '-mcrc' is deprecated
cc1: warning: '-mcrc' is deprecated

[Bug c++/64035] [C++11] ICE in reshape_init_r when using initializer list aggregate initialization for default function parameters

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Still ICEs:

$ ./cc1plus -quiet test1.cpp
test1.cpp: In function ‘int main()’:
test1.cpp:18:7: internal compiler error: in reshape_init_r, at cp/decl.c:6097
  func();
   ^
0x8c8d7e reshape_init_r
/home/marek/src/gcc/gcc/cp/decl.c:6097
0x8c810a reshape_init_class
/home/marek/src/gcc/gcc/cp/decl.c:5879
0x8c8e2b reshape_init_r
/home/marek/src/gcc/gcc/cp/decl.c:6110
0x8c90b3 reshape_init(tree_node*, tree_node*, int)
/home/marek/src/gcc/gcc/cp/decl.c:6170
0x7ff6da implicit_conversion
/home/marek/src/gcc/gcc/cp/call.c:1831
0x824b2f perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
/home/marek/src/gcc/gcc/cp/call.c:10563
0xb077ad convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
/home/marek/src/gcc/gcc/cp/typeck.c:8980
0x81559e convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
/home/marek/src/gcc/gcc/cp/call.c:7355
0x81820e build_over_call
/home/marek/src/gcc/gcc/cp/call.c:7960
0x808f59 build_new_function_call(tree_node*, vec**, int)
/home/marek/src/gcc/gcc/cp/call.c:4317
0xa9b767 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/marek/src/gcc/gcc/cp/semantics.c:2500
0x9a80e8 cp_parser_postfix_expression
/home/marek/src/gcc/gcc/cp/parser.c:7243
0x9aa988 cp_parser_unary_expression
/home/marek/src/gcc/gcc/cp/parser.c:8322
0x9abaa4 cp_parser_cast_expression
/home/marek/src/gcc/gcc/cp/parser.c:9090
0x9abba1 cp_parser_binary_expression
/home/marek/src/gcc/gcc/cp/parser.c:9191
0x9ac97e cp_parser_assignment_expression
/home/marek/src/gcc/gcc/cp/parser.c:9486
0x9acd1b cp_parser_expression
/home/marek/src/gcc/gcc/cp/parser.c:9655
0x9aff06 cp_parser_expression_statement
/home/marek/src/gcc/gcc/cp/parser.c:11131
0x9af813 cp_parser_statement
/home/marek/src/gcc/gcc/cp/parser.c:10935
0x9b0565 cp_parser_statement_seq_opt
/home/marek/src/gcc/gcc/cp/parser.c:11274
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/58908] ICE in process_init_constructor_array for std::vector

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed by r257720.

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-07
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Isn't that dup of 84149? Can you please tweak --param ipa-cp-eval-threshold to
value to 200, 300, 400? Can you please attach -fdump-ipa-cp-details file?

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #22 from Andrew Roberts  ---
The RPI Zero bug was fixed, I'm retesting with the latest snapshot (8.0.1
20180304) just to be sure it is ok. There are still a number of inconsistencies
and things which could be improved.

On Odroid-Xu4 (Cortex A15/A7 Big/little, Aarch32)
-

/usr/local/gcc/bin/gcc -mfpu=auto -O3 -o matrix matrix.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU

It would be better if this error could let the user know they need to select a
CPU manually, rather than incorrectly state it lacks an FPU. This is going to
be confusing to people.

/usr/local/gcc/bin/gcc -mcpu=native -mfpu=auto -O3 -o matrix matrix.c
Is fine.

/usr/local/gcc/bin/gcc -march=native -Q --help=target | grep
"mcpu\|mfpu\|march"
  -march=   armv7ve+vfpv3-d16
  -mcpu=
  -mfpu=vfpv3-d16
/usr/local/gcc/bin/gcc -march=native -mcpu=native -Q --help=target | grep
"mcpu\|mfpu\|march"
  -march=   armv7ve+vfpv3-d16
  -mcpu=cortex-a7
  -mfpu=vfpv3-d16

This is still not detecting BIG/little CPU combinations (I had a separate PR
about this [83207]).

On ODROID-C2 (Cortex A53,AARCH64)
--
/usr/local/gcc/bin/gcc -march=native -mcpu=native -Q --help=target | grep
"mcpu\|mfpu\|march"
  -march=ARCH   armv8-a+crc
  -mcpu=CPU cortex-a53

The output is inconsistent with aarch32 output (=ARCH, =CPU), I had also raised
a PR about this [83193].

On RPI 3 (Cortex A53,AArch32)
-
No issues here that I can see.

I'll update again tomorrow when the RPI Zero build has completed

[Bug libstdc++/84738] stack-overflow in regex_match

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-07
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed, I see it for GCC 6,7,8. But maybe older versions are also affected.

[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Short testcase for the latter, -O2 -Wall vs. -O2 -Wall -fsanitize=address:
struct S { char p[32]; };

struct S *
foo (char *q)
{
  struct S *p = __builtin_malloc (sizeof (struct S));
  __builtin_strncpy (p->p, q, 32);
  p->p[31] = '\0';
  return p;
}

With -fsanitize={,kernel-}address there is:
  __builtin_strncpy (_1, q_5(D), 32);
  _8 = _4->p[31];
  ASAN_CHECK (7, _8, 1, 1);
  p_4->p[31] = 0;
So, the -Wstringop-truncation would need to do the suggested alias search for
the store rather than next statement it does now, and in addition to that would
need to ignore ASAN_CHECK, because those are guaranteed not to actually read
the passed memory, just to check corresponding shadow memory.