[Bug tree-optimization/79291] r244897 introduces IV related performance issues for daxpy on MIPS by enabling peeling for alignment

[doug.gilmore at imgtec dot com]

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

--- Comment #5 from Doug Gilmore  ---
> Bin:  I suspect this is also now broken on ARM, can
> you check?
Oops, sorry I forgot that this problem is not exposed
on the original ARM/Neon for DP.  Sorry for the noise.

[Bug tree-optimization/79291] r244897 introduces IV related performance issues for daxpy on MIPS by enabling peeling for alignment

[doug.gilmore at imgtec dot com]

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

--- Comment #4 from Doug Gilmore  ---
> It also looks like mips lacks implementation of any of the
> vectorizer cost hooks and thus defaults to
> default_builtin_vectorization_cost which means that unaligned
> loads/stores have double cost.
I have investigated that in the past and that costing is needed
in some cases.  I'll start looking into that again.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[doug.gilmore at imgtec dot com]

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

--- Comment #20 from Doug Gilmore  ---
I'll collect more tracing data on the costing problem.

Hopefully I post an update in the next few days.

[Bug middle-end/32003] Undocumented -fdump-tree options

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00104.html

[Bug c++/79326] mistakenly rejects valid GNU C++ (typeof) code on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|mistakenly rejects valid|mistakenly rejects valid
   |C++ code on |GNU C++ (typeof) code on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #1 from Andrew Pinski  ---
This is a GNU C++ extension.  IIRC a bug like this was closed as won't fix as
decltype works.

[Bug fortran/79312] Empty array in assignment not correctly type-checked

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to john.harper from comment #0)
> This program violates f2008 syntax rule 7.2.1.2(4) but gfortran 6.1.1 on an
> x86-64 system compiles and runs it, printing 0
> 
>program emptyarray5
> implicit none
> real a(0)
> a = [logical::]
> print *,size(a)
>   end program emptyarray5
> 
> ! f2008 7.2.1.2 (4) if the variable is polymorphic it shall be type
> ! compatible with expr ; otherwise the declared types of the variable and
> ! expr shall conform as specified in Table 7.8,
> !
> ! Table 7.8: Type conformance for the intrinsic assignment statement
> !
> ! Type of the variable | Type of expr
> !---+
> !   integer|   integer, real, complex   |
> ! real |   integer, real, complex   |
> !   complex|   integer, real, complex   |
> !  character   |  character |
> !   logical|   logical  |
> !  derived type|  same derived type as the variable |
> !---+

