[Bug tree-optimization/71417] New: wrong code (SIGFPE) at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 71417
   Summary: wrong code (SIGFPE) at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in both 32-bit and 64-bit modes.

This is a regression from 6.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160604 (experimental) [trunk revision 237091] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-6.1 -O3 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
Floating point exception (core dumped)
$ 


---


char a = -97;
int b, c, d, e;

int
main ()
{
  int g = d, h = 0, i = 1; 
  for (; h < 3; h++)
{
  if (g > -1)
{
  int j;
  g = j = 0;
  for (; j < 5; j++)
  L1:
if (!i)
  goto L1;
  a = e;
}
  else
i = 0;
}
  b = c / ~(a | 114);
  return 0; 
}

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Resolution|WORKSFORME  |FIXED

--- Comment #2 from Martin Sebor  ---
I just happened to be looking into this report and it's not clear to me whether
or not the warning should be expected in this case.  The documentation suggests
it should be:

-Wunused-variable
Warn whenever a local or static variable is unused aside from its
declaration.

and I could find no tests that exercise this case, or the much simpler:

staticc int i;
static int j = i;

which is also not diagnosed by GCC (it is by Clang).

Since the dynamic initialization is retained, it might make sense not to
diagnose it.  On the other hand, when the initialization has no observable
side-effects it would be nice to know that it's still done (in case the
variable can be removed, such as in the simple test above).

Either way, the warning doesn't seem to work as I would expect in many cases. 
For example, the following produces no warnings with GCC (Clang diagnoses both
s and k, which makes more sense to me):

int f ();
static int i = f ();

static struct S { } s = S ();

static int j;
static int k = j;

[Bug c++/60272] atomic<>::compare_exchange_weak has spurious store and can cause race conditions

[max.wittal at mwittal dot de]

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

--- Comment #10 from Max Wittal  ---
Sorry, I'm pretty sure now that there is some hard to find bug in my code, like
the ABA problem.

Please disregard my comment above.

[Bug c++/71394] -Werror=conversion-null identifies incorrect data member of member initializer list

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-04
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Probably the warning uses input_location and that points to the end of the
mem-initializers list.

Clang gives:

prog.cc:9:7: warning: implicit conversion of NULL constant to 'unsigned int'
[-Wnull-conversion]
n(NULL)
 ~^~~~
  0

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to andysem from comment #0)
> gcc emits 'unused variable' warnings for variables whose initialization
> might have side effects.

It seems to be fixed in 6.1 and 7.0. Thanks for the report anyway.

[Bug c/71411] No warnings for OOB accesses with arrays of size 1

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-6-4
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
Confirmed.  See bug 67872 for a prior report of the same problem.

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

[Bug c/67872] missing -Warray-bounds warning, bogus -Wmaybe-uninitialized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #4 from Martin Sebor  ---
*** Bug 71411 has been marked as a duplicate of this bug. ***

[Bug c++/60335] confused by earlier errors, bailing out

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Looking into it.

[Bug tree-optimization/71416] New: ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)

[chengniansun at gmail dot com]

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

Bug ID: 71416
   Summary: ICE at -O3 in 32-bit and 64-bit modes on
