[Bug c/86067] New: [MIPS] ICE: scal-to-vec1.c:86:1: error: unrecognizable insn with -march=loongson3a

[paul.hua.gm at gmail dot com]

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

Bug ID: 86067
   Summary: [MIPS] ICE: scal-to-vec1.c:86:1: error: unrecognizable
insn with -march=loongson3a
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.hua.gm at gmail dot com
  Target Milestone: ---

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

/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c:
In function ‘main’:
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c:86:1:
error: unrecognizable insn:
(insn 69 68 70 2 (set (reg:V4HI 541)
(unspec:V4HI [
(reg:SI 543)
(subreg/s/u:HI (reg:DI 195 [ _2 ]) 0)
(const_int 0 [0])
] UNSPEC_LOONGSON_PINSRH))
"/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c":45
-1
 (nil))
during RTL pass: vregs
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c:86:1:
internal compiler error: in extract_insn, at recog.c:2304
0x12012a6c7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc_git_trunk/gcc/rtl-error.c:108
0x12012a707 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
../../../gcc_git_trunk/gcc/rtl-error.c:116
0x12078f54f extract_insn(rtx_insn*)
../../../gcc_git_trunk/gcc/recog.c:2304
0x1204b9787 instantiate_virtual_regs_in_insn
../../../gcc_git_trunk/gcc/function.c:1600
0x1204b9787 instantiate_virtual_regs
../../../gcc_git_trunk/gcc/function.c:1970
0x1204b9787 execute
../../../gcc_git_trunk/gcc/function.c:2019
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


cmd:
cc1 -fpreprocessed scal-to-vec1.i -mel -quiet -dumpbase scal-to-vec1.c
-march=loongson3a -mabi=64 -mllsc -mips64r2 -mno-shared -auxbase scal-to-vec1
-O1 -w -version -fdiagnostics-color=never -fno-diagnostics-show-caret -o
scal-to-vec1.s

[Bug c/86053] Builtin fwrite arguments have non_null attribute and builtin function declaration not overloaded

[olivier at wuillemin dot fr]

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

--- Comment #2 from olivier at wuillemin dot fr ---
Resolved ? I find your answer a little bit short.

Concerning the nonnull attribute, in glibc manual i didn't find any requirement
 concerning pointer arguments neither in glibc doc :

size_t fwrite(const void *data, size_t size, size_t count, FILE *stream)
Preliminary: | MT-Safe | AS-Unsafe  corrupt | AC-Unsafe  lock  corrupt | See
Section 1.2.2.1 [POSIX Safety Concepts], page 2.

This  function  writes  up  to count objects of  size size from  the  array
data,  to  the stream stream.  The return value is normally count, if the call
succeeds. Any other value indicates some sort of error, such as running out of
space.

Neither in glibc's stdio.h source :

/* Write chunks of generic data to STREAM.
   This function is a possible cancellation point and therefore not
   marked with __THROW.  */
extern size_t fwrite (const void *__restrict __ptr, size_t __size,
size_t __n, FILE *__restrict __s);

For information VS studio indicates that function generate a runtime parameter
error in case of null pointer.

And if non null pointers are mandatorty for fwrite why they are not mandatory
for fread ?

Also, this doesn't explain why local declaration of a function is overloaded
with built-in declaration.

[Bug c++/85710] [8/9 Regression] Enabling memset-elt-size warning causes ICE on memset of template member array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/86068] New: __cpp_transactional_memory is 210500

[rv at rasmusvillemoes dot dk]

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

Bug ID: 86068
   Summary: __cpp_transactional_memory is 210500
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rv at rasmusvillemoes dot dk
  Target Milestone: ---

The comment above the definition of __cpp_transactional_memory suggests that
201500 was meant to be used. Currently, gcc advertises support for whatever
transactional_memory features get standardized the next 86 years...

It probably can't be corrected to 201500 if there's existing code that does the
__cpp_transactional_memory >= 201505 check, but OTOH setting it to 201505 isn't
ideal either.

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Sorry for the breakage, patch candidate sent here:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00285.html

[Bug tree-optimization/86042] [8/9 Regression] missing strlen optimization after second strcpy

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 5 Jun 2018, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86042
> 
> --- Comment #3 from Martin Sebor  ---
> The strcpy() calls are first transformed into
> 
>   MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})"12"];
> 
> In GCC 7, the above is then transformed into
> 
>   MEM[(char * {ref-all})&a] = "12";
> 
> (I'm not sure what the difference is).

"12" is considered a constant while MEM[(char * {ref-all})"12"]
is considered a read from the constant pool.

It's not simplified to that because GCC 8 uses 'unsigned char[]'
as access type while GCC 7 used char[] and those are not compatible.

I suspect if we change

  /* We get an aggregate copy.  Use an unsigned char[] type to
 perform the copying to preserve padding and to avoid any issues
 with TREE_ADDRESSABLE types or float modes behavior on copying.  
*/
  desttype = build_array_type_nelts (unsigned_char_type_node,
 tree_to_uhwi (len));

in gimple_fold_builtin_memory_op to use char_type_node then we'll
get back GCC 7 behavior for this case.  (I chose unsigned char type
to not change IL based on -f[un]signed-char)

I suspect that with -funsigned-char the testcase already works with GCC8?

"  In GCC 7, the second instance of the
> above is then removed in fre1.

By means of redundant store removal which ATM only handles stores from
constants and registers but not aggregate copies.

> In GCC 8, the second instance makes it all the way to the strlen pass where
> handle_char_store() isn't prepared to deal with it if a length record exists
> for the destination.  I think the strlen() limitation can be handled by the
> same solution as bug 86043: i.e., have handle_char_store() handle cases where
> substrings of any length is overwritten without changing their length, not 
> just
> those of length one by plain character assignment.

Yes, that's a good enhancement independent of this bug.

> I don't know why the duplicate MEM assignment above isn't eliminated earlier
> (that may be a separate bug).

See above - redundant store removal doesn't handle aggregate copies.

[Bug target/86027] string literals get corrupted with -O3 and gas on solaris i386

[subscribe at teskor dot de]

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

--- Comment #4 from Michael Teske  ---
I found the fix for my problem:

+ 2018-02-05  Rainer Orth  
+
+   Backport from mainline
+   2018-01-30  Rainer Orth  
+
+   PR bootstrap/84017
+   * configure.ac (gcc_cv_as_shf_merge): Disable on Solaris 10/x86.
+   * configure: Regenerate.

This fixes a different problem which I didn't have with 7.3.0 (bootstrap worked
fine), but I just confirmed, that disabling gcc_cv_as_shf_merge did the trick.
A broken ld explains my problem.

From my side this bug can be closed.

[Bug c++/86063] [6/7/8/9 Regression] g++ ICE at tree check: expected tree_list, have expr_pack_expansion in cp_check_const_attributes, at cp/decl2.c:1391

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Version|unknown |7.3.0
   Target Milestone|--- |6.5