Index: resolve.c
===
--- resolve.c   (revision 245068)
+++ resolve.c   (working copy)
@@ -9911,6 +9911,13 @@ resolve_ordinary_assign (gfc_code *code,
   lhs = code->expr1;
   rhs = code->expr2;

+  if (rhs->ts.type == BT_LOGICAL  && lhs->ts.type != BT_LOGICAL)
+{
+  gfc_error ("LOGICAL expression at %L assigned to a non-LOGICAL entity",
+>where);
+  return false;
+}
+
   if (rhs->is_boz
   && !gfc_notify_std (GFC_STD_GNU, "BOZ literal at %L outside "
  "a DATA statement and outside INT/REAL/DBLE/CMPLX",

[Bug c++/79329] bogus operator delete access check during instantiation of new-expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/66144] vector element operator produces very bad code

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug target/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|pthaugen at gcc dot gnu.org|meissner at gcc dot 
gnu.org

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

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com
Summary|[7 Regression] wrong code   |[7 Regression] ira and lra
   |at -O3 on x86_64-linux-gnu  |wrong code at -O2 and -Os
   |in 32-bit mode (but not in  |on i686-linux
   |64-bit mode)|

--- Comment #6 from Alan Modra  ---
The testcase in comment #2 fails with x86 -m32 -Os even after fixing the ira
failure, due to lra doing
"Changing pseudo 89 in operand 1 of insn 9 on equiv [const(`d'+0x13c0)]"
This puts the load of d[300...0][0] before the printf, just like the ira bug.
The -Os failure is a regression from gcc-3.4

[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00101.html

[Bug target/79158] gcc.target/powerpc/pr70669.c fails on powerpc BE

[meissner at linux dot vnet.ibm.com]

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

--- Comment #2 from Michael Meissner  ---
On Mon, Jan 30, 2017 at 09:17:26PM +, pthaugen at gcc dot gnu.org wrote:
> Mike, Does this reasoning sound correct to you? If so I'll submit a patch.

That looks fine.  Thanks.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at airs dot com]

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

--- Comment #14 from Ian Lance Taylor  ---
> Could you maybe also backport the fix for PR/79037? [1]

Done.

> Btw, even with the fixes from this PR/79281 and PR/79037, the "go" command is 
> still crashing on m68k with gcc-6. It might be possible that this is the 
> reason the build of gcc-7 fails for this reason, doesn't it?

It could be related, but building GCC does not actually run the go command.

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at gcc dot gnu.org]

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

--- Comment #14 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Feb  1 23:35:59 2017
New Revision: 245110

URL: https://gcc.gnu.org/viewcvs?rev=245110=gcc=rev
Log:
PR go/79037
Backport from mainline:

compiler, runtime: align gc data for m68k

The current GC requires that the gc data be aligned to at least a 4
byte boundary, because it uses the lower two bits of the address for
flags (see LOOP and PRECISE in runtime/mgc0.c).  As the gc data is
stored as a [...]uintptr, that is normally always true.  However, on
m68k, that only guarantees 2 byte alignment.  Fix it by forcing the
alignment.

The parfor code used by the current GC requires that the parfor data
be aligned to at least an 8 byte boundary.  The code in parfor.c
verifies this.  This is normally true, as the data uses uint64_t
values, but, again, this must be enforced explicitly on m68k.

Fixes GCC PR 79037.

Change-Id: Ifdf422db7b37e88f490e54c2f6d249117d359dd6

Modified:
branches/gcc-6-branch/gcc/go/gofrontend/types.cc
branches/gcc-6-branch/libgo/runtime/go-unsafe-pointer.c
branches/gcc-6-branch/libgo/runtime/parfor.c
branches/gcc-6-branch/libgo/runtime/runtime.h

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
(In reply to Ian Lance Taylor from comment #11)
> GCC 7 will require a different fix, as the code has moved from C to Go.  I'm
> not sure what the best approach is.

Btw, even with the fixes from this PR/79281 and PR/79037, the "go" command is
still crashing on m68k with gcc-6. It might be possible that this is the reason
the build of gcc-7 fails for this reason, doesn't it?

The crash in "go" on gcc-6 seems to be related to Go's Mutex type as this code
[1] crashes as well. I will file a separate bug report for that.

> [1] https://tour.golang.org/concurrency/9

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #12 from John Paul Adrian Glaubitz  ---
(In reply to Ian Lance Taylor from comment #11)
> Thanks.  I committed the patch to the GCC 6 branch.
> 
> GCC 7 will require a different fix, as the code has moved from C to Go.  I'm
> not sure what the best approach is.

Ok, thanks. We can look into this later.

Could you maybe also backport the fix for PR/79037? [1]

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

[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311

[orion at cora dot nwra.com]

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

--- Comment #10 from Orion Poplawski  ---
With gcc-7.0.1-0.4.fc26, we no longer get ICEs, but hdf5, openblas fail their
tests on ppc64le, and python2/numpy appears to segfault in tests.  So something
does not appear to be right.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at airs dot com]

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

--- Comment #11 from Ian Lance Taylor  ---
Thanks.  I committed the patch to the GCC 6 branch.

GCC 7 will require a different fix, as the code has moved from C to Go.  I'm
not sure what the best approach is.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at gcc dot gnu.org]

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

--- Comment #10 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Feb  1 22:58:43 2017
New Revision: 245109

URL: https://gcc.gnu.org/viewcvs?rev=245109=gcc=rev
Log:
PR go/79281

Force Lock and Note to be aligned to a 4 byte boundary.  This is
required by the kernel but is not enforced on m68k.

Patch by John Paul Adrian Glaubitz.

Modified:
branches/gcc-6-branch/libgo/runtime/runtime.h

[Bug c++/79331] ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-01
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started to ICE with r244056.

[Bug c++/79325] ICE on valid GNU C++ code (typeof) on x86_64-linux-gnu: in arg_assoc_type, at cp/name-lookup.c:5823

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-01
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
(In reply to Andrew Pinski from comment #1)
> Does it work if you use decltype instead of typeof?

Replacing the first, the test-case can be successfully compiled.

[Bug translation/79332] New: Several bugs related to translation in gcc 7.1-b20170101

[roland.illig at gmx dot de]

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

Bug ID: 79332
   Summary: Several bugs related to translation in gcc
7.1-b20170101
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

The following are all small issues, therefore I think it is easier to address
them all at once.

1.  Make sure that multiline string literals always end in a space.
(PARAM_MAX_STORES_TO_MERGE, PARAM_MAX_SSA_NAME_QUERY_DEPTH)

2.  Remove strictly redundant comments from params.def, i.e. those
comments that exactly repeat the text in the string literal.
(PARAM_MAX_STORES_TO_SINK)

2a. Remove nearly strictly redundant comments from params.def.
(PARAM_MAX_SLSR_CANDIDATE_SCAN)

3.  Remove all instances of dot dot quote (..") from params.def.

4.  Explain what "asan" in "asan-globals" means.
Should I translate it in capital letters?

5.  To be useful, the explanation in invoke.texi must not merely
repeat the parameter description from params.def.
(PARAM_MAX_FSM_THREAD_LENGTH)

By the way, thank you for providing invoke.texi, which provides good
explanations to the very short descriptions in params.def.

To make this even more useful, the explanations from invoke.texi
should be included in the gcc.pot in order to provide the translators
with more context. As it is now, I have to lookup each of the parameters
from params.def in invoke.texi to see what it actually means.
This definition should be provided as a translator comment.

[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #8 from Bill Schmidt  ---
Fixed for server targets.  We will defer 64-bit Darwin until Iain returns from
travels.

[Bug c++/79294] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Feb  1 22:11:57 2017
New Revision: 245108

URL: https://gcc.gnu.org/viewcvs?rev=245108=gcc=rev
Log:
2017-02-01  Bill Schmidt  

PR target/70012
* gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c: Adjust test
conditions.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c

[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler

[sandra at gcc dot gnu.org]

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

--- Comment #3 from sandra at gcc dot gnu.org ---
Created attachment 40649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40649=edit
patch to use "hello, world" to test linking

The attached patch is sufficient to cause a link failure in cases where a
linker script or additional library options are required to support stdio.h
features.  This might not be fully general since other C99 feature checks
assume that math.h, complex.h, stdlib.h, and wchar.h features don't require any
special linker recipe either.

[Bug c++/79331] New: ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451

[su at cs dot ucdavis.edu]

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

Bug ID: 79331
   Summary: ICE on valid C++14 code (with initialized lambda
capture) on x86_64-linux-gnu: in
canonicalize_component_ref, at gimplify.c:2451
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The ICE seems to be a recent regression, but the code is mistakenly rejected by
earlier versions of GCC. 

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170201 (experimental) [trunk revision 245083] (GCC) 
$ 
$ icc -c -std=c++14 small.cpp
$ clang++ -c -std=c++14 small.cpp
$ 
$ g++-trunk -c -std=c++14 small.cpp
small.cpp: In lambda function:
small.cpp:9:14: error: field ‘bar()::<lambda()>::<lambda()>::’
invalidly declared function type
   return f ();
  ^
small.cpp: In lambda function:
small.cpp:9:16: internal compiler error: in canonicalize_component_ref, at
gimplify.c:2451
   return f ();
  ~~^~
0xb8ade3 canonicalize_component_ref
../../gcc-source-trunk/gcc/gimplify.c:2451
0xbaaa37 gimplify_compound_lval
../../gcc-source-trunk/gcc/gimplify.c:2877
0xba0761 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11155
0xba08b0 gimplify_addr_expr
../../gcc-source-trunk/gcc/gimplify.c:5860
0xba08b0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11249
0xbac0a6 gimplify_call_expr
../../gcc-source-trunk/gcc/gimplify.c:3183
0xba1275 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11174
0xbaf657 gimplify_modify_expr
../../gcc-source-trunk/gcc/gimplify.c:5457
0xba26ec gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11203
0xba52c6 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:6478
0xba1a3f gimplify_and_add(tree_node*, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:435
0xba1a3f gimplify_return_expr
../../gcc-source-trunk/gcc/gimplify.c:1521
0xba1a3f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11462
0xba52c6 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:6478
0xba132b gimplify_cleanup_point_expr
../../gcc-source-trunk/gcc/gimplify.c:6230
0xba132b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11578
0xba52c6 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:6478
0xba1a9b gimplify_statement_list
../../gcc-source-trunk/gcc/gimplify.c:1716
0xba1a9b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11630
0xba52c6 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:6478
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 





int foo ();

int bar ()
{
  return [ (foo)] 
  { 
return [=] 
{ 
  return f (); 
} 
();
  } 
  ();
}

[Bug fortran/79312] Empty array in assignment not correctly type-checked

[harper at msor dot vuw.ac.nz]

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

--- Comment #2 from harper at msor dot vuw.ac.nz ---
Another manifestation of this bug:

   program emptyarray6
 implicit none
 logical,allocatable:: OK(:)
 OK = [logical::]==[real::]
 print *,OK
   end program emptyarray6

compiles and prints nothing but I think it should have refused to compile
(logical expression)==(real expression)

On Wed, 1 Feb 2017, dominiq at lps dot ens.fr wrote:

> Date: Wed, 1 Feb 2017 19:21:00 +
> From: dominiq at lps dot ens.fr 
> To: John Harper 
> Subject: [Bug fortran/79312] Empty array in assignment not correctly
> type-checked
> Resent-Date: Thu, 2 Feb 2017 08:21:23 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79312
>
> Dominique d'Humieres  changed:
>
>   What|Removed |Added
> 
> Status|UNCONFIRMED |NEW
>   Last reconfirmed||2017-02-01
> Ever confirmed|0   |1
>
> --- Comment #1 from Dominique d'Humieres  ---
> Confirmed from at least 4.8 up to trunk (7.0). Note that compiling
>
>   program emptyarray5
>implicit none
>real a(1)
>a = .true.
>print *,a
>  end program emptyarray5
>
> gives
>
>a = .true.
>1
> Error: Can't convert LOGICAL(4) to REAL(4) at (1)
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045

[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Feb  1 21:36:09 2017
New Revision: 245107

URL: https://gcc.gnu.org/viewcvs?rev=245107=gcc=rev
Log:
PR ada/79309
* adaint.c (__gnat_killprocesstree): Use strlen instead of sizeof.

Modified:
trunk/gcc/ada/adaint.c

[Bug c++/79308] ICE on specialization of nested template classes (in finish_member_declaration, at cp/semantics.c:2963)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #4 from Martin Liška  ---
(In reply to bjhend from comment #3)
> (In reply to Martin Liška from comment #2)
> > Confirmed, all releases I have ICE (4.5.0+).
> 
> Hi Martin,
> 
> thanks for confirmation. You also added the keyword ice-on-INvalid-code, but
> I think the code is valid.
> 
> The C++-11 standard, paragraph 14.7.3, clause 5 contains a similar example
> (see nested template struct C) with a single element function. Additionally,
> I cannot find anything in the text, saying that this code is invalid, but I
> might be wrong in interpreting the standard.

Sorry for such keyword, I'm not familiar with the standard. Let's switch that
to valid and see what maintainers think about it.

[Bug fortran/79330] gfortran 5.4.0/6.3.0/7.0.0 misinterpret type of character literal bind(C,name=...)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
.

[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
.

[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
Fixed and tested on aarch64-linux-gnu so closing.

[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Feb  1 20:36:23 2017
New Revision: 245103

URL: https://gcc.gnu.org/viewcvs?rev=245103=gcc=rev
Log:
PR ada/79309
* adaint.c (__gnat_killprocesstree): Fix broken string handling.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/adaint.c

[Bug c++/79296] [7 Regression] ICE in mangle_decl, at cp/mangle.c:3845

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Created attachment 40648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40648=edit
reduced testcase

trying to mangle a lambda but asserting that it has linkage.

[Bug fortran/79330] New: gfortran 5.4.0/6.3.0/7.0.0 misinterpret type of character literal bind(C,name=...)

[damian at sourceryinstitute dot org]

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

Bug ID: 79330
   Summary: gfortran 5.4.0/6.3.0/7.0.0 misinterpret type of
character literal bind(C,name=...)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

This a gfortran issue appears in the interface body below, but doesn't
disappears if the procedure is implemented without a separate interface body.
Apparently, the compiler is not exposing variables from the host scope into the
interface body.  Dropping the "module" from "module subroutine" and explicitly
importing the constant via "import :: PREFIX" produces the same error:

$ cat caf_openmp.f90 
module caf_openmp_interface
  implicit none
  character(len=*), parameter :: PREFIX="_gfortran_"
  interface 
module subroutine this_image() bind(C,name=PREFIX//"caf_this_image")
  implicit none
end subroutine
  end interface
end module

$ gfortran -c caf_openmp.f90 
caf_openmp.f90:5:47:

 module subroutine this_image() bind(C,name=PREFIX//"caf_this_image")
   1
Error: Operands of string concatenation operator at (1) are
REAL(4)/CHARACTER(1)
caf_openmp.f90:6:19:

   implicit none
   1
Error: Unexpected IMPLICIT NONE statement in INTERFACE block at (1)
caf_openmp.f90:7:7:

 end subroutine
   1
Error: Expecting END INTERFACE statement at (1)

$ gfortran --version
GNU Fortran (MacPorts gcc7 7-20170108_0) 7.0.0 20170108 (experimental)

This was also tested with gfortran 5.4.0 and 6.3.0.  It would be great if any
fix could be backported to the 5 and 6 branches as well.

[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
The insn needs to have a "v" constraint, rather than "" which allows any
register.  In addition in the PowerPC backend, we tend to want at least
gpc_reg_operand which can do extra checks, or altivec_register_operand which
will only match Altivec registers.  The insn should look like:

(define_insn "bcd"
  [(set (match_operand:V1TI 0 "gpc_reg_operand" "=v")
(unspec:V1TI [(match_operand:V1TI 1 "gpc_reg_operand" "v")
  (match_operand:V1TI 2 "gpc_reg_operand" "v")
  (match_operand:QI 3 "const_0_to_1_operand" "n")]
 UNSPEC_BCD_ADD_SUB))
   (clobber (reg:CCFP CR6_REGNO))]
  "TARGET_P8_VECTOR"
  "bcd. %0,%1,%2,%3"
  [(set_attr "length" "4")
   (set_attr "type" "vecsimple")])

[Bug c++/79308] ICE on specialization of nested template classes (in finish_member_declaration, at cp/semantics.c:2963)

[bjh...@sags-per-mail.de]

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

--- Comment #3 from bjhend  ---
(In reply to Martin Liška from comment #2)
> Confirmed, all releases I have ICE (4.5.0+).

Hi Martin,

thanks for confirmation. You also added the keyword ice-on-INvalid-code, but I
think the code is valid.

The C++-11 standard, paragraph 14.7.3, clause 5 contains a similar example (see
nested template struct C) with a single element function. Additionally, I
cannot find anything in the text, saying that this code is invalid, but I might
be wrong in interpreting the standard.

[Bug c++/69959] [6 Regression] gcc-6 doesn't build gcc-5 anymore

[rogerpack2005 at gmail dot com]

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

Roger Pack  changed:

   What|Removed |Added

 CC||rogerpack2005 at gmail dot com

--- Comment #5 from Roger Pack  ---
FWIW I believe I ran into this building 4.9.3 using gcc 6.2.0

[Bug fortran/79287] include files not searched for relative to the file containing the fortran include statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-01
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
My F2015 draft reads

> 3.4 Including source text
> ...
> 8 The interpretation of char-literal-constant is processor dependent.
> An example of a possible valid interpretation is that char-literal-constant
> is the name of a file that contains the source text to be included.

IMO that means that both behaviors are standard conforming. If this is correct,
I suggest to close the PR as WONTFIX.

[Bug fortran/79312] Empty array in assignment not correctly type-checked

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (7.0). Note that compiling

   program emptyarray5
implicit none
real a(1)
a = .true.
print *,a
  end program emptyarray5

gives

a = .true.
1
Error: Can't convert LOGICAL(4) to REAL(4) at (1)

[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Yes, bcdadd requires all of its arguments to be altivec registers.

However, the pattern below is wrong:

(define_insn "bcd"
  [(set (match_operand:V1TI 0 "register_operand" "")
(unspec:V1TI [(match_operand:V1TI 1 "register_operand" "")
  (match_operand:V1TI 2 "register_operand" "")
  (match_operand:QI 3 "const_0_to_1_operand" "")]
 UNSPEC_BCD_ADD_SUB))
   (clobber (reg:CCFP CR6_REGNO))]
  "TARGET_P8_VECTOR"
  "bcd. %0,%1,%2,%3"
  [(set_attr "length" "4")
   (set_attr "type" "vecsimple")])

It should have "v" constraints for each of the registers, and "n" for the
integer.  It probably should use altivec_register_operand (or at least
gpc_reg_operand) instead of register_operand as well.

[Bug c++/79329] New: bogus operator delete access check during instantiation of new-expression

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 79329
   Summary: bogus operator delete access check during
instantiation of new-expression
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase:

struct A {
  A();
  void *operator new(unsigned long, void*);
private:
  void operator delete(void*, int);
};
A *p = new (p) A;

gives a bogus diagnostic:

:7:16: error: 'static void A::operator delete(void*, int)' is private
within this context
A *p = new (p) A;
   ^
:5:8: note: declared private here
  void operator delete(void*, int);
   ^~~~

Adding a second irrelevant operator delete overload suppresses the diagnostic.
(Perhaps the access check is being performed prior to filtering out
non-matching operator delete functions in the case where the lookup result is
not an overload set.)

[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

[Bug c++/79113] [7 Regression] ICE inheriting a default constructor

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #2 from Nathan Sidwell  ---
Current trunk compiles without error

[Bug c++/79296] [7 Regression] ICE in mangle_decl, at cp/mangle.c:3845

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/79077] [7 regression][new inheriting ctors] bad code for inherited ctor

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #3 from Nathan Sidwell  ---
I think this is the same as 78495, which was fixed on Jan 20.  current trunk
prints the expected output.

[Bug tree-optimization/69224] [5/6/7 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2016-01-11 00:00:00 |2017-2-1
 CC||aldyh at gcc dot gnu.org
  Known to work||4.7.4
  Known to fail||4.8.1, 4.8.2, 4.8.3, 4.8.4,
   ||7.0

--- Comment #7 from Aldy Hernandez  ---
Using http://gcc.godbolt.org/, I see:

4.7.4 works

4.8.1 - 4.9.x has one warning

5.1 has three warnings

5.2 - 6.x has one warning

Compiling a recent trunk r245057 has one warning as well.

[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #3 from Jakub Jelinek  ---
This causes miscompilation of TeX.

[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-01
 CC||jakub at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|wrong code at -O2 and   |[7 Regression] wrong code
   |-fprintf-return-value   |at -O2 and
   ||-fprintf-return-value
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
This is clearly a bug in what I've been asking to fix earlier:
http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00385.html
In particular, the code isn't structured to differentiate between computation
of the possible range of values the argument can have, then adjustment of that
range based on a possible implicit conversion due to say signed to unsigned or
vice versa conversion and finally from that range of values figure out what
values yield minimum or maximum number of characters (which is not necessarily
the range boundaries).

Right now, the code mixes that up:
1) for arg which is SSA_NAME with VR_RANGE, argmin is set to minimum and argmax
to maximum (well,
  argmin = build_int_cst (argtype, wi::fits_uhwi_p (min)
  ? min.to_uhwi () : min.to_shwi ());
  argmax = build_int_cst (argtype, wi::fits_uhwi_p (max)
  ? max.to_uhwi () : max.to_shwi ());
is also questionable code, it can throw away various bits from those values,
why doesn't it use wide_int_to_tree?); at this point argmin and argmax are the
range boundaries
2) otherwise, it computes some values, based on sign/precision of the type
etc.;
these values are not range boundaries, but argmin stands for value with
(hopefully) shortest string representation and argmax with longest string
representation
3) then it swaps them if argmin is bigger than argmax
4) then adjust_range_for_overflow is applied
5) then it picks those argmin and argmax values and for unsigned type uses
their representation lengths as minimum and maximum, for signed vice versa

So, for this testcase what happens is that we have a VR_RANGE, where the first
value is [-35791394, 35791394] and second value [0, 2147483647].
So, 1) applies, 2)/3)/4) are skipped and we figure out the range for the first
argument is [9, 9] (when it actually is [3, 9]) and second one is [2, 10]
(correct).  So the result is [11, 19] when it should have been [5, 19].
Obviously 0 has shorter representation than both -35791394 and 35791394.

[Bug c++/79328] New: Wshadow and lambda captures

[nathan at gcc dot gnu.org]

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

Bug ID: 79328
   Summary: Wshadow and lambda captures
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

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

-Wshadow warnings have a confusing interaction with lambda captures.
1) The names of init lambda captures are not checked.
2) local names are checked regardless of whether there is a default capture to
make an outer object accessible

The original report also mentioned the following case:
T x;
[=, x = std::move(x)] {};
if T is a non-copyable type, the default = capture couldn't capture it.

IMHO such nuance shouldn't affect whether or not this gives a warning (so it
should warn).

I think it clear that #1 should be checked, but I can see arguments for and
against #2.  I think of name hiding as (almost) a syntactic check, and whether
an object can be captured is more of a semantic check.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[vogt at linux dot vnet.ibm.com]

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

--- Comment #38 from Dominik Vogt  ---
Finally, the total between after the last and before the first patch.  Overall,
some tests gain some performance and others lose some.  The total number of
instructions has grown somewhat (especially tonto, calculix, dealII and wrf),
but there's no obvious connection between an increased number of instructions
and loss of performance.

Is this what can be expected of the patches?

All compiled with -O3 -funroll-loops -march=zEC12.

r244260 vs. r243994
---
   run-old.resultrun-new.result
f410.bwaves 1.28s1.27s (  -0.78%,   0.79% )
f416.gamess 7.10s6.82s (  -3.94%,   4.11% )
f433.milc   5.53s5.53s (   0.00%,   0.00% )
f434.zeusmp 2.19s2.18s (  -0.46%,   0.46% )
f435.gromacs1.34s1.33s (  -0.75%,   0.75% )
f436.cactusADM 24.72s   24.80s (   0.32%,  -0.32% )
f437.leslie3d   2.76s2.75s (  -0.36%,   0.36% )
f444.namd  12.13s   12.13s (   0.00%,   0.00% )
f447.dealII 2.03s2.02s (  -0.49%,   0.50% )
f450.soplex 3.90s3.92s (   0.51%,  -0.51% )
f453.povray 2.88s2.86s (  -0.69%,   0.70% )
f454.calculix  17.32s   17.36s (   0.23%,  -0.23% )
f459.GemsFDTD   7.22s7.13s (  -1.25%,   1.26% )
f465.tonto  0.93s0.93s (   0.00%,   0.00% )
f470.lbm2.65s2.66s (   0.38%,  -0.38% )
f481.wrf3.84s3.84s (   0.00%,   0.00% )
f482.sphinx3   10.49s   10.56s (   0.67%,  -0.66% )
i400.perlbench  7.58s7.25s (  -4.35%,   4.55% )
i401.bzip2  3.98s3.96s (  -0.50%,   0.51% )
i403.gcc1.00s1.01s (   1.00%,  -0.99% )
i429.mcf1.49s1.49s (   0.00%,   0.00% )
i445.gobmk  3.55s3.53s (  -0.56%,   0.57% )
i456.hmmer  1.56s1.55s (  -0.64%,   0.65% )
i458.sjeng  3.81s3.79s (  -0.52%,   0.53% )
i462.libquantum17.12s   17.11s (  -0.06%,   0.06% )
i464.h264ref3.14s3.17s (   0.96%,  -0.95% )
i471.omnetpp   11.39s   11.52s (   1.14%,  -1.13% )
i473.astar  7.22s7.26s (   0.55%,  -0.55% )
i483.xalancbmk  7.62s7.69s (   0.92%,  -0.91% )

--

f470.lbm 2984 insns identical
i429.mcf 4165 insns -4 smaller
i462.libquantum 11735 insns +0 changed
i473.astar 12460 insns +32 BIGGER!, 2 funcs bigger (max +79 insns)
f410.bwaves 9820 insns +7 BIGGER!, 1 funcs bigger (max +7 insns)
i401.bzip2 22439 insns -63 smaller
f437.leslie3d 28725 insns +9 BIGGER!, 5 funcs bigger (max +19 insns)
i458.sjeng 38864 insns -26 smaller, 2 funcs bigger (max +24 insns)
f433.milc 35091 insns -70 smaller, 1 funcs bigger (max +5 insns)
f482.sphinx3 51879 insns +4 BIGGER!, 5 funcs bigger (max +15 insns)
i456.hmmer 85157 insns -33 smaller, 4 funcs bigger (max +91 insns)
f444.namd 76220 insns -3 smaller
f434.zeusmp 73937 insns +43 BIGGER!, 3 funcs bigger (max +27 insns)
f459.GemsFDTD 111465 insns +84 BIGGER!, 5 funcs bigger (max +57 insns)
f436.cactusADM 201648 insns +125 BIGGER!, 37 funcs bigger (max +68 insns)
f435.gromacs 250725 insns -53 smaller, 11 funcs bigger (max +25 insns)
i471.omnetpp 135992 insns -435 smaller, 15 funcs bigger (max +80 insns)
i445.gobmk 249112 insns -1167 smaller, 16 funcs bigger (max +82 insns)
f450.soplex 131531 insns -558 smaller, 22 funcs bigger (max +18 insns)
f453.povray 247399 insns -48 smaller, 3 funcs bigger (max +92 insns)
i400.perlbench 305683 insns -216 smaller, 51 funcs bigger (max +554 insns)
f454.calculix 478026 insns +485 BIGGER!, 22 funcs bigger (max +157 insns)
i464.h264ref 316483 insns -76 smaller, 8 funcs bigger (max +76 insns)
i403.gcc 800574 insns -782 smaller, 100 funcs bigger (max +1674 insns)
f465.tonto 1138432 insns +2511 BIGGER!, 235 funcs bigger (max +455 insns)
f447.dealII 764322 insns +597 BIGGER!, 171 funcs bigger (max +295 insns)
f481.wrf 1081604 insns +2769 BIGGER!, 141 funcs bigger (max +2329 insns)
i483.xalancbmk 919758 insns -483 smaller, 277 funcs bigger (max +1002 insns)
f416.gamess 2553939 insns -1589 smaller, 127 funcs bigger (max +46 insns)

statistics:
---
29  tests (total)
11  test executables have grown (more insns)
16  test executables have shrunk (fewer insns)
10140169insns total (old)
+1060   insns difference
+104insns per 1,000,000
-360weighted insns per 1,000,000 *
1264

[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019

[m.ostapenko at samsung dot com]

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

--- Comment #7 from Maxim Ostapenko  ---
Created attachment 40646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40646=edit
Fix 2

Iain, could you test the following patch? This one is likely to be applied
upstream.
As a side note, LLVM folks are not very happy with these patches (they lack of
buildbots to test them). Thus I suspect that for future releases we'll need a)
apply Darwin 10 patches locally or b) disable ASan for Darwin 10.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[vogt at linux dot vnet.ibm.com]

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

--- Comment #37 from Dominik Vogt  ---
r244260 vs. r244256 (comment 25)
---
   run-old.resultrun-new.result
f410.bwaves 1.27s1.27s (   0.00%,   0.00% )
f416.gamess 6.80s6.82s (   0.29%,  -0.29% )
f433.milc   5.56s5.53s (  -0.54%,   0.54% )
f434.zeusmp 2.18s2.18s (   0.00%,   0.00% )
f435.gromacs1.36s1.33s (  -2.21%,   2.26% )
f436.cactusADM 24.66s   24.75s (   0.36%,  -0.36% )
f437.leslie3d   2.76s2.75s (  -0.36%,   0.36% )
f444.namd  12.13s   12.13s (   0.00%,   0.00% )
f447.dealII 2.05s2.01s (  -1.95%,   1.99% )
f450.soplex 3.97s3.92s (  -1.26%,   1.28% )
f453.povray 2.91s2.86s (  -1.72%,   1.75% )
f454.calculix  17.28s   17.36s (   0.46%,  -0.46% )
f459.GemsFDTD   7.28s7.14s (  -1.92%,   1.96% )
f465.tonto  0.94s0.94s (   0.00%,   0.00% )
f470.lbm2.66s2.65s (  -0.38%,   0.38% )
f481.wrf3.84s3.84s (   0.00%,   0.00% )
f482.sphinx3   10.59s   10.61s (   0.19%,  -0.19% )
i400.perlbench  7.49s7.30s (  -2.54%,   2.60% )
i401.bzip2  3.97s3.96s (  -0.25%,   0.25% )
i403.gcc1.01s1.01s (   0.00%,   0.00% )
i429.mcf1.49s1.49s (   0.00%,   0.00% )
i445.gobmk  3.61s3.53s (  -2.22%,   2.27% )
i456.hmmer  1.56s1.57s (   0.64%,  -0.64% )
i458.sjeng  3.77s3.79s (   0.53%,  -0.53% )
i462.libquantum17.13s   17.08s (  -0.29%,   0.29% )
i464.h264ref3.30s3.17s (  -3.94%,   4.10% )
i471.omnetpp   11.38s   11.52s (   1.23%,  -1.22% )
i473.astar  7.58s7.26s (  -4.22%,   4.41% )
i483.xalancbmk  7.53s7.73s (   2.66%,  -2.59% )

--

f470.lbm 2984 insns +0 changed
i429.mcf 4506 insns -346 smaller, 1 funcs bigger (max +2 insns)
i462.libquantum 11728 insns +7 BIGGER!, 5 funcs bigger (max +4 insns)
i473.astar 12309 insns +182 BIGGER!, 8 funcs bigger (max +109 insns)
i401.bzip2 22375 insns +11 BIGGER!, 20 funcs bigger (max +25 insns)
f437.leslie3d 28715 insns +21 BIGGER!, 2 funcs bigger (max +18 insns)
i458.sjeng 38693 insns +145 BIGGER!, 15 funcs bigger (max +69 insns)
f433.milc 34740 insns +265 BIGGER!, 49 funcs bigger (max +72 insns)
f482.sphinx3 52048 insns -148 smaller, 37 funcs bigger (max +195 insns)
i456.hmmer 84420 insns +676 BIGGER!, 61 funcs bigger (max +518 insns)
f444.namd 76218 insns +0 changed, 1 funcs bigger (max +11 insns)
f434.zeusmp 73993 insns -7 smaller, 1 funcs bigger (max +1 insns)
f459.GemsFDTD 111458 insns +85 BIGGER!, 9 funcs bigger (max +89 insns)
f436.cactusADM 201167 insns +608 BIGGER!, 86 funcs bigger (max +264 insns)
f435.gromacs 249275 insns +1416 BIGGER!, 104 funcs bigger (max +978 insns)
i471.omnetpp 137902 insns -2351 smaller, 64 funcs bigger (max +410 insns)
i445.gobmk 247898 insns +57 BIGGER!, 182 funcs bigger (max +782 insns)
f450.soplex 127631 insns +3348 BIGGER!, 56 funcs bigger (max +2104 insns)
f453.povray 245450 insns +1900 BIGGER!, 197 funcs bigger (max +2029 insns)
i400.perlbench 304835 insns +632 BIGGER!, 365 funcs bigger (max +930 insns)
f454.calculix 40 insns +714 BIGGER!, 182 funcs bigger (max +562 insns)
i464.h264ref 316389 insns -34 smaller, 61 funcs bigger (max +1116 insns)
i403.gcc 797389 insns +2408 BIGGER!, 503 funcs bigger (max +1371 insns)
f465.tonto 1141420 insns -449 smaller, 329 funcs bigger (max +874 insns)
f447.dealII 764299 insns +556 BIGGER!, 291 funcs bigger (max +1826 insns)
f481.wrf 1084747 insns -388 smaller, 196 funcs bigger (max +1552 insns)
i483.xalancbmk 919878 insns -411 smaller, 507 funcs bigger (max +1508 insns)
f416.gamess 2561829 insns -9468 smaller, 714 funcs bigger (max +1562 insns)

statistics:
---
29  tests (total)
17  test executables have grown (more insns)
9   test executables have shrunk (fewer insns)
10141892insns total (old)
-571insns difference
-56 insns per 1,000,000
-524weighted insns per 1,000,000 *
4046functions have grown (total) **
+2104   insns in most grown function

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[vogt at linux dot vnet.ibm.com]

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

--- Comment #36 from Dominik Vogt  ---
r244207 vs. r244206 (comment 24)
---
   run-old.resultrun-new.result
f410.bwaves 1.27s1.27s (   0.00%,   0.00% )
f416.gamess 6.87s7.21s (   4.95%,  -4.72% )
f433.milc   5.57s5.57s (   0.00%,   0.00% )
f434.zeusmp 2.18s2.18s (   0.00%,   0.00% )
f435.gromacs1.34s1.36s (   1.49%,  -1.47% )
f436.cactusADM 24.63s   24.56s (  -0.28%,   0.29% )
f437.leslie3d   2.76s2.76s (   0.00%,   0.00% )
f444.namd  12.13s   12.13s (   0.00%,   0.00% )
f447.dealII 2.03s2.02s (  -0.49%,   0.50% )
f450.soplex 3.98s3.98s (   0.00%,   0.00% )
f453.povray 2.89s2.90s (   0.35%,  -0.34% )
f454.calculix  17.28s   17.30s (   0.12%,  -0.12% )
f459.GemsFDTD   7.29s7.29s (   0.00%,   0.00% )
f465.tonto  0.94s0.94s (   0.00%,   0.00% )
f470.lbm2.65s2.64s (  -0.38%,   0.38% )
f481.wrf3.84s3.84s (   0.00%,   0.00% )
f482.sphinx3   10.61s   10.58s (  -0.28%,   0.28% )
i400.perlbench  7.32s7.46s (   1.91%,  -1.88% )
i401.bzip2  3.97s3.97s (   0.00%,   0.00% )
i403.gcc1.00s1.01s (   1.00%,  -0.99% )
i429.mcf1.49s1.49s (   0.00%,   0.00% )
i445.gobmk  3.59s3.61s (   0.56%,  -0.55% )
i456.hmmer  1.57s1.56s (  -0.64%,   0.64% )
i458.sjeng  3.76s3.77s (   0.27%,  -0.27% )
i462.libquantum17.11s   17.08s (  -0.18%,   0.18% )
i464.h264ref3.09s3.29s (   6.47%,  -6.08% )
i471.omnetpp   11.20s   11.16s (  -0.36%,   0.36% )
i473.astar  7.58s7.56s (  -0.26%,   0.26% )
i483.xalancbmk  7.43s7.49s (   0.81%,  -0.80% )

--

i401.bzip2 22375 insns +0 changed
i458.sjeng 38701 insns -8 smaller
f482.sphinx3 52038 insns +7 BIGGER!, 1 funcs bigger (max +7 insns)
i456.hmmer 84421 insns +0 changed
f436.cactusADM 201172 insns -6 smaller, 11 funcs bigger (max +5 insns)
f435.gromacs 249282 insns -3 smaller, 1 funcs bigger (max +2 insns)
i471.omnetpp 137988 insns -86 smaller, 3 funcs bigger (max +2 insns)
i445.gobmk 247886 insns +11 BIGGER!, 6 funcs bigger (max +17 insns)
f450.soplex 127628 insns +3 BIGGER!, 2 funcs bigger (max +2 insns)
f453.povray 245457 insns -2 smaller, 3 funcs bigger (max +3 insns)
i400.perlbench 304597 insns +249 BIGGER!, 17 funcs bigger (max +419 insns)
f454.calculix 40 insns identical
i464.h264ref 316393 insns -3 smaller, 4 funcs bigger (max +7 insns)
i403.gcc 796623 insns +798 BIGGER!, 31 funcs bigger (max +977 insns)
f465.tonto 1141420 insns +0 changed
f447.dealII 764301 insns +1 BIGGER!, 11 funcs bigger (max +139 insns)
f481.wrf 1084840 insns -11 smaller
i483.xalancbmk 919877 insns +3 BIGGER!, 1 funcs bigger (max +12 insns)
f416.gamess 2562020 insns +2 BIGGER!, 1 funcs bigger (max +2 insns)

statistics:
---
29  tests (total)
8   test executables have grown (more insns)
7   test executables have shrunk (fewer insns)
10141266insns total (old)
+955insns difference
+94 insns per 1,000,000
+38 weighted insns per 1,000,000 *
92  functions have grown (total) **
+977insns in most grown function

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[vogt at linux dot vnet.ibm.com]

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

--- Comment #35 from Dominik Vogt  ---
r244167 vs. r244166 (comment 21)
---
   run-old.resultrun-new.result
f410.bwaves 1.27s1.27s (   0.00%,   0.00% )
f416.gamess 6.87s6.87s (   0.00%,   0.00% )
f433.milc   5.57s5.57s (   0.00%,   0.00% )
f434.zeusmp 2.18s2.19s (   0.46%,  -0.46% )
f435.gromacs1.34s1.34s (   0.00%,   0.00% )
f436.cactusADM 24.71s   24.69s (  -0.08%,   0.08% )
f437.leslie3d   2.76s2.76s (   0.00%,   0.00% )
f444.namd  12.13s   12.13s (   0.00%,   0.00% )
f447.dealII 2.04s2.03s (  -0.49%,   0.49% )
f450.soplex 3.91s3.98s (   1.79%,  -1.76% )
f453.povray 2.90s2.89s (  -0.34%,   0.35% )
f454.calculix  17.29s   17.29s (   0.00%,   0.00% )
f459.GemsFDTD   7.27s7.30s (   0.41%,  -0.41% )
f465.tonto  0.94s0.94s (   0.00%,   0.00% )
f470.lbm2.65s2.66s (   0.38%,  -0.38% )
f481.wrf3.84s3.84s (   0.00%,   0.00% )
f482.sphinx3   10.62s   10.62s (   0.00%,   0.00% )
i400.perlbench  7.27s7.34s (   0.96%,  -0.95% )
i401.bzip2  3.97s3.97s (   0.00%,   0.00% )
i403.gcc1.01s1.01s (   0.00%,   0.00% )
i429.mcf1.49s1.49s (   0.00%,   0.00% )
i445.gobmk  3.59s3.59s (   0.00%,   0.00% )
i456.hmmer  1.57s1.59s (   1.27%,  -1.26% )
i458.sjeng  3.77s3.76s (  -0.27%,   0.27% )
i462.libquantum17.09s   17.14s (   0.29%,  -0.29% )
i464.h264ref3.09s3.09s (   0.00%,   0.00% )
i471.omnetpp   11.16s   11.25s (   0.81%,  -0.80% )
i473.astar  7.56s7.58s (   0.26%,  -0.26% )
i483.xalancbmk  7.80s7.37s (  -5.51%,   5.83% )

--

i471.omnetpp 138049 insns -75 smaller, 26 funcs bigger (max +202 insns)
f450.soplex 127589 insns +43 BIGGER!, 13 funcs bigger (max +108 insns)
f453.povray 245456 insns +10 BIGGER!, 5 funcs bigger (max +5 insns)
f447.dealII 764156 insns +150 BIGGER!, 35 funcs bigger (max +1800 insns)
i483.xalancbmk 921932 insns -2045 smaller, 391 funcs bigger (max +1513 insns)

command line:
-
  # ak-scripts/compare.sh --suffix -244167-244166 -r 10 -o
/home/vogt/src/gcc/install-244166 -n /home/vogt/src/gcc/install-244167 -c -O3
-march=zEC12 -funroll-loops

output files:
-
executable diff:
/home/vogt/src/minispec-2006/diff-31012017.result-244167-244166
functions grown:
/home/vogt/src/minispec-2006/funcs-grown-31012017.result-244167-244166
build times:
/home/vogt/src/minispec-2006/buildtime-31012017.result-244167-244166

statistics:
---
29  tests (total)
3   test executables have grown (more insns)
2   test executables have shrunk (fewer insns)
10143197insns total (old)
-1917   insns difference
-188insns per 1,000,000
-77 weighted insns per 1,000,000 *
470 functions have grown (total) **
+1800   insns in most grown function

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[vogt at linux dot vnet.ibm.com]

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

--- Comment #34 from Dominik Vogt  ---
Some Spec2006 results on s390x (zEC12) for the files:

r243995 vs. r243994 (comment 14)
---
   run-old.resultrun-new.result
f410.bwaves 1.27s1.28s (   0.79%,  -0.78% )
f416.gamess 7.09s6.61s (  -6.77%,   7.26% )
f433.milc   5.53s5.54s (   0.18%,  -0.18% )
f434.zeusmp 2.19s2.19s (   0.00%,   0.00% )
f435.gromacs1.34s1.34s (   0.00%,   0.00% )
f436.cactusADM 24.63s   24.67s (   0.16%,  -0.16% )
f437.leslie3d   2.76s2.75s (  -0.36%,   0.36% )
f444.namd  12.13s   12.13s (   0.00%,   0.00% )
f447.dealII 2.03s2.02s (  -0.49%,   0.50% )
f450.soplex 3.92s3.96s (   1.02%,  -1.01% )
f453.povray 2.89s2.87s (  -0.69%,   0.70% )
f454.calculix  17.32s   17.23s (  -0.52%,   0.52% )
f459.GemsFDTD   7.24s7.19s (  -0.69%,   0.70% )
f465.tonto  0.94s0.94s (   0.00%,   0.00% )
f470.lbm2.65s2.66s (   0.38%,  -0.38% )
f481.wrf3.84s3.85s (   0.26%,  -0.26% )
f482.sphinx3   10.50s   10.54s (   0.38%,  -0.38% )
i400.perlbench  7.58s7.37s (  -2.77%,   2.85% )
i401.bzip2  3.98s3.95s (  -0.75%,   0.76% )
i403.gcc1.01s1.00s (  -0.99%,   1.00% )
i429.mcf1.49s1.49s (   0.00%,   0.00% )
i445.gobmk  3.56s3.62s (   1.69%,  -1.66% )
i456.hmmer  1.59s1.57s (  -1.26%,   1.27% )
i458.sjeng  3.81s3.84s (   0.79%,  -0.78% )
i462.libquantum17.13s   17.46s (   1.93%,  -1.89% )
i464.h264ref3.14s3.31s (   5.41%,  -5.14% )
i471.omnetpp   11.50s   11.51s (   0.09%,  -0.09% )
i473.astar  7.22s7.54s (   4.43%,  -4.24% )
i483.xalancbmk  7.51s8.15s (   8.52%,  -7.85% )

--

f470.lbm 2984 insns +0 changed
i429.mcf 4165 insns +346 BIGGER!, 3 funcs bigger (max +339 insns)
i462.libquantum 11735 insns -7 smaller, 4 funcs bigger (max +3 insns)
i473.astar 12460 insns -181 smaller, 12 funcs bigger (max +9 insns)
i401.bzip2 22439 insns -13 smaller, 6 funcs bigger (max +25 insns)
f437.leslie3d 28725 insns -21 smaller
i458.sjeng 38864 insns -144 smaller, 10 funcs bigger (max +26 insns)
f433.milc 35091 insns -262 smaller, 7 funcs bigger (max +6 insns)
f482.sphinx3 51879 insns +139 BIGGER!, 16 funcs bigger (max +326 insns)
i456.hmmer 85157 insns -677 smaller, 26 funcs bigger (max +463 insns)
f444.namd 76220 insns +0 changed, 1 funcs bigger (max +11 insns)
f434.zeusmp 73937 insns +6 BIGGER!, 1 funcs bigger (max +7 insns)
f459.GemsFDTD 111465 insns -151 smaller, 3 funcs bigger (max +21 insns)
f436.cactusADM 201648 insns -638 smaller, 69 funcs bigger (max +103 insns)
f435.gromacs 250725 insns -1425 smaller, 64 funcs bigger (max +316 insns)
i471.omnetpp 135992 insns +2095 BIGGER!, 70 funcs bigger (max +2101 insns)
i445.gobmk 249112 insns -726 smaller, 188 funcs bigger (max +1282 insns)
f450.soplex 131531 insns -3584 smaller, 33 funcs bigger (max +546 insns)
f453.povray 247399 insns -1827 smaller, 118 funcs bigger (max +1481 insns)
i400.perlbench 305683 insns -886 smaller, 207 funcs bigger (max +480 insns)
f454.calculix 478026 insns -837 smaller, 97 funcs bigger (max +1036 insns)
i464.h264ref 316483 insns +35 BIGGER!, 44 funcs bigger (max +2229 insns)
i403.gcc 800574 insns -4048 smaller, 514 funcs bigger (max +1614 insns)
f465.tonto 1138432 insns -970 smaller, 139 funcs bigger (max +653 insns)
f447.dealII 764322 insns -873 smaller, 248 funcs bigger (max +2980 insns)
f481.wrf 1081604 insns +32 BIGGER!, 126 funcs bigger (max +404 insns)
i483.xalancbmk 919758 insns +1914 BIGGER!, 731 funcs bigger (max +1835 insns)
f416.gamess 2553939 insns +9369 BIGGER!, 328 funcs bigger (max +9157 insns)

statistics:
---
29  tests (total)
8   test executables have grown (more insns)
18  test executables have shrunk (fewer insns)
10140169insns total (old)
-3334   insns difference
-328insns per 1,000,000
+435weighted insns per 1,000,000 *
3065functions have grown (total) **
+9157   insns in most grown function
 * Each test case is scaled to 100 insns.  The displayed number is the
   average of all tests.

[Bug tree-optimization/79327] wrong code at -O2 and -fprintf-return-value

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
-fdump-tree-printf-return-value2-alias shows
# RANGE [11, 19] NONZERO 31
range for 'e' which is wrong, it should be [5, 19].

[Bug c++/77620] Generic compile time regression of 7.0

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
We get reports like this every few months, and nobody ever uses -ftime-report
before filing a bug. I think something in the -v output would be useful.

[Bug tree-optimization/79327] New: wrong code at -O2 and -ftree-printf-return

[mpolacek at gcc dot gnu.org]

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

Bug ID: 79327
   Summary: wrong code at -O2 and -ftree-printf-return
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The following aborts with -O2:

volatile int a, b = -1;
char buf[64];

int
main ()
{
  int c = a;
  int d = b;
  if (c >= -35791395 && c < 35791394 && d >= -1 && d < __INT_MAX__)
{
  int e = __builtin_sprintf (buf, "%+03d%02d", c + 1, d + 1);
  if (e > 7)
__builtin_abort ();
}
  return 0;
}

-fno-printf-return-value helps.

[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string

[redi at gcc dot gnu.org]

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

--- Comment #25 from Jonathan Wakely  ---
I have, and it doesn't make much difference:

175800  gcc48.so
608280  gcc49.so
   1159624  gcc5-cow.so
   1176296  gcc6-cow-gc.so
   1176296  gcc6-cow.so
   1180400  gcc6-gc.so
   1180400  gcc6.so
258376  gcc7-cow-patched.so
   1188568  gcc7-cow-trunk.so
258384  gcc7-patched.so
   1188552  gcc7-trunk.so

-cow means using -D_GLIBCXX_CXX11_ABI=0

-gc means using -Wl,--gc-sections

-patched means I've split the explicit instantiations into separate files and
changed __snprintf_lite to not use __int_to_char from locale-inst.o

The patch makes a big difference.

[Bug c++/79326] New: mistakenly rejects valid C++ code on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 79326
   Summary: mistakenly rejects valid C++ code on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It seems to affect at least all versions 4.6.x and later. 

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170201 (experimental) [trunk revision 245083] (GCC) 
$ 
$ clang++ -c small.cpp
$ icc -c small.cpp
$ 
$ g++-trunk -c small.cpp
small.cpp:2:24: error: type of ‘foo’ is unknown
 __typeof__ (foo < int >) bar;
^
$ 





template < typename T > T foo (T); 
__typeof__ (foo < int >) bar;

[Bug c++/79325] ICE on valid GNU C++ code (typeof) on x86_64-linux-gnu: in arg_assoc_type, at cp/name-lookup.c:5823

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE on valid C++ code on|ICE on valid GNU C++ code
   |x86_64-linux-gnu: in|(typeof) on
   |arg_assoc_type, at  |x86_64-linux-gnu: in
   |cp/name-lookup.c:5823   |arg_assoc_type, at
   ||cp/name-lookup.c:5823

--- Comment #1 from Andrew Pinski  ---
Does it work if you use decltype instead of typeof?

[Bug c++/79325] New: ICE on valid C++ code on x86_64-linux-gnu: in arg_assoc_type, at cp/name-lookup.c:5823

[su at cs dot ucdavis.edu]

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

Bug ID: 79325
   Summary: ICE on valid C++ code on x86_64-linux-gnu: in
arg_assoc_type, at cp/name-lookup.c:5823
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It seems to affect 4.8.x and later, but not 4.7.x. 

It might be related to PR 71820. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170201 (experimental) [trunk revision 245079] (GCC)
$
$ g++-4.7 -c small.cpp
$ clang++ -c small.cpp
$
$ g++-trunk -c small.cpp
small.cpp:3:27: internal compiler error: in arg_assoc_type, at
cp/name-lookup.c:5823
 __typeof__ (f (foo < int >)) bar;
   ^
0x89be72 arg_assoc_type
../../gcc-source-trunk/gcc/cp/name-lookup.c:5823
0x89be06 arg_assoc_args
../../gcc-source-trunk/gcc/cp/name-lookup.c:5834
0x89be06 arg_assoc_type
../../gcc-source-trunk/gcc/cp/name-lookup.c:5806
0x89b66d arg_assoc
../../gcc-source-trunk/gcc/cp/name-lookup.c:5905
0x89b838 arg_assoc
../../gcc-source-trunk/gcc/cp/name-lookup.c:5893
0x89e931 arg_assoc_args_vec
../../gcc-source-trunk/gcc/cp/name-lookup.c:5849
0x89e931 lookup_arg_dependent_1
../../gcc-source-trunk/gcc/cp/name-lookup.c:5954
0x89e931 lookup_arg_dependent(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>*)
../../gcc-source-trunk/gcc/cp/name-lookup.c:5982
0x838e24 perform_koenig_lookup(cp_expr, vec<tree_node*, va_gc, vl_embed>*, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2252
0x7b3e95 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6916
0x7ae4bc cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8098
0x7bb717 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8775
0x7bbd25 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8877
0x7bc610 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9165
0x7bf0d9 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9332
0x7b17d9 cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:4923
0x7b323e cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6779
0x7ae4bc cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8098
0x7aed6c cp_parser_sizeof_operand
../../gcc-source-trunk/gcc/cp/parser.c:27439
0x7af219 cp_parser_simple_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16707
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


--


int f (void (*) (int, int));
template < typename T > void foo (T t, __typeof__ (t));
__typeof__ (f (foo < int >)) bar;

[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
Have you tried linking with -Wl,--gc-sections ?

[Bug libquadmath/79317] logq is returning double precision results

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Not a bug then.

[Bug c++/79318] conversion member function preceded with & is not marked as error

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
This seems to be http://wg21.link/cwg1726

[Bug testsuite/79324] The tests introduced at revision r245052 fail on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb  1 15:47:52 2017
New Revision: 245097

URL: https://gcc.gnu.org/viewcvs?rev=245097=gcc=rev
Log:
PR testsuite/79324
* gcc.dg/debug/dwarf2/align-1.c: Add -gno-strict-dwarf to dg-options.
* gcc.dg/debug/dwarf2/align-2.c: Likewise.
* gcc.dg/debug/dwarf2/align-3.c: Likewise.
* gcc.dg/debug/dwarf2/align-4.c: Likewise.
* gcc.dg/debug/dwarf2/align-5.c: Likewise.
* gcc.dg/debug/dwarf2/align-6.c: Likewise.
* gcc.dg/debug/dwarf2/align-as-1.c: Likewise.
* g++.dg/debug/dwarf2/align-1.C: Likewise.
* g++.dg/debug/dwarf2/align-2.C: Likewise.
* g++.dg/debug/dwarf2/align-3.C: Likewise.
* g++.dg/debug/dwarf2/align-4.C: Likewise.
* g++.dg/debug/dwarf2/align-5.C: Likewise.
* g++.dg/debug/dwarf2/align-6.C: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-1.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-2.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-3.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-4.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-5.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-6.C
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-1.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-2.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-3.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-4.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-5.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-6.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-as-1.c

[Bug fortran/79313] associate statement inside openmp loop breaks OMP intrinisics

[mlevy at ucar dot edu]

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

--- Comment #5 from Michael Levy  ---
(In reply to Steve Kargl from comment #3)
> On Wed, Feb 01, 2017 at 04:37:52AM +, kargl at gcc dot gnu.org wrote:
> A 3rd alternative is change your declaration in the subroutine to
> 
> integer, external :: omp_get_thread_num, omp_get_num_threads

I have verified that this works, thank you! (I'm a little confused about how
the associate statement highlighted the need for this attribute in the
declaration but that's okay.)

[Bug c++/77620] Generic compile time regression of 7.0

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
We already output one if you use -ftime-report.

[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Andrew Pinski from comment #6)
> I ran with =31 on aarch64 and ref was working. Maybe it is only test input
> is a problem.

I can confirm that, ref.pl is fine. It doesn't call fork (breakpoint at fork is
never triggered).

[Bug c++/77620] Generic compile time regression of 7.0

[petschy at gmail dot com]

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

--- Comment #6 from petschy at gmail dot com ---
Would it be sensible to put an extra line to the output of 'gcc/g++ -v' if the
slow checks are enabled, which just states this fact / warns about (possibly
mentioning the use of --enable-checking=release at configure)? Future tickets
like this might be avoided this way.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
I agree with the comments that this (if at all) needs to be fixed at RTL
expansion time where we already do quite some "hacks" for sizetype
in POINTER_PLUS_EXPR context:

case POINTER_PLUS_EXPR:
  /* Even though the sizetype mode and the pointer's mode can be different
 expand is able to handle this correctly and get the correct result out
 of the PLUS_EXPR code.  */
  /* Make sure to sign-extend the sizetype offset in a POINTER_PLUS_EXPR
 if sizetype precision is smaller than pointer precision.  */
  if (TYPE_PRECISION (sizetype) < TYPE_PRECISION (type))
treeop1 = fold_convert_loc (loc, type,
fold_convert_loc (loc, ssizetype,
  treeop1));
  /* If sizetype precision is larger than pointer precision, truncate the
 offset to have matching modes.  */

but I don't see from the comments in this bug what the actual stmt is the
critical one.

[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
I ran with =31 on aarch64 and ref was working. Maybe it is only test input is a
problem.

[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
It's about a fork being called after a loop, where one threadsleaves
gomp_simple_barrier_wait (>threads_dock) and runs the folk. Other threads
have't cross the wait barrier.

Jakub?

[Bug fortran/78958] FAIL: gfortran.dg/alloc_comp_class_5.f03 - Segmentation fault

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Created attachment 40620 [details]
> Preliminary patch

> The attached patch fixes the issue at least on x86_64-linux and the sanitizer
> does not report any further issues. Please test.

Confirmed on darwin. The patch also fixes the failures for
allocate_with_source_8.f08 reported in PR78672.

[Bug testsuite/79324] New: The tests introduced at revision r245052 fail on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 79324
   Summary: The tests introduced at revision r245052 fail on
darwin
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: aoliva at gcc dot gnu.org, iains at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

The tests introduced at revision r245052 fail on darwin

FAIL: gcc.dg/debug/dwarf2/align-1.c scan-assembler-times  DW_AT_alignment 1
FAIL: gcc.dg/debug/dwarf2/align-2.c scan-assembler-times  DW_AT_alignment 1
FAIL: gcc.dg/debug/dwarf2/align-3.c scan-assembler-times  DW_AT_alignment 1
FAIL: gcc.dg/debug/dwarf2/align-4.c scan-assembler-times  DW_AT_alignment 2
FAIL: gcc.dg/debug/dwarf2/align-5.c scan-assembler-times  DW_AT_alignment 1
FAIL: gcc.dg/debug/dwarf2/align-6.c scan-assembler-times  DW_AT_alignment 1
FAIL: gcc.dg/debug/dwarf2/align-as-1.c scan-assembler-times  DW_AT_alignment 1

FAIL: g++.dg/debug/dwarf2/align-1.C  -std=gnu++11  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-1.C  -std=gnu++14  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-1.C  -std=gnu++98  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-2.C  -std=gnu++11  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-2.C  -std=gnu++14  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-2.C  -std=gnu++98  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-3.C  -std=gnu++11  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-3.C  -std=gnu++14  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-3.C  -std=gnu++98  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-4.C  -std=gnu++11  scan-assembler-times 
DW_AT_alignment 2
FAIL: g++.dg/debug/dwarf2/align-4.C  -std=gnu++14  scan-assembler-times 
DW_AT_alignment 2
FAIL: g++.dg/debug/dwarf2/align-4.C  -std=gnu++98  scan-assembler-times 
DW_AT_alignment 2
FAIL: g++.dg/debug/dwarf2/align-5.C  -std=gnu++11  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-5.C  -std=gnu++14  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-5.C  -std=gnu++98  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-6.C  -std=gnu++11  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-6.C  -std=gnu++14  scan-assembler-times 
DW_AT_alignment 1
FAIL: g++.dg/debug/dwarf2/align-6.C  -std=gnu++98  scan-assembler-times 
DW_AT_alignment 1

[Bug c++/49974] missing warning for indirectly returning reference to local/temporary

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
We currently warn on all the examples involving X, with -O2. We don't for Y, we
might if there was a caller and the dangling reference was used there...

[Bug c++/79307] g++ misses warning for reference on temporary that invokes undefined behaviour

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Oops, yes thank you!

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

[Bug c++/49974] missing warning for indirectly returning reference to local/temporary

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||steven.spark at gmail dot com

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

[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 1 Feb 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution|--- |FIXED
> 
> --- Comment #3 from Martin Liška  ---
> May I close it as invalid?

Well, why did we parallelize a loop with a fork() call?

[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
May I close it as invalid?

[Bug c++/79300] Wrong diagnostics position

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Confirmed.  I'm looking into this.

[Bug c++/79307] g++ misses warning for reference on temporary that invokes undefined behaviour

[steven.spark at gmail dot com]

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

--- Comment #4 from Szikra  ---
> This is bug 44974.
> 
> > Possible duplicate of bug #44859 or bug #51270.
> 
> Looks more like bug 49974 to me.
> 
> *** This bug has been marked as a duplicate of bug 44974 ***

Hi you are right, my first example is the same as in bug 49974:

struct Y {
Y(int& i) : r(i) { }
int& r;
};

If that were fixed, it would probably solve both problem.
Though my second case might be easier to detect, or it's more obviously wrong
:)

struct TestRefIntDirect {
TestRefIntDirect(int a) : a_(a) {};
const int& a_;
};
This is wrong by in itself, in this case temporary is always created and in the
same place where it is used.

But I have a problem:
Shouldn't this be marked as duplicate of bug 49974 and not bug 44974? :)

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Is affected just the arm-none-eabi target, or are any others?

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #9 from John Paul Adrian Glaubitz  ---
Comment on attachment 40645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40645
Proposed fix

Yes, this is the correct fix for gcc-6.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[jrtc27 at jrtc27 dot com]

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

--- Comment #8 from James Clarke  ---
Created attachment 40645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40645=edit
Proposed fix

I believe this patch is what Adrian did; Adrian, can you please confirm?

[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Martin Liška  ---
Fixed.

[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Wed Feb  1 14:04:38 2017
New Revision: 245095

URL: https://gcc.gnu.org/viewcvs?rev=245095=gcc=rev
Log:
Add dg-require-alias to a ICF test (PR testsuite/79272).

2017-02-01  Martin Liska  

PR testsuite/79272
* gcc.dg/ipa/pr77653.c: Add dg-require-alias to the test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/pr77653.c

[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
And running with OMP_NUM_LIMIT=1 works fine.

[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-01
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Well, it's not GCC 7 regression, problem is that we generate a GOMP_parallel.
After it's done, the main thread is going to do fork/exec:

#0  __libc_fork () at ../sysdeps/nptl/fork.c:49
#1  0x004ef765 in Perl_my_fork () at util.c:2303
#2  0x004915f6 in Perl_pp_fork () at pp_sys.c:4009
#3  0x004acccd in Perl_runops_standard () at run.c:37
#4  0x00445f28 in S_run_body (oldscope=1) at perl.c:2017
#5  perl_run (my_perl=) at perl.c:1934
#6  0x004034a2 in main (argc=4, argv=0x7fffdb88, env=) at perlmain.c:98
(gdb) info threads
  Id   Target Id Frame 
* 1Thread 0x77fae780 (LWP 3579) "perlbench_base." __libc_fork () at
../sysdeps/nptl/fork.c:49
  2Thread 0x770e6700 (LWP 3583) "perlbench_base." do_spin (val=8,
addr=0x77e044) at ../../../libgomp/config/linux/wait.h:56
  3Thread 0x768e5700 (LWP 3584) "perlbench_base." futex_wait (val=8,
addr=0x77e044) at ../../../libgomp/config/linux/x86/futex.h:44
  4Thread 0x760e4700 (LWP 3585) "perlbench_base." futex_wait (val=8,
addr=0x77e044) at ../../../libgomp/config/linux/x86/futex.h:44

and that's why the other threads will not reach the barrier.

[Bug c/79320] sqrt of negative number do not return NaN with i686-w64-mingw32-gcc on pentiumI7/Windows10

[daniel.weil at argosim dot com]

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

--- Comment #2 from Daniel WEIL  ---
OK. I log the issue on mingw bugs : https://sourceforge.net/p/mingw/bugs/2337/

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
It sounds like you have a patch for GCC 6.  If you send it in I can apply it.

The error you show must be from `make -j`, as compiling a file in libgfortran
would not invoke go1.  What is the actual failure?

[Bug libquadmath/79317] logq is returning double precision results

[ggoeckel at presby dot edu]

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

--- Comment #1 from ggoeckel at presby dot edu ---
My error. Sorry. Double precision entered with this assignment.

lntwo=6.9314718055994530941723212145817446e-01

[Bug c/12245] [5/6/7 regression] Uses lots of memory when compiling large initialized arrays

[rguenth at gcc dot gnu.org]

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

--- Comment #63 from Richard Biener  ---
Sth that could pay off with other testcases (nested CONSTRUCTORs) is to
truncate the size of the CONSTRUCTOR_ELTS vec<> to the exact final size after
parsing it
as it will never grow again and we over-allocate during safe-pushing to it.

vec:: has no suitable function to do that (yet) though.

It won't help this particular testcase of course.

[Bug c/12245] [5/6/7 regression] Uses lots of memory when compiling large initialized arrays

[rguenth at gcc dot gnu.org]

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

--- Comment #62 from Richard Biener  ---
Main issue is still for GCC:

Kind   Nodes  Bytes

constants1630852   39140573

integer_cst  1630844


c/c-typeck.c:9020 (output_init_element)   0:  0.0%  33554552:
50.0%  33554440: 31.2%   152:  0.2%20

and for G++:

Kind   Nodes  Bytes

constants1630864   39140861

integer_cst  1630856


cp/constexpr.c:4814 (maybe_constant_value) 67108816:100.0% 100663104   
17:  0.0%   ggc

(huh!)

cp/parser.c:21811 (cp_parser_initializer_list) 33554440: 99.8%  33554552: 
8.3% 0:  0.0%   152:  0.1%20


that maybe_constant_value can be improved to

cp/constexpr.c:4817 (maybe_constant_value) 2032: 13.6%  2144   
 2:  0.0%   ggc

with a simple patch.

[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Liška  ---
(In reply to ktkachov from comment #11)
> (In reply to Martin Liška from comment #10)
> > Can't reproduce any of both tests on both x86_64-linux-gnu and aarach64. Is
> > it still valid?
> 
> I can reproduce the ICE on the original testcase on GCC 6 but not trunk.
> I can't reproduce the ICE in the second testcase anywhere

Ok, thanks. It really disappeared on trunk with the Richi's patch that does
reorganization in pass manager. Anyhow, as I debugged that on GCC6 branch, it's
dup of PR71351. Which still has a reproducible test-case.

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

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[marxin at gcc dot gnu.org]

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

Bug 71142 Summary: [6/7 Regression] ICE: Segmentation fault in ssa_default_def 
(graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142

   What|Removed |Added

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