[Bug gcov-profile/78783] gcov-tool fails in gcov_read_counter_mem

[wangvisual at sohu dot com]

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

Opera Wang  changed:

   What|Removed |Added

 CC||wangvisual at sohu dot com

--- Comment #2 from Opera Wang  ---
We have similar issues in our environment, and I found two situations can
trigger it.

1. When profile2 have more files than profile1, which is fixed in bug 67097

2. When nftw has issues and can't remove all gcda files in output dir.

in gcov-tool.c, unlink_profile_dir:
return nftw(path, unlink_gcda_file, 64, FTW_DEPTH | FTW_PHYS);

then later when call dump_one_gcov:
tag = gcov_read_unsigned ();
if (tag) // <= here tag would be valid because some gcda files still exist
in output dir

nftw is in libc, and on machine1:
ldd (GNU libc) 2.12, Linux 2.6.32-220.el6.x86_64, RedHat Enterprise Linux 6.2
nftw can't remove all gcda files, but if I call nftw the 2nd time, then the
left gcda files will be removed, so it's not a permission issue.

but on machine2:
ldd (GNU libc) 2.5, Linux 2.6.18-371.9.1.el5 x86_64, RedHat Enterprise Linux
5.7
nftw works without any problems.

We have to workaround the 2nd issue by output to a new dir, instead of reuse an
existing dir.

[Bug libfortran/79612] missing space in diagnostic: Incorrect rank of return array in

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
AFAICT This run time error is not covered by the test suite and I don't
understand when it is triggered. Could someone help to write a test?

[Bug fortran/79597] Incomplete error message "Expecting %

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Closing.

[Bug fortran/79601] Possibly wrong use of keyword "intent" in diagnostic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Closing.

[Bug fortran/79601] Possibly wrong use of keyword "intent" in diagnostic

[dominiq at gcc dot gnu.org]

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

--- Comment #2 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Feb 24 23:40:42 2017
New Revision: 245729

URL: https://gcc.gnu.org/viewcvs?rev=245729=gcc=rev
Log:
2017-02-25  Dominique d'Humieres  

PR fortran/79597
* interface.c (gfc_match_end_interface): Remove spurious comma
and space, replace 'got %s' with 'got %qs'.

2017-02-25  Dominique d'Humieres  

PR fortran/79597
* gfortran.dg/dtio_6.f90: Update test.

2017-02-25  Dominique d'Humieres  

PR fortran/79601
* interface.c (check_dtio_arg_TKR_intent): Change 'intent'
to 'INTENT'.

2017-02-25  Dominique d'Humieres  

PR fortran/79601
* gfortran.dg/interface_operator_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/interface_operator_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dtio_6.f90

[Bug fortran/79597] Incomplete error message "Expecting %

[dominiq at gcc dot gnu.org]

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

--- Comment #2 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Feb 24 23:40:42 2017
New Revision: 245729

URL: https://gcc.gnu.org/viewcvs?rev=245729=gcc=rev
Log:
2017-02-25  Dominique d'Humieres  

PR fortran/79597
* interface.c (gfc_match_end_interface): Remove spurious comma
and space, replace 'got %s' with 'got %qs'.

2017-02-25  Dominique d'Humieres  

PR fortran/79597
* gfortran.dg/dtio_6.f90: Update test.

2017-02-25  Dominique d'Humieres  

PR fortran/79601
* interface.c (check_dtio_arg_TKR_intent): Change 'intent'
to 'INTENT'.

2017-02-25  Dominique d'Humieres  

PR fortran/79601
* gfortran.dg/interface_operator_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/interface_operator_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dtio_6.f90

[Bug c/79677] Weird handling of -Werror=

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/79677] Weird handling of -Werror=

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 24 23:15:56 2017
New Revision: 245728

URL: https://gcc.gnu.org/viewcvs?rev=245728=gcc=rev
Log:
PR c/79677
* opts.h (handle_generated_option): Add GENERATED_P argument.
* opts-common.c (handle_option): Adjust function comment.
(handle_generated_option): Add GENERATED_P argument, pass it to
handle_option.
(control_warning_option): Pass false to handle_generated_option
GENERATED_P.
* opts.c (maybe_default_option): Pass true to handle_generated_option
GENERATED_P.
* optc-gen.awk: Likewise.
ada/
* gcc-interface/misc.c (gnat_handle_option): Pass true to
handle_generated_option GENERATED_P.
testsuite/
* gcc.dg/pr79677.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr79677.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/misc.c
trunk/gcc/optc-gen.awk
trunk/gcc/opts-common.c
trunk/gcc/opts.c
trunk/gcc/opts.h
trunk/gcc/testsuite/ChangeLog

[Bug target/79395] Compile error with -mcpu=power9 and __builtin_vec_vcmpne_p

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
(In reply to acsawdey from comment #1)
> * possibly the tests like 3d-01.c should move to gcc.dg/powerpc because
> arguably for -mcpu=power9 we are not testing them fully because of -mno-vsx.

Please leave the test in place, but add new coverage in gcc.target/powerpc for
those built-ins that do have different code generation for ISA 3.0.

[Bug target/79395] Compile error with -mcpu=power9 and __builtin_vec_vcmpne_p

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-24
 Ever confirmed|0   |1

--- Comment #1 from acsawdey at gcc dot gnu.org ---
So, what is going on here is as follows:

Everything in gcc.dg/vmx runs with -mno-vsx. This disables power8-vector which
in turn disables power9-vector. So far so good. If you compile this test case
with -mno-vsx -mcpu=power8 it is fine (no errors) and you get code involving a
vcmpequb, which is ok because it's a legacy altivec instruction.

However with -mno-vsx -mcpu=power9 you get these errors because it's still
trying to use the power9 builtin and then gets farther along and discovers it's
not available because power9 vector is disabled. 

#0  error (gmsgid=0x11e60a68 "Builtin function %s requires the -mcpu=power9
option") at ../../trunk/gcc/diagnostic.c:1308
#1  0x113b9fdc in rs6000_invalid_builtin (fncode=P9V_BUILTIN_VCMPNEB_P)
at ../../trunk/gcc/config/rs6000/rs6000.c:16738
#2  0x113bab58 in rs6000_expand_builtin (exp=0x3fffb5cf4b80,
target=0x0, subtarget=0x0, mode=DImode, ignore=0) at
../../trunk/gcc/config/rs6000/rs6000.c:16945
#3  0x1056f3e0 in expand_builtin (exp=0x3fffb5cf4b80, target=0x0,
subtarget=0x0, mode=DImode, ignore=0) at ../../trunk/gcc/builtins.c:6362

16737 else if ((fnmask & RS6000_BTM_P9_VECTOR) != 0)
16738   error ("Builtin function %s requires the -mcpu=power9 option",
name);

(gdb) p/x rs6000_isa_flags
$2 = 0x206ee1c4d601f
0x10  <-- MASK_P9_VECTOR, not set because of -mno-vsx

I think there are two separate things that ought to be fixed:

* the builtins should work with -mno-vsx -mcpu=power9 just like they did with
-mno-vsx -mcpu=power8
* possibly the tests like 3d-01.c should move to gcc.dg/powerpc because
arguably for -mcpu=power9 we are not testing them fully because of -mno-vsx.

[Bug target/79473] -mload-store-pairs option is not documented in invoke.texi

[mpf at gcc dot gnu.org]

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

--- Comment #1 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Fri Feb 24 22:35:59 2017
New Revision: 245725

URL: https://gcc.gnu.org/viewcvs?rev=245725=gcc=rev
Log:
Add documentation for -mload-store-pairs

gcc/
PR target/79473
* doc/invoke.texi: Document -mload-store-pairs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[mdaniels at qnx dot com]

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

mdaniels at qnx dot com  changed:

   What|Removed |Added

 CC||mdaniels at qnx dot com

--- Comment #15 from mdaniels at qnx dot com  ---
Created attachment 40828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40828=edit
An additional testcase for 5.4.0