[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/86062] Missed redundancy elimination with struct and array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  The issue is that when trying to translate MEM[(struct I *)&res +
8B]
through the aggregate copy res = MEM[(const struct I &)&D.25143][1]; we run
into

  /* Now re-write REF to be based on the rhs of the assignment.  */
  copy_reference_ops_from_ref (gimple_assign_rhs1 (def_stmt), &rhs);

  /* Apply an extra offset to the inner MEM_REF of the RHS.  */
  if (maybe_ne (extra_off, 0))
{
  if (rhs.length () < 2
  || rhs[0].opcode != MEM_REF
  || known_eq (rhs[0].off, -1))
return (void *)-1;

where the rhs ref is an ARRAY_REF of a MEM_REF.  This is a TBAA issue
IIRC (at least when the translated ref would end up in PRE insertion
somehow - PRE doesn't run into this code though).

The following untested fixes it but as said I'm not 100% sure it's safe.

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 4e946ba7baf..4aec41e96c1 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -2270,14 +2270,16 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*vr_,
   /* Apply an extra offset to the inner MEM_REF of the RHS.  */
   if (maybe_ne (extra_off, 0))
{
- if (rhs.length () < 2
- || rhs[0].opcode != MEM_REF
- || known_eq (rhs[0].off, -1))
+ if (rhs.length () < 2)
return (void *)-1;
- rhs[0].off += extra_off;
- rhs[0].op0 = int_const_binop (PLUS_EXPR, rhs[0].op0,
-   build_int_cst (TREE_TYPE (rhs[0].op0),
-  extra_off));
+ int ix = rhs.length () - 2;
+ if (rhs[ix].opcode != MEM_REF
+ || known_eq (rhs[ix].off, -1))
+   return (void *)-1;
+ rhs[ix].off += extra_off;
+ rhs[ix].op0 = int_const_binop (PLUS_EXPR, rhs[ix].op0,
+build_int_cst (TREE_TYPE
(rhs[ix].op0),
+   extra_off));
}

   /* We need to pre-pend vr->operands[0..i] to rhs.  */

[Bug c++/86060] [6/7/8/9 Regression] g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2
Version|unknown |7.3.0
   Target Milestone|--- |6.5

[Bug tree-optimization/86062] Missed redundancy elimination with struct and array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c/86058] TARGET_MEM_REF causing incorrect message for -Wmaybe-uninitialized warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-06
  Component|middle-end  |c
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
"lame" patch (omitting extra operands):

diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index dc76c9957d3..aa05ed00d2f 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -1619,6 +1619,7 @@ c_pretty_printer::postfix_expression (tree e)
   break;

 case MEM_REF:
+case TARGET_MEM_REF:
   expression (e);
   break;

@@ -1759,6 +1760,7 @@ c_pretty_printer::unary_expression (tree e)
   break;

 case MEM_REF:
+case TARGET_MEM_REF:
   if (TREE_CODE (TREE_OPERAND (e, 0)) == ADDR_EXPR
  && integer_zerop (TREE_OPERAND (e, 1)))
expression (TREE_OPERAND (TREE_OPERAND (e, 0), 0));
@@ -2211,6 +2213,7 @@ c_pretty_printer::expression (tree e)
 case ADDR_EXPR:
 case INDIRECT_REF:
 case MEM_REF:
+case TARGET_MEM_REF:
 case NEGATE_EXPR:
 case BIT_NOT_EXPR:
 case TRUTH_NOT_EXPR:

[Bug middle-end/86056] Codegen can result in multiple sequential mfence instructions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-06
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.

[Bug lto/83201] [7/8 Regression] SPEC CPU2017 505.mcf_r produces incorrect output when built with -flto and FDO

[marxin at gcc dot gnu.org]

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

--- Comment #22 from Martin Liška  ---
(In reply to john henning from comment #21)
> Comments from SPEC CPU Documentation Guy:
> 
> As described at 
> https://www.spec.org/cpu2017/Docs/faq.html#Miscompare.07
> https://www.spec.org/cpu2017/Docs/benchmarks/505.mcf_r.html#Portability
> SPEC's recommendation is to use
>-fno-strict-aliasing
> 
> The patch attached to this bug is not approved by SPEC.
> 
> SPEC generally does not change benchmarks after release (no moving targets);
> more detail is at the above links.
> 
>John Henning
>SPEC CPU Subcommittee Secretary

Note that the same function is used by other benchmarks as well: 502.gcc_r,
511.povray_r, 527.cam4_r

That means the same miscompilation can happen for them as well :/

[Bug target/86067] [MIPS] ICE: scal-to-vec1.c:86:1: error: unrecognizable insn with -march=loongson3a

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-06-06
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Which GCC version did you use?

[Bug tree-optimization/86066] [9 Regression] wrong code at -Os and above on x86-64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Version|unknown |9.0
   Keywords||wrong-code
   Last reconfirmed||2018-06-06
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|wrong code at -Os and above |[9 Regression] wrong code
   |on x86-64-linux-gnu |at -Os and above on
   ||x86-64-linux-gnu
   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
Confirmed.  Store-merging again.  Eric?

[Bug rtl-optimization/86064] [8 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-06-06
  Component|c   |rtl-optimization
   Target Milestone|--- |8.2
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
You forgot to attach common.i

[Bug c++/86068] __cpp_transactional_memory is 210500

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-06
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/86064] [8 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[alex_y_xu at yahoo dot ca]

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

--- Comment #2 from alex_y_xu at yahoo dot ca ---
Created attachment 44240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44240&action=edit
common.i.xz

I suspect that when adding a new bug, if the attachment exceeds the file size
limit, it is silently ignored. (or the error message was small enough that I
didn't see it)

anyways, here it is.

[Bug fortran/86006] compile time error generic type bound procedure

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> here is the link:
>
> https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/779807

What do you conclude from the posts?

[Bug rtl-optimization/86064] [8 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction
 Status|WAITING |NEW

--- Comment #3 from Martin Liška  ---
I'm reducing and bisecting..

[Bug rtl-optimization/86064] [8 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #4 from Martin Liška  ---
Reduced test-case:

$ cat pr86064.i
int a;
__attribute__((__cold__)) void b();

void e(int *);
int f();

void c() {
  int d;
  e(&d);
  a = d;
  if (f())
b();
}

[Bug libstdc++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #9 from Josh Marshall  ---
Confirmed in 8.1.1

Also, looking over the following documents:
https://en.cppreference.com/w/cpp/types/ptrdiff_t
https://en.cppreference.com/w/cpp/iterator/iterator
http://en.cppreference.com/w/cpp/iterator/advance
http://en.cppreference.com/w/cpp/iterator/distance
https://en.cppreference.com/w/cpp/concept/Iterator
https://en.cppreference.com/w/cpp/iterator/iterator_traits

All of these do not require difference_type (typename _Distance in glibc) to be
convertible to an integer, and imply implicit conversion from an integer.  From
this reading, I need to change this from an enhancement to a bug.  I also need
to put in a request for a clarification to the standard on this, because it
wasn't very apparent.

Unfortunately, this involves the bigger change to glibc.  Functions like __lg()
will have to be re-written.

[Bug rtl-optimization/86064] [8 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||aoliva at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Started with r257510.

[Bug tree-optimization/86066] [9 Regression] wrong code at -Os and above on x86-64-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
> Confirmed.  Store-merging again.  Eric?

Right, missing handling of BIT_NOT_EXPR for BIT_INSERT_EXPR stores...

[Bug fortran/86051] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3717

[daniel.bershatsky at skolkovotech dot ru]

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

--- Comment #3 from Daniel Bershatsky  ---
(In reply to Dominique d'Humieres from comment #2)
> > This may have been fixed by a patch I submitted today.
> 
> I confirmed that the PR is fixed by the patch at
> 
> https://gcc.gnu.org/ml/fortran/2018-06/msg00013.html

That's great! I will check it out by myself and will be back.

Will this patch be applyed to gfortran branches 6.*, 7.*, and 8.*? If it were
not I would like to get a guidance how to avoid the issue. There are lots of
users who are using these obsolete fortran versions.

[Bug libstdc++/86008] std::quoted(std::basic_string_view) is missing

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Wed Jun  6 11:41:57 2018
New Revision: 261228

URL: https://gcc.gnu.org/viewcvs?rev=261228&root=gcc&view=rev
Log:
PR libstdc++/86008 add std::quoted support for string_view

PR libstdc++/86008
* include/bits/quoted_string.h (_Quoted_string):
Define new partial specialization.
* include/std/iomanip (quoted(basic_string_view, C, C)): Define
new overload.
(operator<<(basic_ostream&, const _Quoted_string&)): Use
value not reference for iteration.
* testsuite/27_io/manipulators/standard/char/quoted.cc: Adjust
comment.
* testsuite/27_io/manipulators/standard/char/quoted_sv.cc: New test.
* testsuite/27_io/manipulators/standard/wchar_t/quoted.cc: Adjust
comment.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/manipulators/standard/char/quoted_sv.cc
  - copied, changed from r261225,
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/manipulators/standard/char/quoted.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/manipulators/standard/wchar_t/quoted_sv.cc
  - copied, changed from r261225,
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/manipulators/standard/wchar_t/quoted.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/quoted_string.h
branches/gcc-8-branch/libstdc++-v3/include/std/iomanip
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/manipulators/standard/char/quoted.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/manipulators/standard/wchar_t/quoted.cc

[Bug debug/86064] [8/9 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|wrong-code  |wrong-debug
   Priority|P3  |P2
  Component|rtl-optimization|debug
Summary|[8 Regression] compiling|[8/9 Regression] compiling
   |Linux kernel: Error: can't  |Linux kernel: Error: can't
   |resolve `.text.unlikely'|resolve `.text.unlikely'
   |{.text.unlikely section} -  |{.text.unlikely section} -
   |`.LVL43x' {.text section}   |`.LVL43x' {.text section}

--- Comment #6 from Richard Biener  ---
Note that -gsplit-dwarf isn't really maintained so you should consider not
using it.

[Bug libstdc++/86008] std::quoted(std::basic_string_view) is missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
I added a new specialization that stores the basic_string_view by value. Fixed
for 8.2

[Bug libstdc++/86015] Better handling of iterator distances

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
cppreference is not the standard. See comment 5, where I quoted the standard
which requires difference_type to be a signed integer type. This is not a bug.

[Bug libstdc++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #11 from Josh Marshall  ---
Then please give me a concrete reference.

[Bug tree-optimization/86062] Missed redundancy elimination with struct and array

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  6 13:03:29 2018
New Revision: 261231

URL: https://gcc.gnu.org/viewcvs?rev=261231&root=gcc&view=rev
Log:
2018-06-06  Richard Biener  

PR tree-optimization/86062
* tree-ssa-sccvn.c (vn_reference_lookup_3): Handle arbitrary
component refs ontop
of to be offsetted base.

* g++.dg/tree-ssa/pr86062.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr86062.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/86062] Missed redundancy elimination with struct and array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed!

[Bug debug/86064] [8/9 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[alex_y_xu at yahoo dot ca]

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

--- Comment #7 from alex_y_xu at yahoo dot ca ---
someone should probably tell Linux to note that in CONFIG_DEBUG_INFO_SPLIT
then.

[Bug tree-optimization/86066] [9 regression] wrong code for bit-field manipulation at -Os

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Jun  6 13:13:24 2018
New Revision: 261232

URL: https://gcc.gnu.org/viewcvs?rev=261232&root=gcc&view=rev
Log:
PR tree-optimization/86066
* gimple-ssa-store-merging.c (process_store): Do not bypass
BIT_NOT_EXPR
for BIT_INSERT_EXPR stores.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr86066.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/86066] [9 regression] wrong code for bit-field manipulation at -Os

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug libstdc++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #12 from Josh Marshall  ---
I can now say why this bothers me from a design perspective.  If the
requirement you are giving is correct, then the distance_type template
parameter must always be signed and always describe the distance between any
two points in memory and therefore must be of the base type ssize_t.  But if it
must always resolve to this one specific type, it doesn't make sense to have it
as a template parameterization. But having the more flexible definition and
usage can start to allow for user applications to do instrumentation and crazy
stuff like grid support through the stdlib one day.  It wouldn't make sense to
add the extra complexity to always use ssize_t, and so it doesn't make sense
that difference_type must be a signed integer only.  It doesn't fit with any
source I've found, it doesn't explain the added complexity in the template, and
it reduces flexibility and generalizability.

[Bug tree-optimization/86062] Missed redundancy elimination with struct and array

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Thanks!

[Bug libstdc++/86015] Better handling of iterator distances

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Josh Marshall from comment #11)
> Then please give me a concrete reference.

C++17 27.2.1 [iterator.requirements.general] paragraph 1.

The same requirement also appears in the C++98, C++03, C++11 and C++14
standards, and in the C++ Extensions for Ranges TS.

[Bug libstdc++/86015] Better handling of iterator distances

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
And signed integer types are defined in C++17 6.7.1 [basic.fundamental].

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
You're jumping through arcane hoops just to provide a property which is not
guaranteed by the function and was never intended to be supported. If you don't
want shrink_to_fit to reallocate then stop calling it.

[Bug libstdc++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #15 from Josh Marshall  ---
That is bizarre.  Then did I stumble upon the vestiges of elements of the
standard which were partially removed prior to 2003?  This may be open for
awhile.  I'll start on a proposal for 2020.  I'll also have to get my hands on
a proper standard.

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
is_trivially_move_constructible is the wrong trait, trivially_copyable is
necessary to determine if memcpy/memmove (and so presumably realloc) are safe.

Does your &n!=&alias##n check still work if operator new is replaced in a
different translation unit, but the default one is the only one in scope in the
current TU?

[Bug target/86069] New: MIPS out-of-range branch expansion can break with -fpic and shrink wrapping

[mpf at gcc dot gnu.org]

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

Bug ID: 86069
   Summary: MIPS out-of-range branch expansion can break with
-fpic and shrink wrapping
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpf at gcc dot gnu.org
  Target Milestone: ---

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

MIPS determines whether a branch is out of range quite late on and replaces an
out of range branch with either a direct or indirect jump. When compiling PIC
code then the only option for a long branch is to perform an indirect jump as
direct jumps are not PC-relative (at least not in the obvious way). The label
to jump to has to be obtained from the GOT as there is no way to calculate a
PC-relative offset directly either. The last-minute expansion of this code has
to grab the GOT pointer from the stack and then load the destination. The
expansion looks like this:

beq $4,$2,.L4

into

bne $4,$2,.L7
.setnoat
lw  $1,16($sp)
lw  $1,%got(.L4)($1)
addiu   $1,$1,%lo(.L4)
jr  $1
.setat
.L7:

With shrink-wrapping it is possible for the compiler to move the prologue (that
sets up the GOT pointer and stashes it on the stack) to be moved after a
potentially out-of-range branch. The branch instructions do not acknowledge the
potential for them to be expanded into a GOT dependent sequence so there is no
way for the shrink-wrap code to do the right thing.

The obvious/simple solution may well be to mark all conditional branches as
using the GOT pointer for PIC code but this will effectively disable shrink
wrapping. To do anything smarter would require handling out-of-range branches
much earlier which is also unlikely to be a good idea.

Test case attached in dejagnu format. It fails at O1 and above. The original
failure was found as part of building LLVM with GCC and has been simplified to
this test case by Simon Dardis.

[Bug target/86069] MIPS out-of-range branch expansion can break with -fpic and shrink wrapping

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 Target||mips-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-06
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||6.3.0, 7.3.0

--- Comment #1 from mpf at gcc dot gnu.org ---
Confirmed as a bug.

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[jan.kratochvil at redhat dot com]

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

--- Comment #11 from Jan Kratochvil  ---
(In reply to Jonathan Wakely from comment #10)
> Does your &n!=&alias##n check still work if operator new is replaced in a
> different translation unit, but the default one is the only one in scope in
> the current TU?

alias##n is expected to be a visibility-hidden symbol of libstdc++ so there
will be no ld.so relocation.
n will be relocated by ld.so as R_X86_64_GLOB_DAT to the real function wherever
it comes from in the final process. It will not point to the PLT slot of
libstdc++.

ISO C++ does not specify the replacement specifics, they say only "displaces
the default version defined by the C ++ standard library".
Here they talk about them:
  http://en.cppreference.com/w/cpp/memory/new/operator_new#Global_replacements

I expect replacing an allocator needs to be done globally for a process as one
may pass allocated objects ownership between program/libraries. That is
typically from the main program or by LD_PRELOAD. Although cppreference talks
about visibility so I guess they think replacing 'operator new' only in one ELF
image (program / shared library) with -fvisibility=hidden is also valid. They
talk about undefined behavior if the replacement is specific only to some TU
which I also find obvious.

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
That page says "a user-provided non-member function with the same signature
defined anywhere in the program, in any source file, replaces the default
version. Its declaration does not need to be visible."

There's no bug here, I don't think this can be done sensibly.

[Bug target/86069] MIPS out-of-range branch expansion can break with -fpic and shrink wrapping

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|9.0 |---

--- Comment #2 from Richard Biener  ---
(In reply to mpf from comment #0)
> The obvious/simple solution may well be to mark all conditional branches as
> using the GOT pointer for PIC code but this will effectively disable shrink
> wrapping. To do anything smarter would require handling out-of-range
> branches much earlier which is also unlikely to be a good idea.

But I think this is the only sensible thing to do.  It will only disable
shrink-wrapping for non-local binding function calls but shrink-wrapping
works in a lot of other cases as well.

Possibly other archs have similar issues with their large code/data models.

[Bug fortran/86051] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3717

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Wed, Jun 06, 2018 at 11:17:42AM +, daniel.bershatsky at skolkovotech dot
ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86051
> 
> --- Comment #3 from Daniel Bershatsky  ru> ---
> (In reply to Dominique d'Humieres from comment #2)
> > > This may have been fixed by a patch I submitted today.
> > 
> > I confirmed that the PR is fixed by the patch at
> > 
> > https://gcc.gnu.org/ml/fortran/2018-06/msg00013.html
> 
> That's great! I will check it out by myself and will be back.
> 
> Will this patch be applyed to gfortran branches 6.*, 7.*, and 8.*? If it were
> not I would like to get a guidance how to avoid the issue. There are lots of
> users who are using these obsolete fortran versions.
> 

It will be back ported. (Well, at least an attempt will be made
to back port the patch, but it should apply with little change).

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[jan.kratochvil at redhat dot com]

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

--- Comment #13 from Jan Kratochvil  ---
Why the example code should not work with "a user-provided non-member function
with the same signature defined anywhere in the program, in any source file,
replaces the default version. Its declaration does not need to be visible."?

I would do the real libstdc++ sources patch as that would comply with these
requirements but I wanted to know first if there are some technical reasons why
it gets rejected, so far I do not see any.

[Bug tree-optimization/85964] [8/9 Regression] compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  6 15:06:50 2018
New Revision: 261237

URL: https://gcc.gnu.org/viewcvs?rev=261237&root=gcc&view=rev
Log:
2018-06-06  Richard Biener  

Backport from mainline
2018-06-04  Richard Biener  

PR tree-optimization/86038
* tracer.c (find_best_successor): Check probability for
being initialized, bail out if not.

* gcc.dg/pr86038.c: New testcase.

2018-05-30  Richard Biener  

PR tree-optimization/85964
* tracer.c (better_p): Drop initialized count check, we only
call the function with initialized counts now.
(find_best_successor): Do find a best edge if one
has uninitialized count.
(find_best_predecessor): Likewise.  Do BB frequency check only
if count is initialized.

2018-05-28  Richard Biener  

PR tree-optimization/85934
* tree-vect-generic.c (expand_vector_operations_1): Hoist
vector boolean check before scalar optimization.

* gcc.target/i386/pr85934.c: New testcase.

2018-05-22  Richard Biener  

PR tree-optimization/85863
* tree-vect-stmts.c (vect_is_simple_cond): Only widen invariant
comparisons when vectype is specified.
(vectorizable_condition): Do not specify vectype for
vect_is_simple_cond when SLP vectorizing.

* gfortran.fortran-torture/compile/pr85863.f: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr86038.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85934.c
   
branches/gcc-8-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr85863.f
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tracer.c
branches/gcc-8-branch/gcc/tree-vect-generic.c
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/85863] [8 Regression] ICE in compiling spec2006 fortran test case solib.fppized.f starting with r260283

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  6 15:06:50 2018
New Revision: 261237

URL: https://gcc.gnu.org/viewcvs?rev=261237&root=gcc&view=rev
Log:
2018-06-06  Richard Biener  

Backport from mainline
2018-06-04  Richard Biener  

PR tree-optimization/86038
* tracer.c (find_best_successor): Check probability for
being initialized, bail out if not.

* gcc.dg/pr86038.c: New testcase.

2018-05-30  Richard Biener  

PR tree-optimization/85964
* tracer.c (better_p): Drop initialized count check, we only
call the function with initialized counts now.
(find_best_successor): Do find a best edge if one
has uninitialized count.
(find_best_predecessor): Likewise.  Do BB frequency check only
if count is initialized.

2018-05-28  Richard Biener  

PR tree-optimization/85934
* tree-vect-generic.c (expand_vector_operations_1): Hoist
vector boolean check before scalar optimization.

* gcc.target/i386/pr85934.c: New testcase.

2018-05-22  Richard Biener  

PR tree-optimization/85863
* tree-vect-stmts.c (vect_is_simple_cond): Only widen invariant
comparisons when vectype is specified.
(vectorizable_condition): Do not specify vectype for
vect_is_simple_cond when SLP vectorizing.

* gfortran.fortran-torture/compile/pr85863.f: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr86038.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85934.c
   
branches/gcc-8-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr85863.f
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tracer.c
branches/gcc-8-branch/gcc/tree-vect-generic.c
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/86038] [9 Regression] ICE in to_reg_br_prob_base, at profile-count.h:242

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  6 15:06:50 2018
New Revision: 261237

URL: https://gcc.gnu.org/viewcvs?rev=261237&root=gcc&view=rev
Log:
2018-06-06  Richard Biener  

Backport from mainline
2018-06-04  Richard Biener  

PR tree-optimization/86038
* tracer.c (find_best_successor): Check probability for
being initialized, bail out if not.

* gcc.dg/pr86038.c: New testcase.

2018-05-30  Richard Biener  

PR tree-optimization/85964
* tracer.c (better_p): Drop initialized count check, we only
call the function with initialized counts now.
(find_best_successor): Do find a best edge if one
has uninitialized count.
(find_best_predecessor): Likewise.  Do BB frequency check only
if count is initialized.

2018-05-28  Richard Biener  

PR tree-optimization/85934
* tree-vect-generic.c (expand_vector_operations_1): Hoist
vector boolean check before scalar optimization.

* gcc.target/i386/pr85934.c: New testcase.

2018-05-22  Richard Biener  

PR tree-optimization/85863
* tree-vect-stmts.c (vect_is_simple_cond): Only widen invariant
comparisons when vectype is specified.
(vectorizable_condition): Do not specify vectype for
vect_is_simple_cond when SLP vectorizing.

* gfortran.fortran-torture/compile/pr85863.f: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr86038.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85934.c
   
branches/gcc-8-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr85863.f
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tracer.c
branches/gcc-8-branch/gcc/tree-vect-generic.c
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/85863] [8 Regression] ICE in compiling spec2006 fortran test case solib.fppized.f starting with r260283

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.1.1
 Resolution|--- |FIXED
  Known to fail||8.1.0

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/85934] [8 Regression] ICE: verify_gimple failed (error: type mismatch in vector pack expression)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.1.1
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug tree-optimization/85934] [8 Regression] ICE: verify_gimple failed (error: type mismatch in vector pack expression)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  6 15:06:50 2018
New Revision: 261237

URL: https://gcc.gnu.org/viewcvs?rev=261237&root=gcc&view=rev
Log:
2018-06-06  Richard Biener  

Backport from mainline
2018-06-04  Richard Biener  

PR tree-optimization/86038
* tracer.c (find_best_successor): Check probability for
being initialized, bail out if not.

* gcc.dg/pr86038.c: New testcase.

2018-05-30  Richard Biener  

PR tree-optimization/85964
* tracer.c (better_p): Drop initialized count check, we only
call the function with initialized counts now.
(find_best_successor): Do find a best edge if one
has uninitialized count.
(find_best_predecessor): Likewise.  Do BB frequency check only
if count is initialized.

2018-05-28  Richard Biener  

PR tree-optimization/85934
* tree-vect-generic.c (expand_vector_operations_1): Hoist
vector boolean check before scalar optimization.

* gcc.target/i386/pr85934.c: New testcase.

2018-05-22  Richard Biener  

PR tree-optimization/85863
* tree-vect-stmts.c (vect_is_simple_cond): Only widen invariant
comparisons when vectype is specified.
(vectorizable_condition): Do not specify vectype for
vect_is_simple_cond when SLP vectorizing.

* gfortran.fortran-torture/compile/pr85863.f: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr86038.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85934.c
   
branches/gcc-8-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr85863.f
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tracer.c
branches/gcc-8-branch/gcc/tree-vect-generic.c
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug c++/85710] [8/9 Regression] Enabling memset-elt-size warning causes ICE on memset of template member array

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Jun  6 15:14:12 2018
New Revision: 261238

URL: https://gcc.gnu.org/viewcvs?rev=261238&root=gcc&view=rev
Log:
PR c++/85710 - ICE with -Wmemset-elt-size.
c-family/
* c-warn.c (warn_for_memset): Don't crash on incomplete element type.
cp/
* semantics.c (finish_call_expr): Call warn_for_memset here.
* parser.c (cp_parser_postfix_expression): Not here.
(literal_integer_zerop): No longer static.
* pt.c (build_non_dependent_expr): Don't wrap CONST_DECL.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wmemset-elt-size1.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c

[Bug libfortran/86070] New: [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

[seurer at gcc dot gnu.org]

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

Bug ID: 86070
   Summary: [7 regression] gfortran.dg/fmt_zero_digits.f90
segmentation fault starting with r261077
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-7/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-7/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/fmt_zero_digits.f90
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -pedantic-errors
-B/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-lm -o ./fmt_zero_digits.exe
PASS: gfortran.dg/fmt_zero_digits.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-7/gcc:.:/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-7/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-7/gcc:/home/seurer/gcc/build/gcc-7/./gmp/.libs:/home/seurer/gcc/build/gcc-7/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-7/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-7/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-7/./mpc/src/.libs:/home/seurer/gcc/build/gcc-7/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-7/./isl/.libs:/home/seurer/gcc/build/gcc-7/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
FAIL: gfortran.dg/fmt_zero_digits.f90   -O0  execution test


Program received signal SIGSEGV, Segmentation fault.
__memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:115
115 ../sysdeps/powerpc/powerpc64/power7/memcpy.S: No such file or
directory.
(gdb) where
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:115
#1  0x3fffb7f3ce64 in write_float_string (dtp=0x3fffee48,
fstr=0x3fffe720 ' ' , "8.D+00", len=70367532635856) at
/home/seurer/gcc/gcc-7/libgfortran/io/write.c:1577
#2  0x3fffb7f41654 in write_float_0 (dtp=0x3fffee48, f=0x10021aa0,
source=0x100012d8 "", kind=) at
/home/seurer/gcc/gcc-7/libgfortran/io/write.c:1599
#3  0x3fffb7f36480 in formatted_transfer_scalar_write (dtp=0x3fffee48,
type=BT_REAL, p=0x100012d8, kind=4, size=4) at
/home/seurer/gcc/gcc-7/libgfortran/io/transfer.c:2017
#4  0x3fffb7f36bcc in formatted_transfer (dtp=0x3fffee48,
type=, p=, kind=, size=4,
nelems=1)
at /home/seurer/gcc/gcc-7/libgfortran/io/transfer.c:2279
#5  0x3fffb7f32d00 in _gfortran_transfer_real (dtp=0x3fffee48,
p=0x100012d8, kind=) at
/home/seurer/gcc/gcc-7/libgfortran/io/transfer.c:2310
#6  0x3fffb7f32d48 in _gfortran_transfer_real_write (dtp=,
p=, kind=) at
/home/seurer/gcc/gcc-7/libgfortran/io/transfer.c:2316
#7  0x1b70 in test () at
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/fmt_zero_digits.f90:15
#8  0x1060 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

[Bug c++/86060] [6/7/8/9 Regression] g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/86071] New: -O0 -foptimize-sibling-calls doesn't optimize

[Hi-Angel at yandex dot ru]

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

Bug ID: 86071
   Summary: -O0 -foptimize-sibling-calls doesn't optimize
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hi-Angel at yandex dot ru
  Target Milestone: ---

# Steps to reproduce:

$ cat test.cpp   
struct Node {
Node* children;
};

const Node& descend(const Node& node) {
if (!node.children) {
return node;
} else // not a leaf
return descend(*node.children);
}

int main() {
Node end;
Node ring = Node{new Node{&end}};
end.children = ˚
descend(ring);
}
$ g++ test.cpp -o a -O0 -g3 -foptimize-sibling-calls
$ ./a
[1]21291 segmentation fault (core dumped)  ./a

Running under gdb shows that crash is because of exhausted stack, i.e.
tail-recursion optimization didn't work.


# Additional information

This one testcase actually does work upon replacing -O0 with -O3.

However, I also have a bit bigger testcase, where tail-recursion optimization
doesn't work even with -O3. I wonder, if it's worth a separate bug.

[Bug tree-optimization/86071] -O0 -foptimize-sibling-calls doesn't optimize

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #1 from Alexander Monakov  ---
In GCC there's no way to selectively enable a few optimizations with their -f
flags at -O0 level: -O0 means that optimizations are completely disabled,
regardless of -f flags. This is mentioned in the manual:

  "Most optimizations are only enabled if an -O level is set on the command
line.  Otherwise they are disabled, even if individual optimization flags are
specified."


Tail call optimization sometimes is not applied because there's an escaping
local variable (possibly from an inlined function), and GCC does not take into
account its life range. This might be what you're seeing at -O3. There's a
recent report: PR 86050.

[Bug c++/86072] New: Poor codegen with atomics

[redbeard0531 at gmail dot com]

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

Bug ID: 86072
   Summary: Poor codegen with atomics
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

https://godbolt.org/g/aEFhq8

#include 

std::atomic progress{-1};

void combine_writes1() {
// These should be reduced to a single store(0,release),
// At least as long as release-sequnce includes same-thread
// relaxed stores. If that is removed, this should just be
// a single relaxed store.
progress.store(0, std::memory_order_relaxed);
progress.store(0, std::memory_order_relaxed);
progress.store(0, std::memory_order_release);
progress.store(0, std::memory_order_release);
progress.store(0, std::memory_order_relaxed);
progress.store(0, std::memory_order_relaxed);
}

void combine_writes2() {
// Ditto above, but should store 5.
progress.store(0, std::memory_order_relaxed);
progress.store(1, std::memory_order_relaxed);
progress.store(2, std::memory_order_release);
progress.store(3, std::memory_order_release);
progress.store(4, std::memory_order_relaxed);
progress.store(5, std::memory_order_relaxed);
}

void combine_loads() {
// These should be reduced to either a single acquire-load
// or an acquire fence. 
progress.load(std::memory_order_relaxed);
progress.load(std::memory_order_relaxed);
progress.load(std::memory_order_acquire);
progress.load(std::memory_order_acquire);
progress.load(std::memory_order_relaxed);
progress.load(std::memory_order_relaxed);
}

combine_writes1():
  xor eax, eax
  mov DWORD PTR progress[rip], eax
  mov DWORD PTR progress[rip], eax
  mov DWORD PTR progress[rip], eax
  mov DWORD PTR progress[rip], eax
  mov DWORD PTR progress[rip], eax
  mov DWORD PTR progress[rip], eax
  ret
combine_writes2():
  mov DWORD PTR progress[rip], 0
  mov DWORD PTR progress[rip], 1
  mov DWORD PTR progress[rip], 2
  mov DWORD PTR progress[rip], 3
  mov DWORD PTR progress[rip], 4
  mov DWORD PTR progress[rip], 5
  ret
combine_loads():
  mov eax, DWORD PTR progress[rip]
  mov eax, DWORD PTR progress[rip]
  mov eax, DWORD PTR progress[rip]
  mov eax, DWORD PTR progress[rip]
  mov eax, DWORD PTR progress[rip]
  mov eax, DWORD PTR progress[rip]
  ret
progress:
  .long -1

This example seems to ICE segfaulting gcc trunk: https://godbolt.org/g/M4ZQGS


Possibly related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86056

[Bug tree-optimization/86072] Poor codegen with atomics

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c++ |tree-optimization

--- Comment #1 from Andrew Pinski  ---
We don't optimize the atomics at all.

[Bug tree-optimization/86072] Poor codegen with atomics

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/86060] [6/7/8/9 Regression] g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Jun  6 17:47:48 2018
New Revision: 261239

URL: https://gcc.gnu.org/viewcvs?rev=261239&root=gcc&view=rev
Log:
PR c++/86060 - ICE on range for with -std=c++98.

* parser.c (cp_parser_init_statement): Don't clobber *decl after
pedwarn.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for35.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/86060] [6/7/8/9 Regression] g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Jun  6 17:48:35 2018
New Revision: 261240

