[Bug tree-optimization/69399] [5/6 Regression] wrong code with -O and int128 (due to ccp?)

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to H.J. Lu from comment #1)
> It works fine with x32 on trunk:
> 
> [hjl@gnu-6 gcc]$ ./xgcc -B./ -O /tmp/x.c
> [hjl@gnu-6 gcc]$ ./a.out 
> [hjl@gnu-6 gcc]$ file ./a.out 
> ./a.out: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0,
> BuildID[sha1]=d7fda1eccd8a9d4b9a9eb05c83ea7306f5fe1709, not stripped
> [hjl@gnu-6 gcc]$

In trunk, this seems to happen only when crosscompiling:

(native x86_64 compiler with -mx32)
$ x86-64-pc-linux-gnu-gcc testcase.c -S -O -mx32
...
foo:
movl$0, %eax
ret
...

but (crosscompiler to x32):
$ x86-64-pc-linux-gnux32-gcc testcase.c -S -O
...
foo:
movl$-127, %eax
ret
...

Native x32 gcc-5.3.0 fails: (native x86_64 fails as well)
# gcc-5.3.0 -O testcase.c
# ./a.out 
Aborted

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #15 from Nick Clifton  ---
Hi Roger, Hi Tony,

I have been trying, unsuccessfully, to build a complete cygwin toolchain, but I
was able to reproduce the reported failure.

I did try out the patch below, which implements Tony's idea of restricting my
original patch to just Mingw targets, but I was still unable to build a full
toolchain (for other reasons).  Roger - perhaps you would be able to test out
the patch in your build environment for me ?

Cheers
  Nick

Index: gcc/config/i386/cygwin.h
===
--- gcc/config/i386/cygwin.h(revision 232666)
+++ gcc/config/i386/cygwin.h(working copy)
@@ -157,3 +157,5 @@
 /* We should find a way to not have to update this manually.  */
 #define LIBGCJ_SONAME "cyggcj" /*LIBGCC_EH_EXTN*/ "-16.dll"

+/* Cygwin does not support weak symbols.  */
+#undef MAKE_DECL_ONE_ONLY

[Bug testsuite/69406] FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
The test should PASS now.

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||nickc at gcc dot gnu.org

--- Comment #15 from Nick Clifton  ---
Hi Guys,

  I have checked in Bernd's patch as it also fixes PR 69129.  I think that this
PR can also be closed now, although I am not sure if we need to add another
testcase to gcc.target/mips.  (I added a testcase for pr69129...)

Cheers
  Nick

[Bug testsuite/69380] [6 Regression] FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap"

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 Target|arm-none-eabi powerpc*-*-*  |arm-none-eabi powerpc*-*-*
   ||aarch64*-*-*
 CC||alalaw01 at gcc dot gnu.org

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
adding "--param max-sra-scalarization-size-Ospeed=72" makes the testcase pass;
or we can XFAIL on arm, AArch64, powerpc (presumably also hppa, alpha, and
others). 72 is quite large; thoughts?

(This suggests that when we move the logic in gimplify_init_constructor, for
pushing stuff out to the constant pool, into tree-sra.c, we may also want to
refine it a bit. But in the meantime...)

[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8

[jakub at gcc dot gnu.org]

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

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

Untested fix.  Though, I wonder if mod_type_die already has some parent it
wouldn't be better to stick the qualified DIEs for it always under the same
parent, rather than to whatever other mod_scope is current at the time when
creating the DIEs.

[Bug libstdc++/69413] [6 Regression] r232327 prevents libstdc++ working after upgrading glibc to 2.23

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug go/69357] libgo refers to _end in a non-weak way

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Btw, my thought was that it ends up like

> cat t2.c
int x = 1;
> gcc t2.c -o libt2.so -shared -lisl -fPIC
> cat t.c
extern char _end[];
char *endp = _end;
int main()
{
}
> gcc -Wl,--as-needed -Wl,--no-add-needed -L. -lt2 -Bstatic t.o -Bdynamic 

where libt2.so might provide _end (but is not needed and not linked in the
end),
referenced from t.o (simulating -static-libgo).

It doesn't error this way though (maybe because libt2.so itself provides _end).

[Bug c++/69411] ICE on invalid code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Marek Polacek  ---
Looks like this was fixed in:

commit 8a9401a4c6a15518e504cb69b16147f02f288526
Author: jakub 
Date:   Tue Jan 12 15:21:27 2016 +

PR objc++/68511
PR c++/69213
* cp-gimplify.c (cp_gimplify_expr) : Don't return
GS_ERROR whenever seen_error (), only if *expr_p contains
cilk spawn stmt, but cilk_detect_spawn_and_unwrap failed.

* g++.dg/opt/pr69213.C: New test.


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

[Bug fortran/68765] warning for aliasing restrict parameters

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #3)
> Sorry, but I did ask further information in
> 
> > Without explicit interface and the main and subroutine in different files,
> > IMO there is no way to give a warning. Even with the test in comment 0,
> > giving a reliable warning will be difficult.
> >

Sorry, but I don't understand what further information is requested here. What
is it you want to know?

[Bug other/69412] New: bootstrap-ubsan profiledbootstrap issues

[trippels at gcc dot gnu.org]

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

Bug ID: 69412
   Summary: bootstrap-ubsan profiledbootstrap issues
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Running:
...--with-build-config="bootstrap-ubsan bootstrap-O3"
make profiledbootstrap

shows on gcc112 (ppc64le):

config/rs6000/rs6000.c:5884:36: runtime error: left shift of negative value
-12301
config/rs6000/rs6000.md:3237:25: runtime error: shift exponent -1 is negative
cp/parser.c:755:7: runtime error: member call on null pointer of type 'struct
vec'
expmed.c:3144:19: runtime error: left shift of negative value -1
real.c:2889:25: runtime error: left shift of negative value -968
simplify-rtx.c:2687:49: runtime error: left shift of 699 by 63 places cannot be
represented in type 'long int'
sreal.c:231:20: runtime error: left shift of negative value -1137897900

[Bug libstdc++/69413] New: [6 Regression] r232327 prevents libstdc++ working after upgrading glibc to 2.23

[redi at gcc dot gnu.org]

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

Bug ID: 69413
   Summary: [6 Regression] r232327 prevents libstdc++ working
after upgrading glibc to 2.23
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The fixes for PR 48891 require libstdc++ to be rebuilt after upgrading glibc to
current trunk (which will be 2.23), because the configure-time checks for isinf
and isnan give the wrong answer for the new glibc.

There needs to be a compile-time check so that rebuilding gcc isn't needed (or
glibc needs to define a macro telling us the isinf and isnan declarations have
been suppressed).

[Bug c++/69315] [6 Regression] ICE in finish_function with constexpr and templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-21
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE in finish_function with |[6 Regression] ICE in
   |constexpr and templates |finish_function with
   ||constexpr and templates
 Ever confirmed|0   |1

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

Started with r230365 - C++ delayed folding merge.

