[Bug c++/70163] C++ DR 257 constructor forward to virtual base class's constructor in an abstract class required

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
Also bug 53878.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Ian Lance Taylor  ---
I would guess that this problem is fixed now on trunk.  Please let me know if
not.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at gcc dot gnu.org]

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

--- Comment #10 from ian at gcc dot gnu.org  ---
Author: ian
Date: Sat Nov  5 00:21:33 2016
New Revision: 241868

URL: https://gcc.gnu.org/viewcvs?rev=241868=gcc=rev
Log:
PR go/78172.
libgo: avoid confusion in upcase_fields in mksysinfo.sh

The mksysinfo.sh script could get confused when there were multiple
types starting with the same name.  I believe this is the underlying
cause of GCC PR 78172.

Also redirect a grep to /dev/null to avoid extraneous messages during
the build.

Reviewed-on: https://go-review.googlesource.com/32821

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/mksysinfo.sh

[Bug c++/71848] [7 Regression] libstdc++ testsuite error on AIX

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Author: dje
Date: Fri Nov  4 23:20:50 2016
New Revision: 241863

URL: https://gcc.gnu.org/viewcvs?rev=241863=gcc=rev
Log:
PR bootstrap/78188
PR c++/71848
* ipa-comdats.c (pass_ipa_comdats::gate): Require HAVE_COMDAT_GROUP.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-comdats.c

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

--- Comment #24 from David Edelsohn  ---
Author: dje
Date: Fri Nov  4 23:20:50 2016
New Revision: 241863

URL: https://gcc.gnu.org/viewcvs?rev=241863=gcc=rev
Log:
PR bootstrap/78188
PR c++/71848
* ipa-comdats.c (pass_ipa_comdats::gate): Require HAVE_COMDAT_GROUP.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-comdats.c

[Bug target/77349] AIX DWARF debugging offset in 64 bit mode

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #4 from David Edelsohn  ---
Fixed.

[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> Created attachment 39966 [details]
> Fix for testcase in comment 9

Works as advertised.

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez  ---
This looks like a duplicate of pr77949, but I cannot confirm since I can't
reproduce it.  Since this looks like it could be white space or column
sensitive, could the reporter please include the testcase as an attachment, as
opposed to cut and pasted onto the bug report?  Thanks.

[Bug c++/78216] Segfault when dealing with a parameter pack of member functions pointers

[michele.caini at gmail dot com]

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

--- Comment #1 from Michele Caini  ---
Link to a question on SO:
http://stackoverflow.com/questions/40431236/gcc-ice-segfault-and-clang-compiles-just-fine-is-this-valid-code

I suspect the code is valid and should be accepted, but I'm not sure about
that.

[Bug c++/78216] New: Segfault when dealing with a parameter pack of member functions pointers

[michele.caini at gmail dot com]

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

Bug ID: 78216
   Summary: Segfault when dealing with a parameter pack of member
functions pointers
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michele.caini at gmail dot com
  Target Milestone: ---

The following code causes an ICE (segfault):

template
struct S;

template
struct S {
template
void f() {}
};

struct A { void f() {} };
struct B { void f() {} };

int main() {
S s;
s.f<::f, ::f>();
}

GCC 7 is affected by a similar problem (ICE with no segfault).

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de  ---
On November 4, 2016 8:09:15 PM GMT+01:00, "dje at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
>
>--- Comment #22 from David Edelsohn  ---
>There are two levels of set_comdat_group(). I am going to move the
>assert to
>cgraph.h and try to find what else is setting comdat groups.
>
>Do you want me to gate IPA comdat in the interim?

Yes, I think that makes sense to restore bootstrap

[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-04
 Ever confirmed|0   |1

--- Comment #11 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #9)
> No, I've also explained what to do about the u.fld thing.

Okay, I take that as your confirmation that the bug should be fixed.  I'll
leave the "how" to whomever is going to work on it.  The latest version of the
patch referenced in comment #0 doesn't trigger the warning so fixing it isn't
as pressing as when it did.

[Bug debug/56974] c++ ref qualifiers not represented in DWARF

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #11 from Jakub Jelinek  ---
Fixed for 7+.

[Bug debug/63243] [meta-bug] RH GDB project tracker

[jakub at gcc dot gnu.org]

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

Bug 56974 Summary: c++ ref qualifiers not represented in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974

   What|Removed |Added

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

[Bug other/78161] contrib/download_prerequisites fails on MacOS, Lubuntu, and Windows

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[7 Regression]  |contrib/download_prerequisi
   |contrib/download_prerequisi |tes fails on MacOS,
   |tes fails on MacOS, |Lubuntu, and Windows
   |Lubuntu, and Windows|

--- Comment #3 from Jakub Jelinek  ---
Dropping the regression flag then.

[Bug c++/77375] [5/6 Regression] constant object with mutable subobject allocated in read-only memory

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] constant |[5/6 Regression] constant
   |object with mutable |object with mutable
   |subobject allocated in  |subobject allocated in
   |read-only memory|read-only memory

--- Comment #8 from Jakub Jelinek  ---
Fixed for 7+ so far.

[Bug debug/28767] GCC should output DW_TAG_ptr_to_member for member functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Jakub Jelinek  ---
Fixed for 7+.

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug c++/77791] ICE on invalid C++11 code with redefined function parameter: tree check: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in cp_parser_lambda_declarator_opt, at

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug fortran/64933] ASSOCIATE on a character variable does not allow substring expressions

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Fri Nov  4 19:23:44 2016
New Revision: 241860

URL: https://gcc.gnu.org/viewcvs?rev=241860=gcc=rev
Log:
2016-04-19  Paul Thomas  

PR fortran/64933
* primary.c (gfc_match_varspec): If selector expression is
unambiguously an array, make sure that the associate name
is an array and has an array spec. Modify the original
condition for doing this to exclude character types.

2016-04-19  Paul Thomas  

PR fortran/64933
* gfortran.dg/associate_23.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_23.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77949] [7 Regression] ICE on invalid code in internal compiler error: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:907

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  ---
Caused by:

commit b65b8df248d4eb4801cbe16287cf32eda9325dec
Author: dmalcolm 
Date:   Tue Jul 5 15:50:54 2016 +

PR c++/62314: add fixit hint for "expected ';' after class definition"

gcc/cp/ChangeLog:
PR c++/62314
* parser.c (cp_parser_class_specifier_1): When reporting
missing semicolons, use a fixit-hint to suggest insertion
of a semicolon immediately after the closing brace,
offsetting the reported column accordingly.

gcc/testsuite/ChangeLog:
PR c++/62314
* gcc/testsuite/g++.dg/parse/error5.C: Update column
number of missing semicolon error.
* g++.dg/pr62314-2.C: New test case.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@238008
138bc75d-0d04-0410-96
1f-82ee72b054a4

[Bug tree-optimization/77860] [7 Regression] ICE in gimple_build_assign_1, at gimple.c:420

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  4 19:14:07 2016
New Revision: 241859

URL: https://gcc.gnu.org/viewcvs?rev=241859=gcc=rev
Log:
PR target/77834
* alias.c (nonoverlapping_memrefs_p): Return 0 if exprx or expry
doesn't have rtl set.

* gcc.dg/pr77834.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr77834.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

--- Comment #22 from David Edelsohn  ---
There are two levels of set_comdat_group(). I am going to move the assert to
cgraph.h and try to find what else is setting comdat groups.