URL: https://gcc.gnu.org/viewcvs?rev=261240&root=gcc&view=rev
Log:
PR c++/86060 - ICE on range for with -std=c++98.

* parser.c (cp_parser_init_statement): Don't clobber *decl after
pedwarn.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/range-for35.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/parser.c

[Bug c++/85977] Incorrect handling of array reference size deduction

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Should work now.

[Bug c++/85977] Incorrect handling of array reference size deduction

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jun  6 17:51:19 2018
New Revision: 261241

URL: https://gcc.gnu.org/viewcvs?rev=261241&root=gcc&view=rev
Log:
PR c++/85977
* pt.c (unify): If ELTTYPE has no deducible template parms, skip
deduction from the list elements.
(type_unification_real): Check convertibility of list elements.

* g++.dg/cpp0x/initlist102.C: New test.
* g++.dg/cpp0x/initlist103.C: New test.
* g++.dg/cpp0x/initlist104.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist102.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist103.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist104.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/86065] gfortran NAMELIST improperly reads arrays that span more than one line.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||6.4.1, 7.3.1, 8.1.1, 9.0
 Resolution|--- |WORKSFORME

--- Comment #3 from kargl at gcc dot gnu.org ---
Resolving as WORKSFORME.  Thanks for the bug report.
I do encourage you to upgrade to a newer version of
gfortran if you can.

