[Bug c/78875] New: -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

[benh at kernel dot crashing.org]

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

Bug ID: 78875
   Summary: -fstack-protector on powerpc64 now always use TLS,
won't work for kernel/firmware
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benh at kernel dot crashing.org
  Target Milestone: ---

Some standalone (not linked with glibc) programs such as the Linux Kernel
or the OPAL firmware do not have a TLS per-se. They use r13 for different
purposes (both examples here use it as some kind of per-cpu pointer).

Depending on gcc version and how it was built, the canary used by
-fstack-protector on powerpc64 is either loaded from a global (r2 relative) or
from the TLS (r13).

The latter case won't work for those programs. I looked into doing like x86 and
basically maintaining an equivalent of that portion of the TLS space for this,
but the offset used -0x7000 really doesn't work with either Linux or OPAL
without major changes to how they use r13.

In the meantime, it would be useful to still be able to exploit the stack
protector, to be able to force via a gcc command line option, the use of
globals instead of TLS (and in general disable any built-in access to the TLS
for projects that have a special runtime environment that doesn't use r13 for
that purpose).

[Bug c++/78749] [7 Regression] bogus warning for friend member function in anonymous namespace

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/78767] [7 Regression] ICE when inheriting constructor of base class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #21 from Peter Bergner  ---
(In reply to Peter Bergner from comment #20)
> Vlad, for the following change in the hunk above:
> 
> >   new_reg != NULL_RTX ? sreg : src,
> 
> shouldn't that always be just "sreg"?  Ie, why are we testing for new_reg !=
> NULL_RTX and sometimes passing in "src"?

Well we still ICE even with that, so this will take more digging.

[Bug c/78874] New: Manual describes "-Wno-aggressive-loop-optimizations" as if without "no-"

[jzwinck at gmail dot com]

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

Bug ID: 78874
   Summary: Manual describes "-Wno-aggressive-loop-optimizations"
as if without "no-"
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jzwinck at gmail dot com
  Target Milestone: ---

The gcc and g++ man pages say:

-Wno-aggressive-loop-optimizations
Warn if in a loop with constant number of iterations the compiler detects
undefined behavior in some statement during one or more of the iterations. 

The "no-" here is a mistake: -Waggressive-loop-optimizations enables the
message and -Wno-* turns it off.

Demo: https://godbolt.org/g/1ICxI5

[Bug c/77767] [5/6/7 Regression] Side-effect from VLA array parameters lost

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 21 00:07:49 2016
New Revision: 243832

URL: https://gcc.gnu.org/viewcvs?rev=243832=gcc=rev
Log:
PR c/77767
* c-decl.c (grokdeclarator): If *expr is non-NULL, append expression
to *expr instead of overwriting it.

* gcc.c-torture/execute/pr77767.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr77767.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #20 from Peter Bergner  ---
(In reply to Peter Bergner from comment #19)
>   emit_insn (GEN_FCN (sri.icode) (new_reg != NULL_RTX ? new_reg : dest,
>   new_reg != NULL_RTX ? sreg : src,
>   scratch_reg));
> }
[snip]
> That subreg for operand1 does not look correct to me.


Vlad, for the following change in the hunk above:

>   new_reg != NULL_RTX ? sreg : src,

shouldn't that always be just "sreg"?  Ie, why are we testing for new_reg !=
NULL_RTX and sometimes passing in "src"?

[Bug c++/78873] New: Virtual call after conversion to base class pointer is not devirtualized

[ambrop7 at gmail dot com]

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

Bug ID: 78873
   Summary: Virtual call after conversion to base class pointer is
not devirtualized
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ambrop7 at gmail dot com
  Target Milestone: ---

The following test case shows the issue. The generated code for
TestDevirtualization could perform a direct call to Impl::Foo but it
performs a call via the vtable.

#include 

struct Iface {
virtual void Foo() = 0;
};

struct Impl : public Iface {
__attribute__ ((noinline))
void Foo() override final
{
printf("Impl::Foo\n");
}
};

template 
__attribute__ ((noinline))
void TestDevirtualuzation(Type *obj)
{
static_cast(obj)->Foo();
}

int main() {
Impl impl;
TestDevirtualuzation();
return 0;
}

I have heard arguments that optimizing this would not be legal, with the
following test case which supposedly might be valid:

struct Liar : Iface {
  void Foo() {}
};

Impl impl;
TestDevirtualuzation(reinterpret_cast());

But I think it is not valid; the result of the reinterpret_cast does not point
to a Liar object, so the static_cast done in TestDevirtualuzation *should* be
invalid. I couldn't find a clear statement in the standard about this though.

[Bug libstdc++/71444] Error constants for MinGW-w64

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
In fact it looks like the patch should work for mingw-w64 v4, and maybe v3 too.

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jan Niklas Hasse from comment #2)
> I'm willing to help.

Great! Please read
https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html
especially the part about legal paperwork.

> Is there an existing starting point for Windows? Can
> boost::filesystem's implementation be used?

No. Just look at the existing code and figure out what the equivalent code
would be for Windows, and write an alternative implementation e.g. replace
calls to POSIX stat() with whatever Windows uses to query file properties, and
replace calls to POSIX chmod with whatever Windows uses to change file
permissions.

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Presumably you had a local variable 'icase' in your function, because you
wouldn't get a diagnostic saying "shadows a parameter" for a global variable.
That's impossible.

It's an error if the local variable is in the outermost block of the function,
because it declares two variables of the same name in the same scope:

void find_vsizet(bool icase=false)
{
bool icase = false;  // error
{
bool icase = false;  // ok here, only a warning
}
}

[Bug c++/78872] g++ refuses const trailing a function declaration.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
You can't just declare new functions of std::locale, that  type is controlled
by the standard library, not by you.

Please stop filing bugs here until you learn basic C++.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #19 from Peter Bergner  ---
(In reply to Peter Bergner from comment #18)
> With the patch Vlad attached minus the one unwanted line/typo, I'm getting
> an ICE on a powerpc64le-linux bootstrap.  Looking into it.

Here's a minimal test case:

bergner@genoa:~/gcc/BUGS/PR78516$ cat libgcc2.i
float
fn1 (__int128 a)
{
  if ((unsigned)a == a)
return a;
}
bergner@genoa:~/gcc/BUGS/PR78516$
/home/bergner/gcc/build/gcc-fsf-mainline-pr78516/./gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr78516/./gcc/ -O2 -S libgcc2.i 
libgcc2.i: In function ‘fn1’:
libgcc2.i:6:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:965
 }
 ^
0x10a8eaaf lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:963

We have the following insn after IRA:

(insn 13 12 31 4 (set (reg:SF 157 [  ])
(float:SF (subreg:DI (reg/v:TI 158 [ aD.2516 ]) 0))) "libgcc2.i":5 407
{floatdisf2_fcfids}
 (expr_list:REG_DEAD (reg/v:TI 158 [ aD.2516 ])
(nil)))

With pseudo 157 being assigned to fp reg fr1 and pseudo 158 being assigned to
r3.  The floatdisf2_fcfids pattern looks like:

(define_insn "floatdisf2_fcfids"
  [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wy")
(float:SF (match_operand:DI 1 "gpc_reg_operand" "d,wi")))]
  "TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_SINGLE_FLOAT
   && TARGET_DOUBLE_FLOAT && TARGET_FCFIDS"
  "@
   fcfids %0,%1
   xscvsxdsp %x0,%x1"
  [(set_attr "type" "fp")])