I have seen a similar problem on 5.4. I applied this fix, just without the
aarch64_can_use_per_function_literal_pools_p() check, and it seems to do the
trick.

Attached is a test case that can reproduce with 5.4, but it not very good as it
is fragile to optimization changes. For example, git bisect landed me on
42b45e8 as a fix and not this change.

$ aarch64-unknown-linux-gnueabi-g++ -g -O2 -fPIE -fstack-protector-strong -c -o
/tmp/test.o /tmp/test.ii
/tmp/ccWVZeQe.s: Assembler messages:
/tmp/ccWVZeQe.s: Error: unaligned opcodes detected in executable segment

[Bug target/79709] Subobtimal code with -mavx and explicit vector

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-24
 Ever confirmed|0   |1

--- Comment #4 from Marc Glisse  ---
(In reply to Marc Glisse from comment #2)
> In reload, subregs are extracted via the stack, whereas the low subreg
> should already be available (NOP) and the high one can be extracted by a
> single insn. That's probably the first thing to investigate. (-mtune doesn't
> change what happens)

To concentrate on this, with -O3 -mavx :
typedef long int v4i __attribute__((vector_size (32)));
v4i foo(v4i a, v4i b) { return a+b; }

vmovdqa %ymm0, -80(%rbp)
vmovdqa %ymm1, -112(%rbp)
vmovdqa -80(%rbp), %xmm4
vmovdqa -64(%rbp), %xmm6
vpaddq  -112(%rbp), %xmm4, %xmm3
vpaddq  -96(%rbp), %xmm6, %xmm5
vmovaps %xmm3, -48(%rbp)
vmovaps %xmm5, -32(%rbp)
vmovdqa -48(%rbp), %ymm0
(plus overhead to align the stack, etc)

compared to clang's

vextractf128$1, %ymm0, %xmm2
vextractf128$1, %ymm1, %xmm3
vpaddq  %xmm2, %xmm3, %xmm2
vpaddq  %xmm0, %xmm1, %xmm0
vinsertf128 $1, %xmm2, %ymm0, %ymm0

[Bug target/79709] Subobtimal code with -mavx and explicit vector

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Marc Glisse from comment #2)
> We have trouble with your VSET macro (known issue):
>   two_28 = BIT_INSERT_EXPR ;
>   two_29 = BIT_INSERT_EXPR ;
>   two_30 = BIT_INSERT_EXPR ;
>   two_31 = BIT_INSERT_EXPR ;
> it is easier for gcc if you write:
>   v4do two={2,2,2,2};
> or you could even replace two with 2 in the expressions, gcc handles it just
> fine.

This part is not at all central to this PR, but we are really missing
optimizations on the new BIT_INSERT_EXPR.

typedef long vec __attribute__((vector_size(16)));
vec f(){
  long l;
  vec v={l,l};
  v[0]=0;
  v[1]=0;
  return v;
}

  _1 = {l_2(D), l_2(D)};
  v_4 = BIT_INSERT_EXPR <_1, 0, 0 (64 bits)>;
  v_5 = BIT_INSERT_EXPR ;

so gcc could replace {l,l} with {0,l} after the first bit_insert_expr (_1 has a
single use), and then {0,0} after the second, one element at a time, the easy
case (though constructors are always tricky).

[Bug target/79709] Subobtimal code with -mavx and explicit vector

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
We have trouble with your VSET macro (known issue):
  two_28 = BIT_INSERT_EXPR ;
  two_29 = BIT_INSERT_EXPR ;
  two_30 = BIT_INSERT_EXPR ;
  two_31 = BIT_INSERT_EXPR ;
it is easier for gcc if you write:
  v4do two={2,2,2,2};
or you could even replace two with 2 in the expressions, gcc handles it just
fine.

In reload, subregs are extracted via the stack, whereas the low subreg should
already be available (NOP) and the high one can be extracted by a single insn.
That's probably the first thing to investigate. (-mtune doesn't change what
happens)

res could be kept in a register (or even better a pair of registers) through
the whole loop.

[Bug target/79709] Subobtimal code with -mavx and explicit vector

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra

--- Comment #1 from Andrew Pinski  ---
Does -march=intel fix the issue?  I am suspecting this is just a tuning issue
where the default (generic) tuning turns on an option which is needed for
better performance on some AMD machines.

[Bug rtl-optimization/79150] ICE: in commit_one_edge_insertion, at cfgrtl.c:2077 for the gcc.dg/pr77834.c test

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Well, does that "end with a non-branch" work?  Not ICE that is; the
real problem will need to be dealt with as well, just probably not
in stage 4.

[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 24 20:41:54 2017
New Revision: 245719

URL: https://gcc.gnu.org/viewcvs?rev=245719=gcc=rev
Log:
PR c++/79588
c-family/
* c-common.c (check_function_restrict): New function.
(check_function_arguments): Add FNDECL argument.  Call
check_function_restrict if -Wrestrict.
* c-warn.c (warn_for_restrict): Remove ARGS argument, add ARGARRAY
and NARGS.  Use auto_vec for ARG_POSITIONS, simplify.
* c-common.h (check_function_arguments): Add FNDECL argument.
(warn_for_restrict): Remove ARGS argument, add ARGARRAY and NARGS.
c/
* c-parser.c (c_parser_postfix_expression_after_primary): Don't
handle -Wrestrict here.
* c-typeck.c (build_function_call_vec): Adjust
check_function_arguments caller.
cp/
* call.c (build_over_call): Call check_function_arguments even for
-Wrestrict, adjust check_function_arguments caller.
* parser.c (cp_parser_postfix_expression): Don't handle -Wrestrict
here.
* typeck.c (cp_build_function_call_vec): Adjust
check_function_arguments caller.
testsuite/
* g++.dg/warn/Wrestrict-1.C: New test.
* g++.dg/warn/Wrestrict-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wrestrict-1.C
trunk/gcc/testsuite/g++.dg/warn/Wrestrict-2.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-warn.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79709] Subobtimal code with -mavx and explicit vector

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Severity|normal  |enhancement

