[Bug target/5360] [SH] Useless address inc-dec sequence for DFmode access

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
When compiling the following test with -m2a -mb -O2

double test (void)
{
  return 123.123;
}

we get

mova.L2,r0
fmov.s  @r0+,fr0
fmov.s  @r0,fr1
rts
add #-4,r0
.L3:
.align 2
.L2:
.long   1079953375
.long   996432413

Although the address reg is dead after the last load, the add #-4 insn is not
eliminated.  This is probably because the DFmode move patterns are split at a
late stage during compilation.  The add #-4 has to be put there initially
because for the register allocator the DFmode constant looks like it doesn't
modify the address register.  In some cases this allows optimizations of
consecutive constant loads, as in:

void test (double* out)
{
  out[0] = 123.123;
  out[1] = 222;
}

mova.L2,r0
fmov.s  @r0+,fr2
fmov.s  @r0+,fr3
add #4,r4
fmov.s  fr3,@r4
fmov.s  fr2,@-r4
fmov.s  @r0+,fr2
fmov.s  @r0,fr3
add #-4,r0
fmov.s  fr2,@(8,r4)
fmov.s  fr3,@(12,r4)
rts/n
.L3:
.align 2
.L2:
.long   1079953375
.long   996432413
.long   1080803328
.long   0

[Bug c++/70971] New: ICE in parameter pack expansion

[barry.revzin at gmail dot com]

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

Bug ID: 70971
   Summary: ICE in parameter pack expansion
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This may not be totally minimal, but the following code:

#include 

struct A {};

template 
struct B : A { };

template  struct typelist {};
template  struct tag { using type = T; };

template 
std::unique_ptr chooseB(typelist )
{
return std::unique_ptr(new B);
}

template 
std::unique_ptr chooseB(typelist choices, Idx i, Rest... rest)
{
auto f = [=](auto tag){
return [=]{ return chooseB(choices, rest...); };
};

std::function fs[] = {
f(tag{})...
};

return fs[i]();
}

int main() {
auto p = chooseB(typelist{}, 0, 1, 2);
}

on gcc 5.3 with g++ -std=c++1z -O2 -Wall -Wextra -Wconversion -pedantic
-pthread produced (http://coliru.stacked-crooked.com/a/8dfc904ff5476477)

main.cpp: In function 'std::unique_ptr chooseB(typelist, Idx, Rest
...) [with Ts = {}; Cs = {int, double, char}; Idx = int; Rest = {int, int}]':
main.cpp:29:1: error: unrecognizable insn:
 }
 ^