x86_64-linux-gnu (vectorizable_live_operation)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160604 (experimental) [trunk revision 237091] (GCC) 
$: 
$: gcc-trunk -m64 -O3 small.c
small.c: In function ‘main’:
small.c:5:5: internal compiler error: in vectorizable_live_operation, at
tree-vect-loop.c:6377
 int main() {
 ^~~~
0xe0661f vectorizable_live_operation(gimple*, gimple_stmt_iterator*,
_slp_tree*, int, gimple**)
../../gcc-source-trunk/gcc/tree-vect-loop.c:6377
0xe02bcf vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc-source-trunk/gcc/tree-vect-stmts.c:8336
0xe09a33 vect_transform_loop(_loop_vec_info*)
../../gcc-source-trunk/gcc/tree-vect-loop.c:6911
0xe28baf vectorize_loops()
../../gcc-source-trunk/gcc/tree-vectorizer.c:554
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$: cat small.c
short a;
char b, e;
static short c;
int d, f;
int main() {
  short g;
  for (; e; ++e) {
d = a;
f = 0;
if (b)
  d = f = g >= c;
  }
  return 0;
}

$:

[Bug c/48116] -Wreturn-type does not work as advertised

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Author: msebor
Date: Sat Jun  4 20:50:50 2016
New Revision: 237093

URL: https://gcc.gnu.org/viewcvs?rev=237093=gcc=rev
Log:
PR c/48116 - -Wreturn-type does not work as advertised

gcc/ChangeLog:
2016-06-04  Martin Sebor  
Marcin Baczyński 

PR c/48116
* doc/invoke.texi (-Wreturn-type): Mention not warning on return with
a void expression in a void function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug fortran/71401] [7 regression] spec2006 test case 416.gamess fails starting with r237003

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  ---
Thanks for report. I am working on it.

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

[Bug fortran/71404] [7 Regression] 416.gamess in SPEC CPU 2006 failed to build

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #6 from Jerry DeLisle  ---
*** Bug 71401 has been marked as a duplicate of this bug. ***

[Bug fortran/71404] [7 Regression] 416.gamess in SPEC CPU 2006 failed to build

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
I am on it. Thanks for reduction. I can "see" the problem.

[Bug libstdc++/71364] [7 regression] recent tuple changes break range-v3 merge.cpp

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen  ---
Which version of range-v3? I cloned https://github.com/ericniebler/range-v3.git
and its tests seem to pass on the current trunk.

[Bug libstdc++/71415] New: std::filesystem::exists that does not throw sets error code if file does not exist

[marejde at gmail dot com]

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

Bug ID: 71415
   Summary: std::filesystem::exists that does not throw sets error
code if file does not exist
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marejde at gmail dot com
  Target Milestone: ---

The following program:

#include 
#include 

int main(int argc, char *argv[])
{
std::error_code error_code;
bool exists = std::experimental::filesystem::exists("does_not_exist",
error_code);

std::cout << "exists: " << exists << '\n';
std::cout << "error_code.value(): " << error_code.value() << '\n';
std::cout << "error_code.message(): " << error_code.message() << '\n';
std::cout << "error_code operator bool: " << (error_code.value() ? true
: false) << '\n';

return 0;
}

outputs:

exists: 0
error_code.value(): 2
error_code.message(): No such file or directory
error_code operator bool: 1

Which means it is not possible to discern between an error and when the file
does not exist without examining error_code.value(), which is platform
dependent.

Tested on Arch Linux with "gcc (GCC) 6.1.1 20160501".

[Bug target/71286] 6.1.0: compiling djgpp programs with LTO emits "visibility attribute not supported in this configuration" warnings

[andris.pavenis at iki dot fi]

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

Andris Pavenis  changed:

   What|Removed |Added

 CC||andris.pavenis at iki dot fi

--- Comment #3 from Andris Pavenis  ---
I have only tried -flto for DJGPP in case of native compiler. In this case LTO
only have limited functionality due to absence of plugin and as result modules
read by linker from static libraries are left out from optimization as far as I
understand.

At least -flto seems to work in this limited case (several object files) for
native DJGPP compiler

[Bug other/71414] New: 2x slower than clang summing small float array

[yyc1992 at gmail dot com]

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

Bug ID: 71414
   Summary: 2x slower than clang  summing small float array
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

Ref https://llvm.org/bugs/show_bug.cgi?id=28002

C source code.

```c
__attribute__((noinline)) float sum32(float *a, size_t n)
{
/* a = (float*)__builtin_assume_aligned(a, 64); */
float s = 0;
for (size_t i = 0;i < n;i++)
s += a[i];
return s;
}```