Do you want me to gate IPA comdat in the interim?

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  ---
On November 4, 2016 3:30:55 PM GMT+01:00, "dje at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
>
>--- Comment #18 from David Edelsohn  ---
>Changing pass_ipa_comdats::gate to
>
>return HAVE_COMDAT_GROUP && optimize;
>
>does not experience the tree-vrp.c bootstrap failure and does not
>generate the
>numerous additional testsuite failures.
>
>There is one additional call to set_comdat_group() in cp/optimize.c,
>although
>that never triggered gcc_assert. And the testsuite failures are not
>ICEs.
>
>The call to set_comdat_group() in varasm.c:make_decl_one_only()
>apparently has
>some additional effect that allows the additional symbols to appear in
>libstdc++.

Hmm, so claiming decl-one-only w/o comdat support is likely broken.  That is,
something assumes comdat groups if make_decl_one_only succeeds.

Gating IPA comdat should be fine.

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

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 CC||ma...@linux-mips.org

--- Comment #11 from Maciej W. Rozycki  ---
TBH this does look like trying to rely on UB to me, as per section
6.5.6 "Additive operators" clause 8 of the C language standard, which
states (among others):

"If both the pointer operand and the result point to elements of the
same array object, or one past the last element of the array object,
the evaluation shall not produce an overflow; otherwise, the behavior
is undefined."

Here under the triggering conditions the pointer the integer is added
to with LDXC1 does not point to an element of the array operated on (or
to one past the last), so the hardware operation matches the standard's
semantics WRT overflow and I don't think we ought to be pushing it.

So it looks like a middle end bug to me and the backend is fine in
faithfully assuming its RTL pattern won't be passed operands leading to
UB.

Have I missed anything?

  Maciej

[Bug c++/67980] left shift count is negative [-Wshift-count-negative] generated for unreachable code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #7 from Paolo Carlini  ---
Fixed.

[Bug c++/67980] left shift count is negative [-Wshift-count-negative] generated for unreachable code

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Nov  4 18:58:53 2016
New Revision: 241858

URL: https://gcc.gnu.org/viewcvs?rev=241858=gcc=rev
Log:
/cp
2016-11-04  Paolo Carlini  

PR c++/67980
* pt.c (tsubst_expr, case IF_STMT): Use fold_non_dependent_expr
to suppress unwanted warnings.

/testsuite
2016-11-04  Paolo Carlini  

PR c++/67980
* g++.dg/cpp1y/pr67980.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr67980.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c/78215] aggressive-loop-optimizations undefined behavior warning does not trigger

[paf at cray dot com]

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

--- Comment #1 from Patrick Farrell  ---
Created attachment 39969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39969=edit
reproducer .c file

.c version of the reproducer

[Bug c/78215] New: aggressive-loop-optimizations undefined behavior warning does not trigger

[paf at cray dot com]

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

Bug ID: 78215
   Summary: aggressive-loop-optimizations undefined behavior
warning does not trigger
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paf at cray dot com
  Target Milestone: ---

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

On GCC 4.8.5 from Red Hat* and GCC 7.0.0 20161104** (built with only
--disable-multib option), the undefined behavior warning from
aggressive-loop-optimization does not trigger with certain loops.

gcc invocation:
gcc -g -Wall -O2 -Werror loop_error.c

The program (attached in both .c and .i versions) is a simple for loop with
undefined behavior, resulting in an infinite loop (i is an int, 'value' is an
unsigned long long):

for (i = 0; i < 2; i++) {
/* Remove this break and the compiler warns correctly -
 * Note there is no break in the original code. */
/* Overflow of signed int occurs at i = 205 */
if (i == 206)
break;
container->value = i * 1024 * 1024 *10;
printf("i: %d\n",i);
}

The compiler fails to warn on this construct and generates an infinite loop. 
The original code (which is much more complex and has dependencies) did not
have a 'break', but had a number of functional and print calls.  I was unable
to reproduce the problem without a break statement, but I believe it can be
done.

The compiler compiles the program as above/as attached without any
warnings/errors.  If the break is removed, it warns (-Werror is set):
./loop_error.c: In function ‘main’:
./loop_error.c:33:38: error: iteration 205u invokes undefined behavior
[-Werror=aggressive-loop-optimizations]
   container->value = i * 1024 * 1024 *10;
  ^
./loop_error.c:27:2: note: containing loop
  for (i = 0; i < 2; i++) {

So the bug is a failure to warn on undefined behavior in some cases.

*gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)

**gcc -v output:
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/home/build/gcc_install/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib
Thread model: posix
gcc version 7.0.0 20161104 (experimental) (GCC)

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> Sure, and in this case there are no implicit extensions to larger types. The
> bug does require an implicit extension to occur but this only happens at
> runtime when on 64-bit hardware and the core is not configured to be limited
> to a 32-bit address space which is always true for a 64-bit kernel as it
> turns out.

OK, if the compiler doesn't know that larger types are involved, then indeed it
cannot do anything to prevent implicit extensions.  Such a configuration needs
to define Pmode as DImode and ptr_mode as SImode for the compiler to work
properly.

[Bug libquadmath/78214] nanq() does not return a quiet NaN

[levim at php dot net]

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

--- Comment #1 from Levi Morrison  ---
Perhaps a less error-prone way to set that same bit is:

UINT64_C(0x1) << 47

Not sure what would be preferred.

[Bug libquadmath/78214] New: nanq() does not return a quiet NaN

[levim at php dot net]

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

Bug ID: 78214
   Summary: nanq() does not return a quiet NaN
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: levim at php dot net
  Target Milestone: ---

Created attachment 39967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39967=edit
Potential patch for the fix.

I compiled the following program, loaded it up in GDB and did a hex dump on the
nan:

#include 
int main(void) {
__float128 nan = nanq(NULL);
return 0;
}

The result looked like this:

0x7fffde40: 0x000x000x000x000x000x000x00   
0x00
0x7fffde48: 0x010x000x000x000x000x000xff   
0x7f

I have only recently started learning about NaN encodings so I may be wrong,
but I do believe that the above NaN is signalling, but the documentation for
`nanq` says it will return a quiet NaN. Shouldn't a quiet NaN look like this?

0x7fffde40: 0x000x000x000x000x000x000x00   
0x00
0x7fffde48: 0x000x000x000x000x000x800xff   
0x7f

It's easy to see from the source why it is this way:

#include "quadmath-imp.h"

__float128
nanq (const char *tagp __attribute__ ((unused)))
{
  // FIXME -- we should use the argument
  ieee854_float128 f;
  f.ieee.exponent = 0x7fff;
  f.ieee.mant_high = 0x1;
  return f.value;
}

The mant_high is set to 0x1 instead of something like 0x8000 (I think I
got the correct number of zeros there, anyway).

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

--- Comment #20 from David Edelsohn  ---
Using set_comdat_group(NULL) in varasm.c did not correct the testsuite
failures.  The only option that has worked so far is to disable ipa-comdat at
gate function.

[Bug c++/77949] [7 Regression] ICE on invalid code in internal compiler error: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:907

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-04
 CC||aldyh at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Aldy Hernandez  ---
Confirmed.  I'll take a peek.

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-04
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
I cannot reproduce on mainline.  I just get a compile error, not an ICE:

reynosa:/build/t$ cat /tmp/a.cc
 template class basic_string {   typedef typename
__gnu_cxx__alloc_traitstemplate  rebindother _Char_alloc_typepublic
   
 static const int npos = static_cast private  
template class num_get  public localefacettemplate  localeid
num_putid;;;;;;   
;;;;;;; }
# 1 "" 1