(insn 28 19 29 2 (set (mem/c:SI (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -92 [0xffa4])) [65 MEM[(struct __lambda1
*) + 4B]+0 S4 A32])
(reg/v 101 [ rest#0 ])) -1
 (nil))
main.cpp:29:1: internal compiler error: in extract_insn, at recog.c:2287
libbacktrace could not find executable to open

With -g instead of -O2 it compiles but segfaults.

On clang it compiles fine.

[Bug tree-optimization/70970] Misaligned SSE with auto-vectorization

[rcc.dark at gmail dot com]

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

--- Comment #2 from Rodrigo  ---
Just noticed a dumb mistake in the parameter order of memalign (_aligned_malloc
is (size, alignment); memalign is (alignment, size)) but the problem persists.

Also forgot that I had to use -march=native under 5.3.1 but not 5.2.0. Sorry
for the possible confusion this may cause, the computers in which I tested
differ a lot. I just hope you can reproduce it without problems.

[Bug tree-optimization/70970] Misaligned SSE with auto-vectorization

[rcc.dark at gmail dot com]

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

Rodrigo  changed:

   What|Removed |Added

  Attachment #38424|0   |1
is obsolete||

--- Comment #1 from Rodrigo  ---
Created attachment 38425
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38425=edit
code (fixed)

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

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

--- Comment #18 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri May  6 01:18:59 2016
New Revision: 235941

URL: https://gcc.gnu.org/viewcvs?rev=235941=gcc=rev
Log:
2016-05-05  Jerry DeLisle  

Backport from trunk.
PR libgfortran/70684
* io/list_read (next_char): Add '\r' to check for end of line.
factor. (two places)

PR libgfortran/70684
* gfortran.dg/list_read_14.f90: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/list_read_14.f90
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/libgfortran/ChangeLog
branches/gcc-4_9-branch/libgfortran/io/list_read.c

[Bug tree-optimization/70970] New: Misaligned SSE with auto-vectorization

[rcc.dark at gmail dot com]

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

Bug ID: 70970
   Summary: Misaligned SSE with auto-vectorization
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcc.dark at gmail dot com
  Target Milestone: ---

Created attachment 38424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38424=edit
the code

Sorry if this has been reported before. I have tested it under:

gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 5.2.1 20151028 (Debian 5.2.1-23) 
gcc version 6.1.0 (GCC) <- Windows
gcc version 5.2.0 (GCC) <- Windows, MinGW-W64

The following code crashes with -std=c++14 -O3:


#include 
#include 

template
__attribute__ ((noinline))
void symmetric_difference(RI ai, RI af, RI bi)
{
   while (ai != af) {
  *ai++ ^= *bi++;
   }
}

int main( )
{
   auto p1 = reinterpret_cast(memalign(4096, 32));
   auto p2 = reinterpret_cast(memalign(4096, 32));
   // _aligned_malloc under Windows

   auto ai = reinterpret_cast(p1 + 1);
   auto bi = reinterpret_cast(p2 + 1);

   symmetric_difference(ai, ai + 64, bi);
}


It stops crashing with -O2 or if I remove the + 1 to the pointers; GDB tells me
that the problem lies within:

  vmovdqa YMMWORD PTR [rbx+rcx*1],ymm0

The register rbx is not aligned and rcx = 0. It seems that it is reading with
vmovdqu but storing with vmovdqa.

[Bug bootstrap/70969] New: power64le ada bootstrap failure: s-unstyp.ads:40:15: violation of No_Elaboration_Code_All at line 42

[msebor at gcc dot gnu.org]

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

Bug ID: 70969
   Summary: power64le ada bootstrap failure: s-unstyp.ads:40:15:
violation of No_Elaboration_Code_All at line 42
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Current trunk (7.0) fails to bootstrap on powerpc64le, due to the following
error:

/build/gcc-trunk-bootstrap/./gcc/xgcc -B/build/gcc-trunk-bootstrap/./gcc/
-B/usr/local/powerpc64le-unknown-linux-gnu/bin/
-B/usr/local/powerpc64le-unknown-linux-gnu/lib/ -isystem
/usr/local/powerpc64le-unknown-linux-gnu/include -isystem
/usr/local/powerpc64le-unknown-linux-gnu/sys-include-c -g -O2  -fPIC  -W
-Wall -gnatpg -nostdinc   s-unstyp.ads -o s-unstyp.o
s-unstyp.ads:40:15: violation of No_Elaboration_Code_All at line 42
s-unstyp.ads:40:15: unit "System" does not have No_Elaboration_Code_All
make[7]: *** [s-unstyp.o] Error 1
make[7]: Leaving directory `/build/gcc-trunk-bootstrap/gcc/ada/rts'

[Bug middle-end/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Created attachment 38423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38423=edit
Preprocessed source

/test/gnu/gcc/objdir/./gcc/cc1plus -fpreprocessed interpret.ii -quiet -dumpbase
interpret.cc -auxbase-strip .libs/interpret.o -g -O2 -Wswitch-enum -Wextra
-Wall -version -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -fwrapv
-fPIC -o interpret.s

r235311 is okay.  r235318 is bad.

[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails

[tulipawn at gmail dot com]

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

--- Comment #6 from PeteVine  ---
Building with -mfpu=neon has duly helped. The fpu configure option is probably
not relevant here (simply setting the default for emitted code) but rather the
CFLAGS used for compiling these intrinsics. (-mfpu=vfpv4)

[Bug other/70968] New: Missed case for -Wmisleading-indentation

[segher at gcc dot gnu.org]

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

Bug ID: 70968
   Summary: Missed case for -Wmisleading-indentation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

Compiling the following with current trunk:

===
void g(int);

void f1(int x)
{
if (x) {
g(x--);
} while (x);
}

void f2(int x)
{
if (x)
g(x--);
while (x);
}

void f3(int x)
{
if (x) g(x--); while (x);
}
===

(-Wall -W -O2) only warns for f3.  f1 has quite misleading indentation.

A warning for "while (x);" wouldn't hurt either probably, if there is
no whitespace before the semicolon anyway, like in f3.

[Bug target/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[uros at gcc dot gnu.org]

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

--- Comment #30 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May  5 22:48:29 2016
New Revision: 235936

URL: https://gcc.gnu.org/viewcvs?rev=235936=gcc=rev
Log:
PR target/70873
* config/i386/i386-protos.h (ix86_standard_x87sse_constant_load_p):
New prototype.
* config/i386/i386.c (ix86_standard_x87sse_constant_load_p): New.
* config/i386/i386.md (push mem splitter): Use find_constant_src in
the splitter condition.
(FP load splitter): Use ix86_standard_x87sse_constant_load_p in
the splitter condition.
(FP float_extend load splitter): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md

[Bug c/70967] New: doc: Please document rotate idiom

[hpa at zytor dot com]

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

Bug ID: 70967
   Summary: doc: Please document rotate idiom
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

The idiom that gcc has recognized since time immemorial (gcc 2-something) to
generate a rotate:

((foo >> n) + (foo << (sizeof(foo) * CHAR_BIT - n))

/* | instead of + has been recognized for almost but not quite as long */

... is undefined behavior under the C standard when n == 0.  There is a
technically portable idiom (bug 57157) which has been recognized since gcc
4.6.3, but that is not portable to older versions of gcc without generating
suboptimal code.

It would be great if the gcc manual could be augmented to document this idiom
for rotate as a GNU C extension so that people are less concerned about its
validity, and compilers that mimic the GNU C dialect (icc, clang, etc.) know to
implement it correctly.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[wilson at gcc dot gnu.org]

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

--- Comment #6 from Jim Wilson  ---
Testing the vcond_mask* patch with make check gave 6 regressions for both armhf
and aarch64.

FAIL: gcc.dg/vect/pr65947-10.c (internal compiler error)
FAIL: gcc.dg/vect/pr65947-10.c (test for excess errors)
FAIL: gcc.dg/vect/pr65947-10.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects (internal compiler
error)
FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects  scan-tree-dump-times
vec
t "LOOP VECTORIZED" 2

The problem here looks like a flaw in the vcond* patterns.  They support int
and fp compare operands, but only int selection operands.  E.g. for 
  (A op B ? X : Y)
A and B can be either int or fp, but X and Y can only be int.  Adding the
vcond_mask* patterns apparently causes gcc to call vcond* in ways it didn't
before, and that exposes the problem.

The x86 port is the only port with vcond and vcond_mask patterns, and it
supports all four combinations if int/fp compare/select operands, so it appears
that aarch64 should also.

I will need time to figure out how to fix the vcond* problems before I can
formally submit the vcond_mask* patch.

[Bug rtl-optimization/70961] Regrename ignores preferred_rename_class

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  ---
> The super_class has nothing to do with the class that is searched for
> renaming registers though, it's just the info passed to the back-end to
> compute this class.  For example, on the ARM, the preferred_class will be
> LO_REGS for any chain of GENERAL_REGS.

As a matter of fact, that might not be true, something like

Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 235858)
+++ config/arm/arm.c(working copy)
@@ -27721,9 +27721,9 @@ static reg_class_t
 arm_preferred_rename_class (reg_class_t rclass)
 {
   /* Thumb-2 instructions using LO_REGS may be smaller than instructions
- using GENERIC_REGS.  During register rename pass, we prefer LO_REGS,
+ using GENERAL_REGS.  During register rename pass, we prefer LO_REGS,
  and code size can be reduced.  */
-  if (TARGET_THUMB2 && rclass == GENERAL_REGS)
+  if (TARGET_THUMB2 && reg_class_subset_p (rclass, GENERAL_REGS))
 return LO_REGS;
   else
 return NO_REGS;

could be needed.

[Bug libstdc++/70966] New: new_delete_resource() has deinit lifetime issues.

[eric at efcs dot ca]

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

Bug ID: 70966
   Summary: new_delete_resource() has deinit lifetime issues.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

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

The value returned from 'new_delete_resource()' should be usable at all stages
of program startup and termination.

In the current implementation the static deinitialization order fiasco can
occur when a static object 'obj' is constructed before the first call to
'new_delete_resource()' and 'obj' references 'new_delete_resource()' in its
destructor.

[Bug rtl-optimization/70961] Regrename ignores preferred_rename_class

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-05
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> When deciding which register to use regrename.c calls the target function
> preferred_rename_class. However in pass 2 in find_rename_reg it then just
> ignores this preference. This results in significantly increased codesize on
> targets which prefer a subset of allocatable registers in order to use
> smaller instructions.

Pass #2 ignores it since the preference simply couldn't be honored.

> Also the computed super_class appears to be the union of all uses and defs
> instead of the intersection. This should be the intersection as that is the
> set of registers that all uses and defs support. 

The super_class has nothing to do with the class that is searched for renaming
registers though, it's just the info passed to the back-end to compute this
class.  For example, on the ARM, the preferred_class will be LO_REGS for any
chain of GENERAL_REGS.

> If the preferred class doesn't result in a valid rename then it could search
> a wider class, but then it would need to check that the size of the newly
> selected patterns does not increase.

The size is an arbitrary criterion, this could also be the latency, etc.

[Bug sanitizer/70875] ICE in get_ubsan_type_info_for_type with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
tree_to_uhwi already contains the tree_fits_uhwi_p assert, so there is no
reason to duplicate that.

[Bug sanitizer/70875] ICE in get_ubsan_type_info_for_type with -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Seems like an overzealous assert:

diff --git a/gcc/ubsan.c b/gcc/ubsan.c
index 802341e..080f798 100644
--- a/gcc/ubsan.c
+++ b/gcc/ubsan.c
@@ -302,11 +302,14 @@ ubsan_source_location (location_t loc)
 static unsigned short
 get_ubsan_type_info_for_type (tree type)
 {
-  gcc_assert (TYPE_SIZE (type) && tree_fits_uhwi_p (TYPE_SIZE (type)));
   if (TREE_CODE (type) == REAL_TYPE)
-return tree_to_uhwi (TYPE_SIZE (type));
+{
+  gcc_assert (TYPE_SIZE (type) && tree_fits_uhwi_p (TYPE_SIZE (type)));
+  return tree_to_uhwi (TYPE_SIZE (type));
+}
   else if (INTEGRAL_TYPE_P (type))
 {
+  gcc_assert (TYPE_SIZE (type) && tree_fits_uhwi_p (TYPE_SIZE (type)));
   int prec = exact_log2 (tree_to_uhwi (TYPE_SIZE (type)));
   gcc_assert (prec != -1);
   return (prec << 1) | !TYPE_UNSIGNED (type);

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

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
With most of the documentation for each option consisting of "the file name is
made by appending .xxx to the source file name" I agree that in its current
form and state of completion the documentation isn't very useful.

I also suspect that providing descriptions for the currently undocumented
options and saying much more than what's in the boilerplate blurb above is
unlikely.

I like the idea of providing a generic description instead, as long is it makes
it easy to derive the option names.  I had to figure out by trial and error
that the name of the option controlling the Object Size Checking dumps is
-fdump-tree-objsz (by using -fdump-tree-all, looking at the suffix of the two
dump files, and appending it to -fdump-tree-).  But after some experimenting
and poking around in the manual I realize there's a better way to do it:

1) Run GCC with -fdump-passes and look for the pass code (e.g., objsz for
Object Size Checking).
2) Append the pass code to the -fdump-tree- (or -fdump-rtl-) option to enable
the dump.
3) Use the pass code to find the name of the dump file created by GCC for the
pass (unless overridden).

So maybe this would be sufficient documentation for all the options.  The one
thing missing is a description of what each of those passes actually does.  For
some it's fairly obvious but for others not so much.  Maybe a brief description
could be added to GCC's -fdump-passes output to help figure that out (e.g.,
under -fdump-passes=verbose if we want to keep the current output unchanged).

How does this sound?

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[zenith432 at users dot sourceforge.net]

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

--- Comment #6 from zenith432 at users dot sourceforge.net ---
(In reply to H.J. Lu from comment #5)
> This may be related to PR 50818.

PR 50818 has morphed into a feature request that the canonical
__builtin_va_{list,start,end,copy} builtins behave according to the ABI of the
function they're in.  Today they behave according to the '-mabi=' setting on
the command line.

This is bug report that the specialized __builtin_ms_va_{list,start,end,copy}
builtins have stopped working when -flto is used.  They worked until gcc 5.3,
both with or without -flto.  In gcc 6.1 with -flto, the canonical iterator
__builtin_va_arg ignores them and works on a sysv_va_list.  To be precise, it's
__builtin_va_arg in the context of -flto that's broken, not the specialized
builtins.  __builtin_va_arg has always been a polymorphic builtin that changes
its behavior based on the type of va_list it's given as an argument.  Without
this polymorphic behavior, there's no way to iterate over an ms_va_list.

[Bug c++/70965] ice in useless_type_conversion_p

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/70965] New: ice in useless_type_conversion_p

[dcb314 at hotmail dot com]

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

Bug ID: 70965
   Summary: ice in useless_type_conversion_p
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 38421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38421=edit
gzipped C++ source code

The attached C++ code, when compiled by gcc trunk dated 20160504,
does this:

/home/dcb/rpmbuild/BUILD/libkolabxml-1.0.3/src/kolabformat.cpp:291:1: internal
compiler error: Segmentation fault
 }
 ^
0xe5113f crash_signal
../../src/trunk/gcc/toplev.c:333
0xb510c0 useless_type_conversion_p(tree_node*, tree_node*)
../../src/trunk/gcc/gimple-expr.c:67
0xf419d0 callsite_arguments_match_p
../../src/trunk/gcc/tree-sra.c:1371
0xf419d0 some_callers_have_mismatched_arguments_p
../../src/trunk/gcc/tree-sra.c:5063

Flag -O2 required.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
I don't see much value in documenting those.  It seems to me that we should
simply document that the format is -fdump-{tree,ipa,rtl}-[-].

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-28 00:00:00 |2016-5-5
 CC||msebor at gcc dot gnu.org
  Known to fail||4.3.0, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.1.0

--- Comment #2 from Martin Sebor  ---
The -fdump-tree-objsz is also undocumented.

I tried to get a comprehensive list of all undocumented tree dumps.  Here's
what I came up with for GCC 6.1.  It looks like the vast majority of them are,
in fact, undocumented.

ipa-afdo
ipa-build_ssa_passes
ipa-cdtor
ipa-chkp_cleanup
ipa-chkp_ecleanup
ipa-chkp_passes
ipa-chkp_versioning
ipa-comdats
ipa-cp
ipa-devirt
ipa-dispachercalls
ipa-emutls
ipa-free-inline-summary
ipa-hsa
ipa-icf
ipa-increase_alignment
ipa-inline
ipa-ipa_oacc
ipa-ipa_oacc_kernels
ipa-opt_local_passes
ipa-profile
ipa-profile_estimate
ipa-pta1
ipa-pure-const
ipa-simdclone
ipa-single-use
ipa-static-var
ipa-targetclone
ipa-tmipa
ipa-visibility
ipa-whole-program
statistics
aprefetch
asan0
asan1
bswap
ccp1
cdce
cddce1
ch1
chkp
chkpopt
ch_vect
copyprop1
cplxlower0
cplxlower1
crited1
cselim
cunroll
cunrolli
dce1
dom1
dse1
ealias
early_optimizations
eh
ehcleanup1
ehdisp
ehopt
einline
eipa_sra
esra
fab1
feedback_fnsplit
fix_loops
fixup_cfg1
fnsplit
forwprop1
fre1
graphite
graphite0
hsagen
ifcombine
ifcvt
inline_param1
isolate-paths
ivcanon
ivopts
laddress
ldist
lim1
local-pure-const1
loop
loopdone
loopinit
lower
lower_vaarg
mergephi1
no_loop
nothrow
oacc_kernels
objsz1
ompexp
ompexpssa1
omplower
omptargetlink
parloops1
pcom
phicprop1
phiopt1
phiprop
profile_estimate
reassoc1
recip
release_ssa
resx
retslot
sancov1
sancov_O0
sanopt
sccp
simduid1
sincos
slp1
slsr
split-paths
stdarg
strlen
switchconv
tailc
tailr1
tmedge
tmlower
tmmark
tmmemopt
tracer
tsan0
tsan1
ubsan
uncprop1
uninit1
unswitch
veclower
veclower21
vrp1
vtable-verify
widening_mul

[Bug tree-optimization/57206] Auto-vectorization fails when array index is an unsigned int expression

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu May  5 16:20:54 2016
New Revision: 235926

URL: https://gcc.gnu.org/viewcvs?rev=235926=gcc=rev
Log:
gcc/testsuite
PR tree-optimization/57206
* gcc.dg/vect/pr57206.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr57206.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/70964] [7 Regression] internal compiler error: in single_succ_edge, at basic-block.h:351

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.1.0
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug tree-optimization/70964] New: [7 Regression] internal compiler error: in single_succ_edge, at basic-block.h:351

[ktkachov at gcc dot gnu.org]

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

Bug ID: 70964
   Summary: [7 Regression] internal compiler error: in
single_succ_edge, at basic-block.h:351
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The testcase:
int a, c, d, e, f;
int b[0];
void
fn1 ()
{
  int g;
  long h;
  for (;;)
{
  g = a < 0 ?: g;
  long i = d = i < 0 && g < i ?: g + i;
  f = 6;
  for (; f; f--)
{
  h = 6;
  for (; h; h--)
{
  int j;
  long *k;
  d || j && (*k = c);
  b[f] = e;
}
}
}
}

ICEs on aarch64-none-linux-gnu compiled with -Ofast.

mycrash.c: In function ‘fn1’:
mycrash.c:4:1: internal compiler error: in single_succ_edge, at
basic-block.h:351
 fn1 ()
 ^~~
0x6fdf23 single_succ_edge
$SRC/gcc/basic-block.h:351
0x6fdf23 lv_adjust_loop_entry_edge
$SRC/gcc/cfgloopmanip.c:1658
0x6fdf23 loop_version(loop*, void*, basic_block_def**, unsigned int, unsigned
int, unsigned int, bool)
$SRC/gcc/cfgloopmanip.c:1726
0xb494ff version_loop_for_if_conversion
$SRC/gcc/tree-if-conv.c:2333
0xb494ff tree_if_conversion
$SRC/gcc/tree-if-conv.c:2735
0xb494ff execute
$SRC/gcc/tree-if-conv.c:2829
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Bisection shows this started with r235842.

[Bug target/70963] New: vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

[markos at freevec dot org]

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

Bug ID: 70963
   Summary: vec_cts/vec_ctf intrinsics produce wrong results for
64-bit floating point
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markos at freevec dot org
  Target Milestone: ---
  Host: powerpc64le-linux-gnu
Target: powerpc64le-linux-gnu
 Build: powerpc64le-linux-gnu

Created attachment 38420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38420=edit
small test program to verify vec_cts/vec_ctf working on doubles

I've noticed some tests in Eigen failing for VSX 64-bit doubles code, when the
algorithm looked perfectly normal. Further investigation -and comparison with
direct output using same inputs from an SSE test program, showed that the
conversion to integer yielded 0 results in the case of VSX (vec_cts basically
returned 0 vectors). I've written a small test case that verifies this on both
big/little endian VSX-capable systems (compiled with -m64 -mvsx). When using
the intrinsic the result is wrong, when using the inline asm version, it works
as expected. I could not test it in a more recent gcc so it may well be fixed,
however it would be great if this would be backported to gcc 5.

Some asm output follows from test program (attached):

vec_cts:
166c:   60 67 00 f0 xvcvdpsxds vs0,vs12
1670:   50 02 00 f0 xxswapd vs0,vs0


asm:
1674:   51 02 00 f0 xxswapd vs32,vs0
1678:   60 07 00 f0 xvcvdpsxds vs0,vs0
167c:   56 02 00 f0 xxswapd vs0,vs32


vec_ctf:
16f8:   50 02 00 f0 xxswapd vs0,vs0
16fc:   e0 07 00 f0 xvcvsxddp vs0,vs0
1700:   50 02 00 f0 xxswapd vs0,vs0

asm:
16f8:   51 02 00 f0 xxswapd vs32,vs0
16fc:   e0 07 00 f0 xvcvsxddp vs0,vs0
1700:   56 02 00 f0 xxswapd vs0,vs32

[Bug c++/16106] Poor error message

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||4.8.5, 4.9.3, 5.3.0, 6.1.0
 Resolution|--- |FIXED
  Known to fail||4.5.3

--- Comment #3 from Martin Sebor  ---
Thank you for the update.  Resolving as Fixed.

[Bug tree-optimization/70956] ICE in build_cross_bb_scalars_def, at graphite-scop-detection.c:1725

[spop at gcc dot gnu.org]

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

--- Comment #2 from Sebastian Pop  ---
The change looks good to me.

[Bug tree-optimization/68105] optimizing repeated floating point addition to multiplication

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to zboson from comment #0)
> In addition, the following equations are always true even without
> associative math.
> 
> 2*a = a + a
> 3*a = a + a + a
> 4*a = a + a + a + a
> 5*a = a + a + a + a + a
> 
> It turns out that GCC does simplify a + a + a + a to 4*a but only with
> associative math enabled e.g. with -Ofast when it could do it with -O3.

This "always true" needs some qualification. It is wrong with -frounding-math,
where you have to stop at 3 IIRC.

(In reply to kugan from comment #2)
> Looks like a duplicate of PR63586.

I am not convinced this is completely a dup. The patch
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00368.html would probably close
PR63586, but not this one since all of the testcases about float in that patch
use -ffast-math.

[Bug c++/70962] optimization not working in Red Hat 5.7 after glibc patching

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Not a gcc issue. Please report this to redhat directly.

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
This may be related to PR 50818.

[Bug c++/70962] New: optimization not working in Red Hat 5.7 after glibc patching

[chita40 at gmail dot com]

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

Bug ID: 70962
   Summary: optimization not working in Red Hat 5.7 after glibc
patching
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chita40 at gmail dot com
  Target Milestone: ---

$ cat tt.c
#include 
#include 
int main( const int argc, const char * argv[] )
{
  std::ifstream in;
  in.open( "/dev/null", std::ios::in );
  if (in.is_open() ) {
  std::cout << "opened" << std::endl;
} else {
  std::cout << "failed" << std::endl;
  }
  return 0;
}

$ g++ tt.c && a.out
opened

$ g++ -O2 tt.c && a.out
failed

[Bug rtl-optimization/70961] New: Regrename ignores preferred_rename_class

[wdijkstr at arm dot com]

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

Bug ID: 70961
   Summary: Regrename ignores preferred_rename_class
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

When deciding which register to use regrename.c calls the target function
preferred_rename_class. However in pass 2 in find_rename_reg it then just
ignores this preference. This results in significantly increased codesize on
targets which prefer a subset of allocatable registers in order to use smaller
instructions.

Also the computed super_class appears to be the union of all uses and defs
instead of the intersection. This should be the intersection as that is the set
of registers that all uses and defs support. 

If the preferred class doesn't result in a valid rename then it could search a
wider class, but then it would need to check that the size of the newly
selected patterns does not increase.

[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #5 from Ramana Radhakrishnan  ---
(In reply to PeteVine from comment #4)
> Until it failed again during the fortran part:
> 
> ../../../libgfortran/io/transfer.c: In function ‘bswap_array’:
> ../../../libgfortran/io/transfer.c:915:25: fatal error: You must enable NEON
> instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use these intrinsics.
>   ((uint16_t*)dest)[i] = __builtin_bswap16 (((uint16_t*)src)[i]);
>  ^~~
> compilation terminated.
> make[3]: *** [transfer.lo] Error 1
> 
> but that looks like user error. It would be nice if `configure` could abort
> or at least warn on not finding `-mfpu=neon` among CFLAGS if fortran was
> enabled.
> 

Strange - that shouldn't be happening and certainly looks like a bug - there
are a number of folks who bootstrap in Thumb mode and --with-fpu=vfpv3-d16
which is essentially the same as vfpv3 but with only 16 D registers. 

I'm not sure what's going on here.

[Bug tree-optimization/68105] optimizing repeated floating point addition to multiplication

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kugan at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from kugan at gcc dot gnu.org ---
Looks like a duplicate of PR63586.

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

[Bug tree-optimization/63586] x+x+x+x -> 4*x in gimple

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||zboson at zboson dot net

--- Comment #7 from kugan at gcc dot gnu.org ---
*** Bug 68105 has been marked as a duplicate of this bug. ***

[Bug target/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[ubizjak at gmail dot com]

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

--- Comment #29 from Uroš Bizjak  ---
Created attachment 38419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38419=edit
Patch to fix problematic splitters

I'm testing the attached patch that introduces
ix86_standard_x87sse_constant_load_p function, and uses it to limit problematic
splitters only to cases, where we can actually transform the insn to a constant
load.

[Bug other/70517] c++filt crashes when demangling a symbol

[blastrock at free dot fr]

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

blastrock at free dot fr changed:

   What|Removed |Added

  Attachment #38165|0   |1
is obsolete||
  Attachment #38166|0   |1
is obsolete||

--- Comment #3 from blastrock at free dot fr ---
Created attachment 38418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38418=edit
Very small test case

I investigated this bug a little more and managed to produce a very small test
case.

Compile this file with g++ 5.3.1 and clang 3.8 and you will get these two
symbols:

_Z4moveIRZ5awaitIRiEDaOT_EUlRKS3_E_ES4_S4_ from clang
_Z4moveIRZ5awaitIRiEDaOT_EUlRKS2_E_ES3_S3_ from gcc

When trying c++filt on the one got from gcc, it will just fail demangling it
and print it raw. But when we do it with the one produced by clang, we get a
crash. The only difference I see there is the substitutions which are shifted
by one on the clang version (I have no idea which compiler is right though).

I enabled the debug stuff from the demangle binary in libiberty and got this (I
added the addresses of the nodes for debugging):

0x7fffd620: typed name
  0x7fffd5d8: template
0x7fffd410: name 'move'
0x7fffd5c0: template argument list
  0x7fffd5a8: reference
0x7fffd590: local name
  0x7fffd518: typed name
0x7fffd488: template
  0x7fffd428: name 'await'
  0x7fffd470: template argument list
0x7fffd458: reference
  0x7fffd440: builtin type int
0x7fffd500: function type
  0x7fffd4a0: name 'auto'
  0x7fffd4e8: argument list
0x7fffd4d0: rvalue reference
  0x7fffd4b8: template parameter 0
  0x7fffd578: lambda 0
0x7fffd560: argument list
  0x7fffd548: reference
0x7fffd530: const
  0x7fffd4d0: rvalue reference
0x7fffd4b8: template parameter 0
  0x7fffd608: function type
0x7fffd530: const
  0x7fffd4d0: rvalue reference
0x7fffd4b8: template parameter 0
0x7fffd5f0: argument list
  0x7fffd530: const
0x7fffd4d0: rvalue reference
  0x7fffd4b8: template parameter 0

What I understand is that when libiberty goes down the first branch, the
"template parameter 0" references this same branch and so we get infinite
recursion. I guess we can at least prevent the crash if we keep in the state a
variable saying which template parameter we are referencing so that we don't go
down the same path infinitely.

My (de)mangling skills are still very low and I don't think I can solve this
one alone. Any help is appreciated.

[Bug middle-end/70960] [7 Regression] ICE: tree check: expected ssa_name, have integer_cst in ifcvt_walk_pattern_tree, at tree-if-conv.c:2465

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-05
  Known to work||6.1.0
Summary|[7.0 Regression] ICE: tree  |[7 Regression] ICE: tree
   |check: expected ssa_name,   |check: expected ssa_name,
   |have integer_cst in |have integer_cst in
   |ifcvt_walk_pattern_tree, at |ifcvt_walk_pattern_tree, at
   |tree-if-conv.c:2465 |tree-if-conv.c:2465
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Dominique d'Humieres  ---
The change occurred between revisions r235803 (OK) and r235816 (ICE).

[Bug middle-end/70960] New: [7.0 Regression] ICE: tree check: expected ssa_name, have integer_cst in ifcvt_walk_pattern_tree, at tree-if-conv.c:2465

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 70960
   Summary: [7.0 Regression] ICE: tree check: expected ssa_name,
have integer_cst in ifcvt_walk_pattern_tree, at
tree-if-conv.c:2465
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

recent trunk regression:

> cat bug.f90 
  SUBROUTINE calbrec(a,ai,error)
REAL(KIND=8):: a(3,3), ai(3,3)
DO i = 1, 3
   il = 1
   IF (i==1) il = 2
   DO j = 1, 3
  ai(j,i) = (-1.0_8)**(i+j)*det*(a(il,jl)*a(iu,ju)-a(il,ju)*a(iu,jl))
   END DO
END DO
  END SUBROUTINE calbrec

> gfortran -c -fprofile-generate -O3 bug.f90 
bug.f90:1:0:

   SUBROUTINE calbrec(a,ai,error)

internal compiler error: tree check: expected ssa_name, have integer_cst in
ifcvt_walk_pattern_tree, at tree-if-conv.c:2465
0xe42ad4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9753
0xc095d6 tree_check
../../gcc/gcc/tree.h:3025
0xc095d6 ifcvt_walk_pattern_tree
../../gcc/gcc/tree-if-conv.c:2465
0xc094e0 ifcvt_walk_pattern_tree
../../gcc/gcc/tree-if-conv.c:2491
0xc0edbe ifcvt_repair_bool_pattern
../../gcc/gcc/tree-if-conv.c:2580
0xc0edbe tree_if_conversion
../../gcc/gcc/tree-if-conv.c:2746
0xc0edbe execute
../../gcc/gcc/tree-if-conv.c:2829
0xc0edbe execute
../../gcc/gcc/tree-if-conv.c:2808
Please submit a full bug report,

> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data/vjoost/gnu/gcc_trunk/install/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160505 (experimental) [trunk revision 235918] (GCC)

[Bug c++/70810] std::function template variadic template arguments do not unpack in function template

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Here is a simplified version of your code which gives an error using GCC, Clang
and Intel icc:

template
  T declval();

template
  struct function {
template()(declval()...))>
  function(F) { }

void operator()(T...) const { }
  };


template
struct Invoker {
  void invoke(function f, Ts ... args) {
f(args ...);
  }
};

template
void invoke(function f, Ts ... args) {
  f(args ...);
}

struct string {
  string(const char*) { }
};

void foo(string, int) {
}

int main() {
  Invoker invoker;
  invoker.invoke(foo, "a", 1); // ok
  invoke(foo, "a", 1); // fail
}

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-05
  Component|target  |lto
  Known to work||5.3.0
Summary|regression in code  |[6/7 Regression] Wrong code
   |generation for  |generation for
   |__builtin_ms_va_list in GCC |__builtin_ms_va_list with
   |6.1 |-flto
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #4 from Dominique d'Humieres  ---
Confirmed.

[Bug c++/70810] std::function template variadic template arguments do not unpack in function template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
The compiler doesn't have to deduce the parameter pack Ts... in that example,
because it is provided explicitly here:

Invoker invoker;

and so the compiler knows the exact type of std::function here:

invoker.invoke(foo, "a", 1); // ok

without needing to deduce anything.

If Visual Studio compiles it then that seems like a bug in VC++ to me.

[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-05
 CC||tkoenig at gcc dot gnu.org
  Known to work||5.3.0
Summary|Invalid type determination  |[6/7 Regression] Invalid
   |due to expression in a type |type determination due to
   |declaration statement   |expression in a type
   ||declaration statement
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0
   Severity|major   |normal

--- Comment #2 from Dominique d'Humieres  ---
This is a regression due to r224190.

[Bug c/70954] -Wmisleading-indentation false positive on GNU "ed"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1

[zenith432 at users dot sourceforge.net]

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

zenith432 at users dot sourceforge.net changed:

   What|Removed |Added

  Component|c   |target

--- Comment #3 from zenith432 at users dot sourceforge.net ---
This only happens when compiling with -flto.

Attached is a standalone sample (va_main.c + va_test.c)

gcc -v
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/lto-wrapper
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.1.1 20160427 (Red Hat 6.1.1-1) (GCC) 

gcc -o prog va_main.c va_test.c
./prog
sum == 15

gcc -o prog_flto -flto va_main.c va_test.c
./prog_flto
Segmentation fault (core dumped)

[Bug c/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1

[zenith432 at users dot sourceforge.net]

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

--- Comment #2 from zenith432 at users dot sourceforge.net ---
Created attachment 38417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38417=edit
va_test.c

[Bug c/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1

[zenith432 at users dot sourceforge.net]

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

--- Comment #1 from zenith432 at users dot sourceforge.net ---
Created attachment 38416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38416=edit
va_main.c

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[rogero at howzatt dot demon.co.uk]

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

--- Comment #5 from Roger Orr  ---
Still fails with gcc 6.1

Are there any plans on how (and when) to fix this, fairly serious, fault?

[Bug tree-optimization/70956] ICE in build_cross_bb_scalars_def, at graphite-scop-detection.c:1725

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #1 from vries at gcc dot gnu.org ---
Consider graphite_find_cross_bb_scalar_vars:
...
static void
graphite_find_cross_bb_scalar_vars (scop_p scop, gimple *stmt,
vec *reads, vec *writes)
{
  tree def;

  if (gimple_code (stmt) == GIMPLE_ASSIGN)
def = gimple_assign_lhs (stmt);
  else if (gimple_code (stmt) == GIMPLE_CALL)
def = gimple_call_lhs (stmt);
  else if (gimple_code (stmt) == GIMPLE_PHI)
def = gimple_phi_result (stmt);
  else
return;


  build_cross_bb_scalars_def (scop, def, gimple_bb (stmt), writes);
  ...
...

We arrive at graphite_find_cross_bb_scalar_vars with:
...
(gdb) call debug_gimple_stmt (stmt)
# VUSE <.MEM_10(D)>
f2 (_1);
...

The call is resultless, so def becomes NULL_TREE.

This tentative patch handles NULL_TREE def in build_cross_bb_scalars_def, and
fixes the assert:
...
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
index 7615842..dd50a1e 100644
--- a/gcc/graphite-scop-detection.c
+++ b/gcc/graphite-scop-detection.c
@@ -1722,8 +1722,7 @@ static void
 build_cross_bb_scalars_def (scop_p scop, tree def, basic_block def_bb,
 vec *writes)
 {
-  gcc_assert (def);
-  if (!is_gimple_reg (def))
+  if (!def || !is_gimple_reg (def))
 return;

   /* Do not gather scalar variables that can be analyzed by SCEV as they can
be
...