[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[dave.anglin at bell dot net]

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

--- Comment #17 from dave.anglin at bell dot net ---
On 2016-07-12, at 12:36 PM, bugzilla-gcc at thewrittenword dot com wrote:

>>  don't have any ia64 hardware and I also don't have an 11.31 box.  So,
>> there's a support issue for ia64 and 11.31.  Albert, if you or one of
>> your staff could help in this regard, I would support the addition of
>> a new hpux maintainer.
> 
> We can provide access to HP-UX 11.23/ia and 11.31/ia. Sadly, apart from
> building GCC, we don't have any intricate ia64 knowledge to help with
> maintainership.

What I was hoping for was someone to handle the hpux aspect on ia64.  Do
occasional builds and tests, etc.  I think Jim and others can handle the code
generation aspects.

I do hppa in my spare time and don't have the time to do more.  This included
working
with Helge Deller to get hppa in Debian ports.  The same needs to occur for
ia64
but so far no one has stepped up.

Dave
--
John David Anglin   dave.ang...@bell.net

[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[uros at gcc dot gnu.org]

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

--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jul 12 22:06:51 2016
New Revision: 238268

URL: https://gcc.gnu.org/viewcvs?rev=238268=gcc=rev
Log:
PR rtl-optimization/68961
* config/i386/sse.md (movsd/movhpd to movupd peephole2s): Add new
peephole variant.  Use sse_reg_operand predicates.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug middle-end/71224] Looping over local copy of aggregate invokes undefined behavior -Waggressive-loop-optimizations

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Buclaw  ---
Ugh, I've just realised that I still managed to get the condition guard wrong.

So there is indeed a (very, very remote) chance that length would overflow. 
Though realloc will overflow and fail first under normal operations.  I've
instead gone and fixed it in the upstream library instead.

[Bug driver/69028] ICE on *any* valid Cilk+ code C/C++: -fcilkplus is incompatible with -fprofile-arcs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Confirmed, I'll take a look.

[Bug c++/68581] ICE in build_conditional_expr_1 upon instantiation of a templated function with Cilk+ directives (valid code)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-12
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |4.9.4
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #2 from Martin Liška  ---
Confirmed on all releases that support -fcilkplus (4.9+).

[Bug middle-end/65289] [5/6/7 regression] ICE when compiling libjpegturbo with -floop-nest-optimize

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
I've just tried to reproduce the problem on x86_64-linux-gnu and I see:

4.9.x:
sorry, unimplemented: Graphite loop optimizations cannot be used

5.x:
ICE

6.1 and 7.0 look good, is it because I'm not using the cross-compiler, as you
do?

Thanks

[Bug c++/71841] variadic template can't cast to base class

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to johan.leroy from comment #3)
> file compiles without a problem

Which files? You still haven't provide a complete testcase.

What is the exact code you are trying to compile?

[Bug c/71853] [6/7 regression] ICE on an ill-formed case statement in c_do_switch_warnings

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c/71853] New: [6/7 regression] ICE on an ill-formed case statement in c_do_switch_warnings

[msebor at gcc dot gnu.org]

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

Bug ID: 71853
   Summary: [6/7 regression] ICE on an ill-formed case statement
in c_do_switch_warnings
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Prior to GCC 6.1, GCC rejected the invalid code below with