reynosa:/build/t$ ./install/bin/g++ -c /tmp/a.cc
/tmp/a.cc:1:63: error: expected nested-name-specifier before
‘__gnu_cxx__alloc_traitstemplate’
  template class basic_string {   typedef typename
__gnu_cxx__alloc_traitstemplate  rebindother _Char_alloc_typepublic
   
 static const int npos = static_cast private  
template class num_get  public localefacettemplate  localeid
num_putid;;;;;;   
;;;;;;; }

etc
etc
etc

Is this still reproducible on mainline, or can we close it?

[Bug target/78213] [7 Regression] -fself-test fails on aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Curiously the -fself-test succeeds during build and the command -fself-test -x
c /dev/null -S works as expected.
Perhaps it has something to do with whether/how much of the rtl is initialised
at the point the tests are run.

[Bug target/78213] [7 Regression] -fself-test fails on aarch64

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
I see.
init_emit explicitly sets:
REG_POINTER (virtual_incoming_args_rtx) = 1;

So I'd think that the /f appears on all targets then?

[Bug target/78213] [7 Regression] -fself-test fails on aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code
Summary|-fself-test fails on|[7 Regression] -fself-test
   |aarch64 |fails on aarch64

--- Comment #2 from Andrew Pinski  ---
/f on a reg does not mean frame related.  Rather it means:

REG_POINTER (x)
Nonzero in a reg if the register holds a pointer. Stored in the frame_related
field and printed as ‘/f’.

(In reply to ktkachov from comment #1)
> Since -fself-test was introduced for GCC 7.0 it's not really a regression

It is a regression since it was run during bootstrap or at least it was ...

[Bug target/78213] -fself-test fails on aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-checking
   Target Milestone|--- |7.0
  Known to fail||7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Since -fself-test was introduced for GCC 7.0 it's not really a regression

[Bug target/78213] New: -fself-test fails on aarch64

[ktkachov at gcc dot gnu.org]

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

Bug ID: 78213
   Summary: -fself-test fails on aarch64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

Running aarch64-none-linux-gnu-gcc -fself-test -S dummy.c gives an error:
$SRC/gcc/rtl-tests.c:96: test_dumping_regs: FAIL: ASSERT_STREQ (expected_dump,
dump) expected="(reg:DI virtual-incoming-args)" actual="(reg/f:DI
virtual-incoming-args)"
cc1: internal compiler error: in fail_formatted, at selftest.c:62
0x124bf56 selftest::fail_formatted(selftest::location const&, char const*, ...)
$SRC/gcc/selftest.c:62
0x124bfda selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
$SRC/gcc/selftest.c:86
0x1238de5 assert_rtl_dump_eq
$SRC/gcc/rtl-tests.c:73
0x1239449 test_dumping_regs
$SRC/gcc/rtl-tests.c:96
0x1239449 selftest::rtl_tests_c_tests()
$SRC/gcc/rtl-tests.c:193
0x11eee9e selftest::run_tests()
$SRC/gcc/selftest-run-tests.c:65
0xb4216b toplev::run_self_tests()
$SRC/gcc/toplev.c:2076
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Looks like the 'actual' dump has a /f on it indicating that it's a
frame-related RTX, causing the string comparison to fail

