[Bug c++/84525] GCC7: generate movaps instruction when assign to unaligned __int128*

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
That testcase is invalid C, -fsanitize=undefined would even tell you.
__int128 requires 16-byte alignment and you're violating that.
You can use __int128 temp; memcpy (, abc, sizeof (temp)); ... use temp ...
or __int128 in a __attribute__((packed)) structure etc. to read unaligned
objects.

[Bug c++/84525] New: GCC7: generate movaps instruction when assign to unaligned __int128*

[buaa.zhaoc at gmail dot com]

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

Bug ID: 84525
   Summary: GCC7: generate movaps instruction when assign to
unaligned __int128*
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: buaa.zhaoc at gmail dot com
  Target Milestone: ---

compiling the following code. Run the binary will cause a segment fault. GCC
version is 7.3, Target: x86_64-pc-linux-gnu, Configure is
../gcc-7.3.0/configure CFLAGS=-O2 LDFLAGS=-static --enable-gold=yes
--enable-languages=c,c++ --enable-c99 --enable-threads=posix
--enable-__cxa_atexit --disable-multilib --disable-bootstrap

g++ -O3 a.cc b.cc

a.cc 
#include 

extern void set_to_max(char* abc);

int main() {
char* abc = new char[100];
set_to_max(abc + 1);
std::cout << (int64_t)(((*(__int128*)(abc+1))) >> 64) << std::endl;
delete[] abc;
return 0;
}

b.cc
void set_to_max(char* abc) {
*reinterpret_cast<__int128*>(abc) = ~((__int128)1 << 127);
}

when I execute following command
g++ -O3 -S b.cc

following asm code generated: 

.file   "b.cc"
.text
.p2align 4,,15
.globl  _Z10set_to_maxPc
.type   _Z10set_to_maxPc, @function
_Z10set_to_maxPc:
.LFB0:
.cfi_startproc
movdqa  .LC0(%rip), %xmm0
movaps  %xmm0, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   _Z10set_to_maxPc, .-_Z10set_to_maxPc
.section.rodata.cst16,"aM",@progbits,16
.align 16
.LC0:
.quad   -1
.quad   9223372036854775807
.ident  "GCC: (GNU) 7.3.0"
.section.note.GNU-stack,"",@progbits

movaps instruction cause the Segmentation fault

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[wilco at gcc dot gnu.org]

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

--- Comment #12 from Wilco  ---
Note PR64242 is related (also frame pointer corruption by __builtin_longjmp).

[Bug target/84522] GCC does not generate cmpxchg16b when mcx16 is used

[nruslan_devel at yahoo dot com]

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

