[Bug rtl-optimization/85099] [meta-bug] selective scheduling issues

2018-04-23 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 85423, which changed state.

Bug 85423 Summary: [8 Regression] ICE in code_motion_process_successors, at 
sel-sched.c:6403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423

   What|Removed |Added

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

[Bug rtl-optimization/80463] [6/7 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments

2018-04-23 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463
Bug 80463 depends on bug 85423, which changed state.

Bug 85423 Summary: [8 Regression] ICE in code_motion_process_successors, at 
sel-sched.c:6403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423

   What|Removed |Added

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

[Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403

2018-04-23 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423

Alexander Monakov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Blocks||80463
 Resolution|--- |FIXED

--- Comment #7 from Alexander Monakov  ---
Thanks. I've added one more "Blocks" edge so indicate that this should be taken
when backporting the earlier patch.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463
[Bug 80463] [6/7 Regression] ICE with -fselective-scheduling2 and
-fvar-tracking-assignments

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

2018-04-23 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435

--- Comment #6 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #5)
> Subject: Re:  gengtype: don't test undefined value after
>  vasprintf failure
> 
> On Mon, 7 Jun 2010, dj at redhat dot com wrote:
> 
> > > If the libiberty maintainers won't review the xvasprintf patch,
> > 
> > I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html
> 
> That's a review of an older version.  The URLs I gave were of a version a 
> different person updated to take account of your original review comments.

Has the updated version been reviewed yet?

[Bug other/44286] Use sentinel attributes in GCC

2018-04-23 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44286

--- Comment #3 from Eric Gallager  ---
(In reply to Ralf Wildenhues from comment #2)
> Patch at .

Does the patch still apply?

[Bug other/30920] Incorrect splaying that not assures the caching property

2018-04-23 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30920

--- Comment #1 from Eric Gallager  ---
Does the patch still apply?

[Bug c++/85509] auto (function pointer) undermining inline expansion with GCC but not LLVM

2018-04-23 Thread aaron_sami_abassi at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509

--- Comment #1 from ASA  ---
I should add that without the static storage duration specifier even without
const specified, it does inline the function invocation.

[Bug target/85511] [X86] Using __builtin_ia32_writeeflags_u32 in 64-bit mode causes internal compiler error

2018-04-23 Thread craig.topper at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85511

--- Comment #2 from Craig Topper  ---
Should this builtin even be allowed in 64-bit mode?

[Bug target/83660] ICE with vec_extract inside expression statement

2018-04-23 Thread acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #19 from acsawdey at gcc dot gnu.org ---
Backported to gcc 7 and 6. Closing again.

[Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403

2018-04-23 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423

--- Comment #6 from Arseny Solokha  ---
I guess this PR can be closed now.

[Bug target/83660] ICE with vec_extract inside expression statement

2018-04-23 Thread acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660

--- Comment #18 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Apr 24 00:19:43 2018
New Revision: 259590

URL: https://gcc.gnu.org/viewcvs?rev=259590&root=gcc&view=rev
Log:
2018-04-23  Aaron Sawdey  

Backport from mainline
2018-04-16  Aaron Sawdey  

PR target/83660
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Mark
vec_extract expression as having side effects to make sure it gets
a cleanup point.

2018-04-23  Aaron Sawdey  

Backport from mainline
2018-04-16  Aaron Sawdey  

PR target/83660
* gcc.target/powerpc/pr83660.C: New test.



Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr83660.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/83660] ICE with vec_extract inside expression statement

2018-04-23 Thread acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660

--- Comment #17 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Apr 24 00:14:21 2018
New Revision: 259586

URL: https://gcc.gnu.org/viewcvs?rev=259586&root=gcc&view=rev
Log:

2018-04-23  Aaron Sawdey  

Backport from mainline
2018-04-16  Aaron Sawdey  

PR target/83660
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Mark
vec_extract expression as having side effects to make sure it gets
a cleanup point.

2018-04-23  Aaron Sawdey  

Backport from mainline
2018-04-16  Aaron Sawdey  

PR target/83660
* gcc.target/powerpc/pr83660.C: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr83660.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/85511] [X86] Using __builtin_ia32_writeeflags_u32 in 64-bit mode causes internal compiler error

2018-04-23 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85511

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-23
 CC||sebastian.peryt at intel dot 
com
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
This works:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index dc80b34f302..427f4e907a6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -37594,7 +37594,10 @@ rdseed_step:
   arg0 = CALL_EXPR_ARG (exp, 0);
   op0 = expand_normal (arg0);
   if (!general_no_elim_operand (op0, word_mode))
-  op0 = copy_to_mode_reg (word_mode, op0);
+  {
+op0 = convert_to_mode (word_mode, op0, 1);
+op0 = copy_to_mode_reg (word_mode, op0);
+  }

   emit_insn (gen_push (op0));
   emit_insn (gen_pop (gen_rtx_REG (word_mode, FLAGS_REG)));

[Bug target/85511] New: [X86] Using __builtin_ia32_writeeflags_u32 in 64-bit mode causes internal compiler error

2018-04-23 Thread craig.topper at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85511

Bug ID: 85511
   Summary: [X86] Using __builtin_ia32_writeeflags_u32 in 64-bit
mode causes internal compiler error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: craig.topper at gmail dot com
  Target Milestone: ---

This code

void foo(unsigned bar) {
  return __builtin_ia32_writeeflags_u32(bar);
}



Throws this error in 64-bit mode

during RTL pass: expand

: In function 'foo':

:2:10: internal compiler error: in copy_to_mode_reg, at explow.c:630

   return __builtin_ia32_writeeflags_u32(bar);

  ^~~

mmap: Invalid argument

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Compiler returned: 1

[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

2018-04-23 Thread wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #7 from Jim Wilson  ---
The problem is exposed in combine, where we take two instructions

(insn 9 8 10 2 (set (reg:DI 72 [ _2 ])
(sign_extend:DI (subreg:HI (reg:SI 75 [ SD.1554.PD.1553 ]) 0)))
"tmp.c"\
:12 92 {extendhidi2}
 (expr_list:REG_DEAD (reg:SI 75 [ SD.1554.PD.1553 ])
(nil)))
(insn 10 9 0 2 (parallel [
(asm_operands/v ("magic %0") ("") 0 [
(subreg/s/u:HI (reg:DI 72 [ _2 ]) 0)
]
 [
(asm_input:HI ("r") tmp.c:12)
]
 [] tmp.c:12)
(clobber (mem:BLK (scratch) [0  A8]))
]) "tmp.c":12 -1
 (expr_list:REG_DEAD (reg:DI 72 [ _2 ])
(nil)))

and then produce

insn 10 9 0 2 (parallel [
(asm_operands/v ("magic %0") ("") 0 [
(subreg:HI (reg:SI 75 [ SD.1554.PD.1553 ]) 0)
]
 [
(asm_input:HI ("r") tmp.c:12)
]
 [] tmp.c:12)
(clobber (mem:BLK (scratch) [0  A8]))
]) "tmp.c":12 -1
 (expr_list:REG_DEAD (reg:SI 75 [ SD.1554.PD.1553 ])
(nil)))

We have now lost the truncation and sign-extension.  The value passed to the
asm has correct value for the low 16 bits, but has garbage in the high 16 bits. 

However, what combine did does not appear wrong by itself.  One could argue
that the problem started with the asm, which is taking a HImode argument, even
though this makes little sense on RISC-V, since the only instructions operating
on HImode are the 16-bit load and store instructions.  Maybe the asm should use
the sign-extended DImode value directly and assume a DImode input instead of a
HImode input?  That would prevent the truncate and sign-extend from being
optimized away, but might be wrong if someone extends the RISC-V ISA to include
instructions that operate directly on HImode values.

I can work around the problem by explicitly casting the asm input to int.
  asm("magic %0" :: "r" ((int)sub.a) : "memory");
and now the asm takes SImode input, and the truncate/sign extend can't be
optimized away.  Asking the user to change their code doesn't seem like the
right solution though.

[Bug c++/85500] INCORRECTLY REPORTED

2018-04-23 Thread aaron_sami_abassi at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500

--- Comment #3 from ASA  ---
> No, that's not valid as a function declaration.

Right, it's:

auto function_name( params ... );

Again, I should have slept before posting.

[Bug fortran/85510] Linking error when accessing a coindexed variable inside an associate block

2018-04-23 Thread damian at sourceryinstitute dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85510

--- Comment #1 from Damian Rouson  ---
As similar error message results if the associate construct is replaced with a
block construct of the form

block
  integer n
  n=1
  print*,i[1]
end block

The error disappears if the 'block' and 'end block' statements are deleted.

[Bug sanitizer/85394] [7 Regression] Unable to run sanitized executables on ppc64le Ubuntu and SLES

2018-04-23 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
  Known to work||8.0.1
 Resolution|FIXED   |---
   Assignee|seurer at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
Summary|[8 Regression] Unable to|[7 Regression] Unable to
   |run sanitized executables   |run sanitized executables
   |on ppc64le Ubuntu and SLES  |on ppc64le Ubuntu and SLES
  Known to fail||7.3.0

--- Comment #5 from Martin Liška  ---
The patch has landed to LLVM repository. I bet it's older than GCC 8
regression, but I can't find any entry in changes where we mention that ASAN is
available for ppc64. I'll backport that to GCC 7 at least.

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

2018-04-23 Thread pc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402

--- Comment #15 from pc at gcc dot gnu.org ---
Author: pc
Date: Mon Apr 23 21:14:38 2018
New Revision: 259582

URL: https://gcc.gnu.org/viewcvs?rev=259582&root=gcc&view=rev
Log:
rs6000: Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative
(PR84302)

The powerpc versions of _mm_slli_epi32 and __mm_slli_epi64 in emmintrin.h
do not properly handle shift values between 16 and 31, inclusive.
These are setting up the shift with vec_splat_s32, which only accepts
*5 bit signed* shift values, or a range of -16 to 15.  Values above 15
produce an error:

  error: argument 1 must be a 5-bit signed literal

Fix is to effectively reduce the range for which vec_splat_s32 is used
to < 32 and use vec_splats otherwise.

Also, __mm_slli_epi{16,32,64}, when given a negative shift value,
should always return a vector of {0}.


PR target/83402
* config/rs6000/emmintrin.h (_mm_slli_epi{16,32,64}):
Ensure that vec_splat_s32 is only called with 0 <= shift < 16.
Ensure negative shifts result in {0}.

gcc/testsuite/
PR target/83402
* gcc.target/powerpc/sse2-psllw-1.c: Refactor and add tests for
several values:  positive, negative, and zero.
* gcc.target/powerpc/sse2-pslld-1.c: Same.
* gcc.target/powerpc/sse2-psllq-1.c: Same.

Modified:
branches/ibm/gcc-7-branch/gcc/ChangeLog
branches/ibm/gcc-7-branch/gcc/config/rs6000/emmintrin.h
branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-pslld-1.c
branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-psllq-1.c
branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-psllw-1.c

[Bug fortran/85510] New: Linking error when accessing a coindexed variable inside an associate block

2018-04-23 Thread damian at sourceryinstitute dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85510

Bug ID: 85510
   Summary: Linking error when accessing a coindexed variable
inside an associate block
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

The code below compiles without error with -fcoarray=single; whereas compiling
with -fcoarray=lib generates the link-time error message shown with the
gfortran 7.2.0 and with the trunk dated 20180412.  The gfortran command comes
from the output of the OpenCoarrays command 'caf --show'. Some of the paths
have been shortened manually for presentation purposes:

$ cat communicate-inside-associate.f90 module foo
contains
  subroutine bar()
integer, save :: i[*]=0
associate(n=>1)
  print*,i[1]
end associate
  end subroutine
end module

use foo
end
$ gfortran -I/opt/opencoarrays/include/OpenCoarrays-2.0.0-26-g840374a_GNU-8.0.1
-fcoarray=lib -Wl,-rpath -Wl,/opt/mpich/3.2/lib -Wl,--enable-new-dtags
communicate-inside-associate.f90 /opt/opencoarrays/lib/libcaf_mpi.a
/opt/mpich/3.2/lib/libmpifort.so /opt/mpich/3.2/lib/libmpi.so
/tmp/ccA8dGYe.o: In function `_caf_init.1.3816':
communicate-inside-associate.f90:(.text+0x4d): undefined reference to
`caf_token.0.3815'
/tmp/ccA8dGYe.o: In function `__foo_MOD_bar':
communicate-inside-associate.f90:(.text+0x153): undefined reference to
`caf_token.0.3815'
collect2: error: ld returned 1 exit status
rouson@sourcery-VirtualBox:~/Desktop/Builds/adhoc/src/gnu/nrc/emulated-collectives$
gfortran --version
GNU Fortran (GCC) 8.0.1 20180412 (experimental)

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

2018-04-23 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #11 from Peter Bergner  ---
Is this fixed so we mark it as RESOLVED / FIXED ???

[Bug fortran/70870] Segmentation violation in gfc_assign_data_value

2018-04-23 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70870

--- Comment #9 from Steve Kargl  ---
On Mon, Apr 23, 2018 at 07:46:59PM +, gs...@t-online.de wrote:
> 
> --- Comment #8 from G. Steinmetz  ---
> > These should have a new PR opened for them.
> Done. This is now pr85506.
> 

Thanks.  I had intended to open the new PR when I committed
the patch, but a severe lack of time has caused a delay.

[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread kelvin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

--- Comment #6 from kelvin at gcc dot gnu.org ---
I'll do regression testing on LE and BE (just to be safe) with the new
regression test added to the test suite.

[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32

2018-04-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560

--- Comment #21 from Jason Merrill  ---
Author: jason
Date: Mon Apr 23 20:49:38 2018
New Revision: 259578

URL: https://gcc.gnu.org/viewcvs?rev=259578&root=gcc&view=rev
Log:
PR c++/69560 - wrong alignof(double) on x86.

CWG 1879 - Inadequate definition of alignment requirement.
* cp-tree.h (ALIGNOF_EXPR_STD_P): New.
* typeck.c (cxx_sizeof_or_alignof_type): Add std_alignof parm.
(cxx_sizeof_expr, cxx_sizeof_nowarn, cxx_alignas_expr)
(cxx_alignof_expr): Pass it.
* parser.c (cp_parser_unary_expression): Pass it.
* pt.c (tsubst_copy): Copy it.
(tsubst_copy_and_build): Pass it.
* decl.c (fold_sizeof_expr): Pass it.

Added:
trunk/gcc/testsuite/g++.dg/abi/align2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/libcc1/libcp1plugin.cc

[Bug c++/68374] G++ -Wshadow doesn't warn about static member shadowing

2018-04-23 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68374

Paolo Carlini  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #6 from Paolo Carlini  ---
Mine.

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
.

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Apr 23 20:31:17 2018
New Revision: 259577

URL: https://gcc.gnu.org/viewcvs?rev=259577&root=gcc&view=rev
Log:
PR middle-end/85496
* expr.c (store_field): In the bitfield case, if the value comes from
a function call and is returned in registers by means of a PARALLEL,
do not change the mode of the temporary unless BLKmode and VOIDmode.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr85496.C
  - copied unchanged from r259574,
trunk/gcc/testsuite/g++.dg/torture/pr85496.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/expr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Apr 23 20:29:22 2018
New Revision: 259576

URL: https://gcc.gnu.org/viewcvs?rev=259576&root=gcc&view=rev
Log:
PR middle-end/85496
* expr.c (store_field): In the bitfield case, if the value comes from
a function call and is returned in registers by means of a PARALLEL,
do not change the mode of the temporary unless BLKmode and VOIDmode.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr85496.C
  - copied unchanged from r259574,
trunk/gcc/testsuite/g++.dg/torture/pr85496.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Apr 23 20:19:39 2018
New Revision: 259574

URL: https://gcc.gnu.org/viewcvs?rev=259574&root=gcc&view=rev
Log:
PR middle-end/85496
* expr.c (store_field): In the bitfield case, if the value comes from
a function call and is returned in registers by means of a PARALLEL,
do not change the mode of the temporary unless BLKmode and VOIDmode.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr85496.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85500] INCORRECTLY REPORTED

2018-04-23 Thread aaron_sami_abassi at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500

--- Comment #2 from ASA  ---
(In reply to Jonathan Wakely from comment #1)
> This is not a valid bug report, see https://gcc.gnu.org/bugs/ for what we
> require.
> 
> (In reply to ASA from comment #0)
> > When initializing an auto variable from a function identifier, GNU C++ is
> > incorrectly defining a new function.
> > 
> > The statement:
> > 
> > auto variable_name = function_name;
> > 
> > Will define a function or nested function depending on the scope of
> > reference named variable_name.  This is not a pedantically correct
> > interpretation of the C++ source code as only variables can be initialized.
> 
> 
> Here's a complete program:
> 
> #include 
> 
> int function_name() { return 0; }
> 
> auto variable_name = function_name;
> 
> static_assert(std::is_pointer::value, "");
> 
> int main()
> {
> return (*variable_name)();
> }
> 
> This shows that your statement is not creating a new function, it's a
> pointer to function. You cannot copy functions or declare them as variables,
> so the 'auto' declaration performs function-to-pointer decay and so deduces
> a function pointer type not a function type.
> 
> > 
> > Also be careful in your bug correction:
> > 
> > auto function_name;
> > 
> > Should still be treated as a function declaration when initialization is not
> > present (as of C++14).
> 
> No, that's not valid as a function declaration.

It was a late night.  You are correct that it is producing a function pointer,
not a new function instance.  I re-submitted the bug as id 85509 with correct
details and sample code.  Thank you, my apologies for not sleeping before I
tried to submit a bug report.

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

2018-04-23 Thread developm...@faf-ltd.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

--- Comment #15 from Peter VARGA  ---
(In reply to Jonathan Wakely from comment #14)
> Installing your own glibc in a new location and trying to point GCC to it
> with -I /FaF/glibc/include is not "the default settings".
> 
> As has been explained, you need to rebuild GCC to use the new glibc. To do
> that you also need the Linux kernel headers in the same sysroot tree, i.e.
> /FaF/glibc
> 
> Did you try that yet?

It would be very much appreciated if you could provide me the missing settings
for my configure command line arguments which look for the moment like this:

--prefix=/FaF --infodir=/FaF/share/info --mandir=/FaF/share/man
--libdir=/FaF/lib64 --libexecdir=/FaF/lib64 --enable-languages=c,c++ 
--enable-checking=release --with-gmp=/FaF/ --with-mpfr=/FaF --with-gmc=/FaF
--with-gxx-include-dir=/FaF/include/c++/7.3 --enable-ssp --disable-libssp
--disable-plugin --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-7.3 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux --disable-multilib

[Bug c++/85509] New: auto (function pointer) undermining inline expansion with GCC but not LLVM

2018-04-23 Thread aaron_sami_abassi at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509

Bug ID: 85509
   Summary: auto (function pointer) undermining inline expansion
with GCC but not LLVM
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron_sami_abassi at hotmail dot com
  Target Milestone: ---

Created attachment 44010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44010&action=edit
This code demonstrates the problem

The attached code when compiled with optimizations in LLVM (I'm using 5.0.0)
expands the call inline through the auto variables PerformQuickly and
PerformSafely.

Adding const solves the issue but GCC should be able to determine that the
function pointer can never be modified and inline the function invocations as
LLVM is doing.

[Bug c++/85470] [7 Regression] Strange error about "call to non-constexpr function"

2018-04-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

--- Comment #5 from Jakub Jelinek  ---
Created attachment 44009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44009&action=edit
gcc8-pr85503.patch

Full untested patch.  I've started bootstrap/regtest on powerpc64-linux
(power7, big endian), unfortunately gcc112 is down and so I can't test on
powerpc64le-linux.  If you could do that, I'd appreciate it.

[Bug c/85508] New: runtime error in config/i386/i386.c

2018-04-23 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85508

Bug ID: 85508
   Summary: runtime error in config/i386/i386.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

typedef char a;
typedef b;
c;
d(e) {
  for (;; f()) {
a *g;
b h;
for (h = 0; h < 27; h++)
  for (e = 0; e <= 26; ++e)
*g &= c;
  }
}

compiled by a ubsan version of recent gcc trunk, I get this:

$ ~/gcc/results/bin/gcc -c -O3 -w bug431.c
../../trunk/gcc/config/i386/i386.c:43197:33: runtime error: left shift of
negative value -1
$ ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.259553.ubsan/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.259553.ubsan
--with-build-config=bootstrap-ubsan --disable-multilib --disable-werror
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
gcc version 8.0.1 20180422 (experimental) (GCC)
$

File ../../trunk/gcc/config/i386/i386.c line 43197 is

 x = gen_int_mode (INTVAL (x) << 8, HImode);

[Bug c++/85505] Code accepted despite a variable using the same name as a parameter

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85505

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-23
 Ever confirmed|0   |1

[Bug c++/85470] [7 Regression] Strange error about "call to non-constexpr function"

2018-04-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Apr 23 19:58:57 2018
New Revision: 259572

URL: https://gcc.gnu.org/viewcvs?rev=259572&root=gcc&view=rev
Log:
PR c++/85470 - wrong error with static data member.

* decl.c (check_initializer): Check DECL_INITIALIZED_IN_CLASS_P.
* typeck2.c (store_init_value): Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/extern_template-4.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/decl.c
branches/gcc-7-branch/gcc/cp/typeck2.c

[Bug fortran/85507] New: [8 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258

2018-04-23 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85507

Bug ID: 85507
   Summary: [8 Regression] ICE in gfc_dep_resolver, at
fortran/dependency.c:2258
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Introduced recently, between 20180325 and 20180422 :


$ cat z1.f90
program p
   integer :: x[*]
   x[2] = x
end


$ cat z2.f90
subroutine sub (n, x)
   integer :: n, x[*]
   x[n] = x
end


$ cat z3.f90
subroutine sub (n, x)
   integer :: i, n, x[*]
   do i = 2, n
  x[i] = x
   end do
end


$ gfortran-8-20180325 -c z1.f90 -fcoarray=lib
$
$ gfortran-8-20180422 -c z1.f90 -fcoarray=lib
z1.f90:3:0:

x[2] = x

internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2258
0x7405a4 gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*)
../../gcc/fortran/dependency.c:2258
0x792595 conv_caf_send
../../gcc/fortran/trans-intrinsic.c:1863
0x798a8d gfc_conv_intrinsic_subroutine(gfc_code*)
../../gcc/fortran/trans-intrinsic.c:10981
0x74abb2 trans_code
../../gcc/fortran/trans.c:1887
0x771f99 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x701120 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x701120 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x747e2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/70870] Segmentation violation in gfc_assign_data_value

2018-04-23 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70870

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #8 from G. Steinmetz  ---
> These should have a new PR opened for them.
Done. This is now pr85506.

[Bug fortran/85506] New: ICE in gfc_assign_data_value, at fortran/data.c:448

2018-04-23 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85506

Bug ID: 85506
   Summary: ICE in gfc_assign_data_value, at fortran/data.c:448
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Extracted from pr70870, in consequence of pr70870 comment 7.


$ cat z1.f90
program p
   type t
  integer :: n
   end type
   type(t), pointer :: z => null()
   data z%n / 3 /
   print *, z%n
end


$ gfortran-8-20180422 -c z1.f90
f951: internal compiler error: in gfc_assign_data_value, at fortran/data.c:448
0x68e5a9 gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
__mpz_struct (*) [1])
../../gcc/fortran/data.c:448
0x711339 check_data_variable
../../gcc/fortran/resolve.c:15477
0x711682 traverse_data_var
../../gcc/fortran/resolve.c:15606
0x71c151 resolve_data
../../gcc/fortran/resolve.c:15661
0x71c151 resolve_types
../../gcc/fortran/resolve.c:16479
0x7177ec gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16568
0x700f4a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x700f4a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x747e2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread kelvin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

--- Comment #4 from kelvin at gcc dot gnu.org ---
Thanks for chasing down the cause of the problem.  I agree with the patch
proposed by jakub, assuming it passes regression testing.

Would you like me to do the testing?  (be glad to unless someone else has
already started the effort.)

[Bug c++/85505] New: Code accepted despite a variable using the same name as a parameter

2018-04-23 Thread abbeyj+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85505

Bug ID: 85505
   Summary: Code accepted despite a variable using the same name
as a parameter
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

The following code is accepted by GCC although I believe it should not be. 
This happens on all versions and all platforms currently available on
https://gcc.godbolt.org/

Test case:
class C {
public:
  ~C();
};
void Foo(int data) {
  switch (0) {
  case 0:;
  }
  C b;
  float data;
}


I would have expected an error here like:
error: declaration of 'float data' shadows a parameter

Note that you do get this error if you comment out (seemingly unrelated) lines
from the test case.

Shout out to https://embed.cs.utah.edu/creduce/ for providing the above reduced
test case.

[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

--- Comment #3 from Jakub Jelinek  ---
base here is a constant pool constant, containing
(const:DI (plus:DI (symbol_ref:DI ("_ZN26OnHoverHandlerGraphicsItem7cornersE")
[flags 0xc0] )
(const_int 8 [0x8])))
so this fails both because the symbol_ref in there isn't a constant pool
address, but address of a static data member, but also because it isn't a
symbol_ref, but address within that static data member.

At least for now, I think easiest is to adjust const_load_sequence_p, so that
it better matches what replace_swapped_load_constant expects.
--- gcc/config/rs6000/rs6000-p8swap.c.jj2018-03-20 22:05:58.0
+0100
+++ gcc/config/rs6000/rs6000-p8swap.c   2018-04-23 21:12:22.259096174 +0200
@@ -593,8 +593,10 @@ const_load_sequence_p (swap_web_entry *i
 remove this special test.  */
  rtx const_vector = get_pool_constant (base);
  if (GET_CODE (const_vector) == SYMBOL_REF
- && !CONSTANT_POOL_ADDRESS_P (const_vector))
-   return false;
+ && CONSTANT_POOL_ADDRESS_P (const_vector))
+   const_vector = get_pool_constant (const_vector);
+ if (GET_CODE (const_vector) != CONST_VECTOR)
+   return false;
}
}
 }

[Bug c++/85470] [7/8 Regression] Strange error about "call to non-constexpr function"

2018-04-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Apr 23 19:11:22 2018
New Revision: 259571

URL: https://gcc.gnu.org/viewcvs?rev=259571&root=gcc&view=rev
Log:
PR c++/85470 - wrong error with static data member.

* decl.c (check_initializer): Check DECL_INITIALIZED_IN_CLASS_P.
* typeck2.c (store_init_value): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/extern_template-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/typeck2.c

[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-23
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Can't reproduce on the original testcase, can on the reduced one, which isn't
really good (requires -fpermissive and has lots of UB in it).
Anyway, on that #c1 testcase this started with r254437.

Now, if I modify the reduced testcase this way, so it doesn't need -fpermissive
and has __builtin_unreachable () in the spots where falling through into the
end of a function/method returning non-void, it starts earlier with r253240:

namespace b {
template < int c > struct d { static constexpr int e = c; };
typedef d< false > f;
template < typename g > struct h { typedef g i; };
template < typename > class j;
template < bool, bool, typename... > struct aa;
struct k {
  template < typename n, typename... q >
  static h< decltype(n()(q()...)) > o(int);
};
template < typename p, typename... t > struct aa< false, false, p, t... > : k {
  typedef decltype(o< p, t... >(0)) i;
};
template < typename p, typename... t >
struct ab : aa< f::e, f::e, p, t... >::i {};
template < typename p, typename... t > struct j< p(t...) > : ab< p, t... > {};
} enum { r, s };
typedef long x;
template < typename > struct ac;
template < typename y > struct ac< y & > { typedef y i; };
template < typename y > struct j { typedef typename b::j< y >::i i; };
template < typename > struct ad;
template < typename > struct ae;
template < typename > class af;
template < typename, int ag, int ah, int = 0, int = ag, int = ah > class ai;
template < typename > class aj;
template < typename, typename, typename > class ak;
template < typename > class al;
template < typename > struct am;
template < typename > struct an;
template < typename y > struct ao { typedef typename am< y >::i i; };
struct aq {
  typedef const ai< double, 2, 1 > &ar;
};
template < typename as > struct at { typedef aj< as > i; };
template < typename as > struct au { typedef typename at< as >::i i; };
template < typename av > av aw(const typename an< av >::i *);
template < typename av, int > av az(const typename an< av >::i *ba) {
  return aw< av >(ba);
}
typedef __attribute__((altivec(vector__))) double bb;
template <> struct am< double > { typedef bb i; };
template <> struct an< bb > { typedef double i; };
template <> bb aw(const double *ba) { return __builtin_vec_vsx_ld(0, ba); }
struct bc {
  template < typename av > int bd(av a) { bd(a); __builtin_unreachable (); }
};
struct be {
  double operator()(const int, const int);
};
template < typename as > class bf : public ae< as > {
public:
  typedef typename ad< as >::bg bg;
  using ae< as >::bh;
  enum { bi };
  bg bj() const;
  template < typename bk > bg bl(const bk &) const;
};
template < typename as > class aj : public bf< as > {
public:
  using bf< as >::bh;
  template < typename bm > ak< be, const as, const bm > operator-(bm bn) {
return ak< be, const as, const bm >(bh(), bn);
  }
  int bo() const;
  al< as > array() { return bh(); }
};
template < typename as > struct ae {
  const as &bh() const { return *static_cast< const as * >(this); }
};
template < typename > struct bp;
template < typename > struct bq;
template < typename y > struct br : bq< y > {
  br(y bs) : bq< y >(bs) {}
};
template < typename y > struct br< const y > : br< y > {
  br(const y &bs) : br< y >(bs) {}
};
template < typename as > struct br< af< as > > {
  typedef as bt;
  br(const bt &m) : bu(m.bv()) {}
  template < int bw, typename ay > ay bx(x, x by) {
return az< ay, bw >(bu + by);
  }
  const typename bt::bg *bu;
};
template < typename bg, int u, int bz, int ca, int cb, int cc >
struct br< ai< bg, u, bz, ca, cb, cc > > : br< af< ai< bg, u, bz > > > {
  typedef ai< bg, u, bz > cd;
  br(const cd &m) : br< af< cd > >(m) {}
};
template < typename bk, typename ce, typename cf >
struct br< ak< bk, ce, cf > > : bp< ak< bk, ce, cf > > {
  br(ak< bk, ce, cf > bs) : bp< ak< bk, ce, cf > >(bs) {}
};
template < typename bk, typename ce, typename cf >
struct bp< ak< bk, ce, cf > > {
  bp(ak< bk, ce, cf > bs) : cg(), ch(bs.ci()) {}
  template < int bw, typename ay > ay bx(x cj, x by) {
return ch.template bx< bw, ay >(cj, by);
  }
  ce cg;
  br< cf > ch;
};
template < typename cd > struct v {
  typedef typename ac< typename cd::ck >::i cl;
  v(cl &arg) : cn(arg) {}
  template < int bw, typename ay > ay bx(x cj, x by) {
return cn.template bx< bw, ay >(cj, by);
  }
  br< cl > cn;
};
template < typename cm > struct bq< al< cm > > : v< al< cm > > {
  bq(al< cm > w) : v< al< cm > >(w.dd()) {}
};
template < typename as > class ap : public bf< as > {};
template < int ax > struct co {

Re: bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint

2018-04-23 Thread Jim Wilson

On 04/23/2018 07:11 AM, Jason Vas Dias wrote:


I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
(with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :

  $ echo '
  typedef unsigned short U16_t;
  static void f(void)
  { U16_t a = 1;
a-=1;
  }' > t.C;


g...@gcc.gnu.org dropped as inappropriate.  Note that gcc-bugs is output 
from our bugzilla.  Sending email here isn't very useful.  If you want a 
bug fixed, you have to open a bug report in bugzilla.  You can ask gcc 
questions on gcc help.


In the C language, operations on short and always performed as int, and 
then converted back to short.  Subtracting one may generated a negative 
number, which converted to unsigned short will change its value.  So the 
warning seems appropriate.


Note that -Wconversion means different things in different gcc versions. 
 It current meaning is to warn for any implicit cast that may change a 
value.  This is not very useful in general, and is not an option that I 
would recommend using by default.  In old gcc versions, -Wconversion 
warned for code that had different meaning in K&R C and ISO C.  That was 
useful, and some people used that option by default, but the option no 
longer does that.


You can silence the warning by adding an explicit cast.
   a = (U16_t) (a - 1);

Jim


[Bug middle-end/85504] New: Bogus -Wrestrict warning with -fsanitize=undefined

2018-04-23 Thread bernd.edlinger at hotmail dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85504

Bug ID: 85504
   Summary: Bogus -Wrestrict warning with -fsanitize=undefined
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Created attachment 44008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44008&action=edit
unreduced test case

This happens with current openssl trunk revision:

./config -fsanitize=undefined --strict-warnings

$ gcc  -I. -Icrypto/include -Iinclude -fPIC -pthread -m64  -Wa,--noexecstack
-DDEBUG_UNUSED -DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -Wswitch -Wsign-compare
-Wmissing-prototypes -Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3
-fsanitize=undefined -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC
-DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM
-DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM
-DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\""
-DNDEBUG  -MMD -MF crypto/engine/eng_ctrl.d.tmp -MT crypto/engine/eng_ctrl.o -c
-o crypto/engine/eng_ctrl.o crypto/engine/eng_ctrl.c
crypto/engine/eng_ctrl.c: In function 'ENGINE_ctrl':
crypto/engine/eng_ctrl.c:110:23: error: 'strcpy' source argument is the same as
destination [-Werror=restrict]
 return strlen(strcpy(s, cdp->cmd_name));
   ^~~~

while I can use -save-temps with this one (see attached test case)
there is another file which does not show the error with -save-temps:

$ gcc  -I. -Iinclude -Iapps -pthread -m64  -Wa,--noexecstack -DDEBUG_UNUSED
-DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wswitch -Wsign-compare -Wmissing-prototypes
-Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3 -fsanitize=undefined
-DNDEBUG  -MMD -MF apps/s_client.d.tmp -MT apps/s_client.o -c -o
apps/s_client.o apps/s_client.c

In file included from /usr/include/string.h:635,
 from apps/s_client.c:15:
apps/s_client.c: In function 's_client_main':
apps/s_client.c:2585:13: error: '__builtin_strncpy' source argument is the same
as destination [-Werror=restrict]
 strncpy(sbuf, mbuf, 2);
 ^~~

$ gcc  -I. -Iinclude -Iapps -pthread -m64  -Wa,--noexecstack -DDEBUG_UNUSED
-DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wswitch -Wsign-compare -Wmissing-prototypes
-Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3 -fsanitize=undefined
-DNDEBUG  -MMD -MF apps/s_client.d.tmp -MT apps/s_client.o -c -o
apps/s_client.o apps/s_client.c -save-temps

[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

Segher Boessenkool  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/85470] [7/8 Regression] Strange error about "call to non-constexpr function"

2018-04-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||segher at gcc dot gnu.org

[Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

--- Comment #1 from Matthias Klose  ---
$ cat gasgraphics.ii
# 3 "" 3
namespace b {
template < int c > struct d { static constexpr int e = c; };
typedef d< false > f;
template < typename g > struct h { typedef g i; };
template < typename > class j;
template < bool, bool, typename... > struct aa;
struct k {
  template < typename n, typename... q >
  static h< decltype(n()(q()...)) > o(int);
};
template < typename p, typename... t > struct aa< false, false, p, t... > : k {
  typedef decltype(o< p, t... >(0)) i;
};
template < typename p, typename... t >
struct ab : aa< f::e, f::e, p, t... >::i {};
template < typename p, typename... t > struct j< p(t...) > : ab< p, t... > {};
} enum { r, s };
typedef long x;
template < typename > struct ac;
template < typename y > struct ac< y & > { typedef y i; };
template < typename y > struct j { typedef typename b::j< y >::i i; };
template < typename > struct ad;
template < typename > struct ae;
template < typename > class af;
template < typename, int ag, int ah, int = 0, int = ag, int = ah > class ai;
template < typename > class aj;
template < typename, typename, typename > class ak;
template < typename > class al;
template < typename > struct am;
template < typename > struct an;
template < typename y > struct ao { typedef typename am< y >::i i; };
struct aq {
  typedef const ai< double, 2, 1 > &ar;
};
template < typename as > struct at { typedef aj< as > i; };
template < typename as > struct au { typedef typename at< as >::i i; };
template < typename av > av aw(const typename an< av >::i *);
template < typename av, int > av az(const typename an< av >::i *ba) {
  return aw< av >(ba);
}
typedef __attribute__((altivec(vector__))) double bb;
template <> struct am< double > { typedef bb i; };
template <> struct an< bb > { typedef double i; };
template <> bb aw(const double *ba) { return __builtin_vec_vsx_ld(0, ba); }
struct bc {
  template < typename av > bd(av a) { bd(a); }
};
struct be {
  double operator()(const, const);
};
template < typename as > class bf : public ae< as > {
public:
  typedef typename ad< as >::bg bg;
  ae< as >::bh;
  enum { bi };
  bg bj() const;
  template < typename bk > bg bl(const bk &) const;
};
template < typename as > class aj : public bf< as > {
public:
  bf< as >::bh;
  template < typename bm > ak< be, const as, const bm > operator-(bm bn) {
return ak< be, const as, const bm >(bh(), bn);
  }
  bo() const;
  al< as > array() { return bh(); }
};
template < typename as > struct ae {
  const as &bh() const { return *static_cast< const as * >(this); }
};
template < typename > struct bp;
template < typename > struct bq;
template < typename y > struct br : bq< y > {
  br(y bs) : bq< y >(bs) {}
};
template < typename y > struct br< const y > : br< y > {
  br(const y &bs) : br< y >(bs) {}
};
template < typename as > struct br< af< as > > {
  typedef as bt;
  br(const bt &m) : bu(m.bv()) {}
  template < int bw, typename ay > ay bx(x, x by) {
return az< ay, bw >(bu + by);
  }
  const typename bt::bg *bu;
};
template < typename bg, int u, int bz, int ca, int cb, int cc >
struct br< ai< bg, u, bz, ca, cb, cc > > : br< af< ai< bg, u, bz > > > {
  typedef ai< bg, u, bz > cd;
  br(const cd &m) : br< af< cd > >(m) {}
};
template < typename bk, typename ce, typename cf >
struct br< ak< bk, ce, cf > > : bp< ak< bk, ce, cf > > {
  br(ak< bk, ce, cf > bs) : bp< ak< bk, ce, cf > >(bs) {}
};
template < typename bk, typename ce, typename cf >
struct bp< ak< bk, ce, cf > > {
  bp(ak< bk, ce, cf > bs) : cg(), ch(bs.ci()) {}
  template < int bw, typename ay > ay bx(x cj, x by) {
return ch.template bx< bw, ay >(cj, by);
  }
  ce cg;
  br< cf > ch;
};
template < typename cd > struct v {
  typedef typename ac< typename cd::ck >::i cl;
  v(cl &arg) : cn(arg) {}
  template < int bw, typename ay > ay bx(x cj, x by) {
return cn.template bx< bw, ay >(cj, by);
  }
  br< cl > cn;
};
template < typename cm > struct bq< al< cm > > : v< al< cm > > {
  bq(al< cm > w) : v< al< cm > >(w.dd()) {}
};
template < typename as > class ap : public bf< as > {};
template < int ax > struct co { double array[ax]; };
template < int ax > class cq {
  co< ax > bu;

public:
  const double *bv() const { return bu.array; }
};
template < typename as > class af : public at< as >::i {
public:
  typedef typename at< as >::i cp;
  cq< cp::bi > cs;
  const typename ad< as >::bg *bv() const { return cs.bv(); }
};
template < typename cr, int ag, int ah, int cu, int ct, int cw >
struct ad< ai< cr, ag, ah, cu, ct, cw > > {
  typedef cr bg;
};
template < typename, int ag, int ah, int, int, int >
class ai : public af< ai< double, ag, ah > > {
  typedef ai cv;
};
template < typename bk, typename ce, typename cf >
struct ad< ak< bk, ce, cf > > {
  typedef typename j< bk(typename ce::bg, typename cf::bg) >::i bg;
};
template < typename, typename, typename > class z;
template < typename bk, typename cy, typename cx >
class ak : public z< bk, cy, cx > 

[Bug target/85503] New: [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu

2018-04-23 Thread doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85503

Bug ID: 85503
   Summary: [8 Regression] ICE in replace_swapped_load_constant,
at config/rs6000/rs6000-p8swap.c:1853 on
powerpc64le-linux-gnu
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44007&action=edit
preprocessed source

seen with r259383 on the trunk, powerpc64le-linux-gnu, worked around with -O2:

$ g++ -Wall -std=gnu++11 -c -O2 gasgraphics.ii 
during RTL pass: swaps
: In function �int GasGraphicsItemcreateOnHoverHandler()�:
:211:1: internal compiler error: in replace_swapped_load_constant, at
config/rs6000/rs6000-p8swap.c:1853
Please submit a full bug report,
with preprocessed source if appropriate.

gcc configured with

--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/powerpc64le-linux-gnu-as
--with-ld=/usr/bin/powerpc64le-linux-gnu-ld --program-suffix=-8
--program-prefix=powerpc64le-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin
--enable-default-pie --with-system-zlib --disable-libphobos
--enable-objc-gc=auto --enable-secureplt --with-cpu=power8
--enable-targets=powerpcle-linux --disable-multilib --enable-multiarch
--disable-werror --with-long-double-128 --enable-checking=release
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu

[Bug gcov-profile/85201] [GCOV] A statement with two && operators and a comma operator in the for loop body is wrongly marked in gcov

2018-04-23 Thread yangyibiao at nju dot edu.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85201

--- Comment #2 from Yibiao Yang  ---
@marxin Is this a real bug? or this bug is only default behavior?

[Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403

2018-04-23 Thread abel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85423

--- Comment #5 from Andrey Belevantsev  ---
Author: abel
Date: Mon Apr 23 15:19:06 2018
New Revision: 259563

URL: https://gcc.gnu.org/viewcvs?rev=259563&root=gcc&view=rev
Log:
PR rtl-optimization/85423

* sel-sched-ir.c (has_dependence_note_mem_dep): Only discard
dependencies to debug insns when the previous insn is non-debug.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr85423.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85501] missed if-conversion / phiopt trick

2018-04-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85501

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For scalar code or vector code?  For the latter, it needs a gather load, which
is expensive...

[Bug c/65892] gcc fails to implement N685 aliasing of union members

2018-04-23 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #39 from joseph at codesourcery dot com  ---
On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:

> Code which relies upon this feature to implement a C-style approximation to
> inheritance has been fairly common, which is precisely why the C committee
> decided to create this rule, to make sure such code had well-defined behavior.

To make sure such code had well-defined behavior *notwithstanding the 
adjacent rule (in C90) that access to a non-current union member was 
otherwise implementation-defined*.  Not overriding any other rule 
elsewhere in the standard that might make such accesses undefined, such as 
type-based aliasing, even though it's subsequently sometimes been 
interpreted in connection with such rules (and access to a non-current 
union member is now non-normatively specified in a footnote as type 
punning).

bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint

2018-04-23 Thread Jason Vas Dias

I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
(with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :

 $ echo '
 typedef unsigned short U16_t;
 static void f(void)
 { U16_t a = 1;
   a-=1;
 }' > t.C;

 $ g++ -std=c++14 -Wall -Wextra -pedantic -Wc++11-compat \
   -Wconversion -Wcast-align -Wcast-qual -Wfloat-equal \
   -Wmissing-declarations -Wlogical-op -Wpacked -Wundef \
   -Wuninitialized -Wvariadic-macros -Wwrite-strings \
   -c t.C -o /dev/null
 t.C:4:8: conversion to 'U16_t' {aka short unsigned int} from 'int' may \
  alter its value.

I don't control the warning flags, as shown above,
that my code must compile against without warnings.

But I think the warning issued above is a GCC bug -
when I look at the code generated, (compile with -S -o t.S),
I see it actually does generate a 16-bit subtraction, which
is what I wanted:

.file   "t.C"
.text
.globl  _Z1fv
.type   _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movw$1, -2(%rbp)
subw$1, -2(%rbp)
#    this is a two-byte word subtract
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   _Z1fv, .-_Z1fv
.ident  "GCC: (GNU) 6.4.1 20180321"
.section.note.GNU-stack,"",@progbits



So why is it generating a warning about conversion from 'int' ?

I don't see any conversion going on in assembler output -
(cast 'a' to a temporary int, do 32-bit integer subtraction of  '1'
 from it, and store sign-extended low 16 bits in 'a' - this is NOT
 what is going on here ) .

I'd like to remove either '-pedantic' or '-Wconversion' from the
warning flags, but this is not an option .

Please can GCC fix this warning bug eventually - I have to wade
through code that generates thousands of them per compilation.

Thanks & Best Regards,
Jason




[Bug target/85434] Address of stack protector guard spilled to stack on ARM

2018-04-23 Thread thopre01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434

--- Comment #7 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #6)
> (In reply to Thomas Preud'homme from comment #3)
> > 
> > My feeling is that the target patterns should also do the address
> > computation, ie stack_protect_set and stack_protect_test would take that MEM
> > of symbol_ref instead of expanding it first.
> 
> The more I think about it the more I think it's the only way to guarantee
> the guard's address does not end up in a register that could be spilled. The
> spilling itself is more likely to happen when reading the GOT entry that
> holds the guard's address is not represented by an UNSPEC because then the
> address computed when setting the canari is reused when doing the
> comparison. UNSPEC seems to prevent that (even though it's not
> UNSPEC_VOLATILE).

I'm experimenting with a patch to mark the MEM to access the GOT entry as
volatile in ARM backend in order to prevent CSE. It works on this PR's testcase
so will give bootstrap and regression testing a try. As I said, this doesn't
fully solve the underlying issue IMO but together with implementation of
stack_protect_set and stack_protect_test in ARM it should make stack protector
as reliable on ARM targets as on AArch64.

Re: Wrong snprintf optimalization

2018-04-23 Thread Marek Polacek
On Sat, Apr 21, 2018 at 11:47:52AM +0200, Dávid Bolvanský wrote:
> Hello,
> 
> #include 
> int main(void)
> {
> char buf[10];
> return snprintf(buf, 0, "string");
> }
> 
> GCC simplifies it to
> main:
> mov eax, 6
> ret
> 
> but 0 is correct I think.

No, 6 seems to be the correct value:
If the output was truncated due to this limit, then the return value
is the number of characters (excluding the terminating null byte) which would 
have been  written
to  the  final  string if enough space had been available.

Marek


[Bug c/65892] gcc fails to implement N685 aliasing of union members

2018-04-23 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #38 from rguenther at suse dot de  ---
On Fri, 20 Apr 2018, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> 
> --- Comment #35 from Martin Sebor  ---
> Here are the proposed changes:
> 
> Pointer Provenance:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm#proposed-technical-corrigendum

Mostly sound.  It seems to mirror what GCC does in points-to analysis,
also tracking pointers through integer (parts).  I wonder about
the Unary arithmetic operator restriction - consider 'long p' with single
provenance, then +p has empty provenance.  That's just odd.  I'd
have expected for example -(-p) to have the same provenance as p.
GCC just uses the same provenance as the operand for unary operators.
GCC also tracks provenance through floating-poing values (yes! matlab
generated code passes pointers through two FP parameters...).

The clarification to 6.5.9#6 is most welcome since it matches what
GCC expects (and GCC doesn't implement -fno-provenance - well, I guess
you could use -fno[-ipa]-pta.


> Trap Representations:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2220.htm#proposed-technical-corrigendum

Not sure what the proposed change to 6.3.2.1p2 means (if there's similar
wording when actually "reading" an uninitialized value elsewhere).  Iff
that makes reads from uninitialized memory well-defined I miss the
definition of said well-defined behavior.

In any case removing the dependence on address-taken or not is good.
Instead of making it explicitely defined maybe remove this sentence.

For 6.3.1.2 I'd say 'the behavior is undefined' instead of
'an unspecified value'.  What's the reason to be not specific here
when one doesn't want 'undefined' behavior?  In particular in the
light of 3.19.3 if the _Bool is a trap representation then this
looks suspicious.

So the idea is to make uninitialized reads return unspecified values
but not invoke undefined behavior.  Offhand I don't know a place
where GCC would take advantage of the difference.  I think for both
we can derive 1 == uninitialized to be true or false statically as we like
but we cannot infer a path to be not taken when it would access an
uninitialized location (I think we don't do that at the moment).

The change doesn't require us to compute x == x to true if x is
uninitialized?

> Unspecified Values:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2221.htm#proposed-technical-corrigendum

So for 3.4 GCC implements a more strict handling for example treating
a *  as not undefined given there's a value of a (zero)
where the expression is fully defined.  So with 3.4 '0 + '
invokes undefined behavior?  That seems to contradict the proposed
wording - there isn't any value of  where the add invokes
undefined behavior.  More to the point why do they introduce undefined
behavior here rather than an unspecified value?  This means that
 on it's own is fine to use but computing
 +  is not.

And in 3.5 they go on and specify '0 * ' as unspecified?!

So I think they go a bit too far here on several accounts.
I'd like to keep reading from uninitialized memory invoking undefined
behavior - if it's just unspecified how are sanitizers supposed to
handle this given the compiler is now free to schedule such reads to
places where they might not have been executed before.



The changes do not seem to cover effective types and aliasing
as far as I can see (or I missed a non-linked proposed corrigendum).
N doesn't seem to have any.

[Bug c++/16070] print something useful instead of

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16070

--- Comment #9 from Jonathan Wakely  ---
I suppose we could potentially have a special case for:

16070.cc:9:13: note:   couldn't deduce template parameter 'T'

It could say:

16070.cc:9:13: note:   couldn't deduce template parameter 'T' from an
overloaded function, because all overloads are equally good.

[Bug target/81652] [meta-bug] -fcf-protection=full bugs

2018-04-23 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
Bug 81652 depends on bug 85489, which changed state.

Bug 85489 Summary: config/x86/sjlj.S should use unsigned integer to unwind 
shadow stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85489

   What|Removed |Added

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

[Bug libitm/85489] config/x86/sjlj.S should use unsigned integer to unwind shadow stack

2018-04-23 Thread hjl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85489

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 23 12:29:00 2018
New Revision: 259559

URL: https://gcc.gnu.org/viewcvs?rev=259559&root=gcc&view=rev
Log:
x86/cet: Use unsigned integer to unwind shadow stack

Use unsigned integer to unwind shadow stack by replacing jle with jbe and
jg with ja.

PR target/85489
* config/x86/sjlj.S (GTM_longjmp): Replace jle/jg with jbe/ja.

Modified:
trunk/libitm/ChangeLog
trunk/libitm/config/x86/sjlj.S

[Bug libitm/85489] config/x86/sjlj.S should use unsigned integer to unwind shadow stack

2018-04-23 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85489

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug c++/16070] print something useful instead of

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16070

--- Comment #8 from Jonathan Wakely  ---
Reduced:

template struct basic_ios { };
template basic_ios& endl(basic_ios& x) { return x; }

template
voidBar(const T&) {}
voidBar(int) {}

int main() {
Bar(endl);
}

GCC trunk says:

16070.cc: In function 'int main()':
16070.cc:9:13: error: no matching function for call to 'Bar()'
 Bar(endl);
 ^
16070.cc:5:9: note: candidate: 'template void Bar(const T&)'
 voidBar(const T&) {}
 ^~~
16070.cc:5:9: note:   template argument deduction/substitution failed:
16070.cc:9:13: note:   couldn't deduce template parameter 'T'
 Bar(endl);
 ^
16070.cc:6:9: note: candidate: 'void Bar(int)'
 voidBar(int) {}
 ^~~
16070.cc:6:9: note:   no known conversion for argument 1 from '' to 'int'


Clang says:

16070.cc:9:5: error: no matching function for call to 'Bar'
Bar(endl);
^~~
16070.cc:6:9: note: candidate function not viable: no overload of 'endl'
matching 'int' for 1st argument
voidBar(int) {}
^
16070.cc:5:9: note: candidate template ignored: couldn't infer template
argument 'T'
voidBar(const T&) {}
^
1 error generated.


EDG says:

"16070.cc", line 9: error: no instance of overloaded function "Bar" matches the
  argument list
argument types are: ()
  Bar(endl);
  ^

1 error detected in the compilation of "16070.cc".



I don't think there's *much* room for improvement in GCC's output (but see
below).

(In reply to Ivan Godard from comment #4)
> Hence what the compiler should produce is something like:
> 
> Error: file crud line 234
> Cannot identify unique overload in call. Arguments are:
> Foo(void (*)(int))
> Foo(void (*)(char))
> note: some arguments are overloaded functions; at least one of the overloads
> must match in its argument position

This isn't possible in your example, because endl is a function template, not
just an overloaded function. That means the list of possible overloads is
infinite, so you can't possible list all the overloads. There's only one
function template, but an unbounded set of possible specializations of that
function template that could be deduced in correct code.

> overloads considered were:  
>file foo line 17: ..; does not match because no possible
> argument satisfied the template at argument position 1
>file bar line 23: ..; does not match because no possible
> argument satisfied the template at argument position 1
>file baz line 5: ..; does not match because no argument 1 can
> be coerced to type int

This is pretty much what GCC does nowadays (and it can result in hundreds of
lines of output, which has its own problems, but at least all the information
is there for the user to inspect if they want to).

One possible improvement I can imagine would be to special case some
diagnostics to give a different message when there's an overload set involved.
That seems to be what Clang does. Instead of:

16070.cc:6:9: note:   no known conversion for argument 1 from '' to 'int'

we could have a custom diagnostic for the  case, like:

16070.cc:6:9: note:   no overload of 'endl' can be converted to 'int'

Personally I don't find this any clearer, but maybe people less used to GCC's
errors would prefer it.

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

2018-04-23 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85422

Tom de Vries  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, patch

--- Comment #11 from Tom de Vries  ---
patch submitted: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01041.html

[Bug c++/19741] suboptimal error message for template functions (as opposed to non-templates)

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19741

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2006-01-15 21:09:27 |2018-4-23

--- Comment #7 from Jonathan Wakely  ---
Reduced to remove the irrelevant parts and demonstrate the difference between
calls to non-template and temploid functions:

template void Func( T ) { }

typedef bool (*op_func)( int );

void Exec( op_func ) { }

template
struct Op
{
  static void Exec( op_func ) { }
};

int main( )
{
  Exec( &Func );
  Op::Exec( &Func );
}

t.cc:17:20: error: no matches converting function 'Func' to type 'op_func' {aka
'bool (*)(int)'}
   Exec( &Func );
^
t.cc:1:27: note: candidate is: 'template void Func(T)'
 template void Func( T ) { }
   ^~~~
t.cc:18:29: error: no matching function for call to 'Op::Exec()'
   Op::Exec( &Func );
 ^
t.cc:10:15: note: candidate: 'static void Op::Exec(op_func) [with T = int;
op_func = bool (*)(int)]'
   static void Exec( op_func ) { }
   ^~~~
t.cc:10:15: note:   no known conversion for argument 1 from '' to 'op_func' {aka 'bool (*)(int)'}

[Bug c++/50462] poor diagnostics for missing parenthesis in call to method

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462

--- Comment #4 from Jonathan Wakely  ---
I think the original example in this bug is the same as PR 77711 comment 2. It
can be reduced to:

struct ostream { };

void operator<<(ostream, int) { }
void operator<<(ostream, void*) { }
void operator<<(ostream, char*) { }

struct V
{
int size() { return 0; };
};

void print(V v)
{ ostream() << v.size; }


Now GCC's output fits on a single page:

50462.cc: In function 'void print(V)':
50462.cc:14:13: error: no match for 'operator<<' (operand types are 'ostream'
and '')
 { ostream() << v.size; }
   ~~^
50462.cc:3:6: note: candidate: void operator<<(ostream, int)
 void operator<<(ostream, int) { }
  ^~~~
50462.cc:3:6: note:   no known conversion for argument 2 from '' to 'int'
50462.cc:4:6: note: candidate: void operator<<(ostream, void*)
 void operator<<(ostream, void*) { }
  ^~~~
50462.cc:4:6: note:   no known conversion for argument 2 from '' to 'void*'
50462.cc:5:6: note: candidate: void operator<<(ostream, char*)
 void operator<<(ostream, char*) { }
  ^~~~
50462.cc:5:6: note:   no known conversion for argument 2 from '' to 'char*'


But Clang still does better, not bothering to perform overload resolution
hoping v.size will turn into something meaningful. Clang just says:

50462.cc:10:18: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
{ std::cout << v.size; }
   ~~^~~~
 ()
50462.cc:5:6: note: possible target for call
int size() {};
^
50462.cc:6:6: note: possible target for call
int size() const {};
^
1 error generated.

So it doesn't bother telling us that every overload of operator<< is unusable
for a nonsense expression, which is much better.

EDG says:

"50462.cc", line 14: error: a pointer to a bound function may only be used to
  call the function
  { ostream() << v.size; }
   ^

1 error detected in the compilation of "50462.cc".

This is a little cryptic and suggests there might be some non-standard
extension  confusing matters.

[Bug c++/80311] Bound member functions extension allows bogus conversions

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80311

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> struct X {
>   int i = 0;
>   int f() { return i; }
> };
> 
> int main() {
>   X x;
>   using fp = int (*)();
>   auto f = (fp)(&X::f);
>   return f();
> }
> 
> This bogus attempt to use
> https://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html fails,
> because there is no 'this' pointer provided for the call to the bound
> function.

I should have been clearer about how it "fails".

It compiles (and gives a warning about use of the extension unless you silence
it with -Wno-pmf-conversions) but then segfaults at runtime.

> G++ should notice this and give a diagnostic, even with -Wno-pmf-conversions.

The bug is that we shouldn't accept invalid uses of the extension. Valid uses
of the extension should give warnings that can be controlled by
-Wno-pmf-conversions as happens today, but invalid uses should be an error
(maybe controllable by -fpermissive) not produce code that is guaranteed to
segfault.

[Bug c++/77711] Add fix-it hints for missing parentheses in member function call

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711

--- Comment #8 from Jonathan Wakely  ---
My patch doesn't help for comment 2 because we never call
invalid_nonstatic_member_fn when the nonsense expression refers to the name of
an overloaded member function. Instead we perform overload resolution hoping
that one of the overloads will disambiguate a.foo, which will never happen.

See Bug 50462 for a case very similar to comment 2 where we end up with over
200 lines of noise simply because don't stop as soon as we see an invalid
member function call, and try to perform overload resolution on it instead.

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

2018-04-23 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85422

--- Comment #10 from Tom de Vries  ---
Created attachment 44006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44006&action=edit
Adjusted patch with testcase

(In reply to Richard Biener from comment #9)

> adjusted patch:

Added testcase.

Build x86_64 with nvptx accelerator on top of trunk r259523 and tested libgomp,
no issues found.

Doing x86_64 bootstrap and reg-test now.

[Bug tree-optimization/85501] New: missed if-conversion / phiopt trick

2018-04-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85501

Bug ID: 85501
   Summary: missed if-conversion / phiopt trick
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Blocks: 53947, 85466
  Target Milestone: ---

PR85466 shows

For the "if" case, llvm turns:

if (myVector[n] > 0.5){
result[n] = 0.8f;
}
else {
result[n] = 0.1f;
}

into

const float tab[2] = { .8f, .1f };
result[n] = tab[item > .5f];

which is a neat trick.  Profitability is not without questions though
(if you'd do this to scalar code).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466
[Bug 85466] Performance is slow when doing 'branchless' conditional style math
operations

[Bug c++/50462] poor diagnostics for missing parenthesis in call to method

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
See PR 77711 comment 1 where I said:

>It's irrelevant that we can't resolve which overload to use, once name lookup
>finds that 'foo' is a function then a.foo is not a valid expression under any
>circumstances.

The same applies here. The expression 'v.size' (when not followed by
parentheses) is not valid C++. Instead of trying to resolve which operator<<
can be used for a nonsense expression we should just give an error immediately
after parsing v.size, which is what Clang does:

50462.cc:10:18: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
{ std::cout << v.size; }
   ~~^~~~
 ()
50462.cc:5:6: note: possible target for call
int size() {};
^
50462.cc:6:6: note: possible target for call
int size() const {};
^
1 error generated.

[Bug tree-optimization/85478] ICE with single element vector

2018-04-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-23
 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Richard Biener  ---
Ok, confirmed.  The following fixes it:

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 259558)
+++ gcc/tree-vect-loop.c(working copy)
@@ -2492,6 +2492,7 @@ again:
   unsigned int size = STMT_VINFO_GROUP_SIZE (vinfo);
   tree vectype = STMT_VINFO_VECTYPE (vinfo);
   if (! vect_store_lanes_supported (vectype, size, false)
+ && ! known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U)
  && ! vect_grouped_store_supported (vectype, size))
return false;
   FOR_EACH_VEC_ELT (SLP_INSTANCE_LOADS (instance), j, node)

Andreas, can you test this?  It's pre-approved if you make it before RC1.

[Bug target/85491] [8 Regression] nbench LU Decomposition test 15% slower than GCC 7, 30% slower than peak

2018-04-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85491

Richard Biener  changed:

   What|Removed |Added

 Blocks||84037, 84016

--- Comment #2 from Richard Biener  ---
I'll throw it on our tester.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016
[Bug 84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
[Bug 84037] [8 Regression] Speed regression of polyhedron benchmark since
r256644

[Bug target/85491] [8 Regression] nbench LU Decomposition test 15% slower than GCC 7, 30% slower than peak

2018-04-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85491

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-23
 Blocks|79703   |
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[8 Regression] scimark LU   |[8 Regression] nbench LU
   |Decomposition test 15%  |Decomposition test 15%
   |slower than GCC 7, 30%  |slower than GCC 7, 30%
   |slower than peak|slower than peak
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Err, nbench, not scimark2.  So it is indeed r257734.  With r257734 we use
avx128 instead of avx256 for nbench1.c:4293:

for(j=0;j

where the important difference over the polyhedron case is that the
stride step is constant and thus the AGU costs are cheaper.  In addition
to that when using AVX128 the loop is unrolled by a factor of 8 putting
pressure on the FMA units where as you can see above the AVX256 variant
is unrolled by a factor of four only.  When removing -funroll-loops
the performance difference is 6474.8 [6495.3] vs. 4946.8 [4779.1] [numbers
in brackets are those with -funroll-loops on the machine used for debugging].

Given the original case was with variable step an adjustment of the change
could look like

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 259556)
+++ gcc/config/i386/i386.c  (working copy)
@@ -50550,8 +50550,9 @@ ix86_add_stmt_cost (void *data, int coun
  construction cost by the number of elements involved.  */
   if (kind == vec_construct
   && stmt_info
-  && stmt_info->type == load_vec_info_type
-  && stmt_info->memory_access_type == VMAT_ELEMENTWISE)
+  && STMT_VINFO_TYPE (stmt_info) == load_vec_info_type
+  && STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_info) == VMAT_ELEMENTWISE
+  && TREE_CODE (DR_STEP (STMT_VINFO_DATA_REF (stmt_info))) != INTEGER_CST)
 {
   stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
   stmt_cost *= TYPE_VECTOR_SUBPARTS (vectype);

which restores performance.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79703
[Bug 79703] [meta-bug] SciMark 2.0 performance issues

[Bug c++/60531] template function not resolved when comparing functions

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60531

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-23
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Confirmed. Possibly related to PR 64194 although that involves functions with
deduced return types, and this one doesn't.

[Bug c++/64194] [C++14] for function template with auto return

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194

--- Comment #8 from Jonathan Wakely  ---
Slightly different testcase from PR 69620 which is probably the same issue:

struct function {
  template
function(F);
};

template 
auto sum(T1 x, T2 y)
{
return x + y;
}

template 
auto sum(T1 x, T2 y, Targ... args)
{
return sum(x + y, args...);
}

int main()
{
//(void)sum;
function f = sum;
}

ded.cc: In function 'int main()':
ded.cc:21:18: error: conversion from '' to
non-scalar type 'function' requested
 function f = sum;
  ^~


It works if the function is instantiated first by uncommenting the first line
in main.

[Bug c++/64194] [C++14] for function template with auto return

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194

Jonathan Wakely  changed:

   What|Removed |Added

 CC||wuyongwei at gmail dot com

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

[Bug c++/69260] C++14 template instantiation problem in GCC

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69260

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Almost certainly a dup of PR 64194

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

[Bug c++/64194] [C++14] for function template with auto return

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gcc at dcousens dot com

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

[Bug c++/85499] Unable to resolve function with inferred return type

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85499

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
Ah it's one I reported myself.

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

[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82644

--- Comment #4 from Jonathan Wakely  ---
This is only fixed on trunk, but I think I planned to fix it for gcc-7 too.

[Bug target/85486] [og7, nvptx] ref-1.C fails with vector length 128

2018-04-23 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85486

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #1 from Tom de Vries  ---
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=708bb8f7b274553d29242a2d28684b2bc5e734bb
:
...
[nvptx] Force vl32 if calling vector-partitionable routines

2018-04-23  Tom de Vries  

PR target/85486
* omp-offload.c (oacc_fn_attrib_level): Remove static.
* omp-offload.h (oacc_fn_attrib_level): Declare.
* config/nvptx/nvptx.c (has_vector_partitionable_routine_calls_p): New
function.
(nvptx_goacc_validate_dims): Force vector length 32 if offloading
function calls vector-partitionable routines.

* testsuite/libgomp.oacc-c-c++-common/pr85486-2.c: New test.
* testsuite/libgomp.oacc-c-c++-common/pr85486-3.c: New test.
* testsuite/libgomp.oacc-c-c++-common/pr85486.c: New test.
...

Patch with test-cases committed. Marking resolved-fixed.

[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506

--- Comment #2 from Jonathan Wakely  ---
This is fixed on trunk, I'm wondering whether to backport it to gcc-6-branch
and gcc-7-branch.

[Bug c++/85500] auto specifier incorrectly defining new function when initializing from function identifier

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is not a valid bug report, see https://gcc.gnu.org/bugs/ for what we
require.

(In reply to ASA from comment #0)
> When initializing an auto variable from a function identifier, GNU C++ is
> incorrectly defining a new function.
> 
> The statement:
> 
> auto variable_name = function_name;
> 
> Will define a function or nested function depending on the scope of
> reference named variable_name.  This is not a pedantically correct
> interpretation of the C++ source code as only variables can be initialized.


Here's a complete program:

#include 

int function_name() { return 0; }

auto variable_name = function_name;

static_assert(std::is_pointer::value, "");

int main()
{
return (*variable_name)();
}

This shows that your statement is not creating a new function, it's a pointer
to function. You cannot copy functions or declare them as variables, so the
'auto' declaration performs function-to-pointer decay and so deduces a function
pointer type not a function type.

> 
> Also be careful in your bug correction:
> 
> auto function_name;
> 
> Should still be treated as a function declaration when initialization is not
> present (as of C++14).

No, that's not valid as a function declaration.

[Bug c++/85499] Unable to resolve function with inferred return type

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85499

--- Comment #3 from Jonathan Wakely  ---
This is an exact dup of an older bug that I can't find right now.

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

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-23
 Ever confirmed|0   |1

--- Comment #14 from Jonathan Wakely  ---
Installing your own glibc in a new location and trying to point GCC to it with
-I /FaF/glibc/include is not "the default settings".

As has been explained, you need to rebuild GCC to use the new glibc. To do that
you also need the Linux kernel headers in the same sysroot tree, i.e.
/FaF/glibc

Did you try that yet?

[Bug tree-optimization/85478] ICE with single element vector

2018-04-23 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

--- Comment #8 from Andreas Krebbel  ---
The problem is similar to PR83753 but with a different call-chain. Richard
Sandiford fixed it by adding:

  /* First cope with the degenerate case of a single-element
 vector.  */
  if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U))
*memory_access_type = VMAT_CONTIGUOUS;

to get_group_load_store_type.  This prevents vect_grouped_store_supported from
being called for single element vectors. 

For this PR vect_grouped_store_supported is called from vect_analyze_loop_2. I
don't know if there is also a better way to deal with it in the caller?!

But regardless I think vect_grouped_store_supported should return false for
single element vectors as proposed in:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00758.html

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

--- Comment #3 from Eric Botcazou  ---
> but we do:
> 6987/* Handle calls that return values in multiple non-contiguous
> locations.
> 6988   The Irix 6 ABI has examples of this.  */
> 6989if (GET_CODE (temp) == PARALLEL)
> 6990  {
> 6991HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (exp));
> 6992scalar_int_mode temp_mode
> 6993  = smallest_int_mode_for_size (size * BITS_PER_UNIT);
> 6994rtx temp_target = gen_reg_rtx (temp_mode);
> 6995emit_group_store (temp_target, temp, TREE_TYPE (exp), size);
> 6996temp = temp_target;
> 6997  }
> 
> and starting from that temp has a wrong mode (DImode) rather than the
> desired one (SCmode).  I must say I really don't understanding this change,
> before that temp_mode was GET_MODE (temp) except when it was BLKmode or
> VOIDmode.

As stated in the ChangeLog, the point was to avoid clobbering MODE, but I agree
that it's probably a little too bold.

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Fixing.

[Bug libstdc++/85494] implementation of random_device on mingw is useless

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to ookawa_mi from comment #0)
> As the main purpose of random_device is seed of mt19937, it is inappropriate.

It has more uses than just that.

> Please replace to REAL random number generator by rand_s or CryptoAPI.

Confirmed.

[Bug c++/65923] False positive for warning about literal operator suffix and using

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65923

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values

2018-04-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/85500] New: auto specifier incorrectly defining new function when initializing from function identifier

2018-04-23 Thread aaron_sami_abassi at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500

Bug ID: 85500
   Summary: auto specifier incorrectly defining new function when
initializing from function identifier
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron_sami_abassi at hotmail dot com
  Target Milestone: ---

When initializing an auto variable from a function identifier, GNU C++ is
incorrectly defining a new function.

The statement:

auto variable_name = function_name;

Will define a function or nested function depending on the scope of reference
named variable_name.  This is not a pedantically correct interpretation of the
C++ source code as only variables can be initialized.

Also be careful in your bug correction:

auto function_name;

Should still be treated as a function declaration when initialization is not
present (as of C++14).

[Bug tree-optimization/85478] ICE with single element vector

2018-04-23 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

--- Comment #7 from Andreas Krebbel  ---
The cross from comment #6 did not trigger the problem because I accidentally
built it with --disable-checking. Dropping this and adding
--with-long-double-128 triggers the ICE on a full cross as well as on a cross
without sysroot.

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
template  class complex;
template  complex operator* (complex, complex);
template <> struct complex { _Complex float f; };
struct A { complex g, h; complex &foo () { return h; } };

void
bar (complex a, complex c)
{
  A b;
  b.foo () = c * a;
}

expand_normal returns an expression of the right mode:

(parallel:SC [
(expr_list:REG_DEP_TRUE (reg:DI 104)
(const_int 0 [0]))
])

but we do:
6987  /* Handle calls that return values in multiple non-contiguous
locations.
6988 The Irix 6 ABI has examples of this.  */
6989  if (GET_CODE (temp) == PARALLEL)
6990{
6991  HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (exp));
6992  scalar_int_mode temp_mode
6993= smallest_int_mode_for_size (size * BITS_PER_UNIT);
6994  rtx temp_target = gen_reg_rtx (temp_mode);
6995  emit_group_store (temp_target, temp, TREE_TYPE (exp), size);
6996  temp = temp_target;
6997}

and starting from that temp has a wrong mode (DImode) rather than the desired
one (SCmode).  I must say I really don't understanding this change, before that
temp_mode was GET_MODE (temp) except when it was BLKmode or VOIDmode.

Eric, can you please have a look?

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

Jakub Jelinek  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug tree-optimization/85497] [8/9 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2018-04-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497

Richard Biener  changed:

   What|Removed |Added

   Keywords||deferred
   Priority|P3  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
Summary|[8 Regression] [graphite]   |[8/9 Regression] [graphite]
   |ICE in set_codegen_error,   |ICE in set_codegen_error,
   |at  |at
   |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple.
   |c:206   |c:206

--- Comment #2 from Richard Biener  ---
This touches more cases where SCOP analysis only is checking scev_analyzable_p
() but code-gen uses scalar_evolution_in_region with a loop != def-loop.  The
artificial scev-max-expr-size makes one succeed and the other fail.  Note more
complex cases could ICE because of the same reason or because some use site is
really not analyzable.

IMHO scev_analyzable_p should get a 'loop' arg.

Nothing for 8.1.

[Bug middle-end/85496] [6/7/8 Regression] internal compiler error: in emit_move_insn, at expr.c:3722

2018-04-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85496

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-23
 Ever confirmed|0   |1

  1   2   >