[Bug lto/78211] [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0

[Bug tree-optimization/78210] [7 regression] slsr-8.c scan-tree-dump-times optimized fails

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #5 from Bill Schmidt  ---
Ah, never mind that last comment.  This patch wasn't backported, so we don't
have to worry about that.

Thus, closing.

[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
Created attachment 39966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39966=edit
Fix for testcase in comment 9

The testcase in comment #10 seems to have been fixed by Andre.

After regtesting, I will commit this fix for comment#9 as obvious.

Paul

[Bug c++/71973] c++ handles built-in functions inconsistently

[edlinger at gcc dot gnu.org]

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

--- Comment #4 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Nov  4 15:30:52 2016
New Revision: 241846

URL: https://gcc.gnu.org/viewcvs?rev=241846=gcc=rev
Log:
2016-11-04  Bernd Edlinger  

PR c++/71973
* g++.dg/cpp1y/lambda-generic-udt.C: Fix builtin function declaration.
* g++.dg/init/new15.C: Likewise.
* g++.dg/ipa/inline-1.C: Likewise.
* g++.dg/ipa/inline-2.C: Likewise.
* g++.dg/lto/20080908-1_0.C: Likewise.
* g++.dg/tc1/dr20.C: Likewise.
* g++.dg/tree-ssa/inline-1.C: Likewise.
* g++.dg/tree-ssa/inline-2.C: Likewise.
* g++.old-deja/g++.law/except1.C: Likewise.
* g++.old-deja/g++.other/vbase5.C: Likewise.
* obj-c++.dg/lto/trivial-1_0.mm: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-udt.C
trunk/gcc/testsuite/g++.dg/init/new15.C
trunk/gcc/testsuite/g++.dg/ipa/inline-1.C
trunk/gcc/testsuite/g++.dg/ipa/inline-2.C
trunk/gcc/testsuite/g++.dg/lto/20080908-1_0.C
trunk/gcc/testsuite/g++.dg/tc1/dr20.C
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-1.C
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-2.C
trunk/gcc/testsuite/g++.old-deja/g++.law/except1.C
trunk/gcc/testsuite/g++.old-deja/g++.other/vbase5.C
trunk/gcc/testsuite/obj-c++.dg/lto/trivial-1_0.mm

[Bug tree-optimization/78210] [7 regression] slsr-8.c scan-tree-dump-times optimized fails

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Should be fixed now.  Please confirm and I will backport.  Thanks!

[Bug tree-optimization/78210] [7 regression] slsr-8.c scan-tree-dump-times optimized fails

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Nov  4 15:21:38 2016
New Revision: 241845

URL: https://gcc.gnu.org/viewcvs?rev=241845=gcc=rev
Log:
2016-11-04  Bill Schmidt  

PR tree-optimization/78210
* gcc.dg/tree-ssa/slsr-8.c: Fix slsr scan to include the
possibility of widening multiplies.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c

[Bug debug/78212] Fortran allocatable strings in derived type elements debug info

[jakub at gcc dot gnu.org]

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

Bug 71906 Summary: [6/7 Regression] Fortran allocatable strings debug info type 
size regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71906

   What|Removed |Added

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

[Bug debug/71906] [6/7 Regression] Fortran allocatable strings debug info type size regression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Regression should be fixed.

[Bug fortran/24546] [meta-bug] gfortran debugging problems

[jakub at gcc dot gnu.org]

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

Bug 71906 Summary: [6/7 Regression] Fortran allocatable strings debug info type 
size regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71906

   What|Removed |Added

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

[Bug debug/78212] New: Fortran allocatable strings in derived type elements debug info

[jakub at gcc dot gnu.org]

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

Bug ID: 78212
   Summary: Fortran allocatable strings in derived type elements
debug info
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jan.kratochvil at redhat dot com,
unassigned at gcc dot gnu.org
Depends on: 71906
Blocks: 24546
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #71906 +++

For:

program pr71906
  character(len=8) :: vard
  character(len=:), allocatable :: vare
  type t
character(len=:), allocatable :: f
  end type
  type(t) :: varf
  allocate(character(len=10) :: vare)
  allocate(character(len=9) :: varf%f)
  vare = 'foo'
  call foo (vard, vare, varf)
contains
  subroutine foo (vara, varb, varc)
character(len=*) :: vara
character(len=:), allocatable :: varb
type(t) :: varc
vara = 'bar'
varb = 'baz'
varc%f = 'str'
  end subroutine
end program pr71906

we still don't create usable debug info for the f field - and it is likely not
even expressible in dwarf5 right now.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug 24546] [meta-bug] gfortran debugging problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71906
[Bug 71906] [6/7 Regression] Fortran allocatable strings debug info type size
regression

[Bug tree-optimization/78210] [7 regression] slsr-8.c scan-tree-dump-times optimized fails

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-04
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
OK, I see what the issue is.  One of the multiplies is a widening multiply (w*
instead of *).  I can fix the test case.  The code generation is what we
expect.

Thanks for the report!

Bill

[Bug lto/78211] New: [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin

[burnus at gcc dot gnu.org]

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

Bug ID: 78211
   Summary: [7 Regression] -fcompare-debug failure with -flto
-fno-use-linker-plugin
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39965=edit
Test case: input19e.ii, compile with -fcompare-debug -flto
-fno-use-linker-plugin -O3

Using
   g++ -S -fcompare-debug -flto -fno-use-linker-plugin -O3 input19e.ii
gives
   g++: error: input19e.ii: -fcompare-debug failure

[Bug tree-optimization/78210] New: [7 regression] slsr-8.c scan-tree-dump-times optimized fails

[clyon at gcc dot gnu.org]

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

Bug ID: 78210
   Summary: [7 regression] slsr-8.c scan-tree-dump-times optimized
fails
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Created attachment 39963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39963=edit
fdump-tree-slsr-details

Since r241695,
gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " \\* " 9
fails on aarch64.

The generated assembly is:

.arch armv8-a
.file   "slsr-8.c"
.text
.align  2
.p2align 3,,7
.global f
.type   f, %function
f:
lsl w3, w0, 1
sbfiz   x3, x3, 2, 32
neg x3, x3
add x1, x1, x3
cmp x1, x2
add x3, x1, x3
sub x0, x1, x0, sxtw 4
cselx0, x0, x3, ne
ret
.size   f, .-f
.ident  "GCC: (GNU) 7.0.0 20161104 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/78210] [7 regression] slsr-8.c scan-tree-dump-times optimized fails

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
Created attachment 39964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39964=edit
slsr-8.c.223t.optimized

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

--- Comment #19 from David Edelsohn  ---
I will try

  if (HAVE_COMDAT_GROUP)
symbol->set_comdat_group (comdat_group);
  else  
symbol->set_comdat_group (NULL);

in varasm.c:make_decl_one_only().

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

--- Comment #18 from David Edelsohn  ---
Changing pass_ipa_comdats::gate to

return HAVE_COMDAT_GROUP && optimize;

does not experience the tree-vrp.c bootstrap failure and does not generate the
numerous additional testsuite failures.

There is one additional call to set_comdat_group() in cp/optimize.c, although
that never triggered gcc_assert. And the testsuite failures are not ICEs.

The call to set_comdat_group() in varasm.c:make_decl_one_only() apparently has
some additional effect that allows the additional symbols to appear in
libstdc++.

[Bug bootstrap/78188] [7 Regression] AIX Bootstrap broken by tree-vrp.c change

[dje at gcc dot gnu.org]

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

--- Comment #17 from David Edelsohn  ---
ld: 0711-317 ERROR: Undefined symbol: .std::allocator::allocator()
ld: 0711-317 ERROR: Undefined symbol: .std::__cxx11::basic_string::basic_string(char const*,
std::allocator const&)
ld: 0711-317 ERROR: Undefined symbol: .std::__cxx11::basic_string::~basic_string()
ld: 0711-317 ERROR: Undefined symbol: .std::allocator::~allocator()

[Bug c++/78209] New: rvalue reference binding to an lvalue accepted

[trippels at gcc dot gnu.org]

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

Bug ID: 78209
   Summary: rvalue reference binding to an lvalue accepted
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

This came up on the isocpp mailing list yesterday:

markus@x4 /tmp % cat test.ii
int main() {
  int & = 0;
  decltype(auto) j = i;
  return j;
}

markus@x4 /tmp % clang++ test.ii
test.ii:3:18: error: rvalue reference to type 'int' cannot bind to lvalue of
type 'int'
  decltype(auto) j = i;
 ^   ~
1 error generated.

markus@x4 /tmp % icpc test.ii
test.ii(3): error: an rvalue reference cannot be bound to an lvalue
decltype(auto) j = i;
   ^
compilation aborted for test.ii (code 2)

markus@x4 /tmp % g++ -Wall -Wextra test.ii
markus@x4 /tmp %

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
GCC by default looks to /usr/local unless you use with-local-prefix option.

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

[matthew.fortune at imgtec dot com]

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

--- Comment #9 from Matthew Fortune  ---
(In reply to Eric Botcazou from comment #8)
> > The expansion looks like an acceptable transformation to me i.e. it is not
> > introducing the overflow for the offending pointer just maintaining what is
> > already in the tree.
> 
> Wrap around for unsigned types is OK but, if expansion does implicit
> extensions to larger types, then things can easily go wrong.

Sure, and in this case there are no implicit extensions to larger types. The
bug does require an implicit extension to occur but this only happens at
runtime when on 64-bit hardware and the core is not configured to be limited to
a 32-bit address space which is always true for a 64-bit kernel as it turns
out.

> > I'm still not sure if there is really a bug. Should reassoc not be doing
> > this for 'sizetype'? Should ivopts not have created the mess in the first
> > place? Would changing either of these actually introduce an assurance that
> > this situation won't occur from other optimisations?
> 
> sizetype is unsigned so all the transformations looks valid.

I'm leaning heavily towards not-a-compiler-bug but may need to offer a
workaround until we can solve this in the Linux kernel.

The only workaround possible is to provide an option to disable register+index
addressing i.e. remove [ls][wd]xc1 instructions.

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
So I'll now test

Index: gcc/tree-if-conv.c
===
--- gcc/tree-if-conv.c  (revision 241802)
+++ gcc/tree-if-conv.c  (working copy)
@@ -2767,7 +2767,9 @@ tree_if_conversion (struct loop *loop)
  || loop->dont_vectorize))
 goto cleanup;

-  if ((any_pred_load_store || any_complicated_phi)
+  /* FIXME: When SLP vectorization can handle if-conversion on its own,
+ predicate all of if-conversion on flag_tree_loop_vectorize.  */
+  if ((any_pred_load_store || any_complicated_phi || flag_tree_loop_vectorize)
   && !version_loop_for_if_conversion (loop))
 goto cleanup;

[Bug sanitizer/78208] Compile-time hog with -fsanitize=null with operator overloading

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-04
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/78208] New: Compile-time hog with -fsanitize=null with operator overloading

[mpolacek at gcc dot gnu.org]

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

Bug ID: 78208
   Summary: Compile-time hog with -fsanitize=null with operator
overloading
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

// { dg-do compile }
// { dg-options "-fsanitize=null" }

class S
{
  virtual void foo () = 0;
};

struct T {
  T  << (const char *s);
};

T t;

void
S::foo ()
{
  t << "a" << "b" << "c" << "d" << "e" << "f" << "g" << "h" << "i"
<< "j" << "k" << "l" << "m" << "n" << "o" << "p" << "q" << "r"
<< "s" << "t" << "u" << "v" << "w" << "z";
}

generates insane amount of expressions in quadratic fashion.  I think we
shouldn't instrument CALL_EXPR_OPERATOR_SYNTAX.

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[howarth.at.gcc at gmail dot com]

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

--- Comment #1 from Jack Howarth  ---
Executing the failing configure test with the stage1 xgcc compiler appears as
follows...

# sandbox-exec -f
/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/x86_64-apple-darwin15.6.0/libgcc/fink.sb
/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/
-B/sw/lib/gcc5/x86_64-apple-darwin15.6.0/bin/
-B/sw/lib/gcc5/x86_64q-darwin15.6.0/lib/ -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.6.0/sys-include -c -g -O2 conftest.c -v
--save-temps
Reading specs from /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/specs
COLLECT_GCC=/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/xgcc
Target: x86_64-apple-darwin15.6.0
Configured with: ../gcc-5.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc5
--mandir=/sw/share/man --infodir=/sw/lib/gcc5/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--with-local-prefix=/usr/local --program-suffix=-fsf-5
Thread model: posix
gcc version 5.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.11.6' '-B'
'/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/' '-B'
'/sw/lib/gcc5/x86_64-apple-darwin15.6.0/bin/' '-B'
'/sw/lib/gcc5/x86_64q-darwin15.6.0/lib/' '-isystem'
'/sw/lib/gcc5/x86_64-apple-darwin15.6.0/include' '-isystem'
'/sw/lib/gcc5/x86_64-apple-darwin15.6.0/sys-include' '-c' '-g' '-O2' '-v'
'-save-temps' '-mtune=core2'
 /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/cc1 -E -quiet -v -iprefix
/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/
-isystem /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/include -isystem
/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/include-fixed -D__DYNAMIC__
-isystem /sw/lib/gcc5/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.6.0/sys-include conftest.c -fPIC
-feliminate-unused-debug-symbols -mmacosx-version-min=10.11.6 -mtune=core2 -g
-fworking-directory -O2 -fpch-preprocess -o conftest.i
ignoring nonexistent directory "/sw/lib/gcc5/x86_64-apple-darwin15.6.0/include"
ignoring nonexistent directory
"/sw/lib/gcc5/x86_64-apple-darwin15.6.0/sys-include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/include-fixed"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/../../../../x86_64-apple-darwin15.6.0/include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/../../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/include"
cc1: error: /usr/local/include: Operation not permitted
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/../../include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/../../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/include-fixed"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/../../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/../../../../x86_64-apple-darwin15.6.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/include
 /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
(In reply to rguent...@suse.de from comment #10)
> On Fri, 4 Nov 2016, wschmidt at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848
> > 
> > --- Comment #8 from Bill Schmidt  ---
> > FYI, the patch I am testing is:
> > 
> > Index: gcc/tree-if-conv.c
> > ===
> > --- gcc/tree-if-conv.c  (revision 241802)
> > +++ gcc/tree-if-conv.c  (working copy)
> > @@ -2767,8 +2767,7 @@ tree_if_conversion (struct loop *loop)
> >   || loop->dont_vectorize))
> >  goto cleanup;
> > 
> > -  if ((any_pred_load_store || any_complicated_phi)
> > -  && !version_loop_for_if_conversion (loop))
> > +  if (flag_tree_loop_vectorize && !version_loop_for_if_conversion (loop))
> >  goto cleanup;
> 
> can any_pred_load_store or any_complicated_phi never be true without
> flag_tree_loop_vectorize?