[Bug c++/86068] __cpp_transactional_memory is 210500

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  6 17:55:39 2018
New Revision: 261242

URL: https://gcc.gnu.org/viewcvs?rev=261242&root=gcc&view=rev
Log:
PR c++/86068
* c-cppbuiltin.c (c_cpp_builtins): Fix a typo, set
__cpp_transactional_memory to 201500 instead of 210500.

* include/bits/c++config: Check __cpp_transactional_memory >= 201500L
rather than __cpp_transactional_memory >= 201505L.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-cppbuiltin.c
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/c++config

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Wed, Jun 06, 2018 at 09:06:04AM +, marxin at gcc dot gnu.org wrote:
> 
> --- Comment #6 from Martin Liška  ---
> Sorry for the breakage, patch candidate sent here:
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00285.html
> 

Please commit the patch to fix the bootstrap failure,
or revert the revision causing the bootstrap failure.

[Bug c/86073] New: -O3 arm generates calls to memset even for known at the compile time very small sizes (<=3)

[pj at hugeone dot co.uk]

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

Bug ID: 86073
   Summary: -O3 arm generates calls to memset even for known at
the compile time very small sizes (<=3)
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pj at hugeone dot co.uk
  Target Milestone: ---

The test code:

void *my_memset1(void *ptr, const int v, size_t size)
{
size_t rem = size & 3;
size_t pro = (4 - ((uint32_t)ptr & 3)) & 3;
uint32_t v32 = *(uint32_t *)ptr = (((unsigned)v) << 24) | (((unsigned)v) <<
16) | (((unsigned)v) << 8) | v;
void *retval = ptr;

pro = pro >= size ? pro : size;
size -= pro;
while(pro--)
{
*(uint8_t *)ptr++ = v;
}
size >>= 2;
while(size--)
{
*(uint32_t *)ptr = v32;
ptr+=4;
}

while(rem--)
{
*(uint8_t *)ptr++ = v;
}
return retval;
}