...so pseudo 158 does not match the pattern's constraints. 
check_and_process_move() doesn't handle this type of insn, so it returns false
and eventually, we generate the following two insns (haven't tracked down where
they come from yet):

(insn 38 12 13 4 (set (reg:DI 165)
(subreg:DI (reg/v:TI 158 [ a ]) 0)) "libgcc2.i":5 582
{*movdi_internal64}
 (nil))

(insn 13 38 31 4 (set (reg:SF 157 [  ])
(float:SF (reg:DI 165))) "libgcc2.i":5 407 {floatdisf2_fcfids}
 (expr_list:REG_DEAD (reg/v:TI 158 [ a ])
(nil)))

This maybe looks ok (?), except for the REG_DEAD on insn 13 should have been
removed and added to the new insn 38.

Later, check_and_process_move() is called again, this time for the new insn 38
and this is where we end up ICEing.  We end up seeing:

(gdb) pr dest
(reg:DI 165)
(gdb) pr dreg
(reg:DI 165)
(gdb) p dclass
$54 = FLOAT_REGS
(gdb) p dregno
$55 = 165

(gdb) pr src
(subreg:DI (reg/v:TI 158 [ a ]) 0)
(gdb) pr sreg
(reg/v:TI 158 [ a ])
(gdb) p sregno
$56 = -1
(gdb) p sclass
$57 = BASE_REGS

(gdb) p secondary_class 
$58 = NO_REGS

Due to the above, new_reg == NULL_RTX and sri.icode ==
CODE_FOR_reload_vsx_from_gprti.  This pushes us down the else clause of the
following if:

  if (sri.icode == CODE_FOR_nothing)
lra_emit_move (new_reg, sreg);
  else
{
  enum reg_class scratch_class;

  scratch_class = (reg_class_from_constraints
   (insn_data[sri.icode].operand[2].constraint));
  scratch_reg = (lra_create_new_reg_with_unique_value
 (insn_data[sri.icode].operand[2].mode, NULL_RTX,
  scratch_class, "scratch"));
  emit_insn (GEN_FCN (sri.icode) (new_reg != NULL_RTX ? new_reg : dest,
  new_reg != NULL_RTX ? sreg : src,
  scratch_reg));
}

We then up calling gen_reload_vsx_from_gprti() via the emit_insn() with:
op0, op1 and op2 as:

(gdb) pr operand0
(reg:DI 165)
(gdb) pr operand1
(subreg:DI (reg/v:TI 158 [ a ]) 0)
(gdb) pr operand2
(reg:IF 166)

That subreg for operand1 does not look correct to me.

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

[jmichae3 at yahoo dot com]

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

