[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Can you attach then preprocessed copy.ii, cc1plus command line and copy.s (with
additional -dA) from both r241136 and r241137 +
http://gcc.gnu.org/ml/gcc-patches/2016-10/msg02062.html ?
The test is -std=c++11 and there are no inline variables, so there shouldn't be
any between those two.

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to H.J. Lu from comment #12)
> (In reply to Martin Liška from comment #10)
> > (In reply to H.J. Lu from comment #9)
> > > (In reply to Richard Biener from comment #6)
> > > > Why would we be not able to tailcall in an interupt handler?
> > > 
> > > We need to verify that the only instruction in an interrupt handler
> > > is a tail call to another interrupt handler.  On the other hand,
> > > this interrupt handler isn't really needed at all.
> > 
> > That can be vefief by fact that the symbol should have only one call (tail
> > call) and set node->icf_merged == true.
> 
> Another issue with ICF tail call:
> 
> ;; Function foo1 (foo1, funcdef_no=3, decl_uid=1443, cgraph_uid=0,
> symbol_order=0)
> 
> foo1 (void * p)
> {
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   foo2 (p_2(D)); [tail call]
>   ^^^  This isn't the same as sibcall.
>   return;
>   ^^  Here is a return statement.
> ;;succ:   EXIT
> 
> }

If I remember correctly, this is gimple representation of the tail-call. If you
look at the generated binary, you'll see really just the jump instruction:

foo2:
.LFB1:
.cfi_startproc
movl$4276093056, %eax
movl$0, (%rax)
ret
.cfi_endproc
.LFE1:
.size   foo2, .-foo2
.p2align 4,,15
.globl  foo1
.type   foo1, @function
foo1:
.LFB3:
.cfi_startproc
jmp foo2
.cfi_endproc

[Bug fortran/78122] [5/6/7 Regression] ICE in get, at cgraph.h:395

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-10-27
 CC||marxin at gcc dot gnu.org
   Host|x86_64-apple-darwin13.4.0   |x86_64-apple-darwin13.4.0,
   ||x86_64-linux-gnu
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|internal compiler error: in |[5/6/7 Regression] ICE in
   |get, at cgraph.h:395|get, at cgraph.h:395

--- Comment #1 from Martin Liška  ---
Confirmed, started with 4.8.0. I'll take a look at that.

[Bug c++/78124] [7 regression][c++1z] explicit inheriting constructor is ignored

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-27
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed. According to my bisecting script first affected is r241187.

[Bug rtl-optimization/78127] New: [5/6/7 Regression] AArch64 internal compiler error: in lra_eliminate, at lra-eliminations.c:1440

[ktkachov at gcc dot gnu.org]

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

Bug ID: 78127
   Summary: [5/6/7 Regression] AArch64 internal compiler error: in
lra_eliminate, at lra-eliminations.c:1440
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

The fortran OpenMP testcase gfortran.dg/gomp/pr39354.f90  ICEs when run with an
explicit -O2:

aarch64-none-linux-gnu-gfortran -O2 -fopenmp -S pr39354.f90

pr39354.f90:37:0:

   END

internal compiler error: in lra_eliminate, at lra-eliminations.c:1439
0xa3599f lra_eliminate(bool, bool)
$SRC/gcc/lra-eliminations.c:1439
0xa1df1a lra(_IO_FILE*)
$SRC/gcc/lra.c:2481
0x9d608d do_reload
$SRC/gcc/ira.c:5371
0x9d608d execute
$SRC/gcc/ira.c:
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/78128] New: fortran/resolve.c:resolve_operator miscompiled at -O2

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

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

Bug ID: 78128
   Summary: fortran/resolve.c:resolve_operator miscompiled at -O2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: ia64-*-*

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

$ gcc -O2 -S gfc.c

mov r35 = r32
mov r38 = r1
.body
;;
.mmi
ld8 r34 = [r15]
ld8 r33 = [r14]
addl r14 = 1, r0
;;
.mmi
st4 [r35] = r14, 4
nop 0
mov r40 = r33
.mmb
mov r39 = r34
nop 0
br.call.sptk.many b0 = gfc_kind_max#
;;
.mmi
ld8 r15 = [r32]
mov r1 = r38
addl r41 = 1, r0
.mmi
mov r40 = r32
ld8 r14 = [r34]
mov r39 = r34
;;
.mib
st4 [r35] = r8   <-- stored too late
cmp.eq p6, p7 = r15, r14
(p7) br.cond.dpnt .L6

[Bug middle-end/78025] [5/6/7 Regression] ICE in simd_clone_adjust, at omp-simd-clone.c:1126

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 39906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39906&action=edit
gcc7-pr78025.patch

Untested fix.

[Bug middle-end/78128] [7 regression] fortran/resolve.c:resolve_operator miscompiled at -O2

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

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|target  |middle-end
   Target Milestone|--- |7.0
Summary|fortran/resolve.c:resolve_o |[7 regression]
   |perator miscompiled at -O2  |fortran/resolve.c:resolve_o
   ||perator miscompiled at -O2

--- Comment #1 from Andreas Schwab  ---
6fcaaf9b931078f979a0282d396e78647ea37999 is the first bad commit
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236117
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug middle-end/78128] [7 regression] fortran/resolve.c:resolve_operator miscompiled at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-27
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug middle-end/78128] [7 regression] fortran/resolve.c:resolve_operator miscompiled at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||71002

--- Comment #3 from Richard Biener  ---
The issue is

;; e_11(D)->ts.kind = _1;

(insn 20 19 0 (set (mem:SI (reg/f:DI 356) [4 e_11(D)->ts.kind+0 S4 A32])
(reg:SI 340 [ _1 ])) "t.i":39 -1
 (nil))

vs.

;; _3 = BIT_FIELD_REF ;

(insn 21 20 0 (set (reg:DI 342 [ _3 ])
(mem:DI (reg/v/f:DI 349 [ e ]) [3 MEM[(bt *)e_11(D)]+0 S8 A64]))
"t.i":40 -1
 (nil))

which use different alias sets.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 241509)
+++ gcc/fold-const.c(working copy)
@@ -3809,7 +3809,8 @@ make_bit_field_ref (location_t loc, tree
 {
   tree result, bftype;

-  if (get_alias_set (inner) != get_alias_set (orig_inner))
+  if (! alias_set_subset_of (get_alias_set (orig_inner),
+get_alias_set (inner)))
 inner = fold_build2 (MEM_REF, TREE_TYPE (inner),
 build_fold_addr_expr (inner),
 build_int_cst

should fix it


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
[Bug 71002] [6 Regression] -fstrict-aliasing breaks Boost's short string
optimization implementation

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Jakub Jelinek  ---
> Can you attach then preprocessed copy.ii, cc1plus command line and copy.s 
> (with
> additional -dA) from both r241136 and r241137 +
> http://gcc.gnu.org/ml/gcc-patches/2016-10/msg02062.html ?
> The test is -std=c++11 and there are no inline variables, so there shouldn't 
> be
> any between those two.

It turns out the failure already occurs at r241136.  I'm now running a
proper reghunt to determine the culprit.

Rainer

[Bug lto/78129] New: -Werror=suggest-final-types leads to -ENOSPC.

[pawel_sikora at zoho dot com]

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

Bug ID: 78129
   Summary: -Werror=suggest-final-types leads to -ENOSPC.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

the -Werror=suggest-final-types doesn't remove *.ltrans*.o files from /tmp on
linking failure. for tmpfs based /tmp this is a major problem.

[Bug libstdc++/70975] experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  ---
Just FYI, in a recent Solaris 12 build sendfile was changed to accept a NULL
off
for Linux compatibility.  However, the separate Solaris 10/11 (which isn't used
yet) doesn't have that change and probably wont.

  Rainer

[Bug fortran/78026] [5/6/7 Regression] ICE in gfc_resolve_omp_declare_simd, at fortran/openmp.c:5190

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug libstdc++/70975] experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
Does following patch work:

--cut here--
diff --git a/libstdc++-v3/src/filesystem/ops.cc
b/libstdc++-v3/src/filesystem/ops.cc
index 9abcee0..b709858 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -444,7 +444,9 @@ namespace
   }

 #ifdef _GLIBCXX_USE_SENDFILE
-const auto n = ::sendfile(out.fd, in.fd, nullptr, from_st->st_size);
+off_t always_zero_offset = 0;
+const auto n = ::sendfile(out.fd, in.fd,
+ &always_zero_offset, from_st->st_size);
 if (n < 0 && (errno == ENOSYS || errno == EINVAL))
   {
 #endif
--cut here--

[Bug fortran/77783] ICE in gfc_compare_union_types, at fortran/interface.c:545

[foreese at gcc dot gnu.org]

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

foreese at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||foreese at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #3 from foreese at gcc dot gnu.org ---
> https://gcc.gnu.org/ml/fortran/2016-10/msg8.html

This is fixed as of r240810.

2016-10-05  Fritz Reese  

Fix ICE due to comparison between UNION components.

gcc/fortran/
* interface.c (gfc_compare_types): Don't compare BT_UNION components
until we know they're both UNIONs.
* interface.c (gfc_compare_union_types): Guard against empty
components.

gcc/testsuite/gfortran.dg/
* dec_union_9.f90: New testcase.
* dec_union_10.f90: New testcase.

[Bug rtl-optimization/77919] [5/6/7 Regression] ICE converting DC to V2DF mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r192946.

[Bug c++/78124] [7 regression][c++1z] explicit inheriting constructor is ignored

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-27
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  WPA stage doesn't clean up properly after errors.

[Bug rtl-optimization/78127] [5/6/7 Regression] AArch64 internal compiler error: in lra_eliminate, at lra-eliminations.c:1440

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug fortran/78122] [5/6/7 Regression] ICE in get, at cgraph.h:395

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug middle-end/78115] Missed optimization for "int modulo 2^31"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-27
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
GCC is pessimized by its own IL (with undefined overflow).  Optimized we have:

  :
  if (num_3(D) < 0)