rem is always <= 3
pro is always <= 3

both generate call to the buikt in memset function


my_memset1:
  push {r3, r4, r5, r6, r7, r8, r9, lr}
  lsls r5, r1, #16
  negs r3, r0
  and r3, r3, #3
  orr r5, r5, r1, lsl #24
  orrs r5, r5, r1
  cmp r3, r2
  orr r5, r5, r1, lsl #8
  it cc
  movcc r3, r2
  mov r7, r1
  mov r8, r0
  str r5, [r0]
  subs r6, r2, r3
  and r9, r2, #3
  cbz r3, .L13
  mov r2, r3
  uxtb r1, r1
  mov r4, r3
  bl memset   <<--- here
  lsrs r0, r6, #2
  add r3, r8, r4
  beq .L14
.L20:
  add r0, r3, r0, lsl #2
.L11:
  str r5, [r3], #4
  cmp r3, r0
  bne .L11
.L10:
  cmp r9, #0
  beq .L12
  mov r2, r9
  uxtb r1, r7
  bl memset<< here
.L12:
  mov r0, r8
  pop {r3, r4, r5, r6, r7, r8, r9, pc}
.L13:
  mov r3, r0
  lsrs r0, r6, #2
  bne .L20
.L14:
  mov r0, r3
  b .L10