--- Comment #6 from Jim Michaels  ---
(In reply to Nathan Sidwell from comment #4)
> sigh, bugzilla's moving on to 'random' other bug gets me.  Again.

btw, I think that random bug number feature is in preferences.

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

[jmichae3 at yahoo dot com]

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

--- Comment #5 from Jim Michaels  ---
I am going to have to go digging through my code. the function that I had this
error on about icase shadowing a parameter was a global var, and I tried
#include 
#include 
#include 
bool icase=false;
std::vector find_vsizet(std::string haystack, std::string needle, bool
icase=false, size_t pos=0){
return {0};
}
int main(){
std::vector vst=find_vsizet("1","2",false,0);
for (int i=0; i < vst.size(); i++) {
std::cout<

[Bug c++/78872] g++ refuses const trailing a function declaration.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-20
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
I don't see why you think this is a bug.  There is no function called
std::locale::icompare in the declared class std::locale.  This is what the
error message exactly says even.

[Bug other/52192] GCC_CHECK_TLS doesn't detect native TLS on Solaris 8/9

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Should we change the target to *-*-netbsd* now that solaris 8 and 9 are not
supported?

[Bug c++/78872] g++ refuses const trailing a function declaration.

[jmichae3 at yahoo dot com]

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

--- Comment #1 from Jim Michaels  ---
icompare.cpp:12:119: error: no 'int std::locale::icompare(const char_type*,
const char_type*, const char_type*, const char_type*) const' member function
declared in class 'std::locale'
 int locale::icompare(const char_type* low1, const char_type* high1, const
char_type*low2, const char_type* high2) const;
   
   ^

[Bug c++/78872] New: g++ refuses const trailing a function declaration.

[jmichae3 at yahoo dot com]

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

Bug ID: 78872
   Summary: g++ refuses const trailing a function declaration.
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmichae3 at yahoo dot com
  Target Milestone: ---

#include 
#include 
#include 
#include 
namespace std {
int locale::icompare(const char_type* low1, const char_type* high1, const
char_type*low2, const char_type* high2) const;
};

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #18 from Peter Bergner  ---
With the patch Vlad attached minus the one unwanted line/typo, I'm getting an
ICE on a powerpc64le-linux bootstrap.  Looking into it.

/home/bergner/gcc/gcc-fsf-mainline-pr78516/libgcc/libgcc2.c: In function
‘__floatuntisf’:
/home/bergner/gcc/gcc-fsf-mainline-pr78516/libgcc/libgcc2.c:1819:1: internal
compiler error: in lra_set_insn_recog_data, at lra.c:965
 }
 ^
0x10a8eaaf lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:963
0x10a8b8d7 lra_get_insn_recog_data
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra-int.h:487
0x10a9142f lra_update_insn_regno_info(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1585
0x10a91e4f lra_push_insn_1
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1736
0x10a91eb3 lra_push_insn(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1744
0x10a92113 push_insns
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1787
0x10a92447 lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1835
0x10aa7ecb check_and_process_move
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra-constraints.c:1261
0x10ab11f3 curr_insn_transform
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra-constraints.c:3709
0x10ab5bf3 lra_constraints(bool)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra-constraints.c:4705
0x10a9435b lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:2377
0x10a0fb2f do_reload
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/ira.c:5400
0x10a10363 execute
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/ira.c:5584

[Bug target/70568] [5/6/7 regression] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Known to work||4.8.5
  Known to fail||4.9.4, 5.4.1, 6.2.1, 7.0

--- Comment #7 from Michael Meissner  ---
I noticed this bug and created PR 78823.  Since that's the same bug as this,
I'll take it.

[Bug target/78823] Poor code on PowerPC when moving SFmode values between GPRs and vector registers

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Michael Meissner  ---
This bug is a duplicate of 70568.

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

[Bug target/70568] [5/6/7 regression] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  ---
*** Bug 78823 has been marked as a duplicate of this bug. ***

[Bug c/77767] [5/6/7 Regression] Side-effect from VLA array parameters lost

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Unfortunately that version breaks the pr49120.c testcase, because mark_exp_read
doesn't deal with STATEMENT_LISTs.  I'll test the other patch.

[Bug c/77754] [5/6/7 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
On Tue, 20 Dec 2016, jakub at gcc dot gnu.org wrote:

> So, where would be the best place to remove the VLA bounds from parameters of
> fn declarations?  Some function called from c_write_global_declarations_1 and
> from walking BLOCK tree vars e.g. right before calling c_genericize in
> finish_function?

That would seem reasonable.

[Bug c/77767] [5/6/7 Regression] Side-effect from VLA array parameters lost

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
I think the append_to_statement_list version should be preferred.

[Bug debug/78871] Anonymous namespace and -flto -gsplit-dwarf: ICE in lhd_decl_printable_name, at langhooks.c:215

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[joseph at codesourcery dot com]

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

--- Comment #17 from joseph at codesourcery dot com  ---
On Tue, 20 Dec 2016, bergner at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
> 
> --- Comment #16 from Peter Bergner  ---
> (In reply to Vladimir Makarov from comment #15)
> > Sorry, I applied your changes manually and did a typo.  The line
> > 
> > SET_SRC (curr_insn_set) = new_reg;
> > 
> > should be removed.
> > 
> > I tested this patch with the typo on x86-64 and no new failures occurred. 
> > Strange.
> 
> That would suggest on x86-64, SET_SRC (curr_insn_set) is never a subreg for 
> the
> insns that we process here.  As they say, better to be lucky than good! :-) 
> With the SPE, we're just not lucky as shown by Joseph's last run.  I'm sure it
> will pass after removing the unwanted line above.

With this fix, my build completes OK and the number of FAILs is down from 
105 to 62 in g++.sum and from 246 to 188 in gcc.sum (again, this is a 
rough comparison with a build from a month ago rather than an exact 
comparison against unmodified current mainline).

[Bug debug/78871] New: Anonymous namespace and -flto -gsplit-dwarf: ICE in lhd_decl_printable_name, at langhooks.c:215

[trippels at gcc dot gnu.org]

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

Bug ID: 78871
   Summary: Anonymous namespace and -flto -gsplit-dwarf: ICE in
lhd_decl_printable_name, at langhooks.c:215
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

All supported gcc versions are affected:


markus@x4 ~ % cat Util.ii
namespace {
void foo() {}
}

markus@x4 ~ % g++ -flto -gsplit-dwarf Util.ii
Util.ii: In function ‘foo’:
Util.ii:2:13: internal compiler error: in lhd_decl_printable_name, at
langhooks.c:215
 void foo() {}
 ^
0x8eec74 lhd_decl_printable_name(tree_node*, int)
/home/markus/gcc/gcc/langhooks.c:215
0x6ffa74 gen_namespace_die
/home/markus/gcc/gcc/dwarf2out.c:25009
0x6ffa74 gen_decl_die
/home/markus/gcc/gcc/dwarf2out.c:25215
0x70078e dwarf2out_decl
/home/markus/gcc/gcc/dwarf2out.c:25628
0x706c2f force_decl_die
/home/markus/gcc/gcc/dwarf2out.c:24847
0x706de5 declare_in_namespace
/home/markus/gcc/gcc/dwarf2out.c:24947
0x700127 declare_in_namespace
/home/markus/gcc/gcc/dwarf2out.c:24918
0x700127 gen_decl_die
/home/markus/gcc/gcc/dwarf2out.c:25116
0x70078e dwarf2out_decl
/home/markus/gcc/gcc/dwarf2out.c:25628
0x700cde dwarf2out_function_decl
/home/markus/gcc/gcc/dwarf2out.c:25643
0x7762ef rest_of_handle_final
/home/markus/gcc/gcc/final.c:4506
0x7762ef execute
/home/markus/gcc/gcc/final.c:4548
Please submit a full bug report,

[Bug other/78808] target_clones not applying to openmp functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The thing is that the pass_dispatcher_calls runs quite late, as late IPA pass,
while the OpenMP outlining is done far earlier.  So, we'd need some cgraph node
bit to represent OpenMP/OpenACC/Cilk+ outlined functions, and in
multiple_targets.c look at the cgraph edges from the functions we are cloning,
find out what outlined functions from itself it calls and attempt to clone them
too, plus adjust the cloned function to use them instead.  Though they are
actually called indirectly, so probably there aren't any cgraph edges and we'd
have to find it through other means.

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

[toconnor at forcepoint dot com]

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

--- Comment #10 from Tom O'Connor  ---
In regards to GDB, I noticed that when using a macro to get the offset for
these bitfields, with objects built by both GCC 5 and earlier as well as GCC 6,
I always get 0.  For example:

(gdb) macro define offsetof(t, f) &((t *) 0)->f)
(gdb) p offsetof(struct s, type)
$1 = (unsigned int *) 0x0

Historically, prior to GCC 6, this always matched up with DWARF's
DW_AT_data_member_location value for bitfields.  Yes, I see how GCC 6's
combination of data_member_location and bit_offset can be combined to reach the
true location.  Historically, my use case has used the data_member_location
value to get me the offset into say a raw memory image, for where to start
reading data from a field of a structure in memory; I'd do bitfield shifts
after reading from the aligned offset as reported in the DWARF structure.

If using DECL_BIT_FIELD_REPRESENTATIVE as data_member_location is nicer and
doesn't break the Ada use case, I'd be all for that.  But if what's currently
being emitted by GCC 6 is considered "more correct" than what previous versions
had emitted, then I'll have to adjust.  I only noticed the change between 5 and
6 once I started seeing odd results with the same code built by different GCCs.

[Bug c++/72764] [5/6/7 Regression] ICE on invalid C++11 code instantiating an alias template: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in typedef_variant_p, at tree.c:12660

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Seems both make_typename_type and finish_decltype_type can return
error_mark_node even if the arguments passed to those aren't error_mark_node
(as they are called tf_none, no diagnostics is emitted).
The question is what strip_typedefs should do if that happens?  Shall it return
error_mark_node, or the original type, something different?  The end of the
function assumes that result is a valid type.

[Bug rtl-optimization/78751] [7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn) w/ -Os -misel

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Created attachment 40383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40383=edit
patch

I use this patch as workaround.  It, well, sucks.  But it does work.

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[paul.hua.gm at gmail dot com]

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

--- Comment #5 from Paul Hua  ---
(In reply to Paul Hua from comment #4)

> 
> Maybe the r242326 cause the bug, the r242324 build success.
>
The r242326 and r242324 has another bug that r242522 fixed. If use r242326 to
reproduce this bug, you should patched the r242522.

[Bug tree-optimization/71563] [6/7 Regression] Regression in GCC-7.0.0's optimizer.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 40382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40382=edit
gcc7-pr71563.patch

Untested fix.

[Bug c++/78861] sequencer.cpp:603:53: error: cannot convert 'std::basic_istream::__istream_type {aka std::basic_istream}' to 'bool' in assignment

[martin.gansser at gmail dot com]

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

--- Comment #6 from mgansser at alice dot de  
---
(In reply to Markus Trippelsdorf from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > No, that will convert the stream to a bool then try to bitshift it.
> > 
> > It should be:
> > 
> >result = bool( iss >> t.duration >> t.width );
> 
> Yeah, sorry.

fine, compiles now w/o problems.

Danke

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #3 from Bernd Schmidt  ---
Looks like if_then_else_cond manages to return a false_rtx identical to the
original one, and we try to simplify it again.

[Bug c++/78861] sequencer.cpp:603:53: error: cannot convert 'std::basic_istream::__istream_type {aka std::basic_istream}' to 'bool' in assignment

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Jonathan Wakely from comment #4)
> No, that will convert the stream to a bool then try to bitshift it.
> 
> It should be:
> 
>result = bool( iss >> t.duration >> t.width );

Yeah, sorry.

[Bug c++/78861] sequencer.cpp:603:53: error: cannot convert 'std::basic_istream::__istream_type {aka std::basic_istream}' to 'bool' in assignment

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
No, that will convert the stream to a bool then try to bitshift it.

It should be:

   result = bool( iss >> t.duration >> t.width );

[Bug driver/78863] [6/7 Regression] error on -fsanitize suggests invalid -fsanitize=all

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 40381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40381=edit
Untested patch

Bit-Fields Impact on Stack Pointer or Stack Size

[Sridhar]

Hello,

I am using BIT Fields in my program with powerPC target and when I am trying
check stack usage I see some strange values for the stack pointer.

typedef struct sample_type{

unsigned int var1 : 2;
unsigned int var2 : 2;
unsigned int var3 : 2;
unsigned int var4 : 2;
unsigned int var5 : 2;
unsigned int var6 : 2;
unsigned int var7 : 2;
unsigned int var8 : 2;

}sample;


..

typedef struct sample1_type{

sample myvariable;
...
..

}sample1;


The variable created with type sample1 impacting lot to the stack size. I
did disassemble of the object file and checked the stwu instruction will be
having huge value in the function where the variable of structure having bit
fields is used and variable is not function scope.

If remove bit fields then stwu will have very less value for updating the
stack pointer. 

So my question is how does the Bit fields impacts the stack memory in a
function?? 

Note, I have ensure that bit fields structure is word aligned 





--
View this message in context: 
http://gcc.1065356.n8.nabble.com/Bit-Fields-Impact-on-Stack-Pointer-or-Stack-Size-tp1333667.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug c++/78861] sequencer.cpp:603:53: error: cannot convert 'std::basic_istream::__istream_type {aka std::basic_istream}' to 'bool' in assignment

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to mgans...@alice.de from comment #2)
> (In reply to Markus Trippelsdorf from comment #1)
> > https://gcc.gnu.org/gcc-6/porting_to.html
> 
> I am not a software developer, could you please tell me, where can i get
> help ?

Well, just read the porting_to page. It explicitly addresses your issue.

instead of:
   result = ( iss >> t.duration >> t.width );
use:
   result = ( (bool)iss >> t.duration >> t.width );

[Bug c++/78861] sequencer.cpp:603:53: error: cannot convert 'std::basic_istream::__istream_type {aka std::basic_istream}' to 'bool' in assignment

[martin.gansser at gmail dot com]

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

--- Comment #2 from mgansser at alice dot de  
---
(In reply to Markus Trippelsdorf from comment #1)
> https://gcc.gnu.org/gcc-6/porting_to.html

I am not a software developer, could you please tell me, where can i get help ?

[Bug c++/72707] [5/6/7 regression] local anonymous union member hides names in the same scope

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/71827] [5/6/7 Regression] ICE on invalid C++11 code with non constant diff between two labels

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
__INTPTR_TYPE__
foo () 
{
  m: n: constexpr __INTPTR_TYPE__ a = ((__INTPTR_TYPE__) & -
(__INTPTR_TYPE__) &) + 23;
  return a;
}

compiles fine, so it is considered an integral constant expression that just
doesn't fold into an INTEGER_CST.  For the template parameter we need an
INTEGER_CST (I bet in various other cases).

constexpr int
foo (const int *a)
{
  m: n: constexpr __INTPTR_TYPE__ b = ((__INTPTR_TYPE__) & -
(__INTPTR_TYPE__) &) + 23;
  return a[b];
}

const int c[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
constexpr int d = foo (c);

is rejected though:
pr71827-4.C:9:23:   in constexpr expansion of ‘foo(((const int*)(& c)))’
pr71827-4.C:5:13: error: ‘(((long unsigned int)long int)(&& n)) - ((long
int)(&& m))) + 23)) * 4)’ is not a constant expression
   return a[b];
 ^

clang++ rejects all of these.
So perhaps replace the assert with an error message if the expression is not
INTEGER_CST?

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[paul.hua.gm at gmail dot com]

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

--- Comment #4 from Paul Hua  ---
The r243817 still build failure.


configure:3460: /home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/xgcc
-B/home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/
-B/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/bin/
-B/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/lib/
-isystem
/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/include
-isystem
/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/sys-include
   -o conftest -g -O2 -minterlink-mips16   conftest.c  >&5
conftest.c: In function 'main':
conftest.c:11:1: error: unrecognizable insn:
 main ()
 ^~~~
(insn 2 0 0 (set (reg:TI 64 lo) 
(const_int 0 [0])) "conftest.c":12 -1
 (nil))
conftest.c:11:1: internal compiler error: in internal_dfa_insn_code, at
config/mips/mips.md:764
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3463: $? = 1 
configure:3651: checking for suffix of object files
configure:3673: /home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/xgcc
-B/home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/
-B/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/bin/
-B/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/lib/
-isystem
/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/include
-isystem
/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/sys-include
   -c -g -O2 -minterlink-mips16  conftest.c >&5
conftest.c: In function 'main':
conftest.c:11:1: error: unrecognizable insn:
 main ()
 ^~~~
(insn 2 0 0 (set (reg:TI 64 lo)
(const_int 0 [0])) "conftest.c":12 -1
 (nil))
conftest.c:11:1: internal compiler error: in internal_dfa_insn_code, at
config/mips/mips.md:764
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3677: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/;
| /* end confdefs.h.  */
|
| int  
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3691: error: in
`/home/xuchenghua/GCC/test/gcc-r243817_obj/mips64el-unknown-linux/libgcc':
configure:3694: error: cannot compute suffix of object files: cannot compile
-

Maybe the r242326 cause the bug, the r242324 build success.

[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Actually disabling reassoc is enough to "fix" it, the patch itself is not
needed,
fixed by VRP then (which also folds stmts and knows the  trick).

[Bug c++/71821] [5/6/7 regression] ICE on invalid C++11 code (incorrect argument for alignas): unexpected expression ‘f’ of kind template_id_expr

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
TEMPLATE_ID_EXPR is considered to be potential_constant_expression_1, so
require_potential_rvalue_constant_expression (e)
at the start of cxx_alignas_expr.  But cxx_eval_constant_expression does not
handle it.  So, shall potential_constant_expression_1 return false for
TEMPLATE_ID_EXPR and similar if !processing_template_decl (or always)?  Or
shall
cxx_eval_constant_expression handle it (how?)?

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

[derodat at adacore dot com]

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

Pierre-Marie de Rodat  changed:

   What|Removed |Added

 CC||derodat at adacore dot com

--- Comment #9 from Pierre-Marie de Rodat  ---
(In reply to Jakub Jelinek from comment #7)
> The behavior changed with r231762, I haven't looked (yet) into details if it
> is valid or not and why that changed.
I haven’t had a look yet neither… bit addressing is hard. ;-) All I can do for
now is to give some context for r231762: this commit tried to handle fields
with dynamic sizes/positions but only with a focus on the ones at least
byte-aligned.

My playground for this was discriminated types in Ada, and I’m not sure these
can be bit-packed (i.e. using sub-byte addressing). So if anything changed for
bitfields, that was not intentional and can likely be fixed as long as it does
not break things for the Ada types I tested. By the way, if one wants to see
what I used for testing, here it is:
https://github.com/pmderodat/dwarf-ada-testsuite/.

[Bug c++/78840] [5/6/7 Regression] ICE with const variables in templates implicitly captured by nested lambda expressions

[nathan at gcc dot gnu.org]

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

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

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
sigh, bugzilla's moving on to 'random' other bug gets me.  Again.

[Bug c/77754] [5/6/7 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
So, where would be the best place to remove the VLA bounds from parameters of
fn declarations?  Some function called from c_write_global_declarations_1 and
from walking BLOCK tree vars e.g. right before calling c_genericize in
finish_function?

[Bug c/77754] [5/6/7 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
int fn3 (void);
void fn4 (int[][fn3 ()]);

void
fn1 (void)
{
  int a[10][fn3 ()];
  fn4 (a);
}

also ICEs.

[Bug libstdc++/78870] Support std::filesystem on Windows

[jhasse at bixense dot com]

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

--- Comment #2 from Jan Niklas Hasse  ---
I'm willing to help. Is there an existing starting point for Windows? Can
boost::filesystem's implementation be used?

[Bug gcov-profile/78792] gfortran + gcov confused by #line directive

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-20
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Ok, I can confirm that line directives are accepted, however gcov does not
respect filename of the directives.

Second issue is that calling gcov example.in, actually loads example.gcno file,
where it's written that it's note file for example.f90 (compiled file). Maybe
we can show error message when an argument of gcov does not reflect to a file
mentioned in the note file.

Anyhow, I'm planning to discuss that with Honza and return to that for GCC 8.

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Because nobody who uses Windows has contributed any help to make it work.
Nothing will change until somebody does that. I've written 100% of the
filesystem code so far, but I'm not going to do the Windows implementation too.

[Bug c++/77812] [5/6/7 Regression] incorrectly rejects valid C++ code that uses enum in template instantiation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r181359.
Note, on:
enum f { R, G, B }; 
struct g {}; 

template 
void e ();

template 
void f ()
{
  e (); 
}

template 
void g ()
{
  e (); 
}

void h ()
{
  f ();
  g ();
}
we actually reject even the instantiation of g with -std=c++98, while clang++
accepts it with all -std= versions.

[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.

[matthew.fortune at imgtec dot com]

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

Matthew Fortune  changed:

   What|Removed |Added

 CC||matthew.fortune at imgtec dot 
com

--- Comment #17 from Matthew Fortune  ---
(In reply to Bill Schmidt from comment #15)
> ;; Function andrew (andrew, funcdef_no=2, decl_uid=2361, cgraph_uid=2,
> symbol_order=2)
> 
> andrew (struct s * p)
> {
>   unsigned int _4;
>   unsigned int _5;
>   unsigned int _6;
> 
>   :
>   _4 = BIT_FIELD_REF <*p_3(D), 32, 0>;
>   _5 = _4 & 1;
>   _6 = _5;
>   return _6;
> 
> }

MIPS sees this same spurious failure. The issue (on a GCC 6 branch) is that the
optimization has successfully happened it just looks like the check is wrong in
the testcase. The presence of a logical and is not harmful as it is a
legitimate way to truncate: (from match.pd)

/* A truncation to an unsigned type (a zero-extension) should be
   canonicalized as bitwise and of a mask.  */

This simplification kicks in for MIPS and presumably powerpc but does not (I
don't know why) for x86_64. There is no 'goto' demonstrating that a single bit
extract does not use an IF.

I therefore propose we just update the check to verify there is no 'goto'.

Matthew

[Bug c/77767] [5/6/7 Regression] Side-effect from VLA array parameters lost

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 40378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40378=edit
gcc7-pr77767-2.patch

Version with append_to_statement_list.

[Bug driver/78863] [6 Regression] error on -fsanitize suggests invalid -fsanitize=all

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
I've got patch for that, will send to ML soon.

[Bug c/77767] [5/6/7 Regression] Side-effect from VLA array parameters lost

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 40377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40377=edit
gcc7-pr77767.patch

I went through all the grokdeclarator (indirect) callers, and those callers (of
e.g. groktypename, grokparm, push_parm_decl and c_parser_objc_method_decl) that
are called with non-NULL expr actually ensure it is initialized with NULL_TREE
first and want to append to it.
Here is thus an untested patch.  Optionally, the building of COMPOUND_EXPR
could be in both spots (this one and the one in the if (this_size_varies)
handling later on) replaced with append_to_statement_list (whatever, expr);
Any preferences here?

[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Note that the attached patch will actually end up propagating that  form
everywhere (and run into those object-size fallout issues).

[Bug driver/78863] [6 Regression] error on -fsanitize suggests invalid -fsanitize=all

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-20
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|error on -fsanitize |[6 Regression] error on
   |suggests invalid|-fsanitize suggests invalid
   |-fsanitize=all  |-fsanitize=all
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/78869] [6/7 Regression] Strange __builtin_memcpy optimisations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
For GCC 8 I'll look into fixing the missing memcpy folding.

[Bug tree-optimization/78869] [6/7 Regression] Strange __builtin_memcpy optimisations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||missed-optimization
   Last reconfirmed||2016-12-20
  Component|c   |tree-optimization
 Ever confirmed|0   |1
Summary|Strange __builtin_memcpy|[6/7 Regression] Strange
   |optimisations   |__builtin_memcpy
   ||optimisations
   Target Milestone|--- |6.3

--- Comment #1 from Richard Biener  ---
It's SRA which handles

memcpy_test (char * ptr)
{
  char * D.1764;
  char temp[64];

  try
{
  D.1764 = ptr + 64;
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})D.1764];
  MEM[(char * {ref-all})ptr] = MEM[(char * {ref-all})];

by "scalarizing" temp byte-wise:

  :
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})ptr_1(D) + 64B];
  temp$0_2 = MEM[(char * {ref-all})ptr_1(D) + 64B];
  temp$1_7 = MEM[(char * {ref-all})ptr_1(D) + 65B];
...
  MEM[(char * {ref-all})ptr_1(D)] = temp$0_2;
  MEM[(char * {ref-all})ptr_1(D) + 1B] = temp$1_7;
  MEM[(char * {ref-all})ptr_1(D) + 2B] = temp$2_8;
  MEM[(char * {ref-all})ptr_1(D) + 3B] = temp$3_9;
...
  return;

ugh.  Looks like memcpy folding doesn't handle

  D.1765 = ptr + 64;
  __builtin_memcpy ([0], D.1765, 64);
  __builtin_memcpy (ptr, [0], 64);

so we're just "lucky" there.  Regression from GCC 5, the SRA capability was
added with GCC 6.

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|nathan at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #4 from Richard Biener  ---
I will look at it but it's probably a latent issue.  Before the patch we
happily returned a DIE from the hash table we pruned previously.

Will look at next year, that is.

[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
(In reply to Richard Biener from comment #7)
> I don't think that the middle-end converts pow(, int-valued) to powi anywhere
> as generally the result can be off too far (maybe we could for some known
> special values).

For pow(x, 2.), we always get a multiplication. With -ffast-math, all pow(x,
(double)int_cst) are converted to a sequence of multiplications (I just tried
with pow(x,123456789) which gives a sequence of 37 multiplications at -O1
-ffast-math). But with pow(x,(double)int_var), we don't generate a call to
__powidf2, even a combination of -Os -ffast-math calls __pow_finite instead.

[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Created attachment 40376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40376=edit
forwprop fix

The forwprop piece, untested (apart from on the testcase).  No time to explore
further before the start of the next year.

[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
(In reply to Marc Glisse from comment #1)
> Not sure what the best angle is here.
> 
> _18 = (unsigned long) [(void *) + 9B];
> _16 = _18 + 1;
> 
> looks like it would be better as:
> 
> _19 = (unsigned long) 
> _16 = _19 + 10;
> 
> (I guess we don't want to produce [(void *) + 10B])
> 
> But that might not be true anymore if _18 had several uses.

We do already have

/* Pattern match
 tem1 = (long) ptr1;
 tem2 = (long) ptr2;
 tem3 = tem2 - tem1;
 tem4 = (unsigned long) tem3;
 tem5 = ptr1 + tem4;
   and produce
 tem5 = ptr2;  */
(simplify
  (pointer_plus @0 (convert?@2 (minus@3 (convert @1) (convert @0
  /* Conditionally look through a sign-changing conversion.  */
  (if (TYPE_PRECISION (TREE_TYPE (@2)) == TYPE_PRECISION (TREE_TYPE (@3))
   && ((GIMPLE && useless_type_conversion_p (type, TREE_TYPE (@1)))
|| (GENERIC && type == TREE_TYPE (@1
   @1))

for example...  But I guess the issue is [ + 9B] vs. _
(I'm quite sure operand_equal_p doesn't treat those as equal).  At least
propagation passes will canonicalize _ + 1 to [ + 9B]
(but that transform is not done on its own AFAIR).  forwprop does that
as well, but not as part of its "copy" lattice init.  Fixing that
results in

   [10.00%]:
  _18 = (unsigned long) [(void *) + 9B];
  _3 = (unsigned long) [(void *) + 1B];
  _16 = _18 + 1;
  _14 = _16 - _3;
  _13 = buf__9(D) + ptr_6(D);
  __builtin_memcpy (_13, , _14);

after forwprop4, so we still miss some patterns here.  I guess reassoc
makes our job harder in this case...  disabling reassoc2 yields

   [10.00%]:
  _13 = buf__9(D) + ptr_6(D);
  MEM[(char * {ref-all})_13] = MEM[(char * {ref-all})];
  return;

at forwprop4.  So eventually reassoc misses the  trick as well or we
should really apply that generally (ISTR it messed up some object-size
warning stuff if done generally).

> Reassoc could also play a role, either to cancel the two +1, or to put the
> two converted addresses together.
> 
> I guess extra match.pd patterns might be doable as well, but I am scared of
> the number of variants that might appear.

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #9 from Jakub Jelinek  ---
Apparently this ICEs for one reason in C and completely different reason in
C++,
the C++ reason is very much broken expand_array_notation_exprs, I think I've
mentioned that already several years ago - while the C FE uses walk_tree and
just handles the trees it wants to handle, the C++ FE just recursively calls
itself and thinks it handles everything it should, but obviously doesn't (and
some cases like OMP_PARALLEL which appears here pretends to handle, but doesn't
actually).  So, IMHO the C++ expand_array_notation_exprs needs to be rewritten
to use cp_walk_tree instead.  There is another problem that affects also the C
FE, the callback routine calls contains_array_notation_expr, which again walks
all the subtrees (and doesn't use *walk_tree for that, another bug); but that
means with very large expression the compile time complexity is exponential.
Probably it needs to instead do contains_array_notation_expr just once and mark
all the expressions that contain array notations in some hash map, then just
look up that hash map or something similar.

On the other side, the C++ FE has a hack like:
/* If it is a built-in array notation function, then the return type of
 the function is the element type of the array passed in as array 
 notation (i.e. the first parameter of the function).  */
  if (flag_cilkplus && TREE_CODE (fn) == CALL_EXPR) 
{
  enum built_in_function bif = 
is_cilkplus_reduce_builtin (CALL_EXPR_FN (fn));
  if (bif == BUILT_IN_CILKPLUS_SEC_REDUCE_ADD
  || bif == BUILT_IN_CILKPLUS_SEC_REDUCE_MUL
  || bif == BUILT_IN_CILKPLUS_SEC_REDUCE_MAX
  || bif == BUILT_IN_CILKPLUS_SEC_REDUCE_MIN
  || bif == BUILT_IN_CILKPLUS_SEC_REDUCE
  || bif == BUILT_IN_CILKPLUS_SEC_REDUCE_MUTATING)
{ 
  if (call_expr_nargs (fn) == 0)
{
  error_at (EXPR_LOCATION (fn), "Invalid builtin arguments");
  return error_mark_node;
}
  /* for bif == BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_ZERO or
 BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_ZERO or
 BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_NONZERO or 
 BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_NONZERO or
 BUILT_IN_CILKPLUS_SEC_REDUCE_MIN_IND or
 BUILT_IN_CILKPLUS_SEC_REDUCE_MAX_IND
 The pre-defined return-type is the correct one.  */
  tree array_ntn = CALL_EXPR_ARG (fn, 0); 
  TREE_TYPE (fn) = TREE_TYPE (array_ntn); 
  return fn;
}
}
in build_cxx_call, which, while very unclean, actually fixes the issue the C FE
is having - that the return type from __sec_reduce_add etc. is initially
thought to be int rather than the type of the first argument.  The clean fix is
to remove the above hack and use
IFN_CILKPLUS_SEC_REDUCE{_ADD,_MUL,_MAX,_MIN,,_MUTATING} internal fns and
resolve_overloaded_built create those ifn calls with the right type.
A hackish fix is essentially to move the above hack into
resolve_overloaded_builtin (it is unclean, because the builtin still claims
return type of int and the CALL_EXPR doesn't match it, but as it is lowered
soon afterwards, it might not be as a big deal).

I don't want to write all of the above myself, so the question is, is Intel
still maintaining the Cilk+ support, or is it time to deprecate it and remove
in the next release?

[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Note that absence of flags such as -ffast-math only libstdc++ knows whether
the standard allows pow(, int) to be implemented with more than a single
rounding.

I don't think that the middle-end converts pow(, int-valued) to powi anywhere
as generally the result can be off too far (maybe we could for some known
special values).

[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #18 from ktkachov at gcc dot gnu.org ---
Fixed.

[Bug libstdc++/78870] New: Support std::filesystem on Windows

[jhasse at bixense dot com]

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

Bug ID: 78870
   Summary: Support std::filesystem on Windows
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jhasse at bixense dot com
  Target Milestone: ---

Currently std::experimental::filesystem / stdc++fs is missing in MSYS2 / MinGW
(tested with GCC 6.2.0).

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[matthew.fortune at imgtec dot com]

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

--- Comment #3 from Matthew Fortune  ---
(In reply to Aldy Hernandez from comment #2)
> I can't reproduce on a cross build.  Is there a mips64el box on the compile
> farm or somewhere public so someone can look at this?

The following machines were added to the farm relatively recently. gcc24 is not
accepting my login currently though to gcc22 or gcc23 are usable. They will not
be fast though as they are modified routers. They are 32-bit but with 64-bit
multilibs I suspect that is good enough to reproduce. I won't find time to look
at this until the new year at least, any help is appreciated.

Operating system are currently configured as follows:
* gcc22 - kernel 3.14.10 (EB), Debian 7.10 (Wheezy), gcc 4.6.3
* gcc23 - kernel 4.1.4 (EL), Debian 8.4 (Jessie), gcc 4.9.2
* gcc24 - kernel 4.1.4 (EL), Debian 8.4 (Jessie), gcc 4.9.2 (EB = big endian,
EL = little endian)

[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2

[ktkachov at gcc dot gnu.org]

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

--- Comment #17 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Dec 20 09:39:44 2016
New Revision: 243820

URL: https://gcc.gnu.org/viewcvs?rev=243820=gcc=rev
Log:
[ARM] PR target/78694: Avoid invalid RTL sharing in minipool code

PR target/78694
* config/arm/arm.c (dump_minipool): Copy mp->value before emitting it
in the minipool to avoid invalid RTL sharing.

* gcc.c-torture/compile/pr78694.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr78694.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug c/78869] New: Strange __builtin_memcpy optimisations

[tvrtko.ursulin at linux dot intel.com]

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

Bug ID: 78869
   Summary: Strange __builtin_memcpy optimisations
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tvrtko.ursulin at linux dot intel.com
  Target Milestone: ---

Created attachment 40375
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40375=edit
Intermediate file as requested.

Hi,

I have observed a strange code being generated from simple usage of
__builtin_memcpy. Test case is simply this:

void memcpy_test(char *ptr)
{
char temp[64];

__builtin_memcpy(temp, ptr + 64, 64);
__builtin_memcpy(ptr, temp, 64);
}

void memcpy_test2(void *ptr)
{
char temp[64];

__builtin_memcpy([0], ptr + 64, 64);
__builtin_memcpy(ptr, [0], 64);
}

When I compile this with -O2 memcpy_test generates a byte-per-byte unrolled
copy for memcpy_test, while memcpy_test2 correctly generates a qword-by-qword
unrolled copy.

If I change the optimisation level to -O3 then the memcpy_test becomes XMM
optimised, so 128-bit moves, while memcpy_test2 remains qword-by-qword.

First question obviously is that how come it chooses to do byte-per-byte copy
and secondly why is there a difference in the code generated between the two
functions?

Thanks!



[tursulin@t460p ~]$ gcc -v -save-temps -c -O2 memcpy-test.c 
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/6.2.1/cc1 -E -quiet -v memcpy-test.c
-mtune=generic -march=x86-64 -O2 -fpch-preprocess -o memcpy-test.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/6.2.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/6.2.1/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/6.2.1/cc1 -fpreprocessed memcpy-test.i
-quiet -dumpbase memcpy-test.c -mtune=generic -march=x86-64 -auxbase
memcpy-test -O2 -version -o memcpy-test.s
GNU C11 (GCC) version 6.2.1 20160916 (Red Hat 6.2.1-2) (x86_64-redhat-linux)
compiled by GNU C version 6.2.1 20160916 (Red Hat 6.2.1-2), GMP version
6.1.1, MPFR version 3.1.4, MPC version 1.0.2, isl version 0.14 or 0.13
warning: MPFR header version 3.1.4 differs from library version 3.1.5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 6.2.1 20160916 (Red Hat 6.2.1-2) (x86_64-redhat-linux)
compiled by GNU C version 6.2.1 20160916 (Red Hat 6.2.1-2), GMP version
6.1.1, MPFR version 3.1.4, MPC version 1.0.2, isl version 0.14 or 0.13
warning: MPFR header version 3.1.4 differs from library version 3.1.5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c310f7e29a18a5e3f0310939bf78ca27
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o memcpy-test.o memcpy-test.s
GNU assembler version 2.26.1 (x86_64-redhat-linux) using BFD version version
2.26.1-1.fc24
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/:/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/6.2.1/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/6.2.1/:/usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-mtune=generic'
'-march=x86-64'

[Bug c++/78852] [7 Regression] ICE with Boost.Variant 1.62

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug bootstrap/78859] [7 Regression] profiledbootstrap failure caused by -Werror=nonnull

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build, diagnostic
   Priority|P3  |P1
Version|unknown |7.0
   Target Milestone|--- |7.0
Summary|profiledbootstrap failure   |[7 Regression]
   |caused by -Werror=nonnull   |profiledbootstrap failure
   ||caused by -Werror=nonnull

[Bug fortran/78867] [7 Regression] GFortran function returning string ICE with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
The issue is that at read-in cfun is unexpectedly NULL.  We're here:

static void
input_function (tree fn_decl, struct data_in *data_in,
struct lto_input_block *ib, struct lto_input_block *ib_cfg)
{
...
  /* Read the tree of lexical scopes for the function.  */
  DECL_INITIAL (fn_decl) = stream_read_tree (ib, data_in);
  unsigned block_leaf_count = streamer_read_uhwi (ib);
  while (block_leaf_count--)
stream_read_tree (ib, data_in);


and only later we do:


  if (!streamer_read_uhwi (ib))
return;

  push_struct_function (fn_decl);
  fn = DECL_STRUCT_FUNCTION (fn_decl);
  init_tree_ssa (fn);

this means that the BLOCK tree (and its VAR_DECLs) have references to SSA
names.

Which I think boils down to another instance of a missing DECL_EXPR and thus
not properly gimplified sizes:

test ()
{
  static void bar (character(kind=1)[1:] &, integer(kind=4), integer(kind=8) &
restrict);

  {
static integer(kind=8) C.3454 = 2;
integer(kind=8) * D.3455;
integer(kind=8) D.3456;
character(kind=1)[1:MAX_EXPR <(integer(kind=4)) D.3456, 0>] * pstr.0;
^^^

void * restrict D.3458;
integer(kind=4) D.3459;

D.3455 = 
D.3456 = *D.3455;
D.3458 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
MAX_EXPR <(integer(kind=4)) D.3456, 0>, 1>);
pstr.0 = (character(kind=1)[1:MAX_EXPR <(integer(kind=4)) D.3456, 0>] *)
D.3458;
bar (pstr.0, MAX_EXPR <(integer(kind=4)) D.3456, 0>, D.3455);
D.3459 = MAX_EXPR <(integer(kind=4)) D.3456, 0>;

[Bug fortran/78867] [7 Regression] GFortran function returning string ICE with -flto

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Uh, my bisection failed, as it turns out r243624 fails for me..

Looking more carefully r238055 is OK, but r238821 is not.

[Bug c++/78572] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4968

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
I'll take a stab.

[Bug fortran/78867] [7 Regression] GFortran function returning string ICE with -flto

[jb at gcc dot gnu.org]

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

--- Comment #3 from Janne Blomqvist  ---
(In reply to Janne Blomqvist from comment #2)
> (In reply to Dominique d'Humieres from comment #1)
> > This seems to be a regression between revisions r243624 (2016-12-13,
> > compiles) and r243765 (2016-12-16, ICE with -m32 or -m64).
> 
> Thanks for quickly narrowing it down. I'll bisect it to find the exact
> commit.

Uh, my bisection failed, as it turns out r243624 fails for me..

[Bug testsuite/71232] [7 Regression] FAIL gnat.dg/vect[36].adb scan-tree-dump-times vect "vectorized 1 loops" 15

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
.

[Bug testsuite/71232] [7 Regression] FAIL gnat.dg/vect[36].adb scan-tree-dump-times vect "vectorized 1 loops" 15

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Dec 20 08:50:21 2016
New Revision: 243819

URL: https://gcc.gnu.org/viewcvs?rev=243819=gcc=rev
Log:
Fix PR testsuite/71232 entry.

Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71237] [7 regression] scev tests failing after pass reorganization

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Dec 20 08:45:52 2016
New Revision: 243818

URL: https://gcc.gnu.org/viewcvs?rev=243818=gcc=rev
Log:
PR testsuite/71237
* gnat.dg/vect1.adb: Add -fno-vect-cost-model to dg-options.
* gnat.dg/vect2.adb: Likewise.
* gnat.dg/vect3.adb: Likewise.
* gnat.dg/vect4.adb: Likewise.
* gnat.dg/vect5.adb: Likewise.
* gnat.dg/vect6.adb: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gnat.dg/vect1.adb
trunk/gcc/testsuite/gnat.dg/vect2.adb
trunk/gcc/testsuite/gnat.dg/vect3.adb
trunk/gcc/testsuite/gnat.dg/vect4.adb
trunk/gcc/testsuite/gnat.dg/vect5.adb
trunk/gcc/testsuite/gnat.dg/vect6.adb

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Reduced testcase:
void
foo (double *a, double *b, double *c, int m, int o, int p)
{
  _Cilk_for (int i = 0; i < p; ++i)
a[i] += __sec_reduce_add (b[i:o] * c[m:o:-1]);
}
ICEs with both C and C++.

[Bug testsuite/71232] [7 Regression] FAIL gnat.dg/vect[36].adb scan-tree-dump-times vect "vectorized 1 loops" 15

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|middle-end  |testsuite

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

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-20
 Ever confirmed|0   |1

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||clm at codesourcery dot com,
   ||matthew.fortune at imgtec dot 
com

--- Comment #2 from Aldy Hernandez  ---
I can't reproduce on a cross build.  Is there a mips64el box on the compile
farm or somewhere public so someone can look at this?