It's quite possible, I'm not sure.  I was trying to remove all preconditions
for doing if-conversion, but without the test for flag_tree_loop_vectorize I
ran into failures in the test suite for -O2 -ftree-if-conversion or whatever it
is.

> 
> Btw, I think we should simply guard if-conversion with
> flag_tree_loop_vectorize... (given it has no cost model)

Seems that can work if we can make SLP vectorization handle the
PHI-convertibles on its own without if-conversion, as you suggested, but until
then it will lose some SLP opportunities.

By the way, outer loop vectorization is failing because of

  if ((loop->inner)->inner || (loop->inner)->next)
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "not vectorized: multiple nested loops.\n");
  return false;
}

The versioned inner loop has two loops, so we don't even consider it further.

Bill

> 
> Richard.
> 
> >/* Now all statements are if-convertible.  Combine all the basic
> > 
> >

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Fri, 4 Nov 2016, wschmidt at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848
> 
> --- Comment #8 from Bill Schmidt  ---
> FYI, the patch I am testing is:
> 
> Index: gcc/tree-if-conv.c
> ===
> --- gcc/tree-if-conv.c  (revision 241802)
> +++ gcc/tree-if-conv.c  (working copy)
> @@ -2767,8 +2767,7 @@ tree_if_conversion (struct loop *loop)
>   || loop->dont_vectorize))
>  goto cleanup;
> 
> -  if ((any_pred_load_store || any_complicated_phi)
> -  && !version_loop_for_if_conversion (loop))
> +  if (flag_tree_loop_vectorize && !version_loop_for_if_conversion (loop))
>  goto cleanup;

can any_pred_load_store or any_complicated_phi never be true without
flag_tree_loop_vectorize?

Btw, I think we should simply guard if-conversion with
flag_tree_loop_vectorize... (given it has no cost model)

Richard.

>/* Now all statements are if-convertible.  Combine all the basic
> 
>

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Fri, 4 Nov 2016, wschmidt at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848
> 
> --- Comment #7 from Bill Schmidt  ---
> OK, I will try to get some machine time to do performance testing of the
> existing patch as soon as possible.
> 
> Here is the list of failures:
> 
> > FAIL: gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects  
> > scan-tree-dump-times slp1 "basic block vectorized" 1
> > FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times slp1 "basic block 
> > vectorized" 1
> 66a69,76
> > FAIL: gcc.dg/vect/vect-cond-1.c -flto -ffat-lto-objects  
> > scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
> > FAIL: gcc.dg/vect/vect-cond-1.c scan-tree-dump-times vect "OUTER LOOP 
> > VECTORIZED" 1
> > FAIL: gcc.dg/vect/vect-cond-3.c -flto -ffat-lto-objects  
> > scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
> > FAIL: gcc.dg/vect/vect-cond-3.c scan-tree-dump-times vect "OUTER LOOP 
> > VECTORIZED" 1
> > FAIL: gcc.dg/vect/vect-cond-4.c -flto -ffat-lto-objects  
> > scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
> > FAIL: gcc.dg/vect/vect-cond-4.c scan-tree-dump-times vect "OUTER LOOP 
> > VECTORIZED" 1
> > FAIL: gcc.dg/vect/vect-cond-6.c -flto -ffat-lto-objects  
> > scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
> > FAIL: gcc.dg/vect/vect-cond-6.c scan-tree-dump-times vect "OUTER LOOP 
> > VECTORIZED" 1

Ok, so that's outer loop vect not handling the if (LOOP_VECTORIZED ()) 
case -- if-conversion only handles innermost loops but the vectorizer
handles a single outer loop.  This means the if (LOOP_VECTORIZED ())
would need to be put on the outer loop or outer loop vectorization
would need to handle it in some way.  I think we already disable
outer loop vectorization when sth forces LOOP_VECTORIZED () for
if-conversion.  I think "ignoring" LOOP_VECTORIZED and its associated
CFG in outer loop vectorization and folding it away before transform
might work...  (we also fail to if-convert the "outer" loop btw).
See vect_analyze_loop_form_1 for what loop form we expect for outer
loop vectorization.

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
FYI, the patch I am testing is:

Index: gcc/tree-if-conv.c
===
--- gcc/tree-if-conv.c  (revision 241802)
+++ gcc/tree-if-conv.c  (working copy)
@@ -2767,8 +2767,7 @@ tree_if_conversion (struct loop *loop)
  || loop->dont_vectorize))
 goto cleanup;

-  if ((any_pred_load_store || any_complicated_phi)
-  && !version_loop_for_if_conversion (loop))
+  if (flag_tree_loop_vectorize && !version_loop_for_if_conversion (loop))
 goto cleanup;

   /* Now all statements are if-convertible.  Combine all the basic

[Bug c++/78198] ICE on valid code in: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_base, at cp/search.c:203

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Jason Merrill from comment #6)
> Fixed.

Thanks for the fast fix. The PR has block compilation of Firefox.

[Bug c++/78198] ICE on valid code in: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_base, at cp/search.c:203

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
OK, I will try to get some machine time to do performance testing of the
existing patch as soon as possible.

Here is the list of failures:

> FAIL: gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects  
> scan-tree-dump-times slp1 "basic block vectorized" 1
> FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times slp1 "basic block 
> vectorized" 1
66a69,76
> FAIL: gcc.dg/vect/vect-cond-1.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "OUTER LOOP VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-cond-1.c scan-tree-dump-times vect "OUTER LOOP 
> VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-cond-3.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "OUTER LOOP VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-cond-3.c scan-tree-dump-times vect "OUTER LOOP 
> VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-cond-4.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "OUTER LOOP VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-cond-4.c scan-tree-dump-times vect "OUTER LOOP 
> VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-cond-6.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "OUTER LOOP VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-cond-6.c scan-tree-dump-times vect "OUTER LOOP 
> VECTORIZED" 1

[Bug ada/78207] New: outdated comment outlining wrong edition of REs in g-regexp.ads (GNAT.Regexp) for GNAT.Regpat

[georggcc at googlemail dot com]

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

Bug ID: 78207
   Summary: outdated comment outlining wrong edition of REs in
g-regexp.ads (GNAT.Regexp) for GNAT.Regpat
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: georggcc at googlemail dot com
  Target Milestone: ---

The introductory comment in GNAT.Regexp about GNAT.Regpat states
that the latter is an implementation of V7 regular expressions
using the same internal data structures are Henry Spencer's.

It used to be/do, I think, but now is a Perloid extension.
The comment within package GNAT.Regpat proper (g-regpat.ads)
reflects this. I think the comment in the "overarching"
package GNAT.Regexp has not been updated.

[Bug c++/78198] ICE on valid code in: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_base, at cp/search.c:203

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Nov  4 12:47:01 2016
New Revision: 241843

URL: https://gcc.gnu.org/viewcvs?rev=241843=gcc=rev
Log:
PR c++/78198 - inherited template ctor with default arg

* call.c (convert_default_arg): Look through inheriting ctors.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor22.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug driver/78206] New: bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[howarth.at.gcc at gmail dot com]

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

Bug ID: 78206
   Summary: bootstrap failure under Apple sandbox that blacklists
reads in /usr/local
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth.at.gcc at gmail dot com
  Target Milestone: ---

I ran into a rather interesting bootstrap failure for all FSF gcc releases when
performed under an Apple sandbox configured to blacklist reads in /usr/local.
The libgcc configure run using the stage1 xgcc compiler fails with the error...

configure:3462: /sw/src/fink.build/gcc6-6.2.0-2/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc6-6.2.0-2/darwin_objdir/./gcc/
-B/sw/lib/gcc6/x86_64-apple-darwin15.6.0/bin/
-B/sw/lib/gcc6/x86_64-apple-darwin15.6.0/lib/ -isystem
/sw/lib/gcc6/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc6/x86_64-apple-darwin15.6.0/sys-include-o conftest -g -O2  
conftest.c  >&5
cc1: error: /usr/local/include: Operation not permitted

This bootstrap failure is suppressed if the configure option
--with-local-prefix=/sw or --with-local-prefix=/ is passed under the sandbox
build.

I assume cc1 is performing an stat() call on the /usr/include directory which
fails  in an unrecoverable manner due to the sandbox.

Note the Apple sandbox in this case was run with 'sandbox-exec -f fink.sb'
where the fink.sb file contained...

(version 1)

(allow default)

(deny file*
   (subpath "/usr/local")
)

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Not costing redundant permutations (using a too trival implementation but good
enough for this case):

t.f90:158:0: note: Cost model analysis:
  Vector inside of basic block cost: 984
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 616
t.f90:158:0: note: not vectorized: vectorization is not profitable.

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> The expansion looks like an acceptable transformation to me i.e. it is not
> introducing the overflow for the offending pointer just maintaining what is
> already in the tree.

Wrap around for unsigned types is OK but, if expansion does implicit extensions
to larger types, then things can easily go wrong.

> I'm still not sure if there is really a bug. Should reassoc not be doing
> this for 'sizetype'? Should ivopts not have created the mess in the first
> place? Would changing either of these actually introduce an assurance that
> this situation won't occur from other optimisations?

sizetype is unsigned so all the transformations looks valid.

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
Ok, so fixing the accounting to disregard obviously dead loads gets us to

t.f90:158:0: note: Cost model analysis:
  Vector inside of basic block cost: 1224
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 616
t.f90:158:0: note: not vectorized: vectorization is not profitable.

that still doesn't account for the redundant ones... (we still emit those
so we conservatively assume no CSE here).  I suppose the "simple" way
of costing permutation might be the real issue here though.

Permutations like { 58, 58, 58, 58 } are also vectorized badly
(and costed accordingly).  Likewise { 4, 5, 4, 5 } is costed as
permutation.

Not counting non-permutations improves things to

t.f90:158:0: note: Cost model analysis:
  Vector inside of basic block cost: 1080
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 616
t.f90:158:0: note: not vectorized: vectorization is not profitable.

So there is room for improvement but this was the "easy" parts (for the
rest also more analysis is required).  Likely there's some CSE inbetween
the SLP instances involved.

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

[matthew.fortune at imgtec dot com]

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

--- Comment #7 from Matthew Fortune  ---
(In reply to Eric Botcazou from comment #6)
> > The issue may stem from the C front end where the dumps start off as below.
> > Note that the '-1' in kappa-1 has ended up being represented as 1073741823
> > (0x3fff) presumably owing to the fact it will be multiplied by 4
> > eventually and hence be 'safe'.
> 
> All pointer calculations are done in sizetype and it is unsigned.  This kind
> of issues generally come from the RTL level, maybe expansion here.

The expansion looks like an acceptable transformation to me i.e. it is not
introducing the overflow for the offending pointer just maintaining what is
already in the tree.

I dug back to reassoc2 based on Andrew's comment which gets the following as
input:

  _48 = (sizetype) kappa_6(D);
  _49 = _48 * 8;
  _50 = s_37(D) + _49;
  ivtmp.19_47 = (unsigned int) _50

and then in the loop:

  _54 = (sizetype) s_37(D);
  _55 = ivtmp.19_3 - _54;
  _56 = _55 + 4294967280;
  # RANGE [0, 4294967295] NONZERO 4294967288
  _19 = _56;
  # PT = nonlocal escaped 
  _20 = _17 + _19;
  # VUSE <.MEM_4>
  _21 = *_20

This includes a pointer subtraction of 's' (somewhat pointless but valid I
believe).

reassoc2 changes it to this:

  _48 = (sizetype) kappa_6(D);
  _49 = _48 * 8;
  _50 = s_37(D) + _49;
  ivtmp.19_47 = (unsigned int) _50;

and in the loop:

  _54 = (sizetype) s_37(D);
  _38 = -_54;
  _25 = 4294967280 - _54;
  _56 = _25 + ivtmp.19_3;
  # RANGE [0, 4294967295] NONZERO 4294967288
  _19 = _56;
  # PT = nonlocal escaped 
  _20 = _17 + _19;
  # VUSE <.MEM_4>
  _21 = *_20;

And _56 is where we get the overflow.

I'm still not sure if there is really a bug. Should reassoc not be doing this
for 'sizetype'? Should ivopts not have created the mess in the first place?
Would changing either of these actually introduce an assurance that this
situation won't occur from other optimisations?

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[dominiq at lps dot ens.fr]

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

--- Comment #20 from Dominique d'Humieres  ---
> (maybe you can benchmark with -fno-vect-cost-model?)

Compiling the code in comment 0 with -fno-vect-cost-model leads to

% grep mulpd pr37150.s | wc -l
 142
% grep mulsd pr37150.s | wc -l
   0

[Bug target/78199] [PowerPC] Missing optimization for local-exec TLS model

[sebastian.hu...@embedded-brains.de]

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

--- Comment #1 from Sebastian Huber  ---
A native 64-bit PowerPC GCC built on

uname -a
Linux gcc2-power8.osuosl.org 3.17.4-301.fc21.ppc64le #1 SMP Mon Dec 1 07:51:01
UTC 2014 ppc64le ppc64le ppc64le GNU/Linux

generates this

gcc -O2 -ftls-model=local-exec -S tls.c -o -
.file   "tls.c"
.machine power8
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl fi
.type   fi, @function
fi:
addis 9,13,i@tprel@ha
addi 9,9,i@tprel@l
lwa 3,0(9)
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   fi,.-fi
.section".toc","aw"
.align 3
.LC0:
.quad   s
.section".text"
.align 2
.p2align 4,,15
.globl fs
.type   fs, @function
fs:
.LCF1:
0:  addis 2,12,.TOC.-.LCF1@ha
addi 2,2,.TOC.-.LCF1@l
.localentry fs,.-fs
addis 9,2,.LC0@toc@ha   # gpr load fusion, type long
ld 9,.LC0@toc@l(9)
lwa 3,0(9)
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   fs,.-fs
.ident  "GCC: (GNU) 7.0.0 20161030 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
We do find SLP opportunities but in the end fail to vectorize with AVX2
because of

t.f90:158:0: note: BB vectorization with gaps at the end of a load is not
supported
t.f90:158:0: note: not vectorized: relevant stmt not supported: _1477 =
*pol_y_1422(D)[_675];
t.f90:158:0: note: removing SLP instance operations starting from: coef_x[0] =
_1604;

  /* ???  The following is overly pessimistic (as well as the loop
 case above) in the case we can statically determine the excess
 elements loaded are within the bounds of a decl that is accessed.
 Likewise for BB vectorizations using masked loads is a possibility. 
*/
  if (bb_vinfo && slp_perm && group_size % nunits != 0)
{
  dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
   "BB vectorization with gaps at the end of a load "
   "is not supported\n");
  return false;
}