[Bug target/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures

[bergner at gcc dot gnu.org]

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

--- Comment #10 from Peter Bergner  ---
Author: bergner
Date: Wed Jun  6 18:40:53 2018
New Revision: 261243

URL: https://gcc.gnu.org/viewcvs?rev=261243&root=gcc&view=rev
Log:
PR target/63177
* /config/rs6000/rs6000.h (ASM_CPU_SPEC): Add support for -mpower9.
Don't handle -mcpu=power8 if -mpower9-vector is also used.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.h

[Bug target/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner  ---
Fixed on trunk.  I'll check how far back we need to back port this to and fix
it there too.

[Bug fortran/86065] gfortran NAMELIST improperly reads arrays that span more than one line.

[charlie at sallyandcharlie dot com]

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

--- Comment #4 from Charlie  ---
Thank you.

I ran "MinGW Installation Manager" and it installed gfortran v 6.3.0-1

That version appears to work fine for my namelist array problem.

I'm not sure how to upgrade beyond 6.3.0-1 to the versions mentioned in the
"known to work" section (6.4.1, 7.3.1, 8.1.1, 9.0)
but my immediate problem is certainly fixed.

Thanks Again,
Charlie

-Original Message-
From: kargl at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Wednesday, June 6, 2018 10:52 AM
To: char...@sallyandcharlie.com
Subject: [Bug fortran/86065] gfortran NAMELIST improperly reads arrays that
span more than one line.

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||6.4.1, 7.3.1, 8.1.1, 9.0
 Resolution|--- |WORKSFORME

--- Comment #3 from kargl at gcc dot gnu.org ---
Resolving as WORKSFORME.  Thanks for the bug report.
I do encourage you to upgrade to a newer version of
gfortran if you can.

[Bug c++/85577] list-initialization chooses initializer-list constructor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Can the testcase be turned into a runtime test?  I couldn't figure it out (how
to construct A).

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Martin Liška  ---
> Sorry for the breakage, patch candidate sent here:
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00285.html

Now successfully bootstrapped without regressions on i386-pc-solaris2.11
and sparc-sun-solaris2.11.

Rainer

[Bug c++/82930] [C++17] ICE: in is_normal_capture_proxy, at cp/lambda.c:288 with structured binding in a lambda function with auto typed arguments

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed in r257761.

[Bug c++/83996] [6/7 Regression] ICE with zero-sized array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/86063] [6/7/8/9 Regression] g++ ICE at tree check: expected tree_list, have expr_pack_expansion in cp_check_const_attributes, at cp/decl2.c:1391

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/85958] Make const qualifier error clear