[Bug rtl-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Indeed, it does.

[Bug tree-optimization/69347] [6 regression] excessive compile time with -O2

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law  ---
And in fact, we purposefully raised the maximum amount of memory that we allow
GCSE to allocate (precisely for this kind of function).  This testcase now
comes in under that maximum limit and thus we GCSE this function.

If I use the same limits, then we're looking at a total of 17.56 seconds for
gcc-5 vs 19.08 for the trunk.  Roughly 2/3s of that slowdown is DOM.

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Also consider


typedef int myint __attribute__((align(1)));
void foo (int, int);

void bar()
{
  foo ((myint)1, (myint)2);
  foo (1, 2);
}

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #15)
> After discussing this on IRC I'll make a change to support this use case,
> without needing to rebuild libstdc++ when glibc is updated.

I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69413 for that.

[Bug other/69412] bootstrap-ubsan profiledbootstrap issues

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
cp/parser.c:755:7 issue started with the "expression ranges" commit r231293.

  747 static inline cp_token *  
  748 cp_lexer_previous_token (cp_lexer *lexer) 
  749 { 
  750   cp_token_position tp = cp_lexer_previous_token_position (lexer);
  751   
  752   /* Skip past purged tokens.  */ 
  753   while (tp->purged_p)
  754 { 
  755   gcc_assert (tp != lexer->buffer->address ());   
  756   tp--;   
  757 }

[Bug libgomp/69414] New: [OpenACC] "!$acc update self" does not provide expected result

[dc-fukuoka at sgi dot com]

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

Bug ID: 69414
   Summary: [OpenACC] "!$acc update self" does not provide
expected result
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dc-fukuoka at sgi dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37418=edit
including a reproducer, test script and the patch.

To whom it may concern, 

We are using gcc/5.2.0 with OpenACC support in our system.
One user found a bug of OpenACC of gcc.
I confirmed that the bug exists in gcc/5.3.0.
Please have a look at the attached file.

=
$ cat gcc1.f90
program gcc1
  use openacc
  implicit none
  integer :: a(16)=0
  integer :: i

  !$acc enter data copyin(a)
  !$acc kernels present(a)
  !$acc loop
  do i=1,16
 a(i)=a(i)+i
  end do
  !$acc end kernels
  !$acc update self(a(7:13))
  !$acc exit data delete(a)
  write(*,'(16i3)') a(:)
end program gcc1
=

The output should be 0  0  0  0  0  0  7  8  9 10 11 12 13  0  0  0.
If gcc 5.3.0 is used, it gives 0  0  0  0  0  0  1  2  3  4  5  6  7  0  0  0.

=
$ module load gcc/5.3.0
$ gfortran -g -o gcc1.gnu -fopenacc -foffload=nvptx-none gcc1.f90
$ ./gcc1.gnu
  0  0  0  0  0  0  1  2  3  4  5  6  7  0  0  0
=

If PGI compiler 15.10 is used, it provides expected result.

=
$ module switch gcc/5.3.0 pgi/15.10
$ pgfortran -g -o gcc1.pgi -acc -ta=tesla:cc35 gcc1.f90
$ ./gcc1.pgi
  0  0  0  0  0  0  7  8  9 10 11 12 13  0  0  0
=
And then I looked into the source code libgomp/oacc-mem.c, and found that it
can be fixed by the attached patch.

=
$ module switch pgi/15.10 gcc/5.3.0.patched
$ gfortran -g -o gcc1.gnu.patched -fopenacc -foffload=nvptx-none gcc1.f90
$ ./gcc1.gnu.patched
  0  0  0  0  0  0  7  8  9 10 11 12 13  0  0  0
=

I tested several OpenACC programs with the patch, so far it works fine.
Please review the patch and let me know if the patch can be applied into our
production system or not.

Best regards,
Daichi Fukuoka

[Bug c++/58046] template operator= in SFINAE class

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jan 21 10:55:30 2016
New Revision: 232671

URL: https://gcc.gnu.org/viewcvs?rev=232671=gcc=rev
Log:
2016-01-21  Paolo Carlini  

PR c++/58046
* g++.dg/cpp0x/pr58046.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr58046.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[trippels at gcc dot gnu.org]

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

Bug 63427 Summary: hwint.h:250:29: runtime error: shift exponent 64 is too 
large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63427

   What|Removed |Added

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

[Bug fortran/63427] hwint.h:250:29: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
closing as fixed

[Bug c++/69410] New: friend declarations in local classes

[colu...@gmx-topmail.de]

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

Bug ID: 69410
   Summary: friend declarations in local classes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colu...@gmx-topmail.de
  Target Milestone: ---

void a();
void f() {
class A {
friend void ::a();
friend class Z;
};
}

---

The above fails for two (false) reasons, although it shouldn't. a is qualified,
therefore [class.friend]/11 does not apply. However, [class.friend]/11 does
apply in the subsequent declaration, making it well-formed - Z is declared to
be a local class. See the example in the aforementioned paragraph.

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Indeed, latest trunk with
-O3 -mcpu=power7 -mtune=power8 pr67211.C -fno-vect-cost-model
still ICEs.

[Bug c++/69290] [6 Regression] g++ ICE (segfault) on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-21
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|g++ ICE (segfault) on   |[6 Regression] g++ ICE
   |x86_64-linux-gnu|(segfault) on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r231665.  This might be a dup.

[Bug c++/69138] Woverflow not triggered for constexpr within template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug testsuite/69406] FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 21 13:33:27 2016
New Revision: 232672

URL: https://gcc.gnu.org/viewcvs?rev=232672=gcc=rev
Log:
libstdc++/69406 Fix test to check for supported headers

PR libstdc++/69406
* include/bits/cpp_type_traits.h: Ensure C++ language linkage.
* include/ext/type_traits.h: Likewise.
* testsuite/17_intro/headers/c++2011/linkage.cc: Check autoconf macros
for presence of C headers.
* testsuite/ext/type_traits/add_unsigned_floating_neg.cc: Adjust
dg-error line number.
* testsuite/ext/type_traits/add_unsigned_integer_neg.cc: Likewise.
* testsuite/ext/type_traits/remove_unsigned_floating_neg.cc: Likewise.
* testsuite/ext/type_traits/remove_unsigned_integer_neg.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/cpp_type_traits.h
trunk/libstdc++-v3/include/ext/type_traits.h
trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/linkage.cc
trunk/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_floating_neg.cc
trunk/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_integer_neg.cc
   
trunk/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_floating_neg.cc
trunk/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_integer_neg.cc

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug target/69129] [6 Regression] ICE in get_attr_got, at config/mips/mips.md:694 on mips-linux-gnu

[nickc at gcc dot gnu.org]

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

--- Comment #6 from Nick Clifton  ---
Author: nickc
Date: Thu Jan 21 14:07:01 2016
New Revision: 232674

URL: https://gcc.gnu.org/viewcvs?rev=232674=gcc=rev
Log:
PR target/69129
PR target/69012
* config/mips/mips.c (mips_compute_frame_info): Initialise
args_size and hard_frame_pointer_offset fields of the frame
structure before calling mips_global_pointer.

PR target/69129
* gcc.target/mips/pr69129.c: New.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr69129.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
This reduced testcase started ICEing with r230365.

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[nickc at gcc dot gnu.org]

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

--- Comment #14 from Nick Clifton  ---
Author: nickc
Date: Thu Jan 21 14:07:01 2016
New Revision: 232674

URL: https://gcc.gnu.org/viewcvs?rev=232674=gcc=rev
Log:
PR target/69129
PR target/69012
* config/mips/mips.c (mips_compute_frame_info): Initialise
args_size and hard_frame_pointer_offset fields of the frame
structure before calling mips_global_pointer.

PR target/69129
* gcc.target/mips/pr69129.c: New.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr69129.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68769] [fortran] annotate omp data pointers with restrict for -fno-cray-pointers

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> > Without pointers, there's no way to introduce an alias for a and b.
> 
> Indeed! but I don't understand what cray pointers have to do with that. They
> are an extension to f77 which is rejected by gfortran unless -fcray-pointer
> is used

I was looking around for something 'pointery' in fortran, and fcray-pointer is
what I found.

 > Note that in post f90 standards, POINTERs are part of the Fortran syntax and
> can alias. 

I see, that's good to know.

Indeed, with this program, I can introduce aliasing:
...
program main
  implicit none
  integer, parameter :: n = 1024
  integer:: i
  integer, target :: a(n)
  integer, pointer :: b(:)

  b => a
  i = 0

  do i = 0, n - 1
 a(i) = i * 2
  end do

!$omp parallel do
  do i = 1, n
 a(i) = b(i) + b(i)
  end do

  do i = 0, n - 1
 if (a(i) .ne. i * 4) call abort
  end do

end program main
...

Marking resolved-invalid.