xyz.c:3:12: error: expected ‘:’ or ‘...’ before ‘{’ token

Since r225116 committed in the GCC 6.0 development cycle GCC fails on it with
an ICE:

$ cat xyz.c && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc -S
-Wall -Wextra -Wpedantic xyz.c 
void f (void)
{
  case (0) {
switch 0: { }
  }
}

xyz.c: In function ‘f’:
xyz.c:3:12: error: expected ‘:’ or ‘...’ before ‘{’ token
   case (0) {
^
xyz.c:4:12: error: expected ‘(’ before numeric constant
 switch 0: { }
^
xyz.c:4:12: warning: statement with no effect [-Wunused-value]
xyz.c:5:3: internal compiler error: Segmentation fault
   }
   ^
0xe96dee crash_signal
/src/gcc/trunk/gcc/toplev.c:335
0x87b066 c_do_switch_warnings(splay_tree_s*, unsigned int, tree_node*,
tree_node*, bool, bool)
/src/gcc/trunk/gcc/c-family/c-common.c:6296
0x7f2b64 c_finish_case(tree_node*, tree_node*)
/src/gcc/trunk/gcc/c/c-typeck.c:10042
0x812c23 c_parser_switch_statement
/src/gcc/trunk/gcc/c/c-parser.c:5612
0x811a35 c_parser_statement_after_labels
/src/gcc/trunk/gcc/c/c-parser.c:5144
0x81149b c_parser_compound_statement_nostart
/src/gcc/trunk/gcc/c/c-parser.c:4861
0x810e8c c_parser_compound_statement
/src/gcc/trunk/gcc/c/c-parser.c:4696
0x8119cb c_parser_statement_after_labels
/src/gcc/trunk/gcc/c/c-parser.c:5135
0x81149b c_parser_compound_statement_nostart
/src/gcc/trunk/gcc/c/c-parser.c:4861
0x810e8c c_parser_compound_statement
/src/gcc/trunk/gcc/c/c-parser.c:4696
0x80ba9c c_parser_declaration_or_fndef
/src/gcc/trunk/gcc/c/c-parser.c:2105
0x80a54e c_parser_external_declaration
/src/gcc/trunk/gcc/c/c-parser.c:1549
0x80a0a5 c_parser_translation_unit
/src/gcc/trunk/gcc/c/c-parser.c:1430
0x83c491 c_parse_file()
/src/gcc/trunk/gcc/c/c-parser.c:17930
0x8aef11 c_common_parse_file()
/src/gcc/trunk/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/71852] New: add warning for conditions that can never be true

[tromey at gcc dot gnu.org]

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

Bug ID: 71852
   Summary: add warning for conditions that can never be true
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Consider this code, derived from some code in gdb's arm-tdep.c:

int main(int argc, char**argv)
{
  unsigned int aa = argc;

  aa = aa & 0x04;

  if (aa == 0x00) {
// Ok.
  } else if (aa == 0x01) {
// Ok.
  } else if (aa == 0x0b) {
// Oops.
  }
}


Here, two of the conditions can never be true.
I think it would be nice if gcc could warn for this case.

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
Latest patch posted here.

https://gcc.gnu.org/ml/fortran/2016-07/msg00046.html

Still testing.

[Bug c++/71814] [6/7 Regression] ICE on valid C++11 code: in write_type, at cp/mangle.c:2158

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[matare at lih dot rwth-aachen.de]

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

--- Comment #20 from Victor Mataré  ---
(In reply to Victor Mataré from comment #19)
> > I'm not suggesting anything radical or novel, just the standard way to use
> > iostreams.
> [...]
> Maybe anyone with more insight into the standardization process knows
> anything about this?

Addendum: Maybe one (probably not the best) solution could be to let the linker
throw a warning or an error, and to let the distributors sort it out.

Btw, if this triggers a bug somewhere in a larger, existing codebase, it might
be hard to track down for developers, so I think we should at least have a
warning kinda soonish.

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[matare at lih dot rwth-aachen.de]

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

--- Comment #19 from Victor Mataré  ---
> I'm not suggesting anything radical or novel, just the standard way to use
> iostreams.

I'd call that "the legacy way" or the "C-like pattern". Call it "predominant"
or "established" if you wish.

But The Standard also defines an intuitive, modern, exception-driven error
handling, and I (probably along with every other developer who dislikes leaky
abstractions) really don't see why I shouldn't be using it. Obviously the
transition issues after the inheritance change were foreseeable, so I'd expect
the C++11 standard or any accompanying document to mention it. Or does the
standardization and the resulting guidance deliberately exclude deployment
issues such as this?

Maybe anyone with more insight into the standardization process knows anything
about this?

[Bug target/71805] incorrect code for test pr45752.c with -mcpu=power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #6 from Michael Meissner  ---
Fixed in trunk subversion id 238256 and in gcc6 subversion id 238258.

[Bug target/71805] incorrect code for test pr45752.c with -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Tue Jul 12 18:12:11 2016
New Revision: 238258

URL: https://gcc.gnu.org/viewcvs?rev=238258=gcc=rev
Log:
Backport from mainline

[gcc]
2016-07-12  Michael Meissner  

PR target/71805
* config/rs6000/altivec.md (altivec_vperm__internal):
The xxperm and xxpermr instructions require that the 2nd input
operand overlap with the output operand, and not the 1st.
(altivec_vperm_v8hiv16qi): Likewise.
(altivec_vperm__uns_internal): Likewise.
(altivec_vpermr__internal): Likewise.
(vperm_v8hiv4si): Likewise.
(vperm_v16qiv8hi): Likewise.

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

PR target/71805
* gcc.target/powerpc/pr71805.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr71805.c
  - copied unchanged from r238257,
trunk/gcc/testsuite/gcc.target/powerpc/pr71805.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/altivec.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe

[vsz.bugzilla at emailuser dot net]

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

--- Comment #8 from vsz.bugzilla at emailuser dot net ---
And the link command output:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-5.4.0/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include
--libexecdir=/mingw32/lib --with-gxx-include-dir=/mingw32/include/c++/5.4.0
--enable-bootstrap --with-arch=i686 --with-tune=generic
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-libatomic --enable-threads=posix --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-version-specific-runtime-libs --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32
--with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev1, Built by MSYS2
project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
gcc version 5.4.0 (Rev1, Built by MSYS2 project)
COMPILER_PATH=C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/;C:/msys64/mingw32/bin/../lib/gcc/;C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32/bin/
LIBRARY_PATH=C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/;C:/msys64/mingw32/bin/../lib/gcc/;C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32/lib/../lib/;C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../lib/;C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32/lib/;C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../
COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'test.exe' '-s' '-mtune=generic'
'-march=i686'
 C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/collect2.exe -plugin
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/liblto_plugin-0.dll
-plugin-opt=C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\username\AppData\Local\Temp\ccx3Npce.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -m i386pe -Bdynamic -o test.exe -s
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32/lib/../lib/crt2.o
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/crtbegin.o
-LC:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0
-LC:/msys64/mingw32/bin/../lib/gcc
-LC:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32/lib/../lib
-LC:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../lib
-LC:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32/lib
-LC:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../.. test.o win.o
-lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32
-lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex
-lmsvcrt
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32/lib/../lib/default-manifest.o
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.4.0/crtend.o
```

[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe

[vsz.bugzilla at emailuser dot net]

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

--- Comment #7 from vsz.bugzilla at emailuser dot net ---
Created attachment 38883
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38883=edit
Test case #1

Attached a test case that includes all referred sources, generated .o binaries,
and .exe, plus the default manifest .o from the MSYS2 installation.

[Bug target/71805] incorrect code for test pr45752.c with -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Tue Jul 12 17:42:04 2016
New Revision: 238256

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

PR target/71805
* config/rs6000/altivec.md (altivec_vperm__internal):
The xxperm and xxpermr instructions require that the 2nd input
operand overlap with the output operand, and not the 1st.
(altivec_vperm_v8hiv16qi): Likewise.
(altivec_vperm__uns_internal): Likewise.
(altivec_vpermr__internal): Likewise.
(vperm_v8hiv4si): Likewise.
(vperm_v16qiv8hi): Likewise.

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

PR target/71805
* gcc.target/powerpc/pr71805.c: New test.


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

[Bug c++/71841] variadic template can't cast to base class

[daniel.kruegler at googlemail dot com]

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

--- Comment #5 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #4)
> I cannot confirm this:
> 
> http://melpon.org/wandbox/permlink/Y6tlw5LQ71o1o6ei

Sorry, this should be:

http://melpon.org/wandbox/permlink/3L5qgWb4x0gJw6FV

> But it doesn't really matter much, because I already provided two arguments
> why the program that you have provided is non-conforming.

[Bug c++/71841] variadic template can't cast to base class

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  ---
(In reply to johan.leroy from comment #3)
> clang version I've used:
> 
> $ clang --version
> clang version 3.8.0 (branches/release_38)
> Target: x86_64-pc-windows-msvc
> Thread model: posix
> InstalledDir: C:\LLVM\bin
> 
> file compiles without a problem

I cannot confirm this:

http://melpon.org/wandbox/permlink/Y6tlw5LQ71o1o6ei

But it doesn't really matter much, because I already provided two arguments why
the program that you have provided is non-conforming.

[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Makes sense, I don't know why I didn't add divisions in the original patch.
*_MOD_EXPR, shifts and rotates should work as well with 0 on the left, max with
INT_MAX, etc, I was quite minimalist there.

Of course, if I had gone with the simpler approach of folding the operation
after replacement (here 0 / 10) and comparing that with the PHI argument, we
wouldn't need the neutral/absorbing logic at all :-(

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
(In reply to Boris Kolpackov from comment #17)
> > if (is >> x >> y >> z)
> 
> And what should happen in the else part of such statements?
> 
> if (is >> x >> y >> z)
>   ...
> else
>   throw something();

Whatever is appropriate for the program.

> Also note that if the 'is >> x' call in the above chain fails, you will
> still execute 'is >> y' and 'is >> z' before noticing the failure.

But they don't do anything if the stream state isn't good, they just return.

I'm not suggesting anything radical or novel, just the standard way to use
iostreams.

[Bug fortran/62125] Nested select type not accepted (rejects valid)

[mrestelli at gmail dot com]

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

--- Comment #9 from mrestelli  ---
Here is a test; should compile and run without errors.


module m
 implicit none
 type, abstract :: t1
  logical :: l
 end type t1
 type, extends(t1), abstract :: t2
  integer :: i
 end type t2
 type, extends(t2) :: t3
  real :: x
 end type t3
contains
 subroutine s(u)
  class(t1), intent(in) :: u
  if(.not.u%l) call abort()
   select type(u); class is(t2)
 if(u%i.ne.2) call abort()
 select type(u); class is(t3)
   if(u%x.ne.3.5) call abort()
 end select
   end select
 end subroutine s
end module m

program p
 use m
 implicit none
 type(t3) :: var = t3( l=.true. , i=2 , x=3.5 )
 call s(var)
end program p

[Bug preprocessor/71851] New: Get more time granularity at preprocessing

[daniel.gutson at intel dot com]

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

Bug ID: 71851
   Summary: Get more time granularity at preprocessing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at intel dot com
  Target Milestone: ---

I'm proposing to add either an __EXTENDED_TIME__ predefined macro which has the
form "HH:MM:SS.xxx" where xxx are the milliseconds, or a predefined macro that
expands to an integral constant representing milliseconds passed after 00:00:00
hs.

One usage of this enhancement is to seed randomization abilities during compile
time (i.e. using template metaprogramming).

If OK please assign this to me.

[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe

[nickc at gcc dot gnu.org]

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

--- Comment #6 from Nick Clifton  ---
(In reply to vsz.bugzilla from comment #5)
> You may find a self-contained example under the GitHub link included in the
> original report. Direct link:

Unfortunately I do not have a MYSY2 installation, or even a Windows machine,
so I cannot reproduce the example.  Would it be possible for you to upload a
zip
file archive containing the win.o, test.o, default-manifest.o and test.exe
binaries ?  If you can capture the linker command line that produces the
test.exe file as well, that would help too.

Cheers
  Nick

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #16 from The Written Word  
---
(In reply to John David Anglin from comment #15)
> Steve Ellcey used to support HP-UX/IA64 but he moved on to MIPS.  Don't
> know Jim Wilson's status.

I emailed them both. Maybe they can point me to a new maintainer.

> I don't have any ia64 hardware and I also don't have an 11.31 box.  So,
> there's a support issue for ia64 and 11.31.  Albert, if you or one of
> your staff could help in this regard, I would support the addition of
> a new hpux maintainer.

We can provide access to HP-UX 11.23/ia and 11.31/ia. Sadly, apart from
building GCC, we don't have any intricate ia64 knowledge to help with
maintainership.

> Patch looks reasonable but needs to be sent to gcc-patches with cc's.

I will look into this.

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[boris at kolpackov dot net]

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

--- Comment #17 from Boris Kolpackov  ---
> if (is >> x >> y >> z)

And what should happen in the else part of such statements?

if (is >> x >> y >> z)
  ...
else
  throw something();

Also note that if the 'is >> x' call in the above chain fails, you will still
execute 'is >> y' and 'is >> z' before noticing the failure.

[Bug driver/71850] @file should be used to cc1/cc1plus when @file is used

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to christian wilmes from comment #2)
> Which component performs the CreateProcess call then?

I am saying there is code in gcc.c that handles the linking side of things but
not calling of cc1.

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.c;h=7460f6af148969734c6cffeef870388355ef76cf;hb=HEAD#l5616

For an example.


There is another piece of code which handles the spec i with combine_inputs set
but I have not looked into how combine_inputs is set to true and what the 'i'
command is used.


https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.c;h=7460f6af148969734c6cffeef870388355ef76cf;hb=HEAD#l5504

[Bug driver/71850] @file should be used to cc1/cc1plus when @file is used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Confirmed.

[Bug driver/71850] CreateProcess argument lpCommandLine exceeds limit 32k limit

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The driver does handle the case where @file is used for linking and passes a
temp @file to the linker.

[Bug driver/71850] @file should be used to cc1/cc1plus when @file is used

[christian.wilmes at elektrobit dot com]

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

--- Comment #2 from christian wilmes  
---
Which component performs the CreateProcess call then?

[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
To elaborate on the use case: my immediate need for it is to detect at compile
time possible buffer overflow in calls to sprintf (the -Wformat-length patch)
without _FORTIFY_SOURCE that not all projects use and without optimization. 
The Linux kernel, for example, isn't affected by _FORTIFY_SOURCE because it
defines its own sprintf et at..  Although itdoes obviously benefits from
optimization,  without _FORTIFY_SOURCE inserting calls to
__builtin_object_size, the compute_builtin_object_size function fails just as
it does without optimization.

Another use case is to make -Warray-bounds usable without optimization (bug
67872).  Yet another one is to improve the -Wplacement-new warning.  It seems
that any feature (warning or otherwise) in GCC that needs to compute the size
of an indirectly referenced object could potentially benefit by using the same
function instead of rolling its own.

Beyond GCC itself, I think the feature will be generally more useful when
funcational (in the unambiguous "constant" cases) without optimization.

[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I meant comment #0.

[Bug driver/71850] New: CreateProcess argumend lpCommandLine exceeds limit 32k limit

[christian.wilmes at elektrobit dot com]

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

Bug ID: 71850
   Summary: CreateProcess argumend lpCommandLine exceeds limit 32k
limit
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian.wilmes at elektrobit dot com
  Target Milestone: ---

Under windows the command line is limited to 32k. When passing an compiler
option file (via @optionfile) it is parsed by gcc and then a call to cc1 is
generated via CreateProcess API. In this case gcc passes the parameters from
the option file and does not check wether it exceeds the 32k limit. For example
if someone defines too many include directories gcc will crash with a
"CreateProcess: No such file or directory" error.

[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Yes, I understand and agree with that.  What I envision is handling just the
basic cases like the ones in comment #2 (and similar) that don't involve the
objsz machinery.  My -Wformat-length patch (bug 49905) already uses a simple
form of this enhancement to detect buffer overflow without optimization.

[Bug c/57853] pointer arithmetic on arrays

[brodhow at sbcglobal dot net]

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

--- Comment #16 from this is me  ---
Andrew Pinski:

  Will you delete this Bug 57853 web page for me? 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853

  I can't hired!

Howard
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853
>
> Andrew Pinski  changed:
>
> What|Removed |Added
> 
>   Status|UNCONFIRMED |RESOLVED
>   Resolution|--- |INVALID
>
> --- Comment #8 from Andrew Pinski  ---
>> "*++arr[0][0]" is not supposed to change the array arr!
> At this point I am going to say you don't know C and should ask on a C mailing
> list learning C.
>
> *++arr[0][0] does the following:
> ++arr[0][0]
> And then deferences that value (which turns into 's').
>
>
> If you only want (arr[0][0])[1] then use that or *(arr[0][0]+1) rather than 
> ++.
>

[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment

[segher at gcc dot gnu.org]

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

--- Comment #14 from Segher Boessenkool  ---
Author: segher
Date: Tue Jul 12 15:13:47 2016
New Revision: 238251

URL: https://gcc.gnu.org/viewcvs?rev=238251=gcc=rev
Log:
Backport from mainline
2016-07-06  Segher Boessenkool  

PR target/70098
PR target/71763
* config/rs6000/rs6000.md (*ctr_internal1, *ctr_internal2,
*ctr_internal5, *ctr_internal6): Add *wi to the output
constraint.

gcc/testsuite/
PR target/70098
PR target/71763
* gcc.target/powerpc/pr71763.c: New file.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr71763.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/71763] powerpc64: ICE due to need for output reload on jump

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
Author: segher
Date: Tue Jul 12 15:13:47 2016
New Revision: 238251

URL: https://gcc.gnu.org/viewcvs?rev=238251=gcc=rev
Log:
Backport from mainline
2016-07-06  Segher Boessenkool  

PR target/70098
PR target/71763
* config/rs6000/rs6000.md (*ctr_internal1, *ctr_internal2,
*ctr_internal5, *ctr_internal6): Add *wi to the output
constraint.

gcc/testsuite/
PR target/70098
PR target/71763
* gcc.target/powerpc/pr71763.c: New file.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr71763.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
Author: segher
Date: Tue Jul 12 15:10:08 2016
New Revision: 238250

URL: https://gcc.gnu.org/viewcvs?rev=238250=gcc=rev
Log:
Backport from mainline
2016-07-06  Segher Boessenkool  

PR target/70098
PR target/71763
* config/rs6000/rs6000.md (*ctr_internal1, *ctr_internal2,
*ctr_internal5, *ctr_internal6): Add *wi to the output
constraint.

gcc/testsuite
PR target/70098
PR target/71763
* gcc.target/powerpc/pr71763.c: New file.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr71763.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/71763] powerpc64: ICE due to need for output reload on jump

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Author: segher
Date: Tue Jul 12 15:10:08 2016
New Revision: 238250

URL: https://gcc.gnu.org/viewcvs?rev=238250=gcc=rev
Log:
Backport from mainline
2016-07-06  Segher Boessenkool  

PR target/70098
PR target/71763
* config/rs6000/rs6000.md (*ctr_internal1, *ctr_internal2,
*ctr_internal5, *ctr_internal6): Add *wi to the output
constraint.

gcc/testsuite
PR target/70098
PR target/71763
* gcc.target/powerpc/pr71763.c: New file.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr71763.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/71634] [4.9//5/6 Regression] Invalid write with in mark_loops_for_removal (ira-build.c:2256) with --param ira-max-loops-num=0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-12
Summary|Invalid write with in   |[4.9//5/6 Regression]
   |mark_loops_for_removal  |Invalid write with in
   |(ira-build.c:2256) with |mark_loops_for_removal
   |--param ira-max-loops-num=0 |(ira-build.c:2256) with
   ||--param ira-max-loops-num=0
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Fixed on trunk, all active branches suffer from the same issue. I've been
testing the same patch.

[Bug middle-end/71700] [4.9/5/6 Regression] wrong code with struct assignment with sub-word signed bitfields

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||7.0
Summary|[4.9/5/6/7 Regression]  |[4.9/5/6 Regression] wrong
   |wrong code with struct  |code with struct assignment
   |assignment with sub-word|with sub-word signed
   |signed bitfields|bitfields
  Known to fail|7.0 |

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Fixed for GCC 7.
Will test backports

[Bug middle-end/71700] [4.9/5/6/7 Regression] wrong code with struct assignment with sub-word signed bitfields

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Jul 12 15:00:28 2016
New Revision: 238248

URL: https://gcc.gnu.org/viewcvs?rev=238248=gcc=rev
Log:
[expr.c] PR middle-end/71700: zero-extend sub-word value when widening
constructor element

PR middle-end/71700
* expr.c (store_constructor): Mask sign-extended bits when widening
sub-word constructor element at the start of a word.

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


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr71700.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/71634] Invalid write with in mark_loops_for_removal (ira-build.c:2256) with --param ira-max-loops-num=0

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Tue Jul 12 14:54:52 2016
New Revision: 238247

URL: https://gcc.gnu.org/viewcvs?rev=238247=gcc=rev
Log:
Fix PR rtl-optimization/71634

* ira-build.c (mark_loops_for_removal): Properly iterate
loops.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-build.c

[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
One of the reasons is that -O0 should mean short compile time.  If you schedule
the objsz pass at -O0, you might slow down the compilation, especially on
larger functions.
The glibc headers won't use it at -O0 anyway, so what would it be good for?

[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Sorry, but this is an enhancement request, not a bug report, so unless there is
a reason that I'm missing why the enhancement itself is problematic or
undesirable I would like to keep it open and, given cycles, implement it. (I
already have a very simple prototype that handles the three cases below and
passes regression testing with no issues.)

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[danglin at gcc dot gnu.org]

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

--- Comment #15 from John David Anglin  ---
Steve Ellcey used to support HP-UX/IA64 but he moved on to MIPS.  Don't
know Jim Wilson's status.

I don't have any ia64 hardware and I also don't have an 11.31 box.  So,
there's a support issue for ia64 and 11.31.  Albert, if you or one of
your staff could help in this regard, I would support the addition of
a new hpux maintainer.

Patch looks reasonable but needs to be sent to gcc-patches with cc's.

[Bug rtl-optimization/11832] Optimization of common stores in switch statements

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||33315
Summary|Optimization of common code |Optimization of common
   |in switch statements|stores in switch statements

--- Comment #10 from Richard Biener  ---
Similar to PR33315 this requests handling of stores (though this time really
hoisting).  The PRE hoisting doesn't do anything to stores.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug 33315] stores not commoned by sinking

[Bug tree-optimization/21485] [4.9/5/6/7 Regression] missed load PRE, PRE makes i?86/7 suck

[rguenth at gcc dot gnu.org]

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

--- Comment #60 from Richard Biener  ---
With code hoisting we now end up with the following for the testcase in
comment#6.  Over-the-weekend testing on bytemark (nbench?) didn't show
any effect though.  Thus requires re-evaluation.

NumSift (long int * array, long unsigned int i, long unsigned int j)
{
  long unsigned int k;
  sizetype _4;
  sizetype _5;
  long int * _6;
  long int _7;
  long unsigned int _8;
  long int * _9;
  long int _10;
  long unsigned int _14;
  long int * _28;
  long int pretmp_29;
  long unsigned int _30;
  long int prephitmp_31;
  long int * prephitmp_34;

  :
  goto ;

  :
  _30 = _14 * 8;
  _28 = array_22(D) + _30;
  pretmp_29 = *_28;
  if (_14 < j_20(D))
goto ;
  else
goto ;

  :
  _4 = _14 + 1;
  _5 = _4 * 8;
  _6 = array_22(D) + _5;
  _7 = *_6;
  if (_7 > pretmp_29)
goto ;
  else
goto ;

  :

  :
  # k_16 = PHI <_14(3), _14(4), _4(5)>
  # prephitmp_34 = PHI <_28(3), _28(4), _6(5)>
  # prephitmp_31 = PHI 
  _8 = i_15 * 8;
  _9 = array_22(D) + _8;
  _10 = *_9;
  if (_10 < prephitmp_31)
goto ;
  else
goto ;

  :
  *prephitmp_34 = _10;
  *_9 = prephitmp_31;
  goto ;

  :
  i_26 = j_20(D) + 1;

  :
  # i_23 = PHI 

  :
  # i_15 = PHI 
  _14 = i_15 * 2;
  if (_14 <= j_20(D))
goto ;
  else
goto ;

  :
  return;

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #14 from The Written Word  
---
We backported this patch to gcc-4.7.4 which we used to bootstrap gcc-5.4.0 on
HP-UX/IA. We seem to get farther than before in building gcc-5.4.0 though the
build still fails for what appears are reasons unrelated to this issue.

[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Only for -Os, it's better to avoid the expensive division otherwise.  Maybe
if we can predict the division to be likely executed it is profitable to
make it unconditional.

Missing GIMPLE phiopt.

absorbing_element_p needs to handle division for this.

Index: gcc/tree-ssa-phiopt.c
===
--- gcc/tree-ssa-phiopt.c   (revision 238242)
+++ gcc/tree-ssa-phiopt.c   (working copy)
@@ -812,7 +812,7 @@ neutral_element_p (tree_code code, tree
 /* Returns true if ARG is an absorbing element for operation CODE.  */

 static bool
-absorbing_element_p (tree_code code, tree arg)
+absorbing_element_p (tree_code code, tree arg, bool right)
 {
   switch (code)
 {
@@ -823,6 +823,13 @@ absorbing_element_p (tree_code code, tre
 case BIT_AND_EXPR:
   return integer_zerop (arg);

+case TRUNC_DIV_EXPR:
+case CEIL_DIV_EXPR:
+case FLOOR_DIV_EXPR:
+case ROUND_DIV_EXPR:
+case EXACT_DIV_EXPR:
+  return !right && integer_zerop (arg);
+
 default:
   return false;
 }
@@ -994,9 +1001,10 @@ value_replacement (basic_block cond_bb,
  && operand_equal_for_phi_arg_p (rhs1, cond_lhs)
  && neutral_element_p (code_def, cond_rhs, false))
  || (operand_equal_for_phi_arg_p (arg1, cond_rhs)
- && (operand_equal_for_phi_arg_p (rhs2, cond_lhs)
- || operand_equal_for_phi_arg_p (rhs1, cond_lhs))
- && absorbing_element_p (code_def, cond_rhs
+ && ((operand_equal_for_phi_arg_p (rhs2, cond_lhs)
+  && absorbing_element_p (code_def, cond_rhs, true))
+ || (operand_equal_for_phi_arg_p (rhs1, cond_lhs)
+ && absorbing_element_p (code_def, cond_rhs, false))
 {
   gsi = gsi_for_stmt (cond);
   if (INTEGRAL_TYPE_P (TREE_TYPE (lhs)))

[Bug tree-optimization/24568] [meta-bug] Missed optimization: trivialization of silly code

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
  :
  milliDiff_6 = -milliDiff_5(D);
  minutesDiff_15 = milliDiff_6 / 6;
  minutesDiff_8 = -minutesDiff_15;

so we still fail to notice that this is equal to

  minutesDiff_3 = milliDiff_5(D) / 6;

which is what $reporter requests (vars are signed).

One possible way to achieve this is to either sink or hoist negates across
a signed division.  I think only hoisting is generally valid, thus

(simplify
 (trunc_div (negate @0) @1)
 (if (INTEGRAL_TYPE_P (type)
  && ! TYPE_UNSIGNED (type))
  (negate (trunc_div @0 @1

or of course a pattern capturing the cancelling negate.

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[bugzilla-gcc at thewrittenword dot com]

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

The Written Word  changed:

   What|Removed |Added

 CC||bugzilla-gcc@thewrittenword
   ||.com

--- Comment #13 from The Written Word  
---
Created attachment 38882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38882=edit
Patch for HP-UX/IA

[Bug rtl-optimization/29144] Missing if-conversion. If-conversion dependent on operand order. Inconsistent if-conversion.

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
b and d are fixed on trunk (GCC 7) but we're just lucky with the association.

[Bug tree-optimization/33315] stores not commoned by sinking

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization
Summary|If condition not getting|stores not commoned by
   |eliminated  |sinking

--- Comment #7 from Richard Biener  ---
comment#4 is long fixed (in DOM).  In the original testcase the redundant
conditons are eliminated but we retain

test ()
{
  int i;

  :
  i_8 = num;
  if (i_8 == 1)
goto ;
  else
goto ;

  :
  MEM[(int *)] = 0;
  MEM[(int *) + 4B] = 0;
  goto ;

  :
  MEM[(int *) + 4B] = 0;

  :
  MEM[(int *) + 8B] = 0;
  return;

  :
  MEM[(int *)] = 0;
  if (i_8 == 2)
goto ;
  else
goto ;

  :
  MEM[(int *) + 4B] = 0;
  goto ;


because nothing sinks the common stores and tail-merging does only obfuscate
the CFG.  So this didn't really have sth to do with PR23286.  But the
complaint that the if condition is not eliminated is no longer true.

transmogrifying bug.

[Bug tree-optimization/67879] unnecessary jump in ternary

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/70159] missed CSE optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/71849] New: bitfield placement of overly aligned type

[nathan at gcc dot gnu.org]

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

Bug ID: 71849
   Summary: bitfield placement of overly aligned type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

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

Iain Sandoe & I have discovered an anomaly with the placement of bitfields with
a paradoxically aligned underlying type (alignment > size).  The calculation in
 excess_unit_span (stor-layout.c) erroneously considers such bitfields to
always straddle an allocation unit boundary, unless they start at bit-offset 0
within such an allocation.

The testcase contains two struct definitions that differ only by the underlying
type of the SECOND field.  In char_bit, it's type is 'char
__attribute__((aligned(__alignof(int' -- a char with int alignment.  In
int_bit, its type is plain int.  Both are 1 bit in size.

One might expect these two structs to be laid out the same.  That doesn't
happen.

char_bit's second field is placed at byte offset 4 bit 0, whereas int_bit's
second field is placed at byte offset 0 bit 1.  The struct sizes and offsets of
the third field are also different, as fallout from this change.

It seems excess_unit_span (or its callers) should check for such paradoxical
bitfield types.

However, (a) this is probably a rare case and (b) changing this is going to
break ABI compatibility.  So we may not care (but I couldn't find an existing
bug capturing this problem).

FWIW clang lays out these structs identically, which is how we became aware of
the problem.

[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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #2 from David Edelsohn  ---
New.

[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 #1 from David Edelsohn  ---
Created attachment 38880
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38880=edit
insert4_neg.ii pre-processed source code

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

[dje at gcc dot gnu.org]

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

Bug ID: 71848
   Summary: [7 Regression] libstdc++ testsuite error on AIX
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

Recent C++ front-end changes appear to have elicited new failures on AIX for
insert4_neg.cc in libstdc++ testsuite.  The error did not occur with r238169
(after the recent libstdc++ changes), but do occur after r238197 (the C++
changes).

In file included from
/tmp/20160711/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/functions.h:39:0,
 from
/tmp/20160711/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/safe_sequence.h:34,
 from
/tmp/20160711/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/list:35,
 from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/list/debug/insert4_neg.cc:20:
/tmp/20160711/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/formatter.h: In
function '__gnu_debug::_Error_formatter&
__gnu_debug::_Error_formatter::_M_iterator(const _Iterator&, const char*) [with
_Iterator = __gnu_debug::_Safe_iterator]':
/tmp/20160711/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/formatter.h:387:7:
error: __gnu_debug::_Error_formatter&
__gnu_debug::_Error_formatter::_M_iterator(const _Iterator&, const char*) [with
_Iterator = __gnu_debug::_Safe_iterator] causes a section type conflict with
__gnu_debug::_Error_formatter& __gnu_debug::_Error_formatter::_M_iterator(const
_Iterator&, const char*) [with _Iterator =
__gnu_debug::_Safe_iterator]
/tmp/20160711/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/debug/formatter.h:387:7:
note: '__gnu_debug::_Error_formatter&
__gnu_debug::_Error_formatter::_M_iterator(const _Iterator&, const char*) [with
_Iterator = __gnu_debug::_Safe_iterator]' was declared here


The "second type conflict" is peculiar to AIX, but I suspect that there is an
underlying problem introduced by the patch -- somehow the type or alignment of
the object is changing after it initially has been added to the symbol table or
layout generated.

[Bug tree-optimization/24001] Simple redundancy not eliminated

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug rtl-optimization/33828] Issues with code hoisting implementation in gcse.c

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug middle-end/70159] missed CSE optimization

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug tree-optimization/21676] [4.3 Regression] Optimizer regression: SciMark sparse matrix benchmark

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug rtl-optimization/11832] Optimization of common code in switch statements

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug middle-end/33315] If condition not getting eliminated

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug tree-optimization/67879] unnecessary jump in ternary

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug tree-optimization/23286] Missed code hoisting optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #42 from Richard Biener  ---
Fixed for GCC 7.

[Bug tree-optimization/24568] [meta-bug] Missed optimization: trivialization of silly code

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug rtl-optimization/29144] Missing if-conversion. If-conversion dependent on operand order. Inconsistent if-conversion.

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug tree-optimization/21485] [4.9/5/6/7 Regression] missed load PRE, PRE makes i?86/7 suck

[rguenth at gcc dot gnu.org]

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

Bug 23286 Summary: Missed code hoisting optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

   What|Removed |Added

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

[Bug middle-end/70159] missed CSE optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 12 13:32:04 2016
New Revision: 238242

URL: https://gcc.gnu.org/viewcvs?rev=238242=gcc=rev
Log:
2016-07-12  Steven Bosscher  
Richard Biener  

PR tree-optimization/23286
PR tree-optimization/70159
* doc/invoke.texi: Document -fcode-hoisting.
* common.opt (fcode-hoisting): New flag.
* opts.c (default_options_table): Enable -fcode-hoisting at -O2+.
* tree-ssa-pre.c (pre_stats): Add hoist_insert.
(do_regular_insertion): Rename to ...
(do_pre_regular_insertion): ... this and amend general comments
on insertion strathegy.
(do_partial_partial_insertion): Rename to ...
(do_pre_partial_partial_insertion): ... this.
(do_hoist_insertion): New function.
(insert_aux): Take flags on whether to do PRE and/or hoist insertion
and call do_hoist_insertion properly.
(insert): Adjust.
(pass_pre::gate): Enable also if -fcode-hoisting is enabled.
(pass_pre::execute): Register hoist_insert stats.

* gcc.dg/tree-ssa/ssa-pre-11.c: Disable code hosting.
* gcc.dg/tree-ssa/ssa-pre-27.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-28.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-2.c: Likewise.
* gcc.dg/tree-ssa/pr35286.c: Likewise.
* gcc.dg/tree-ssa/pr35287.c: Likewise.
* gcc.dg/hoist-register-pressure-1.c: Likewise.
* gcc.dg/hoist-register-pressure-2.c: Likewise.
* gcc.dg/hoist-register-pressure-3.c: Likewise.
* gcc.dg/pr51879-12.c: Likewise.
* gcc.dg/strlenopt-9.c: Likewise.
* gcc.dg/tree-ssa/pr47392.c: Likewise.
* gcc.dg/tree-ssa/pr68619-4.c: Likewise.
* gcc.dg/tree-ssa/split-path-5.c: Likewise.
* gcc.dg/tree-ssa/slsr-35.c: Likewise.
* gcc.dg/tree-ssa/slsr-36.c: Likewise.
* gcc.dg/tree-ssa/loadpre3.c: Adjust so hosting doesn't apply.
* gcc.dg/tree-ssa/pr43491.c: Scan optimized dump for desired result.
* gcc.dg/tree-ssa/ssa-pre-31.c: Adjust expected outcome for hoisting.
* gcc.dg/tree-ssa/ssa-hoist-1.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-2.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-3.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-4.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-5.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-6.c: New testcase.
* gfortran.dg/pr43984.f90: Adjust expected outcome.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/hoist-register-pressure-1.c
trunk/gcc/testsuite/gcc.dg/hoist-register-pressure-2.c
trunk/gcc/testsuite/gcc.dg/hoist-register-pressure-3.c
trunk/gcc/testsuite/gcc.dg/pr51879-12.c
trunk/gcc/testsuite/gcc.dg/strlenopt-9.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr35286.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr35287.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr43491.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr47392.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68619-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-35.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-36.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-27.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-28.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-31.c
trunk/gcc/testsuite/gfortran.dg/pr43984.f90
trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/23286] Missed code hoisting optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #41 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 12 13:32:04 2016
New Revision: 238242

URL: https://gcc.gnu.org/viewcvs?rev=238242=gcc=rev
Log:
2016-07-12  Steven Bosscher  
Richard Biener  

PR tree-optimization/23286
PR tree-optimization/70159
* doc/invoke.texi: Document -fcode-hoisting.
* common.opt (fcode-hoisting): New flag.
* opts.c (default_options_table): Enable -fcode-hoisting at -O2+.
* tree-ssa-pre.c (pre_stats): Add hoist_insert.
(do_regular_insertion): Rename to ...
(do_pre_regular_insertion): ... this and amend general comments
on insertion strathegy.
(do_partial_partial_insertion): Rename to ...
(do_pre_partial_partial_insertion): ... this.
(do_hoist_insertion): New function.
(insert_aux): Take flags on whether to do PRE and/or hoist insertion
and call do_hoist_insertion properly.
(insert): Adjust.
(pass_pre::gate): Enable also if -fcode-hoisting is enabled.
(pass_pre::execute): Register hoist_insert stats.

* gcc.dg/tree-ssa/ssa-pre-11.c: Disable code hosting.
* gcc.dg/tree-ssa/ssa-pre-27.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-28.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-2.c: Likewise.
* gcc.dg/tree-ssa/pr35286.c: Likewise.
* gcc.dg/tree-ssa/pr35287.c: Likewise.
* gcc.dg/hoist-register-pressure-1.c: Likewise.
* gcc.dg/hoist-register-pressure-2.c: Likewise.
* gcc.dg/hoist-register-pressure-3.c: Likewise.
* gcc.dg/pr51879-12.c: Likewise.
* gcc.dg/strlenopt-9.c: Likewise.
* gcc.dg/tree-ssa/pr47392.c: Likewise.
* gcc.dg/tree-ssa/pr68619-4.c: Likewise.
* gcc.dg/tree-ssa/split-path-5.c: Likewise.
* gcc.dg/tree-ssa/slsr-35.c: Likewise.
* gcc.dg/tree-ssa/slsr-36.c: Likewise.
* gcc.dg/tree-ssa/loadpre3.c: Adjust so hosting doesn't apply.
* gcc.dg/tree-ssa/pr43491.c: Scan optimized dump for desired result.
* gcc.dg/tree-ssa/ssa-pre-31.c: Adjust expected outcome for hoisting.
* gcc.dg/tree-ssa/ssa-hoist-1.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-2.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-3.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-4.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-5.c: New testcase.
* gcc.dg/tree-ssa/ssa-hoist-6.c: New testcase.
* gfortran.dg/pr43984.f90: Adjust expected outcome.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/hoist-register-pressure-1.c
trunk/gcc/testsuite/gcc.dg/hoist-register-pressure-2.c
trunk/gcc/testsuite/gcc.dg/hoist-register-pressure-3.c
trunk/gcc/testsuite/gcc.dg/pr51879-12.c
trunk/gcc/testsuite/gcc.dg/strlenopt-9.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr35286.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr35287.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr43491.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr47392.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68619-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-35.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-36.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-27.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-28.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-31.c
trunk/gcc/testsuite/gfortran.dg/pr43984.f90
trunk/gcc/tree-ssa-pre.c

[Bug fortran/62125] Nested select type not accepted (rejects valid)

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
I confirm that the patch in comment 5 allows the test to be compiled without
regression.

A test case showing that the code executes as expected is needed to avoid to
replace reject-valid with wrong-code.

[Bug fortran/71839] undefined reference to `_gfortran_caf_stop_str'

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Maybe I should ask the OpenCoarrays people.

Indeed!

[Bug fortran/71783] [5/6/7 Regression ] ICE on valid code in gimplify_var_or_parm_decl at gimplify.c:1801

[toon at moene dot org]

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

--- Comment #13 from Toon Moene  ---
On 07/11/2016 10:26 PM, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783
>
> Thomas Koenig  changed:
>
>What|Removed |Added
> 
>  Status|WAITING |RESOLVED
>  Resolution|--- |FIXED
>
> --- Comment #12 from Thomas Koenig  ---
> (In reply to Martin Liška from comment #11)
>> (In reply to Thomas Koenig from comment #10)
>>> Fixed on 5/6/7.  I don't have a working 4.9 compiler at the moment.
>>>
>>> Could anybody check if the fix also needs to be applied there?
>>
>> 4.9 is not affected by the PR.
>
> Thanks.
>
> Closing.
>

Thanks for working on this !

[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenther at suse dot de]

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

--- Comment #26 from rguenther at suse dot de  ---
On Tue, 12 Jul 2016, npl at chello dot at wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
> 
> --- Comment #25 from npl at chello dot at ---
> Yes, that works fine. I just meant to say it needs more work than casting to a
> type with less alignment, and unless explicitly marked with this pragma you 
> can
> expect a compiler to access like the (deduced) type was properly aligned.

sth like

typedef int acc __attribute__((may_alias, aligned(1)));

and an actual access like

  *(acc *)p;

works as well (type punning allowed via may_alias, alignment adjusted
to 1 byte).

Of course that's not portable.

Portable is to use memcpy which irrespective of the type of the
pointer has to assume an unaligned access.

[Bug tree-optimization/50417] regression: memcpy with known alignment

[npl at chello dot at]

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

--- Comment #25 from npl at chello dot at ---
Yes, that works fine. I just meant to say it needs more work than casting to a
type with less alignment, and unless explicitly marked with this pragma you can
expect a compiler to access like the (deduced) type was properly aligned.

[Bug tree-optimization/50417] regression: memcpy with known alignment

[olegendo at gcc dot gnu.org]

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

--- Comment #24 from Oleg Endo  ---
(In reply to npl from comment #22)
> 
> Its also generally quite hard to force the compiler to do less-aligned
> accesses, and I haven`t seen this "solution" anywhere. (Probably because it
> doesn`t work on any current compiler)

Hm, have you tried using the address of a member in a packed (1) struct?

[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Invalid thus.

[Bug tree-optimization/71836] Missing constant prop from const variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-12
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  The loop is only unrolled late and only FRE knows how to lookup
from *.LC0.  DOM only applies CSE to literally equivalent stores (that's
a quite hard limit which also makes it quite more efficient than FRE).

Not sure if more FRE passes are really desirable.

[Bug tree-optimization/71842] Optimize FMA when some arguments are simple constants

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  For now we only apply full constant folding and what you propose
for integer FMA.

[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Using the code in comment 6, with 4.9.3, 5.3.0, 6.1.0 and recent 7.0 trunk:

   textdata bss dec hex filename
   5606 696  40634218c6 493.eb
   4943 696  405679162f 493.nt
   4476 672  4051881444 493.pb
   4609 676   4528914a9 530.eb
   4881 704   8559315d9 530.nt
   4996 652   456521614 530.pb
   4527 704   852391477 610.eb
   4729 704   854411541 610.nt
   4974 680   85662161e 610.pb
   4960 704   856721628 700.eb
   5037 696   85741166d 700.nt
   5234 672   85914171a 700.pb

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Boris Kolpackov from comment #15)
> I am interested to hear what is your recommendation to do instead, call
> good()
> after every IO operation?

The normal way that iostreams are designed to be used:

  if (is >> x >> y >> z)

or

  if (os << a << b << c)

Not explicitly calling good() after every operation, that's dumb too.

[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|6.0 |5.5

[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 12 10:56:11 2016
New Revision: 238241

URL: https://gcc.gnu.org/viewcvs?rev=238241=gcc=rev
Log:
Implement N4258 noexcept for std::basic_string.

Backport from mainline
2015-10-02  Jonathan Wakely  

* testsuite/21_strings/basic_string/allocator/char/minimal.cc: Guard
explicit instantiation with check for new ABI.
* testsuite/21_strings/basic_string/allocator/wchar_t/minimal.cc:
Likewise. Use wchar_t as char_type.

Backport from mainline
2015-09-11  Jonathan Wakely  

PR libstdc++/58265
* doc/xml/manual/intro.xml: Document LWG 2063 and 2064 resolutions.
* doc/html/manual/bugs.html: Regenerate.
* include/bits/basic_string.h (basic_string): Implement N4258. Add
correct exception-specifications and propagate allocators correctly.
* include/bits/basic_string.tcc (basic_string::swap): Propagate
allocators correctly.
* include/debug/string (__gnu_debug::basic_string): Add correct
exceptions-specifications and allcoator-extended constructors.
* testsuite/21_strings/basic_string/allocator/char/copy.cc: New.
* testsuite/21_strings/basic_string/allocator/char/copy_assign.cc:
New.
* testsuite/21_strings/basic_string/allocator/char/minimal.cc: New.
* testsuite/21_strings/basic_string/allocator/char/move.cc: New.
* testsuite/21_strings/basic_string/allocator/char/move_assign.cc:
New.
* testsuite/21_strings/basic_string/allocator/char/noexcept.cc: New.
* testsuite/21_strings/basic_string/allocator/char/swap.cc: New.
* testsuite/21_strings/basic_string/allocator/wchar_t/copy.cc: New.
* testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc:
New.
* testsuite/21_strings/basic_string/allocator/wchar_t/minimal.cc: New.
* testsuite/21_strings/basic_string/allocator/wchar_t/move.cc: New.
* testsuite/21_strings/basic_string/allocator/wchar_t/move_assign.cc:
New.
* testsuite/21_strings/basic_string/allocator/wchar_t/noexcept.cc: New.
* testsuite/21_strings/basic_string/allocator/wchar_t/swap.cc: New.
* testsuite/util/testsuite_allocator.h (tracker_allocator): Define
defaulted assignment operators.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/minimal.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/move.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/move_assign.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/noexcept.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/swap.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/copy.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/minimal.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/move.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/move_assign.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/noexcept.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/swap.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/doc/html/manual/bugs.html
branches/gcc-5-branch/libstdc++-v3/doc/xml/manual/intro.xml
branches/gcc-5-branch/libstdc++-v3/include/bits/basic_string.h
branches/gcc-5-branch/libstdc++-v3/include/bits/basic_string.tcc
branches/gcc-5-branch/libstdc++-v3/include/debug/string
branches/gcc-5-branch/libstdc++-v3/testsuite/util/testsuite_allocator.h

[Bug fortran/71839] undefined reference to `_gfortran_caf_stop_str'

[mexas at bristol dot ac.uk]

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

--- Comment #5 from Anton Shterenlikht  ---
The puzzling thing is that symbol _gfortran_caf_stop_str
is in the OpenCoarrays library:

$ nm ~/OpenCoarrays-1.6.0/opencoarrays-build/lib/libcaf_mpi.a | grep
_gfortran_caf_stop_str
4870 T _gfortran_caf_stop_str

My library must not affect whether this symbol is found or not.

However, it seems, when I build my library, a lot of
OpenCoarray symbols are added to it, but not that one.

For example, another symbol, _gfortran_caf_error_stop_str, is also in
the OpenCoarrays library:

$ nm ~/OpenCoarrays-1.6.0/opencoarrays-build/lib/libcaf_mpi.a | grep
_gfortran_caf_error_stop_str
48e0 T _gfortran_caf_error_stop_str

but this one is added to my library by caf:

nm ../libcgpack.a |grep stop
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str
 U _gfortran_caf_error_stop_str

Maybe I should ask the OpenCoarrays people.

[Bug target/71847] powerpc64le: Potential rlwinm optimisation

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
I wonder why we don't do it in two insns, anyway?  (rldicl+rldimi).

[Bug tree-optimization/71752] [7 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:229 w/ -O1 -ftree-vectorize

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from alahay01 at gcc dot gnu.org ---
Looks like vector q4_lsm.5_8 is used before it is defined.

[Bug fortran/71795] [4.9/5/6/7 Regression] Two Bugs in array constructors (optimization)

[vladimir.fuka at gmail dot com]

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

Vladimir Fuka  changed:

   What|Removed |Added

 CC||vladimir.fuka at gmail dot com

--- Comment #3 from Vladimir Fuka  ---
I suppose it should not be P4 critical?

[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de  ---
On Tue, 12 Jul 2016, npl at chello dot at wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
> 
> --- Comment #22 from npl at chello dot at ---
> > > 0014 :
> > >   14: e3a03000mov r3, #0
> > >   18: e5803000str r3, [r0]
> > >   1c: e5812000str r2, [r1]
> > >   20: e590ldr r0, [r0] // The load thats missing above
> > >   24: e24dd010sub sp, sp, #16 // Time for another 
> > >   28: e28dd010add sp, sp, #16 // Bugreport ?
> > >   2c: e12fff1ebx  lr
> > 
> > It's not done on STRICT_ALIGNMENT platforms because not all of those expand
> > misaligned moves correctly (IIRC).  Looking at RTL expansion at least the
> > misaligned destination will work correctly.  The question remains is what
> > happens for -Os and for example both misaligned source and destination.
> > Or on x86 where a simple rep; movb; is possible (plus the register setup
> > of course).
> 
> Not sure what you mean, x86 has unaligned accesses and shouldn't be affected.
> Also, I doubt there are many cases where the function-call (and the register
> and stack shuffling) will use less code than the aligned access.
> 
> The generated code for unaligned access could be improved in many cases (ARM
> atleast), possibly fixed. But thats not generally an argument against 
> improving
> the builtins?

Sure.  It is just that I am usually (overly?) cautionous when introducing
unaligned accesses because historically they were handled wrong and
nowadays they might be handled very inefficient on strict-align targets.

I am going to propose the patch and add a testcase with most misalign
cases so we can see runtime fallout on the more weird targets.

[Bug middle-end/71716] [7 Regression] gcc.dg/atomic/c11-atomic-exec-4.c is miscompiled with -march=corei7

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/71716] [7 Regression] gcc.dg/atomic/c11-atomic-exec-4.c is miscompiled with -march=corei7

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 12 08:58:56 2016
New Revision: 238239

URL: https://gcc.gnu.org/viewcvs?rev=238239=gcc=rev
Log:
PR middle-end/71716
* gimple-fold.c (optimize_atomic_compare_exchange_p): Return false
for SCALAR_FLOAT_TYPE_P type of expected var, or if TYPE_PRECISION
is different from mode's bitsize.  Small cleanup.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c

[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 12 08:56:14 2016
New Revision: 238238

URL: https://gcc.gnu.org/viewcvs?rev=238238=gcc=rev
Log:
2016-07-12  Richard Biener  

PR rtl-optimization/68961
* fwprop.c (propagate_rtx): Allow SUBREGs of VEC_CONCAT and CONCAT
to simplify to a non-constant.

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

Added:
trunk/gcc/testsuite/gcc.target/i386/pr68961.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fwprop.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/60172] [4.9/5 Regression] ARM performance regression from trunk@207239

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||6.1.0
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |6.0
Summary|[4.9/5/6/7 Regression] ARM  |[4.9/5 Regression] ARM
   |performance regression from |performance regression from
   |trunk@207239|trunk@207239

--- Comment #30 from Richard Biener  ---
Thus fixed for GCC 6+, not fixing for older branches.

[Bug c++/71841] variadic template can't cast to base class

[johan.leroy at openehs dot co.uk]

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

--- Comment #3 from johan.leroy at openehs dot co.uk ---
clang version I've used:

$ clang --version
clang version 3.8.0 (branches/release_38)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\LLVM\bin

file compiles without a problem

[Bug target/71652] [4.9/5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I think the bug is that
  if (!strcmp (opts->x_ix86_arch_string, "generic"))
error ("generic CPU can be used only for %stune=%s %s",
   prefix, suffix, sw);
  else if (!strcmp (opts->x_ix86_arch_string, "intel"))
error ("intel CPU can be used only for %stune=%s %s",
   prefix, suffix, sw);
is too late.
I'd stick it into:
  for (i = 0; i < pta_size; i++)
if (! strcmp (opts->x_ix86_arch_string, processor_alias_table[i].name))
  {
HERE >
ix86_schedule = processor_alias_table[i].schedule;
and if emitting the error, just break, so that neither ix86_arch nor
opts->x_ix86_isa_flags is affected.
Similarly, the "CPU you selected does not support x86-64 " error should not
affect these.

Perhaps it would be helpful to go over the whole ix86_option_override_internal
and for all errors emitted in there make sure that beyond reporting errors the
function doesn't keep the options in an invalid state - changes them to some
sane defaults on errors.
Some places already do that:
  error ("-mstringop-strategy=rep_8byte not supported for 32-bit code");
  opts->x_ix86_stringop_alg = no_stringop;
etc., but other spots don't.

[Bug tree-optimization/70600] Missed tree optimization with multiple additions in different types.

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 11 Jul 2016, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70600
> 
> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>Keywords||missed-optimization
>  CC||pinskia at gcc dot gnu.org
>Severity|normal  |enhancement
> 
> --- Comment #3 from Andrew Pinski  ---
> I have seen other cases which need to be handled by FRE/PRE instead of
> reassiocate.
> 
> Even the simple:
> 
> int f(int a, int b, int d)
> {
>   unsigned a1 = a;
>   unsigned b1 = b;
>   unsigned c1 = a + b;
>   int c = c1;
>   if (d)
> c = a + b;
>   return c;
> }
> 
> Note I think FRE handles the above incorrectly as it converts the safe 
> unsigned
> addition to non safe signed addition. I will file a different bug about that
> issue.

It's going to be interesting to teach FRE this equivalence ;)  I assume
you wanted to write

>   unsigned c1 = a1 + b1;

even though it doesn't make a difference in the IL.

It may be interesting to try transitioning GIMPLE to singed/unsigned
ops rather than relying on types (so be more similar to RTL in this
regard).  That would of course fix this.

The way FRE works with having expression tables that only cover
a single GIMPLE stmt it would require looking up unsigned
variants of a and b and then looking up the sum of both.  If found
we'd need to possibly insert a conversion.  I think it's possible
to teach FRE to do this in a quite generic way for all ops that
are sign-agnostic.  But doing this even for truncated ops and
thus using a truncated widened op might is going to be expensive
and not always profitable.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 238237)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -3384,17 +3430,54 @@ visit_copy (tree lhs, tree rhs)
 static bool
 visit_nary_op (tree lhs, gimple *stmt)
 {
-  bool changed = false;
   tree result = vn_nary_op_lookup_stmt (stmt, NULL);
-
   if (result)
-changed = set_ssa_val_to (lhs, result);
-  else
-{
-  changed = set_ssa_val_to (lhs, lhs);
-  vn_nary_op_insert_stmt (stmt, lhs);
+return set_ssa_val_to (lhs, result);
+  else if (INTEGRAL_TYPE_P (TREE_TYPE (lhs))
+  && (TYPE_PRECISION (TREE_TYPE (lhs))
+  == GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (lhs
+  && is_gimple_assign (stmt))
+{
+  enum tree_code code = gimple_assign_rhs_code (stmt);
+  switch (code)
+   {
+   case PLUS_EXPR:
+   case MINUS_EXPR:
+   case MULT_EXPR:
+ {
+   tree ops[3];
+   ops[0] = gimple_assign_rhs1 (stmt);
+   ops[1] = gimple_assign_rhs2 (stmt);
+   tree type = TREE_TYPE (lhs);
+   type = signed_or_unsigned_type_for (! TYPE_UNSIGNED (type),
+type);
+   ops[0] = vn_nary_op_lookup_pieces (1, NOP_EXPR, type, ops, 
NULL);
+   if (ops[0])
+ {
+   ops[1] = vn_nary_op_lookup_pieces (1, NOP_EXPR, type, 
[1],
+  NULL);
+   if (ops[1])
+ {
+   ops[0] = vn_nary_op_lookup_pieces (2, code, type, ops,
+  NULL);
+   if (ops[0])
+ {
+   result = vn_nary_build_or_lookup (NOP_EXPR,
+ TREE_TYPE (lhs),
+ ops);
+   if (result)
+ return set_ssa_val_to (lhs, result);
+ }
+ }
+ }
+   break;
+ }
+   default:;
+   }
 }

+  bool changed = set_ssa_val_to (lhs, lhs);
+  vn_nary_op_insert_stmt (stmt, lhs);
   return changed;
 }


produces in t.c.034t.fre1

f (int a, int b, int d)
{
  int c;
  unsigned int c1;
  unsigned int b1;
  unsigned int a1;
  _Bool _1;
  _Bool _2;
  _Bool _3;
  int _5;

  :
  a1_7 = (unsigned int) a_6(D);
  b1_9 = (unsigned int) b_8(D);
  c1_10 = a1_7 + b1_9;
  _1 = a_6(D) <= 0;
  _2 = b_8(D) <= 0;
  _3 = _1 | _2;
  if (_3 != 0)
goto ;
  else
goto ;

  :
  c_12 = (int) c1_10;

  :
  # _5 = PHI <0(2), c_12(3)>
  return _5;

}