[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Created attachment 40273
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40273=edit
Results with Andre's patch

> But from your description I could fix (1) and (2) by looking at the code.
> Attached patch also fixes some formating.

Works as expected. Thanks.

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
Created attachment 40272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40272=edit
Lightly tested patch.

(In reply to Martin Sebor from comment #6)

After some more testing, although the patch I showed happens to fix the problem
in the test case, it's not actually correct.  I found a few other subtle issues
in the function that need to fixed.  I'm testing a more comprehensive patch
that should fix it the right way.

[Bug middle-end/78703] -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-07
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
The MB_LEN_MAX value could be specified via a target hook just like the %p
format was.  For unknown targets a conservative MB_LEN_MAX value could be
hardcoded to 6 based on UTF-8.  I'm not aware of an encoding with a value
that's greater than that or an implementation that defines it to a larger
value.  If there was one where MB_LEN_MAX was larger then that value could be
used.

POSIX defines the term Radix Character as "the character that separates the
integer part of a number from the fractional part."  It further defines the
term Character as "a sequence of one or more bytes representing a single
graphic symbol or control code."  I think that makes it fairly clear that the
decimal_point string specified in a locale definition file is meant to be a
single multibyte character.  I haven't tried to see if there is a localedef
utility that would accept a longer string or, if there is one, that the libc
implementation on which it runs would accept it.

That said, although assuming that the length of the decimal point character is
up to MB_LEN_MAX bytes should be safe under these constraints, disabling the
optimization when a floating point directive was detected that produced a
decimal point would another way to avoid the problem.

[Bug target/71727] -O3 -mstrict-align produces code which assumes unaligned vector accesses work

[hs.naveen2u at gmail dot com]

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

hs.naveen2u at gmail dot com changed:

   What|Removed |Added

 CC||hs.naveen2u at gmail dot com

--- Comment #3 from hs.naveen2u at gmail dot com ---
Fixed and Committed as:-
https://gcc.gnu.org/ml/gcc-cvs/2016-12/msg00244.html

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Wed, Dec 07, 2016 at 01:31:51AM +, dmalcolm at gcc dot gnu.org wrote:
> 
> --- Comment #7 from David Malcolm  ---
> Sorry about the breakage.  Should be fixed by r243332.
> 

Thanks for the prompt attention to this bug.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #12 from Kazumoto Kojima  ---
Hmm...  From
https://gcc.gnu.org/onlinedocs/gccint/Sharing.html#Sharing
the above patch looks wrong.  Perhaps the splitter in problem
might have to take care of subreg case even when referencing
a reg rtx in the input operands.

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Sorry about the breakage.  Should be fixed by r243332.

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Wed Dec  7 01:28:13 2016
New Revision: 243332

URL: https://gcc.gnu.org/viewcvs?rev=243332=gcc=rev
Log:
Fix x86_64-ism in selftest (PR bootstrap/78705)

In r243317 I accidentally introduced an assumption in a selftest
in i386.c that Pmode == DImode.  This patch conditionalizes the
overzealous string comparison to avoid breaking the build on
32-bit i386.c targets.

gcc/ChangeLog:
PR bootstrap/78705
* config/i386/i386.c (selftest::ix86_test_dumping_memory_blockage):
Conditionalize the string comparison on Pmode == DImode.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
i386.md's define_expand "memory_blockage" has:
  operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
so it's due to the difference in Pmode between i386 and x86_64.

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Dec  7 01:08:40 2016
New Revision: 243331

URL: https://gcc.gnu.org/viewcvs?rev=243331=gcc=rev
Log:
2016-12-06  Bill Schmidt  

Backport from mainline
2016-12-05  Bill Schmidt  
Stefan Freudenberger  

PR tree-optimization/78646
* gimple-ssa-strength-reduction.c (replace_ref): The pointer
addition used for the memory base expression should have the type
of the candidate.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimple-ssa-strength-reduction.c

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Dec  7 01:04:47 2016
New Revision: 243330

URL: https://gcc.gnu.org/viewcvs?rev=243330=gcc=rev
Log:
2016-12-06  Bill Schmidt  

Backport from mainline
2016-12-05  Bill Schmidt  
Stefan Freudenberger  

PR tree-optimization/78646
* gimple-ssa-strength-reduction.c (replace_ref): The pointer
addition used for the memory base expression should have the type
of the candidate.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimple-ssa-strength-reduction.c

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-07
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from David Malcolm  ---
Reproduced with i686-pc-linux-gnu

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  ---
Created attachment 40271
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40271=edit
reduce testcase

With -O1, sh4-linux compiler makes insns

(insn 67 150 165 5 (set (reg:SI 239)
(and:SI (subreg:SI (reg/v:DI 163 [ high ]) 0)
(const_int 1 [0x1]))) "test.c":34 88 {*andsi_compact}
 (nil))
(insn 165 67 74 5 (set (reg:SI 147 t)
(eq:SI (and:SI (subreg:SI (reg/v:DI 163 [ high ]) 0)
(const_int 1 [0x1]))
(const_int 0 [0]))) "test.c":34 -1
 (nil))

and two (subreg:SI (reg/v:DI 163 [ high ]) 0) are shared.

emit-rtl.c:verify_rtl_sharing calls verify_insn_sharing for these
insns and verify_insn_sharing marks rtxes with verify_rtx_sharing.
SUBREG rtx is always marked as used with verify_rtx_sharing.  Then
the second subreg is reported as erroneous because it's already
marked as used.  I think that this is a false positive.  It seems
to me that SUBREG should be handled specially.

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 4650540..4fa4773 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2714,6 +2714,9 @@ verify_rtx_sharing (rtx orig, rtx insn)
 case SCRATCH:
   /* SCRATCH must be shared because they represent distinct values.  */
   return;
+case SUBREG:
+  verify_rtx_sharing (SUBREG_REG (x), insn);
+  return;
 case CLOBBER:
   /* Share clobbers of hard registers (like cc0), but do not share pseudo
reg
  clobbers or clobbers of hard registers that originated as pseudos.

I could be totally wrong about that, though.

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Sorry about the breakage.

Expected:
(cinsn 1 (set (mem/v:BLK (0|scratch:DI) [0  A8])
(unspec:BLK [
(mem/v:BLK (reuse_rtx 0) [0  A8])
] UNSPEC_MEMORY_BLOCKAGE)))

Actual:
(cinsn 1 (set (mem/v:BLK (0|scratch:SI) [0  A8])
(unspec:BLK [
(mem/v:BLK (reuse_rtx 0) [0  A8])
] UNSPEC_MEMORY_BLOCKAGE)))

Looks like the difference is "SI" vs "DI" within the scratch.

[Bug target/72717] [5/6/7 Regression] ICE: in emit_move_insn, at expr.c:3693 with vector shift @ powerpc64le

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Created attachment 40270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40270=edit
Proposed patch

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
svn merge -r 243317:243316 .

fixes the problem.

[Bug bootstrap/78705] ICE in ix86_test_dumping_memory_blockage

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> gmake[3]: Entering directory '/mnt/kargl/obj/gcc'
> /mnt/kargl/obj/./gcc/xgcc -B/mnt/kargl/obj/./gcc/ -nostdinc -x c /dev/null
> -S -fself-test -o /dev/null
> /mnt/kargl/gcc/gcc/config/i386/i386.c:51198:
> ix86_test_dumping_memory_blockage: FAIL: ASSERT_STREQ (expected_dump, dump)
> expected="(cinsn 1 (set (mem/v:BLK (0|scratch:DI) [0  A8])
> (unspec:BLK [
> (mem/v:BLK (reuse_rtx 0) [0  A8])
> ] UNSPEC_MEMORY_BLOCKAGE)))
> " actual="(cinsn 1 (set (mem/v:BLK (0|scratch:SI) [0  A8])
> (unspec:BLK [
> (mem/v:BLK (reuse_rtx 0) [0  A8])
> ] UNSPEC_MEMORY_BLOCKAGE)))
> "
> cc1: internal compiler error: in fail_formatted, at selftest.c:62
> no stack trace because unwind library not available
> Please submit a full bug report,
> with preprocessed source if appropriate.

This failure is on i686-*-freebsd.

/mnt/kargl/gcc/configure \
  --prefix=$HOME/work --with-isl=/usr/local \
  --enable-languages=c,c++,fortran --disable-nls

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #12 from Jeffrey A. Law  ---
I'm starting to lean towards disabling the optimization by default for gcc-7. 
It's tickling a number of issues at this stage and I'm starting to worry there
may be many more out there.

[Bug bootstrap/78705] New: ICE in ix86_test_dumping_memory_blockage

[kargl at gcc dot gnu.org]

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

Bug ID: 78705
   Summary: ICE in ix86_test_dumping_memory_blockage
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

gmake[3]: Entering directory '/mnt/kargl/obj/gcc'
/mnt/kargl/obj/./gcc/xgcc -B/mnt/kargl/obj/./gcc/ -nostdinc -x c /dev/null -S
-fself-test -o /dev/null
/mnt/kargl/gcc/gcc/config/i386/i386.c:51198: ix86_test_dumping_memory_blockage:
FAIL: ASSERT_STREQ (expected_dump, dump) expected="(cinsn 1 (set (mem/v:BLK
(0|scratch:DI) [0  A8])
(unspec:BLK [
(mem/v:BLK (reuse_rtx 0) [0  A8])
] UNSPEC_MEMORY_BLOCKAGE)))
" actual="(cinsn 1 (set (mem/v:BLK (0|scratch:SI) [0  A8])
(unspec:BLK [
(mem/v:BLK (reuse_rtx 0) [0  A8])
] UNSPEC_MEMORY_BLOCKAGE)))
"
cc1: internal compiler error: in fail_formatted, at selftest.c:62
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/67955] tree-dse does not use pointer info

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #10 from Jeffrey A. Law  ---
I've applied Tom's patch to the trunk which fixes this problem.

[Bug tree-optimization/67955] tree-dse does not use pointer info

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Tue Dec  6 23:18:17 2016
New Revision: 243325

URL: https://gcc.gnu.org/viewcvs?rev=243325=gcc=rev
Log:
PR tree-optimization/67955
* tree-ssa-alias.c (same_addr_size_stores_p): New function.
(stmt_kills_ref_p): Use it.

PR tree-optimization/67955
* gcc.dg/tree-ssa/dse-points-to.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/dse-points-to.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c

[Bug other/55389] library cannot be rebuilt by make all-target

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
*** Bug 52197 has been marked as a duplicate of this bug. ***

[Bug libitm/52197] library cannot be rebuilt by make all-target

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
.

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

[Bug other/55389] library cannot be rebuilt by make all-target

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
This happens for libsanitizer, libcilkrts, libitm at least.

[Bug middle-end/78700] [7 regression] gccgo testcases stack.go, recover.go, crypto/tls fails

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

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

[Bug middle-end/78700] [7 regression] gccgo testcases stack.go, recover.go, crypto/tls fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Dec  6 22:47:00 2016
New Revision: 243322

URL: https://gcc.gnu.org/viewcvs?rev=243322=gcc=rev
Log:
PR middle-end/78700
* calls.c (expand_call): Move back call to prepare_call_address.

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

[Bug target/72717] [5/6/7 Regression] ICE: in emit_move_insn, at expr.c:3693 with vector shift @ powerpc64le

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug target/78658] powerpc64le: ICE with -mcpu=power9 -Og

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Tue Dec  6 22:15:31 2016
New Revision: 243320

URL: https://gcc.gnu.org/viewcvs?rev=243320=gcc=rev
Log:
[gcc]
2016-12-06  Michael Meissner  

PR target/78658
* config/rs6000/rs6000.md (zero_extendqi2): Use ^ instead of
?* constraints for the ISA 3.0 patterns, so the register allocator
is more likely to allocate QImode/HImode to vector registers for
conversion to floating point unless a reload is needed.
(zero_extendhi2): Likewise.
(float2_internal): Properly deal with the
first alternative which is converting QImode/HImode to floating
point and the QImode/HImode value is in a vector register, and
does not allocate the second pseudo register.  Remove zero
extending into traditional floating point registers, since the
instruction used only works on traditional altivec registers.
(floatuns2_internal): Likewise.

[gcc/testsuite]
2016-12-06  Michael Meissner  

PR target/78658
* gcc.target/powerpc/pr78658.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr78658.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #29 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Dec  6 22:11:54 2016
New Revision: 243319

URL: https://gcc.gnu.org/viewcvs?rev=243319=gcc=rev
Log:
2016-12-06  Bill Schmidt  

Backport from mainline
2016-09-01  Bill Schmidt  
Michael Meissner  

PR target/72827
* config/rs6000/rs6000.c (rs6000_legitimize_address): Avoid
reg+reg addressing for TImode.
(rs6000_legitimate_address_p): Only allow register indirect
addressing for TImode, even without TARGET_QUAD_MEMORY.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
(In reply to Bernd Schmidt from comment #3)
> Not sure it's that bad really. An unconditional trap is pretty much by
> definition not performance-critical.

Sure, but this was prohibiting propagating anything into a *conditional*
trap instruction?  Or do I read that wrong.

[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

[vanyacpp at gmail dot com]

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

--- Comment #4 from Ivan Sorokin  ---
(In reply to Richard Biener from comment #1)

> +  if (flag_delete_null_pointer_checks
> +  && is_gimple_assign (stmt)
> +  && is_gimple_assign (stmt)

Duplicate conjunct.

> +  && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR
> +  && tree_expr_nonzero_p (gimple_assign_rhs2 (stmt)))
> +return true;
> +
>return false;
>  }

I thought a bit more about the issue. I think that not only the result of
pointer-integer addition, but also its argument are values that could be proven
non-zero. Consider the following example:

bool f(int* a)
{
  bool x = a == nullptr;
  a += 10;
  return x;
}

In this example x could be proven to be false. Because if it is true then
(a+=10) causes undefined behavior. At the moment clang doesn't optimize this. I
don't any real example when this is needed. Just the way this optimization can
be made more widely applicable.

[Bug libobjc/78698] [7 regression] Using static PIC libgc fails when it has dependencies

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
Created attachment 40269
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40269=edit
Candidate patch

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt  ---
Not sure it's that bad really. An unconditional trap is pretty much by
definition not performance-critical. Then again, there's a possible alternate
fix, which I'll attach.

[Bug middle-end/78703] -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
But how will you know what MB_LEN_MAX the different implementations use?
And does it really have to be a single character, not a string?

At least in glibc in the included locales there are just 3 decimal_point forms,
"", "" and "".  But perhaps you should see if localedef
allows you to define something containing multiple characters (or a single one
from surrogate pair etc.).  Would be also interesting to see if zero length
radix character will get through.

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to jos...@codesourcery.com from comment #9)
> Implementation-specific can in practice include cases where the 
> implementation deviates from the standard (e.g. Windows 3-digit exponents, 
> though disabling the optimization for floating-point formats should hide 
> that).  It's clearly not a good idea to convert a minor conformance bug in 
> the library into a buffer overrun by causing a program to allocate enough 
> memory for the standard output from a format but not enough for what the 
> library implementation actually outputs.
> 
> (It wouldn't surprise me if there are printf implementations whose results 
> for some floating-point values are not one of the nearest decimals in each 
> direction and so could take more characters than either of those take in 
> some cases.)

Yeah, that is what I don't like on -fprintf-return-value either.  Warning if in
certain cases the GCC assumption on what the library will actually do is not
100% matching the library implementation is one thing, but the optimization
(which I'm not sure is really that beneficial in most cases) is just too
dangerous, perhaps with the exception of the safest cases (no % characters, or
just %s with known non-NULL strings, or perhaps some easy integral cases).
There are many library implementations, and not all of them match the spec
100%, and the current GCC implementation of the optimization doesn't match it
100% either.

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #6)
> The bug behind the wrong output in comment #0 is in the format_floating
> function with an unknown argument failing to use the precision.  The
> following simple patch fixes that.
> 
> @@ -1261,9 +1277,9 @@ format_floating (const conversion_spec , int
>   res.range.min = 2 + (prec < 0 ? 6 : prec);
>  
>   /* Compute the maximum just once.  */
> - static const int f_max[] = {
> -   format_floating_max (double_type_node, 'f'),
> -   format_floating_max (long_double_type_node, 'f')
> + const int f_max[] = {
> +   format_floating_max (double_type_node, 'f', prec),
> +   format_floating_max (long_double_type_node, 'f', prec)
>   };
>   res.range.max = width == INT_MIN ? HOST_WIDE_INT_MAX : f_max [ldbl];

I'm happy you've removed the static, because it performs a runtime construction
of the array.  But: 1) the comment is now wrong 2) it is really weird and
inefficient way of writing:
  if (width == INT_MIN)
res.range.max = HOST_WIDE_INT_MAX;
  else
res.range.max = format_floating_max (ldbl ? long_double_type_node
 : double_type_node, 'f', prec);

> @@ -1279,9 +1295,9 @@ format_floating (const conversion_spec , int
>   res.range.min = 2 + (prec < 0 ? 6 : prec);
>  
>   /* Compute the maximum just once.  */
> - static const int g_max[] = {
> -   format_floating_max (double_type_node, 'g'),
> -   format_floating_max (long_double_type_node, 'g')
> + const int g_max[] = {
> +   format_floating_max (double_type_node, 'g', prec),
> +   format_floating_max (long_double_type_node, 'g', prec)
>   };
>   res.range.max = width == INT_MIN ? HOST_WIDE_INT_MAX : g_max [ldbl];

Similarly.

[Bug preprocessor/78680] [7 Regression] ICE in get_substring_ranges_for_loc, at input.c:1398

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
I have tested something similar, and it does work, but it prevents any
optimisation by cprop of any trap_if, also if it would not turn into
an unconditional trap.  This is pretty bad :-(

[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

[vanyacpp at gmail dot com]

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

--- Comment #3 from Ivan Sorokin  ---
(In reply to Richard Biener from comment #1)

> Of course I wonder why the check is here in the first place...  Is placement
> new valid for nullptr?

I believe this check here is to allow placement new (std::nothrow) T() to work.
I don't know about the standard wording though.

[Bug target/78658] powerpc64le: ICE with -mcpu=power9 -Og

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 40268
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40268=edit
Proposed patch

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[segher at gcc dot gnu.org]

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

--- Comment #17 from Segher Boessenkool  ---
(In reply to James Greenhalgh from comment #16)
> Created attachment 40267 [details]
> Proposed Patch
> 
> Would you mind testing the attached to see if it fixes your issue?

Bootstrapped fine, regression suite worked fine.  :-)

> I've bootstrapped it on PowerPC myself without any problems, but that's not
> a strong endorsement of the patch given that I've yet to reproduce your
> failure!

It's still a mystery what causes this.  I use a recentish binutils and
GCC to build with, and you use the old OS versions, that is the only
difference I can see.  How that leads to this difference, I have no idea.

[Bug c++/78704] New: operator-> pointer return type is not recognized as pointer type

[joseph.h.garvin at gmail dot com]

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

Bug ID: 78704
   Summary: operator-> pointer return type is not recognized as
pointer type
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joseph.h.garvin at gmail dot com
  Target Milestone: ---

My coworker Jay Miller discovered this but he couldn't create an account
because of the spam restriction in effect. He tried to send an e-mail to the
overseers list as suggested but it bounced back -- it's possible nobody can
create accounts or request them right now.

In this minimal test case operator-> returns a pointer type but neither GCC 4.9
or 6.2 recognize it as such:

struct Object
{
int key;
};

// Making this a class rather than a template allows it to compile
template 
class Foo
{
public:
// Changing the returning type to const Object* allows it to compile
auto operator->() const { return  }

private:
Object b;
};

// Making this a class rather than a template allows it to compile
template 
class X
{
protected:
Foo cont;

public:
int get_val() const
{
// error: result of 'operator->()' yields non-pointer result
return cont->key;

// Calling operator-> directory compiles fine
//return cont.operator->()->key;
}
};

int main()
{
return 0;
}

[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
See also PR 35878.

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  ---
This appears to happen in cprop. Would anyone like to test this on ppc?

Index: cprop.c
===
--- cprop.c (revision 242958)
+++ cprop.c (working copy)
@@ -1047,6 +1047,10 @@
   int changed = 0, changed_this_round;
   rtx note;

+  /* We can't convert these to unconditional traps because it would invalidate
the CFG.  */
+  if (GET_CODE (PATTERN (insn)) == TRAP_IF)
+return 0;
+
   do
 {
   changed_this_round = 0;

[Bug preprocessor/78657] Using macro with _Pragma gives error: '#pragma' is not allowed here

[jquinsey at entrenet dot com]

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

--- Comment #5 from Joseph Quinsey  ---
More similar or duplicate reports:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37267

[Bug libstdc++/78702] [libstdc++] class __shim in locale::facet is private

[hiraditya at msn dot com]

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

--- Comment #3 from AK  ---
llvm-project/install/bin/clang++ -std=gnu++14 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cxx11-shim_facets.lo -c ../../../src/c++11/cxx11-shim_facets.cc 
-fPIC -DPIC -D_GLIBCXX_SHARED -o cxx11-shim_facets.o (+ some include flags from
Makefile)


../../../src/c++11/cxx11-shim_facets.cc:230:60: error: '__shim' is a private
member of 'std::locale::facet'
  struct numpunct_shim : std::numpunct<_CharT>, facet::__shim
   ^
~/s/work/gcc/libstdc++-v3/build/include/bits/locale_classes.h:464:11: note:
declared private here
class __shim;


clang version 4.0.0
Target: x86_64-unknown-linux-gnu

[Bug libstdc++/78702] [libstdc++] class __shim in locale::facet is private

[hiraditya at msn dot com]

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

--- Comment #2 from AK  ---
Sorry for the confusion, I was using clang++ (trunk) to build libstdc++

[Bug preprocessor/78657] Using macro with _Pragma gives error: '#pragma' is not allowed here

[jquinsey at entrenet dot com]

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

Joseph Quinsey  changed:

   What|Removed |Added

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

--- Comment #4 from Joseph Quinsey  ---
Similar or duplicate reports:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70811,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59367,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50387.

[Bug preprocessor/78657] Using macro with _Pragma gives error: '#pragma' is not allowed here

[jquinsey at entrenet dot com]

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

--- Comment #3 from Joseph Quinsey  ---
Similar or duplicate reports:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70811,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59367,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50387.

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[vlad at petric dot cc]

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

--- Comment #10 from Vlad Petric  ---
Could someone boost its priority? Given that gcc segfaults with valid code (see
newest example/attachment), I believe it's worth a P1.

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
Implementation-specific can in practice include cases where the 
implementation deviates from the standard (e.g. Windows 3-digit exponents, 
though disabling the optimization for floating-point formats should hide 
that).  It's clearly not a good idea to convert a minor conformance bug in 
the library into a buffer overrun by causing a program to allocate enough 
memory for the standard output from a format but not enough for what the 
library implementation actually outputs.

(It wouldn't surprise me if there are printf implementations whose results 
for some floating-point values are not one of the nearest decimals in each 
direction and so could take more characters than either of those take in 
some cases.)

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Still no repro with bootstrap compiler.

wschmidt@genoa:~/src$ $GCC_INSTALL/bin/gcc -S -O3 pr78695.c
wschmidt@genoa:~/src$ $GCC_INSTALL/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/wschmidt/gcc/install/gcc-mainline-test/bin/gcc
COLLECT_LTO_WRAPPER=/home/wschmidt/gcc/install/gcc-mainline-test/libexec/gcc/powerpc64le-unknown-linux-gnu/7.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /home/wschmidt/gcc/gcc-mainline-test/configure
--enable-languages=c,c++,fortran,objc,obj-c++,go --with-cpu=power8
--disable-multilib --with-long-double-128
--prefix=/home/wschmidt/gcc/install/gcc-mainline-test
Thread model: posix
gcc version 7.0.0 20161203 (experimental) [trunk revision 243219] (GCC) 

Will await more information.

[Bug c++/71274] [5/6 Regression] deprecated static const member of struct raises warning without use

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Dec  6 18:51:56 2016
New Revision: 243314

URL: https://gcc.gnu.org/viewcvs?rev=243314=gcc=rev
Log:
PR c++/71274 - deprecated warning without use.

* decl2.c (maybe_instantiate_decl): Split out from mark_used.
(decl_constant_var_p): Use it instead.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/warn/deprecated-11.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/decl2.c

[Bug c++/71515] [5/6 Regression] ICE on valid C++ code on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Dec  6 18:51:50 2016
New Revision: 243313

URL: https://gcc.gnu.org/viewcvs?rev=243313=gcc=rev
Log:
PR c++/71515 - typename in partial specialization

* pt.c (resolve_typename_type): Try to avoid calling
currently_open_class.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/template/typename22.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/77907] [6 Regression] Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Tue Dec  6 18:51:45 2016
New Revision: 243312

URL: https://gcc.gnu.org/viewcvs?rev=243312=gcc=rev
Log:
PR c++/77907 - static init and PMF

* constexpr.c (cxx_eval_constant_expression): Use cp_fold_convert.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/pr77907.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c

[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Tue Dec  6 18:51:37 2016
New Revision: 243311

URL: https://gcc.gnu.org/viewcvs?rev=243311=gcc=rev
Log:
PR c++/57728 - explicit instantiation and defaulted functions

* pt.c (do_type_instantiation): Don't mess with non-user-provided
member functions.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/explicit12.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/class.c
branches/gcc-6-branch/gcc/cp/pt.c

[Bug target/72717] [5/6/7 Regression] ICE: in emit_move_insn, at expr.c:3693 with vector shift @ powerpc64le

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez  ---
FWIW:

emit_move_insn() is trying to emit a move from an SI to a DI and dying:

#1  0x107a4e24 in emit_move_insn (x=0x3fffb58bd8f0, y=0x3fffb58bd8a8)
at /home/aldyh/gcc/gcc/expr.c:3696
(gdb) call debug_rtx(x)
(reg:DI 179)
(gdb) call debug_rtx(y)
(subreg/s/v:SI (reg:DI 156 [ _3 ]) 0)
(gdb) 

This comes via rs6000_expand_vector_init():

  /* Double word values on VSX can use xxpermdi or lxvdsx.  */
  if (VECTOR_MEM_VSX_P (mode) && (mode == V2DFmode || mode == V2DImode))
{
  rtx op0 = XVECEXP (vals, 0, 0);
  rtx op1 = XVECEXP (vals, 0, 1);
  if (all_same)
{
  if (!MEM_P (op0) && !REG_P (op0))
=>  op0 = force_reg (inner_mode, op0);
  if (mode == V2DFmode)
emit_insn (gen_vsx_splat_v2df (target, op0));
  else
emit_insn (gen_vsx_splat_v2di (target, op0));

...where we have:

(gdb) p inner_mode
$4 = DImode
(gdb) call debug_rtx(vals)
(parallel:V2DI [
(subreg/s/v:SI (reg:DI 156 [ _3 ]) 0)
(subreg/s/v:SI (reg:DI 156 [ _3 ]) 0)
])
(gdb) p inner_mode
$5 = DImode
(gdb) call debug_rtx(op0)  
   
  (subreg/s/v:SI (reg:DI 156 [ _3 ]) 0)

[Bug fortran/70864] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1403

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---
Related to pr68846  (technically slightly different).
Backtrace identical to that of pr68846 comment 3 etc.

[Bug fortran/68846] Pointer function as LValue doesn't work when the assignment regards a dummy argument.

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #5 from Gerhard Steinmetz  
---

Related to pr70864  (technically slightly different).
Backtrace identical to that of pr70864 comment 3.

[Bug fortran/68846] Pointer function as LValue doesn't work when the assignment regards a dummy argument.

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---

Further modified and reduced to a skeleton, i.e. :


$ cat z3.f90
module m68846
   type t
   contains
  procedure, nopass :: f => f1
   end type
contains
   function f1() result(p)
  real, pointer :: p
   end
   subroutine s3(z, value)
  type(t) :: z
  real, intent(in) :: value
  z%f() = value
   end
end module


$ cat z4.f90
module m68846
   type t
   contains
  procedure, nopass :: f => f1
   end type
contains
   function f1() result(p)
  real, pointer :: p
   end
   subroutine s3(z, value)
  type(t) :: z
  real, intent(inout) :: value
  z%f() = value   !!
   end
end module


$ gfortran-7-20161204 -c z3.f90
z3.f90:13:19:

   z%f() = value
   1
Error: Dummy argument '_F.DA0' with INTENT(IN) in pointer association context
(pointer assignment) at (1)


$ gfortran-7-20161204 -c z4.f90
z4.f90:7:0:

function f1() result(p)

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1477
0x75a352 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1477
0x75e5b7 generate_local_decl
../../gcc/fortran/trans-decl.c:5327
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x75f412 generate_local_vars
../../gcc/fortran/trans-decl.c:5527
0x75f412 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6206
0x7331f9 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2164
0x6e72fd translate_all_program_units
../../gcc/fortran/parse.c:6025
0x6e72fd gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/68846] Pointer function as LValue doesn't work when the assignment regards a dummy argument.

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #3 from Gerhard Steinmetz  
---

Both variants reduced and simplified a bit :


$ cat z1.f90
module m68846
  type grid_t
real, pointer :: p(:) => null()
  end type
  type subgrid_t
class(grid_t), pointer :: grd => null()
  contains
procedure, pass :: jmp => lvalue_jmp
  end type
contains
  function lvalue_jmp(hobj, i) result(p)
class(subgrid_t), intent(inout) :: hobj
integer, intent(in) :: i
real, pointer :: p
p => hobj%grd%p(i)
  end
  subroutine fillgeom_03(subgrid, value)
type(subgrid_t), intent(inout) :: subgrid
real, intent(in) :: value
subgrid%jmp(1) = value
  end
end module


$ cat z2.f90
module m68846
  type grid_t
real, pointer :: p(:) => null()
  end type
  type subgrid_t
class(grid_t), pointer :: grd => null()
  contains
procedure, pass :: jmp => lvalue_jmp
  end type
contains
  function lvalue_jmp(hobj, i) result(p)
class(subgrid_t), intent(inout) :: hobj
integer, intent(in) :: i
real, pointer :: p
p => hobj%grd%p(i)
  end
  subroutine fillgeom_03(subgrid, value)
type(subgrid_t), intent(inout) :: subgrid
real, intent(inout) :: value   !!
subgrid%jmp(1) = value
  end
end module


$ gfortran-7-20161204 -c z1.f90
z1.f90:20:26:

 subgrid%jmp(1) = value
  1
Error: Dummy argument '_F.DA0' with INTENT(IN) in pointer association context
(pointer assignment) at (1)


$ gfortran-7-20161204 -c z2.f90
z2.f90:22:0:

 end module

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1477
0x75a352 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1477
0x75e5b7 generate_local_decl
../../gcc/fortran/trans-decl.c:5327
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x75f412 generate_local_vars
../../gcc/fortran/trans-decl.c:5527
0x75f412 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6206
0x7331f9 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2164
0x6e72fd translate_all_program_units
../../gcc/fortran/parse.c:6025
0x6e72fd gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/68846] Pointer function as LValue doesn't work when the assignment regards a dummy argument.

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #2 from Gerhard Steinmetz  
---
Update, new backtrace :


$ gfortran-7-20161204 -c pr68846_in.f90
pr68846_in.f90:61:32:

 subgrid%jmp(i,j) = value
1
Error: Dummy argument '_F.DA0' with INTENT(IN) in pointer association context
(pointer assignment) at (1)


$ gfortran-7-20161204 -c pr68846_inout.f90
pr68846_inout.f90:53:0:

   SUBROUTINE fillgeom_03( subgrid, value  )

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1477
0x75a352 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1477
0x75e5b7 generate_local_decl
../../gcc/fortran/trans-decl.c:5327
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x75f412 generate_local_vars
../../gcc/fortran/trans-decl.c:5527
0x75f412 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6206
0x7331f9 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2164
0x6e72fd translate_all_program_units
../../gcc/fortran/parse.c:6025
0x6e72fd gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/72755] Internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1369

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #10 from Gerhard Steinmetz  
---
Reduced source is nearly identical, backtrace completely identical
to that of pr70864 comment 3.

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
(In reply to jos...@codesourcery.com from comment #5)

Thanks for the pointer to 7.1.1#2.  I wasn't aware of that either.

With the removal of the %p handling the pass doesn't make any assumptions about
implementation-specific behavior.  I agree that in light of the locale-specific
behavior the presence of floating point directives in the format string that
emit a decimal point needs to disable the return value optimization.  I've
raised bug 78703 for that.  I'll submit a separate patch for bug.

[Bug middle-end/78703] New: -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point

[msebor at gcc dot gnu.org]

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

Bug ID: 78703
   Summary: -fprintf-return-value floating point handling
incorrect in locales with a mulltibyte decimal point
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

POSIX specifies that:

All forms of the fprintf() functions allow for the insertion of a
language-dependent radix character in the output string.  The radix character
is defined in the current locale (category LC_NUMERIC).  In the POSIX locale,
or in a locale where the radix character is not defined, the radix character
shall default to a  ('.')

Similar wording is in buried in C which defines the decimal-point character in
7.1.1, p2 (as noted in bug 78696, comment 5).

The following test case derived from bug 78696, comment 3, shows that the
-fprintf-return-value optimization assumes the call is made in the POSIX
locale.  The optimization needs to avoid making this assumption.  To be safe,
it needs to conservatively assume that the length of the decimal point
character is up to MB_LEN_MAX bytes.

$ cat zz.c && gcc -O2 -Wformat zz.c && LC_ALL='ps_AF.UTF-8' ./a.out
#include 

#define FMT "%.2f"
const char *fmt = FMT;

int main (void)
{
  if (!setlocale (LC_ALL, ""))
return 1;

  int m = __builtin_snprintf (0, 0, FMT, 1.5);   // computed by GCC
  int n = __builtin_snprintf (0, 0, fmt, 1.5);   // computed by libc

  __builtin_printf ("%i == %i\n", m, n);
}

4 == 5

[Bug fortran/70864] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1403

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #3 from Gerhard Steinmetz  
---
Reduced and simplified a bit.


$ cat pr70864_cm.f90
module m70864
  type BoxArray
  contains
procedure :: boxarray_assign
generic :: assignment(=) => boxarray_assign
  end type
  type MultiFab
type(BoxArray) :: ba
  end type
contains
  subroutine boxarray_assign (dst, src)
class(BoxArray), intent(inout) :: dst
type (BoxArray), intent(in   ) :: src
  end
  subroutine multifab_copy (mf1, mf2)
type(MultiFab), intent(inout) :: mf1, mf2
mf2 = mf1   !!
  end
end module


$ gfortran-7-20161204 -c pr70864_cm.f90
pr70864_cm.f90:19:0:

 end module

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1477
0x75a352 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1477
0x75e5b7 generate_local_decl
../../gcc/fortran/trans-decl.c:5327
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x75f412 generate_local_vars
../../gcc/fortran/trans-decl.c:5527
0x75f412 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6206
0x7331f9 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2164
0x6e72fd translate_all_program_units
../../gcc/fortran/parse.c:6025
0x6e72fd gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/72755] Internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1369

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #9 from Gerhard Steinmetz  
---
Reduced and simplified a bit more. Element "buffer" in "t_string"
is not needed to produce the ICE, thus commented out.


$ cat pr72755_c9.f90
module m72755
   type t_string
  ! character(len=:), allocatable :: buffer
   contains
  procedure :: string_assign_from_string
  generic :: assignment(=) => string_assign_from_string
   end type
   type t_msg
  type(t_string) :: text
   end type
contains
   subroutine string_assign_from_string( left, right )
  class(t_string), intent(inout) :: left
  type(t_string), intent(in) :: right
   end subroutine
   subroutine messages_push_back( array, msg )
  type(t_msg), allocatable, intent(inout) :: array(:)
  type(t_msg), intent(in) :: msg
  array(1) = msg   !!
   end subroutine
end module


$ gfortran-7-20161204 -c pr72755_c9.f90
pr72755_c9.f90:21:0:

 end module

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1477
0x75a352 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1477
0x75e5b7 generate_local_decl
../../gcc/fortran/trans-decl.c:5327
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x75f412 generate_local_vars
../../gcc/fortran/trans-decl.c:5527
0x75f412 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6206
0x7331f9 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2164
0x6e72fd translate_all_program_units
../../gcc/fortran/parse.c:6025
0x6e72fd gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #7 from James Greenhalgh  ---
That fixes my miscompilation, and the miscompilation of the library I reduced
the testcase from. Thanks.

[Bug middle-end/78700] [7 regression] gccgo testcases stack.go, recover.go, crypto/tls fails

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|go  |middle-end

--- Comment #3 from Eric Botcazou  ---
Recategorizing.

[Bug go/78700] [7 regression] gccgo testcases stack.go, recover.go, crypto/tls fails

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-12/msg00485.ht
   ||ml
 CC|ebotcazou at gcc dot gnu.org   |
   Assignee|ian at airs dot com|ebotcazou at gcc dot 
gnu.org
   Target Milestone|--- |7.0
Summary|gccgo testcases stack.go,   |[7 regression] gccgo
   |recover.go, crypto/tls  |testcases stack.go,
   |start failing with r241222  |recover.go, crypto/tls
   |on ppc64le  |fails

--- Comment #2 from Eric Botcazou  ---
The fix was just posted.

[Bug go/78700] gccgo testcases stack.go, recover.go, crypto/tls start failing with r241222 on ppc64le

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
> I don't recall the details of how closures work in gccgo but in one of my
> gdb debugging sessions the value in r11 looked suspicious.  I think there
> were some assumptions about r11.

Correct, r11 (the static chain register) is clobbered by a call to memcpy.

[Bug c++/78701] [6/7 Regression] ICE: unexpected expression N of kind template_parm_index

[vince.rev at gmail dot com]

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

--- Comment #3 from Vincent  ---
I am compiling with:
g++ test_bug.cpp -o test_bug
g++ -std=c++11 test_bug.cpp -o test_bug
g++ -std=c++14 test_bug.cpp -o test_bug
and it fails in the 3 cases.

[Bug c++/78693] [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-06
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r231349.

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #16 from James Greenhalgh  ---
Created attachment 40267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40267=edit
Proposed Patch

Would you mind testing the attached to see if it fixes your issue?

I've bootstrapped it on PowerPC myself without any problems, but that's not a
strong endorsement of the patch given that I've yet to reproduce your failure!

[Bug c++/78701] [6/7 Regression]ICE: unexpected expression N of kind template_parm_index

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-06
 CC||marxin at gcc dot gnu.org
Summary|Internal compiler error:|[6/7 Regression]ICE:
   |unexpected expression N of  |unexpected expression N of
   |kind template_parm_index|kind template_parm_index
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Both snippets started to be rejected (ICE) with r223301.
One has to use -std=c++11.

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[ienkovich at gcc dot gnu.org]

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

--- Comment #9 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #8)
> 
> MPX wrapper library doesn't call external functions with bounds
> and there is no need to use PLT to call internal functions within
> MPX wrapper library.

It doesn't explain why it doesn't work.

[Bug libstdc++/78702] [libstdc++] class __shim in locale::facet is private

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to AK from comment #0)
> In file: include/bits/locale_classes.h
> 371   class locale::facet
> 372   {
> ...
> 465 class __shim;
> 466
> 467 const facet* _M_sso_shim(const id*) const;
> 468 const facet* _M_cow_shim(const id*) const;
> 
> However in file: src/c++11/cxx11-shim_facets.cc
> numpunct_shim derives from facet::__shim which results in compilation error.

No it doesn't.

If you're using some non-default options or a non-GCC compiler to build
libstdc++ then it would be helpful to say so. Because that file builds fine
(probably due to one of GCC's bugs related to access checking in templates). 


> 227   namespace // unnamed
> 228   {
> 229 template
> 230   struct numpunct_shim : std::numpunct<_CharT>, facet::__shim
> 231   {
> 232 typedef typename numpunct<_CharT>::__cache_type __cache_type;
> 233
> 234 // f must point to a type derived from numpunct[abi:other]
> 235 numpunct_shim(const facet* f, __cache_type* c = new __cache_type)
> 236 : std::numpunct<_CharT>(c), __shim(f), _M_cache(c)
> 237 {
> 238   __numpunct_fill_cache(other_abi{}, f, c);
> 239 }
> 
> 
> What could be a possible fix here?

We can build that file with -fno-access-control if needed.

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
The bug behind the wrong output in comment #0 is in the format_floating
function with an unknown argument failing to use the precision.  The following
simple patch fixes that.

@@ -1261,9 +1277,9 @@ format_floating (const conversion_spec , int
res.range.min = 2 + (prec < 0 ? 6 : prec);

/* Compute the maximum just once.  */
-   static const int f_max[] = {
- format_floating_max (double_type_node, 'f'),
- format_floating_max (long_double_type_node, 'f')
+   const int f_max[] = {
+ format_floating_max (double_type_node, 'f', prec),
+ format_floating_max (long_double_type_node, 'f', prec)
};
res.range.max = width == INT_MIN ? HOST_WIDE_INT_MAX : f_max [ldbl];

@@ -1279,9 +1295,9 @@ format_floating (const conversion_spec , int
res.range.min = 2 + (prec < 0 ? 6 : prec);

/* Compute the maximum just once.  */
-   static const int g_max[] = {
- format_floating_max (double_type_node, 'g'),
- format_floating_max (long_double_type_node, 'g')
+   const int g_max[] = {
+ format_floating_max (double_type_node, 'g', prec),
+ format_floating_max (long_double_type_node, 'g', prec)
};
res.range.max = width == INT_MIN ? HOST_WIDE_INT_MAX : g_max [ldbl];

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Also does not reproduce with a debug compiler at r243219:

wschmidt@genoa:~/src$ $GCC_INSTALL/bin/gcc -S -O3 pr78695.c
wschmidt@genoa:~/src$ $GCC_INSTALL/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/wschmidt/gcc/install/gcc-mainline-test-debug/bin/gcc
COLLECT_LTO_WRAPPER=/home/wschmidt/gcc/install/gcc-mainline-test-debug/libexec/gcc/powerpc64le-unknown-linux-gnu/7.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /home/wschmidt/gcc/gcc-mainline-test/configure
--enable-languages=c,c++ --with-cpu=power8 --disable-multilib
--with-long-double-128
--prefix=/home/wschmidt/gcc/install/gcc-mainline-test-debug --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161203 (experimental) [trunk revision 243219] (GCC) 

I will try a bootstrap compiler.  Can you please post your configuration, and
any possible local modifications?  This looks like something that is very
sensitive to middle-end optimization, so small changes can make the problem
disappear.

[Bug libstdc++/78702] New: [libstdc++] class __shim in locale::facet is private

[hiraditya at msn dot com]

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

Bug ID: 78702
   Summary: [libstdc++] class __shim in locale::facet is private
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

In file: include/bits/locale_classes.h
371   class locale::facet
372   {
...
465 class __shim;
466
467 const facet* _M_sso_shim(const id*) const;
468 const facet* _M_cow_shim(const id*) const;

However in file: src/c++11/cxx11-shim_facets.cc
numpunct_shim derives from facet::__shim which results in compilation error.

227   namespace // unnamed
228   {
229 template
230   struct numpunct_shim : std::numpunct<_CharT>, facet::__shim
231   {
232 typedef typename numpunct<_CharT>::__cache_type __cache_type;
233
234 // f must point to a type derived from numpunct[abi:other]
235 numpunct_shim(const facet* f, __cache_type* c = new __cache_type)
236 : std::numpunct<_CharT>(c), __shim(f), _M_cache(c)
237 {
238   __numpunct_fill_cache(other_abi{}, f, c);
239 }


What could be a possible fix here?

[Bug c++/78701] Template deduction, dependent template and conversion to bool failure

[vince.rev at gmail dot com]

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

--- Comment #1 from Vincent  ---
Addition:
==
#include 
template  T f(T x) {return T();}
int main(int argc, char* argv[]) {return f(42);}
==
(without the N + 1)
returns:
==
test_bug.cpp: In substitution of ‘template T f(T) [with T
= int; T N = ; bool B = ]’:
test_bug.cpp:3:46:   required from here
test_bug.cpp:2:40: internal compiler error: unexpected expression ‘N’ of kind
template_parm_index
 template  T f(T x) {return T();}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
==

[Bug c++/78701] New: Template deduction, dependent template and conversion to bool failure

[vince.rev at gmail dot com]

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

Bug ID: 78701
   Summary: Template deduction, dependent template and conversion
to bool failure
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vince.rev at gmail dot com
  Target Milestone: ---

The following code fails to compile on g++ 6.1, 6.2, and 7 (and I guess on g++
6.0):
==
#include 
template  T f(T x) {return T();}
int main(int argc, char* argv[]) {return f(42);}
==

It returns the following error:
==
test_bug.cpp: In function ‘int main(int, char**)’:
test_bug.cpp:3:46: error: no matching function for call to ‘f(int)’
 int main(int argc, char* argv[]) {return f(42);}
  ^
test_bug.cpp:2:49: note: candidate: template T f(T)
 template  T f(T x) {return T();}
 ^
test_bug.cpp:2:49: note:   template argument deduction/substitution failed:
test_bug.cpp:2:42: error: invalid use of template type parameter ‘T’
 template  T f(T x) {return T();}
~~^~~
test_bug.cpp:2:44: error: could not convert template argument ‘’ to ‘bool’
 template  T f(T x) {return T();}
^
==

[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler

[vehre at gcc dot gnu.org]

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

--- Comment #1 from vehre at gcc dot gnu.org ---
Created attachment 40266
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40266=edit
Patch fixing (1) and (2) of the list in the description.

Hi Dominique,

I have not (yet) been able to make an instrumented gfortran.

But from your description I could fix (1) and (2) by looking at the code.
Attached patch also fixes some formating.

- Andre

[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
The radix character is not a POSIX extension.  See the C11 7.1.1#2: "The 
decimal-point character is the character used by functions that convert 
floating-point numbers to or from character sequences to denote the 
beginning of the fractional part of such character sequences. 180) It is 
represented in the text and examples by a period, but may be changed by 
the setlocale function." (that wording dates back to C90).  It's grouping, 
indicated by the ' flag, that's a POSIX extension.

I tend to agree that this option is not yet ready to enable by default.  
It also risks introducing buffer overruns on systems where printf doesn't 
quite follow the standard interpretation followed by the implementation of 
the option.  (E.g. some versions of Windows printf functions always use a 
3-digit exponent even when standard C would require a 2-digit exponent.  
Do you allow for that?)

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
Fixed on trunk. Closing

[Bug go/78700] New: gccgo testcases stack.go, recover.go, crypto/tls start failing with r241222

[boger at us dot ibm.com]

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

Bug ID: 78700
   Summary: gccgo testcases stack.go, recover.go, crypto/tls start
failing with r241222
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: boger at us dot ibm.com
CC: cmang at google dot com
  Target Milestone: ---

There are 3 failures in the gccgo testcases starting with commit 241222.  I
built with 241215 and none of these tests failed there, and the two between are
simple and relate to fortran and sparc.

In the go tests for gcc, stack.go failure looks like this:

bad func 21 at level 8000
panic: fail

goroutine 16 []:
__go_panic
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/runtime/go-panic.c:110main.recur
   
/home/boger/gccgo.work/trunk/src/gcc/testsuite/go.test/test/stack.go:87main.main
   
/home/boger/gccgo.work/trunk/src/gcc/testsuite/go.test/test/stack.go:99FAIL:
go.test/test/stack.go execution,  -O2 -g
testcase /home/boger/gccgo.work/trunk/src/gcc/testsuite/go.test/go-test.exp
completed in 1 seconds

recover.go:

panic: 13
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0xa]

goroutine 16 [running]:
__go_panic
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/runtime/go-panic.c:110__go_panic
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/runtime/go-panic.c:66main.test13reflect2
   
/home/boger/gccgo.work/trunk/src/gcc/testsuite/go.test/test/recover.go:456main.main
   
/home/boger/gccgo.work/trunk/src/gcc/testsuite/go.test/test/recover.go:58
goroutine 18 [finalizer wait]:

Also, libgo testcase crypto/tls starts failing with this commit as well:
unexpected fault address 0xc02f00010313
fatal error: fault
[signal 0xb code=0x1 addr=0xc02f00010313]

goroutine 77 [running]:
runtime_dopanic
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/runtime/panic.c:133runtime_throw
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/runtime/panic.c:195sig_panic_info_handler
/home/boger/gccgo.work/trunk/bld/../src/libgo/runtime/go-signal.c:296
:0tls.$nested12
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/handshake_client_test.go:755tls.$nested3
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/handshake_client_test.go:370
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/handshake_client_test.go:273kickoff
/home/boger/gccgo.work/trunk/bld/../src/libgo/runtime/proc.c:257created
by crypto_tls.run.pN21_crypto_tls.clientTest
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/handshake_client_test.go:302
+828

goroutine 16 [chan receive]:
testing.Run.pN9_testing.T
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/testing/testing.go:646testing.$nested9
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/testing/testing.go:792testing.tRunner
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/testing/testing.go:609testing.RunTests
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/testing/testing.go:790testing.Run.pN9_testing.M
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/testing/testing.go:742main.main
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/_testmain.go:109
goroutine 18 [finalizer wait]:

goroutine 20 [syscall]:
goroutine in C code; stack unavailable

goroutine 76 [semacquire]:
sync.runtime_notifyListWait
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/runtime/sema.go:271sync.Wait.pN9_sync.Cond
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/sync/cond.go:57io.read.pN7_io.pipe
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/io/pipe.go:47io.Read.pN13_io.PipeReader
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/io/pipe.go:129io.ReadAtLeast
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/io/io.go:307io.ReadFull
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/io/io.go:325crypto_tls.run.pN21_crypto_tls.clientTest
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/handshake_client_test.go:387tls.runClientTestForVersion
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/handshake_client_test.go:428tls.runClientTestTLS12
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/handshake_client_test.go:440crypto_tls.TestHandshakClientSCTs
   
/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/gotest16088/test/handshake_client_test.go:770testing.tRunner
   
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/testing/testing.go:609created
by testing.Run.pN9_testing.T
/home/boger/gccgo.work/trunk/bld/../src/libgo/go/testing/testing.go:645
+660

[Bug preprocessor/78680] [7 Regression] ICE in get_substring_ranges_for_loc, at input.c:1398

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The failed assertion in get_substring_ranges_for_loc:

  gcc_assert (line_width >= (start.column - 1 + literal_length));

suggests that the code assumes the entire literal is on the same line (i.e.,
contains no escaped newlines).  Removing the assertion avoids the ICE but I'm
not familiar enough with the code to even guess if that's a viable fix or if it
would just delay the symptom of the bug.  David will know for sure.

[Bug c/78657] Using macro with _Pragma gives error: '#pragma' is not allowed here

[jquinsey at entrenet dot com]

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

--- Comment #2 from Joseph Quinsey  ---
The code

   int foo =
   #pragma GCC diagnostic push
42;

gives exactly the same error messages. So this report is not about _Pragma per
se, but about #pragma.

But I cannot see where or if the standard addresses this. N1570 section
5.1.1.2, Translation phases, item 4 seems to say "All preprocessing directives
are then deleted".

Other preprocessor directives on the second line, such as

   int foo =
   #define BAR bar
42;

are perfectly fine in gcc/g++ (including #include).

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Dec  6 17:13:31 2016
New Revision: 243308

URL: https://gcc.gnu.org/viewcvs?rev=243308=gcc=rev
Log:
2016-12-06  Jerry DeLisle  

PR fortran/78659
* resolve.c (resolve_fl_namelist): Remove unneeded error.
PR fortran/78659
* gfortran.dg/alloc_comp_constraint_1.f90: Update test.
* gfortran.dg/alloc_comp_constraint_7.f90: New test.
* gfortran.dg/namelist_34.f90: Update test.
* gfortran.dg/namelist_63.f90: Update test.

Added:
trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_1.f90
trunk/gcc/testsuite/gfortran.dg/namelist_34.f90
trunk/gcc/testsuite/gfortran.dg/namelist_63.f90

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
The offending line appears to be

  rtx_insn *and_insn = DF_REF_INSN (base_def_link->ref);

which would seem to indicate an inconsistency in the dataflow information at
this point.  It would be good to be able to reproduce this...

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Yeah, I can't reproduce this either (r243264).  Do you have local
modifications?

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez  ---
FWIW, I can't reproduce on my ppc64le linux box:

$ ./xgcc -B./ -c b.i -O3$ ./xgcc -B./ -c b.i -O3
$

[Bug c++/78690] [7 Regression] ICE in cxx_incomplete_type_diagnostic, at cp/typeck2.c:552

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
This ICE happens because we arrive in cxx_incomplete_type_diagnostic with type
== global type, which is a LANG_TYPE:
 545 case LANG_TYPE:
 546   if (type == init_list_type_node)
 547 {
 548   emit_diagnostic (diag_kind, loc, 0,
 549"invalid use of brace-enclosed initializer
list");
 550   break;
 551 }
 552   gcc_assert (type == unknown_type_node);

and we crash on the assert.  Now, we've gotten there because since r236221 "a"
in this testcase

struct a;
template  class c {
  using b::a;
  void d() { a. }
};

isn't considered a dependent object anymore, so we go to complete_type_or_else
in cp_parser_postfix_dot_deref_expression.  Not sure if it should be.

[Bug fortran/78226] Fill out location information everywhere

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from vehre at gcc dot gnu.org ---
Assigning just to make sure it gets processed and no one wastes time on a pr
that is nearly fixed.

[Bug tree-optimization/78699] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu (memory-hog)

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|target  |tree-optimization

--- Comment #1 from Bill Schmidt  ---
Moving to tree-optimization, SLP vectorizer issue.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #27 from Bernd Schmidt  ---
Thread with discussion is here. The patch got stalled because we don't
understand the bootstrap failure.

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00421.html