[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
[Sorry for the delay, email hiccup over the last couple of days]

> CCing Eric on whether REF_REVERSE_STORAGE_ORDER should be checked in
> operand_equal_p and whether TYPE_REVERSE_STORAGE_ORDER doesn't have to be
> tested in useless_type_conversion_p (perhaps the latter is ok, if it is not
> possible for two aggregates with the same TYPE_CANONICAL to have different
> TYPE_REVERSE_STORAGE_ORDER).

The design is that memory references are always accessed in the same storage
order, i.e. there will be no references to the same memory location differing
only by the storage order in the program; in other words, operand_equal_p need
not bother about REF_REVERSE_STORAGE_ORDER if everything works as designed.

Likewise for useless_type_conversion_p: TYPE_REVERSE_STORAGE_ORDER is a
property of canonical types and cannot differ between types with the same
canonical type.

[Bug target/69403] Wrong thumb2_ior_scc_strict_it insn pattern.

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Self-contained testcase that works form -O2 -march=armv7-a -mthumb but aborts
for -O2 -march=armv8-a -mthumb:

int a, b, c;

__attribute__ ((__noinline__)) int
fn1 ()
{
  if ((b | (a != (a & c))) == 1)
__builtin_abort ();
  return 0;
}

int
main (void)
{
  a = 5;
  c = 1;
  b = 6;
  return fn1 ();
}

[Bug fortran/68765] warning for aliasing restrict parameters

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #2 from vries at gcc dot gnu.org ---
Status 'waiting' means: 'The submitter was asked for further information, or
asked to try out a patch' ( https://gcc.gnu.org/bugs/management.html ).

Since there's no patch to try out, nor a request for further information,
setting status back to unconfirmed.

[Bug other/69412] bootstrap-ubsan profiledbootstrap issues

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-21
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
On x86_64 I get:

gcc/combine.c:12304:18: runtime error: left shift of negative value -4096
gcc/cp/parser.c:755:7: runtime error: member call on null pointer of type
'struct vec'
gcc/dwarf2out.c:1518:45: runtime error: negation of -9223372036854775808 cannot
be represented in type 'long int [3]'; cast to an unsigned type to negate this
value to itself
gcc/expmed.c:3144:19: runtime error: left shift of negative value -1
gcc/real.c:2889:25: runtime error: left shift of negative value -63
gcc/rtlanal.c:5119:48: runtime error: shift exponent 4294967295 is too large
for 64-bit type 'long unsigned int'
gcc/sreal.c:231:20: runtime error: left shift of negative value -1073741824
libiberty/md5.c:336:7: runtime error: load of misaligned address 0x7ffdfca83722
for type 'const md5_uint32', which requires 4 byte alignment
..
libiberty/md5.c:351:7: runtime error: load of misaligned address 0x7ffe90f5ca96
for type 'const md5_uint32', which requires 4 byte alignment

[Bug rtl-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Marek, can't reproduce this either, r225722 with -m32 -O2 works the same as
r225721.  Any special options have been used?

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[vogt at linux dot vnet.ibm.com]

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

--- Comment #13 from Dominik Vogt  ---
I'm running into problems testing the latest Gcc with the latest Glibc.  The
test program is just

  #include 

It's a bit difficult to provide the propert args to g++ to make it use the
replacement Glibc after its own headers but before the system Glibc.  This
should do it:

  $ g++ --sysroot ~/src/git/glibc/install -std=c++11 x.C

However, this results in errors with isnan and isinf:

-- snip --
  In file included from .../git/gcc/install/include/c++/6.0.0/math.h:36:0,
   from x.C:1:
  .../gcc/install/include/c++/6.0.0/cmath:614:11: error: ‘::isinf’ has not been
declared
 using ::isinf;
 ^

  .../gcc/install/include/c++/6.0.0/cmath:638:11: error: ‘::isnan’ has not been
declared
 using ::isnan;
 ^
-- snip --

With -v Gcc prints this include dir search list which looks fine to me:

-- snip --
ignoring nonexistent directory ".../glibc/install/usr/local/include"
ignoring nonexistent directory
".../gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/../../../../s390x-ibm-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

.../gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/../../../../include/c++/6.0.0

.../gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/../../../../include/c++/6.0.0/s390x-ibm-linux-gnu

.../gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/../../../../include/c++/6.0.0/backward
 .../gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/include
 .../gcc/install/include
 .../gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/include-fixed
 .../glibc/install/usr/include
End of search list.
-- snip --

Not sure whether this is a Gcc issue, a Glibc issue or just bad arguments to
g++.

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||mrestelli at gmail dot com

--- Comment #7 from Dominique d'Humieres  ---
*** Bug 69409 has been marked as a duplicate of this bug. ***

[Bug fortran/69409] Internal compiler error with -fcheck=all

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr69385.

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

[Bug c++/69411] New: ICE on invalid code

[bernd.edlinger at hotmail dot de]

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

Bug ID: 69411
   Summary: ICE on invalid code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Created attachment 37416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37416=edit
reduced test case

Hi,

the attached small.cc creates an ICE when compiled with -fsanitize=undefined
initially the ICE was triggered by a single error in > 100.000 lines C++ code.

gcc -c -fsanitize=undefined small.cc
small.cc:2:3: error: expected '{' before 'inline'
   inline namespace __cxx11 __attribute__((__abi_tag__ ("cxx11"))) { }
   ^~
[...]
small.cc:151:1: error: expected '}' at end of input
small.cc:126:12: warning: inline function 'T*
std::TB5Util::SOCmnPointer::p() const [with T =
std::TB5Util::OTClientSession]' used but never defined
  inline T* p() const;
^

small.cc:134:24: warning: inline function 'const tstring&
std::TB5Util::OTClientSession::getUrl() const' used but never defined
  inline const tstring& getUrl() const;
^~

small.cc: In member function 'std::TB5Util::EnumStatusCode
std::TB5Util::SecureChannel::removeSession(std::TB5Util::OTClientSessionPtr,
bool)':
small.cc:150:121: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.c:497
   messageStream << "Secure channel: " << this << "(" << m_channelHandle << ")
remove session " << session->getName() << " (" << session.p() << ") to " <<
session->getUrl();
   
 ^~~~

0xf86f27 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-6-20160110/gcc/tree.c:9654
0xace87f tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-6-20160110/gcc/tree.h:3121
0xace87f create_tmp_from_val
../../gcc-6-20160110/gcc/gimplify.c:497
0xace87f lookup_tmp_var
../../gcc-6-20160110/gcc/gimplify.c:533
0xace87f internal_get_tmp_var
../../gcc-6-20160110/gcc/gimplify.c:563
0xac6652 get_initialized_tmp_var(tree_node*, gimple**, gimple**)
../../gcc-6-20160110/gcc/gimplify.c:600
0xac6652 gimplify_save_expr
../../gcc-6-20160110/gcc/gimplify.c:4977
0xac6652 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6-20160110/gcc/gimplify.c:10402
0xad737a gimplify_call_expr
../../gcc-6-20160110/gcc/gimplify.c:2361
0xac6ac1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6-20160110/gcc/gimplify.c:10085
0xacb756 gimplify_stmt(tree_node**, gimple**)
../../gcc-6-20160110/gcc/gimplify.c:5616
0xacc361 gimplify_compound_expr
../../gcc-6-20160110/gcc/gimplify.c:4932
0xac724c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6-20160110/gcc/gimplify.c:10103
0xad6c9b gimplify_call_expr
../../gcc-6-20160110/gcc/gimplify.c:2528
0xac6ac1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6-20160110/gcc/gimplify.c:10085
0xace24c internal_get_tmp_var
../../gcc-6-20160110/gcc/gimplify.c:557
0xac6652 get_initialized_tmp_var(tree_node*, gimple**, gimple**)
../../gcc-6-20160110/gcc/gimplify.c:600
0xac6652 gimplify_save_expr
../../gcc-6-20160110/gcc/gimplify.c:4977
0xac6652 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6-20160110/gcc/gimplify.c:10402
0xad737a gimplify_call_expr
../../gcc-6-20160110/gcc/gimplify.c:2361
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Eric Botcazou from comment #12)
> [Sorry for the delay, email hiccup over the last couple of days]
> 
> > CCing Eric on whether REF_REVERSE_STORAGE_ORDER should be checked in
> > operand_equal_p and whether TYPE_REVERSE_STORAGE_ORDER doesn't have to be
> > tested in useless_type_conversion_p (perhaps the latter is ok, if it is not
> > possible for two aggregates with the same TYPE_CANONICAL to have different
> > TYPE_REVERSE_STORAGE_ORDER).
> 
> The design is that memory references are always accessed in the same storage
> order, i.e. there will be no references to the same memory location
> differing only by the storage order in the program; in other words,
> operand_equal_p need not bother about REF_REVERSE_STORAGE_ORDER if
> everything works as designed.

How do you ensure that?  You could (perhaps through aliasing violation or union
or what) access the same memory slot through two different MEMs, and if one of
them has reverse and the other does not...

> Likewise for useless_type_conversion_p: TYPE_REVERSE_STORAGE_ORDER is a
> property of canonical types and cannot differ between types with the same
> canonical type.

Is TYPE_REVERSE_STORAGE_ORDER only used for aggregates, or even scalar types?
Because for the latter, useless_type_conversion_p usually only cares about
precision and signedness and nothing else, doesn't care about TYPE_CANONICAL.

[Bug target/69403] [4.9/5/6 Regression] Wrong thumb2_ior_scc_strict_it insn pattern.

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
   Target Milestone|--- |4.9.5
Summary|Wrong   |[4.9/5/6 Regression] Wrong
   |thumb2_ior_scc_strict_it|thumb2_ior_scc_strict_it
   |insn pattern.   |insn pattern.
  Known to fail||4.9.4, 5.3.1, 6.0

[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
> How do you ensure that?  You could (perhaps through aliasing violation or
> union or what) access the same memory slot through two different MEMs, and
> if one of them has reverse and the other does not...

Indeed, you cannot use type punning to toggle the storage order, or else Bad
Things will happen...

> Is TYPE_REVERSE_STORAGE_ORDER only used for aggregates, or even scalar types?

Only for aggregate types.

[Bug fortran/68765] warning for aliasing restrict parameters

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Status 'waiting' means: 'The submitter was asked for further information,
> or asked to try out a patch' ( https://gcc.gnu.org/bugs/management.html ).
>
> Since there's no patch to try out, nor a request for further information,
> setting status back to unconfirmed.

Sorry, but I did ask further information in

> Without explicit interface and the main and subroutine in different files,
> IMO there is no way to give a warning. Even with the test in comment 0,
> giving a reliable warning will be difficult.
>
> I am in favor to close this PR as WONTFIX.

"setting status back to unconfirmed" does not help.

[Bug c/69407] -Wunused-value on __atomic_fetch_OP and __atomic_OP_fetch

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek  ---
I'll look into this.

[Bug c/69407] -Wunused-value on __atomic_fetch_OP and __atomic_OP_fetch

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Started a long time ago:


commit 1cd6e20de6e40ead3795087811f151f00b06e016
Author: amacleod 
Date:   Sun Nov 6 14:55:48 2011 +

Check in patch/merge from cxx-mem-model  Branch



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

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #14)
> So I believe the problem is that you need to reconfigure libstdc++ with the
> new glibc headers, you can't just drop them in later and expect an
> already-built libstdc++ to work with them. Libstdc++ depends on glibc, so if
> you update glibc (or fake doing so by using --sysroot to point at a new
> glibc) then you need to rebuild libstdc++ too.

After discussing this on IRC I'll make a change to support this use case,
without needing to rebuild libstdc++ when glibc is updated.

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from janus at gcc dot gnu.org ---
Hi Paul,

> As you will have seen, I have posted a fix for the first problem

you mean the one in comment #3? It sounded like you were not quite happy with
it yet, but I will anyway give it a try tonight ...


> and
> have another fix in the pipeline for the problem in comment #5.
> 
> I'll post them on the PR but cannot do any more than that until SUnday night.

Yes, if you have any further patches, please share them here. I will be happy
to regtest anything you manage to cook up ...

Cheers,
Janus

[Bug fortran/69409] New: Internal compiler error with -fcheck=all

[mrestelli at gmail dot com]

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

Bug ID: 69409
   Summary: Internal compiler error with -fcheck=all
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

Compiling the attached code with the latest trunk version and using
-fcheck=all produces an internal compiler error:


module m

 implicit none

 private

 type :: t_a
  real, allocatable :: ax(:)
 end type t_a

contains

 pure function new_a(x) result(a)
  type(t_a) :: a
  real, intent(in) :: x

   allocate( a%ax(1) )
   a%ax = x

 end function new_a

end module m



$ gfortran -fcheck=all -c m.f90
m.f90:18:0:

a%ax = x


internal compiler error: in wide_int_to_tree, bei tree.c:1488
0xc62e93 wide_int_to_tree(tree_node*,
generic_wide_int const&)
.././../gcc-trunk-source/gcc/tree.c:1488
0xc62f79 build_int_cst(tree_node*, long)
.././../gcc-trunk-source/gcc/tree.c:1296
0x6b788d gfc_trans_assignment_1
.././../gcc-trunk-source/gcc/fortran/trans-expr.c:9305
0x681571 trans_code
.././../gcc-trunk-source/gcc/fortran/trans.c:1680
0x6a485c gfc_generate_function_code(gfc_namespace*)
.././../gcc-trunk-source/gcc/fortran/trans-decl.c:6107
0x684861 gfc_generate_module_code(gfc_namespace*)
.././../gcc-trunk-source/gcc/fortran/trans.c:2058
0x63de9d translate_all_program_units
.././../gcc-trunk-source/gcc/fortran/parse.c:5599
0x63de9d gfc_parse_file()
.././../gcc-trunk-source/gcc/fortran/parse.c:5818
0x67e685 gfc_be_parse_file
.././../gcc-trunk-source/gcc/fortran/f95-lang.c:201


$ gfortran --version
GNU Fortran (GCC) 6.0.0 20160120 (experimental)


(version 4.9.3 is fine; in fact, I think this is a regression
interoduced recently, even if I can not say exactly when).

[Bug c++/58046] template operator= in SFINAE class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Dominik Vogt from comment #13)
> -- snip --
>   In file included from .../git/gcc/install/include/c++/6.0.0/math.h:36:0,
>from x.C:1:
>   .../gcc/install/include/c++/6.0.0/cmath:614:11: error: ‘::isinf’ has not
> been declared
>  using ::isinf;
>  ^

If this line is being compiled it means libstdc++ was configured against the
old glibc headers (because _GLIBCXX_HAVE_OBSOLETE_ISINF_ISNAN is defined). The
error means you are successfully using the new glibc headers when compiling
your test, but they don't match the glibc headers used at configure-time.

So I believe the problem is that you need to reconfigure libstdc++ with the new
glibc headers, you can't just drop them in later and expect an already-built
libstdc++ to work with them. Libstdc++ depends on glibc, so if you update glibc
(or fake doing so by using --sysroot to point at a new glibc) then you need to
rebuild libstdc++ too.

[Bug c/69382] noinit()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
GCC Bugzilla isn't the right place to ask questions like these.  Please use
gcc-help mailing list: https://gcc.gnu.org/ml/gcc-help/

dereferencing type-punned pointer will break strict-aliasing rules

[Marcel Behlau]

Hi,

i wan't to create aliase (name and type) for the elements of an 
char-array. Unfortunately my gcc produce the warning "dereferencing 
type-punned pointer will break strict-aliasing rules", if i use -O2 or 
bigger. Since i set -Werror, the warning will become an error.


I attached an example to this mail. To compile and generate the problem, 
i use "gcc -O2 -Werror -Wall main.cpp".


I found an workaround (without using pragma, or somethink else), with 
it's included in the code, too. To activate, pass an extra "-DWorking" 
to the gcc-Command. The workaround is working, but using an pointer is 
ugly.


Best regrads,

Marcel

--
Dipl. Ing (FH) Marcel Behlau
(Software Developer)

ELFIN GmbH
Siegburger Straße 215
50679 Köln
Germany

Tel: +49 (221) 6778932-0
Fax: +49 (221) 6778932-2
marcel.beh...@elfin.de
www.elfin.de

//gcc -O2 -Wall main.cpp
//gcc -O2 -Wall main.cpp -DWorking

//#define Working

struct Ec
{
  char ecData;
};

class ClassZero
{
public:
  char data[8];
  char* pointer;
  Ec& ec0;

#ifdef Working
  ClassZero() : pointer(data), ec0(*(Ec*)(pointer)) { }
#else
  ClassZero() : ec0(*(Ec*)(data)) { }
#endif

};

int main()
{
return 0;
} 

[Bug testsuite/69380] [6 Regression] FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I think we should just restrict such a scan-tree-dump-not test to the targets
where it is known to succeed for now.

[Bug rtl-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Does using -march=x86-64 makes the bug appear?

[Bug target/69129] [6 Regression] ICE in get_attr_got, at config/mips/mips.md:694 on mips-linux-gnu

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #7 from Nick Clifton  ---
I have now checked in the patch.  The same patch was also generated for PR
69012, so that PR can probably be closed as well.

[Bug tree-optimization/69355] [5/6 Regression] Wrong results with -O1 optimization

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 21 07:59:32 2016
New Revision: 232663

URL: https://gcc.gnu.org/viewcvs?rev=232663=gcc=rev
Log:
PR c++/69355
* tree-dfa.c (get_ref_base_and_extent): Use GET_MODE_BITSIZE (mode)
for bitsize instead of GET_MODE_PRECISION (mode).

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

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

[Bug tree-optimization/69347] [6 regression] excessive compile time with -O2

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
A goodly amount of the problem is PRE (rtl-pre):

gcc-5:

 PRE :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc


 PRE :  11.16 (34%) usr   0.88 ( 8%) sys  12.05 (28%) wall 
   499 kB ( 0%) ggc

What's exceedingly strange is I thought I had done a comparison of gcc-4.9,
gcc-5 and gcc-6, finding that gcc-4.9 & gcc-6 were comparable after my change. 
I must have missed something along the way.

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-21
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE in dwarf2out_finish, at |[6 Regression] ICE in
   |dwarf2out.c:27175 with LTO  |dwarf2out_finish, at
   ||dwarf2out.c:27175 with LTO
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Sounds possibly related to PR69137 as that has changes to deferred_asm_name
creation points (you can try confirming this by reverting the change).

You reduce the testcase by adding -r -nostdlib to the link line and "bisect"
the object files needed to trigger the bug.  If -flto-partition=1to1 reproduces
the bug as well then do the reduction with that option active.  Then if you
reached a minimal set substitute preprocessed source for the object file inputs
and attach those (those you can then reduce further if you like).

Thus waiting for a testcase.

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The dividend is val = {-1, 0}, len = 2  (bah, we need a debug_wide_int for
gdb use!)

We do

  n = divisor_blocks_needed;
  while (n > 1 && b_divisor[n - 1] == 0)
n--;

stripping the leading zeros and feed that n to

  if (remainder)
{
  wi_pack ((unsigned HOST_WIDE_INT *) remainder, b_remainder, n);
  *remainder_len = canonize (remainder, (n + 1) / 2, dividend_prec);
  /* The remainder is always the same sign as the dividend.  */
  if (dividend_neg)
*remainder_len = wi::sub_large (remainder, zeros, 1, remainder,
*remainder_len, dividend_prec,
UNSIGNED, 0);

so in int_const_binop we end up with val = {-2 }, len = 1 (that's still correct
I think given wide-int rules).

Interestingly things go downhill in wide_int_to_tree where we compute
ext_len as 3 and go the build_new_int_cst path which does

  if (len < ext_len)
{
  --ext_len;
  TREE_INT_CST_ELT (nt, ext_len)
= zext_hwi (-1, cst.get_precision () % HOST_BITS_PER_WIDE_INT);
  for (unsigned int i = len; i < ext_len; ++i)
TREE_INT_CST_ELT (nt, i) = -1;

thus puts { -2, -1, 0 } in the INTEGER_CST storage (instead of { -2, 0, 0 }).

I think it needs to put 0 there for TYPE_UNSIGNED?  But then not sure
why it computes ext_len to 3 instead of 2 for this case anyway...  it does

  if (TYPE_UNSIGNED (type) && wi::neg_p (cst))
return cst.get_precision () / HOST_BITS_PER_WIDE_INT + 1;

but I'd have expected

return cst.get_len () + 1;

well, the three kinds of lengths are somewhat odd, so I simply assume 3
is correct for now.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 232666)
+++ gcc/tree.c  (working copy)
@@ -1267,7 +1267,7 @@ build_new_int_cst (tree type, const wide
   TREE_INT_CST_ELT (nt, ext_len)
= zext_hwi (-1, cst.get_precision () % HOST_BITS_PER_WIDE_INT);
   for (unsigned int i = len; i < ext_len; ++i)
-   TREE_INT_CST_ELT (nt, i) = -1;
+   TREE_INT_CST_ELT (nt, i) = TYPE_UNSIGNED (type) ? 0 : -1;
 }
   else if (TYPE_UNSIGNED (type)
   && cst.get_precision () < len * HOST_BITS_PER_WIDE_INT)

doesn't fix this unfortunately, so the bug must be elsewhere (eventually
-2 and len = 1 is not correct as result from divmod).

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #6)
> so in int_const_binop we end up with val = {-2 }, len = 1 (that's still

I think already this is wrong, because I think val = { -2 }, len = 1 for
precision 128 is 0xfffeU128 rather than
0xfffeU128.  But I could be wrong.  It would be nice if all the
rules were clearly documented.

At least, if I e.g. in the testcase swap -2 with 0xULL, so that
int_const_binop_1 converts the (__uint128_t) -2 to wide_int when calling
wi::mod_trunc, then arg2 is:
$10 = { = {val = {-2, 0, 140737488343280}, len = 1, precision
= 128}, static is_sign_extended = }
Thus, IMNSHO { -2 }, 1 is (__uint128_t) -2 rather than (__uint128_t) -2ULL.

[Bug ipa/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ABI
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=65956

--- Comment #6 from Richard Biener  ---
So in

/* Implement TARGET_FUNCTION_ARG_BOUNDARY.  Every parameter gets at
   least PARM_BOUNDARY bits of alignment, but will be given anything up
   to STACK_BOUNDARY bits if the type requires it.  */

static unsigned int
mips_function_arg_boundary (machine_mode mode, const_tree type)
{
  unsigned int alignment;

  alignment = type ? TYPE_ALIGN (type) : GET_MODE_ALIGNMENT (mode);
  if (alignment < PARM_BOUNDARY)
alignment = PARM_BOUNDARY;
  if (alignment > STACK_BOUNDARY)
alignment = STACK_BOUNDARY;
  return alignment;
}

drop the TYPE_ALIGN use if mode is not BLKmode (and assert it is not VOIDmode?
I wonder what we get for integer constants here).

Similar to arm I'm curious what the ABI documentation says for

typedef int myint __attribute__((align(1)));

int foo (myint, myint);

calling convention vs. any other alignment of the args and whether it is
really intended to make those incompatible.

With C11 aligning a type is no longer a GCC extension(?), for previous
C versions either GCC shouldn't change the ABI or document the ABI
extension.

But I really doubt this is an intended behavior.

I see another use in va-arg processing (and va-args are usually the argument
why port maintainers say they need to look at the types of the actual
passed values - but I think the mode and its alignment is what matters)

  /* If the actual alignment is less than the alignment of the type,
 adjust the type accordingly so that we don't assume strict alignment
 when dereferencing the pointer.  */
  boundary *= BITS_PER_UNIT;
  if (boundary < TYPE_ALIGN (type))
{
  type = build_variant_type_copy (type);
  TYPE_ALIGN (type) = boundary;
}

Aggregates are tricky (but again, don't look at alignment of actual passed
values!  Look at most at the type alignment of the prototype arg type!
[or for values not passed by reference simply ignore it and use the alignment
of the main variant]).

[Bug lto/69394] [5.3] ICE when linking with lto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-21
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
What's the actuall ICE message?  Are you sure all object files were compiled
with exactly the same compiler?

[Bug tree-optimization/69378] [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[rguenth at gcc dot gnu.org]

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

Bug 69378 Summary: [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69378

   What|Removed |Added

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

[Bug target/65624] ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 21 09:52:46 2016
New Revision: 232668

URL: https://gcc.gnu.org/viewcvs?rev=232668=gcc=rev
Log:
PR target/69187
PR target/65624
* config/arm/arm-builtins.c (arm_expand_neon_builtin): Increase
args array size by one to avoid buffer overflow.

* gcc.target/arm/pr69187.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr69187.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69403] Wrong thumb2_ior_scc_strict_it insn pattern.

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-21
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I'll have a look

[Bug tree-optimization/67781] [5 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations

[thopre01 at gcc dot gnu.org]

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

--- Comment #15 from Thomas Preud'homme  ---
Author: thopre01
Date: Thu Jan 21 08:29:28 2016
New Revision: 232664

URL: https://gcc.gnu.org/viewcvs?rev=232664=gcc=rev
Log:
2016-01-21  Thomas Preud'homme  

Backport from mainline
2016-01-08  Thomas Preud'homme  

gcc/
PR tree-optimization/67781
* tree-ssa-math-opts.c (find_bswap_or_nop): Zero out bytes in cmpxchg
and cmpnop in two steps: first the ones not accessed in original
gimple expression in a endian independent way and then the ones not
accessed in the final result in an endian-specific way.

gcc/testsuite/
PR tree-optimization/67781
* gcc.c-torture/execute/pr67781.c: New file.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr67781.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-ssa-math-opts.c

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[vogt at linux dot vnet.ibm.com]

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

--- Comment #12 from Dominik Vogt  ---
Regarding the Glibc fix; do you mean this commit?

  2016-01-11 13:34 Adhemerval Zanella   * Fix isinf/isnan
declaration conflict with C++11

That does *not* fix the isnan and isinf errors.

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Indeed, there were tons of richi's SLP changes in the last 10 days.  Where one
of those changes make this bug latent.

[Bug testsuite/69406] FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-21
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
No, it should just be checking which headers are present, as other tests do,
like 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Give a cost model change exposed this I suspect the cost mode fix (PR68961) hid
this again.  Just debug the issue ontop of r231674 please - it is definitely
a latent issue.  Or try -fno-vect-cost-model on g++.dg/pr67211.C and trunk.

[Bug lto/69408] New: LD crashes with LTO

[night_ghost at ykoctpa dot ru]

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

Bug ID: 69408
   Summary: LD crashes with LTO
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: night_ghost at ykoctpa dot ru
  Target Milestone: ---

trying to compile Arducopter 3.2.1 for AVR I got crash:

%% ArduCopter.cpp
%% ArduCopter.elf
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core
dumped
compilation terminated.
make: *** [/tmp/ArduCopter.build/ArduCopter.elf] Ошибка 1
make: *** Удаляется файл `/tmp/ArduCopter.build/ArduCopter.elf'

but there is no .core file in popular places.

without LTO build successed

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||clm at codesourcery dot com,
   ||echristo at gcc dot gnu.org,
   ||matthew.fortune at imgtec dot 
com
  Component|ipa |target
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #7 from Richard Biener  ---
Target bug, not mine.  Might want to review the lengthy discussion about the
similar ARM issue on the mailinglist last year (Jan-Apr).

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Seems the bug is somewhere around wi::divmod_internal.

[Bug lto/69408] LD crashes with LTO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||avr
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-21
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Waiting for a testcase.  See https://gcc.gnu.org/bugs.html

[Bug c++/58046] template operator= in SFINAE class

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
This is fixed in trunk. I'm adding a testcase and closing the bug.

[Bug tree-optimization/69378] [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 21 08:50:38 2016
New Revision: 232666

URL: https://gcc.gnu.org/viewcvs?rev=232666=gcc=rev
Log:
2016-01-21  Richard Biener  

PR tree-optimization/69378
* tree-ssa-sccvn.c (dominated_by_p_w_unex): New function.
(set_ssa_val_to): Use it for dominance checks taking into
account not executable edges.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
nOn Thu, 21 Jan 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69400
> 
> --- Comment #7 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #6)
> > so in int_const_binop we end up with val = {-2 }, len = 1 (that's still
> 
> I think already this is wrong, because I think val = { -2 }, len = 1 for
> precision 128 is 0xfffeU128 rather than
> 0xfffeU128.  But I could be wrong.  It would be nice if all the
> rules were clearly documented.
> 
> At least, if I e.g. in the testcase swap -2 with 0xULL, so 
> that
> int_const_binop_1 converts the (__uint128_t) -2 to wide_int when calling
> wi::mod_trunc, then arg2 is:
> $10 = { = {val = {-2, 0, 140737488343280}, len = 1, 
> precision
> = 128}, static is_sign_extended = }
> Thus, IMNSHO { -2 }, 1 is (__uint128_t) -2 rather than (__uint128_t) -2ULL.

Ok, so things go wrong then with building the wide-int result using
the "reduced" divisor_blocks_needed.  Thus

  if (remainder)
{
  wi_pack ((unsigned HOST_WIDE_INT *) remainder, b_remainder, n);
  *remainder_len = canonize (remainder, (n + 1) / 2, dividend_prec);

should "extend" the remainder (if UNSINGED?) to the divisor len and
canonize should be fed with that instead?

Index: wide-int.cc
===
--- wide-int.cc (revision 232666)
+++ wide-int.cc (working copy)
@@ -1860,6 +1860,11 @@ wi::divmod_internal (HOST_WIDE_INT *quot
   if (remainder)
 {
   wi_pack ((unsigned HOST_WIDE_INT *) remainder, b_remainder, n);
+  if (sgn == UNSIGNED && n < divisor_blocks_needed)
+   {
+ remainder[(n + 1) / 2] = 0;
+ n++;
+   }
   *remainder_len = canonize (remainder, (n + 1) / 2, dividend_prec);
   /* The remainder is always the same sign as the dividend.  */
   if (dividend_neg)

fixes the particular testcase.  Similar adjustment needed for
the quotiend

[Bug target/69403] Wrong thumb2_ior_scc_strict_it insn pattern.

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I agree that the pattern is buggy but I can't get the bad codegen to trigger on
any of 4.9, 5 or trunk. I get a branch over lines 26 and 27:
bug:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
cmp r0, r2
push{r3, r4, r5, r6, r7, lr}
bcc .L9
mvn r0, #-2147483648
pop {r3, r4, r5, r6, r7, pc}
.L9:
mov r7, r2
mov r5, r1
mov r4, r0
bl  FT_MSB
rsb r2, r0, #31
addsr6, r0, #1
lsl r3, r4, r2
lsr r1, r5, r6
orrsr3, r3, r1
lsl r1, r5, r2
udivr0, r3, r7
mls r3, r7, r0, r3
.L4:
lsrsr2, r1, #31
lslsr0, r0, #1
orr r3, r2, r3, lsl #1
lslsr1, r1, #1
cmp r7, r3
bhi .L3
subsr3, r3, r7
orr r0, r0, #1
.L3:
subsr6, r6, #1
bne .L4
pop {r3, r4, r5, r6, r7, pc}


I'll fix the *thumb2_ior_scc_strict_it.
I believe the first alternative should just be deleted and operand 0 be made an
earlyclobber, but an executable testcase triggering this problem would be
useful for the testsuite. Are there any implicit tuning options that are used?
i.e. some particular --with-tune or --with-cpu configure option?

[Bug fortran/67068] Ambiguous interfaces generated when including open mip fortran header

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #7 from Dominique d'Humieres  ---
> IMO this PR should be closed as INVALID.

No feedback. Closing as INVALID.

[Bug ipa/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 21 Jan 2016, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
> 
> Jeffrey A. Law  changed:
> 
>What|Removed |Added
> 
>Priority|P3  |P2
>Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
> gnu.org
> 
> --- Comment #4 from Jeffrey A. Law  ---
> It's starting to look like a problem in tree-ssa-pre.c
> 
> Essentially we have these these key statements in various blocks:
> 
>   _10 = yyvsp_1->sym;
>   _15 = yyvsp_1->sym;
>   _17 = enter (_14, _15);
>   _22 = MEM[(union YYSTYPE *)yyvsp_1];
> 
> Respectively _10 and _22 have the types:
> 
> (gdb) p debug_tree (cfun->gimple_df->ssa_names.m_vecdata[10]->typed.type)
>   type  size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x703842a0
> fields  0x702ebe70>
> unsigned SI file j.c line 4 col 9 size  32> unit size 
> align 32 offset_align 64
> offset 
> bit offset  context
> > context  0x703c80f0 D.1453>
> pointer_to_this  chain  0x702ee850 D.1407>>
> sizes-gimplified public unsigned SI size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x703c6540>
> 
> 
> (gdb) p debug_tree (cfun->gimple_df->ssa_names.m_vecdata[22]->typed.type)
>   type  size 
> unit size 
> align 8 symtab 0 alias set -1 canonical type 0x703843f0 context
> 
> pointer_to_this  chain  0x702eea18 D.1410>>
> sizes-gimplified unsigned SI
> size  bitsizetype> constant 32>
> unit size  sizetype> constant 4>
> align 64 symtab 0 alias set -1 canonical type 0x70384d20>
> 
> The type of _15 is the same as the type of _10.
> 
> For reference, we're referring to instances of this structure:
> 
> union YYSTYPE
> {
>   Symbol *sym;
>   Node rec;
> };
> 
> 
> The key thing to note from the types is they have different alignments.
> 
> Anyway, PRE detects the redundant memory reference and creates:
> 
>   # prephitmp_23 = PHI 
> 
> 
> Where _23 and _26 will have the type with the 64 bit alignment.
> 
> That node feeds this statement:
> 
>   _17 = enter (_14, prephitmp_23);
> 
> Yow!  Remember that statement previously looked like:
> 
>   _17 = enter (_14, _15);
> 
> So the alignment associated with the second argument to "enter" has changed
> from 32 to 64.  That in turn may change how the argument gets passed on some
> ports (mips, epiphany, maybe others).   In this specific instance is causes 
> the
> MIPS backend to align the parameter, passing it in $6 rather than where the
> callee expects it ($5), which in turn results in gsoap being mis-compiled on
> MIPS.
> 
> Richi -- you know the PRE code better than anyone that's currently active. 
> Thoughts?

Sounds like the same mistake the ARM port had - deriving calling 
convention from type alignment of (r)_values_.  An rvalue doesn't
have alignment.

Value-numbering (and PRE) unify based on value equivalence, it
doesn't matter whether the type of the value stored in register
_23 or _15 are different, all it matters is if they are the
same, say 42 (with "alignment 8") or 42 (with "alignment 16").

Values don't have alignment.

The ports need to be fixed similar to how ARM AACPS was fixed.
See

2015-07-06  Alan Lawrence  

Backport from mainline r225465
2015-07-06  Alan Lawrence  

PR target/65956
* config/arm/arm.c (arm_needs_doubleword_align): Drop any outer
alignment attribute, exploring one level down for records and 
arrays.

[Bug c/69405] [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 21 09:52:46 2016
New Revision: 232668

URL: https://gcc.gnu.org/viewcvs?rev=232668=gcc=rev
Log:
PR target/69187
PR target/65624
* config/arm/arm-builtins.c (arm_expand_neon_builtin): Increase
args array size by one to avoid buffer overflow.

* gcc.target/arm/pr69187.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr69187.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/69408] LD crashes with LTO

[night_ghost at ykoctpa dot ru]

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

--- Comment #2 from night_ghost at ykoctpa dot ru ---
there are reqirements for reporting *language* bugs but no LTO bugs in
https://gcc.gnu.org/bugs.html

I can ZIP build tree but I saw a list of all that i can send in the "we do not
want". Crash occurs on final linking so I can't give the refined test case. But
crash always comes.

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem

[paul.richard.thomas at gmail dot com]

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

--- Comment #6 from paul.richard.thomas at gmail dot com  ---
Dear Janus,

It's good to hear from you.

As you will have seen, I have posted a fix for the first problem and
have another fix in the pipeline for the problem in comment #5.

I'll post them on the PR but cannot do any more than that until SUnday night.

Cheers

Paul

On 20 January 2016 at 22:32, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385
>
> --- Comment #5 from janus at gcc dot gnu.org ---
> In fact I have hit the same ICE with a slightly different test case:
>
>
> program test
>
>   implicit none
>
>   type :: t
> real, allocatable :: r(:)
>   end type
>
>   type(t) :: a
>
>   a%r = 0.
>
> end
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload

[vogt at linux dot vnet.ibm.com]

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

--- Comment #11 from Dominik Vogt  ---
Looks good, the errors are gone now.  Thanks!

[Bug target/63304] Aarch64 pc-relative load offset out of range

[clyon at gcc dot gnu.org]

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

--- Comment #39 from Christophe Lyon  ---
We have backported r227748, 229160 and 229161 to our linaro-gcc-5 branch, and
we got a bug report from the kernel team.

Indeed, when the kernel is configured with CONFIG_ARM64_ERRATUM_843419, the
support for relocations R_AARCH64_ADR_PREL_PG_HI21 and
R_AARCH64_ADR_PREL_PG_HI21_NC is removed from the kernel to avoid loading
objects with possibly offending sequences. In this case the kernel is built
with
-mcmodel=large.

With these backports, these relocations are generated again by default.

Adding -mpc-relative-literal-loads to the kernel Makefile in
arch/arm64/Makefile does fix the build, but since this option is not supported
by GCC if it does not contain these backports (and the compiler aborts with an
error), it's not obvious how to modify the Makefile to decide when to use this
option.

So, although Ramana said he would backport these to the FSF gcc-5 branch, maybe
it's safer not to.

Or change the default?

Or... change GCC's -mfix-cortex-a53-843419 to change the default for
-mpc-relative-literal-loads and add -mfix-cortex-a53-843419 to the kernel
Makefile.

[Bug bootstrap/69329] [6 Regression] --with-build-config=bootstrap-asan fails because LSAN_OPTIONS is not honored

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
(In reply to Mikhail Maltsev from comment #1)
> I tried this patch:
> 
> diff --git a/Makefile.in b/Makefile.in
> index 2733c4d..31ee4c0 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -789,7 +789,8 @@ BASE_FLAGS_TO_PASS = \
> $(CXX_FOR_TARGET_FLAG_TO_PASS) \
> "TFLAGS=$(TFLAGS)" \
> "CONFIG_SHELL=$(SHELL)" \
> -   "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" 
> +   "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" \
> +   "LSAN_OPTIONS=$(LSAN_OPTIONS)"
>  
>  # We leave this in just in case, but it is not needed anymore.
>  RECURSE_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS)
> diff --git a/Makefile.tpl b/Makefile.tpl
> index f7bb77e..860175e 100644
> --- a/Makefile.tpl
> +++ b/Makefile.tpl
> @@ -590,7 +590,8 @@ BASE_FLAGS_TO_PASS =[+ FOR flags_to_pass +][+ IF
> optional +] \
> $(CXX_FOR_TARGET_FLAG_TO_PASS) \
> "TFLAGS=$(TFLAGS)" \
> "CONFIG_SHELL=$(SHELL)" \
> -   "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" 
> +   "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" \
> +   "LSAN_OPTIONS=$(LSAN_OPTIONS)"
>  
>  # We leave this in just in case, but it is not needed anymore.
>  RECURSE_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS)
> 
> It fixes the issue but causes regressions for normal build (without ASAN
> instrumentation):
> 
> Running target unix/-m32
> FAIL: c-c++-common/asan/pr59063-2.c   -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/pr59063-2.c   -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  compilation failed to produce executable
> FAIL: c-c++-common/asan/pr59063-2.c   -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/pr59063-2.c   -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  compilation failed to produce executable
> 
> "compilation failed to produce executable" actually means link errors
> (-lasan not found).

That is just weird and I can't reproduce it.  That said, perhaps it would be
better to only propagate LSAN_OPTIONS down if it is set.  So replace
"LSAN_OPTIONS=$(LSAN_OPTIONS)" with
"$(if $(LSAN_OPTIONS),LSAN_OPTIONS=$(LSAN_OPTIONS))"
in both spots?

[Bug rtl-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||vmakarov at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Looks like a RA bug to me.
At least in *.ira we have above the test for the second printf:
(insn 171 170 316 24 (set (reg/v:QI 122 [ x ])
(not:QI (subreg:QI (reg:SI 201) 0))) pr69377.c:64 504 {*one_cmplqi2_1}
 (expr_list:REG_DEAD (reg:SI 201)
(nil)))
(insn 316 171 172 24 (set (reg:HI 224 [ u.3_64 ])  
(mem/c:HI (symbol_ref:SI ("u") [flags 0x2]  ) [2 u+0 S2 A16])) 88 {*movhi_internal}
 (nil))
(insn 172 316 173 24 (set (reg:CCGC 17 flags)
(compare:CCGC (reg/v:QI 156 [ x ])
(reg/v:QI 122 [ x ]))) pr69377.c:65 5 {*cmpqi_1}
 (expr_list:REG_DEAD (reg/v:QI 156 [ x ])
(nil)))
(jump_insn 173 172 174 24 (set (pc)
(if_then_else (le (reg:CCGC 17 flags)
(const_int 0 [0]))
(label_ref:SI 180)
(pc))) pr69377.c:65 633 {*jcc_1}
 (expr_list:REG_DEAD (reg:CCGC 17 flags)
(int_list:REG_BR_PROB 7100 (nil)))
 -> 180)
but *.reload turns it into:
(insn 457 170 171 26 (set (reg/v:QI 0 ax [orig:122 x ] [122])
(reg:QI 1 dx [201])) pr69377.c:64 89 {*movqi_internal}
 (nil))
(insn 171 457 458 26 (set (reg/v:QI 0 ax [orig:122 x ] [122])
(not:QI (reg/v:QI 0 ax [orig:122 x ] [122]))) pr69377.c:64 504
{*one_cmplqi2_1}
 (nil))
(insn 458 171 509 26 (set (reg/v:QI 1 dx [orig:156 x ] [156])
(reg/v:QI 0 ax [orig:122 x ] [122])) pr69377.c:64 89 {*movqi_internal}
 (nil))
(insn 509 458 316 26 (set (mem/c:QI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [5 %sfp+-24 S1 A32])   
(reg/v:QI 1 dx [orig:156 x ] [156])) pr69377.c:64 89 {*movqi_internal}
 (nil))
(insn 316 509 499 26 (set (reg:HI 0 ax [orig:224 u.3_64 ] [224])
(mem/c:HI (symbol_ref:SI ("u") [flags 0x2]  ) [2 u+0 S2 A16])) 88 {*movhi_internal}
 (nil))
(insn 499 316 172 26 (set (reg/v:QI 3 bx [orig:156 x ] [156])
(reg/v:QI 1 dx [orig:156 x ] [156])) pr69377.c:65 89 {*movqi_internal}
 (nil))
(insn 172 499 173 26 (set (reg:CCGC 17 flags)
(compare:CCGC (reg/v:QI 3 bx [orig:156 x ] [156])
(reg/v:QI 3 bx [orig:156 x ] [156]))) pr69377.c:65 5 {*cmpqi_1}
 (nil))
(jump_insn 173 172 174 26 (set (pc)
(if_then_else (le (reg:CCGC 17 flags)
(const_int 0 [0]))
(label_ref:SI 180)
(pc))) pr69377.c:65 633 {*jcc_1}
 (int_list:REG_BR_PROB 7100 (nil))
 -> 180)
Thus in the end we compare a QImode register with itself, while the source has:
c = x;
z = -y;
t1 = (j && y << c) + k || x;
x = ~(u % p);
if (x < c)
and thus we want to compare the older value of x with completely different
value.

[Bug fortran/68768] [fortran] propagate foo restrict to foo._omp_fn.0

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> Here again I don't understand your reference to -fno-cray-pointers (see
> pr68769 comment 1).

Right, as in pr68769, the reference comes from my lack of knowledge of fortran.
So please disregard this.

As I understand now, we can introduce aliases using equivalence and
pointer/target.

I didn't manage to make an example using equivalence (running into: Error:
EQUIVALENCE attribute conflicts with DUMMY attribute).

But here's an example using pointer/target:
...
subroutine subr6 (a)

  implicit none
  integer, parameter :: N = 1024
  integer :: i
  integer, target :: a(N)
  integer, pointer :: b(:)
  b => a
  i = 0

!$omp parallel do
  do i = 1, N
 a(i) = b(i) + b(i)
  end do

end subroutine

program main
  implicit none
  interface
 subroutine subr6 (a)

   implicit none
   integer, target :: a(1024)
 end subroutine subr6
  end interface
  integer, parameter :: n = 1024
  integer, dimension (0:n-1) :: a
  integer:: i

  do i = 0, n - 1
 a(i) = i * 2
  end do

  call subr6(a)

  do i = 0, n - 1
 if (a(i) .ne. i * 4) call abort
  end do

end program main
...

Interestingly, that means that a is no longer a restrict pointer:
...
subr6 (integer(kind=4)[1024] * a)
...

So AFAIU, it is indeed safe (in the description field example) to redeclare a
and b with restrict in the thread function. It is somewhat fragile though,
since it assumes a certain type of code generation in the fortran front-end.

Marking it as resolved-wontfix.

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
I think I've a fix for the first problem.  But a reduced testcase would be
really nice.

[Bug fortran/68765] warning for aliasing restrict parameters

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to vries from comment #0)
> Consider this invalid example:
> ...
> subroutine foo (a, b)
> 
>   implicit none
>   integer :: a
>   integer :: b
> 
>   a = 1
>   b = 0
>   a = a + 1
> 
> end subroutine
> 
> program main
>   implicit none
>   integer :: a
> 
>   call foo(a, a)
> 
>   if (a .ne. 1) call abort
> 
> end program main
> ...
> 
> The example is invalid because foo is called with aliasing parameters, while
> in fortran, we assume that parameters do not alias by annotating them with
> restrict, as demonstrated in the original dump:

First, there are no parameters (that would be named constants) here.
'a' in the 'main' is an actual argument.  'a' and 'b' in 'foo' are
dummy arguments.

Second, there is no assumption about aliasing.  The Fortran standard
explicitly forbids the above code, and the prohibition is on the
programmer not the Fortran processor.

Third, the Fortran standard does not have a numbered constraint
for this invalid code, which means that a Fortran processor is not
required to detect and report this invalid code.  Indeed, with this
code

   program aaa
 real a(2)
 call foo(a,a)
   end program aaa

and no other information, what should a Fortran processor do?

[Bug rtl-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Adjusted testcase for the testsuite, without relying on stdout output:

int r, *s, t, p, a, q, b;
short u = 3;
static int *v;
char c;
int cc;

__attribute__((noinline, noclone)) void
baz (const char *p, int q)
{
  asm volatile ("" : : "r" (p) : "memory");
  if (q != 1 + (cc++ == 0))
__builtin_abort ();
  if (*p != cc)
__builtin_abort ();
}

static int *
foo (int p1)
{
  int w = 2, j;
  while (q < 1)
{
  int d = 6094 ^ p, e = ~r;
  p = e;
  if (!d)
return 
  for (j = 0; j < 1;)
{
  for (j = 0; j < 1; j++)
for (; q < 2; q++)
  ;
}
}
  if (u)
for (;;)
  {
char x;
int y, z = 1, t1;
for (x = 7; x; x++)
  {
int f = p || r;
t1 = ~p | w;
w = (u || f % a) % ~(t1 && f) - r;
if (p < 6)
  {
baz ("\1", t1);
break;
  }
  }
int g = 4 % w;
if (g)
  {
--p;
int h = p && t1;
z = h;
if (p > 5 && z)
  continue;
  }
y = g;
if (z < p)
  {
int i = g / u;
y = i;
  }
int j = u & y, k, o = z * x;
if (p)
  {
k = z;
o = t1;
c = x;
z = -y;
t1 = (j && y << c) + k || x;
x = ~(u % p);
if (x < c)
  baz ("\2", t1);
  }
int l = p < z;
short m = ((l && y) & ~u) * t1;
int n = u && t1;
if (t1 && x && (!x || z))
  m = l * (y && n) | x;
baz ("\3", t1);
if (o && m > w)
  *v = 0;
else
  {
if (!p1)
  continue;
return 
  }
  }
}

static void
bar (char p1)
{
  s = foo (254);
  while (p1 <= 0)
{
  s = foo (254);
  for (;;)
;
}
}

int
main ()
{
  bar (4);
  if (cc != 3)
__builtin_abort ();
  return 0;
}

[Bug rtl-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Note that this and the original testcase trigger
p.c: In function ‘foo’:
p.c:92:1: warning: control reaches end of non-void function
so I remember adding "return " at the end of foo (it still triggers the
bug).

[Bug tree-optimization/69399] [5/6 Regression] wrong code with -O and int128

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||mrs at gcc dot gnu.org
Summary|[5/6 Regression] wrong code |[5/6 Regression] wrong code
   |with -O and int128 (due to  |with -O and int128
   |ccp?)   |

--- Comment #3 from H.J. Lu  ---
It is caused by r210113.  Stage 3 compiler is miscompiled by stag 2 compiler.

[Bug preprocessor/55115] [4.9/5/6 Regression] missing headers as fatal breaks cproto logic

[Robert.Gomes at igt dot com]

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

--- Comment #18 from RGomes  ---
The cproto design and usage is not broken. Everyone here agrees that a missing
include during "compilation" rightfully should generate an error. It is the
"preprocessor behavior only" where we are asking for tolerance for a missing
include. Why? Because a .h file that contains only function prototypes is being
generated ahead of the compilation (cproto is doing this step, using the gcc
preprocessor) - then later, that generated .h file "will" be present during
compilation. This is just one use case - there are others - so the request
being made is only for the preprocessor eliminating this error - not
compilation. (Followup to my earlier post - my present workaround was
reluctantly installing 2 gcc compilers: a 4.4 compatible one invoked for
prototyping only, and the latest gcc for compilation).