this is possibly because we initially detect quite large groups which are
later split for proper SLP detection into smaller units (but that splitting
does only split the store groups, not the load groups that end up being used).
This means we get SLP permutation to trigger (looks even required for the
case I'm looking at which has a {4, 4, 5, 5} permutation but which obviously
only needs a single element and thus would have no issue with "gaps").

Basically this means how we perform load permutation in SLP should be rewritten
(and/or we should also try to split the load groups if all uses can agree
on a set -- remember we key groups on stmts and thus can't have multiple
groups for a stmt...).

We _do_ vectorize this with SSE2 vectors if you disable the cost model,
thus rejection is only because:

t.f90:158:0: note: Cost model analysis:
  Vector inside of basic block cost: 9408
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 616

note we have a lot of SLP instances in this basic block and thus some
of the cost analysis might be totally off (I suspect we are again confused
by the large load groups and our SLP permutation handling there).

  /* And adjust the number of loads performed.  */
  unsigned nunits
= TYPE_VECTOR_SUBPARTS (STMT_VINFO_VECTYPE (stmt_info));
  ncopies_for_cost
= (GROUP_SIZE (stmt_info) - GROUP_GAP (stmt_info)
   + nunits - 1) / nunits;
  ncopies_for_cost *= SLP_INSTANCE_UNROLLING_FACTOR (instance);