See [this
gist](https://gist.github.com/yuyichao/5b07f71c1f19248ec5511d758532a4b0) for
assembly output by different compilers. GCC appears to be ~2x slower than clang
on the two machines (4702HQ and 6700K) I benchmarked this.

[Bug ada/71413] New: [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*

[doko at gcc dot gnu.org]

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

Bug ID: 71413
   Summary: [7 Regression] bootstrap (gnat) broken on
arm-linux-gnueabi*
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk 20160603 fails to build on arm-linux-gnueabi* with

Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
Bootstrap comparison failure!
gcc/ada/sem_ch13.o differs
Makefile:23154: recipe for target 'compare' failed
make[4]: *** [compare] Error 1

armhf is configured with

 --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
 --prefix=/usr/lib/gcc-snapshot
 --enable-shared
 --enable-linker-build-id
 --disable-nls
 --with-sysroot=/
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-libitm
 --disable-libquadmath
 --enable-plugin
 --with-system-zlib
 --disable-browser-plugin
 --enable-java-awt=gtk
 --enable-gtk-cairo
 --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-7-snap-armhf/jre
 --enable-java-home
 --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-7-snap-armhf
 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-7-snap-armhf
 --with-arch-directory=arm
 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
 --enable-objc-gc
 --enable-multiarch
 --enable-multilib
 --disable-sjlj-exceptions
 --with-arch=armv7-a
 --with-fpu=vfpv3-d16
 --with-float=hard
 --with-mode=thumb
 --disable-werror
 --enable-multilib
 --enable-checking=yes
 --build=arm-linux-gnueabihf
 --host=arm-linux-gnueabihf
 --target=arm-linux-gnueabihf

armel is configured with

 --prefix=/usr/lib/gcc-snapshot
 --enable-shared
 --enable-linker-build-id
 --disable-nls
 --with-sysroot=/
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-libitm
 --disable-libquadmath
 --enable-plugin
 --with-system-zlib
 --disable-browser-plugin
 --enable-java-awt=gtk
 --enable-gtk-cairo
 --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-7-snap-armel/jre
 --enable-java-home
 --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-7-snap-armel
 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-7-snap-armel
 --with-arch-directory=arm
 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
 --enable-objc-gc
 --enable-multiarch
 --disable-sjlj-exceptions
 --with-arch=armv4t
 --with-float=soft
 --disable-werror
 --enable-checking=yes
 --build=arm-linux-gnueabi
 --host=arm-linux-gnueabi
 --target=arm-linux-gnueabi

[Bug fortran/71412] iso_c_bindings and optimization interaction bug

[relliott at umn dot edu]

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

--- Comment #6 from relliott at umn dot edu ---
> Have you considered the SAVE attribute?
>
>  integer(c_int), pointer,save:: val
>
> laptop-kargl:kargl[246] gmake
> gfc -O3 -g -Wall -pedantic  -c skeleton-f.F90
> ~/work/bin/gcc -O3 -g -Wall -ansi -pedantic  -c skeleton-c.c
> gfc -O3 -g -Wall skeleton*.o  -o skeleton
> laptop-kargl:kargl[247] ./skeleton
> -- in storePtr: pointer address --> 0x28621018 <-- value --> 0 <-- index --> 0
> -- just a print statement --> nothing <-- index -->   0
> -- in getPtr:   pointer address --> 0x28621018 <-- value --> 21 <-- index -->
> 0
> -- in storePtr: pointer address --> 0x28621020 <-- value --> 0 <-- index --> 1
> -- just a print statement --> nothing <-- index -->   1
> -- in getPtr:   pointer address --> 0x28621020 <-- value --> 12 <-- index -->
> 1
> -- value of 'val0' variable -->   21
> -- value of 'val1' variable -->   12

Thanks,

I'll look at SAVE more closely.


>
> PS: You probably do not want to use -pedantic with gfortran.

OK.

>
> PPS: bugzilla is not an appropriate forum to learn Fortran.  Try
> comp.lang.fortran.

Agreed.  I didn't get any response from fort...@gcc.gnu.org and I thought it 
was a bug, so I submitted to bugzilla.  I'll consider this closed now and look 
for other resources.

Many thanks for your interaction.

Ryan

[Bug fortran/71412] iso_c_bindings and optimization interaction bug

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Sat, Jun 04, 2016 at 04:36:24PM +, relliott at umn dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412
> 
> --- Comment #4 from relliott at umn dot edu ---
> > Ahem, give val the SAVE attribute.
> >
> >  integer(c_int), pointer, save :: val
> 
> Hi,  Thanks for your help.  Unfortunately, I don't think using
> save will serve my purpose in this case.  Although, now I see
> that the skeleton code does not illustrate this aspect of my
> requirements.  The myalloc() function is supposed 
> to be able to allocate multiple independent values.

Have you considered the SAVE attribute?

  integer(c_int), pointer,save:: val

laptop-kargl:kargl[246] gmake
gfc -O3 -g -Wall -pedantic  -c skeleton-f.F90
~/work/bin/gcc -O3 -g -Wall -ansi -pedantic  -c skeleton-c.c
gfc -O3 -g -Wall skeleton*.o  -o skeleton
laptop-kargl:kargl[247] ./skeleton 
 -- in storePtr: pointer address --> 0x28621018 <-- value --> 0 <-- index --> 0
 -- just a print statement --> nothing <-- index -->   0
 -- in getPtr:   pointer address --> 0x28621018 <-- value --> 21 <-- index -->
0
 -- in storePtr: pointer address --> 0x28621020 <-- value --> 0 <-- index --> 1
 -- just a print statement --> nothing <-- index -->   1
 -- in getPtr:   pointer address --> 0x28621020 <-- value --> 12 <-- index -->
1
 -- value of 'val0' variable -->   21
 -- value of 'val1' variable -->   12

PS: You probably do not want to use -pedantic with gfortran.

PPS: bugzilla is not an appropriate forum to learn Fortran.  Try 
comp.lang.fortran.

[Bug fortran/71412] iso_c_bindings and optimization interaction bug

[relliott at umn dot edu]

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

--- Comment #4 from relliott at umn dot edu ---
> Ahem, give val the SAVE attribute.
>
>  integer(c_int), pointer, save :: val

Hi,  Thanks for your help.  Unfortunately, I don't think using save will serve 
my purpose in this case.  Although, now I see that the skeleton code does not 
illustrate this aspect of my requirements.  The myalloc() function is supposed 
to be able to allocate multiple independent values.

I've updated the code to demonstrate this requirement.  Attached.

The typical output is now:

$ make
gfortran -m32 -O3 -g -Wall -pedantic  -c skeleton-f.F90
gcc -m32 -O3 -g -Wall -ansi -pedantic  -c skeleton-c.c
gfortran -m32 -O3 -g -Wall skeleton*.o  -o skeleton

$ ./skeleton
  -- in storePtr: pointer address --> 0x78625940 <-- value --> 805306368 <--
index --> 0
  -- just a print statement --> nothing <-- index -->   0
  -- in getPtr:   pointer address --> 0x78625940 <-- value --> 805306368 <--
index --> 0
  -- in storePtr: pointer address --> 0x78625950 <-- value --> 805306368 <--
index --> 1
  -- just a print statement --> nothing <-- index -->   1
  -- in getPtr:   pointer address --> 0x78625950 <-- value --> 805306368 <--
index --> 1
  -- value of 'val0' variable -->805306368
  -- value of 'val1' variable -->805306368

$ make clean
rm -f skeleton skeleton*.o *.mod

$ make DEFS=-DOK
gfortran -m32 -O3 -g -Wall -pedantic -DOK -c skeleton-f.F90
gcc -m32 -O3 -g -Wall -ansi -pedantic -DOK -c skeleton-c.c
gfortran -m32 -O3 -g -Wall skeleton*.o  -o skeleton

$ ./skeleton
  -- in storePtr: pointer address --> 0x78e41c80 <-- value --> -268435456 <--
index --> 0
  -- value of 'val' variable -->   21 <-- index -->0
  -- in getPtr:   pointer address --> 0x78e41c80 <-- value --> 21 <-- index -->
0
  -- in storePtr: pointer address --> 0x78e41c90 <-- value --> -268435456 <--
index --> 1
  -- value of 'val' variable -->   12 <-- index -->1
  -- in getPtr:   pointer address --> 0x78e41c90 <-- value --> 12 <-- index -->
1
  -- value of 'val0' variable -->   21
  -- value of 'val1' variable -->   12



Suggestions would be much appreciated.

Thanks,

Ryan

[Bug fortran/71412] iso_c_bindings and optimization interaction bug

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to relliott from comment #2)
> > I believe gfortran's behavior conforms to the standard.  F2003 states
> >
> >   When the execution of a procedure is terminated by execution
> >   of a RETURN or END statement, an allocatable variable that is
> >   a named local variable of the procedure retains its allocation
> >   and definition status if it has the SAVE attribute or is a
> >   function result variable or a subobject thereof; otherwise, it
> >   is deallocated.
> >
> > val is a local variable.  val does not have the SAVE attribute.
> 
> If that is the case, how should the desired result be achieved in a standard 
> conformant way?

Ahem, give val the SAVE attribute.

  integer(c_int), pointer, save :: val

[Bug fortran/71412] iso_c_bindings and optimization interaction bug

[relliott at umn dot edu]

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

--- Comment #2 from relliott at umn dot edu ---
> I believe gfortran's behavior conforms to the standard.  F2003 states
>
>   When the execution of a procedure is terminated by execution
>   of a RETURN or END statement, an allocatable variable that is
>   a named local variable of the procedure retains its allocation
>   and definition status if it has the SAVE attribute or is a
>   function result variable or a subobject thereof; otherwise, it
>   is deallocated.
>
> val is a local variable.  val does not have the SAVE attribute.

If that is the case, how should the desired result be achieved in a standard 
conformant way?

[Bug fortran/71412] iso_c_bindings and optimization interaction bug

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to relliott from comment #0)
> Created attachment 38644 [details]
> minimal skeleton code that illustrates the bug
> 
> A problem exists in the way gfortran optimizes functions/subroutines when c
> interoperability (and specifically the c_loc() intrinsic) are used.
> 

I believe gfortran's behavior conforms to the standard.  F2003 states

   When the execution of a procedure is terminated by execution
   of a RETURN or END statement, an allocatable variable that is
   a named local variable of the procedure retains its allocation
   and definition status if it has the SAVE attribute or is a
   function result variable or a subobject thereof; otherwise, it
   is deallocated.

val is a local variable.  val does not have the SAVE attribute.

[Bug tree-optimization/71405] [6/7 Regression] ICE on valid C++ code at -Os and above on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jun  4 14:50:57 2016
New Revision: 237091

URL: https://gcc.gnu.org/viewcvs?rev=237091=gcc=rev
Log:
PR tree-optimization/71405
* tree-ssa.c (execute_update_addresses_taken): For clobber with
incompatible type, build a new clobber with the right type instead
of building a VIEW_CONVERT_EXPR around it.

* g++.dg/torture/pr71405.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr71405.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c

[Bug tree-optimization/71408] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu

[kugan at gcc dot gnu.org]

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

--- Comment #3 from kugan at gcc dot gnu.org ---
Looking into it. Looks like zero_one_operation is still broken.

[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-04
 CC||alahay01 at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE at -O3 in 32-bit and|[7 Regression] ICE at -O3
   |64-bit modes on |in 32-bit and 64-bit modes
   |x86_64-linux-gnu|on x86_64-linux-gnu
   |(verify_gimple: integral|(verify_gimple: integral
   |result type precision does  |result type precision does
   |not match field size of |not match field size of
   |BIT_FIELD_REF)  |BIT_FIELD_REF)
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r237064.

[Bug fortran/71412] New: iso_c_bindings and optimization interaction bug

[relliott at umn dot edu]

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

Bug ID: 71412
   Summary: iso_c_bindings and optimization interaction bug
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: relliott at umn dot edu
  Target Milestone: ---

Created attachment 38644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38644=edit
minimal skeleton code that illustrates the bug

A problem exists in the way gfortran optimizes functions/subroutines when c
interoperability (and specifically the c_loc() intrinsic) are used.

The attached code illustrates the issue.  A variable is allocated and a pointer
is to the allocated memory is sent to C and stored in global memory.  Next the
memory is initialized in the same routine that it was allocated.  Finally, in a
different routine the memory pointer is retrieved from c and the value stored
in memory is printed.  With optimization -O3 the initialization is optimized
out.  With optimization -O0 the initialization occurs and the code runs
correctly.

The typical output and sequence of steps to run the code is given below.

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ cd skeleton/

vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ make
gfortran -m32 -O3 -g -Wall -pedantic  -c skeleton-f.F90
gcc -m32 -O3 -g -Wall -ansi -pedantic  -c skeleton-c.c
gfortran -m32 -O3 -g -Wall skeleton*.o  -o skeleton

vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ ./skeleton
 -- in storePtr: pointer address --> 0x95caba0 <-- value --> -144534256
 -- just a print statement  --> nothing
 -- in getPtr:   pointer address --> 0x95caba0 <-- value --> -144534256
 -- value of 'val2' variable -->   -144534256

vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ make clean
rm -f skeleton skeleton*.o *.mod

vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ make OPT=-O0
gfortran -m32 -O0 -g -Wall -pedantic  -c skeleton-f.F90
gcc -m32 -O0 -g -Wall -ansi -pedantic  -c skeleton-c.c
gfortran -m32 -O0 -g -Wall skeleton*.o  -o skeleton

vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ ./skeleton
 -- in storePtr: pointer address --> 0x8d09ba0 <-- value --> -143915760
 -- just a print statement  --> nothing
 -- in getPtr:   pointer address --> 0x8d09ba0 <-- value --> 21
 -- value of 'val2' variable -->   21

[Bug c/71411] New: No warnings for OOB accesses with arrays of size 1

[ch3root at openwall dot com]

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

Bug ID: 71411
   Summary: No warnings for OOB accesses with arrays of size 1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

In this example rows in a 2D array are arrays of size 1. gcc is smart enough to
conclude that an unknown index have to be 0 but doesn't warn about known index
1. Raising the level of -Warray-bounds to 2 doesn't help.

Source code:

--
#include 

int main(int c, char **v)
{
  (void)v;

  char a[2][1] = {{5}, {7}};

  printf("c = %d\n", c);
  printf("a[0][c] = %d\n", a[0][c]);
  printf("a[0][1] = %d\n", a[0][1]);
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -Warray-bounds=2 -O3 test.c && ./a.out
c = 1
a[0][c] = 5
a[0][1] = 7
------

gcc version: gcc (GCC) 7.0.0 20160604 (experimental)

For comparison:

--
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
test.c:11:28: warning: array index 1 is past the end of the array (which
contains 1 element) [-Warray-bounds]
  printf("a[0][1] = %d\n", a[0][1]);
   ^~
test.c:7:3: note: array 'a' declared here
  char a[2][1] = {{5}, {7}};
  ^
1 warning generated.
c = 1
a[0][c] = 7
a[0][1] = 7
--

clang version: clang version 3.9.0 (trunk 271312)

[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  ---
Author: olegendo
Date: Sat Jun  4 11:00:58 2016
New Revision: 237090

URL: https://gcc.gnu.org/viewcvs?rev=237090=gcc=rev
Log:
gcc/ChangeLog
PR tree-optimization/52171
* config/sh/sh.c (sh_use_by_pieces_infrastructure_p): Use
by_pieces_ninsns instead of move_by_pieces_ninsns.


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

[Bug tree-optimization/71408] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-04
 CC||jakub at gcc dot gnu.org,
   ||kugan at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|wrong code at -Os and above |[7 Regression] wrong code
   |on x86_64-linux-gnu |at -Os and above on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
This started to ICE in r236564, the ICE got fixed in r236643, but it is
miscompiled already in that revision.

[Bug c++/71406] [7 Regression] ICE on valid C++ code on x86_64-linux-gnu: in finish_class_member_access_expr, at cp/typeck.c:2782

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-04
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on valid C++ code on|[7 Regression] ICE on valid
   |x86_64-linux-gnu: in|C++ code on
   |finish_class_member_access_ |x86_64-linux-gnu: in
   |expr, at cp/typeck.c:2782   |finish_class_member_access_
   ||expr, at cp/typeck.c:2782
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r236221.

[Bug tree-optimization/71405] [6/7 Regression] ICE on valid C++ code at -Os and above on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/71405] [6/7 Regression] ICE on valid C++ code at -Os and above on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-04
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|ICE on valid C++ code at|[6/7 Regression] ICE on
   |-Os and above on|valid C++ code at -Os and
   |x86_64-linux-gnu:   |above on x86_64-linux-gnu:
   |verify_gimple failed|verify_gimple failed
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r222135.

[Bug target/71208] [6 regression] mmix: C++ code fails to link

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #3 from Hans-Peter Nilsson  ---
I don't have access to cygwin(!) but I'll see if I can reproduce this on a
x86_64-linux host.

[Bug tree-optimization/71408] wrong code at -Os and above on x86_64-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(Separately from the wrong code) some of the reads of c.f1 are represented as
BIT_FIELD_REF  & 262143, which prevents us from optimizing it to a
constant (others that are represented as c.f1 work just fine) :-(

  c.f1 = 7;
  c.f3 = 0;
  _1 = BIT_FIELD_REF ;
  _2 = _1 & 262143;
  if (_2 != 0)

[Bug tree-optimization/71410] New: ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 71410
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
Segmentation fault
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 6.1.x. 

This is likely related to PR 71366, which has been fixed. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160603 (experimental) [trunk revision 237075] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c
$ gcc-6.1 -O3 -c small.c
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: Segmentation fault
 fn1 ()
 ^~~
0xbbeaaf crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x789944 find_edge(basic_block_def*, basic_block_def*)
../../gcc-source-trunk/gcc/cfganal.c:506
0xd07431 unloop_loops
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:633
0xd0a6e2 tree_unroll_loops_completely(bool, bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1379
0xd0a893 execute
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1587
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


int a, b[40];

int 
fn1 ()
{
  for (;;)
{
  int c, d; 
  for (c = 0; c < 5; c++)
{
  for (;;)
{
  if (b[(c + 1) * 8])
break;
  return a;
}
  a = a || b[0];
}
  for (d = 0; d < 1; d++)
a = 0;
}
}

[Bug bootstrap/66947] Bootstrap error: Extraneous text after `else' directive

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
> I would like to see the changes in 6.1.0 backported to the upcoming 5.5.0 so
> that this bug is resolved.

Patches should be posted on the gcc-patc...@gcc.gnu.org mailing-list.

[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
I agree that G++ seems to be correct according to the revised direction.

[Bug bootstrap/71409] New: darwin Comparing stages 2 and 3 slight failure

[jay.krell at cornell dot edu]

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

Bug ID: 71409
   Summary: darwin Comparing stages 2 and 3 slight failure
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

MacOSX Yosemite 10.10.4  


  jair:~ jay$ uname -a  
  Darwin jair.local 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04
PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64  


  /src/gcc-6.1.0/configure -prefix=/Users/jay/gcc610  

  make  

  Comparing stages 2 and 3  
  warning: gcc/cc1-checksum.o differs  
  warning: gcc/cc1obj-checksum.o differs  
  warning: gcc/cc1plus-checksum.o differs  
  Bootstrap comparison failure!  
  gcc/tree-ssa-structalias.o differs  
  libcpp/expr.o differs

[Bug tree-optimization/71403] [7 Regression] wrong code (segfault) at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-04
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|wrong code (segfault) at|[7 Regression] wrong code
   |-O3 on x86_64-linux-gnu |(segfault) at -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r236831.

[Bug c++/60272] atomic<>::compare_exchange_weak has spurious store and can cause race conditions

[max.wittal at mwittal dot de]

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

--- Comment #9 from Max Wittal  ---
I still get this bug in gcc version 5.2.1 20151010 on x86_64-linux-gnu.

Please see attached code.

[Bug c++/60272] atomic<>::compare_exchange_weak has spurious store and can cause race conditions

[max.wittal at mwittal dot de]

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

Max Wittal  changed:

   What|Removed |Added

 CC||max.wittal at mwittal dot de

--- Comment #8 from Max Wittal  ---
Created attachment 38642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38642=edit
Example code that still triggers this bug.

[Bug c++/70202] ICE on invalid code on x86_64-linux-gnu in build_simple_base_path, at cp/class.c:579

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug c++/70202] ICE on invalid code on x86_64-linux-gnu in build_simple_base_path, at cp/class.c:579

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Jun  4 07:10:58 2016
New Revision: 237089

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

PR c++/70202
* parser.c (cp_parser_class_head): When xref_basetypes fails and
emits an error do not zero the type.

/testsuite
2016-06-04  Paolo Carlini  

PR c++/70202
* g++.dg/inherit/crash5.C: New.
* g++.dg/inherit/virtual1.C: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/inherit/crash5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/inherit/virtual1.C

[Bug tree-optimization/71408] New: wrong code at -Os and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 71408
   Summary: wrong code at -Os and above on x86_64-linux-gnu
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -Os
and above in both 32-bit and 64-bit modes.

This is a regression from 6.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160603 (experimental) [trunk revision 237075] (GCC) 
$ 
$ gcc-trunk -O1 small.c; ./a.out
$ gcc-6.1 -Os small.c; ./a.out
$ 
$ gcc-trunk -Os small.c
$ ./a.out
4
$ 


---


unsigned a, b;

struct S0
{
  int f1:18;
  unsigned f3:4;
};  

void fn1 ()
{
  struct S0 c = { 7, 0 };
  if (c.f1)
c.f3 = 3;
  a = -~c.f3;
  c.f3 = ~(c.f1 && c.f1);
  c.f1 = c.f3 * (c.f1 - (c.f1 - a % c.f1)) + ~c.f3 * -a;
  b = ~(c.f1 & a);
  if (b >= 4294967295)
__builtin_printf ("%d\n", a);
}

int
main ()
{
  fn1 ();
  return 0; 
}

[Bug tree-optimization/71407] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)

[chengniansun at gmail dot com]

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

Chengnian Sun  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #1 from Chengnian Sun  ---
A better cleaned test case. 

int a, c, d;
short b;

void fn1 ()
{
  int e;
  for (; c; c++)
{
  for (; a; a++)
b = (short) a || e;
  e = d;
}
}

[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0

[sch...@linux-m68k.org]

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

--- Comment #10 from Andreas Schwab  ---
../../gcc/expr.c:1146:60: error: unused parameter 'mode'
[-Werror=unused-parameter]
 move_by_pieces_d::generate (rtx op0, rtx op1, machine_mode mode)
^~~~

[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction

[owner at bugs dot debian.org]

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

--- Comment #15 from owner at bugs dot debian.org ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message has not been forwarded to the package maintainers or
other interested parties; you should ensure that the developers are
aware of the problem you have entered into the system - preferably
quoting the Bug reference number, #85535.

If you wish to submit further information on this problem, please
send it to 85535-qu...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||12086

--- Comment #9 from Andrew Pinski  ---
Doesn't this partly solve bug 12086 also?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
[Bug 12086] memcmp(i,j,4) should use word (SI) subtraction