[jg at jguk dot org]

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

--- Comment #10 from Jonny Grant  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Jonny Grant from comment #5)
> > I personally feel "bind" is not a word any programming course teaches, we
> > say "passing parameters" or "passing arguments".
> 
> You pass arguments, which initialize parameters. Initialization of
> references is called binding.

Our C++ lectures always said "pass by reference". A quick search online seems
to say similar. Although I appreciate compiler developers will always use more
formally accurate terms.

https://stackoverflow.com/questions/373419/whats-the-difference-between-passing-by-reference-vs-passing-by-value


> > 
> > In addition, I feel we don't think we really need the word "reference"
> 
> If the parameter type wasn't a reference there would be no problem. Omitting
> the reason it fails seems unhelpful.

My reasoning for not listing the word "reference" is that "int&" includes the
symbol & which means reference.   But a little duplication is ok.. only one
word.

> > Therefore, I suggest the following:
> > 
> > $ g++ -o main main.cpp -Wall -Werror -Wconversion
> > main.cpp: In function ‘int main()’:
> > main.cpp:11:25: error: cannot pass ‘const int’ to non-const ‘int&’
> 
> No this is nonsense. You are not passing something to a reference, you are
> passing it to the function. The object cannot be bound to the reference
> because of the cv-qualifiers.

Ok, point taken you are right.

So this I suggest:
 main.cpp:11:25: error: cannot pass ‘const int’ by non-const ‘int&’

Or with the "reference" word:
 main.cpp:11:25: error: cannot pass ‘const int’ by non-const ‘int&’ reference.

Although i do like W E Brown suggestion, I took out the "type":

"can't initialize parameter reference 'int&' with argument 'const int'"

> I'm keen to make the language clearer, but not by making it simply wrong
> about what's happening!

great! :)

[Bug c++/85577] list-initialization chooses initializer-list constructor

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
To construct an A you'd need to add:

A() = default;

But this might actually be INVALID, due to Core DR 2137.

I'll look into it tomorrow.

[Bug target/85657] Make __ibm128 a separate type, even if long double uses the IBM double-double format

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Wed Jun  6 21:11:15 2018
New Revision: 261246

URL: https://gcc.gnu.org/viewcvs?rev=261246&root=gcc&view=rev
Log:
[gcc]
2018-06-06  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_passes_ieee128): New boolean to
track if we pass or return IEEE 128-bit floating point.
(ieee128_mangling_gcc_8_1): New boolean to say whether to generate
C++ mangling that is compatible with GCC 8.1.
(TARGET_ASM_GLOBALIZE_DECL_NAME): Override target hook.
(init_cumulative_args): Note if we pass or return IEEE 128-bit
floating point types.
(rs6000_function_arg_advance_1): Likewise.
(rs6000_mangle_type): Optionally generate mangled names that match
what GCC 8.1 generated for IEEE 128-bit floating point types.
(rs6000_globalize_decl_name): If we have an external function that
passes or returns IEEE 128-bit types, generate a weak reference
from the mangled name used in GCC 8.1 to the current mangled
name.

[gcc]
2018-06-05  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_init_builtins): Make __ibm128 use
the long double type if long double is IBM extended double.  Make
__float128 use the long double type if long double is IEEE 128-bit.

[gcc/testsuite]
2018-06-05  Michael Meissner  

PR target/85657
* g++.dg/pr85657.C: Only test whether __ibm128 and long double can
be used in templates.  Don't check for them in overloaded functions.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/pr85657.C

[Bug fortran/85641] [7/8/9 Regression] ICE with string concatenate

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
This looks good:

--- frontend-passes.c   (Revision 261245)
+++ frontend-passes.c   (Arbeitskopie)
@@ -57,6 +57,8 @@ static bool has_dimen_vector_ref (gfc_expr *);
 static int matmul_temp_args (gfc_code **, int *,void *data);
 static int index_interchange (gfc_code **, int*, void *);

+static bool is_fe_temp (gfc_expr *e);
+
 #ifdef CHECKING_P
 static void check_locus (gfc_namespace *);
 #endif
@@ -254,6 +256,9 @@ realloc_string_callback (gfc_code **c, int *walk_s
   || !expr1->ts.deferred)
 return 0;

+  if (is_fe_temp (expr1))
+return 0;
+
   expr2 = gfc_discard_nops (co->expr2);

   if (expr2->expr_type == EXPR_VARIABLE)

[Bug fortran/85641] [7/8/9 Regression] ICE with string concatenate

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Jun  6 21:41:29 2018
New Revision: 261248

URL: https://gcc.gnu.org/viewcvs?rev=261248&root=gcc&view=rev
Log:
2018-06-06  Thomas Koenig  

PR fortran/85641
* frontend-passes.c (is_fe_temp): Add prototype.
(realloc_string_callback): Early return for frontend-generated
temporary.

2018-06-06  Thomas Koenig  

PR fortran/85641
* gfortran.dg/realloc_on_assign_30.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_30.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85657] Make __ibm128 a separate type, even if long double uses the IBM double-double format

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Wed Jun  6 22:54:17 2018
New Revision: 261253

URL: https://gcc.gnu.org/viewcvs?rev=261253&root=gcc&view=rev
Log:
[gcc]
2018-06-06  Michael Meissner  

PR target/85657
* config/rs6000/rs6000-builtin.def (BU_IBM128_2): New helper
macro for __ibm128 built-in functions.
(PACK_IF): Add __ibm128 pack/unpack functions.
(UNPACK_IF): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Do not
enable long double built-in functions if long double is IEEE
128-bit floating point.
(rs6000_invalid_builtin): Update long double built-in function
error message.
(rs6000_expand_builtin): For PACK_IF and UNPACK_IF built-in
functions, adjust the built-in function to use the long double
built-in function if __ibm128 and long double are the same type.
* doc/extend.texi (PowerPC builtins): Update documention for
__builtin_{,un}pack_longdouble.  Add documentation for
__builtin_{,un}pack_ibm128.

[gcc/testsuite]
2018-06-06  Michael Meissner  

PR target/85657
* gcc.target/powerpc/pr85657-4.c: New tests.
* gcc.target/powerpc/pr85657-5.c: Likewise.
* gcc.target/powerpc/pr85657-6.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-builtin.def
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/86074] New: gcc fails to compile a code sample

[zhonghao at pku dot org.cn]

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

Bug ID: 86074
   Summary: gcc fails to compile a code sample
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

Created attachment 44242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44242&action=edit
memory leak

The code sample comes from https://bugs.llvm.org/show_bug.cgi?id=20335
The latest llvm can compile the attached code sample, but gcc produces many
errors.

BTW, the llvm bug report says that the attached code triggers memory leak.
Please check whether it also triggers memory leak on GCC.

[Bug tree-optimization/86075] New: dead store elimination defeats strlen optimization after memset zero followed by strcpy

[msebor at gcc dot gnu.org]

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

Bug ID: 86075
   Summary: dead store elimination defeats strlen optimization
after memset zero followed by strcpy
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC emits optimally efficient code for the first of the two equivalent
functions below but generates very inefficient code for the latter.  First, it
zeroes out the entire array even though only a small part of it is used. 
Worse, (and ironically) because it eliminates the store to a[3] as dead early
on (in fre1) and before the strlen pass runs, the strlen optimization isn't
performed, and so the entire dead body of the function isn't eliminated.

Since unnecessarily zeroing-out storage just before storing strings in it is
common practice, detecting and handling it could lead to significant
improvements.  The solution for the missing strlen optimization in this case
could be as simple as enhancing the strlen pass to track not just string
lengths but also sizes of zeroed-out blocks of storage used for strings.

$ cat c.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c
void f (void)
{
  char a[4096];

  __builtin_memcpy (a, "123", 3);
  a[3] = 0;

  if (__builtin_strlen (a) != 3)// folded
__builtin_abort ();
}