first of all it doesn't consider CSE between the SLP instances, second
it also counts loads that will be dead after the permutation has been
applied.  So it's a very conservative estimate.  Let me see if I can
improve things here.  The vectorization _does_ seem to look profitable
(maybe you can benchmark with -fno-vect-cost-model?)

[Bug sanitizer/78204] ‘no_sanitize’ attribute directive ignored [-Wattributes]

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Severity|normal  |enhancement

--- Comment #3 from Martin Liška  ---
As I'm reading the source code, there's no option to do that.
Apart from 'no_sanitize' attribute, GCC supports 'no_sanitize_undefined'
attribute (clang does not) and clang has 'no_sanitize_memory' (not handled by
GCC).

I welcome the ability to have finer attributes for sanitizer and I can do that.
What's Jakub thinking about it?

[Bug tree-optimization/78205] New: BB vectorization confused by too large load groups

[rguenth at gcc dot gnu.org]

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

Bug ID: 78205
   Summary: BB vectorization confused by too large load groups
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---

double x, a[4], b[4], c[5];

void foo ()
{
  a[0] = c[0];
  a[1] = c[1];
  a[2] = c[0];
  a[3] = c[1];
  b[0] = c[2];
  b[1] = c[3];
  b[2] = c[2];
  b[3] = c[3];
  x = c[4];
}

if you comment the load from c[4] the testcase will be vectorized.  If not the
we run into

  /* ???  The following is overly pessimistic (as well as the loop
 case above) in the case we can statically determine the excess
 elements loaded are within the bounds of a decl that is accessed.
 Likewise for BB vectorizations using masked loads is a possibility. 
*/
  if (bb_vinfo && slp_perm && group_size % nunits != 0)
{
  dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
   "BB vectorization with gaps at the end of a load "
   "is not supported\n");
  return false;
}


I do have a hackish patch.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug sanitizer/78204] ‘no_sanitize’ attribute directive ignored [-Wattributes]

[jan.kratochvil at redhat dot com]

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

--- Comment #2 from Jan Kratochvil  ---
Yes, that would be the best, to stay compatible with clang.
Or is there some other way how to disable -fsanitize=float-divide-by-zero only
for one function / block of code?

[Bug sanitizer/78204] ‘no_sanitize’ attribute directive ignored [-Wattributes]

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-04
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Ok, do I understand it properly that you're missing support of
no_sanitize("string literals"), as defined here:

http://clang.llvm.org/docs/AttributeReference.html#no-sanitize-clang-no-sanitize

[Bug sanitizer/78204] New: ‘no_sanitize’ attribute directive ignored [-Wattributes]

[jan.kratochvil at redhat dot com]

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

Bug ID: 78204
   Summary: ‘no_sanitize’ attribute directive ignored
[-Wattributes]
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

g++ -o 44 44.C -Wall -g -fsanitize=bool -fsanitize=float-divide-by-zero;./44
-
int intzero(0);
//__attribute__((no_sanitize_undefined))
__attribute__((no_sanitize("float-divide-by-zero")))
int main() {
  union { char c; bool b; } u={42};
  double d(double(10)/intzero);
  return u.b + d;
}
-
gcc-6.2.1-2.fc24.x86_64
clang 1:3.8-34 Ubuntu x86_64
 - Fedora clang does not support ubsan