--- Comment #5 from Ruslan Nikolaev  ---
After more t(In reply to Andrew Pinski from comment #1)
> IIRC this was done because there is no atomic load/stores or a way to do
> backwards compatible.

After more thinking about it... Should not it be controlled by some flag
(similar to -mcx16 which enables cmpxchg16b)? This flag can basically say, that
atomic_load on 128-bit will not work on read-only memory. I think, it is better
than just unconditionally disabling lock-free implementation for 128-bit types
in C11 (which can is useful in a number of cases) just to accommodate some rare
cases when memory accesses must be read-only. That would also be more portable
and compatible with other compilers such as clang.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[wilco at gcc dot gnu.org]

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

--- Comment #11 from Wilco  ---
(In reply to Ramana Radhakrishnan from comment #10)
> (In reply to Jakub Jelinek from comment #4)
> > Is the requirement just for functions that contain setjmp?  If so, the
> > backend could just force frame pointers in cfun->calls_setjmp functions.
> 
> I think we should flip back fno-omit-frame-pointer on for gcc-8 as that
> breaks the guarantee that we've had in the port for quite a while. I'm
> testing a patch currently that I will get out first thing tomorrow to turn
> this back on.
> 
> If we want to turn it off that should be a conscious decision.
> 
> 
> > 
> > If not, even if the default is tweaked again to be -fno-omit-frame-pointer
> > on aarch64, the code is still wrong with explicit -fno-omit-frame-pointer,
> > even before that change.
> 
> I think we should treat that as a separate but related issue.
> 
> 
> Ramana

The code is clearly incorrect even with the frame pointer is enabled, so this
has absolutely nothing to do with the frame pointer default. Like the eh_return
builtin, the implementation of these builtins is incorrect with or without a
frame pointer (and apparently has always been).

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[ramana at gcc dot gnu.org]

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

--- Comment #10 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #4)
> Is the requirement just for functions that contain setjmp?  If so, the
> backend could just force frame pointers in cfun->calls_setjmp functions.

I think we should flip back fno-omit-frame-pointer on for gcc-8 as that breaks
the guarantee that we've had in the port for quite a while. I'm testing a patch
currently that I will get out first thing tomorrow to turn this back on.

If we want to turn it off that should be a conscious decision.


> 
> If not, even if the default is tweaked again to be -fno-omit-frame-pointer
> on aarch64, the code is still wrong with explicit -fno-omit-frame-pointer,
> even before that change.

I think we should treat that as a separate but related issue.


Ramana

[Bug c/84524] New: -O3 causes behavior change

[caleb.fujimori at gmail dot com]

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

Bug ID: 84524
   Summary: -O3 causes behavior change
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: caleb.fujimori at gmail dot com
  Target Milestone: ---

Created attachment 43491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43491=edit
Preprocessed source

Compiling with -march=native -O3 causes an array initialization loop to fill
all elements with 61215. Disabling AVX512 with -mno-avx512f or -mno-avx512bw
creates the expected behavior.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --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-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c99'
'-march=native' '-O3' '-o' 'avx512bug'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
avx512bug.c -march=knl -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a
-mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma
-mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt
-mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave
-mxsaveopt -mavx512f -mno-avx512er -mavx512cd -mno-avx512pf -mno-prefetchwt1
-mclflushopt -mxsavec -mxsaves -mavx512dq -mavx512bw -mno-avx512vl
-mno-avx512ifma -mno-avx512vbmi -mclwb -mno-pcommit -mno-mwaitx --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=14080
-mtune=generic -std=c99 -Wall -Wextra -O3 -fpch-preprocess
-fstack-protector-strong -Wformat-security -o avx512bug.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c99'
'-march=native' '-O3' '-o' 'avx512bug'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -fpreprocessed avx512bug.i -march=knl
-mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe
-maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi
-mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd
-mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mavx512f
-mno-avx512er -mavx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec
-mxsaves -mavx512dq -mavx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi
-mclwb -mno-pcommit -mno-mwaitx --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=14080 -mtune=generic -quiet
-dumpbase avx512bug.c -auxbase avx512bug -O3 -Wall -Wextra -std=c99 -version
-fstack-protector-strong -Wformat-security -o avx512bug.s
GNU C99 (Ubuntu 5.4.0-6ubuntu1~16.04.9) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C99 (Ubuntu 5.4.0-6ubuntu1~16.04.9) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d079eab342c322d6be59e8628e10ae67
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' 

[Bug c++/70468] [6/7/8 Regression] ICE on invalid code on x86_64-linux-gnu in emit_mem_initializers, at cp/init.c:1109

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/84424] [8 Regression] ICE on C++ code: tree check: expected record_type or union_type or qual_union_type, have vector_type in reduced_constant_expression_p, at cp/constexpr.c:1766

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/84424] [8 Regression] ICE on C++ code: tree check: expected record_type or union_type or qual_union_type, have vector_type in reduced_constant_expression_p, at cp/constexpr.c:1766

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Feb 22 22:50:37 2018
New Revision: 257924

URL: https://gcc.gnu.org/viewcvs?rev=257924=gcc=rev
Log:
PR c++/84424 - ICE with constexpr and __builtin_shuffle.

* constexpr.c (reduced_constant_expression_p): Handle CONSTRUCTOR of
VECTOR_TYPE.

Added:
trunk/gcc/testsuite/g++.dg/ext/vector34.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[wilco at gcc dot gnu.org]

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

--- Comment #9 from Wilco  ---
(In reply to Jakub Jelinek from comment #7)
> cfun->has_nonlocal_label instead of cfun->calls_setjmp would cover
> __builtin_setjmp.

Do non-local labels do the same odd thing? It seems to me if the mid-end
automatically inserts explicit writes to the frame pointer, it should also set
frame_pointer_needed. This may be a bug on other targets too.

Also a much better implementation would use a small landing pad in the function
that does the __builtin_setjmp (rather than inline it a different function), so
you avoid the frame pointer corruption. Eg.

baz:
...
ldr x1, [x0, 8]
br  x1

L7_nonlocal: (landing pad in foo)
ldr x29, [x0, 16]
ldr sp,  [x0]
b   .L7

Or maybe we should get rid of these horrible hacks altogether?

[Bug c++/84424] [8 Regression] ICE on C++ code: tree check: expected record_type or union_type or qual_union_type, have vector_type in reduced_constant_expression_p, at cp/constexpr.c:1766

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/84346] Statement functions should not accept keywords

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
I have a patch.

[Bug fortran/59781] [6 Regression] [F03] Incorrect initialisation of derived type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #19 from Thomas Koenig  ---
Test case committed, closing.

[Bug fortran/59781] [6 Regression] [F03] Incorrect initialisation of derived type

[tkoenig at gcc dot gnu.org]

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

--- Comment #18 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Feb 22 22:01:53 2018
New Revision: 257917

URL: https://gcc.gnu.org/viewcvs?rev=257917=gcc=rev
Log:
2018-02-22  Thomas Koenig  

PR fortran/59781
* gfortran.dg/derived_init_5.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/derived_init_5.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[carll at gcc dot gnu.org]

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

--- Comment #10 from Carl Love  ---
These builtins were per a request from Steve Monroe.  Not sure why he wanted
them or if he actually ever used them.

[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

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

[Bug fortran/84523] New: [8 Regression] Runtime crash deallocating allocatable array within derived type

[anlauf at gmx dot de]

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

Bug ID: 84523
   Summary: [8 Regression] Runtime crash deallocating allocatable
array within derived type
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gmx dot de
  Target Milestone: ---

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

The attached code crashes when checking allocatable components within
a derived type:

 ### destruct: size(rc% spots)=  80
 ### destruct: allocated (vm) = F

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xe3ff in ???
#1  0x8048a5e in destruct
at /work/DWD/git/dace_code/gfcbug148.f90:33
#2  0x8048be8 in gfcbug148
at /work/DWD/git/dace_code/gfcbug148.f90:12
#3  0x8049088 in main
at /work/DWD/git/dace_code/gfcbug148.f90:13


The program runs without problems with any version 4.8 through 7.2:

 ### destruct: size(rc% spots)=  80
 ### destruct: allocated (vm) = F
 OK

[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 22 21:27:44 2018
New Revision: 257916

URL: https://gcc.gnu.org/viewcvs?rev=257916=gcc=rev
Log:
PR target/82851
* gcc.target/i386/avx2-vpaddq-3.c: Add -mtune=generic to dg-options.
* gcc.target/i386/avx2-vpsubq-3.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx2-vpaddq-3.c
trunk/gcc/testsuite/gcc.target/i386/avx2-vpsubq-3.c

[Bug c++/84516] bitfield temporaries > 32-bits have wrong type

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
See also bug 70733, another bug with these types being user-exposed for 
bit-fields for C++.  For C++ (unlike C), the existence of these types 
internally in the compiler should never be user-visible, because bit-field 
width is explicitly not part of the type for C++.

[Bug c++/84518] [8 Regression] ICE with lambda capturing broken variable

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-22
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Thanks for filing this report.

Confirmed.  Both ICEs started with r253265.

The first ICE (testcase in comment #0) happens at line 446 of lambda.c in
build_capture_proxy here:

441   if (DECL_NORMAL_CAPTURE_P (member))
442 {
443   if (DECL_VLA_CAPTURE_P (member))
444 {
445   init = CONSTRUCTOR_ELT (init, 0)->value;
446   init = TREE_OPERAND (init, 0); // Strip ADDR_EXPR.
447   init = TREE_OPERAND (init, 0); // Strip ARRAY_REF.
448 }

where "init" is error_mark.


The second ICE (testcase in comment #1):

Happens at line 288 of lambda.c in is_normal_capture_proxy here:
288   gcc_assert (TREE_CODE (val) == COMPONENT_REF);

where val is a NOP_EXPR around a COMPONENT_REF (casting from T* to reference to
T[]).

[Bug target/81572] [7/8 Regression] gcc-7 regression: unnecessary vector regmove on compare

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Feb 22 21:17:51 2018
New Revision: 257915

URL: https://gcc.gnu.org/viewcvs?rev=257915=gcc=rev
Log:
2018-02-22  Vladimir Makarov  

PR target/81572
* lra-int.h (LRA_UNKNOWN_ALT, LRA_NON_CLOBBERED_ALT): New macros.
* lra.c (lra_set_insn_recog_data, lra_update_insn_recog_data): Use
LRA_UNKNOWN_ALT.
* lra-constraints.c (curr_insn_transform): Set up
LRA_NON_CLOBBERED_ALT for moves processed on the fast path.  Use
LRA_UNKNOWN_ALT.
(remove_inheritance_pseudos): Use LRA_UNKNOWN_ALT.
* lra-eliminations.c (spill_pseudos): Ditto.
(process_insn_for_elimination): Ditto.
* lra-lives.c (reg_early_clobber_p): Use the new macros.
* lra-spills.c (spill_pseudos): Use LRA_UNKNOWN_ALT and
LRA_NON_CLOBBERED_ALT.

2018-02-22  Vladimir Makarov  

PR target/81572
* gcc.target/powerpc/pr81572.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr81572.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/lra-eliminations.c
trunk/gcc/lra-int.h
trunk/gcc/lra-lives.c
trunk/gcc/lra-spills.c
trunk/gcc/lra.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84522] GCC does not generate cmpxchg16b when mcx16 is used

[nruslan_devel at yahoo dot com]

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

--- Comment #4 from Ruslan Nikolaev  ---
I guess, in this case you would have to fall-back to lock-based implementation
for everything. But does C11 even require that atomic_load work on read-only
memory?

[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

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

[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
The problem seems to be that gfc_conv_initalizer does not look
through

(gdb) p *expr
$1 = {expr_type = EXPR_STRUCTURE, ts = {type = BT_DERIVED, kind = 0,

to

(gdb) p *(expr->ts.u.derived->components->ts->u.derived)


$22 = {name = 0x77487080 "c_ptr", module = 0x77483410
"__iso_c_binding", declared_at = {nextc = 0x25672b8, lb = 0x2567280}, ts = {
type = BT_INTEGER, kind = 8, u = {derived = 0x256fc00, cl = 0x256fc00, pad
= 39255040}, interface = 0x0, is_c_interop = 1, is_iso_c = 1

It is, of course, open if it should need to... without adding the
vtab, gfc_conv_initializer does not even appear to be called.

[Bug target/84522] GCC does not generate cmpxchg16b when mcx16 is used

[nruslan_devel at yahoo dot com]

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

--- Comment #3 from Ruslan Nikolaev  ---
(In reply to Ruslan Nikolaev from comment #2)
> Yes, but not having atomic_load is far less an issue. Oftentimes, algorithms
> that use 128-bit can simply use compare_and_exchange only (at least for
> x86-64).

In other words, can atomic_load be redirected to libatomic while
compare_exchange still be generated directly (if -mcx16 is specified)?

[Bug target/84522] GCC does not generate cmpxchg16b when mcx16 is used

[nruslan_devel at yahoo dot com]

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

--- Comment #2 from Ruslan Nikolaev  ---
Yes, but not having atomic_load is far less an issue. Oftentimes, algorithms
that use 128-bit can simply use compare_and_exchange only (at least for
x86-64).

[Bug target/84522] GCC does not generate cmpxchg16b when mcx16 is used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
IIRC this was done because there is no atomic load/stores or a way to do
backwards compatible.

[Bug c/84522] New: GCC does not generate cmpxchg16b when mcx16 is used

[nruslan_devel at yahoo dot com]

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

Bug ID: 84522
   Summary: GCC does not generate cmpxchg16b when mcx16 is used
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

I looked up similar bugs, but I could not quite understand why it redirects to
libatomic when used with 128-bit cmpxchg in x86-64 even when '-mcx16' flag is
specified. Especially because similar cmpxchg8b for x86 (32-bit) is still used
without redirecting to libatomic.

80878 mentioned something about read-only memory, but that should only apply to
atomic_load, not atomic_compare_and_exchange. Right?

It is especially annoying because libatomic will not guarantee lock-freedom,
therefore, these functions become useless in many cases.
This compiler behavior is inconsistent with clang.

For instance, for the following code:

#include 

__uint128_t cmpxhg_weak(_Atomic(__uint128_t) * obj, __uint128_t * expected,
__uint128_t desired)
{
return atomic_compare_exchange_weak(obj, expected, desired);
}

GCC generates:

(gcc -std=c11 -mcx16 -Wall -O2 -S test.c)

cmpxhg_weak:
subq$8, %rsp
movl$5, %r9d
movl$5, %r8d
call__atomic_compare_exchange_16@PLT
xorl%edx, %edx
movzbl  %al, %eax
addq$8, %rsp
ret

While clang/llvm generates the code which is obviously lock-free:
cmpxhg_weak:# @cmpxhg_weak
pushq   %rbx
movq%rdx, %r8
movq(%rsi), %rax
movq8(%rsi), %rdx
xorl%r9d, %r9d
movq%r8, %rbx
lockcmpxchg16b  (%rdi)
sete%cl
je  .LBB0_2
movq%rax, (%rsi)
movq%rdx, 8(%rsi)
.LBB0_2:
movb%cl, %r9b
xorl%edx, %edx
movq%r9, %rax
popq%rbx
retq

However, for 32-bit GCC still generates cmpxchg8b:

#include 
#include 

uint64_t cmpxhg_weak(_Atomic(uint64_t) * obj, uint64_t * expected, uint64_t
desired)
{
return atomic_compare_exchange_weak(obj, expected, desired);
}

gcc -std=c11 -m32 -Wall -O2 -S test.c


cmpxhg_weak:
pushl   %edi
pushl   %esi
pushl   %ebx
movl20(%esp), %esi
movl24(%esp), %ebx
movl28(%esp), %ecx
movl16(%esp), %edi
movl(%esi), %eax
movl4(%esi), %edx
lock cmpxchg8b  (%edi)
movl%edx, %ecx
movl%eax, %edx
sete%al
je  .L2
movl%edx, (%esi)
movl%ecx, 4(%esi)
.L2:
popl%ebx
movzbl  %al, %eax
xorl%edx, %edx
popl%esi
popl%edi
ret

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[wilco at gcc dot gnu.org]

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

--- Comment #8 from Wilco  ---
(In reply to Jakub Jelinek from comment #7)
> cfun->has_nonlocal_label instead of cfun->calls_setjmp would cover
> __builtin_setjmp.
> 
> aarch64_frame_pointer_required would force frame_pointer_needed and thus be
> true in that case too.  But sure, if it works, we can change:
>/* Force a frame chain for EH returns so the return address is at FP+8. 
> */
>cfun->machine->frame.emit_frame_chain
> -= frame_pointer_needed || crtl->calls_eh_return;
> += frame_pointer_needed || crtl->calls_eh_return ||
> cfun->has_nonlocal_label;

Note I'm not convinced this is sufficient. I tried compiling
testsuite/gcc.c-torture/execute/pr60003.c and it appears to mess up the frame
pointer so it no longer points to a frame chain:

baz:
adrpx1, .LANCHOR0
add x0, x1, :lo12:.LANCHOR0
stp x29, x30, [sp, -16]!
mov x29, sp
ldr x2, [x0, 8]
ldr x29, [x1, #:lo12:.LANCHOR0]  // load of bad frame pointer
ldr x0, [x0, 16]
mov sp, x0
br  x2

foo:
stp x29, x30, [sp, -176]!
adrpx2, .LANCHOR0
add x1, x2, :lo12:.LANCHOR0
mov x29, sp
add x3, sp, 176  // store of bad frame pointer
str x3, [x2, #:lo12:.LANCHOR0]
stp x19, x20, [sp, 16]
stp x21, x22, [sp, 32]
stp x23, x24, [sp, 48]
stp x25, x26, [sp, 64]
stp x27, x28, [sp, 80]
stp d8, d9, [sp, 96]
stp d10, d11, [sp, 112]
stp d12, d13, [sp, 128]
stp d14, d15, [sp, 144]
str w0, [sp, 172]
adrpx0, .L7
add x0, x0, :lo12:.L7
str x0, [x1, 8]
mov x0, sp
str x0, [x1, 16]
bl  baz
.p2align 2
.L7:
ldr w0, [sp, 172]
ldp x19, x20, [sp, 16]
ldp x21, x22, [sp, 32]
ldp x23, x24, [sp, 48]
ldp x25, x26, [sp, 64]
ldp x27, x28, [sp, 80]
ldp d8, d9, [sp, 96]
ldp d10, d11, [sp, 112]
ldp d12, d13, [sp, 128]
ldp d14, d15, [sp, 144]
ldp x29, x30, [sp], 176
ret

What should happen is that it stores the actual sp/fp just before calling baz,
and baz then restores those before jumping to L7.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
cfun->has_nonlocal_label instead of cfun->calls_setjmp would cover
__builtin_setjmp.

aarch64_frame_pointer_required would force frame_pointer_needed and thus be
true in that case too.  But sure, if it works, we can change:
   /* Force a frame chain for EH returns so the return address is at FP+8.  */
   cfun->machine->frame.emit_frame_chain
-= frame_pointer_needed || crtl->calls_eh_return;
+= frame_pointer_needed || crtl->calls_eh_return ||
cfun->has_nonlocal_label;

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[wilco at gcc dot gnu.org]

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

--- Comment #6 from Wilco  ---
(In reply to Jakub Jelinek from comment #5)

> (completely untested) would require frame pointers for all setjmp calls, not
> just __builtin_setjmp.

That's the correct approach indeed, however aarch64_frame_pointer_required is
no longer used, this now needs to added to aarch64_layout_frame:

  /* Force a frame chain for EH returns so the return address is at FP+8.  */
  cfun->machine->frame.emit_frame_chain
= frame_pointer_needed || crtl->calls_eh_return;

> BTW, does __builtin_return_address really work on aarch64 without frame
> pointers?  Various other targets require frame pointers when
> cfun->machine->access_prev_frame (i.e. when SETUP_FRAME_ADDRESSES () has
> been used).

It only supports returning the return address of the current function (and even
that is most likely a bug rather than useful). When level != 0 it always
returns 0.

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[carll at gcc dot gnu.org]

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

--- Comment #9 from Carl Love  ---
This test case is in the list in PR 84422 .  Working on a patch.

[Bug go/84484] libgo configure tests fail to find -latomic

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #18 from Ian Lance Taylor  ---
Thanks for the patch.  I committed it.

[Bug go/84484] libgo configure tests fail to find -latomic

[ian at gcc dot gnu.org]

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

--- Comment #17 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Feb 22 19:49:04 2018
New Revision: 257914

URL: https://gcc.gnu.org/viewcvs?rev=257914=gcc=rev
Log:
PR go/84484
libgo: add support for riscv64

Patch by Andreas Schwab.

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

* go.test/go-test.exp (go-set-goarch): Recognize riscv64-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/go.test/go-test.exp
trunk/libgo/configure
trunk/libgo/configure.ac
trunk/libgo/go/cmd/cgo/main.go
trunk/libgo/go/go/build/syslist.go
trunk/libgo/go/internal/syscall/unix/getrandom_linux_generic.go
trunk/libgo/go/runtime/hash64.go
trunk/libgo/go/runtime/lfstack_64bit.go
trunk/libgo/go/runtime/unaligned1.go
trunk/libgo/go/syscall/endian_little.go
trunk/libgo/go/syscall/libcall_linux_ustat.go
trunk/libgo/goarch.sh
trunk/libgo/match.sh
trunk/libgo/misc/cgo/testcshared/src/libgo2/dup2.go
trunk/libgo/misc/cgo/testcshared/src/libgo2/dup3.go
trunk/libgo/testsuite/gotest

[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

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

--- Comment #7 from Steve Ellcey  ---
This should be fixed now.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #5 from Jakub Jelinek  ---
--- gcc/config/aarch64/aarch64.c.jj 2018-02-22 09:26:12.028616476 +0100
+++ gcc/config/aarch64/aarch64.c2018-02-22 20:23:29.449621557 +0100
@@ -7432,6 +7432,20 @@ aarch64_secondary_reload (bool in_p ATTR
   return NO_REGS;
 }

+/* Value should be nonzero if functions must have frame pointers.
+   Zero means the frame pointer need not be set up (and parms may
+   be accessed via the stack pointer) in functions that seem suitable.  */
+
+static bool
+aarch64_frame_pointer_required (void)
+{
+  /* __builtin_setjmp requries frame pointers.  */
+  if (cfun->calls_setjmp)
+return true;
+
+  return false;
+}
+
 static bool
 aarch64_can_eliminate (const int from ATTRIBUTE_UNUSED, const int to)
 {
@@ -17463,6 +17477,9 @@ aarch64_run_selftests (void)
 #undef TARGET_CALLEE_COPIES
 #define TARGET_CALLEE_COPIES hook_bool_CUMULATIVE_ARGS_mode_tree_bool_false

+#undef TARGET_FRAME_POINTER_REQUIRED
+#define TARGET_FRAME_POINTER_REQUIRED aarch64_frame_pointer_required
+
 #undef TARGET_CAN_ELIMINATE
 #define TARGET_CAN_ELIMINATE aarch64_can_eliminate


(completely untested) would require frame pointers for all setjmp calls, not
just __builtin_setjmp.

I agree pretty much all uses of __builtin_setjmp are a bug, but somebody needs
to explain it to the ruby authors.  It is even weirder because they are using
the builtin with jmp_buf variable, jmp_buf is for the libc setjmp, for
__builtin_setjmp I think it is just void *buf[5]; or something similar.

BTW, does __builtin_return_address really work on aarch64 without frame
pointers?  Various other targets require frame pointers when
cfun->machine->access_prev_frame (i.e. when SETUP_FRAME_ADDRESSES () has been
used).

[Bug tree-optimization/84515] missed optimization: expected loop merging

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
count==1 might be the difficult case, since it's the only situation in which
the second loop does something but the first loop doesn't.  But the code for:

void f2(unsigned count) {
unsigned i;
if (count <= 1) {
  g += count;
} else {
  for (i = 0; i < count/2; i++) g++;
  for ( ; i < count  ; i++) g++;
}
}

is also poor.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Is the requirement just for functions that contain setjmp?  If so, the backend
could just force frame pointers in cfun->calls_setjmp functions.

If not, even if the default is tweaked again to be -fno-omit-frame-pointer on
aarch64, the code is still wrong with explicit -fno-omit-frame-pointer, even
before that change.

The test uses __builtin_setjmp, can't reproduce it when using normal setjmp,
so is it just __builtin_setjmp that requires frame pointers?  I think we don't
really have a flag about uses of __builtin_setjmp right now, but it could be
added next to calls_setjmp (calls_builtin_setjmp).  Marking the function with
__builtin_setjmp with __attribute__((optimize ("no-omit-frame-pointer"))) fixes
it too.

[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

[Bug middle-end/21161] [6/7/8 Regression] "clobbered by longjmp" warning ignores the data flow

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #12 from Jeffrey A. Law  ---
I've got something that is working on most targets.  I'm still refining a bit,
but I'm pretty confident we'll be able to fix in this cycle.

As expected scanning RTL from the setjmp point to figure out where the longjmp
will go (so that we can use the live-in set at the longjmp target rather than
the live set at the setjmp point) is a bit hairy.

It's almost certainly the case that the scanning is not going to work on all
targets.  For example MIPS inserts an unspec sequence to fiddle the GOT after
the call and I really don't want to ignore an insn we don't understand.  But
again, what I've currently got works on most targets and there's still some
refinements to do to improve coverage.

[Bug fortran/84511] [6/7/8 Regression] Internal compiler error from directly printing return of C_LOC

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
I have a patch.

[Bug fortran/84519] STOP and ERROR STOP statements with QUIET specifier

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #1 from Janne Blomqvist  ---
Working on a patch, assigning to myself.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
To me any use of __builtin_setjmp/__builtin_longjmp is almost always incorrect.

[Bug c++/70468] [6/7/8 Regression] ICE on invalid code on x86_64-linux-gnu in emit_mem_initializers, at cp/init.c:1109

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
It is the expand_member_init's current_template_parms check that matters here,
with
-  if (current_template_parms
- || same_type_p (basetype, current_class_type))
- return basetype;
+  if (/* current_template_parms
+ || */same_type_p (basetype, current_class_type))
+   return basetype;
both testcases from this PR are properly rejected and no ICEs.
That breaks other stuff though, like:
/usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:134:9:
error: type '__gnu_cxx::new_allocator<_Tp>' is not a direct base of
'std::allocator<  >'
/usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:146:4:
error: type 'typename __gnu_cxx::__alloc_traits<_Alloc>::rebind<_CharT>::other'
is not a direct base of 'std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_Alloc_hider'
/usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:149:4:
error: type 'typename __gnu_cxx::__alloc_traits<_Alloc>::rebind<_CharT>::other'
is not a direct base of 'std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_Alloc_hider'

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1

[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Thomas Koenig  ---
Backported the patch due to overwhelming popular demand :-)

This really is a duplicate, closing the patch as such.

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

[Bug fortran/81116] Last character of allocatable-length string reset to blank in an assigment

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||david.sagan at gmail dot com

--- Comment #7 from Thomas Koenig  ---
*** Bug 84495 has been marked as a duplicate of this bug. ***

[Bug fortran/81116] Last character of allocatable-length string reset to blank in an assigment

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Feb 22 18:52:21 2018
New Revision: 257912

URL: https://gcc.gnu.org/viewcvs?rev=257912=gcc=rev
Log:
2018-02-22  Thomas Koenig  

PR fortran/81116
PR fortran/84495
Backport from trunk
* frontend-passes.c (realloc_string_callback): If expression is a
concatenation, also check for dependency.
(constant_string_length): Check for presence of symtree.

2018-02-22  Thomas Koenig  

PR fortran/81116
PR fortran/84495
* gfortran.dg/realloc_on_assignment_29.f90:  New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_29.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/frontend-passes.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Feb 22 18:52:21 2018
New Revision: 257912

URL: https://gcc.gnu.org/viewcvs?rev=257912=gcc=rev
Log:
2018-02-22  Thomas Koenig  

PR fortran/81116
PR fortran/84495
Backport from trunk
* frontend-passes.c (realloc_string_callback): If expression is a
concatenation, also check for dependency.
(constant_string_length): Check for presence of symtree.

2018-02-22  Thomas Koenig  

PR fortran/81116
PR fortran/84495
* gfortran.dg/realloc_on_assignment_29.f90:  New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_29.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/frontend-passes.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-22
 CC||ramana.radhakrishnan at arm 
dot co
   ||m
 Ever confirmed|0   |1

--- Comment #2 from James Greenhalgh  ---
It is a bug that we have changed to -fomit-frame-pointer by default for
AArch64. That changes a long standing ABI decision made at the dawn of the
port, and promised as a feature of the architecture. I would like to see this
fixed for GCC 8.

Ramana was testing a patch to fix this and change us back to
-fno-omit-frame-pointer, it (or someone else's patch achieving the same) would
be appreciated as the immediate fix for this issue.

I haven't validated the longer-term problem you mention with
-fomit-frame-pointer.

Ramana, can you pick this up and set us back to the appropriate default?
Otherwise, I can spin a patch. We should fix this urgently, or we miss the good
value that comes from whole-distribution testing.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Created attachment 43489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43489=edit
Reproducer

When compiled with:
  gcc -DDUMP -g -O0 -fstack-protector-strong -Wall test.c
this runs to completion, and the x29 values show the function calls/returns:
x29 = 0x7ff2977910 : main : start of main
x29 = 0x7ff29778d0 : test_2 : start of test_2
x29 = 0x7ff29776a0 : test_1 : start of test_1
x29 = 0x7ff29776a0 : test_1 : zero return
x29 = 0x7ff2977690 : uses_longjmp : in uses_longjmp
x29 = 0x7ff2977740 : test_1 : non-zero return
x29 = 0x7ff2977690 : after_longjmp : after raise
x29 = 0x7ff2977740 : test_1 : end of test_1
x29 = 0x7ff29778d0 : test_2 : end of test_2
x29 = 0x7ff2977910 : main : end of main

On adding -fomit-frame-pointer, it crashes, and the x29 values show a
corruption after "uses_longjmp" which becomes a crash when the x29 value is
later used:

x29 = 0x7fff4709c0 : main : start of main
x29 = 0x7fff470960 : test_2 : start of test_2
x29 = 0x7fff470960 : test_1 : start of test_1
x29 = 0x7fff470960 : test_1 : zero return
x29 = 0x7fff470720 : uses_longjmp : in uses_longjmp
x29 = 0x7fff4707d0 : test_1 : non-zero return
x29 = 0x7fff4707d0 : after_longjmp : after raise
x29 = 0x7fff4707d0 : test_1 : end of test_1
x29 = 0x7fff4707d0 : test_2 : end of test_2
*** stack smashing detected ***: ./test-O0-omit-fp terminated

[Bug c++/70468] [6/7/8 Regression] ICE on invalid code on x86_64-linux-gnu in emit_mem_initializers, at cp/init.c:1109

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
clang++ errors here are on #c0:
pr70468.C:6:10: error: type 'A::f0' (aka 'A<>') is not a direct or virtual base
of 'A'
and on #c2:
pr70468-2.C:5:10: error: type 'A::f0' (aka 'A<>') is not a direct or virtual
base of 'A'

[Bug target/84521] New: [8 Regression] aarch64: Frame-pointer corruption with setjmp/longjmp and -fomit-frame-pointer

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84521
   Summary: [8 Regression] aarch64: Frame-pointer corruption with
setjmp/longjmp and -fomit-frame-pointer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
CC: jgreenhalgh at gcc dot gnu.org, marcus.shawcroft at arm dot 
com,
rearnsha at gcc dot gnu.org, wilco at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-unknown-linux-gnu
Target: aarch64-unknown-linux-gnu
 Build: aarch64-unknown-linux-gnu

The downstream bug report here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1545239
describes a problem seen on aarch64 with gcc 8 that breaks the build of Ruby at
-O1 and above.

Bisection shows that the problem started with r254815, which made
-fomit-frame-pointer the default.
Jakub reported:
> It is actually much older, I get the same crash if vm.c is compiled with
> -mlittle-endian -mabi=lp64 -g -grecord-gcc-switches -O1 -Wall 
> -Werror=format-security
> -fexceptions -fPIC -fstack-protector -fno-strict-overflow 
> -fexcess-precision=standard -fomit-frame-pointer
> with r204770, so already GCC 4.9 behaves that way too.
> Note ruby uses -fno-omit-frame-pointer already, but only on mingw32.

The issue is that the code generated for __builtin_longjmp reads a value for
x29 (the frame pointer) from the jmp_buf, but the code generated for
__builtin_setjmp doesn't actually write x29 to the jmp_buf, leading to
corruption of x29 when a longjmp occurs.

This corruption seems to be short-lived when -fno-omit-frame-pointer (the old
default), as every function restores x29 from the stack on exit.
With the new default of -fomit-frame-pointer the corruption can survive long
enough to cause crashes.

There's a lot more analysis at the downstream bug report in the URL above.

I'm about to attach a reproducer.

I'm marking this as "[8 Regression]" since although this is appears to be a
long-standing bug, the change of default in r254815 exposes it by default.

[Bug c++/84520] New: [6/7/8 Regression] ICE with lambda and static member function

[reichelt at gcc dot gnu.org]

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

Bug ID: 84520
   Summary: [6/7/8 Regression] ICE with lambda and static member
function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid testcase triggers an ICE since GCC 5.1.0.
It was compiled without problems in GCC 4.9.x.


struct A
{
  static void foo(int);
  void (*f)(int) = [](auto i) { foo(i); };
};


bug.cc: In instantiation of 'A:: [with auto:1 = int]':
bug.cc:4:29:   required by substitution of 'template
A::::operator decltype
(((A::)0u).operator()(i)) (*)(auto:1)() const [with auto:1 =
int]'
bug.cc:4:41:   required from here
bug.cc:4:36: internal compiler error: in lambda_expr_this_capture, at
cp/lambda.c:697
   void (*f)(int) = [](auto i) { foo(i); };
^
0x83f04c lambda_expr_this_capture(tree_node*, bool)
../../gcc-5.1.0/gcc/cp/lambda.c:695
0x83f387 maybe_resolve_dummy(tree_node*, bool)
../../gcc-5.1.0/gcc/cp/lambda.c:789
0x6485a1 build_new_method_call_1
../../gcc-5.1.0/gcc/cp/call.c:8027
0x6485a1 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-5.1.0/gcc/cp/call.c:8275
0x7cd9ef finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-5.1.0/gcc/cp/semantics.c:2367
0x6b536f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-5.1.0/gcc/cp/pt.c:15211
0x6a2a85 tsubst_expr
../../gcc-5.1.0/gcc/cp/pt.c:14398
0x6a39b2 tsubst_expr
../../gcc-5.1.0/gcc/cp/pt.c:13809
0x6a25fb tsubst_expr
../../gcc-5.1.0/gcc/cp/pt.c:13981
0x6a25fb tsubst_expr
../../gcc-5.1.0/gcc/cp/pt.c:13981
0x6a0774 instantiate_decl(tree_node*, int, bool)
../../gcc-5.1.0/gcc/cp/pt.c:20407
0x7219f8 mark_used(tree_node*, int)
../../gcc-5.1.0/gcc/cp/decl2.c:5029
0x63d88a build_over_call
../../gcc-5.1.0/gcc/cp/call.c:7489
0x64889e build_new_method_call_1
../../gcc-5.1.0/gcc/cp/call.c:8205
0x64889e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-5.1.0/gcc/cp/call.c:8275
0x6b5fe2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-5.1.0/gcc/cp/pt.c:15205
0x6aac9e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-5.1.0/gcc/cp/pt.c:12530
0x6b0a5f tsubst_function_type
../../gcc-5.1.0/gcc/cp/pt.c:11624
0x6ab365 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-5.1.0/gcc/cp/pt.c:12357
0x6aac06 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-5.1.0/gcc/cp/pt.c:11899
Please submit a full bug report, [etc.]

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #8 from Segher Boessenkool  ---
I'll handle it.

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
We actually do *not* need TARGET_FPRND; fctiw and fctid are ISA 1.xx insns.

Before power8 we do not allow putting SImode in FPRs.

[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #4 from Will Schmidt  ---
Tried to re-create locally, I've gotten two ICE's using the provided testcode
snippet, neither look quite like the originally reported issue.  (thus I don't
know if this is actually the same issue).

Neither of these require the -fgraphite-identity option be specified.  -m32 or
-m64 doesn't seem to matter for me. 

Target: powerpc64-unknown-linux-gnu
Configured with: /home/willschm/gcc/gcc-mainline-regtest_patches/configure
--enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7
--with-long-double-128
--prefix=/home/willschm/gcc/install/gcc-mainline-regtest_patches
--disable-bootstrap --with-isl --with-graphite : (reconfigured)
/home/willschm/gcc/gcc-mainline-regtest_patches/configure
--enable-languages=c,c++ --with-cpu=power7 --with-long-double-128
--prefix=/home/willschm/gcc/install/gcc-mainline-regtest_patches
--disable-bootstrap --with-isl --with-graphite

# with -O2.  
> $GCC_INSTALL/bin/gcc ./pr82982.c  -c -O2 -m32
during GIMPLE pass: store-merging
./pr82982.c: In function ‘km’:
./pr82982.c:4:1: internal compiler error: Segmentation fault
 km (void)
 ^~
0x10f75447 crash_signal
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/toplev.c:325

# with -O3.
> $GCC_INSTALL/bin/gcc ./pr82982.c  -c -O3
during IPA pass: cp
./pr82982.c:31:1: internal compiler error: Segmentation fault
 }
 ^
0x10f75447 crash_signal
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/toplev.c:325
0x103de084 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/tree.h:3131
0x10da9e77 opts_for_fn
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/tree.h:5319
0x10dbe04b cgraph_node::optimize_for_size_p()
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/cgraph.h:3152
0x11e50afb ipcp_cloning_candidate_p
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:709
0x11e50ef3 initialize_node_lattices
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:1177
0x11e5df7b ipcp_propagate_stage
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:3284
0x11e5e317 ipcp_driver
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:5026
0x11e5e3ff execute
/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:5120

[Bug c++/80955] Macros expanded in definition of user-defined literals

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Also the new testcase for this bug has undefined behaviour. _ID is a reserved
name so the program cannot use it to define a macro or a UDL.

[Bug c++/84518] [8 Regression] ICE with lambda capturing broken variable

[reichelt at gcc dot gnu.org]

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

--- Comment #1 from Volker Reichelt  ---
A modified testcase produces a slightly different stack-trace:


template void foo()
{
  T x[=];
  []{};
}


bug.cc: In function 'void foo()':
bug.cc:3:7: error: expected primary-expression before '=' token
   T x[=];
   ^
bug.cc:3:8: error: expected primary-expression before ']' token
   T x[=];
^
bug.cc: In lambda function:
bug.cc:4:6: internal compiler error: in is_normal_capture_proxy, at
cp/lambda.c:289
   []{};
  ^
0x614602 is_normal_capture_proxy(tree_node*)
../../gcc/gcc/cp/lambda.c:289
0x8d4918 is_capture_proxy_with_ref(tree_node*)
../../gcc/gcc/cp/lambda.c:301
0x8d49ad insert_capture_proxy(tree_node*)
../../gcc/gcc/cp/lambda.c:311
0x8d546f build_capture_proxy(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:474
0x8d8596 start_lambda_function(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:1374
0x91daad cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:10662
0x91daad cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10182
0x91daad cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5257
0x93043c cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7026
0x931010 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91139f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
0x911baa cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x9133e4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9482
0x913af8 cp_parser_expression
../../gcc/gcc/cp/parser.c:9651
0x9157b8 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:8
0x91bb2d cp_parser_statement
../../gcc/gcc/cp/parser.c:10922
0x91d040 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d117 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933890 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933890 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
Please submit a full bug report, [etc.]

[Bug fortran/84519] New: STOP and ERROR STOP statements with QUIET specifier

[jb at gcc dot gnu.org]

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

Bug ID: 84519
   Summary: STOP and ERROR STOP statements with QUIET specifier
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

In F2018 the STOP and ERROR STOP statements take and extra QUIET= specifier, a
logical value determining whether any information should be printed to the
screen or not.

For GCC 8, it would be good to have this in the library API even though the
parsing could well be postponed to a later release.

[Bug c++/84518] New: [8 Regression] ICE with lambda capturing broken variable

[reichelt at gcc dot gnu.org]

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

Bug ID: 84518
   Summary: [8 Regression] ICE with lambda capturing broken
variable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid testcase triggers an ICE on trunk:


template void foo()
{
  int x[=];
  []{};
}

void bar()
{
  foo<0>();
}


bug.cc: In function 'void foo()':
bug.cc:3:9: error: expected primary-expression before '=' token
   int x[=];
 ^
bug.cc:3:10: error: expected primary-expression before ']' token
   int x[=];
  ^
bug.cc: In instantiation of 'void foo() [with int  = 0]':
bug.cc:9:10:   required from here
bug.cc:4:3: internal compiler error: tree check: expected class 'expression',
have 'exceptional' (error_mark) in tree_operand_check, at tree.h:3630
   []{};
   ^
0x78a846 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9385
0x614d34 expr_check(tree_node*, char const*, int, char const*)
../../gcc/gcc/tree.h:3301
0x614d34 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/gcc/tree.h:3630
0x614d34 build_capture_proxy(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:447
0x8d8596 start_lambda_function(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:1374
0x95a004 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17080
0x95a9e2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18368
0x969349 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17130
0x969349 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16862
0x968ce0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16079
0x9683c9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16065
0x966481 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16346
0x965718 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16050
0x965718 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23406
0x98b7ab instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23522
0x8b1cab c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4720
Please submit a full bug report, [etc.]

The regression was introduced between 2017-09-26 and 2017-10-07.

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Dominique d'Humieres  ---
> Assign to Jerry per his request.

So moved status to ASSIGN.

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
  Known to fail||8.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Assign to Jerry per his request.

[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Ah, I can reproduce with -mtune=silvermont or -mtune=atom, it works fine with
-mtune=generic or e.g. -mtune=silvermont -fno-vect-cost-model.

I'd just add -mtune=generic to the 2 test's dg-options.

[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Can't reproduce it here, both on x86_64-linux and i686-linux I see
PASS: gcc.target/i386/avx2-vpaddq-3.c scan-assembler-times vpaddq[
\\t]+[^\n]*%ymm[0-9] 1
PASS: gcc.target/i386/avx2-vpsubq-3.c scan-assembler-times vpsubq[
\\t]+[^\n]*%ymm[0-9] 1
Any special --with-arch/--with-tune you're using?
My builds are just
../configure --enable-languages=default,ada,obj-c++,lto,go,brig
--enable-checking=yes,rtl,extra
for x86_64-linux and
../configure --enable-languages=default,obj-c++,lto,go,brig
--enable-checking=yes,rtl,extra
for i686-linux.

[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed in r257910.

[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal

[romain.geissler at amadeus dot com]

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

--- Comment #6 from Romain Geissler  ---
Thanks ;)

[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Feb 22 17:35:29 2018
New Revision: 257910

URL: https://gcc.gnu.org/viewcvs?rev=257910=gcc=rev
Log:
PR tree-optimization/84480 - bogus -Wstringop-truncation despite assignment
with an inlined string literal

gcc/ChangeLog:

PR tree-optimization/84480
* gimple-fold.c (gimple_fold_builtin_strcpy): Move warnings
to maybe_diag_stxncpy_trunc.  Call it.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Integrate warnings
from gimple_fold_builtin_strcpy.  Print inlining stack.
(handle_builtin_stxncpy): Print inlining stack.
* tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Declare.

gcc/testsuite/ChangeLog:

PR tree-optimization/84480
* c-c++-common/Wstringop-truncation.c: Adjust text of expected
warnings.
* g++.dg/warn/Wstringop-truncation-1.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wstringop-truncation-1.C
trunk/gcc/tree-ssa-strlen.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation.c
trunk/gcc/tree-ssa-strlen.c

[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"

[laurent at guerby dot net]

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

--- Comment #18 from Laurent GUERBY  ---
Marxin, you have a cfarm account and access to gcc22 / 23 / 24 which are mips64
machines. If you need to change ssh keys see here:
https://cfarm.tetaneutral.net/login/

[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
(In reply to Felix Fietkau from comment #16)
> Any update on this, or any way I could help in getting this fixed?
> It would be nice if we could finally switch OpenWrt to a more recent GCC
> version soon.

I would like to really help you. But it's really problematic to have a mips
qemu machine with working network. Having that I would be able to run e.g.
https://people.debian.org/~aurel32/qemu/mips/

and I would be able to debug that locally. Any help how to play with?

[Bug c++/80955] Macros expanded in definition of user-defined literals

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Moved to PR 84517

[Bug preprocessor/84517] New: [8 Regression] "string literal"__FILE__ no longer accepted

[redi at gcc dot gnu.org]

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

Bug ID: 84517
   Summary: [8 Regression] "string literal"__FILE__ no longer
accepted
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

const char* err() { return "Error in "__FILE__; }

With GCC 7 this gave a warning:

file.cc:1:28: warning: invalid suffix on literal; C++11 requires a space
between literal and string macro [-Wliteral-suffix]
 const char* err() { return "Error in "__FILE__; }
^

But GCC 8 now rejects it:

file.cc: In function ‘const char* err()’:
file.cc:1:28: error: unable to find string literal operator
‘operator""__FILE__’ with ‘const char [10]’, ‘long unsigned int’ arguments
 const char* err() { return "Error in "__FILE__; }
^~~

This was caused by r254443 for PR 80955

I'm not going to add the "rejects-valid" keyword, because technically the code
is invalid, but we accept it as an extension because there is no matching UDL.

[Bug c++/84196] invalid call to a function template with a vector argument silently accepted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
  Known to work|4.7.4   |
   Target Milestone|6.5 |---
Summary|[6/7/8 Regression] invalid  |invalid call to a function
   |call to a function template |template with a vector
   |with a vector argument  |argument silently accepted
   |silently accepted   |

--- Comment #2 from Jakub Jelinek  ---
Which means this really is not a regression.
If you replace the v[0] + v[1] + v[2] + v[3] part that is only accepted
starting from r186994, it will be accepts-invalid all the way to the
introduction of vector_size attribute.

The clang++ error looks bogus as well, there is no reason why I can't do:

template 
int f (T x)
{
  T __attribute__((vector_size (16))) v = { x };
  v[0] += 1;
  ...
  return v[0];
}
int x = f (5);

What doesn't work is that 1) we don't really have mangling for template
parameter with attributes on it 2) something else is broken for parameter
passing of these, e.g.
template 
int f (T v __attribute__ ((vector_size (16
{
  return 0;
}

int main ()
{
  return f ((int __attribute__ ((vector_size (16 { 1, 2, 3, 4} );
}
where we really don't need deduction fails too and 3) deduction doesn't work
with these.  So, I think we should instead reject just what we can't support
and sorry about stuff we don't want to support right now.

[Bug target/84176] Need a different thunk for -mindirect-branch=thunk-extern -fcf-protection -mcet

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Feb 22 17:09:06 2018
New Revision: 257909

URL: https://gcc.gnu.org/viewcvs?rev=257909=gcc=rev
Log:
i386: Add __x86_indirect_thunk_nt_reg for -fcf-protection -mcet

nocf_check attribute can be used with -fcf-protection -mcet to disable
control-flow check by adding NOTRACK prefix before indirect branch.
When -mindirect-branch=thunk-extern -mindirect-branch-register is added,
indirect branch via register, "notrack call/jmp reg", is converted to

call/jmp __x86_indirect_thunk_nt_reg

When running on machines with CET enabled, __x86_indirect_thunk_nt_reg
can be updated to

notrack jmp reg

at run-time to restore NOTRACK prefix in the original indirect branch.

Since we don't support -mindirect-branch=thunk-extern, CET and MPX at
the same time, -mindirect-branch=thunk-extern is disallowed with
-fcf-protection=branch and -fcheck-pointer-bounds.

Tested on i686 and x86-64.

gcc/

PR target/84176
* config/i386/i386.c (ix86_set_indirect_branch_type): Issue an
error when -mindirect-branch=thunk-extern, -fcf-protection=branch
and -fcheck-pointer-bounds are used together.
(indirect_thunk_prefix): New enum.
(indirect_thunk_need_prefix): New function.
(indirect_thunk_name): Replace need_bnd_p with need_prefix.  Use
"_nt" instead of "_bnd" for NOTRACK prefix.
(output_indirect_thunk): Replace need_bnd_p with need_prefix.
(output_indirect_thunk_function): Likewise.
(): Likewise.
(ix86_code_end): Update output_indirect_thunk_function calls.
(ix86_output_indirect_branch_via_reg): Replace
ix86_bnd_prefixed_insn_p with indirect_thunk_need_prefix.
(ix86_output_indirect_branch_via_push): Likewise.
(ix86_output_function_return): Likewise.
* doc/invoke.texi: Document -mindirect-branch=thunk-extern is
incompatible with -fcf-protection=branch and
-fcheck-pointer-bounds.

gcc/testsuite/

PR target/84176
* gcc.target/i386/indirect-thunk-11.c: New test.
* gcc.target/i386/indirect-thunk-12.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-12.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-13.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-14.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-15.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-16.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-10.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-8.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-9.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-11.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-12.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-12.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-13.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-14.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-15.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-16.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-10.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-8.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/80955] Macros expanded in definition of user-defined literals

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Testing this:

--- a/libcpp/lex.c
+++ b/libcpp/lex.c
@@ -1903,7 +1903,7 @@ lex_raw_string (cpp_reader *pfile, cpp_token *token,
const uchar *base,
 literal thus breaking the program.
 Try to identify macros with is_macro. A warning is issued.
 The macro name should not start with '_' for this warning. */
-  if ((*cur != '_') && is_macro (pfile, cur))
+  if ((*cur != '_' || cur[1] == '_') && is_macro (pfile, cur))
{
  /* Raise a warning, but do not consume subsequent tokens.  */
  if (CPP_OPTION (pfile, warn_literal_suffix) &&
!pfile->state.skipping)
@@ -2034,7 +2034,7 @@ lex_string (cpp_reader *pfile, cpp_token *token, const
uchar *base)
 literal thus breaking the program.
 Try to identify macros with is_macro. A warning is issued.
 The macro name should not start with '_' for this warning. */
-  if ((*cur != '_') && is_macro (pfile, cur))
+  if ((*cur != '_' || cur[1] == '_') && is_macro (pfile, cur))
{
  /* Raise a warning, but do not consume subsequent tokens.  */
  if (CPP_OPTION (pfile, warn_literal_suffix) &&
!pfile->state.skipping)

[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481

[sje at gcc dot gnu.org]

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

--- Comment #6 from Steve Ellcey  ---
Author: sje
Date: Thu Feb 22 17:08:10 2018
New Revision: 257908

URL: https://gcc.gnu.org/viewcvs?rev=257908=gcc=rev
Log:
2018-02-22  Steve Ellcey  

PR target/83335
* gcc/testsuite/gcc.target/aarch64/asm-2.c: Add dg-error for
ILP32 mode.
* gcc/testsuite/gcc.target/aarch64/asm-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/asm-4.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/asm-2.c

[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481

[sje at gcc dot gnu.org]

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

--- Comment #5 from Steve Ellcey  ---
Author: sje
Date: Thu Feb 22 17:06:31 2018
New Revision: 257907

URL: https://gcc.gnu.org/viewcvs?rev=257907=gcc=rev
Log:
2018-02-22  Steve Ellcey  

PR target/83335
* config/aarch64/aarch64.c (aarch64_print_address_internal):
Change gcc_assert call to output_operand_lossage.

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

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
It does break if I set the breakpoints before the shared libs have loaded.


Thread 3 "a.out" hit Breakpoint 1, 0x3fffb6e0c860 in .__memset_power7 ()
   from /lib64/libc.so.6
#0  0x3fffb6e0c860 in .__memset_power7 () from /lib64/libc.so.6
#1  0x3fffb7055b10 in __interceptor_memset (dst=0x100201f0 , 
v=, size=40)
at
/home/segher/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:709
#2  0x3fffb6f9f2b0 in .pthread_mutex_init () from /lib64/libpthread.so.0
#3  0x3fffb704d58c in __interceptor_pthread_mutex_init (
m=0x100201f0 , a=0x0)
at /home/segher/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:1132
#4  0x1dc4 in .Thread1 ()
#5  0x3fffb7049454 in __tsan_thread_start_func (arg=0x3fffeda0)
at /home/segher/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:905
#6  0x3fffb6f9c95c in .start_thread () from /lib64/libpthread.so.0
#7  0x3fffb6e83bbc in .__clone () from /lib64/libc.so.6

[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
(In reply to Eric Gallager from comment #10)
> Have all of the changes committed from this bug fixed it?

No, I'm preparing some changes for stage1.

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Seems any -O* level with -mcpu=power6 or -mcpu=power7 actually.

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The ICE is with -m64 -mcpu=power6 -O0.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #11 from Segher Boessenkool  ---
I rebuilt everything, and it still does not break at all.

[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
Have all of the changes committed from this bug fixed it?

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||carll at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I guess this regressed with r253238 when these builtins were introduced.
I actually see multiple issues with these builtins:
1) as written above, lrintsfsi2 condition is TARGET_SF_FPR && TARGET_FPRND,
ditto lrintsfdi2 and lrintdfdi2 condition is TARGET_DF_FPR && TARGET_FPRND.
The builtins def file says just RS6000_BTM_HARD_FLOAT as the requirement, which
isn't enough, we also need TARGET_FPRND and for one of the builtins
TARGET_SF_FPR, for the other TARGET_DF_FPR.  Changing
BU_FP_MISC_1 to require even (RS6000_BTM_HARD_FLOAT | RS6000_BTM_CELL)
doesn't work, then the builtin is refused on all CPUs but -mcpu=cell.
So, do we need to introduce two new RS6000_BTM_* values for these two builtins
and arrange for the right tests for them to be done?
2) with -mcpu=power6 or -mcpu=power7
long
f1 (float x)
{
  return __builtin_fctid (x);
}

long
f2 (double x)
{
  return __builtin_fctid (x);
}

int
f3 (float x)
{
  return __builtin_fctiw (x);
}

int
f4 (double x)
{
  return __builtin_fctiw (x);
}
ICEs in LRA instead:
pr83964.c: In function ‘f3’:
pr83964.c:24:1: error: unable to generate reloads for:
 }
 ^
(insn 7 6 8 2 (set (reg:SI 124)
(unspec:SI [
(reg:DF 121 [ _1 ])
] UNSPEC_FCTIW)) "pr83964.c":23 419 {lrintsfsi2}
 (expr_list:REG_DEAD (reg:DF 121 [ _1 ])
(nil)))
during RTL pass: reload
pr83964.c:24:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3884
0xdc05c5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)

Either the rs6000 builtins expansion code for __builtin_fctiw float_truncate
the operand so that it is SFmode rather than DFmode, or it shouldn't use
lrintsf* code, but some other for an expander that adds the float_truncate.

What is the point of these builtins, i.e. what is the advantage of them over a
C cast from float or double to int or long?

[Bug libstdc++/78870] Support std::filesystem on Windows

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
(In reply to niXman from comment #10)
> (In reply to Jonathan Wakely from comment #9)
> > There's a patch at https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html
> > 
> > I haven't reviewed or tested it yet.
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00772.html
> 
> Tested on i686/x86_64-MinGW-W64 and x86_64-linux-gnu.

Adding "patch" keyword

[Bug target/79926] i386: untranslated placeholder "exception/interrupt" in diagnostic

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack, patch
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79868
   Severity|normal  |trivial

--- Comment #2 from Eric Gallager  ---
(In reply to David Malcolm from comment #1)
> Candidate patch:
>   https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00446.html

This was reviewed as "ok with changes"

[Bug fortran/84509] STOP and PAUSE statements with -fdefault-integer-8 and large stop code

[jb at gcc dot gnu.org]

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

--- Comment #2 from Janne Blomqvist  ---
Author: jb
Date: Thu Feb 22 16:14:21 2018
New Revision: 257903

URL: https://gcc.gnu.org/viewcvs?rev=257903=gcc=rev
Log:
PR 78534, 84509 Fix libgfortran API for PAUSE statement

This patch changes the libgfortran API for the PAUSE statement. By
passing a GFC_INTEGER_8 it handles -fdefault-integer-8, and for the
character version passing the length as a size_t.

Regtested on x86_64-pc-linux-gnu, committed as obvious.

gcc/fortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR 78534
PR 84509
* trans-decl.c (gfc_build_builtin_function_decls): Pass
gfc_int8_type node to pause_numeric, size_type_node to
pause_string.
* trans-stmt.c (gfc_trans_pause): Likewise.

libgfortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR 78534
PR 84509
* runtime/pause.c (pause_numeric): Modify to take GFC_INTEGER_8
argument.
(pause_string): Modify to take size_t character length argument.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-stmt.c
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/pause.c

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

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

--- Comment #28 from Janne Blomqvist  ---
Author: jb
Date: Thu Feb 22 16:14:21 2018
New Revision: 257903

URL: https://gcc.gnu.org/viewcvs?rev=257903=gcc=rev
Log:
PR 78534, 84509 Fix libgfortran API for PAUSE statement

This patch changes the libgfortran API for the PAUSE statement. By
passing a GFC_INTEGER_8 it handles -fdefault-integer-8, and for the
character version passing the length as a size_t.

Regtested on x86_64-pc-linux-gnu, committed as obvious.

gcc/fortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR 78534
PR 84509
* trans-decl.c (gfc_build_builtin_function_decls): Pass
gfc_int8_type node to pause_numeric, size_type_node to
pause_string.
* trans-stmt.c (gfc_trans_pause): Likewise.

libgfortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR 78534
PR 84509
* runtime/pause.c (pause_numeric): Modify to take GFC_INTEGER_8
argument.
(pause_string): Modify to take size_t character length argument.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-stmt.c
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/pause.c

[Bug tree-optimization/84515] missed optimization: expected loop merging

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-22
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug c++/84516] bitfield temporaries > 32-bits have wrong type

[gnu at mllr dot cc]

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

--- Comment #1 from Greg Miller  ---
The issue is not related to iostream. So, here's perhaps a simpler reproduction
example that may focus more on the issue at hand.

Link: https://godbolt.org/g/vA2rPN

struct A {
long x : 32;
long y : 33;
};

void F(int) {}
void F(long) {}
template 
void F(T) = delete;

int main() {
A a;
F(a.x);   // Calls F(long)
F(+a.x);  // Calls F(int)
F(a.y);   // Calls F(long)
F(+a.y);  // error: use of deleted function 'void F(T) [with T = long
int:33]'
}

Here we can see that the type of the expression `+a.y` is `long int:33`, which
I suspect is a problem. I think the type of that expression should be `long
int`.

[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords|error-recovery, |ice-on-valid-code
   |ice-on-invalid-code |
Summary|[6/7/8 Regression] ICE on   |[6/7/8 Regression] ICE on
   |invalid code in |valid code in
   |push_access_scope, at   |push_access_scope, at
   |cp/pt.c:229 |cp/pt.c:229

--- Comment #14 from Paolo Carlini  ---
Thus Comment #11 contains valid code.

[Bug c++/84516] New: bitfield temporaries > 32-bits have wrong type

[gnu at mllr dot cc]

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

Bug ID: 84516
   Summary: bitfield temporaries > 32-bits have wrong type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu at mllr dot cc
  Target Milestone: ---

(Disclaimer: I'm not a compiler guy, so I may accidentally use the wrong
terminology)

Example: https://godbolt.org/g/brhTMw


#include 
struct A {
long x : 32;
long y : 33;
};
int main() {
A a;
std::cout << a.x;  // OK
std::cout << a.y;  // OK
std::cout << +a.x;  // OK
std::cout << +a.y;  // BREAKS on gcc
}

The problem is the last line. The type of the expression `+a.y` is 'long
int:33', which is not a type that operator<<() has an overload for. The type of
the expression `a.y` is 'long int' and so op<<() has an overload and works.

This issue seems to be affected by

(a) The size of the bit field; <= 32 bits works, > 32 bits breaks.
(b) Whether the bitfield is used in an expression producing a temporary;
>32-bit size AND a temporary breaks, <= 32-bit size and an lvalue works.

I confirmed this behavior on x86-64 gcc trunk using godbolt.org. (link again:
https://godbolt.org/g/brhTMw)

[Bug target/81228] [7 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2508

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from sudi at gcc dot gnu.org ---
Backported to gcc-7 as r257901

[Bug target/81228] [7 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2508

[sudi at gcc dot gnu.org]

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

--- Comment #10 from sudi at gcc dot gnu.org ---
Author: sudi
Date: Thu Feb 22 15:01:05 2018
New Revision: 257901

URL: https://gcc.gnu.org/viewcvs?rev=257901=gcc=rev
Log:
Adding the missing LTGT to plug the ICE in PR81228.
This is a backport of r255625 of trunk.

*** gcc/ChangeLog ***

2018-02-22  Sudakshina Das  
Bin Cheng  

Backport from mainline:
2017-12-14  Sudakshina Das  
Bin Cheng  

PR target/81228
* config/aarch64/aarch64.c (aarch64_select_cc_mode): Move LTGT to
CCFPEmode.
* config/aarch64/aarch64-simd.md (vec_cmp): Add
LTGT.

*** gcc/testsuite/ChangeLog ***

2017-02-22  Sudakshina Das  

Backport from mainline:
2017-12-14  Sudakshina Das  

PR target/81228
* gcc.dg/pr81228.c: New.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81228.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/aarch64/aarch64-simd.md
branches/gcc-7-branch/gcc/config/aarch64/aarch64.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[tromey at gcc dot gnu.org]

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

--- Comment #17 from Tom Tromey  ---
The results in comment #13 seem to be missing some compilations --
I would have expected to see more files from libcpp in there.
As it is I only see directives.o and line-map.o.

[Bug tree-optimization/84515] New: missed optimization: expected loop merging

[nsz at gcc dot gnu.org]

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

Bug ID: 84515
   Summary: missed optimization: expected loop merging
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

i expected f1 and f2 to compile to the same code:

unsigned g;

void f1(unsigned count) {
unsigned i;
for (i = 0; i < count  ; i++) g++;
}

void f2(unsigned count) {
unsigned i;
for (i = 0; i < count/2; i++) g++;
for ( ; i < count  ; i++) g++;
}


but with -O3 the asm is

f1:
  testl %edi, %edi
  je .L1
  addl %edi, g(%rip)
.L1:
  ret

f2:
  movl %edi, %eax
  shrl %eax
  je .L8
  addl %eax, g(%rip)
.L8:
  cmpl %eax, %edi
  jbe .L7
  subl %eax, %edi
  addl %edi, g(%rip)
.L7:
  ret

(on aarch64 even the address of g is recomputed for the second loop with adrp)

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
Unless vectors count as aggregates (more or less), in which case we can ignore
my previous comment.

[Bug target/81572] [7/8 Regression] gcc-7 regression: unnecessary vector regmove on compare

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
  I am working on this PR.  The patch will be ready today or tomorrow.

  The problem is that the move insn has one alternative with early clobber and
this move insn is  processed on a fast path which ignores that other
alternatives might have no early clobbers.

[Bug c++/80955] Macros expanded in definition of user-defined literals

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Is there a way to check if it's a pre-defined macro?

Or just change the condition to allow starting with two underscores, but not
allow starting with one (since user-defined UDLs must start with a single
underscore, and must not start with two).