[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.

Re: [PATCH] Fix switchconv ICE (PR tree-optimization/84740)

[Richard Biener]

On March 7, 2018 10:51:08 PM GMT+01:00, Jakub Jelinek  wrote:
>Hi!
>
>On the following testcase info.final_bb has only one PHI, the virtual
>one,
>so info.phi_count is 0.  For info.phi_count == 0, we don't really
>create any
>arrays etc.; just returning early (before create_temp_arrays) would
>work,
>but would leave the useless GIMPLE_SWITCH in the IL and it would take
>many
>passes to optimize it properly.  We know that all but the default: bbs
>are
>really empty and the default: can do something arbitrary, if all the
>ranges
>are consecutive, it is better to just let gen_inbound_check do its work
>and convert the switch into if (cond) { former_default_bb }.
>All but build_constructors function can handle 0 info.phi_count, but
>build_constructors can't, on the other side doesn't need to do anything
>if it is 0.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK. 

Richard. 

>2018-03-07  Jakub Jelinek  
>
>   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.
>
>--- gcc/tree-switch-conversion.c.jj2018-01-09 08:58:15.0 +0100
>+++ gcc/tree-switch-conversion.c   2018-03-07 12:03:42.228246408 +0100
>@@ -1563,7 +1563,8 @@ process_switch (gswitch *swtch)
>   gather_default_values (info.default_case_nonstandard
>? gimple_switch_label (swtch, 1)
>: gimple_switch_default_label (swtch), );
>-  build_constructors (swtch, );
>+  if (info.phi_count)
>+build_constructors (swtch, );
> 
>build_arrays (swtch, ); /* Build the static arrays and
>assignments.   */
>   gen_inbound_check (swtch, );   /* Build the bounds check.  */
>--- gcc/testsuite/gcc.dg/torture/pr84740.c.jj  2018-03-07
>12:13:02.153271986 +0100
>+++ gcc/testsuite/gcc.dg/torture/pr84740.c 2018-03-07
>12:12:42.643270368 +0100
>@@ -0,0 +1,24 @@
>+/* PR tree-optimization/84740 */
>+
>+void
>+frobulate_for_gcc (unsigned int v)
>+{
>+  const char *s;
>+  switch (v)
>+{
>+case 0:
>+  s = "foo";
>+  break;
>+case 1:
>+  s = "bar";
>+  break;
>+case 2:
>+  s = "spam";
>+  break;
>+default:
>+  s = (const char *) 0;
>+  break;
>+}
>+  if (!s)
>+__builtin_printf ("%s\n", s);
>+}
>
>   Jakub

[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.

[PATCH, rs6000] Fix PR83969: ICE in final_scan_insn, at final.c:2997

[Peter Bergner]

PR83969 shows another bug in mem_operand_gpr() (which implements the "Y"
constraint) accepting reg+reg addresses.  This was fixed by adding a call
to rs6000_offsettable_memref_p() to verify the address is a valid offsettable
address.  Fixing that exposed a problem in the *movdi_internal64 pattern
which was using the "Y" constraint for the integer load/store alternatives,
which allow either reg+offset or reg+reg addresses.  This worked before
only because of the buggy mem_operand_gpr.  The fix for that was to use
the "YZ" constraint which allows both reg+offset and reg+reg addresses.

This passed bootstrap and regtesting on powerpc64-linux, running the
testsuite in both 32-bit and 64-bit modes with no regressions.
Ok for trunk?

Peter

gcc/
    PR target/83969
    * config/rs6000/rs6000.c (rs6000_offsettable_memref_p): New prototype.
    Add strict argument and use it.
    (rs6000_split_multireg_move): Update for new strict argument.
    (mem_operand_gpr): Disallow all non-offsettable addresses.
    * config/rs6000/rs6000.md (*movdi_internal64): Use YZ constraint.

gcc/testsuite/
    PR target/83969
    * gcc.target/powerpc/pr83969.c: New test.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c    (revision 258268)
+++ gcc/config/rs6000/rs6000.c    (working copy)
@@ -1378,6 +1378,7 @@ static rtx rs6000_debug_legitimize_reloa
                        int, int, int *);
 static bool rs6000_mode_dependent_address (const_rtx);
 static bool rs6000_debug_mode_dependent_address (const_rtx);
+static bool rs6000_offsettable_memref_p (rtx, machine_mode, bool);
 static enum reg_class rs6000_secondary_reload_class (enum reg_class,
                      machine_mode, rtx);
 static enum reg_class rs6000_debug_secondary_reload_class (enum reg_class,
@@ -8207,10 +8208,8 @@ mem_operand_gpr (rtx op, machine_mode mo
   int extra;
   rtx addr = XEXP (op, 0);
 
-  /* Don't allow altivec type addresses like (mem (and (plus ...))).
- See PR target/84279.  */
-
-  if (GET_CODE (addr) == AND)
+  /* Don't allow non-offsettable addresses.  See PRs 83969 and 84279.  */
+  if (!rs6000_offsettable_memref_p (op, mode, false))
 return false;
 
   op = address_offset (addr);
@@ -9956,7 +9955,7 @@ rs6000_find_base_term (rtx op)
    in 32-bit mode, that the recog predicate rejects.  */
 
 static bool
-rs6000_offsettable_memref_p (rtx op, machine_mode reg_mode)
+rs6000_offsettable_memref_p (rtx op, machine_mode reg_mode, bool strict)
 {
   bool worst_case;
 
@@ -9964,7 +9963,7 @@ rs6000_offsettable_memref_p (rtx op, mac
 return false;
 
   /* First mimic offsettable_memref_p.  */
-  if (offsettable_address_p (true, GET_MODE (op), XEXP (op, 0)))
+  if (offsettable_address_p (strict, GET_MODE (op), XEXP (op, 0)))
 return true;
 
   /* offsettable_address_p invokes rs6000_mode_dependent_address, but
@@ -9978,7 +9977,7 @@ rs6000_offsettable_memref_p (rtx op, mac
   worst_case = ((TARGET_POWERPC64 && GET_MODE_CLASS (reg_mode) == MODE_INT)
     || GET_MODE_SIZE (reg_mode) == 4);
   return rs6000_legitimate_offset_address_p (GET_MODE (op), XEXP (op, 0),
-                     true, worst_case);
+                     strict, worst_case);
 }
 
 /* Determine the reassociation width to be used in reassociate_bb.
@@ -24063,7 +24062,7 @@ rs6000_split_multireg_move (rtx dst, rtx
   emit_insn (gen_add3_insn (breg, breg, delta_rtx));
   src = replace_equiv_address (src, breg);
     }
-      else if (! rs6000_offsettable_memref_p (src, reg_mode))
+      else if (! rs6000_offsettable_memref_p (src, reg_mode, true))
     {
   if (GET_CODE (XEXP (src, 0)) == PRE_MODIFY)
     {
@@ -24130,7 +24129,7 @@ rs6000_split_multireg_move (rtx dst, rtx
     emit_insn (gen_add3_insn (breg, breg, delta_rtx));
   dst = replace_equiv_address (dst, breg);
     }
-      else if (!rs6000_offsettable_memref_p (dst, reg_mode)
+      else if (!rs6000_offsettable_memref_p (dst, reg_mode, true)
        && GET_CODE (XEXP (dst, 0)) != LO_SUM)
     {
   if (GET_CODE (XEXP (dst, 0)) == PRE_MODIFY)
@@ -24169,7 +24168,7 @@ rs6000_split_multireg_move (rtx dst, rtx
     }
     }
   else if (GET_CODE (XEXP (dst, 0)) != LO_SUM)
-        gcc_assert (rs6000_offsettable_memref_p (dst, reg_mode));
+        gcc_assert (rs6000_offsettable_memref_p (dst, reg_mode, true));
 }
 
   for (i = 0; i < nregs; i++)
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md    (revision 258268)
+++ gcc/config/rs6000/rs6000.md    (working copy)
@@ -8549,14 +8549,14 @@ (define_split
 ;;  FPR->GPR   GPR->FPR   VSX->GPR   GPR->VSX
 (define_insn "*movdi_internal64"
   [(set (match_operand:DI 0 "nonimmediate_operand"
-   "=Y,    r, r, r, r,  r,
+   "=YZ,   r, 

[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

Re: [PATCH] Fix tail recursion (PR tree-optimization/84739)

[Jeff Law]

On 03/07/2018 02:42 PM, Jakub Jelinek wrote:
> Hi!
> 
> Before Honza introduced recursive_call_p, this tree-tailcall.c snipped
> has been guarded with if (func == current_function_decl), so what we used
> for DECL_ARGUMENTS didn't really matter.  But as it can now be some alias
> to it, we really want to check that the current function's arguments
> match the arguments of the call, rather than just that the call's arguments
> match its function type.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-03-07  Jakub Jelinek  
> 
>   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.
OK.
jeff

[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.

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Peter Bergner]

On 3/7/18 12:01 AM, Jeff Law wrote:
> I believe so by nature that the setjmp dominates the longjmp sites and
> thus also dominates the dispatcher.  But it's something I want to
> explicitly check before resubmitting.

Are we sure a setjmp has to dominate its longjmp sites?  Couldn't you
have something like:

bb(a): bb(b):
  ......
  setjmp (env)   setjmp (env)
  \ /
   \   /
\ /
 \   /
  \ /
   \   /
bb(c):
  ...
  longjmp (env)

...or:

bb(a):
  ...
  setjmp (env)
  |\
  | \
  |  \
  |   \
  |   bb(b):
  | ...
  | setjmp (env)
  |   /
  |  /
  | /
  v
bb(c):
  ...
  longjmp (env)

If so, then the setjmp calls might not dominate the longjmp call.

Peter

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Martin Sebor]

On 03/07/2018 04:04 PM, Richard Sandiford wrote:

Martin Sebor  writes:

@@ -409,23 +412,33 @@ builtin_memref::set_base_and_offset (tree expr)
   base = get_inner_reference (expr, , , _off,
  , , , );

+  /* get_inner_reference is not expected to return null.  */
+  gcc_assert (base != NULL);
+
   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);

-  HOST_WIDE_INT const_off;
-  if (!base || !bytepos.is_constant (_off))
+  /* Convert the poly_int64 offset to to offset_int.  The offset
+ should be constant but be prepared for it not to be just in
+ case.  */


I know it's just repeating what I said in the other reply, but I think
we should drop this comment.  It doesn't add anything and it will quickly
become out of date once the frontend supports variable-length types.


For some reason I never got the email you're referring to (I just
found it in the archives, after some head scratching as to what
you meant above).

I added the comment based on your feedback that it can't happen
yet (as an explanation for not calling to_constant() instead),
but I'll remove it before I commit the patch.

Otherwise, I only made these changes here because Jakub asked
me to.  They are unrelated to the fix for the ICE and so they
should have been made independently of it.  But since they are
correct and any difference in efficiency between HOST_WIDE_INT
and offset_int here is surely insignificant (and since you
also said you were fine either way) I'll leave the offset_int
in place.

Thanks
Martin

[PATCH] Fix tail recursion (PR tree-optimization/84739)

[Jakub Jelinek]

Hi!

Before Honza introduced recursive_call_p, this tree-tailcall.c snipped
has been guarded with if (func == current_function_decl), so what we used
for DECL_ARGUMENTS didn't really matter.  But as it can now be some alias
to it, we really want to check that the current function's arguments
match the arguments of the call, rather than just that the call's arguments
match its function type.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-03-07  Jakub Jelinek  

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.

--- gcc/tree-tailcall.c.jj  2018-01-12 11:35:51.470222838 +0100
+++ gcc/tree-tailcall.c 2018-03-06 23:05:39.779048759 +0100
@@ -481,7 +481,7 @@ find_tail_calls (basic_block bb, struct
 {
   tree arg;
 
-  for (param = DECL_ARGUMENTS (func), idx = 0;
+  for (param = DECL_ARGUMENTS (current_function_decl), idx = 0;
   param && idx < gimple_call_num_args (call);
   param = DECL_CHAIN (param), idx ++)
{
--- gcc/testsuite/gcc.dg/pr84739.c.jj   2018-03-07 09:43:13.961110879 +0100
+++ gcc/testsuite/gcc.dg/pr84739.c  2018-03-07 09:43:19.856109830 +0100
@@ -0,0 +1,26 @@
+/* PR tree-optimization/84739 */
+/* { dg-do compile } */
+/* { dg-require-weak "" } */
+/* { dg-options "-O2" } */
+
+static void baz (void) __attribute__((weakref("bar")));/* { dg-warning 
"alias between functions of incompatible types" } */
+
+int
+foo (int x, int y)
+{
+  if (x)
+y = 0;
+  if (y)
+goto lab;
+  y = 0;
+lab:
+  return y;
+}
+
+void
+bar (int x, int y) /* { dg-message "aliased declaration here" } */
+{
+  y = foo (x, y);
+  if (y != 0)
+baz ();
+}

Jakub

[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.

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Richard Sandiford]

Martin Sebor  writes:
> @@ -409,23 +412,33 @@ builtin_memref::set_base_and_offset (tree expr)
>base = get_inner_reference (expr, , , _off,
> , , , );
>  
> +  /* get_inner_reference is not expected to return null.  */
> +  gcc_assert (base != NULL);
> +
>poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
>  
> -  HOST_WIDE_INT const_off;
> -  if (!base || !bytepos.is_constant (_off))
> +  /* Convert the poly_int64 offset to to offset_int.  The offset
> + should be constant but be prepared for it not to be just in
> + case.  */

I know it's just repeating what I said in the other reply, but I think
we should drop this comment.  It doesn't add anything and it will quickly
become out of date once the frontend supports variable-length types.

> +  offset_int cstoff;
> +  if (bytepos.is_constant ())

Also, same comment about this being less efficient than using the
natural type of HOST_WIDE_INT.  I think this and...

>  {
> -  base = get_base_address (TREE_OPERAND (expr, 0));
> -  return;
> +  offrange[0] += cstoff;
> +  offrange[1] += cstoff;
> +
> +  /* Besides the reference saved above, also stash the offset
> +  for validation.  */
> +  if (TREE_CODE (expr) == COMPONENT_REF)
> + refoff = cstoff;
>  }
> +  else
> +offrange[1] += maxobjsize;
>  
> -  offrange[0] += const_off;
> -  offrange[1] += const_off;
> -
>if (var_off)
>  {
>if (TREE_CODE (var_off) == INTEGER_CST)
>   {
> -   offset_int cstoff = wi::to_offset (var_off);
> +   cstoff = wi::to_offset (var_off);
> offrange[0] += cstoff;
> offrange[1] += cstoff;

...this are logically separate variables, so there's no need for
them to have the same type and name.

Richard

[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

Re: Fix some _GLIBCXX_DEBUG pretty printer errors

[Jonathan Wakely]

On 7 March 2018 at 17:39, François Dumont wrote:
> On 06/03/2018 22:21, Jonathan Wakely wrote:
>>
>>
>>> @@ -575,10 +586,12 @@ class StdDebugIteratorPrinter:
>>>  # and return the wrapped iterator value.
>>>  def to_string (self):
>>>  base_type = gdb.lookup_type('__gnu_debug::_Safe_iterator_base')
>>> +itype = self.val.type.template_argument(0)
>>>  safe_seq = self.val.cast(base_type)['_M_sequence']
>>> -if not safe_seq or self.val['_M_version'] !=
>>> safe_seq['_M_version']:
>>> +if not safe_seq:
>>> +return str(self.val.cast(itype))
>>
>> So what's the effect of this change when we get a value-initialized
>> debug iterator? It prints the wrapped (value-initialized) non-debug
>> iterator instead?
>>
> Yes, for instance this test in smiple11.cc:
>
>
>   std::deque::iterator deqiter0;
> // { dg-final { note-test deqiter0 {non-dereferenceable iterator for
> std::deque} } }
>
> Was failing when running 'make check-debug
> RUNTESTFLAGS=prettyprinters.exp' because it was displaying 'invalid
> iterator' rather than non-dereferenceable. Now it is succeeded.

OK, thanks for confirming.

This is OK for trunk, thanks. If anybody complains about the missing
printers for the __norm types we can add them back again.

[PATCH] avoid warning for memcpy to self (PR 83456)

[Martin Sebor]

I have become convinced that issuing -Wrestrict in gimple-fold
for calls to memcpy() where the source pointer is the same as
the destination causes more trouble than it's worth, especially
when inlining is involved, as in:

  inline void bar (void *d, void *s, unsigned N)
  {
if (s != d)
  memcpy (d, s, N);
  }

  void foo (void* src)
  {
bar (src, src, 1);
  }

It seems that there should be a way to teach GCC to avoid
folding statements in dead blocks (e.g., in a block controlled
by 'if (0 != 0)' as the one below), and that it might even speed
up compilation, but in the meantime it leads to false positive
-Wrestrict warnings.

The attached patch removes this instance of the warning and
adjusts tests not to expect it.

Martin
PR tree-optimization/83456 - -Wrestrict false positive on a non-overlapping memcpy in an inline function

gcc/ChangeLog:

	PR tree-optimization/83456
	* gimple-fold.c (gimple_fold_builtin_memory_op): Avoid warning
	for perfectly overlapping calls to memcpy.
	(gimple_fold_builtin_memory_chk): Same.

gcc/testsuite/ChangeLog:

	PR tree-optimization/83456
	* c-c++-common/Wrestrict-2.c: Remove test cases.
	* c-c++-common/Wrestrict.c: Same.
	* gcc.dg/Wrestrict-12.c: New test.

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c	(revision 258339)
+++ gcc/gimple-fold.c	(working copy)
@@ -713,13 +713,7 @@ gimple_fold_builtin_memory_op (gimple_stmt_iterato
 {
   /* Avoid diagnosing exact overlap in calls to __builtin_memcpy.
 	 It's safe and may even be emitted by GCC itself (see bug
-	 32667).  However, diagnose it in explicit calls to the memcpy
-	 function.  */
-  if (check_overlap && *IDENTIFIER_POINTER (DECL_NAME (func)) != '_')
-  	warning_at (loc, OPT_Wrestrict,
-  		"%qD source argument is the same as destination",
-  		func);
-
+	 32667).  */
   unlink_stmt_vdef (stmt);
   if (gimple_vdef (stmt) && TREE_CODE (gimple_vdef (stmt)) == SSA_NAME)
 	release_ssa_name (gimple_vdef (stmt));
@@ -2499,15 +2493,6 @@ gimple_fold_builtin_memory_chk (gimple_stmt_iterat
  (resp. DEST+LEN for __mempcpy_chk).  */
   if (fcode != BUILT_IN_MEMSET_CHK && operand_equal_p (src, dest, 0))
 {
-  if (fcode != BUILT_IN_MEMMOVE && fcode != BUILT_IN_MEMMOVE_CHK)
-	{
-	  tree func = gimple_call_fndecl (stmt);
-
-	  warning_at (loc, OPT_Wrestrict,
-		  "%qD source argument is the same as destination",
-		  func);
-	}
-
   if (fcode != BUILT_IN_MEMPCPY_CHK)
 	{
 	  replace_call_with_value (gsi, dest);
Index: gcc/testsuite/c-c++-common/Wrestrict-2.c
===
--- gcc/testsuite/c-c++-common/Wrestrict-2.c	(revision 258339)
+++ gcc/testsuite/c-c++-common/Wrestrict-2.c	(working copy)
@@ -12,13 +12,13 @@
 
 static void wrap_memcpy (void *d, const void *s, size_t n)
 {
-  memcpy (d, s, n);   /* { dg-warning "source argument is the same as destination" "memcpy" } */
+  memcpy (d, s, n);   /* { dg-warning "accessing 2 bytes at offsets 0 and 1 overlaps 1 byte at offset 1" "memcpy" } */
 }
 
-void call_memcpy (void *d, size_t n)
+void call_memcpy (char *d)
 {
-  const void *s = d;
-  wrap_memcpy (d, s, n);
+  const void *s = d + 1;
+  wrap_memcpy (d, s, 2);
 }
 
 
Index: gcc/testsuite/c-c++-common/Wrestrict.c
===
--- gcc/testsuite/c-c++-common/Wrestrict.c	(revision 258339)
+++ gcc/testsuite/c-c++-common/Wrestrict.c	(working copy)
@@ -52,7 +52,6 @@ void test_memcpy_cst (void *d, const void *s)
   } while (0)
 
   T (a, a, 0);
-  T (a, s = a, 3);   /* { dg-warning "\\\[-Wrestrict" "memcpy" } */
 
   /* This isn't detected because memcpy calls with small power-of-2 sizes
  are intentionally folded into safe copies equivalent to memmove.
@@ -64,19 +63,6 @@ void test_memcpy_cst (void *d, const void *s)
   T (a, a + 3, 5);   /* { dg-warning "\\\[-Wrestrict" "memcpy" } */
 
   {
-char a[3] = { 1, 2, 3 };
-
-/* Verify that a call to memcpy with an exact overlap is diagnosed
-   (also tested above) but an excplicit one to __builtin_memcpy is
-   not.  See bug 32667 for the rationale.  */
-(memcpy)(a, a, sizeof a);   /* { dg-warning "source argument is the same as destination" "memcpy" } */
-sink (a);
-
-__builtin_memcpy (a, a, sizeof a);
-sink (a);
-  }
-
-  {
 char a[3][7];
 sink (a);
 
@@ -116,11 +102,6 @@ void test_memcpy_cst (void *d, const void *s)
 memcpy (d, s, sizeof x.a);
 sink ();
 
-d = x.a;
-s = x.a;
-memcpy (d, s, sizeof x.a);/* { dg-warning "\\\[-Wrestrict" "memcpy" } */
-sink ();
-
 d = x.a + 4;
 s = x.b;
 memcpy (d, s, sizeof x.a);/* { dg-warning "\\\[-Wrestrict" "memcpy" } */
@@ -450,19 +431,6 @@ void test_memcpy_var (char *d, const char *s)
   memcpy (d, d, 0);
   sink (d);
 
-  memcpy (d, d, n);   /* { dg-warning "source argument is the same as 

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Martin Sebor]

On 03/07/2018 12:37 PM, Jeff Law wrote:

On 02/26/2018 10:32 AM, Martin Sebor wrote:


PR tree-optimization/84526 - ICE in generic_overlap at 
gcc/gimple-ssa-warn-restrict.c:927 since r257860

gcc/ChangeLog:

PR tree-optimization/84526
* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
Remove dead code.
(builtin_access::generic_overlap): Be prepared to handle non-array
base objects.

gcc/testsuite/ChangeLog:

PR tree-optimization/84526
* gcc.dg/Wrestrict-10.c: New test.

Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c  (revision 257963)
+++ gcc/gimple-ssa-warn-restrict.c  (working copy)
@@ -396,6 +396,9 @@ builtin_memref::set_base_and_offset (tree expr)
   if (TREE_CODE (expr) == ADDR_EXPR)
 expr = TREE_OPERAND (expr, 0);

+  /* Stash the reference for offset validation.  */
+  ref = expr;
+
   poly_int64 bitsize, bitpos;
   tree var_off;
   machine_mode mode;
@@ -409,23 +412,33 @@ builtin_memref::set_base_and_offset (tree expr)
   base = get_inner_reference (expr, , , _off,
  , , , );

+  /* get_inner_reference is not expected to return null.  */
+  gcc_assert (base != NULL);
+
   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);

-  HOST_WIDE_INT const_off;
-  if (!base || !bytepos.is_constant (_off))
+  /* Convert the poly_int64 offset to to offset_int.  The offset
+ should be constant but be prepared for it not to be just in
+ case.  */
+  offset_int cstoff;
+  if (bytepos.is_constant ())
 {
-  base = get_base_address (TREE_OPERAND (expr, 0));
-  return;
+  offrange[0] += cstoff;
+  offrange[1] += cstoff;
+
+  /* Besides the reference saved above, also stash the offset
+for validation.  */
+  if (TREE_CODE (expr) == COMPONENT_REF)
+   refoff = cstoff;
 }
+  else
+offrange[1] += maxobjsize;

So is this assignment to offrange[1] really correct?

ISTM that it potentially overflows (relative to MAXOBJSIZE) and that
you'd likely be better off just assigning offrange[1] to MAXOBJSIZE.

Or alternately signal to the callers that we can't really analyze the
memory address and inhibit further analysis of the potential overlap of
the objects.


The offsets are stored in offset_int and there is code to deal
with values outside the [-MAXOBJSIZE, MAXOBJSIZE] range, either
by capping them to the bounds of the array/object being accessed
if it's known, or to the MAXOBJSIZE range.  There are a number of
places where offsets with unknown values are being added together
and where their sum might end up exceeding that range (e.g., when
dealing with multiple offsets, each in some range) but as long
as the offsets are only added and not multiplied they should never
overflow offset_int.  It would be okay to assign MAXOBJSIZE here
instead of adding it, but there are other places with the same
addition (see the bottom of builtin_memref::extend_offset_range)
so doing it here alone would be inconsistent.


@@ -918,12 +924,18 @@ builtin_access::generic_overlap ()
   if (!overlap_certain)
 {
   if (!dstref->strbounded_p && !depends_p)
+   /* Memcpy only considers certain overlap.  */
return false;

   /* There's no way to distinguish an access to the same member
 of a structure from one to two distinct members of the same
 structure.  Give up to avoid excessive false positives.  */
-  tree basetype = TREE_TYPE (TREE_TYPE (dstref->base));
+  tree basetype = TREE_TYPE (dstref->base);
+
+  if (POINTER_TYPE_P (basetype)
+ || TREE_CODE (basetype) == ARRAY_TYPE)
+   basetype = TREE_TYPE (basetype);
+
   if (RECORD_OR_UNION_TYPE_P (basetype))
return false;
 }

This is probably fairly reasonable.  My only concern would be that we
handle multi-dimensional arrays correctly.  Do you need to handle
ARRAY_TYPEs with a loop?


Yes, good catch, thanks!  It's unrelated to this bug (the ICE) but
it seems simple enough to handle at the same time so I've added
the loop and a test to verify it works as expected.


I do have a more general concern.  Given that we walk backwards through
pointer casts and ADDR_EXPRs we potentially lose information.  For
example we might walk backwards through a cast from a small array to a
larger array type.

Thus later we use the smaller array type when computing the bounds and
subsequent offset from BASE.  This could lead to a missed warning as the
computed offset would be too small.


There are many false negatives here.  A lot of those I noticed
during testing are because of limitations in the strlen pass
(I must have raised a dozen bugs to track and, hopefully, fix
in stage 1).  There are also deficiencies in the restrict pass
itself.  For instance, using builtin_object_size to compute
the size of member arrays leads to many because bos computes
the size of the larger 

gcc-6-20180307 is now available

[gccadmin]

Snapshot gcc-6-20180307 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180307/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 258342

You'll find:

 gcc-6-20180307.tar.xzComplete GCC

  SHA256=39718ba6a009390bcfb7ecb5d2ed0debce0c2f0c6000d625c50afb5e9ffa912d
  SHA1=5ac4fdd01b947d23cb5a705dcbf518d3605f8c71

Diffs from 6-20180228 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[PATCH] Fix switchconv ICE (PR tree-optimization/84740)

[Jakub Jelinek]

Hi!

On the following testcase info.final_bb has only one PHI, the virtual one,
so info.phi_count is 0.  For info.phi_count == 0, we don't really create any
arrays etc.; just returning early (before create_temp_arrays) would work,
but would leave the useless GIMPLE_SWITCH in the IL and it would take many
passes to optimize it properly.  We know that all but the default: bbs are
really empty and the default: can do something arbitrary, if all the ranges
are consecutive, it is better to just let gen_inbound_check do its work
and convert the switch into if (cond) { former_default_bb }.
All but build_constructors function can handle 0 info.phi_count, but
build_constructors can't, on the other side doesn't need to do anything
if it is 0.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-03-07  Jakub Jelinek  

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.

--- gcc/tree-switch-conversion.c.jj 2018-01-09 08:58:15.0 +0100
+++ gcc/tree-switch-conversion.c2018-03-07 12:03:42.228246408 +0100
@@ -1563,7 +1563,8 @@ process_switch (gswitch *swtch)
   gather_default_values (info.default_case_nonstandard
 ? gimple_switch_label (swtch, 1)
 : gimple_switch_default_label (swtch), );
-  build_constructors (swtch, );
+  if (info.phi_count)
+build_constructors (swtch, );
 
   build_arrays (swtch, ); /* Build the static arrays and assignments.   */
   gen_inbound_check (swtch, );/* Build the bounds check.  */
--- gcc/testsuite/gcc.dg/torture/pr84740.c.jj   2018-03-07 12:13:02.153271986 
+0100
+++ gcc/testsuite/gcc.dg/torture/pr84740.c  2018-03-07 12:12:42.643270368 
+0100
@@ -0,0 +1,24 @@
+/* PR tree-optimization/84740 */
+
+void
+frobulate_for_gcc (unsigned int v)
+{
+  const char *s;
+  switch (v)
+{
+case 0:
+  s = "foo";
+  break;
+case 1:
+  s = "bar";
+  break;
+case 2:
+  s = "spam";
+  break;
+default:
+  s = (const char *) 0;
+  break;
+}
+  if (!s)
+__builtin_printf ("%s\n", s);
+}

Jakub

[PATCH] __builtin_early_constant_p (PR c++/78420)

[Jakub Jelinek]

Hi!

This is the implementation of __builtin_early_constant_p builtin which
is at all optimization levels quite similar to __builtin_constant_p
at -O0, except that the FE folding might be slightly different between -O0
and -O1+.  In any case, the builtin is folded to 0 already during the FEs
if the argument can't be proven constant or non-constant, like with
__builtin_constant_p at -O0.
The users can use it for stuff where __builtin_constant_p doesn't really
work (e.g. the kernel ilog2 case), for e.g. C macro constexpr-like
programming.

Is this ok for stage1, or do you find it not useful at all?

In any case, bootstrapped/regtested on x86_64-linux and i686-linux.

2018-03-07  Jakub Jelinek  

PR c++/78420
* builtins.def (BUILT_IN_EARLY_CONSTANT_P): New built-in.
* builtins.h (force_folding_builtin_constant_p): Change from bool to
int.
* builtins.c (force_folding_builtin_constant_p): Likewise.
(expand_builtin): Handle BUILT_IN_EARLY_CONSTANT_P like
BUILT_IN_CONSTANT_P.
(fold_builtin_constant_p): Check force_folding_builtin_constant_p > 0
instead of force_folding_builtin_constant_p.
(fold_builtin_1) : Don't return
integer_zero_node if force_folding_builtin_constant_p < 0.
: New case.
(is_simple_builtin): Handle BUILT_IN_EARLY_CONSTANT_P like
BUILT_IN_CONSTANT_P.
* doc/extend.texi (__builtin_early_constant_p): Document.
c-family/
* c-common.c (check_builtin_function_arguments): Handle
BUILT_IN_EARLY_CONSTANT_P like BUILT_IN_CONSTANT_P.
c/
* c-parser.c (c_parser_get_builtin_args): Adjust for
force_folding_builtin_constant_p now being int rather than bool.
cp/
* cp-tree.h (DECL_IS_BUILTIN_CONSTANT_P): Handle
BUILT_IN_EARLY_CONSTANT_P like BUILT_IN_CONSTANT_P.
* call.c (magic_varargs_p): Likewise.
* tree.c (builtin_valid_in_constant_expr_p): Likewise.
* constexpr.c (cxx_eval_builtin_function_call): Likewise.
Adjust for force_folding_builtin_constant_p now being int rather than
bool.
* cp-gimplify.c: Include builtins.h.
(cp_fold): For __builtin*_constant_p adjust temporarily
force_folding_builtin_constant_p rather than optimize.
testsuite/
* g++.dg/delayedfold/builtin-constant4.C: New test.
* g++.dg/delayedfold/builtin-constant3.C: New test.
* g++.dg/ext/builtin14.C: New test.
* g++.dg/ext/builtin12.C: New test.
* g++.dg/ext/builtin13.C: New test.
* g++.dg/cpp1y/constexpr-78420.C: New test.
* g++.dg/cpp0x/constexpr-builtin5.C: New test.
* g++.dg/cpp0x/constexpr-builtin4.C: New test.
* gcc.dg/torture/pr78420.c: New test.

--- gcc/builtins.def.jj 2018-01-03 10:19:55.103533949 +0100
+++ gcc/builtins.def2018-03-07 15:55:20.756617250 +0100
@@ -857,6 +857,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_DCGETTE
 DEF_EXT_LIB_BUILTIN(BUILT_IN_DGETTEXT, "dgettext", 
BT_FN_STRING_CONST_STRING_CONST_STRING, ATTR_FORMAT_ARG_2)
 DEF_GCC_BUILTIN(BUILT_IN_DWARF_CFA, "dwarf_cfa", BT_FN_PTR, ATTR_NULL)
 DEF_GCC_BUILTIN(BUILT_IN_DWARF_SP_COLUMN, "dwarf_sp_column", 
BT_FN_UINT, ATTR_NULL)
+DEF_GCC_BUILTIN(BUILT_IN_EARLY_CONSTANT_P, "early_constant_p", 
BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_EH_RETURN, "eh_return", 
BT_FN_VOID_PTRMODE_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_EH_RETURN_DATA_REGNO, "eh_return_data_regno", 
BT_FN_INT_INT, ATTR_LEAF_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_EXECL, "execl", 
BT_FN_INT_CONST_STRING_CONST_STRING_VAR, ATTR_SENTINEL_NOTHROW_LIST)
--- gcc/builtins.h.jj   2018-01-04 00:43:16.103702766 +0100
+++ gcc/builtins.h  2018-03-07 16:31:54.898348803 +0100
@@ -46,8 +46,10 @@ extern struct target_builtins *this_targ
 #define this_target_builtins (_target_builtins)
 #endif
 
-/* Non-zero if __builtin_constant_p should be folded right away.  */
-extern bool force_folding_builtin_constant_p;
+/* 1 if __builtin_{,early_}constant_p should be folded right away,
+   -1 if __builtin_{,early_}constant_p should not be folded to 0 when
+   fold_builtin_constant_p returned NULL.  */
+extern int force_folding_builtin_constant_p;
 
 extern bool is_builtin_fn (tree);
 extern bool called_as_built_in (tree);
--- gcc/builtins.c.jj   2018-02-19 20:35:54.418015330 +0100
+++ gcc/builtins.c  2018-03-07 16:32:12.326353626 +0100
@@ -91,8 +91,10 @@ const char * built_in_names[(int) END_BU
initialized to NULL_TREE.  */
 builtin_info_type builtin_info[(int)END_BUILTINS];
 
-/* Non-zero if __builtin_constant_p should be folded right away.  */
-bool force_folding_builtin_constant_p;
+/* 1 if __builtin_{,early_}constant_p should be folded right away,
+   -1 if __builtin_{,early_}constant_p should not be folded to 0 when
+   fold_builtin_constant_p returned NULL.  */
+int force_folding_builtin_constant_p;
 
 

Re: [PATCH] Fix ICE for static vars in offloaded functions

[Jakub Jelinek]

On Wed, Mar 07, 2018 at 02:20:26PM +0100, Tom de Vries wrote:
> Fix ICE for static vars in offloaded functions
> 
> 2018-03-06  Tom de Vries  
> 
>   PR lto/84592
>   * varpool.c (varpool_node::get_create): Mark static variables in
>   offloaded functions as offloadable.
> 
>   * testsuite/libgomp.c/pr84592-2.c: New test.
>   * testsuite/libgomp.c/pr84592.c: New test.
>   * testsuite/libgomp.oacc-c-c++-common/pr84592-3.c: New test.

Ok, thanks

Jakub

[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;
}

Re: C++ PATCH for c++/84036, ICE with variadic lambda capture

[Jason Merrill]

On Sun, Feb 11, 2018 at 8:21 PM, Jason Merrill  wrote:
> The old lambda model handled variadic capture by focusing on the
> FIELD_DECL rather than trying to map between capture proxies.  The new
> model relies more on capture proxies, so it makes sense to use them
> more for variadic capture as well.  So with this patch we treat a
> variadic capture proxy as a pack, rather than the field.

Which makes the recently added is_capture_proxy_with_ref redundant.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4f59367cbb4fe82c68f9df30e49af8a2a19dd6cf
Author: Jason Merrill 
Date:   Tue Mar 6 17:31:44 2018 -0500

* lambda.c (is_capture_proxy_with_ref): Remove.

* constexpr.c, expr.c, cp-tree.h, semantics.c: Adjust.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index bd53bfbfe47..2c5a71f3ee5 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -5429,7 +5429,7 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict, bool now,
 case VAR_DECL:
   if (DECL_HAS_VALUE_EXPR_P (t))
 	{
-	  if (now && is_capture_proxy_with_ref (t))
+	  if (now && is_normal_capture_proxy (t))
 	{
 	  /* -- in a lambda-expression, a reference to this or to a
 		 variable with automatic storage duration defined outside that
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 8f3ec86e8ce..3a6f8f33e8d 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6896,7 +6896,6 @@ extern void insert_capture_proxy		(tree);
 extern void insert_pending_capture_proxies	(void);
 extern bool is_capture_proxy			(tree);
 extern bool is_normal_capture_proxy (tree);
-extern bool is_capture_proxy_with_ref   (tree);
 extern void register_capture_members		(tree);
 extern tree lambda_expr_this_capture(tree, bool);
 extern void maybe_generic_this_capture		(tree, tree);
diff --git a/gcc/cp/expr.c b/gcc/cp/expr.c
index b2c8cfaf88c..2e679868970 100644
--- a/gcc/cp/expr.c
+++ b/gcc/cp/expr.c
@@ -111,7 +111,7 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
 {
 case VAR_DECL:
 case PARM_DECL:
-  if (rvalue_p && is_capture_proxy_with_ref (expr))
+  if (rvalue_p && is_normal_capture_proxy (expr))
 	{
 	  /* Look through capture by copy.  */
 	  tree cap = DECL_CAPTURED_VARIABLE (expr);
@@ -154,7 +154,7 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
 	{
 	  /* Try to look through the reference.  */
 	  tree ref = TREE_OPERAND (expr, 0);
-	  if (rvalue_p && is_capture_proxy_with_ref (ref))
+	  if (rvalue_p && is_normal_capture_proxy (ref))
 	{
 	  /* Look through capture by reference.  */
 	  tree cap = DECL_CAPTURED_VARIABLE (ref);
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 345b210e89c..094979e81a3 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -291,24 +291,13 @@ is_normal_capture_proxy (tree decl)
   return DECL_NORMAL_CAPTURE_P (val);
 }
 
-/* Returns true iff DECL is a capture proxy for which we can use
-   DECL_CAPTURED_VARIABLE.  In effect, this is a normal proxy other than a
-   nested capture of a function parameter pack.  */
-
-bool
-is_capture_proxy_with_ref (tree var)
-{
-  return (is_normal_capture_proxy (var) && DECL_LANG_SPECIFIC (var)
-	  && DECL_CAPTURED_VARIABLE (var));
-}
-
 /* VAR is a capture proxy created by build_capture_proxy; add it to the
current function, which is the operator() for the appropriate lambda.  */
 
 void
 insert_capture_proxy (tree var)
 {
-  if (is_capture_proxy_with_ref (var))
+  if (is_normal_capture_proxy (var))
 {
   tree cap = DECL_CAPTURED_VARIABLE (var);
   if (CHECKING_P)
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 8a0096ddf92..bb8b5953539 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3332,7 +3332,7 @@ process_outer_var_ref (tree decl, tsubst_flags_t complain, bool odr_use)
 {
   /* Check whether we've already built a proxy.  */
   tree var = decl;
-  while (is_capture_proxy_with_ref (var))
+  while (is_normal_capture_proxy (var))
 	var = DECL_CAPTURED_VARIABLE (var);
   tree d = retrieve_local_specialization (var);
 

Re: [C++ Patch/RFC] PR 71169 ("[7/8 Regression] ICE on invalid C++ code in pop_nested_class"), PR 71832 and more

[Paolo Carlini]

Hi,

On 07/03/2018 21:23, Jason Merrill wrote:

On Wed, Mar 7, 2018 at 12:18 PM, Paolo Carlini  wrote:

Hi,

[snip the various clarifications]

Il 7 Marzo 2018 17:57:07 CET, Jason Merrill  ha scritto:

My thought was that this patch adds a lot of managing of the flag in
different places in the parser, whereas looking for error_mark_node in
the template parms here would be just in one place.  But if you prefer
the current approach, that's fine, it's straightforward enough.

Thanks a lot for the various clarifications above, where essentially turns out 
that some details of my patch are correct essentially by chance ;) Seriously, 
I'm thinking the following: since 8 is getting real close, what if, for 8, for 
the known mild regressions, we go ahead with my super safe Plan B which I 
mentioned at beginning of the thread, then as soon as trunk branches we 
immediately apply my patch and we give it a serious spin, say we rebuild 
distros with it, and see what happens?

This is what I was suggesting, what do you think?
Eh, eh, certainly I don't have anything to say from the correctness 
point of view. As I already tried to explain, what I find annoying in 
this kind of approach, no matter how well is implemented, is that at 
parsing time we have to go anyway over all the parameters of all the 
template lists and then we know once and for all, for the corresponding 
class, whether there are erroneous parameters or not. In this kind of 
approach we go again through all the parameters, and, for example, 
multiple times when there are nested classes for example, I'm pretty 
sure in some (other) cases too (I should think more about that to be 
more specific). If you ask my opinion, at the moment I still believe 
that the best solution would be doing something at parsing time, save 
the information, in a more elegant way, maybe adding a special 
"erroneous TREE_VEC" flag to the TREE_VECs. I don't know exactly. Even 
better a unique flag for all the template parameter lists of each class. 
That said, if you don't foresee immediate performance-related issues, 
it's of course your call ;) If/when I will have a more concrete 
alternate proposal I will speak up ;) Nice anyway that we agree about 
the basic idea :-)


Paolo.

[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

Re: [C++ Patch/RFC] PR 71169 ("[7/8 Regression] ICE on invalid C++ code in pop_nested_class"), PR 71832 and more

[Jason Merrill]

On Wed, Mar 7, 2018 at 12:18 PM, Paolo Carlini  wrote:
> Hi,
>
> [snip the various clarifications]
>
> Il 7 Marzo 2018 17:57:07 CET, Jason Merrill  ha scritto:
>>My thought was that this patch adds a lot of managing of the flag in
>>different places in the parser, whereas looking for error_mark_node in
>>the template parms here would be just in one place.  But if you prefer
>>the current approach, that's fine, it's straightforward enough.
>
> Thanks a lot for the various clarifications above, where essentially turns 
> out that some details of my patch are correct essentially by chance ;) 
> Seriously, I'm thinking the following: since 8 is getting real close, what 
> if, for 8, for the known mild regressions, we go ahead with my super safe 
> Plan B which I mentioned at beginning of the thread, then as soon as trunk 
> branches we immediately apply my patch and we give it a serious spin, say we 
> rebuild distros with it, and see what happens?

This is what I was suggesting, what do you think?
commit 706f372b52e65694161b9dff0272481d23fa898a
Author: Jason Merrill 
Date:   Wed Mar 7 14:45:19 2018 -0500

PR c++/71832 - ICE with ill-formed template parameter.

* pt.c (any_erroneous_template_args_p): New.
* parser.c (cp_parser_class_specifier_1): Use it.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 268be0fd543..8f3ec86e8ce 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6558,6 +6558,7 @@ extern int processing_template_parmlist;
 extern bool dependent_type_p			(tree);
 extern bool dependent_scope_p			(tree);
 extern bool any_dependent_template_arguments_p  (const_tree);
+extern bool any_erroneous_template_args_p	(const_tree);
 extern bool dependent_template_p		(tree);
 extern bool dependent_template_id_p		(tree, tree);
 extern bool type_dependent_expression_p		(tree);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index a19bbe1e1d0..f7a8be50b79 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -22682,6 +22682,8 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   FOR_EACH_VEC_SAFE_ELT (unparsed_funs_with_default_args, ix, e)
 	{
 	  decl = e->decl;
+	  if (any_erroneous_template_args_p (decl))
+	continue;
 	  /* If there are default arguments that have not yet been processed,
 	 take care of them now.  */
 	  if (class_type != e->class_type)
@@ -22704,6 +22706,8 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   save_ccr = current_class_ref;
   FOR_EACH_VEC_SAFE_ELT (unparsed_nsdmis, ix, decl)
 	{
+	  if (any_erroneous_template_args_p (decl))
+	continue;
 	  if (class_type != DECL_CONTEXT (decl))
 	{
 	  if (pushed_scope)
@@ -27642,6 +27646,9 @@ cp_parser_late_parsing_for_member (cp_parser* parser, tree member_function)
   if (DECL_FUNCTION_TEMPLATE_P (member_function))
 member_function = DECL_TEMPLATE_RESULT (member_function);
 
+  if (any_erroneous_template_args_p (member_function))
+return;
+
   /* There should not be any class definitions in progress at this
  point; the bodies of members are only parsed outside of all class
  definitions.  */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 89024c10fe2..1ce04aaabc7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25048,6 +25048,38 @@ any_dependent_template_arguments_p (const_tree args)
   return false;
 }
 
+/* Returns true if ARGS contains any errors.  */
+
+bool
+any_erroneous_template_args_p (const_tree args)
+{
+  int i;
+  int j;
+
+  if (args && TREE_CODE (args) != TREE_VEC)
+{
+  if (tree ti = get_template_info (args))
+	args = TI_ARGS (ti);
+  else
+	args = NULL_TREE;
+}
+
+  if (!args)
+return false;
+  if (args == error_mark_node)
+return true;
+
+  for (i = 0; i < TMPL_ARGS_DEPTH (args); ++i)
+{
+  const_tree level = TMPL_ARGS_LEVEL (args, i + 1);
+  for (j = 0; j < TREE_VEC_LENGTH (level); ++j)
+	if (error_operand_p (TREE_VEC_ELT (level, j)))
+	  return true;
+}
+
+  return false;
+}
+
 /* Returns TRUE if the template TMPL is type-dependent.  */
 
 bool

[PATCH] rs6000: -mreadonly-in-sdata (PR82411)

[Segher Boessenkool]

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).

Tested etc.; committing.


Segher


2018-03-07  Segher Boessenkool  

* 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/
* gcc.target/powerpc/ppc-sdata-2.c: Skip if -mno-readonly-in-sdata.

---
 gcc/config/rs6000/rs6000.c | 5 +
 gcc/config/rs6000/sysv4.opt| 4 
 gcc/doc/invoke.texi| 9 -
 gcc/testsuite/gcc.target/powerpc/ppc-sdata-2.c | 1 +
 4 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index fd96fb8..5cc116f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -32590,6 +32590,11 @@ rs6000_elf_in_small_data_p (const_tree decl)
 }
   else
 {
+  /* If we are told not to put readonly data in sdata, then don't.  */
+  if (TREE_READONLY (decl) && rs6000_sdata != SDATA_EABI
+ && !rs6000_readonly_in_sdata)
+   return false;
+
   HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (decl));
 
   if (size > 0
diff --git a/gcc/config/rs6000/sysv4.opt b/gcc/config/rs6000/sysv4.opt
index 9534c1c..fb03c0a 100644
--- a/gcc/config/rs6000/sysv4.opt
+++ b/gcc/config/rs6000/sysv4.opt
@@ -27,6 +27,10 @@ msdata=
 Target RejectNegative Joined Var(rs6000_sdata_name)
 Select method for sdata handling.
 
+mreadonly-in-sdata
+Target Report Var(rs6000_readonly_in_sdata) Init(1) Save
+Allow readonly data in sdata.
+
 mtls-size=
 Target RejectNegative Joined Var(rs6000_tls_size) Enum(rs6000_tls_size)
 Specify bit size of immediate TLS offsets.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 82db9d6..ac5a198 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1085,7 +1085,7 @@ See RS/6000 and PowerPC Options.
 -mdlmzb  -mno-dlmzb @gol
 -mprototype  -mno-prototype @gol
 -msim  -mmvme  -mads  -myellowknife  -memb  -msdata @gol
--msdata=@var{opt}  -mvxworks  -G @var{num} @gol
+-msdata=@var{opt}  -mreadonly-in-sdata  -mvxworks  -G @var{num} @gol
 -mrecip  -mrecip=@var{opt}  -mno-recip  -mrecip-precision @gol
 -mno-recip-precision @gol
 -mveclibabi=@var{type}  -mfriz  -mno-friz @gol
@@ -24081,6 +24081,13 @@ On embedded PowerPC systems, put all initialized 
global and static data
 in the @code{.data} section, and all uninitialized data in the
 @code{.bss} section.
 
+@item -mreadonly-in-sdata
+@itemx -mreadonly-in-sdata
+@opindex mreadonly-in-sdata
+@opindex mno-readonly-in-sdata
+Put read-only objects in the @code{.sdata} section as well.  This is the
+default.
+
 @item -mblock-move-inline-limit=@var{num}
 @opindex mblock-move-inline-limit
 Inline all block moves (such as calls to @code{memcpy} or structure
diff --git a/gcc/testsuite/gcc.target/powerpc/ppc-sdata-2.c 
b/gcc/testsuite/gcc.target/powerpc/ppc-sdata-2.c
index 570c81f..ee77456 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc-sdata-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/ppc-sdata-2.c
@@ -5,6 +5,7 @@
 /* { dg-final { scan-assembler-not "\\.section\[ \t\]\\.sdata2," } } */
 /* { dg-final { scan-assembler "sdat@sdarel\\(13\\)" } } */
 /* { dg-final { scan-assembler "sdat2@sdarel\\(13\\)" } } */
+/* { dg-skip-if "" { *-*-* } { "-mno-readonly-in-sdata" } { "" } } */
 
 
 int sdat = 2;
-- 
1.8.3.1

[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

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Jeff Law]

On 02/21/2018 03:11 AM, Alexandre Oliva wrote:
> On Feb 15, 2018, Szabolcs Nagy  wrote:
> 
>> i see assembler slow downs with these location view patches
>> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
> 
> 
> [LVU] reset view at function entry, omit views at line zero
> 
> Location views might be associated with locations that lack line
> number information (line number zero), but since we omit .loc
> directives that would have been issued with line number zero, we also
> omit the symbolic view numbers that would have been issued at such
> points.
> 
> Resetting views at function entry points address some of these issues,
> and alleviate the huge chains of symbolic views that have burdened
> assemblers since we disabled -ginternal-reset-location-views by
> default, but other problems of undefined views remain when it's not
> the whole function that lacks line number info, just parts of it.
> 
> So, when we encounter a request to output a view that may have been
> referenced, but we decide to omit the .loc because the line is zero,
> we will now omit the view as well, i.e., we will internally regard
> that view as zero-numbered.
> 
> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok to install?
> 
> Uros, could you please confirm whether this fixes the 84404 go problem
> you reported on alpha?  I'm guessing it's the same issue.  TIA,
> 
> for  gcc/ChangeLog
> 
>   PR debug/84404
>   PR debug/84408
>   * dwarf2out.c (struct dw_line_info_table): Update comments for
>   view == -1.
>   (FORCE_RESET_NEXT_VIEW): New.
>   (FORCE_RESETTING_VIEW_P): New.
>   (RESETTING_VIEW_P): Check for -1 too.
>   (ZERO_VIEW_P): Likewise.
>   (new_line_info_table): Force-reset next view.
>   (dwarf2out_begin_function): Likewise.
>   (dwarf2out_source_line): Simplify zero_view_p initialization.
>   Test FORCE_RESETTING_VIEW_P and RESETTING_VIEW_P instead of
>   view directly.  Omit view when omitting .loc at line 0.
> 
> for  gcc/testsuite/ChangeLog
> 
>   PR debug/84404
>   PR debug/84408
>   * gcc.dg/graphite/pr84404.c: New.
OK.

jeff

[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"
}

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Jeff Law]

On 02/26/2018 10:32 AM, Martin Sebor wrote:
> 
> PR tree-optimization/84526 - ICE in generic_overlap at 
> gcc/gimple-ssa-warn-restrict.c:927 since r257860
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/84526
>   * gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
>   Remove dead code.
>   (builtin_access::generic_overlap): Be prepared to handle non-array
>   base objects.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/84526
>   * gcc.dg/Wrestrict-10.c: New test.
> 
> Index: gcc/gimple-ssa-warn-restrict.c
> ===
> --- gcc/gimple-ssa-warn-restrict.c(revision 257963)
> +++ gcc/gimple-ssa-warn-restrict.c(working copy)
> @@ -396,6 +396,9 @@ builtin_memref::set_base_and_offset (tree expr)
>if (TREE_CODE (expr) == ADDR_EXPR)
>  expr = TREE_OPERAND (expr, 0);
>  
> +  /* Stash the reference for offset validation.  */
> +  ref = expr;
> +
>poly_int64 bitsize, bitpos;
>tree var_off;
>machine_mode mode;
> @@ -409,23 +412,33 @@ builtin_memref::set_base_and_offset (tree expr)
>base = get_inner_reference (expr, , , _off,
> , , , );
>  
> +  /* get_inner_reference is not expected to return null.  */
> +  gcc_assert (base != NULL);
> +
>poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
>  
> -  HOST_WIDE_INT const_off;
> -  if (!base || !bytepos.is_constant (_off))
> +  /* Convert the poly_int64 offset to to offset_int.  The offset
> + should be constant but be prepared for it not to be just in
> + case.  */
> +  offset_int cstoff;
> +  if (bytepos.is_constant ())
>  {
> -  base = get_base_address (TREE_OPERAND (expr, 0));
> -  return;
> +  offrange[0] += cstoff;
> +  offrange[1] += cstoff;
> +
> +  /* Besides the reference saved above, also stash the offset
> +  for validation.  */
> +  if (TREE_CODE (expr) == COMPONENT_REF)
> + refoff = cstoff;
>  }
> +  else
> +offrange[1] += maxobjsize;
So is this assignment to offrange[1] really correct?

ISTM that it potentially overflows (relative to MAXOBJSIZE) and that
you'd likely be better off just assigning offrange[1] to MAXOBJSIZE.

Or alternately signal to the callers that we can't really analyze the
memory address and inhibit further analysis of the potential overlap of
the objects.

> @@ -918,12 +924,18 @@ builtin_access::generic_overlap ()
>if (!overlap_certain)
>  {
>if (!dstref->strbounded_p && !depends_p)
> + /* Memcpy only considers certain overlap.  */
>   return false;
>  
>/* There's no way to distinguish an access to the same member
>of a structure from one to two distinct members of the same
>structure.  Give up to avoid excessive false positives.  */
> -  tree basetype = TREE_TYPE (TREE_TYPE (dstref->base));
> +  tree basetype = TREE_TYPE (dstref->base);
> +
> +  if (POINTER_TYPE_P (basetype)
> +   || TREE_CODE (basetype) == ARRAY_TYPE)
> + basetype = TREE_TYPE (basetype);
> +
>if (RECORD_OR_UNION_TYPE_P (basetype))
>   return false;
>  }
This is probably fairly reasonable.  My only concern would be that we
handle multi-dimensional arrays correctly.  Do you need to handle
ARRAY_TYPEs with a loop?

I do have a more general concern.  Given that we walk backwards through
pointer casts and ADDR_EXPRs we potentially lose information.  For
example we might walk backwards through a cast from a small array to a
larger array type.

Thus later we use the smaller array type when computing the bounds and
subsequent offset from BASE.  This could lead to a missed warning as the
computed offset would be too small.

I'm inclined to ack after fixing offrange[1] computation noted above as
I don't think the patch makes things any worse.  As I noted in a prior
message, I don't see concerns with consistency of BASE that Jakub sees here.

jeff

[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.

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Jeff Law]

On 02/23/2018 02:46 PM, Martin Sebor wrote:
>> This doesn't address any of my concerns that it is completely random
>> what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
>> (e.g. the argument of the function), sometimes the ADDR_EXPR operand,
>> sometimes the base of the reference, sometimes again address (if the
>> base of the reference is MEM_REF).  By the lack of consistency in what
>> it is, just deciding on its type whether you take TREE_TYPE or
>> TREE_TYPE (TREE_TYPE ()) of it also gives useless result.  You could e.g
>> call the memcpy etc. function with ADDR_EXPR of a VAR_DECL that has
>> pointer
>> type, then if dstref->base is that VAR_DECL, POINTER_TYPE_P (basetype)
>> would be true.
> 
> I think I understand what you're saying but this block is only
> used for string functions (not for memcpy), and only as a stopgap
> to avoid false positives.  Being limited to (a subset of) string
> functions the case I think you're concerned about, namely calling
> strcpy with a pointer to a pointer, shouldn't come up in valid
> code.  It's not bullet-proof but I don't think there is
> a fundamental problem, either with this patch or with the one
> that introduced it.  The fundamental problem is that MEM_REF
> can be ambiguous and that's what this code is trying to combat.
> See the example I gave here:
> https://gcc.gnu.org/ml/gcc/2018-02/msg00136.html
> 
> If you think I'm missing something please put together a small
> test case to help me see the problem.  I'm not nearly as
> comfortable thinking in terms of the internal representation
> to visualize all the possibilities here.
I think at least part of the issue here was that previously you had this
code in set_base_and_offset:

 HOST_WIDE_INT const_off;
  if (!base || !bytepos.is_constant (_off))
{
  base = get_base_address (TREE_OPERAND (expr, 0));
  return;
}

That is stripping away part of EXPR in a way I don't think was safe.
With this gone in the most recent patches I'm a lot less concerned.

Jeff

[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.

Re: [PATCH] Add a few new contrib.texi entries, especially for people who perform GCC fuzzy testing and report bugs (take 2)

[Volker Reichelt]

On 03/07/2018 03:24 PM, Jakub Jelinek wrote:


On Wed, Mar 07, 2018 at 02:06:33PM +0100, Jakub Jelinek wrote:

As appreciation of the hard work of people doing fuzzy testing of
GCC and reporting high quality bugs, I'd like to list them in contrib.texi.
This patch just lists them in the GCC testing group, shall we have a special
sub-list for the fuzzy testing?
The patch also adds or updates a couple of other entries, but I'm sure I've
missed many people in both the testing and GCC development categories, for
which I apologize.  We can always have incremental patches, contrib.texi
is helplessly obsolete anyway and for many doesn't reflect last 10-15 years
of work at all.  We should also add entries for people reporting lots of
bugs even if it is not from fuzzy testing.

Anyway, ok for trunk?  Are all people on the CC ok with them being listed in
there (reply privately if needed)?




Thanks Jakub, for the appreciation!

My way of saying thank you, is (of course) to file an new 
ice-on-valid-code regression:

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

Thanks again,
Volker

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Jeff Law]

On 02/23/2018 01:13 PM, Jakub Jelinek wrote:
> On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
>> +  /* get_inner_reference is not expected to return null.  */
>> +  gcc_assert (base != NULL);
>> +
>>poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
>>  
>> -  HOST_WIDE_INT const_off;
>> -  if (!base || !bytepos.is_constant (_off))
>> -{
>> -  base = get_base_address (TREE_OPERAND (expr, 0));
>> -  return;
>> -}
>> -
>> +  /* There is no conversion from poly_int64 to offset_int even
>> + though the latter is wider, so go through HOST_WIDE_INT.
>> + The offset is expected to always be constant.  */
>> +  HOST_WIDE_INT const_off = bytepos.to_constant ();
> 
> The assert is ok, but removing the bytepos.is_constant (_off)
> is wrong, I'm sure Richard S. can come up with some SVE testcase
> where it will not be constant.  If it is not constant, you can handle
> it like var_off (which as I said on IRC or in the PR also seems to be
> incorrect, because if the base is not a decl the variable offset could be
> negative).
> 
>>offrange[0] += const_off;
>>offrange[1] += const_off;
>>  
>> @@ -923,7 +923,11 @@ builtin_access::generic_overlap ()
>>/* There's no way to distinguish an access to the same member
>>   of a structure from one to two distinct members of the same
>>   structure.  Give up to avoid excessive false positives.  */
>> -  tree basetype = TREE_TYPE (TREE_TYPE (dstref->base));
>> +  tree basetype = TREE_TYPE (dstref->base);
>> +  if (POINTER_TYPE_P (basetype)
>> +  || TREE_CODE (basetype) == ARRAY_TYPE)
>> +basetype = TREE_TYPE (basetype);
> 
> This doesn't address any of my concerns that it is completely random
> what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
> (e.g. the argument of the function), sometimes the ADDR_EXPR operand,
> sometimes the base of the reference, sometimes again address (if the
> base of the reference is MEM_REF).  By the lack of consistency in what
> it is, just deciding on its type whether you take TREE_TYPE or
> TREE_TYPE (TREE_TYPE ()) of it also gives useless result.  You could e.g
> call the memcpy etc. function with ADDR_EXPR of a VAR_DECL that has pointer
> type, then if dstref->base is that VAR_DECL, POINTER_TYPE_P (basetype)
> would be true.
The intent of the code is that BASE is a pointer to a memory location
that can be compared to another BASE for the purposes of trying to
determine if there's an overlap between two arguments.

Note that BASE may have a different type than what actually appeared in
the call.  Martin's code is presented with the actual argument, but then
tries to walk backwards to refine that value.  In particular it might
look through pointer typecasts or pointer arithmetic.  The latter
results in a memory address plus an offset.

It may also look at an ADDR_EXPR and strip away its various _REF nodes.
The result in this case is similar to pointer arithmetic in that we will
have a memory address plus an offset.

Note that the memory address computed in here and stored into BASE may
differ in its type from what is actually passed to the function for
which we are checking for invalid argument overlap.  In fact, I think

The key here is boil arguments down to a memory location plus an
optional offset, which in turn allows us to compare them against each
other for overlap.  In some ways it's like what we do in alias.c for RTL
(which isn't necessary a shining example of good code).

I don't think the lack of consistency is really a major issue inside
builtin_memref::set_base_and_offset -- as long as clients use the
information just for warnings and are aware that the underlying types
may differ from what appeared in the call itself.

Removal of the undesirable base = get_base_address (TREE_OPERAND (expr,
0)) definitely helps clarify IMHO.

I'll have more comments as a follow-up to one of Martin's messages.

Jeff

[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).

[PATCH 2/2] ifcvt: unfixed testcase for 2nd issue within PR tree-optimization/84178

[David Malcolm]

Here's a testcase for the 2nd issue within PR tree-optimization/84178.

With -03 -fno-tree-forwprop, trunk and gcc 7 segfault inside update_ssa
when called from version_loop_for_if_conversion when a loop is versioned.

During loop_version, some blocks are duplicated, and this can duplicate
SSA names, leading to the duplicated SSA names being added to
tree-into-ssa.c's old_ssa_names.

For example, _117 is an SSA name defined in one of these to-be-duplicated
blocks, and hence is added to old_ssa_names when duplicated.

One of the BBs has this gimplified predicate (again, these stmts are *not*
yet in a BB):
  _173 = h4.1_112 != 0;
  _171 = (signed char) _117;
  _172 = _171 >= 0;
  _170 = ~_172;
  _169 = _170 & _173;

Note the reference to SSA name _117 in the above.

When update_ssa runs later on in version_loop_for_if_conversion,
SSA name _117 is in the old_ssa_names bitmap, and thus has
prepare_use_sites_for called on it:

2771  /* If an old name is in NAMES_TO_RELEASE, we cannot remove it from
2772 OLD_SSA_NAMES, but we have to ignore its definition site.  */
2773  EXECUTE_IF_SET_IN_BITMAP (old_ssa_names, 0, i, sbi)
2774{
2775  if (names_to_release == NULL || !bitmap_bit_p (names_to_release, 
i))
2776prepare_def_site_for (ssa_name (i), insert_phi_p);
2777  prepare_use_sites_for (ssa_name (i), insert_phi_p);
2778}

prepare_use_sites_for iterates over the immediate users, which includes
the:
  _171 = (signed char) _117;
in the gimplified predicate.

This tried to call "mark_block_for_update" on the BB of this def_stmt,
leading to a read-through-NULL segfault, since this statement isn't in a
BB yet.

In an earlier attempt to fix this I wrote:
> The following patch fixes the 2nd ICE by inserting the gimplified predicates
> earlier: immediately before the possible version_loop_for_if_conversion,
> rather than within combine_blocks.  That way they're in their BBs before
> we attempt any further manipulation of the CFG.

to which Richard responded:
> Hum, but that will alter both copies of the loops, no?  I think the fix is
> to instead delay the update_ssa call to _after_ combine_blocks ()
> (and remember if it is necessary just in case we didn't version).

I attempted this, but didn't come up with something that worked; so am
posting this in the hope that Richard (or someone else) can finish the
fix.

gcc/testsuite/ChangeLog:
PR tree-optimization/84178
* gcc.c-torture/compile/pr84178-2.c: New test.
---
 gcc/testsuite/gcc.c-torture/compile/pr84178-2.c | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr84178-2.c

diff --git a/gcc/testsuite/gcc.c-torture/compile/pr84178-2.c 
b/gcc/testsuite/gcc.c-torture/compile/pr84178-2.c
new file mode 100644
index 000..b2548e9
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr84178-2.c
@@ -0,0 +1,18 @@
+/* { dg-options "-fno-tree-forwprop" } */
+
+int zy, h4;
+
+void
+r8 (long int mu, int *jr, int *fi, short int dv)
+{
+  do
+{
+  int tx;
+
+  tx = !!h4 ? (zy + h4) : 1;
+  mu = tx;
+  *jr = (((unsigned char) mu > (254 >> dv)) ? 0 : (unsigned char) tx) + 
*fi;
+} while (*jr == 0);
+
+  r8 (mu, jr, fi, 1);
+}
-- 
1.8.5.3

[PATCH 1/2] tree-if-conv.c: fix ICE seen with -fno-tree-forwprop (PR tree-optimization/84178)

[David Malcolm]

PR tree-optimization/84178 reports a couple of source files that ICE inside
ifcvt when compiled with -03 -fno-tree-forwprop (trunk and gcc 7).

Both cases involve problems with ifcvt's per-BB gimplified predicates.

Testcase 1 fails this assertion within release_bb_predicate during cleanup:

283   if (flag_checking)
284 for (gimple_stmt_iterator i = gsi_start (stmts);
285  !gsi_end_p (i); gsi_next ())
286   gcc_assert (! gimple_use_ops (gsi_stmt (i)));

The testcase contains a division in the loop, which leads to
if_convertible_loop_p returning false (due to gimple_could_trap_p being true
for the division).  This happens *after* the per-BB gimplified predicates
have been created in predicate_bbs (loop).
Hence tree_if_conversion bails out to "cleanup", but the gimplified predicates
exist and make use of SSA names; for example this conjunction for two BB
conditions:

  _4 = h4.1_112 != 0;
  _175 = (signed char) _117;
  _176 = _175 >= 0;
  _174 = _4 & _176;

is using SSA names.

This assertion was added in r236498 (aka 
c3deca2519d97c55876869c57cf11ae1e5c6cf8b):

2016-05-20  Richard Biener  

* tree-if-conv.c (add_bb_predicate_gimplified_stmts): Use
gimple_seq_add_seq_without_update.
(release_bb_predicate): Assert we have no operands to free.
(if_convertible_loop_p_1): Calculate post dominators later.
Do not free BB predicates here.
(combine_blocks): Do not recompute BB predicates.
(version_loop_for_if_conversion): Save BB predicates around
loop versioning.

* gcc.dg/tree-ssa/ifc-cd.c: Adjust.

The following patch fixes this by adding a call to gimple_seq_discard
to release_bb_predicate.  It also updates the assertion, so that
instead of asserting the stmts have no imm uses, instead assert that
they weren't added to a bb before discarding them (otherwise discarding
them would be a bug).  We know this is the case because
insert_gimplified_predicates has:

  /* Once the sequence is code generated, set it to NULL.  */
  set_bb_predicate_gimplified_stmts (bb, NULL);

but asserting it seems appropriate as a double-check.

The patch doesn't address the 2nd issue within PR tree-optimization/84178.

Successfully bootstrapped on x86_64-pc-linux-gnu.

OK for trunk?

gcc/ChangeLog:
PR tree-optimization/84178
* tree-if-conv.c (release_bb_predicate): Remove the
the assertion that the stmts have NULL use_ops.
Discard the statements, asserting that they haven't
yet been added to a BB.

gcc/testsuite/ChangeLog:
PR tree-optimization/84178
* gcc.c-torture/compile/pr84178-1.c: New test.
---
 gcc/testsuite/gcc.c-torture/compile/pr84178-1.c | 18 ++
 gcc/tree-if-conv.c  |  8 +---
 2 files changed, 23 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr84178-1.c

diff --git a/gcc/testsuite/gcc.c-torture/compile/pr84178-1.c 
b/gcc/testsuite/gcc.c-torture/compile/pr84178-1.c
new file mode 100644
index 000..49f2c89
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr84178-1.c
@@ -0,0 +1,18 @@
+/* { dg-options "-fno-tree-forwprop" } */
+
+int zy, h4;
+
+void
+r8 (long int mu, int *jr, int *fi, short int dv)
+{
+  do
+{
+  int tx;
+
+  tx = !!h4 ? (zy / h4) : 1;
+  mu = tx;
+  *jr = (((unsigned char) mu > (254 >> dv)) ? 0 : (unsigned char) tx) + 
*fi;
+} while (*jr == 0);
+
+  r8 (mu, jr, fi, 1);
+}
diff --git a/gcc/tree-if-conv.c b/gcc/tree-if-conv.c
index cac3fd7..5467f3f 100644
--- a/gcc/tree-if-conv.c
+++ b/gcc/tree-if-conv.c
@@ -271,8 +271,7 @@ init_bb_predicate (basic_block bb)
   set_bb_predicate (bb, boolean_true_node);
 }
 
-/* Release the SSA_NAMEs associated with the predicate of basic block BB,
-   but don't actually free it.  */
+/* Release the SSA_NAMEs associated with the predicate of basic block BB.  */
 
 static inline void
 release_bb_predicate (basic_block bb)
@@ -280,11 +279,14 @@ release_bb_predicate (basic_block bb)
   gimple_seq stmts = bb_predicate_gimplified_stmts (bb);
   if (stmts)
 {
+  /* Ensure that these stmts haven't yet been added to a bb.  */
   if (flag_checking)
for (gimple_stmt_iterator i = gsi_start (stmts);
 !gsi_end_p (i); gsi_next ())
- gcc_assert (! gimple_use_ops (gsi_stmt (i)));
+ gcc_assert (! gimple_bb (gsi_stmt (i)));
 
+  /* Discard them.  */
+  gimple_seq_discard (stmts);
   set_bb_predicate_gimplified_stmts (bb, NULL);
 }
 }
-- 
1.8.5.3

Re: [PATCH/RFC] tree-if-conv.c: fix two ICEs seen with -fno-tree-forwprop (PR tree-optimization/84178)

[David Malcolm]

On Fri, 2018-02-16 at 12:48 +0100, Richard Biener wrote:
> On Thu, Feb 15, 2018 at 11:07 PM, David Malcolm 
> wrote:
> > On Fri, 2018-02-09 at 12:02 +0100, Richard Biener wrote:
> > > On Thu, Feb 8, 2018 at 11:23 PM, David Malcolm  > > om>
> > > wrote:
> > > > PR tree-optimization/84178 reports a couple of source files
> > > > that
> > > > ICE inside
> > > > ifcvt when compiled with -03 -fno-tree-forwprop (trunk and gcc
> > > > 7).
> > > > 
> > > > Both cases involve problems with ifcvt's per-BB gimplified
> > > > predicates.
> > > > 
> > > > Testcase 1 fails this assertion within release_bb_predicate
> > > > during
> > > > cleanup:
> > > > 
> > > > 283   if (flag_checking)
> > > > 284 for (gimple_stmt_iterator i = gsi_start
> > > > (stmts);
> > > > 285  !gsi_end_p (i); gsi_next ())
> > > > 286   gcc_assert (! gimple_use_ops (gsi_stmt (i)));
> > > > 
> > > > The testcase contains a division in the loop, which leads to
> > > > if_convertible_loop_p returning false (due to
> > > > gimple_could_trap_p
> > > > being true
> > > > for the division).  This happens *after* the per-BB gimplified
> > > > predicates
> > > > have been created in predicate_bbs (loop).
> > > > Hence tree_if_conversion bails out to "cleanup", but the
> > > > gimplified
> > > > predicates
> > > > exist and make use of SSA names; for example this conjunction
> > > > for
> > > > two BB
> > > > conditions:
> > > > 
> > > >   _4 = h4.1_112 != 0;
> > > >   _175 = (signed char) _117;
> > > >   _176 = _175 >= 0;
> > > >   _174 = _4 & _176;
> > > > 
> > > > is using SSA names.
> > > 
> > > But then this shouldn't cause any stmt operands to be created -
> > > who
> > > is calling
> > > update_stmt () on a stmt using the SSA names?  Maybe something
> > > calls
> > > force_gimple_operand_gsi to add to the sequence?
> > 
> > 
> > The immediate use is created deep within folding when the
> > gimplified
> > predicate is created.
> > 
> > Here's the backtrace of exactly where:
> > 
> > (gdb) bt
> > #0  link_imm_use_stmt (linknode=0x71a0b8d0, def= > 0x71a196c0>, stmt=)
> > at ../../src/gcc/ssa-iterators.h:307
> > #1  0x012531c5 in add_use_op (fn=0x71a03000,
> > stmt=, op=0x71a236d8,
> > last=0x7fffcb10) at ../../src/gcc/tree-ssa-operands.c:307
> > #2  0x01253607 in finalize_ssa_uses (fn=0x71a03000,
> > stmt=)
> > at ../../src/gcc/tree-ssa-operands.c:410
> > #3  0x0125368b in finalize_ssa_stmt_operands
> > (fn=0x71a03000, stmt=)
> > at ../../src/gcc/tree-ssa-operands.c:436
> > #4  0x01254b62 in build_ssa_operands (fn=0x71a03000,
> > stmt=)
> > at ../../src/gcc/tree-ssa-operands.c:948
> > #5  0x012550df in update_stmt_operands (fn=0x71a03000,
> > stmt=)
> > at ../../src/gcc/tree-ssa-operands.c:1081
> > #6  0x00c10642 in update_stmt_if_modified (s= > 0x71a23690>) at ../../src/gcc/gimple-ssa.h:185
> > #7  0x00c10e82 in update_modified_stmts
> > (seq=0x71a23690) at ../../src/gcc/gimple-iterator.c:58
> > #8  0x00c111f1 in gsi_insert_seq_before (i=0x7fffcfb0,
> > seq=0x71a23690, mode=GSI_SAME_STMT)
> > at ../../src/gcc/gimple-iterator.c:217
> > #9  0x00c241d0 in replace_stmt_with_simplification
> > (gsi=0x7fffcfb0, rcode=..., ops=0x7fffcdb0,
> > seq=0x7fffcdd8, inplace=false) at ../../src/gcc/gimple-
> > fold.c:4473
> > #10 0x00c25a63 in fold_stmt_1 (gsi=0x7fffcfb0,
> > inplace=false, valueize=0xc2663b )
> > at ../../src/gcc/gimple-fold.c:4775
> > #11 0x00c266b7 in fold_stmt (gsi=0x7fffcfb0) at
> > ../../src/gcc/gimple-fold.c:4996
> > #12 0x00c552b1 in maybe_fold_stmt (gsi=0x7fffcfb0) at
> > ../../src/gcc/gimplify.c:3193
> > #13 0x00c5f1e9 in gimplify_modify_expr
> > (expr_p=0x7fffd328, pre_p=0x7fffd910,
> > post_p=0x7fffd1e0,
> > want_value=false) at ../../src/gcc/gimplify.c:5803
> > #14 0x00c7b461 in gimplify_expr (expr_p=0x7fffd328,
> > pre_p=0x7fffd910, post_p=0x7fffd1e0,
> > gimple_test_f=0xc5d723 , fallback=0) at
> > ../../src/gcc/gimplify.c:11434
> > #15 0x00c62661 in gimplify_stmt (stmt_p=0x7fffd328,
> > seq_p=0x7fffd910) at ../../src/gcc/gimplify.c:6658
> > #16 0x00c4c449 in gimplify_and_add (t= > 0x71a26230>, seq_p=0x7fffd910) at
> > ../../src/gcc/gimplify.c:441
> > #17 0x00c4cc89 in internal_get_tmp_var (val= > 0x71a26140>, pre_p=0x7fffd910, post_p=0x0, is_formal=true,
> > allow_ssa=true) at ../../src/gcc/gimplify.c:597
> > #18 0x00c4ccd2 in get_formal_tmp_var (val= > 0x71a26140>, pre_p=0x7fffd910) at
> > ../../src/gcc/gimplify.c:618
> > #19 0x00c7ee6a in gimplify_expr (expr_p=0x71a261b0,
> > pre_p=0x7fffd910, post_p=0x7fffd790,
> > gimple_test_f=0xc0f6d0 

[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.

Re: [PING] [PATCH] consider successor blocks when avoiding -Wstringop-truncation (PR 84468)

[Jeff Law]

On 03/01/2018 02:17 PM, Martin Sebor wrote:
> 
> I read you last reply as asking me to handle multiple edges.
Sorry, I should have been clearer.

You need to be prepared for the possibility of multiple edges and handle
them in a conservatively correct way.  The most likely way to get
multiple outgoing edges is going to be via exception handling.

In this code I think that's easily accomplished by making the code which
walks into the successor block(s) conditional on single_succ_p (bb) and
that the edge is not marked as EDGE_ABNORMAL.

> The original patch handled just one edge and didn't bother
> with EDGE_ABNORMAL because I wanted to keep it simple.
Understood.  But that's not safe in the sense that once you have
multiple successors, you don't know which one you will transfer control
to -- thus you have to check all of them for a suitable store.  If any
doesn't have a suitable store, then you'd have to warn.

Essentially the question you need to answer is "given I'm in block X, do
all paths from block X have a suitable store to terminate the string
prior to a use".  You can handle that in the trivial case with the code
you're proposing in this patch, and that's fine for gcc-8.

But the "right" way to answer that question is to look at the virtual
operand chains.  Though as we've discussed that may not necessarily be a
good thing.





  But
> it sounds like you want me to go back to the first version
> and just add a check for EDGE_ABNORMAL.  The attached patch
> does that (plus it skips over any non-debug statements in
> the successor block). 
Correct.  I think your original patch with a check for single_succ_p is
the direction I think we want for gcc-8.



 Besides the usual I retested it with
> the Linux kernel.  There are just three instances of
> the warning in my default configuration but I know there
> are a lot more in more extensive builds.
I've actually got a fair amount of data here on kernel builds using the
trunk on a variety of architectures.  I haven't gone through it all yet,
but there's certainly some string-op truncation warnings and a few
others.  I haven't figured out how best to aggregate that info and I
don't want to duplicate Arnd's work.




> 
> 
>> I glanced over the tests and I didn't see any that would benefit from
>> handling multiple edges or the recursion (every one of the dg-bogus
>> markers should be immediately transferring control to the null
>> termination statement AFAICT).
> 
> I've added some more test cases involving C++ exceptions (and
> found one false positive(*)) but I don't have a test to exercise
> blocks with multiple outgoing edges.  For future reference, how
> would I create one?
EH is the best bet to create them.  You might also be able to get one if
we've got fake edges in the CFG (necessary for things like
post-dominator computation).  async exceptions could likely create them
fairly easily.


My comment was more about not seeing the need to look into successor
blocks if there's more than one.


Can you file a bug report on the false positive so that we have a
reminder to revisit looking at the virtual operand chains as a better
solution here?

I think this version is OK.

Thanks, and again sorry for the confusion.


Jeff

[PATCH][AArch64] PR target/84748: Mark *compare_cstore_insn as clobbering CC reg

[Kyrill Tkachov]

Hi all,

In this wrong-code PR the combine pass ends up moving a CC-using instruction past a 
*compare_cstore_insn
insn_and_split. After reload the *compare_cstore_insn splitter ends up 
generating a SUBS instruction that
clobbers the condition flags, and things go bad.

The solution is simple, the *compare_cstore_insn pattern should specify 
that it clobbers the CC register
so that combine (or any other pass) does not assume that it can move CC-using 
patterns across it.

This patch does that and fixes the testcase.

The testcase FAILs on GCC 8 only, but the buggy pattern is in GCC 6 onwards, so 
we should backport this as
a latent bug fix after it's had some time to bake in trunk.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk and later backports?

Thanks,
Kyrill

2018-03-07  Kyrylo Tkachov  

PR target/84748
* config/aarch64/aarch64.md (*compare_cstore_insn): Mark pattern
as clobbering CC_REGNUM.

2018-03-07  Kyrylo Tkachov  

PR target/84748
* gcc.c-torture/execute/pr84748.c: New test.
commit 9c008e450e1cd95f2905071e6c8a0ff92b856358
Author: Kyrylo Tkachov 
Date:   Wed Mar 7 15:05:25 2018 +

[AArch64] PR target/84748: Mark *compare_cstore_insn as clobbering CC reg

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 69ff5ca..4463a13 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -3242,7 +3242,8 @@ (define_insn "aarch64_cstore"
 (define_insn_and_split "*compare_cstore_insn"
   [(set (match_operand:GPI 0 "register_operand" "=r")
 	 (EQL:GPI (match_operand:GPI 1 "register_operand" "r")
-		  (match_operand:GPI 2 "aarch64_imm24" "n")))]
+		  (match_operand:GPI 2 "aarch64_imm24" "n")))
+   (clobber (reg:CC CC_REGNUM))]
   "!aarch64_move_imm (INTVAL (operands[2]), mode)
&& !aarch64_plus_operand (operands[2], mode)
&& !reload_completed"
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr84748.c b/gcc/testsuite/gcc.c-torture/execute/pr84748.c
new file mode 100644
index 000..9572ab2
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr84748.c
@@ -0,0 +1,34 @@
+/* { dg-require-effective-target int128 } */
+
+typedef unsigned __int128 u128;
+
+int a, c, d;
+u128 b;
+
+unsigned long long g0, g1;
+
+void
+store (unsigned long long a0, unsigned long long a1)
+{
+  g0 = a0;
+  g1 = a1;
+}
+
+void
+foo (void)
+{
+  b += a;
+  c = d != 84347;
+  b /= c;
+  u128 x = b;
+  store (x >> 0, x >> 64);
+}
+
+int
+main (void)
+{
+  foo ();
+  if (g0 != 0 || g1 != 0)
+__builtin_abort ();
+  return 0;
+}