-
//__attribute__((no_sanitize_undefined))
__attribute__((no_sanitize("float-divide-by-zero")))
FAIL gcc: I want to suppress the "division by zero" message.
44.C:4:10: warning: ‘no_sanitize’ attribute directive ignored [-Wattributes]
 int main() {
44.C:6:22: runtime error: division by zero
44.C:7:12: runtime error: load of value 42, which is not a valid value for type
'bool'
PASS clang++:
44.C:7:12: runtime error: load of value 42, which is not a valid value for type
'bool'
-
__attribute__((no_sanitize_undefined))
//__attribute__((no_sanitize("float-divide-by-zero")))
FAIL gcc: Missing "load of value 42, which is not a valid value for type
'bool'"
-

[Bug c++/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[yroux at gcc dot gnu.org]

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

--- Comment #2 from Yvan Roux  ---
Hi Richard,

sorry for the lack of context, here is the full backtrace:

reduced.C: In function 'void f()':
reduced.C:7:8: internal compiler error: in tree_to_shwi, at tree.c:7313
   char a[e] = "";
^
0x1007a32 tree_to_shwi(tree_node const*)
.../gcc.git~master/gcc/tree.c:7313
0x105bffa default_use_anchors_for_symbol_p(rtx_def const*)
.../gcc.git~master/gcc/varasm.c:6810
0x9e8776 use_anchored_address(rtx_def*)
.../gcc.git~master/gcc/explow.c:549
0xa0e148 expand_expr_addr_expr_1
.../gcc.git~master/gcc/expr.c:7729
0xa00e6c expand_expr_addr_expr
.../gcc.git~master/gcc/expr.c:7920
0xa00e6c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
.../gcc.git~master/gcc/expr.c:10998
0x8ca22e expand_expr
.../gcc.git~master/gcc/expr.h:279
0x8ca22e get_memory_rtx
.../gcc.git~master/gcc/builtins.c:1279
0x8ce361 expand_builtin_memcpy_args
.../gcc.git~master/gcc/builtins.c:2995
0x8da0ea expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
.../gcc.git~master/gcc/builtins.c:6236
0xa01135 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
.../gcc.git~master/gcc/expr.c:10773
0x8fb8cc expand_expr
.../gcc.git~master/gcc/expr.h:279
0x8fb8cc expand_call_stmt
.../gcc.git~master/gcc/cfgexpand.c:2668
0x8fb8cc expand_gimple_stmt_1
.../gcc.git~master/gcc/cfgexpand.c:3581
0x8fb8cc expand_gimple_stmt
.../gcc.git~master/gcc/cfgexpand.c:3747
0x8fd410 expand_gimple_basic_block
.../gcc.git~master/gcc/cfgexpand.c:5754
0x9026e6 execute
.../gcc.git~master/gcc/cfgexpand.c:6368

A quick check shows that using tree_to_uhwi instead of tree_to_shwi fixes the
issue, but I'll look calling site as well.

[Bug fortran/68600] Inlined MATMUL is too slow.

[tkoenig at gcc dot gnu.org]

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

--- Comment #14 from Thomas Koenig  ---
Question: Would it make sense to add an option so that only
matrices with size known at compile-time are inlined?

Somethin like

-finline-matmul-size-var=0 (to disable), -finline-matmul-size-fixed=5
(to inline for fixed size up to 5 only).

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
> Still a current issue?

The test in comment 0 is not vectorized with trunk (7.0) at r241833.

[Bug c++/78198] ICE on valid code in: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_base, at cp/search.c:203

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
The code is rejected by clang 3.8.1:
clang++ pr78198.cpp -c -std=gnu++11
pr78198.cpp:8:12: error: expected ')'
D(aArgs...);
   ^
pr78198.cpp:8:6: note: to match this '('
D(aArgs...);
 ^
pr78198.cpp:8:7: error: redefinition of 'aArgs'
D(aArgs...);
  ^
pr78198.cpp:7:74: note: previous definition is here
template C::SingleObject MakeUnique(Args... aArgs)
{
 ^
pr78198.cpp:16:17: error: ISO C++11 does not allow access declarations; use
using declarations instead
BufferList::BufferList;
^
using 
3 errors generated.

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #17 from Thomas Koenig  ---
Still a current issue?

[Bug fortran/78122] [5/6/7 Regression] ICE in get, at cgraph.h:395

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Ok, problem is that Fortran FE decides to make p STATIC in:

  /* Derived types are a bit peculiar because of the possibility of
 a default initializer; this must be applied each time the variable
 comes into scope it therefore need not be static.  These variables
 are SAVE_NONE but have an initializer.  Otherwise explicitly
 initialized variables are SAVE_IMPLICIT and explicitly saved are
 SAVE_EXPLICIT.  */
  if (!sym->attr.use_assoc
&& (sym->attr.save != SAVE_NONE || sym->attr.data
|| (sym->value && sym->ns->proc_name->attr.is_main_program)
|| (flag_coarray == GFC_FCOARRAY_LIB
&& sym->attr.codimension && !sym->attr.allocatable)))
TREE_STATIC (decl) = 1;

and thus call graph is unhappy as there's a reference between a varpool symbol
and a local variable. I quess it must be fixed in the FE.

[Bug tree-optimization/78185] [5/6 Regression] Wrong branch optimization with -O1 on x86/x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.4.7, 7.0
   Target Milestone|--- |5.5
Summary|Wrong branch optimization   |[5/6 Regression] Wrong
   |with -O1 on x86/x86_64  |branch optimization with
   ||-O1 on x86/x86_64
  Known to fail||4.5.4, 4.6.4, 4.7.4, 4.8.5,
   ||4.9.4, 5.4.0, 6.2.0

--- Comment #8 from Richard Biener  ---
Fixed on trunk.  Earlier releases need -O2 to trigger this.  Can't reproduce
with 4.4 or earlier.

[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Nov  4 08:54:42 2016
New Revision: 241841

URL: https://gcc.gnu.org/viewcvs?rev=241841=gcc=rev
Log:
2016-11-04  Richard Biener  

PR middle-end/78185
* loop-invariant.c (find_exits): Record entering inner
loops as possibly exiting to handle infinite sub-loops.
* tree-ssa-loop-im.c: Include tree-ssa-loop-niter.h.
(fill_always_executed_in_1): Honor infinite child loops.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr78185.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-invariant.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-im.c

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #39960|0   |1
is obsolete||

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

Ignore what I wrote in the last 2 comments, it turned out to be a DSE (step5)
bug in the end.

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
http://gcc.opensuse.org/SPEC/CINT/sb-czerny-head-64-2006/index.html

confirms the regression (even bigger with -Ofast -flto -march=native which
is a skylake here).  Likewise
http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64-2006/index.html (though
peak makes it hard to spot in the graph).

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |WAITING
Version|tree-ssa|7.0
   Keywords||missed-optimization
   Last reconfirmed||2016-11-04
  Component|tree-optimization   |rtl-optimization
 CC|richard.guenther at gmail dot com  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|[7 regression]: 429.mcf of  |[7 Regression] 429.mcf of
   |cpu2006 regresses in GCC|cpu2006 regresses in GCC
   |trunk for avx2 target.  |trunk for avx2 target.
   Target Milestone|--- |7.0

--- Comment #2 from Richard Biener  ---
The issue is the missed cmp-and-branch fusion which you should a) enable in the
first place like via -mtune=bdver4 b) is appearantly made impossible/hard by
changes in original RTL expansion with regard to a complex condition.

Please attach a testcase.

[Bug c++/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
DECL_SIZE is always sizetype (unsigned), so using tree_to_shwi looks odd.  Of
course this is a local object on the stack which never should use anchors
so the fix should be in the caller (which you omit from the stack trace).

[Bug c++/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64, arm
   Target Milestone|--- |7.0