[Bug target/69148] [5 Regression] ICE (floating point exception) on s390x-linux-gnu

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #11 from Vladimir Makarov  ---
(In reply to Dominik Vogt from comment #10)
> (In reply to Matthias Klose from comment #8)
> > I prepared a patch for the distro builds. Any reason that this can't go to
> > the gcc-5-branch?
> 
> Ping?

Sorry for the answer delay.  I have too many PRs these days.

After some thoughts recently about the possible patch risks, I believe it is ok
to commit the patch into gcc-5-branch.

Could you do this?  Or you prefer me to do this.

[Bug target/79709] New: Subobtimal code with -mavx and explicit vector

[tkoenig at gcc dot gnu.org]

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

Bug ID: 79709
   Summary: Subobtimal code with -mavx and explicit vector
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

For the following code

typedef double v4do __attribute__((vector_size (32)));
typedef long int v4i __attribute__((vector_size (32)));

#define VSET(vect,val) do { vect[0]=val; vect[1]=val; vect[2]=val; vect[3]=val;
} while (0)
void foo(v4do cx, v4do cy, v4i *r)
{
  v4do x, y, xn, yn;
  v4i add, res;
  v4do two, four;
  long int done;

  VSET(res, 0L);
  VSET(two, 2.0);
  VSET(four, 4.0);
  x = cx;
  y = cy;
  done = 0;
  while (1)
{
  xn = x*x - y*y + cx;
  yn = two*x*y + cy;
  add = xn+xn + yn*yn < four;
  res += add;
  if (add[0] == 0 || add[1] == 0 || add[2] || add[3])
break;
  x = xn;
  y = yn;
}
  *r = res;
}

gcc compares strange code.  The loop is translated with 7.0.1 20170212
with "gcc -O3 -S -mavx v.c" into

.L14:
vpextrq $1, %xmm2, %rax
testq   %rax, %rax
je  .L2
vmovdqa -48(%rbp), %ymm5
vextractf128$0x1, %ymm5, %xmm2
vmovq   %xmm2, %rax
testq   %rax, %rax
jne .L2
vpextrq $1, %xmm2, %rax
vmovapd %ymm3, %ymm5
testq   %rax, %rax
jne .L2
.L3:
vmulpd  %ymm5, %ymm5, %ymm3
vmulpd  %ymm8, %ymm5, %ymm5
vsubpd  %ymm6, %ymm3, %ymm3
vmulpd  %ymm4, %ymm5, %ymm4
vaddpd  %ymm0, %ymm3, %ymm3
vaddpd  %ymm1, %ymm4, %ymm4
vaddpd  %ymm3, %ymm3, %ymm2
vmulpd  %ymm4, %ymm4, %ymm6
vaddpd  %ymm6, %ymm2, %ymm2
vcmpltpd%ymm7, %ymm2, %ymm5
vmovapd %ymm5, -48(%rbp)
vmovdqa -48(%rbp), %xmm5
vpaddq  -112(%rbp), %xmm5, %xmm5
vmovaps %xmm5, -80(%rbp)
vmovdqa -32(%rbp), %xmm5
vpaddq  -96(%rbp), %xmm5, %xmm2
vmovaps %xmm2, -64(%rbp)
vmovdqa -80(%rbp), %ymm2
vmovdqa %ymm2, -112(%rbp)
vmovdqa -48(%rbp), %xmm2
vmovq   %xmm2, %rax
testq   %rax, %rax
jne .L14

which contains quite a few unnecessary instructions for moving stuff around.

By comparision, clang translates the inner loop to

.LBB0_1:# =>This Inner Loop Header: Depth=1
vmulpd  %ymm5, %ymm5, %ymm6
vmulpd  %ymm4, %ymm4, %ymm7
vsubpd  %ymm7, %ymm6, %ymm6
vaddpd  %ymm5, %ymm5, %ymm7
vaddpd  %ymm0, %ymm6, %ymm5
vmulpd  %ymm7, %ymm4, %ymm4
vaddpd  %ymm1, %ymm4, %ymm4
vaddpd  %ymm5, %ymm5, %ymm6
vmulpd  %ymm4, %ymm4, %ymm7
vaddpd  %ymm7, %ymm6, %ymm6
vcmpltpd%ymm8, %ymm6, %ymm6
vextractf128$1, %ymm6, %xmm7
vextractf128$1, %ymm2, %xmm3
vpaddq  %xmm3, %xmm7, %xmm3
vpaddq  %xmm2, %xmm6, %xmm2
vinsertf128 $1, %xmm3, %ymm2, %ymm2
vmovq   %xmm7, %rax
vpextrq $1, %xmm7, %rcx
orq %rax, %rcx
jne .LBB0_4
# BB#2: #   in Loop: Header=BB0_1 Depth=1
vpextrq $1, %xmm6, %rax
testq   %rax, %rax
je  .LBB0_4
# BB#3: #   in Loop: Header=BB0_1 Depth=1
vmovq   %xmm6, %rax
testq   %rax, %rax
jne .LBB0_1

which looks much more straighforward, and should be faster.

[Bug target/79437] Redundant move instruction when getting sign bit of double on 32-bit architecture

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Vladimir Makarov from comment #3)

>17: ax:DI=[sp:SI+0x4]
> 6: {ax:DI=ax:DI 0>>0x3f;clobber flags:CC;}
>12: ax:SI=ax:SI
>13: use ax:SI
>  
> The code is fine with RA point of view.  In any case, it hardly can be fixed
> in RA.  And it is practically impossible to teach RA to predict all
> subsequent split decisions.

Interesting, that -fregmove doesn't improve the code, although the
cprop_hardreg pass is placed after the post-reload split.

[Bug target/79038] Improve PowerPC ISA 3.0 conversion between integers and hardware _Float128

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #40611|0   |1
is obsolete||

--- Comment #4 from Michael Meissner  ---
Created attachment 40827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40827=edit
Patch to add enhancements

This patch is the part of the patch that adds the enhancements for PR 79038
that are waiting for GCC 8 to open.  Part of the patch was submitted to fix an
earlier bug, and this patch is all of the enhancement parts that were not
committed to GCC 7.

[Bug rtl-optimization/79456] [7 regression] Extra instruction emitted after LRA patch

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
I can not reproduce the bug on the fresh trunk any more.  I believe the problem
is analogous to

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

and it was solved last week.

[Bug translation/79705] cp/decl.c message not marked for translation

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 7.

[Bug translation/79705] cp/decl.c message not marked for translation

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Fri Feb 24 18:54:13 2017
New Revision: 245717

URL: https://gcc.gnu.org/viewcvs?rev=245717=gcc=rev
Log:
PR translation/79705
* decl.c (check_redeclaration_exception_specification): Mark a string
for translation.  Make the pointer const.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug c/69602] [6/7 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||peter at eisentraut dot org

--- Comment #19 from Marek Polacek  ---
*** Bug 79708 has been marked as a duplicate of this bug. ***

[Bug c/79708] -Wlogical-op with duplicate errno symbols

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Looks like an exact dup of PR69602.

*** This bug has been marked as a duplicate of bug 69602 ***

[Bug c/79708] New: -Wlogical-op with duplicate errno symbols

[peter at eisentraut dot org]

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

Bug ID: 79708
   Summary: -Wlogical-op with duplicate errno symbols
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at eisentraut dot org
  Target Milestone: ---

This is an attempt to write portable code:

#include 

int
main()
{
if (errno == EWOULDBLOCK || errno == EAGAIN)
return 1;
return 0;
}

At some point, gcc -Wlogical-op started warning about this with:

test.c:6:27: warning: logical ‘or’ of equal expressions [-Wlogical-op]

This is unfortunate, because I find -Wlogical-op useful otherwise.

Could the warning be modified to realize when the duplicate values are from
macros expansion?  (I'm aware of the difference between preprocessor and
compiler and that this might be difficult.)

[Bug middle-end/79396] [5/6/7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2 -march=haswell

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Created attachment 40826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40826=edit
gcc7-pr79396.patch

Untested fix.

[Bug middle-end/79396] [5/6/7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2 -march=haswell

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|7.0 |5.5

[Bug middle-end/79396] [5/6/7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2 -march=haswell

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Reduced testcase:
struct A { A (); ~A (); };

float
foo (float x)
{
  A a;
  return __builtin_pow (x, 2) + 2;
}

[Bug target/79437] Redundant move instruction when getting sign bit of double on 32-bit architecture

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #2)
> Even -mno-stv doesn't help here, the problem is that for the shift we don't
> lower DImode operations here until too late (split2) and so EDX:EAX is used
> for the 64-bit value.

Yes, exactly.  After LRA we have RTL for the code w/o DO_BOOL:

   17: ax:DI=[sp:SI+0x4]
6: {ax:DI=ax:DI 0>>0x3f;clobber flags:CC;}
   12: ax:SI=ax:SI
   13: use ax:SI

The code is fine with RA point of view.  In any case, it hardly can be fixed in
RA.  And it is practically impossible to teach RA to predict all subsequent
split decisions.

[Bug tree-optimization/79390] 10% performance drop in SciMark2 LU after r242550

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Which is what I wrote in #c9.  Let's add a target hook and do the cap in there,
rather than artificially lowering the max-rtl-if-conversion-insns default.

[Bug c++/79707] New: missing -Wunused-result on an unused new expression

[msebor at gcc dot gnu.org]

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

Bug ID: 79707
   Summary: missing -Wunused-result on an unused new expression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The result of the new expression in the return statement in the following
example is unused, leaking the memory it allocates.  GCC doesn't point it out
by issuing a warning on the code (such as -Wunused-result).

There may be cases where the warning may be considered a false positive: for
example, a class whose constructor stores the this pointer in some registry so
the unused return value of the new expression need not be stored to prevent the
memory and the object from leaking.  Those are likely rare and may be an
acceptable trade-off.  For POD types the warning should in practice always be a
true positive.  I.e., in 'void f () { new int; }' GCC should not only warn but
can also eliminate the new expression.

$ cat t.C && gcc -O2 -S -Wall -Wextra -Wpedantic -Wunused-result
-fdump-tree-optimized=/dev/stdout t.C
struct S {
  S (int, S * = 0);
};

S* f (S *p)
{
  // typo: 'return new S (1, p)' intended
  return new S (1), p;
}

;; Function S* f(S*) (_Z1fP1S, funcdef_no=0, decl_uid=2290, cgraph_uid=0,
symbol_order=0)

S* f(S*) (struct S * p)
{
  void * D.2324;
  void * _3;

   [100.00%]:
  _3 = operator new (1);
  S::S (_3, 1, 0B);

   [100.00%]:
  return p_5(D);

 [0.00%]:
  operator delete (_3, 1);
  _7 = __builtin_eh_pointer (1);
  __builtin_unwind_resume (_7);

}

[Bug rtl-optimization/79150] ICE: in commit_one_edge_insertion, at cfgrtl.c:2077 for the gcc.dg/pr77834.c test

[tomtab at gcc dot gnu.org]

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

--- Comment #5 from tomtab at gcc dot gnu.org ---
Here are some more details about this failure:

It is caused by "gcc_assert (!JUMP_P (last))" in
commit_one_edge_insertion (gcc/cfgrtl.c:2077):

  if (returnjump_p (last))
{
  /* ??? Remove all outgoing edges from BB and add one for EXIT.
 This is not currently a problem because this only happens
 for the (single) epilogue, which already has a fallthru edge
 to EXIT.  */

  e = single_succ_edge (bb);
  gcc_assert (e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun)
  && single_succ_p (bb) && (e->flags & EDGE_FALLTHRU));

  e->flags &= ~EDGE_FALLTHRU;
  emit_barrier_after (last);

  if (before)
delete_insn (before);
}
  else
gcc_assert (!JUMP_P (last));

The assert is triggered because we're removing an edge which ends on
a conditional jump, which is part of a loop.

The primary reason for the existence of this loop is the fact that the code in
gcc.dg/pr77834.c uses vector extensions.

When compiling code which uses vectors, a looping memcpy is generated if the
vectors are big enough, i.e. >32 bytes for MIPS32 or >64 bytes for MIPS64.
This is done by mips_expand_block_move (gcc/config/mips.c:8103).

Such a memcpy can be generated for a partition copy which is then inserted on
an edge (in insert_partition_copy_on_edge, gcc/tree-outof-ssa.c:239).

This is done during PHI node elimination, which is done by eliminate_phi
(gcc/tree-outof-ssa.c:700), which is called by expand_phi_nodes, as a part of
the expand pass (gcc/cfgexpand.c:6339).

My proposed fix was to update the CFG by calling find_many_sub_basic_blocks
with an all-one block bitmap (which also happens in cfgexpand.c, after edge
removal) whenever an edge contains an insn which satisfies control_flow_insn_p
(see proposed patch in the post above).

However, Segher Boessenkool suggested that we could insert some kind of a nop
whenever the edge ends on a conditional jump, in order to minimize the risk of
breaking the compiler at such a late stage in the development cycle.

So, what would be an appropriate solution for this ?

[Bug rtl-optimization/79150] ICE: in commit_one_edge_insertion, at cfgrtl.c:2077 for the gcc.dg/pr77834.c test

[tomtab at gcc dot gnu.org]

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

tomtab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||tomtab at gcc dot gnu.org

--- Comment #4 from tomtab at gcc dot gnu.org ---
Created attachment 40825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40825=edit
My proposed fix for PR79150.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #21 from Marek Polacek  ---
Patch posted .  Let's
see how it pans out.

[Bug tree-optimization/79390] 10% performance drop in SciMark2 LU after r242550

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #8)
> Try --param=max-rtl-if-conversion-insns=2 .
> Or try some -mtune that is not:
> /* X86_TUNE_ONE_IF_CONV_INSNS: Restrict a number of set insns to be
>if-converted to one.  */
> DEF_TUNE (X86_TUNE_ONE_IF_CONV_INSN, "one_if_conv_insn",
>   m_SILVERMONT | m_KNL | m_INTEL | m_CORE_ALL | m_GENERIC)
> See PR68920 for more details.  cmov is a mixed bag, sometimes it helps
> (usually when the jump can't be predicted well), sometimes it slows things
> down tremendously.

True, but here we converted to MAXSD, which I assume is not predicted. I think
that the above tune is declared with CMOV in mind. OTOH, if the conversion
results in non-predicted insn, such as MAX, SBB, etc... we can emit all of them
without fear of slowdown.

[Bug c/79677] Weird handling of -Werror=

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-24
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug tree-optimization/45397] [5/6 Regression] Issues with integer narrowing conversions

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Issues   |[5/6 Regression] Issues
   |with integer narrowing  |with integer narrowing
   |conversions |conversions

--- Comment #30 from Jeffrey A. Law  ---
Dropping the regression marker.  THe other cases are requests for additional
optimizations, not regressions.

[Bug rtl-optimization/79286] [7 Regression] ira and lra wrong code at -O2 and -Os on i686-linux

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jeffrey A. Law  ---
Darwin issues should be fixed now too.

[Bug rtl-optimization/79286] [7 Regression] ira and lra wrong code at -O2 and -Os on i686-linux

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Fri Feb 24 15:36:10 2017
New Revision: 245714

URL: https://gcc.gnu.org/viewcvs?rev=245714=gcc=rev
Log:
PR rtl-optimizatoin/79286
* ira.c (update_equiv_regs): Drop may_trap_p exception to
dominance test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c

[Bug translation/79705] cp/decl.c message not marked for translation

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Right, thanks.

[Bug tree-optimization/79390] 10% performance drop in SciMark2 LU after r242550

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Perhaps we just want to limit number of cmov converted insns in a bb rather
than all noce* attempts, or we should also check how far is the user of the
conditional move; on this exact testcase we turn one of the conditional insns
into a maxsd (which supposedly has reasonable latency) and another one into
cmov, but that one is consumed only by itself from earlier iteration and then
whatever called the function.
Perhaps noce_convert_multiple_sets should call in addition to
noce_conversion_profitable_p some target hook that in the x86 case would count
real cmove insns and for the ONE_IF_CONV... targets reject it only if there are
more than one real cmove?  I'm also surprised that the
noce_convert_multiple_sets doesn't try all those other cases like abs, minmax,
addcc, sign_mask etc.  But apparently the backend manages to expand at least
the minmax as such.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[jamborm at gcc dot gnu.org]

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

--- Comment #28 from Martin Jambor  ---
(In reply to Martin Jambor from comment #27)
> Unfortunately, something else has added a further gigabyte to WPA of
> FF in the last week:

So this fortunately turnout to be a mistake in measurement, I was
comparing a --enable-gather-detailed-mem-stats build with a normal
one.  The correct values are:

  | compiler| wpa mem (KB) | wpa mem (GB) |
  |-+--+--|
  | gcc 6 branch|  4046451 | 3.86 |
  | trunk rev. 245382   |  5468227 | 5.21 |
  | patched rev. 245382 |  4255799 | 4.06 |
  | trunk rev. 245595   |  5452515 | 5.20 |
  | patched rev. 245595 |  4240379 | 4.04 |

Thus, the patch avoids most of the reported increase in memory use.

[Bug c++/79706] invalid delete[] expression doesn't cause substitution failure

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-24
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
This means libstdc++ can't use SFINAE to check if a delete[] expression is
well-formed:


namespace std {
  template T&& declval();

  template struct result_of { };
  template
struct result_of
{
  using type = decltype(declval()(declval()));
};
}

template
  struct can_delete { };

template
  struct can_delete())>
  { void operator()(_Yp*) const; };

template
  struct can_delete())>
  { void operator()(_Yp*) const; };

struct A {
  void operator delete[](void*) = delete;
  void operator delete(void*) = delete;
};

std::result_of(A*)> r;


The result_of primary template should be used, but instead we get errors (or
one error, five times) while trying to match the partial specialization:

sp.cc: In instantiation of ‘struct can_delete’:
sp.cc:6:49:   required by substitution of ‘template struct
std::result_of [with F =
can_delete; A = A*]’
sp.cc:28:41:   required from here
sp.cc:17:3: error: use of deleted function ‘static void A::operator delete
[](void*)’
   { void operator()(_Yp*) const; };
   ^
sp.cc:24:8: note: declared here
   void operator delete[](void*) = delete;
^~~~
sp.cc:17:3: error: use of deleted function ‘static void A::operator delete
[](void*)’
   { void operator()(_Yp*) const; };
   ^
sp.cc:24:8: note: declared here
   void operator delete[](void*) = delete;
^~~~
sp.cc:17:10: error: use of deleted function ‘static void A::operator delete
[](void*)’
   { void operator()(_Yp*) const; };
  ^~~~
sp.cc:24:8: note: declared here
   void operator delete[](void*) = delete;
^~~~
sp.cc:17:10: error: use of deleted function ‘static void A::operator delete
[](void*)’
   { void operator()(_Yp*) const; };
  ^~~~
sp.cc:24:8: note: declared here
   void operator delete[](void*) = delete;
^~~~
sp.cc:17:27: error: use of deleted function ‘static void A::operator delete
[](void*)’
   { void operator()(_Yp*) const; };
   ^
sp.cc:24:8: note: declared here
   void operator delete[](void*) = delete;
^~~~

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
I'll have a look but -fno-schedule-insns "fixing things" has been known to
uncover alias analysis bugs from the GIMPLE level due to the scheduler using
the alias information to reorder memory ops

[Bug c++/79706] invalid delete[] expression doesn't cause substitution failure

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The first testcase does fail to compile, but for the wrong reason:

e.cc: In instantiation of ‘typename enable_if<_Array, decltype (delete [] 
ck_delete::__p)>::type ck_delete(_Yp*) [with bool _Array = true; _Yp = A;
typename enable_if<_Array, decltype (delete []  ck_delete::__p)>::type =
void]’:
e.cc:23:12:   required from here
e.cc:15:5: error: use of deleted function ‘static void A::operator delete
[](void*)’
   { delete[] __p; }
 ^~
e.cc:19:8: note: declared here
   void operator delete[](void*) = delete;
^~~~


The function template shouldn't even be instantiated, because the signature
should have a substitution failure.

[Bug c++/79706] invalid delete[] expression doesn't cause substitution failure

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Probably the same issue:

struct A {
  void operator delete(void*) = delete;
  void operator delete[](void*) = delete;
};

using type1 = decltype(delete (A*)0);
using type2 = decltype(delete[] (A*)0);

Neither of these invalid delete expressions gives an error.

Clang says:

e.cc:6:24: error: attempt to use a deleted function
using type1 = decltype(delete (A*)0);
   ^
e.cc:2:8: note: 'operator delete' has been explicitly marked deleted here
  void operator delete(void*) = delete;
   ^
e.cc:7:24: error: attempt to use a deleted function
using type2 = decltype(delete[] (A*)0);
   ^
e.cc:3:8: note: 'operator delete[]' has been explicitly marked deleted here
  void operator delete[](void*) = delete;
   ^
2 errors generated.


EDG says:

"e.cc", line 6: error: function "A::operator delete(void *)" (declared at line
  2) cannot be referenced -- it is a deleted function
  using type1 = decltype(delete (A*)0);
 ^

"e.cc", line 7: error: function "A::operator delete[](void *)" (declared at
  line 3) cannot be referenced -- it is a deleted function
  using type2 = decltype(delete[] (A*)0);
 ^

2 errors detected in the compilation of "e.cc".

[Bug c++/79706] New: invalid delete[] expression doesn't cause substitution failure

[redi at gcc dot gnu.org]

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

Bug ID: 79706
   Summary: invalid delete[] expression doesn't cause substitution
failure
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template struct enable_if { };
template struct enable_if { using type = T; };

// Check that delete expression is well-formed:
template
  auto
  ck_delete(_Yp* __p)
  -> typename enable_if::type;

// Check that delete[] expression is well-formed:
template
  auto
  ck_delete(_Yp* __p)
  -> typename enable_if<_Array, decltype(delete[] __p)>::type
  { delete[] __p; }

struct A {
  void operator delete(void*) = delete;
  void operator delete[](void*) = delete;
};


auto f1 = _delete;  // error expected here

int main()
{
f1(new A[1]);
}

[Bug translation/79705] cp/decl.c message not marked for translation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Please make it const char *const msg = 
so that -Wformat can see it.

[Bug tree-optimization/79390] 10% performance drop in SciMark2 LU after r242550

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Try --param=max-rtl-if-conversion-insns=2 .
Or try some -mtune that is not:
/* X86_TUNE_ONE_IF_CONV_INSNS: Restrict a number of set insns to be
   if-converted to one.  */
DEF_TUNE (X86_TUNE_ONE_IF_CONV_INSN, "one_if_conv_insn",
  m_SILVERMONT | m_KNL | m_INTEL | m_CORE_ALL | m_GENERIC)
See PR68920 for more details.  cmov is a mixed bag, sometimes it helps (usually
when the jump can't be predicted well), sometimes it slows things down
tremendously.

[Bug rtl-optimization/79150] ICE: in commit_one_edge_insertion, at cfgrtl.c:2077 for the gcc.dg/pr77834.c test

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P2  |P3
  Known to fail||4.8.5, 4.9.4, 7.0.1

--- Comment #3 from mpf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Priority on non-regression bugs is meaningless.  So - can you identify a
> working release (list it in Known-to-work)?

Ah, OK.  It looks like I have never actually read all the details from the
managing bugs page!

I've just gone all the way down to GCC 4.8 and the testcase is failing from
then clearly showing the code is rare.

The ICE in the testsuite results make this failure seem worse than it is I
guess.  Just an unfortunate testcase that exposes a long term bug.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/79390] 10% performance drop in SciMark2 LU after r242550

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
The testcase for RTL if-conversion part:

--cut here--
extern double A[32];

int foo (void)
{
  double t = A[0];
  int jp = 0;
  int i;

  for (i = 0; i < 32; i++)
{
  double ab = A[i];
  if (ab > t)
{
  jp = i;
  t = ab;
}
}

  return jp;
}
--cut here--

gcc -O2:

...
.L5:
movsd   A(,%rdx,8), %xmm0
ucomisd %xmm1, %xmm0
jbe .L3
movapd  %xmm0, %xmm1
movl%edx, %eax
.L3:
addq$1, %rdx
.L2:
cmpq$32, %rdx
jne .L5

There is no difference w/ and w/o -fno-split-paths with the above testcase.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-24
 CC||ktkachov at gcc dot gnu.org
  Component|tree-optimization   |target
 Ever confirmed|0   |1

--- Comment #10 from Jakub Jelinek  ---
-fno-schedule-insns fixes it even with PTRS_COMPARE_UNEQUAL=286 (while
-fno-schedule-insns2 still aborts).
Let's consider this a target bug for now (especially when it doesn't fail on
any other arch).

[Bug tree-optimization/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
As there are two different comparisons, I've in the debugger tried to manually
optimize just one of them and not the other one (return 0 in gdb), and it seems
that it is the:
 == _286
comparison that matters (when optimized into false, testcase aborts), the other
comparison doesn't matter.
tmp is indeed an automatic variable and _286 is this parameter + some constant
offset, so indeed fre3 is right to optimize that away.

[Bug tree-optimization/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Fri, 24 Feb 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
> 
> --- Comment #7 from Jakub Jelinek  ---
> Comparing PTRS_COMPARE_UNEQUAL={287,286} fre3 (287 doesn't occur in the list,
> so it is never optimize using ptrs_compare_unequal, 286 is only optimize for
> _286),
> the differences are:
>_286 = [(struct function *)this_9(D) + 100B].D.542596;
> -  if ( == _286)
> -goto ; [46.53%]
> -  else
> -goto ; [53.47%]
> -
> -   [50.53%]:
> ...
> and
> -   [45.34%]:
> -  if ( == _286)
> -goto ; [26.74%]
> -  else
> -goto ; [73.26%]
> -
> -   [33.22%]:
> plus lots of renumbering of basic blocks; the number of skipped bbs is big
> though.

Assuming D.616011 and tmp are automatic vars that's obviously correct.
_286 is just 'this' offsetted.

[Bug tree-optimization/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Comparing PTRS_COMPARE_UNEQUAL={287,286} fre3 (287 doesn't occur in the list,
so it is never optimize using ptrs_compare_unequal, 286 is only optimize for
_286),
the differences are:
   _286 = [(struct function *)this_9(D) + 100B].D.542596;
-  if ( == _286)
-goto ; [46.53%]
-  else
-goto ; [53.47%]
-
-   [50.53%]:
...
and
-   [45.34%]:
-  if ( == _286)
-goto ; [26.74%]
-  else
-goto ; [73.26%]
-
-   [33.22%]:
plus lots of renumbering of basic blocks; the number of skipped bbs is big
though.

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

[palves at redhat dot com]

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

--- Comment #8 from Pedro Alves  ---
Created attachment 40823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40823=edit
reproducer v4

Same as above.

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

[palves at redhat dot com]

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

--- Comment #7 from Pedro Alves  ---
Today I remembered to try reducing the v3 reproducer by converting to C instead
of C++.

The resulting warnings are not exactly the same, but they're very similar.  The
fact that we still only get warnings for foo_1 and foo_3 is preserved.
All the foo_* functions are identical except for the literal being compared to.
 Somehow comparing against 0, 1, 3, or FLAG1 behaves differently.  Comparing
against 1 doesn't warn, but against FLAG1 (which is 1)
does.  Quite mystifying.


struct enum_flags { int value; };

static inline void set_flag (struct enum_flags *f, int e) { f->value = f->value
| e; }
static inline int get_flag (struct enum_flags *f) { return f->value; }

enum flag { FLAG1 = 1, };

extern void bar ();

void
foo_0 (int param)
{
  struct enum_flags f0; // doesn't warn

  if (param)
set_flag (, FLAG1);

  if (get_flag () != 0) // doesn't warn
bar ();
}

void
foo_1 (int param)
{
  struct enum_flags f1; // warns

  if (param)
set_flag (, FLAG1);

  if (get_flag () != FLAG1) // warns
bar ();
}

void
foo_2 (int param)
{
  struct enum_flags f2; // doesn't warn

  if (param)
set_flag (, FLAG1);

  if (get_flag () != 1)
bar ();
}

void
foo_3 (int param)
{
  struct enum_flags f3; // warns

  if (param)
set_flag (, FLAG1);

  if (get_flag () != 3)
bar ();
}


Results in:


$ /opt/gcc/bin/gcc enum_flags4.c -o enum_flags -O2 -Wall -Werror
-Wuninitialized -c
enum_flags4.c: In function ‘foo_1’:
enum_flags4.c:3:81: error: ‘f1.value’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
 static inline void set_flag (struct enum_flags *f, int e) { f->value =
f->value | e; }
   
~^~~
enum_flags4.c:25:21: note: ‘f1.value’ was declared here
   struct enum_flags f1; // warns
 ^~
enum_flags4.c: In function ‘foo_3’:
enum_flags4.c:3:81: error: ‘f3.value’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
 static inline void set_flag (struct enum_flags *f, int e) { f->value =
f->value | e; }
   
~^~~
enum_flags4.c:49:21: note: ‘f3.value’ was declared here
   struct enum_flags f3; // warns
 ^~
cc1: all warnings being treated as errors

[Bug tree-optimization/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
for i in /tmp/rh1422456-_*.s; do j=`basename $i .s`; echo ===$j===; g++ -o
/tmp/$j{,.s}; /tmp/$j; done
===rh1422456-_150===
===rh1422456-_155===
===rh1422456-_192===
===rh1422456-_212===
===rh1422456-_233===
===rh1422456-_262===
===rh1422456-_286===
rh1422456-_286: /tmp/rh1422456.C:50: int main(int, char**): Assertion `r && itr
== end' failed.
Aborted (core dumped)
===rh1422456-_299===
===rh1422456-_335===
===rh1422456-_375===
rh1422456-_375: /tmp/rh1422456.C:50: int main(int, char**): Assertion `r && itr
== end' failed.
Aborted (core dumped)
===rh1422456-_416===
===rh1422456-_424===
===rh1422456-_460===
===rh1422456-_568===
===rh1422456-_647===
===rh1422456-_9===
rh1422456-_9: /tmp/rh1422456.C:50: int main(int, char**): Assertion `r && itr
== end' failed.
Aborted (core dumped)

So it is just 3 SSA_NAMEs that result in abort this time (and no invalid free
most likely).  _9 is actually this_9(D), let me try _286 now how it affects the
tree dumps.  Of course it might be some RTL bug only triggered through the
changes.

[Bug tree-optimization/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Repeated on current trunk r245696, this time with:
--- gcc/tree-ssa-alias.c.jj 2017-01-10 08:12:48.0 +0100
+++ gcc/tree-ssa-alias.c2017-02-24 12:15:17.869368974 +0100
@@ -387,7 +387,13 @@ ptrs_compare_unequal (tree ptr1, tree pt
  || ! decl_binds_to_current_def_p (obj1))
return false;
}
-  return !pt_solution_includes (>pt, obj1);
+  if (!pt_solution_includes (>pt, obj1))
+{
+gcc_assert (TREE_CODE (ptr2) == SSA_NAME);
+int x = atoi (getenv ("PTRS_COMPARE_UNEQUAL"));
+debug_generic_stmt (ptr2);
+return SSA_NAME_VERSION (ptr2) == x;
+}
 }

   /* ???  We'd like to handle ptr1 != NULL and ptr1 != ptr2
hack.  Unpatched trunk fails, with -fno-tree-pre succeeds and with this hack
and PTRS_COMPARE_UNEQUAL=11 succeeds as well.  Let me try the various ssa
name versions next.

[Bug translation/79705] cp/decl.c message not marked for translation

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-24
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #20 from Marek Polacek  ---
Oh well.  Anyway, this

--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -1973,7 +1973,8 @@ cp_fold_maybe_rvalue (tree x, bool rval)
 {
   x = cp_fold (x);
   if (rval && DECL_P (x)
- && TREE_CODE (TREE_TYPE (x)) != REFERENCE_TYPE)
+ && TREE_CODE (TREE_TYPE (x)) != REFERENCE_TYPE
+ && !TYPE_PTRDATAMEM_P (TREE_TYPE (x)))
{
  tree v = decl_constant_value (x);
  if (v != x && v != error_mark_node)


fixes the original testcase, as well as the one Comment 4 and in Comment 11.

[Bug translation/79705] cp/decl.c message not marked for translation

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I suppose we want

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1274,7 +1274,7 @@ check_redeclaration_exception_specification (tree
new_decl,
   && !comp_except_specs (new_exceptions, old_exceptions, ce_normal))
 {
   const char *msg
-   = "declaration of %qF has a different exception specifier";
+   = G_("declaration of %qF has a different exception specifier");
   bool complained = true;
   location_t new_loc = DECL_SOURCE_LOCATION (new_decl);
   if (DECL_IN_SYSTEM_HEADER (old_decl))

[Bug preprocessor/79701] #pragma ignored "-Wcomment" has no effect

[damien at iwi dot me]

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

--- Comment #1 from Damien GERARD  ---
behavior observed:
 - debian 9 with gcc 6.3 & 5.4
   gcc (Debian 6.3.0-7) 6.3.0 20170218
   gcc-5 (Debian 5.4.1-5) 5.4.1 20170205

 - CentOS 7.2 gcc 6.2 (rhel-devtoolset)

[Bug rtl-optimization/79150] ICE: in commit_one_edge_insertion, at cfgrtl.c:2077 for the gcc.dg/pr77834.c test

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Priority on non-regression bugs is meaningless.  So - can you identify a
working release (list it in Known-to-work)?

[Bug translation/79705] New: cp/decl.c message not marked for translation

[fmarchal at perso dot be]

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

Bug ID: 79705
   Summary: cp/decl.c message not marked for translation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

In cp/decl.c, inside function check_redeclaration_exception_specification(),
one can find the code below where the "declaration of %qF has a different
exception specifier" text isn't translated but the "from previous declaration
%qF" text following it is translated.

  /* [except.spec]

 If any declaration of a function has an exception-specification,
 all declarations, including the definition and an explicit
 specialization, of that function shall have an
 exception-specification with the same set of type-ids.  */
  if (! DECL_IS_BUILTIN (old_decl)
  && !comp_except_specs (new_exceptions, old_exceptions, ce_normal))
{
  const char *msg
= "declaration of %qF has a different exception specifier";
  bool complained = true;
  location_t new_loc = DECL_SOURCE_LOCATION (new_decl);
  if (DECL_IN_SYSTEM_HEADER (old_decl))
complained = pedwarn (new_loc, OPT_Wsystem_headers, msg, new_decl);
  else if (!flag_exceptions)
/* We used to silently permit mismatched eh specs with
   -fno-exceptions, so make them a pedwarn now.  */
complained = pedwarn (new_loc, OPT_Wpedantic, msg, new_decl);
  else
error_at (new_loc, msg, new_decl);
  if (complained)
inform (DECL_SOURCE_LOCATION (old_decl),
"from previous declaration %qF", old_decl);
}

Either translate both or translate none. I guess they should be both
translated.

[Bug tree-optimization/79389] [7 Regression] 30% performance regression in SciMark2 MonteCarlo

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 24 11:51:33 2017
New Revision: 245713

URL: https://gcc.gnu.org/viewcvs?rev=245713=gcc=rev
Log:
2017-02-24  Richard Biener  

PR tree-optimization/79389
* gimple-ssa-split-paths.c (is_feasible_trace): Properly skip
debug insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-split-paths.c

[Bug tree-optimization/79690] IVOPTs drops gs: prefix

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Vectorizer fix I am testing:

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 245712)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -6324,7 +6324,7 @@ vectorizable_store (gimple *stmt, gimple
   vect_permute_store_chain().  */
vec_oprnd = result_chain[i];

- data_ref = fold_build2 (MEM_REF, TREE_TYPE (vec_oprnd),
+ data_ref = fold_build2 (MEM_REF, vectype,
  dataref_ptr,
  dataref_offset
  ? dataref_offset

[Bug rtl-optimization/79150] ICE: in commit_one_edge_insertion, at cfgrtl.c:2077 for the gcc.dg/pr77834.c test

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 Target|mips-mti-*  |mips*
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-24
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from mpf at gcc dot gnu.org ---
Updating to P2 as this test case can be tweaked to show the same ICE on MIPS64
making it a bug on a primary target.  To show this on MIPS64 (n32/n64) then a
vector size of 128 is required rather than 64.

[Bug tree-optimization/79390] 10% performance drop in SciMark2 LU after r242550

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Fri, 24 Feb 2017, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390
> 
> Uroš Bizjak  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #5 from Uroš Bizjak  ---
> (In reply to Richard Biener from comment #4)
> > On trunk I see with -fno-split-paths:
> > 
> > .L5:
> > movq(%r14,%rdx,8), %rcx
> > vmovsd  (%rcx,%rbx), %xmm0
> > vandpd  %xmm3, %xmm0, %xmm0
> > vucomisd%xmm1, %xmm0
> > jbe .L4
> > vmovapd %xmm0, %xmm1
> > movl%edx, %r9d
> > .L4:
> > addq$1, %rdx
> > cmpq%rdi, %rdx
> > jne .L5
> 
> This looks similar to PR79389, where two problems were exposed. In addition to
> split-paths issue, perhaps something disturbed RTL if-conversion to generate
> jump instead of cmova?
> 
> .L4:
> movq(%r15,%rax,8), %rcx
> vmovsd  (%rcx,%rbx), %xmm0
> vandpd  %xmm3, %xmm0, %xmm0
> vucomisd%xmm1, %xmm0
> vmaxsd  %xmm1, %xmm0, %xmm1
> cmova   %eax, %edx
> addq$1, %rax
> cmpl%eax, %r14d
> jg  .L4

Note the path-splitting I noticed in comment#1 is not mitigated by
the recent cost-model fixes (a threading opportunity is still
detected - a non-existig one though).

[Bug tree-optimization/79390] 10% performance drop in SciMark2 LU after r242550

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #4)
> On trunk I see with -fno-split-paths:
> 
> .L5:
> movq(%r14,%rdx,8), %rcx
> vmovsd  (%rcx,%rbx), %xmm0
> vandpd  %xmm3, %xmm0, %xmm0
> vucomisd%xmm1, %xmm0
> jbe .L4
> vmovapd %xmm0, %xmm1
> movl%edx, %r9d
> .L4:
> addq$1, %rdx
> cmpq%rdi, %rdx
> jne .L5

This looks similar to PR79389, where two problems were exposed. In addition to
split-paths issue, perhaps something disturbed RTL if-conversion to generate
jump instead of cmova?

.L4:
movq(%r15,%rax,8), %rcx
vmovsd  (%rcx,%rbx), %xmm0
vandpd  %xmm3, %xmm0, %xmm0
vucomisd%xmm1, %xmm0
vmaxsd  %xmm1, %xmm0, %xmm1
cmova   %eax, %edx
addq$1, %rax
cmpl%eax, %r14d
jg  .L4

[Bug target/79404] [7 Regression] h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[dhowells at redhat dot com]

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

--- Comment #6 from dhowells at redhat dot com  ---
That builds now, thanks!

[Bug target/71695] m68k: long long multiplication broken

[martin at netbsd dot org]

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

Martin Husemann  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Martin Husemann  ---
Sorry for late reply - it turns out this was due to a local, let say, "merge
mishap" and slightly related to ancient bug 12792.

[Bug tree-optimization/56541] vectorizaton fails in conditional assignment of a constant

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed on trunk.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[amker at gcc dot gnu.org]

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

Bug 56541 Summary: vectorizaton fails in conditional assignment of a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56541

   What|Removed |Added

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

[Bug middle-end/78401] SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Can you please provide perf report of hot spots?

[Bug other/79703] [meta-bug] SciMark 2.0 performance issues

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||t.artem at mailcity dot com

--- Comment #1 from Uroš Bizjak  ---
SciMark 2.0 has lots of tight loops that are ideal for perf. Just stating the
benchmark score of two compilers does not represent a good report. We need at
least a perf report, with eventual analysis of hot spots. Something similar to
[1] is a good start.

For regressions, a regression hunt like [2] is also welcome

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79389#c3
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79389#c0

[Bug c/79692] [7 Regression] -Wformat-overflow false positive?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0
Summary|-Wformat-overflow false |[7 Regression]
   |positive?   |-Wformat-overflow false
   ||positive?

[Bug middle-end/78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
With trunk:

markus@x4 crafty % gcc -Wall -Wno-array-bounds -pipe -march=native -O3 -pthread
-DSYZYGY -DTEST -DCPUS=4 -DUNIX -c crafty.c
markus@x4 crafty % ./crafty bench quit
...
Total nodes: 193900602
Raw nodes per second: 5166549
Total elapsed time: 37.53

markus@x4 crafty % clang -lm -Wall -Wno-array-bounds -pipe -march=native -O3
-pthread -DSYZYGY -DTEST -DCPUS=4 -DUNIX crafty.c
markus@x4 crafty % ./a.out bench quit
...
Total nodes: 195568787
Raw nodes per second: 5206836
Total elapsed time: 37.56

This is under 1% difference and just in the noise.
Closing as invalid.

[Bug target/79704] [meta-bug] Phoronix Test Suite compiler performance issues

[trippels at gcc dot gnu.org]

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

Bug 78406 Summary: Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78406

   What|Removed |Added

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

[Bug tree-optimization/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
I don't see any unconditional delete() in .fre1 or .fre3 (r245696 - did you do
your analysis with r235622?  There were PTA fixes afterwards).

[Bug target/79704] [meta-bug] Phoronix Test Suite compiler performance issues

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I had recently a quick look at
http://www.phoronix.com/scan.php?page=article=gcc7-clang4-jan=2
EP-DGEMM where Phoronix claims clang is over 2.5x faster than gcc and in my
limited understanding pretty much all time is spent in the system libraries not
compiled with the test (blas, and even one written in fortran), so I don't
understand any difference at all on that test (unless it uses very different
libraries or very different configuration, e.g. using C blas instead of Fortran
blas or vice versa etc.).  After all, LLVM doesn't have a viable Fortran FE
anyway.

[Bug tree-optimization/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> E.g. on 122 valgrind says:
> ==21905== Invalid free() / delete / delete[] / realloc()
> ==21905==at 0x484B224: operator delete(void*) (vg_replace_malloc.c:576)
> ==21905==by 0x11BB3:
> path_expression_grammar<__gnu_cxx::__normal_iterator std::__cxx11::basic_string std::allocator > > >::path_expression_grammar() (in /tmp/rh1422456.122)
> ==21905==  Address 0xbd8fd048 is on thread 1's stack
> 
> Looking at tree dumps from PTRS_COMPARE_UNEQUAL=1 (works) and
> PTRS_COMPARE_UNEQUAL=122 (calls free on invalid arg), I see the first change
> in *.fre1 in path_expression_grammar::path_expression_grammar()
> function,
>MEM[(struct  &)this_10(D) + 56] ={v} {CLOBBER};
>MEM[(struct function_base *)this_10(D) + 56B].vtable = 0B;
>_122 = MEM[(char * *)];
> -  if (_M_local_buf != _122)
> -goto ;
> -  else
> -goto ;
> -
> -  :
>operator delete (_122);
> -
> -  :
>MEM[(struct  &)] ={v} {CLOBBER};
>D.552047 ={v} {CLOBBER};
>D.552048 ={v} {CLOBBER};
>_29 = _10(D)->attr;
> and
> @@ -12334,15 +12330,7 @@ path_expression_grammar::path_
>  
>  :
>_140 = MEM[(char * *)];
> -  if (_M_local_buf != _140)
> -goto ;
> -  else
> -goto ;
> -
> -  :
>operator delete (_140);
> -
> -  :
>MEM[(struct  &)] ={v} {CLOBBER};
>D.552047 ={v} {CLOBBER};
>resx 7
> 
> (all other changes are just in bb numbers, as some bbs have been removed in
> the latter case).
> No idea what to figure out from this though, it just removes some operator
> delete calls (free), but that shouldn't cause free being called on invalid,
> worst case just memory leak.

It more looks like it will now call delete on _140 where it might have not
(if equal to &..._M_local_buf).  This smells like a PTA issue and the
question is why D.552047 is thought to not point to
D.552047.D.20672._M_local_buf.

I'm trying to reproduce the above with a cross.

[Bug tree-optimization/45397] [5/6/7 Regression] Issues with integer narrowing conversions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #29 from Richard Biener  ---
Created attachment 40822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40822=edit
patch doing this in SCCVN

This instead of in DOM implements it in SCCVN which makes the saturated ops
recognized in phiopt1.

The other testcases in this bug involve other peculiarities like having
& 255 instead of a conversion to match or having A + B + CST.  This shows
that this kind of matching is really a hack... (or well, it show for another
time that handling CSE and larger expressions that are associatable is
difficult).

[Bug target/79704] [meta-bug] Phoronix Test Suite compiler performance issues

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||meta-bug
 Status|UNCONFIRMED |NEW
URL||https://www.phoronix-test-s
   ||uite.com/
   Last reconfirmed||2017-02-24
 Depends on||79703, 78406, 78405
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78405
[Bug 78405] OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than
under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78406
[Bug 78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79703
[Bug 79703] [Meta-bug] SciMark 2.0 performance issues

[Bug target/79704] New: [meta-bug] Phoronix Test Suite compiler performance issues

[ubizjak at gmail dot com]

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

Bug ID: 79704
   Summary: [meta-bug] Phoronix Test Suite compiler performance
issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

This meta-bug tracks Phoronix Test Suite [1] compiler performance issues.

[1] https://www.phoronix-test-suite.com/

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[reichelt at gcc dot gnu.org]

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

--- Comment #19 from Volker Reichelt  ---
No, that's again invalid.
The second operand of .* or .-> must point to a valid class member,
otherwise you'll get undefined behavior.
The only way to achieve this in this class with a single member is to
initialize it with ::c (or a copy of this value).

[Bug target/79703] SciMark 2.0 performance issues

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||meta-bug
 Status|UNCONFIRMED |NEW
URL||http://math.nist.gov/scimar
   ||k2/download_c.html
   Last reconfirmed||2017-02-24
 Ever confirmed|0   |1

[Bug target/79703] New: SciMark 2.0 performance issues

[ubizjak at gmail dot com]

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

Bug ID: 79703
   Summary: SciMark 2.0 performance issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

This meta-bug tracks SciMark 2.0 [1] performance issues.

[1] http://math.nist.gov/scimark2/download_c.html

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||kreckel at ginac dot de

--- Comment #6 from Jonathan Wakely  ---
*** Bug 79702 has been marked as a duplicate of this bug. ***

[Bug libstdc++/79702] AX_CXX_COMPILE_STDCXX([17]) does not work with GCC=7.0.1

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
this is already known

*** This bug has been marked as a duplicate of bug 78939 ***

[Bug libstdc++/79702] AX_CXX_COMPILE_STDCXX([17]) does not work with GCC=7.0.1

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
typedef __SIZE_TYPE__ size_t;
template using __void_t = void;


template
struct integral_constant
{
  static constexpr _Tp value = __v;
  typedef _Tp value_type;
  typedef integral_constant<_Tp, __v> type;
  constexpr operator value_type() const { return value; }
  constexpr value_type operator()() const { return value; }
};

  template
struct tuple_size;

  template
struct __tuple_size_cv_impl { };

  template
struct __tuple_size_cv_impl<_Tp,
__void_t::value)>>
: integral_constant::value> { };


  template
struct tuple_size : __tuple_size_cv_impl<_Tp> { };


struct S
{
  int x1 : 2;
  volatile double y1;
};

S f3()
{
  return {};
}

const auto [ x3, y3 ] = f3();

[Bug middle-end/29887] wrong-code for errno handling on overflow/underflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #6 from Richard Biener  ---
Note this bug mostly applied to -mfancy-math-387 -m32
[-funsafe-math-optimizations].  It seems the expand_errno_check() optimization
has been removed gradually and finally with

2015-11-17  Richard Sandiford  

* builtins.c (expand_errno_check, expand_builtin_mathfn)
(expand_builtin_mathfn_2): Delete.
(expand_builtin): Remove handling of functions with
internal function equivalents.
...

Thus this is fixed fully since GCC 6.

[Bug libstdc++/79702] AX_CXX_COMPILE_STDCXX([17]) does not work with GCC=7.0.1

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
And #include  is enough to reproduce.

[Bug libstdc++/79702] AX_CXX_COMPILE_STDCXX([17]) does not work with GCC=7.0.1

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-24
 CC||trippels at gcc dot gnu.org,
   ||ville.voutilainen at gmail dot 
com
  Component|c++ |libstdc++
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
It is a libstdc++ issue. It works fine with e.g. -stdlib=libc++.