void g (void)
{
  char a[4096] = "";// all bytes zeroed out

  __builtin_memcpy (a, "123", 3);
  a[3] = 0; // eliminated

  if (__builtin_strlen (a) != 3)// not folded
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1956, cgraph_uid=0, symbol_order=0)

f ()
{
   [local count: 1073741825]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1960, cgraph_uid=1, symbol_order=1)

g ()
{
  char a[4096];
  long unsigned int _1;

   [local count: 1073741825]:
  a = "";
  __builtin_memcpy (&a, "123", 3);
  _1 = __builtin_strlen (&a);
  if (_1 != 3)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  a ={v} {CLOBBER};
  return;

}

[Bug target/86067] [MIPS] ICE: scal-to-vec1.c:86:1: error: unrecognizable insn with -march=loongson3a

[paul.hua.gm at gmail dot com]

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

--- Comment #2 from Paul Hua  ---
(In reply to Richard Biener from comment #1)
> Which GCC version did you use?

the trunk version (r261200)

It's also ICEed on gcc-7 and gcc-8.

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-07
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Mine, not sure why that patch would break it. I had to manually apply to 7
branch so maybe I flubbed it.

[Bug tree-optimization/86076] New: [9 Regression] ICE: verify_gimple failed (error: location references block not in block tree)

[asolokha at gmx dot com]

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

Bug ID: 86076
   Summary: [9 Regression] ICE: verify_gimple failed (error:
location references block not in block tree)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20180603 snapshot (r261132) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -ftree-parallelize-loops=2 -fno-tree-dce
-fno-tree-pre -fno-tree-vrp --param max-loop-header-insns=1:

% gcc-9.0.0-alpha20180603 -O2 -ftree-parallelize-loops=2 -fno-tree-dce
-fno-tree-pre -fno-tree-vrp --param max-loop-header-insns=1 -c gjp2o2cc.c
gjp2o2cc.c: In function 'o7':
gjp2o2cc.c:10:1: error: location references block not in block tree
 o7 (int uu)
 ^~
lv.constprop
_2 = lv.constprop ();
during GIMPLE pass: ompexpssa
gjp2o2cc.c:10:1: internal compiler error: verify_gimple failed
0xce3469 verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180603/work/gcc-9-20180603/gcc/tree-cfg.c:5401
0xbbebaf execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180603/work/gcc-9-20180603/gcc/passes.c:1994
0xbbfafe execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180603/work/gcc-9-20180603/gcc/passes.c:2048

[Bug tree-optimization/86076] [9 Regression] ICE: verify_gimple failed (error: location references block not in block tree)

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
int __attribute__ ((noinline))
lv (int tm)
{
  (void) tm;

  return 0;
}

void
o7 (int uu)
{
  while (uu < 1)
while (uu != 0)
{
  short int ca;

  ca = lv (0);
  (void) ca;
  ++uu;
}

  lv (lv (0));
}

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Thu Jun  7 04:21:35 2018
New Revision: 261260

URL: https://gcc.gnu.org/viewcvs?rev=261260&root=gcc&view=rev
Log:
Fix libgcov-driver-system bootstrap failure (PR bootstrap/86057).

2018-06-07  Martin Liska  

PR bootstrap/86057
* libgcov-driver-system.c (replace_filename_variables): Use
memcpy instead of mempcpy.
(allocate_filename_struct): Do not allocate filename, allocate
prefix and set it.
(gcov_exit_open_gcda_file): Allocate memory for gf->filename
here and properly copy content into it.
* libgcov-driver.c (struct gcov_filename): Remove max_length
field, change prefix from size_t into char *.
(compute_summary): Do not calculate longest filename.
(gcov_do_dump): Release memory of gf.filename after each file.
* libgcov-util.c (compute_summary): Use new signature of
compute_summary.
(calculate_overlap): Likewise.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/libgcov-driver-system.c
trunk/libgcc/libgcov-driver.c
trunk/libgcc/libgcov-util.c

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/86076] [7/8/9 Regression] ICE: verify_gimple failed (error: location references block not in block tree)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-07
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|[9 Regression] ICE: |[7/8/9 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: location references |(error: location references
   |block not in block tree)|block not in block tree)
 Ever confirmed|0   |1
  Known to fail||7.1.0, 8.1.0, 9.0

--- Comment #2 from Martin Liška  ---
Confirmed, note that I see it also on GCC 7 and 8 branches.
Started with an unrelated commit I guess: r241329.

[Bug c++/86074] gcc fails to compile a code sample

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-06-07
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Note that ICC 18 also rejects with:

(33): error: function template "operator==" has already been defined

  friend bool operator==(SimpleAllocator const & lhs, SimpleAllocator
const & rhs)

  ^

  detected during:

instantiation of class "SimpleAllocator [with T=char]" at line
88 of
"/opt/compiler-explorer/gcc-6.3.0/bin/../include/c++/6.3.0/bits/alloc_traits.h"

instantiation of class "std::allocator_traits<_Alloc> [with
_Alloc=SimpleAllocator]" at line 52 of
"/opt/compiler-explorer/gcc-6.3.0/bin/../include/c++/6.3.0/ext/alloc_traits.h"

instantiation of class "__gnu_cxx::__alloc_traits<_Alloc> [with
_Alloc=SimpleAllocator]" at line 75 of
"/opt/compiler-explorer/gcc-6.3.0/bin/../include/c++/6.3.0/bits/basic_string.h"

instantiation of class "std::__cxx11::basic_string<_CharT, _Traits,
_Alloc> [with _CharT=char, _Traits=std::char_traits,
_Alloc=SimpleAllocator]" at line 56

(39): error: function template "operator!=" has already been defined

  friend bool operator!=(SimpleAllocator const & lhs, SimpleAllocator
const & rhs)

  ^

  detected during:

instantiation of class "SimpleAllocator [with T=char]" at line
88 of
"/opt/compiler-explorer/gcc-6.3.0/bin/../include/c++/6.3.0/bits/alloc_traits.h"

instantiation of class "std::allocator_traits<_Alloc> [with
_Alloc=SimpleAllocator]" at line 52 of
"/opt/compiler-explorer/gcc-6.3.0/bin/../include/c++/6.3.0/ext/alloc_traits.h"

instantiation of class "__gnu_cxx::__alloc_traits<_Alloc> [with
_Alloc=SimpleAllocator]" at line 75 of
"/opt/compiler-explorer/gcc-6.3.0/bin/../include/c++/6.3.0/bits/basic_string.h"

instantiation of class "std::__cxx11::basic_string<_CharT, _Traits,
_Alloc> [with _CharT=char, _Traits=std::char_traits,
_Alloc=SimpleAllocator]" at line 56

compilation aborted for  (code 2)

Compiler returned: 2

Is it really a valid code snippet?

[Bug c++/86074] gcc fails to compile a code sample

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Moving the definition of the operator== and operator!= out from the template
class, then the code works.

[Bug pending/86077] New: gcc does not recognize --param key=value when surrounded by single quotes

[ptdrnvqd at 10mail dot org]

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

Bug ID: 86077
   Summary: gcc does not recognize --param key=value when
surrounded by single quotes
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pending
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ptdrnvqd at 10mail dot org
  Target Milestone: ---

gcc 5.5.0

when trying to build tensorflow using bazel
if i specify flags, it for some of the commands automatically wraps them in
single quotes, thus errors like 

gcc: error: unrecognized command line option '--param
max-inline-insns-single=500'

copy-find-replace-pasting the command to remove the single-quotes removes the
error but there are so many files!, rather unfeasible to do this manually

 i don't if this is bazel's fault more or gcc, could it be fixed here?

[Bug c++/86074] gcc fails to compile a code sample

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Nathan Sidwell  ---
Yeah, it's invalid.  The template friend operator== function's signature does
not depend on the enclosing template at all.  so, when instantiated in say
simpleAllocator and simpleAllocator, will collide.