goto ;
  else
goto ;

  :
  _1 = num_3(D) + 1;
  num_4 = _1 + 2147483647;

  :
  # num_2 = PHI 
  return num_2;

not sure what exactly clang matches here.

[Bug libstdc++/70975] experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Uroš Bizjak  ---
> Does following patch work:
>
> --cut here--
> diff --git a/libstdc++-v3/src/filesystem/ops.cc
> b/libstdc++-v3/src/filesystem/ops.cc
> index 9abcee0..b709858 100644
> --- a/libstdc++-v3/src/filesystem/ops.cc
> +++ b/libstdc++-v3/src/filesystem/ops.cc
> @@ -444,7 +444,9 @@ namespace
>}
>
>  #ifdef _GLIBCXX_USE_SENDFILE
> -const auto n = ::sendfile(out.fd, in.fd, nullptr, from_st->st_size);
> +off_t always_zero_offset = 0;
> +const auto n = ::sendfile(out.fd, in.fd,
> + &always_zero_offset, from_st->st_size);
>  if (n < 0 && (errno == ENOSYS || errno == EINVAL))
>{
>  #endif
> --cut here--

Cursory testing indicates it does: I've built copy.cc both without and
with the patch and copied the binaries to the only remaining Solaris 12
machine with an older build which doesn't have the recent sendfile
change.  The unpatched binary SEGVs as before, the patched one completes
successfully.

Thanks.
Rainer

[Bug rtl-optimization/77919] [5/6/7 Regression] ICE converting DC to V2DF mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I guess the first question is if it is valid for expand_expr that requests some
mode to return a rtx with some completely different mode.  If not, then the bug
is somewhere in normal_inner_ref: code:
if (GET_CODE (op0) == CONCAT && !must_force_mem)
  {
if (bitpos == 0
&& bitsize == GET_MODE_BITSIZE (GET_MODE (op0)))
  { 
if (reversep)
  op0 = flip_storage_order (GET_MODE (op0), op0);
return op0;
  }
If bitpos/bitsize indicate the real or imaginary part of the CONCAT, then we
don't return and let the later code handle the mode changes, but for this early
out we don't really consider what the mode is.
E.g. when handling VIEW_CONVERT_EXPR, as in e.g.
typedef float V __attribute__((vector_size (16)));
typedef _Complex float DC __attribute__((mode (DC)));
DC foo (void);
V bar ()
{
  return ((union U { DC c; V v; }) { .c = foo () }).v;
}
V baz ()
{
  DC c = foo ();
  return *(V *)&c;
}
we do:
  if (target == 0 || GET_MODE (target) != TYPE_MODE (inner_type))
target
  = assign_stack_temp_for_type
(TYPE_MODE (inner_type),
 GET_MODE_SIZE (TYPE_MODE (inner_type)), inner_type);

  emit_move_insn (target, op0);
because op0 is not a MEM.

[Bug rtl-optimization/77930] Compile time hog w/ -O2 -g -funroll-loops -ftree-loop-if-convert-stores on 32-bit targets

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-27
 CC||ramana at gcc dot gnu.org
  Component|target  |rtl-optimization
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #3 from Ramana Radhakrishnan  ---
var-tracking issue.

Is this likely to be a regression from gcc-6 or an earlier version of the
compiler ?

[Bug target/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #7 from Ramana Radhakrishnan  ---
(In reply to PeteVine from comment #6)
> There's definitely a problem with mcpu/mtune in GCC6 to the point I wasn't
> able to get the expected performance back, please look here:
> 
> http://openbenchmarking.org/result/1609269-LO-GCRYPTAAR21
> 
> BTW, that benchmark required lots of hacking/patching to run on aarch64.
> Won't work OOTB.

Please report bugs as per https://gcc.gnu.org/bugs/

for e.g. give command line options, attach pre-processor source and give
information about what platform you were running this on so that folks who want
to reproduce this can do so with the information in the bugzilla and not have
to guess which version of which source had a problem .

[Bug middle-end/78115] Missed optimization for "int modulo 2^31"

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
For the first part, when we transform (X+C1)+C2 to X+(C1+C2), we check that
C1+C2 doesn't overflow. But if C1+C2 would give INT_MIN, we still have the
possibility to generate X-INT_MIN without going to an unsigned type.

For the second part, I am not sure either. Some guesses:
X - INT_MIN becomes X ^ INT_MIN. Since we know that all the bits set in INT_MIN
(the top one) are also set in X (< 0), this becomes X & INT_MAX. In the branch
X >= 0, X & INT_MAX would fold to X (kind of like a neutral element) so we can
do the operation unconditionally.
A bit far-fetched maybe...

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[tulipawn at gmail dot com]

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

--- Comment #11 from PeteVine  ---
Well, I finally managed to complete an LTO bootstrap on ARM (even leaving the
full complement of C(XX)FLAGS in place, bar -flto) but it seems using ld.bfd is
a must.

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

[Bug target/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[tulipawn at gmail dot com]

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

--- Comment #8 from PeteVine  ---
I thought I was clear it was just a heads-up. All relevant data is already
inside and anyone willing to look closer should just run the benchmark on any
machine/platform like this, e.g.:

$ phoronix-test-suite benchmark 1609257-LO-FORTRANAA01 ,

and so on.

[Bug c++/78130] New: Strict overflow warning appears to be invalid

[rianquinn at gmail dot com]

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

Bug ID: 78130
   Summary: Strict overflow warning appears to be invalid
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rianquinn at gmail dot com
  Target Milestone: ---

Currently bounds checks inside Microsoft's GSL are causing a strict overflow
warning to trigger that appears to be invalid (i.e. the bounds checks should be
fine). The issue has been documented here:
https://github.com/Microsoft/GSL/pull/405

The bounds check looks like this (both count and size() are std::ptrdiff_t):
Expects(count >= 0 && count <= size());

The code can be seen here:
https://github.com/Microsoft/GSL/blob/master/gsl/span#L475

The warning is the following:
warning: assuming signed overflow does not occur when assuming
that (X - c) > X is always false [-Wstrict-overflow]

And the warning occurs on both GCC 5 and 6. Simplifying the code still
generates the warning:
Expects(count >= 0); // fine
Expects(count <= size()); // Generates warning

Doing the following fixes the issue, but is obviously less than ideal:
Expects(count >= 0 && (count < size() || count == size()));

[Bug c++/78130] Strict overflow warning appears to be invalid

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-27
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Please attach a preprocessed testcase as per https://gcc.gnu.org/bugs/.

[Bug rtl-optimization/77919] [5/6/7 Regression] ICE converting DC to V2DF mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> I guess the first question is if it is valid for expand_expr that requests
> some mode to return a rtx with some completely different mode.  If not, then
> the bug is somewhere in normal_inner_ref: code:
> if (GET_CODE (op0) == CONCAT && !must_force_mem)
>   {
> if (bitpos == 0
> && bitsize == GET_MODE_BITSIZE (GET_MODE (op0)))
>   { 
> if (reversep)
>   op0 = flip_storage_order (GET_MODE (op0), op0);
> return op0;
>   }
> If bitpos/bitsize indicate the real or imaginary part of the CONCAT, then we
> don't return and let the later code handle the mode changes, but for this
> early out we don't really consider what the mode is.

I agree that the early return is awkward here.  What happens if you just fall
through in this case?

[Bug c++/78130] Strict overflow warning appears to be invalid

[rianquinn at gmail dot com]

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

--- Comment #2 from Rian Quinn  ---
The output:

Using built-in specs.
COLLECT_GCC=/usr/bin/c++
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)
COLLECT_GCC_OPTIONS='-D' 'GSL_THROW_ON_CONTRACT_VIOLATION' '-I'
'/home/user/gsl/build' '-I' '/home/user/gsl/tests/..' '-I'
'/home/user/gsl/tests/./unittest-cpp' '-v' '-save-temps' '-fno-strict-aliasing'
'-std=c++14' '-O3' '-Wall' '-Wno-missing-braces' '-o'
'CMakeFiles/string_span_tests.dir/string_span_tests.cpp.o' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -I /home/user/gsl/build
-I /home/user/gsl/tests/.. -I /home/user/gsl/tests/./unittest-cpp -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE -D GSL_THROW_ON_CONTRACT_VIOLATION
/home/user/gsl/tests/string_span_tests.cpp -mtune=generic -march=x86-64
-std=c++14 -Wall -Wno-missing-braces -fno-strict-aliasing -O3 -fpch-preprocess
-fstack-protector-strong -Wformat-security -o string_span_tests.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/user/gsl/build
 /home/user/gsl/tests/..
 /home/user/gsl/tests/./unittest-cpp
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-D' 'GSL_THROW_ON_CONTRACT_VIOLATION' '-I'
'/home/user/gsl/build' '-I' '/home/user/gsl/tests/..' '-I'
'/home/user/gsl/tests/./unittest-cpp' '-v' '-save-temps' '-fno-strict-aliasing'
'-std=c++14' '-O3' '-Wall' '-Wno-missing-braces' '-o'
'CMakeFiles/string_span_tests.dir/string_span_tests.cpp.o' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -fpreprocessed string_span_tests.ii
-quiet -dumpbase string_span_tests.cpp -mtune=generic -march=x86-64
-auxbase-strip CMakeFiles/string_span_tests.dir/string_span_tests.cpp.o -O3
-Wall -Wno-missing-braces -std=c++14 -version -fno-strict-aliasing
-fstack-protector-strong -Wformat-security -o string_span_tests.s
GNU C++14 (Ubuntu 5.4.0-6ubuntu1~16.04.2) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 5.4.0-6ubuntu1~16.04.2) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 15157934e8203caff79287fd8f2d2843
/home/user/gsl/tests/string_span_tests.cpp: In member function ‘virtual void
Suitestring_span_tests::Testzstring::RunImpl() const’:
/home/user/gsl/tests/string_span_tests.cpp:865:329: warning: assuming signed
overflow does not occur when assuming that (X - c) > X is always false
[-Wstrict-overflow]
In file included from /home/user/gsl/tests/../gsl/string_span:24:0,
 from /home/user/gsl/tests/string_span_tests.cpp:19:
/home/user/gsl/tests/../gsl/span:475:9: warning: assuming signed overflow does
not occur when assuming that (X - c) > X is always false [-Wstrict-overflow]
 Expects(count >= 0 && count <= size());
 ^
/home/user/gsl/tests/string_span_tests.cpp: In member function ‘virtual void
Suitestring_span_tests::Testwzstr

[Bug c++/78130] Strict overflow warning appears to be invalid

[rianquinn at gmail dot com]

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

--- Comment #3 from Rian Quinn  ---
Created attachment 39908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39908&action=edit
ii and s file

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #21 from Bernd Edlinger  ---
(In reply to wilco from comment #20)
> > Wilco, where have you seen the additional registers used with my
> > previous patch, maybe we can try to fix that somehow?
> 
> What happens is that the move of zero causes us to use extra registers in
> shifts as both source and destination are now always live at the same time.
> We generate worse code for simple examples like x | (y << 3):
> 
> -mfpu=vfp:
>   push{r4, r5}
>   lslsr5, r1, #3
>   orr r5, r5, r0, lsr #29
>   lslsr4, r0, #3
>   orr r0, r4, r2
>   orr r1, r5, r3
>   pop {r4, r5}
>   bx  lr
> -mfpu=neon:
>   lslsr1, r1, #3
>   orr r1, r1, r0, lsr #29
>   lslsr0, r0, #3
>   orrsr0, r0, r2
>   orrsr1, r1, r3
>   bx  lr
> 

hmm. I think with my patch reverted the code is the same.

I tried -O2 -marm -mfpu=vfp -mhard-float get the first variant
with and without patch.

For -O2 -marm -mfpu=vfp -msoft-float I get the second variant
with and witout patch.

For -O2 -marm -mfpu=neon -mhard-float I get the second variant

With -O2 -marm -mfpu=neon -msoft-float I get a third variant
again with and without patch:

lsl r1, r1, #3
mov ip, r0
orr r0, r2, r0, lsl #3
orr r1, r1, ip, lsr #29
orr r1, r1, r3
bx  lr



Am I missing something?

[Bug c++/78130] Strict overflow warning appears to be invalid

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |NEW
  Known to fail||6.2.0

--- Comment #4 from Richard Biener  ---
Confirmed.  Not in any way analyzed or reduced yet.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[wilco at gcc dot gnu.org]

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

--- Comment #22 from wilco at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #21)
> (In reply to wilco from comment #20)
> > > Wilco, where have you seen the additional registers used with my
> > > previous patch, maybe we can try to fix that somehow?
> > 
> > What happens is that the move of zero causes us to use extra registers in
> > shifts as both source and destination are now always live at the same time.
> > We generate worse code for simple examples like x | (y << 3):
> > 
> > -mfpu=vfp:
> > push{r4, r5}
> > lslsr5, r1, #3
> > orr r5, r5, r0, lsr #29
> > lslsr4, r0, #3
> > orr r0, r4, r2
> > orr r1, r5, r3
> > pop {r4, r5}
> > bx  lr
> > -mfpu=neon:
> > lslsr1, r1, #3
> > orr r1, r1, r0, lsr #29
> > lslsr0, r0, #3
> > orrsr0, r0, r2
> > orrsr1, r1, r3
> > bx  lr
> > 
> 
> hmm. I think with my patch reverted the code is the same.
> 
> I tried -O2 -marm -mfpu=vfp -mhard-float get the first variant
> with and without patch.

Yes that's what I get.

> For -O2 -marm -mfpu=vfp -msoft-float I get the second variant
> with and witout patch.

This still gives the first variant for me.

> For -O2 -marm -mfpu=neon -mhard-float I get the second variant

Right.

> With -O2 -marm -mfpu=neon -msoft-float I get a third variant
> again with and without patch:
> 
> lsl r1, r1, #3
> mov ip, r0
> orr r0, r2, r0, lsl #3
> orr r1, r1, ip, lsr #29
> orr r1, r1, r3
> bx  lr

I don't see this...

> Am I missing something?

What I meant is that your patch still makes a large difference on the original
test case despite making no difference in simple cases like the above.

Anyway, there is another bug: on AArch64 we correctly recognize there are 8
1-byte loads, shifts and orrs which can be replaced by a single 8-byte load and
a byte reverse. Although it is recognized on ARM and works correctly if it is a
little endian load, it doesn't perform the optimization if a byte reverse is
needed. As a result there are lots of 64-bit shifts and orrs which create huge
register pressure if not expanded early.

This testcase is turning out to be a goldmine of bugs...

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  ---
(In reply to Martin Liška from comment #13)
> (In reply to H.J. Lu from comment #12)
> > (In reply to Martin Liška from comment #10)
> > > (In reply to H.J. Lu from comment #9)
> > > > (In reply to Richard Biener from comment #6)
> > > > > Why would we be not able to tailcall in an interupt handler?
> > > > 
> > > > We need to verify that the only instruction in an interrupt handler
> > > > is a tail call to another interrupt handler.  On the other hand,
> > > > this interrupt handler isn't really needed at all.
> > > 
> > > That can be vefief by fact that the symbol should have only one call (tail
> > > call) and set node->icf_merged == true.
> > 
> > Another issue with ICF tail call:
> > 
> > ;; Function foo1 (foo1, funcdef_no=3, decl_uid=1443, cgraph_uid=0,
> > symbol_order=0)
> > 
> > foo1 (void * p)
> > {
> > ;;   basic block 2, loop depth 0
> > ;;pred:   ENTRY
> >   foo2 (p_2(D)); [tail call]
> >   ^^^  This isn't the same as sibcall.
> >   return;
> >   ^^  Here is a return statement.
> > ;;succ:   EXIT
> > 
> > }
> 
> If I remember correctly, this is gimple representation of the tail-call. If
> you look at the generated binary, you'll see really just the jump
> instruction:
> 
> foo2:
> .LFB1:
>   .cfi_startproc
>   movl$4276093056, %eax
>   movl$0, (%rax)
>   ret
>   .cfi_endproc
> .LFE1:
>   .size   foo2, .-foo2
>   .p2align 4,,15
>   .globl  foo1
>   .type   foo1, @function
> foo1:
> .LFB3:
>   .cfi_startproc
>   jmp foo2
>   .cfi_endproc

Not with interrupt handler which needs different epilogue and prologue.

[Bug target/78132] New: GCC produces invalid instruction (kmovd and kmovq) for KNL.

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 78132
   Summary: GCC produces invalid instruction (kmovd and kmovq) for
KNL.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Created attachment 39909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39909&action=edit
Reproducer.

GCC produces invalid instruction (kmovd and kmovq) for KNL. The reproducer for
kmovq was attached, but I there is exist similar error for kmovd.

Reproducer:
unsigned short c;
char a, d, f, b;
short e;
long g;
int main() {
  g = c;
  f = c & e;
  d = c & a | e;
  if (a)
b = c;
}

GCC version:
>$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/vlivinsk/workspace/gcc-dev/bin-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/vlivinsk/workspace/gcc-dev/trunk/configure
--prefix=/home/vlivinsk/workspace/gcc-dev/bin-trunk
Thread model: posix
gcc version 7.0.0 20161026 (experimental) (GCC)

Error:
>$ g++ -O3 -march=knl small.cpp
>$ sde -knl -- ./a.out
TID 0 SDE-ERROR: Executed instruction not valid for specified chip (KNL):
0x400436: kmovq k0, rax
Image: a.out+0x436 (in multi-region image, region# 0)
Function: main
Instruction bytes are: c4 e1 fb 92 c0

[Bug c++/78130] Strict overflow warning appears to be invalid

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
markus@x4 tmp % cat string_span_tests.ii
class A {
public:
  using index_type = int;
  index_type m_fn1() { return size_; }
  index_type size_;
};
struct B {
  using element_type = int;
  using index_type = int;
  using pointer = element_type;
  B(pointer, index_type);
  void m_fn2(index_type p1) {
int a = m_fn3();
if (__builtin_expect(p1 <= a, 1))
  throw;
  }
  index_type m_fn3() { return storage_.m_fn1(); }
  A storage_;
};
struct C {
  using impl_type = B;
  C(impl_type);
  void m_fn4() {
int b = span_.m_fn3();
span_.m_fn2(b - 1);
  }
  impl_type span_;
};
template  using zstring_span = C;
struct D {
  void m_fn5() const;
};
void D::m_fn5() const {
  zstring_span<> c({0, 0});
  try {
c.m_fn4();
  } catch (int) {
  }
}

markus@x4 tmp % g++ -c -O2 -Wall string_span_tests.ii
string_span_tests.ii: In member function ‘void D::m_fn5() const’:
string_span_tests.ii:14:29: warning: assuming signed overflow does not occur
when assuming that (X - c) <= X is always true [-Wstrict-overflow]
 if (__builtin_expect(p1 <= a, 1))
  ~~~^~~~

[Bug c++/78130] Strict overflow warning appears to be invalid

[rianquinn at gmail dot com]

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

--- Comment #6 from Rian Quinn  ---
Correct me if I'm wrong, but it would appear that this is indeed an bug with
GCC (based on current activity). If that is the case, what would be your
recommendations on how to resolve this issue in the GSL. At the moment, our
current approach is to disable strict overflow, but that seems a bit harsh. 

Any other options?

[Bug c++/78130] Strict overflow warning appears to be invalid

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
Reduced a bit more:

struct B {
  B();
  void m_fn2(int p1) {
if (p1 <= storage_)
  throw;
  }
  int storage_;
};
void f() {
  B span_;
  int b = span_.storage_;
  span_.m_fn2(b - 1);
}

The warning seems correct to me (assuming the reduction didn't change things
too much). We have a comparison storage_ - 1 <= storage_, the compiler
optimizes it to true, and the warning tells you about it (maybe in the full
code the compiler would have a chance to prove that storage_ is never 0 and
thus storage_ - 1 can never overflow, but that's hard).

A warning doesn't necessary say that something is wrong with your code, here it
just informs you about an optimization. How useful that is is a different
question...

[Bug target/78132] [7 Regression] GCC produces invalid instruction (kmovd and kmovq) for KNL.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-27
 CC||marxin at gcc dot gnu.org,
   ||ubizjak at gmail dot com
   Target Milestone|--- |7.0
Summary|GCC produces invalid|[7 Regression] GCC produces
   |instruction (kmovd and  |invalid instruction (kmovd
   |kmovq) for KNL. |and kmovq) for KNL.
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r239672.

[Bug target/78132] [7 Regression] GCC produces invalid instruction (kmovd and kmovq) for KNL.

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Related to bug 77476.

[Bug c++/78130] Strict overflow warning appears to be invalid

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Markus Trippelsdorf  ---
OK. Closing.

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
> 
> Not with interrupt handler which needs different epilogue and prologue.

I see, however I'm not sure it's known information when IPA ICF is running.
Or am I wrong?

[Bug rtl-optimization/77919] [5/6/7 Regression] ICE converting DC to V2DF mode

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Reduced testcase:
struct A { A (double) {} _Complex double i; };
typedef int __attribute__ ((vector_size (16))) B;
typedef struct { B b; } C;
struct D { D (const B &x) : b (x) {} B b; };
static inline B foo (const double *x) { C *a; a = (C *) x; return a->b; }
static inline D baz (const A &x) { return foo ((double *) &x); }
D b = baz (0);

(In reply to Eric Botcazou from comment #5)
> I agree that the early return is awkward here.  What happens if you just
> fall through in this case?

It will force the CONCAT into memory.  I'll try the falling through for the
case when bitpos == 0 and bitsize is the whole CONCAT size if mode1 != GET_MODE
(op0) and will add logging when that happens to see how often and when that
happens.

[Bug fortran/54679] Erroneous "Expected P edit descriptor" in conjunction with L descriptor

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
I should have looked at this sooner. We actually do diagnose this, but our
warning/error logic is not right.

pr54679.f90:8:56:

 PRINT "(A,1X,I2,1X,A,1X,I2,1X,A,2(1X,I0,1X),A,2(1X,L0,1X))"
1
Warning: Extension: Missing positive width after L descriptor at (1)

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
WE also found out performance drop on another important benchmark with the same
symptoms after r241170, namely loop marked with .L18 has +12 more fills from
stack. The test-case will be attached.

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[ysrumyan at gmail dot com]

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

--- Comment #3 from Yuri Rumyantsev  ---
Created attachment 39910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39910&action=edit
another test-case

Must be compiled with "-Ofast -fopenmp -funroll-loops -march=knl"

[Bug testsuite/78133] New: Commit r241489 adds printf specifiers not supported by newlib.

[tamar.christina at arm dot com]

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

Bug ID: 78133
   Summary: Commit r241489 adds printf specifiers not supported by
newlib.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tamar.christina at arm dot com
  Target Milestone: ---

The commit adds tests for the double hex specifier %a which is not supported by
newlib.

These should probably be ifdef'ed out to prevent failures.

FAIL: test_a_double:364: "%.0a" expected result for "a" doesn't match function
call return value: 1 != 6

FAIL: test_a_double:365: "%.0a" expected result for "a" doesn't match function
call return value: 1 != 6

FAIL: test_a_double:366: "%.0a" expected result for "a" doesn't match function
call return value: 1 != 6

FAIL: test_a_double:367: "%.1a" expected result for "a" doesn't match function
call return value: 1 != 8

FAIL: test_a_double:368: "%.2a" expected result for "a" doesn't match function
call return value: 1 != 9

FAIL: test_a_double:369: "%.3a" expected result for "a" doesn't match function
call return value: 1 != 10

FAIL: test_a_double:372: "%.0a" expected result for "a" doesn't match output
length: 1 not in [6, 10]

FAIL: test_a_double:373: "%.1a" expected result for "a" doesn't match output
length: 1 not in [6, 12]

FAIL: test_a_double:374: "%.2a" expected result for "a" doesn't match output
length: 1 not in [6, 13]

FAIL: test_a_long_double:380: "%.0La" expected result for "a" doesn't match
function call return value: 1 != 6

FAIL: test_a_long_double:381: "%.0La" expected result for "a" doesn't match
function call return value: 1 != 6

FAIL: test_a_long_double:382: "%.0La" expected result for "a" doesn't match
function call return value: 1 != 6

FAIL: test_a_long_double:383: "%.1La" expected result for "a" doesn't match
function call return value: 1 != 8

FAIL: test_a_long_double:384: "%.2La" expected result for "a" doesn't match
function call return value: 1 != 9

[Bug testsuite/78133] Commit r241489 adds printf specifiers not supported by newlib.

[tamar.christina at arm dot com]

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

--- Comment #1 from Tamar Christina  ---
These are coming from gcc.dg/tree-ssa/builtin-sprintf.c

[Bug libstdc++/78134] New: set::set lower_bound() for transparent comparator returns const_iterator

[barry.revzin at gmail dot com]

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

Bug ID: 78134
   Summary: set::set lower_bound() for transparent comparator
returns const_iterator
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

#include 

struct comp {
bool operator()(int i, int j) const {
return i < j;
}

using is_transparent = void;
};

template  struct is_same { static constexpr bool value =
false;  };
template  struct is_same { static constexpr bool value = true;
};

int main() {
using S = std::set;
S s;
static_assert(is_same::value,
"!");

}

We're invoking the function template version of lower_bound(), but s is
non-const so the result should be iterator. Instead we're getting
const_iterator. This compiles on clang with libc++.

[Bug target/78132] [7 Regression] GCC produces invalid instruction (kmovd and kmovq) for KNL.

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
The failing instruction is pre-existing movdi_internal.

movzwl  c(%rip), %eax   # 5 zero_extendhidi2/1  [length = 8]
kmovw   e(%rip), %k1# 9 *movhi_internal/6   [length = 9]
movzbl  a(%rip), %edx   # 13*movqi_internal/3   [length = 8]
kmovq   %rax, %k0   # 51*movdi_internal/23  [length = 4]
kmovw   %k0, %ecx   # 40*movqi_internal/10  [length = 4]

Unsupported insn alternatives should be also conditionally enabled in QI, SI
and DI move patterns, in the same way as the fix for PR 77476.

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  ---
(In reply to Martin Liška from comment #15)
> > 
> > Not with interrupt handler which needs different epilogue and prologue.
> 
> I see, however I'm not sure it's known information when IPA ICF is running.
> Or am I wrong?

The information is available.  But I don't know if ICF should be concerned.
We can disable ICF for interrupt handler or use it as a feature to detect
code duplication for interrupt handler, which I submitted a patch for:

https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02177.html

[Bug middle-end/77735] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 358)

[tamar.christina at arm dot com]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tamar.christina at arm dot com

--- Comment #10 from Tamar Christina  ---
Hi Martin,

These tests fail when using newlib. I've created a new ticket for this.

Should probably be ifdef out?

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

Thanks,
Tamar

[Bug c/78135] New: In an unsigned long (64 bit) 1<<31 gives rubbish

[jmdh01 at btinternet dot com]

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

Bug ID: 78135
   Summary: In an unsigned long (64 bit) 1<<31 gives rubbish
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmdh01 at btinternet dot com
  Target Milestone: ---

Created attachment 39911
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39911&action=edit
gcc_version+specimen.c+specimen.i example program demonstrating bug

It would appear that left shifting a single bit into bit 31 causes the result
to be "sign extended". This could be caused by either a hardware quirk or over
enthusiastic optimisation forgetting that the operand is unsigned or a
combination of both. Example program attached. This bug is horrible: the code
emitted by gcc is ok for 98% percent of the time; it took a whole week to track
down this particular gem.

gcc -g -o specimen2 -Wall -Wextra specimen.c  only complains about an unused
variable.

The problem manifests itself using an Intel J1900 and an i5-6400 both with 8GB
ram.

Operating System: Ubuntu 16.04.1 (with Trinity)
Kernel: linux 4.4.0-45-generic (x86_64)

Attachments:
1) gcc_version.txt
2) specimen.c -- source of example program
3) specimen.i -- as requested

[Bug c/78135] In an unsigned long (64 bit) 1<<31 gives rubbish

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
wk = 0x1 << j;

That is still int << j

Try changing it to be the following:
wk = 0x1ull << j;

[Bug c/78135] In an unsigned long (64 bit) 1<<31 gives rubbish

[jmdh01 at btinternet dot com]

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

John Hunter  changed:

   What|Removed |Added

 CC||jmdh01 at btinternet dot com

--- Comment #3 from John Hunter  ---
Created attachment 39912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39912&action=edit
Short program to demonstrate the bug

[Bug c/78135] In an unsigned long (64 bit) 1<<31 gives rubbish

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Also:
  printf("\n  Finally: 0x%016lx, how silly can you get?\n",
(unsigned long)((1 << 24) << 7));

This is undefined as shifting into the sign bit is undefined.
use instead:
  printf("\n  Finally: 0x%016lx, how silly can you get?\n",
(unsigned long)((1ul << 24) << 7));

[Bug testsuite/78136] New: gcc.dg/cpp/trad/include.c fails with newer glibc versions

[tamar.christina at arm dot com]

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

Bug ID: 78136
   Summary: gcc.dg/cpp/trad/include.c fails with newer glibc
versions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tamar.christina at arm dot com
  Target Milestone: ---

The test gcc.dg/cpp/trad/include.c fails with any glibc versions after commit
6962682ffe5e5f0373047a0b894fee7a774be254.

This commits adds a macro that uses the ## string function which
-traditional-cpp doesn't support.

I'm not quite sure what the intention of the test is.. If it just to test that
-traditional-cpp work and a header file was picked that would always be
available? 

or is it to test glibc compatibility with -traditional-cpp. In the end building
still works, so I assume this test isn't critical. But not sure what should be
done about it.

The source file is compiled with  -traditional-cpp -lm

and the error

Excess errors:
/usr/include/stdlib.h:183:0: error: token "##" is not valid in preprocessor
expressions

[Bug rtl-optimization/78132] [7 Regression] GCC produces invalid instruction (kmovd and kmovq) for KNL.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
This is actually a bug in the REE pass, HARD_REGNO_MODE_OK is false for the
mask registers and DImode unless -mavx512bw, that pass should honor it.
I'll fix it.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #23 from Bernd Edlinger  ---
(In reply to wilco from comment #22)
> 
> What I meant is that your patch still makes a large difference on the
> original test case despite making no difference in simple cases like the
> above.

For sure it is papering over something, as the complete init-regs pass,
it is even documented to do that:

/* Check all of the uses of pseudo variables.  If any use that is MUST
   uninitialized, add a store of 0 immediately before it.  For
   subregs, this makes combine happy.  For full word regs, this makes
   other optimizations, like the register allocator and the reg-stack
   happy as well as papers over some problems on the arm and other
   processors where certain isa constraints cannot be handled by gcc.

I have seen the DI = 0 decay to two SI = 0 and finally removed
well before the init-regs pass runs, and the init-regs pass finds
nothing to do in this test case.  Nevertheless they have a very
positive influence in the lra pass.  In the moment I do not see,
what could replace this.  Magic.

> Anyway, there is another bug: on AArch64 we correctly recognize there are 8
> 1-byte loads, shifts and orrs which can be replaced by a single 8-byte load
> and a byte reverse. Although it is recognized on ARM and works correctly if
> it is a little endian load, it doesn't perform the optimization if a byte
> reverse is needed. As a result there are lots of 64-bit shifts and orrs
> which create huge register pressure if not expanded early.
> 
> This testcase is turning out to be a goldmine of bugs...


Yes, and the test case can be modified to exercise other insns too.

For instance I just added di-mode ~ to the sigma blocks:

#define Sigma0(x)   ~(ROTR((x),28) ^ ROTR((x),34) ^ ROTR((x),39))
#define Sigma1(x)   ~(ROTR((x),14) ^ ROTR((x),18) ^ ROTR((x),41))
#define sigma0(x)   ~(ROTR((x),1)  ^ ROTR((x),8)  ^ ((x)>>7))
#define sigma1(x)   ~(ROTR((x),19) ^ ROTR((x),61) ^ ((x)>>6))

and saw the stack use double with -marm -mfpu=vfp -msoft-float -Os
to 528, and when I disable the one_cmpldi2 pattern it goes
back to 278 again:

thus I will add this to the second patch:

@@ -5020,7 +5020,7 @@
 (define_insn_and_split "one_cmpldi2"
   [(set (match_operand:DI 0 "s_register_operand""=w,&r,&r,?w")
(not:DI (match_operand:DI 1 "s_register_operand" " w, 0, r, w")))]
-  "TARGET_32BIT"
+  "TARGET_32BIT && TARGET_HARD_FLOAT"
   "@
vmvn\t%P0, %P1
#


Not every di2 pattern is hamful, for instance unary minus does nothing.
Mostly all patterns that mix =w and =r alternatives.

[Bug rtl-optimization/78132] [7 Regression] GCC produces invalid instruction (kmovd and kmovq) for KNL.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[pthaugen at gcc dot gnu.org]

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

--- Comment #4 from Pat Haugen  ---
(In reply to Yuri Rumyantsev from comment #2)
> WE also found out performance drop on another important benchmark with the
> same symptoms after r241170, namely loop marked with .L18 has +12 more fills
> from stack. The test-case will be attached.

I don't understand what "fills from stack" is, are you referring to register
spills?

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[ysrumyan at gmail dot com]

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

--- Comment #5 from Yuri Rumyantsev  ---
Yes, some virtual register are allocated on stack and we got more loads from
stack to get their values.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #24 from Bernd Edlinger  ---
(In reply to Bernd Edlinger from comment #23)
> @@ -5020,7 +5020,7 @@
>  (define_insn_and_split "one_cmpldi2"
>[(set (match_operand:DI 0 "s_register_operand"  "=w,&r,&r,?w")
>   (not:DI (match_operand:DI 1 "s_register_operand" " w, 0, r, w")))]

BTW: who knows what it is good for to have
=w
 w

on the first alternative, and on the 4th alternative
?w
 w

"?" does only make the alternative less attractive, but it is otherwise
exactly the same as the first one, right?

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[wilco at gcc dot gnu.org]

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

--- Comment #25 from wilco at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #24)
> (In reply to Bernd Edlinger from comment #23)
> > @@ -5020,7 +5020,7 @@
> >  (define_insn_and_split "one_cmpldi2"
> >[(set (match_operand:DI 0 "s_register_operand""=w,&r,&r,?w")
> > (not:DI (match_operand:DI 1 "s_register_operand" " w, 0, r, w")))]
> 
> BTW: who knows what it is good for to have
> =w
>  w
> 
> on the first alternative, and on the 4th alternative
> ?w
>  w
> 
> "?" does only make the alternative less attractive, but it is otherwise
> exactly the same as the first one, right?

Alternatives can be disabled, there are flags, eg:

(set_attr "arch" "neon_for_64bits,*,*,avoid_neon_for_64bits")

I think the NEON alternatives not only do not help at all, they actually
generate cause CQ to be far worse even when no NEON instructions are ever
generated.

[Bug c/78135] In an unsigned long (64 bit) 1<<31 gives rubbish

[jmdh01 at btinternet dot com]

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

--- Comment #4 from John Hunter  ---
The annotation of Constants with `ul' is a fudge. In the specimen program,
a constant (1) is assigned to an unsigned long variable (wk) which forces it to
be `ul'. The optimiser, in trying to eliminate a local intermediate variable
inconveniently "forgets" the intrinsic properties of the values in wk. This
makes it an invalid optimisation since it no longer translates the original
intentions of the programmer. (I am sure that Bill Waite would call this a
bug).
I have my K&R chapter 2 p41 open in front of me. It states quite clearly:

"char and short are converted to int, and ...

 Otherwise if either operand is long, the other is converted to long and the
result is long.
 Otherwise if either operand is unsigned, the other is converted to unsigned
and the result is unsigned. ... "

[Bug c/78135] In an unsigned long (64 bit) 1<<31 gives rubbish

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to John Hunter from comment #4)
> The annotation of Constants with `ul' is a fudge.

Not in this case as:
((1 << 24) << 7))

is an int.

[Bug c/78135] In an unsigned long (64 bit) 1<<31 gives rubbish

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #1)
> wk = 0x1 << j;
> 
> That is still int << j

That is not true, that is actually either long int << j or long long int << j
on most targets (e.g. LP64 the former and ILP32 the latter).
Otherwise, on 32-bit int targets, 1 << 31 is defined in C++, but is INT_MIN
then,
i.e. negative, and undefined behavior in C99/C11 (just try
-fsanitize=undefined).
And, again on 32-bit int targets, (1 << 24) << 7 is well defined, but 0.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[bernd.edlinger at hotmail dot de]

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

--- Comment #26 from Bernd Edlinger  ---
(In reply to wilco from comment #25)
> 
> Alternatives can be disabled, there are flags, eg:
> 
> (set_attr "arch" "neon_for_64bits,*,*,avoid_neon_for_64bits")
> 

Ok I see, thanks.

Still lots of insns could be simplified into less alternatives,
when the attribs are identical of course.  Doesn't that create
smaller tables and use less memory to compile?

> I think the NEON alternatives not only do not help at all, they actually
> generate cause CQ to be far worse even when no NEON instructions are ever
> generated.

Yes.  At least when not fpu is available, there can't possibly be
any benefit from these insns.  Sure there will be cases when
the fpu instructions can improve something, just not here.

[Bug c/78135] In an unsigned long (64 bit) 1<<31 gives rubbish

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
(In reply to John Hunter from comment #4)
> The annotation of Constants with `ul' is a fudge. In the specimen program,
> a constant (1) is assigned to an unsigned long variable (wk) which forces it

If you are talking about wk = 1 << j;, then it really doesn't matter what type
the wk variable has, this is assigning the value of 1 << j into the wk
variable,
so 1 << j is first evaluated and then converted into unsigned long and stored.

(In reply to Jakub Jelinek from comment #6)
> And, again on 32-bit int targets, (1 << 24) << 7 is well defined, but 0.

Sorry, thought about (1 << 24) << 8; and it is well defined in C++, still
undefined behavior in C99.  For (1 << 24) << 7, it is again INT_MIN in C++, UB
in C99.  You really want (1U << 24) << 8 (if you want to get 0), or (1ULL <<
24) << 7 (if you want to get 0x1ULL.

[Bug middle-end/77735] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 358)

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Thanks for the heads up!  Yes, the tests will need to be disabled but I'll also
need to fix the gimple-ssa-sprintf pass to avoid assuming that %a is supported
when it isn't.  Unless one already exists that might involve adding a new
configuration test.

[Bug testsuite/78133] Commit r241489 adds printf specifiers not supported by newlib.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
It sounds like the gimple-ssa-sprintf pass needs to be modified to avoid
assuming that %a is supported when it isn't.  Unless one already exists that
might involve adding a new configuration test.  Let me look into it.

[Bug testsuite/78133] Commit r241489 adds printf specifiers not supported by newlib.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-27
 Ever confirmed|0   |1

[Bug middle-end/78025] [5/6/7 Regression] ICE in simd_clone_adjust, at omp-simd-clone.c:1126

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Oct 27 18:51:28 2016
New Revision: 241628

URL: https://gcc.gnu.org/viewcvs?rev=241628&root=gcc&view=rev
Log:
PR middle-end/78025
* omp-simd-clone.c (simd_clone_adjust): Handle noreturn declare simd
functions.

* g++.dg/gomp/declare-simd-7.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/declare-simd-7.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-simd-clone.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/70975] experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Oct 27 18:55:55 2016
New Revision: 241629

URL: https://gcc.gnu.org/viewcvs?rev=241629&root=gcc&view=rev
Log:
PR70975 Pass valid offset argument to sendfile

PR libstdc++/70975
* src/filesystem/ops.cc (do_copy_file) [_GLIBCXX_USE_SENDFILE]:
Pass non-null pointer to sendfile for offset argument.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/filesystem/ops.cc

[Bug libstdc++/70975] experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uroš Bizjak  ---
Fixed.

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||pmderodat at gcc dot gnu.org

--- Comment #5 from Rainer Orth  ---
It turns out I've been barking up the wrong tree: the reghunt revealed that
this
patch

2016-10-12  Pierre-Marie de Rodat  

* dwarf2out.c (dwarf2out_early_global_decl): For nested
functions, call dwarf2out_decl on the parent function first.

is the culprit.  The message cited

dsymutil ./copy.exe
warning: invalid DWARF generated by the compiler: DIE 0x0003cb45 has multiple 
AT_inline attributes in
'/private/var/gcc/reghunt/pr78112/33425/x86_64-apple-darwin11.4.2/libstdc++-v3/testsuite/copy.o'.
warning: invalid DWARF generated by the compiler: DIE 0x000401a8 has multiple 
AT_inline attributes in
'/private/var/gcc/reghunt/pr78112/33425/x86_64-apple-darwin11.4.2/libstdc++-v3/testsuite/copy.o'.
warning: invalid DWARF generated by the compiler: DIE 0x00040fff has multiple 
AT_inline attributes in
'/private/var/gcc/reghunt/pr78112/33425/x86_64-apple-darwin11.4.2/libstdc++-v3/testsuite/copy.o'.

is from dsymutil, not the assembler as I first assumed.

I'm attaching a tarball with preprocessed input (identical except for path
names) and the assembler output.  The one at r241022 is fine, while dsymutil
complains about the second (r241023) and indeed in the assembler output at
line 57708 there's a duplicate DW_AT_inline.

  Rainer

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  ---
Created attachment 39914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39914&action=edit
preprocessed input and assembler output before and after the culprit patch

[Bug c++/61414] enum class bitfield size-checking failure

[matt at godbolt dot org]

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

Matt Godbolt  changed:

   What|Removed |Added

 CC||matt at godbolt dot org

--- Comment #8 from Matt Godbolt  ---
Definitely a plus one to a switch to disable the warning: we currently have to
work around this by putting code that does this in an -Isystem directory!

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
Can you post your configure command (or gcc -v output).

[Bug fortran/54679] Erroneous "Expected P edit descriptor" in conjunction with L descriptor

[nmm1 at cam dot ac.uk]

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

--- Comment #5 from Nick Maclaren  ---
That's the right message.  Warning or error, it doesn't matter.

[Bug fortran/78026] [5/6/7 Regression] ICE in gfc_resolve_omp_declare_simd, at fortran/openmp.c:5190

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Oct 27 19:55:12 2016
New Revision: 241630

URL: https://gcc.gnu.org/viewcvs?rev=241630&root=gcc&view=rev
Log:
PR fortran/78026
* parse.c (decode_statement): Don't create namespace for possible
select type here and destroy it afterwards.
(parse_select_type_block): Set gfc_current_ns to new_st.ext.block.ns.
(parse_executable, gfc_parse_file): Formatting fixes.
* match.c (gfc_match_select_type): Create namespace for select type
here, only after matching select type.  Formatting fixes.  Free that
namespace if not returning MATCH_YES, after gfc_undo_symbols,
otherwise remember it in new_st.ext.block.ns and switch to parent
namespace anyway.

* gfortran.dg/gomp/pr78026.f03: New test.
* gfortran.dg/select_type_38.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr78026.f03
trunk/gcc/testsuite/gfortran.dg/select_type_38.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[derodat at adacore dot com]

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

Pierre-Marie de Rodat  changed:

   What|Removed |Added

 CC||derodat at adacore dot com

--- Comment #7 from Pierre-Marie de Rodat  ---
(In reply to Rainer Orth from comment #5)
> I'm attaching a tarball with preprocessed input (identical except for path
> names) and the assembler output.  The one at r241022 is fine, while dsymutil
> complains about the second (r241023) and indeed in the assembler output at
> line 57708 there's a duplicate DW_AT_inline.

Thank you for reporting! I’m on vacation until the end of the week; I’ll try to
reproduce and understand what is going on next week.

[Bug c++/78137] New: [C++1z] braced initializer in defaulted function argument causes ICE

[eric.niebler at gmail dot com]

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

Bug ID: 78137
   Summary: [C++1z] braced initializer in defaulted function
argument causes ICE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

With -std=gnu++1z, the following code ICEs the compiler:

```
struct S {};

template 
void foo(T t = {}) {}

int main() {
  foo();
}
```

Result:

test.cpp: In function ‘int main()’:
test.cpp:6:7: internal compiler error: in build_over_call, at cp/call.c:7847
   foo();
   ^

The same code compiles successfully with -std=gnu++14.

[Bug fortran/78026] [5/6 Regression] ICE in gfc_resolve_omp_declare_simd, at fortran/openmp.c:5190

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |gfc_resolve_omp_declare_sim |gfc_resolve_omp_declare_sim
   |d, at fortran/openmp.c:5190 |d, at fortran/openmp.c:5190

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

[Bug c++/78137] [C++1z] braced initializer in defaulted function argument causes ICE

[eric.niebler at gmail dot com]

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

Eric Niebler  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Niebler  ---
Didn't see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78003. FWIW, this repro
is simpler.

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

[Bug c++/78003] [7 Regression] c++17: ICE in build_over_call, at cp/call.c:7847

[eric.niebler at gmail dot com]

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

Eric Niebler  changed:

   What|Removed |Added

 CC||eric.niebler at gmail dot com

--- Comment #4 from Eric Niebler  ---
*** Bug 78137 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/77860] [7 Regression] ICE in gimple_build_assign_1, at gimple.c:420

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Doesn't reproduce since r240865.  Started with r237318.
Does r240865 fix this or just make it latent?

[Bug c++/54535] gcc fails to warn when functions are inlined

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
-Werror=div-by-zero
is only for literal written code and not for code at optimization time.

[Bug c/53562] Add -Werror= support for -D_FORTIFY_SOURCE / __builtin___memcpy_chk

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
A new option has been implemented in the patch below:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02308.html

[Bug middle-end/78138] New: missing warnings on buffer overflow with non-constant source length

[msebor at gcc dot gnu.org]

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

Bug ID: 78138
   Summary: missing warnings on buffer overflow with non-constant
source length
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is just a record of a limitation addressed in a patch already posted for
review (https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02308.html).

In the following program the calls to strcpy and memcpy clearly overflow, even
though the exact size of the source sequence in each case isn't known.   It
would be helpful if GCC detected this overflow and issued a warning at compile
time, rather than having the compiled program crash at runtime.

$ cat b.c && for o in "" -DCHK=1; do /build/gcc-git/gcc/xgcc -B
/build/gcc-git/gcc $o -O2 -S b.c; done
char d [5];

#ifdef CHK
#  define bos(p, t)__builtin_object_size (d, t)
#  define memcpy(d, s, n)  __builtin___memcpy_chk (d, s, n, bos (d, 1))
#  define strcpy(d, s) __builtin___strcpy_chk (d, s, bos (d, 1))
#else
void* memcpy (void*, const void*, unsigned long);
extern char* strcpy (char*, const char*);
#endif

void f (int i, int j)
{
  strcpy (d, j ? "12345" : "123456");
}

void g (void *p)
{
  extern unsigned n;
  if (n < 17 || 32 < n) n = 7;

  memcpy (d, p, n);
};

[Bug middle-end/78138] missing warnings on buffer overflow with non-constant source length

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-28
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=53562
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/57082] brace initialization requires public destructor

[lucdanton at free dot fr]

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

lucdanton at free dot fr changed:

   What|Removed |Added

 CC||lucdanton at free dot fr

--- Comment #1 from lucdanton at free dot fr ---
Using a very similar testcase I bisected the issue to r239783:

//--
struct no_destr {
no_destr() = default;
protected:
~no_destr() = default;
};

int main()
{
// error: 'no_destr::~no_destr()' is protected within this context
new no_destr {};
}

[Bug rtl-optimization/78029] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[sebastian.hu...@embedded-brains.de]

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

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #7 from Sebastian Huber  ---
I get the ICE while building a libgcc variant:

/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc
-B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc
-B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/
-isystem
/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/targ-include
-isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include
-B/opt/rtems-4.12/powerpc-rtems4.12/bin/
-B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem
/opt/rtems-4.12/powerpc-rtems4.12/include -isystem
/opt/rtems-4.12/powerpc-rtems4.12/sys-include-g -O2 -mcpu=8540 -O2
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../newlib/libc/sys/rtems/include
-g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -I. -I. -I../../.././gcc
-I/home/EB/sebastian_h/archive/gcc-git/libgcc
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/.
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include  -DHAVE_CC_TLS  -o
_addsub_df.o -MT _addsub_df.o -MD -MP -MF _addsub_df.dep
-DFINE_GRAINED_LIBRARIES -DL_addsub_df  -c
/home/EB/sebastian_h/archive/gcc-git/libgcc/fp-bit.c -fvisibility=hidden
-DHIDE_EXPORTS