[Bug preprocessor/84161] preprocessor should discard Fortran comments

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> It should not.

Well, why not? 

If you say that the preprocessor is meant only for C/C++, then it shouldn't be
used with Fortran at all.

If one uses it with Fortran, it should also understand the specifics of Fortran
syntax, no?

Would it make sense to have a "Fortran mode" or something like that? Right now
gfortran is using 'traditional' mode IIUC.


> Use /* ... */ or // comments instead if you don't want expansion in them.

Using // actually does not work for me:

comment.F90:5:0:

 // _ASSERT_() is a nice macro :)
 ^
Error: macro "_ASSERT_" requires 2 arguments, but only 1 given
comment.F90:5:1:

 // _ASSERT_() is a nice macro :)
 1
Error: Invalid character in name at (1)


Using /* ... */ does work, but it's strange to do that in Fortran code (plus it
breaks if the code is not preprocessed; preprocessing is 'optional' for
Fortran).

!/* ... */ is a reasonable workaround for now.



> The preprocessor doesn't know anything about Fortran parsing and changing
> this would e.g. break OpenMP or OpenACC, where we do want normal
> preprocessing in !$omp and !$acc comments.

That's true (and it's different from C/C++ where OpenMP uses pragmas, not
comment-like directive).
One could still teach the preprocessor to discard !... , but not !$..., in a
Fortran context.

[Bug rtl-optimization/84164] New: [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1

[zsojka at seznam dot cz]

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

Bug ID: 84164
   Summary: [8 Regression] ICE: in elimination_costs_in_insn, at
reload1.c:3633 at -O1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

This occurs only with the aarch64-unknown-linux-gnu target.

Compiler output:
$ cc1 -quiet testcase.c -O
during RTL pass: ira
testcase.c: In function 'foo':
testcase.c:15:1: internal compiler error: in elimination_costs_in_insn, at
reload1.c:3633
 }
 ^
0xbed921 elimination_costs_in_insn
/repo/gcc-trunk/gcc/reload1.c:3630
0xbf68cf calculate_elim_costs_all_insns()
/repo/gcc-trunk/gcc/reload1.c:1607
0xa64ced ira_costs()
/repo/gcc-trunk/gcc/ira-costs.c:2249
0xa5d17c ira_build()
/repo/gcc-trunk/gcc/ira-build.c:3427
0xa53d66 ira
/repo/gcc-trunk/gcc/ira.c:5293
0xa53d66 execute
/repo/gcc-trunk/gcc/ira.c:5604
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ xgcc -v
Using built-in specs.
COLLECT_GCC=/repo/build-trunk-257290-checking-yes-rtl-df-extra-aarch64/./gcc/xgcc
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-257290-checking-yes-rtl-df-extra-aarch64
Thread model: posix
gcc version 8.0.1 20180201 (experimental) (GCC)

[Bug target/82795] [7/8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.3.1
 Resolution|--- |FIXED
Summary|[7 Regression] ICE in   |[7/8 Regression] ICE in
   |predicate_mem_writes, at|predicate_mem_writes, at
   |tree-if-conv.c:2251 |tree-if-conv.c:2251
  Known to fail||7.3.0

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

[Bug target/82795] [7/8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Feb  1 12:07:46 2018
New Revision: 257292

URL: https://gcc.gnu.org/viewcvs?rev=257292=gcc=rev
Log:
2018-02-01  Richard Biener  

Backport from mainline
2017-11-02  Richard Biener  

PR tree-optimization/82795
* tree-if-conv.c (predicate_mem_writes): Remove bogus assert.

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

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr82795.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-if-conv.c

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[pault at gcc dot gnu.org]

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

--- Comment #20 from Paul Thomas  ---
A temporary fix:

Index: ../trunk/gcc/fortran/trans-io.c
===
*** ../trunk/gcc/fortran/trans-io.c (revision 257261)
--- ../trunk/gcc/fortran/trans-io.c (working copy)
*** gfc_trans_transfer (gfc_code * code)
*** 2590,2596 

if (expr->ts.type != BT_CLASS
 && expr->expr_type == EXPR_VARIABLE
!&& gfc_expr_attr (expr).pointer)
goto scalarize;


--- 2590,2596 

if (expr->ts.type != BT_CLASS
 && expr->expr_type == EXPR_VARIABLE
!&& (gfc_expr_attr (expr).pointer || gfc_expr_attr (expr).allocatable))
goto scalarize;

fixes this and pr84155.

transfer_array is receiving a dtype with all the fields set to zero. I will get
back to this tonight or tomorrow morning. I have to go to the lab now.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
A temporary fix:

Index: ../trunk/gcc/fortran/trans-io.c
===
*** ../trunk/gcc/fortran/trans-io.c (revision 257261)
--- ../trunk/gcc/fortran/trans-io.c (working copy)
*** gfc_trans_transfer (gfc_code * code)
*** 2590,2596 

if (expr->ts.type != BT_CLASS
 && expr->expr_type == EXPR_VARIABLE
!&& gfc_expr_attr (expr).pointer)
goto scalarize;


--- 2590,2596 

if (expr->ts.type != BT_CLASS
 && expr->expr_type == EXPR_VARIABLE
!&& (gfc_expr_attr (expr).pointer || gfc_expr_attr (expr).allocatable))
goto scalarize;

fixes this and pr84141.

transfer_array is receiving a dtype with all the fields set to zero. I will get
back to this tonight or tomorrow morning. I have to go to the lab now.

Paul

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka  ---
I have started with experiments on czerny. Set --param inline-min-speedup from
8 to 15 at 30th of January and to 30 yesterday.
Most of size regression comes away with 15 and I observed to off-noise
regressions.  GCC of spec2006 improves 32.5->34.5
With 30 there are regressions in botan (but not wrt earlier releases, just wrt
best values we got) that are bit random (improvements too) and mesa of spec2000
5200->4950.
There is still noticeable code size improvements and also facerec improves
6400->8000. (may be independent as it fixes regression from 19th)

So consistent improvement is possible with 15. I will also check
inline-insns-auto/single and arrive to patch hopefully by end of weekend.

Honza

[Bug preprocessor/84165] #define strlen asdf affects calls to asdf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
You get a declaration from stdio.h for asdf because you redefined strlen

[Bug tree-optimization/84013] wrong __restrict clique with inline asm operand

[katsunori.kumatani at gmail dot com]

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

--- Comment #4 from Katsunori Kumatani  ---
Thanks, it's quite useful in some "meta asm" cases (in conjunction with
plugins, asms can be useful since you can't add builtins). Or when doing custom
calls in asms (or syscalls, etc) and you know what memory they touch, without
having to clobber everything. :)

[Bug c/84168] New: Please backport "Avoid assembler warnings from AArch64 constructor/destructor priorities."

[frank.mehnert at googlemail dot com]

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

Bug ID: 84168
   Summary: Please backport "Avoid assembler warnings from AArch64
constructor/destructor priorities."
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frank.mehnert at googlemail dot com
  Target Milestone: ---

Please backport changeset 41be51b050e5de25e711657bdc0b19a7e98a564a at least to
gcc-7, if possible also to gcc-6. This warning is triggered very often in our
(L4Re) project.

Thank you!

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> This shouldn't happen with degagnu after
>
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347

Which would mean requiring at least DejaGnu 1.6, while install.texi
still states a minimum of 1.4.4.

The other issue (unconditionally generating .code16gcc without checking
if the assembler supports it) still stands.

Rainer

[Bug target/83846] Some SVE tests fail with -mabi=ilp32

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Feb  1 11:04:58 2018
New Revision: 257290

URL: https://gcc.gnu.org/viewcvs?rev=257290=gcc=rev
Log:
[AArch64] Fix SVE testsuite failures for ILP32 (PR 83846)

The SVE tests are split into code-quality compile tests and runtime
tests.  A lot of the former are geared towards LP64.  It would be
possible (but tedious!) to mark up every line that is expected to work
only for LP64, but I think it would be a constant source of problems.

Since the code has not been tuned for ILP32 yet, I think the best
thing is to select only the runtime tests for that combination.
They all pass on aarch64-elf and aarch64_be-elf except vec-cond-[34].c,
which are unsupported due to the lack of fenv support.

The patch also replaces uses of built-in types with stdint.h types
where possible.  (This excludes tests that change the endianness,
since we can't assume that system header files work in that case.)

2018-02-01  Richard Sandiford  

gcc/testsuite/
PR testsuite/83846
* gcc.target/aarch64/sve/aarch64-sve.exp: Only do *_run tests
for ILP32.
* gcc.target/aarch64/sve/clastb_2_run.c (main): Use TYPE instead
of hard-coding the choice.
* gcc.target/aarch64/sve/clastb_4_run.c (main): Likewise.
* gcc.target/aarch64/sve/clastb_5_run.c (main): Likewise.
* gcc.target/aarch64/sve/clastb_3_run.c (main): Likewise.  Generalize
memset call.
* gcc.target/aarch64/sve/const_pred_1.C: Include stdint.h and use
stdint.h types.
* gcc.target/aarch64/sve/const_pred_2.C: Likewise.
* gcc.target/aarch64/sve/const_pred_3.C: Likewise.
* gcc.target/aarch64/sve/const_pred_4.C: Likewise.
* gcc.target/aarch64/sve/load_const_offset_2.c: Likewise.
* gcc.target/aarch64/sve/logical_1.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_1.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_2.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_3.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_4.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_5.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_6.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_7.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_8.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_1.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_2.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_3.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_4.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_1.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_2.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_2_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_3.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_3_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_4.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_4_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_7.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_8.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_8_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_9.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_9_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_10.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_10_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_11.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_11_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_12.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_12_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_13.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_13_run.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_14.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_18.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_19.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_20.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_21.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_22.c: Likewise.
* gcc.target/aarch64/sve/struct_vect_23.c: Likewise.
* gcc.target/aarch64/sve/popcount_1.c (popcount_64): Use
__builtin_popcountll rather than __builtin_popcountl.

Reviewed-by: James Greenhalgh 

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/sve/aarch64-sve.exp
trunk/gcc/testsuite/gcc.target/aarch64/sve/clastb_2_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/clastb_3_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/clastb_4_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/clastb_5_run.c

[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
I've tested this on powerpc64-linux {-m64,-m32} as well (change_zero_ext
is pretty important for us; we have big testcases for this and related code).
No issues found.

[Bug rtl-optimization/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
We encounter an unrecognizable insn:
(insn 59 58 43 7 (set (reg:DI 124)
(rotatert:DI (reg:DI 125 [ c ])
(subreg:QI (and:SI (reg:SI 128)
(const_int 65535 [0x])) 0))) "ice.c":8 -1


It comes from the *aarch64_reg_3_neg_mask2 splitter. Need to figure out
what went wrong there

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #12)
> I've just checked a x86_64-apple-darwin11.4.2 build: the test PASSes for
> -m64, but FAILs for -m32 with
> 
> /var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//cchNxmiW.s:7:no such
> instruction: `shrx %eax, 4(%esp),%eax'
http://www.felixcloutier.com/x86/SARX:SHLX:SHRX.html

[Bug target/35179] execs crash in shared lib destructor = do_global_dtors_aux

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Gallager  ---
(In reply to Eric Gallager from comment #8)
> (In reply to Eric Gallager from comment #7)
> > (In reply to Radu Hociung from comment #6)
> > > Comment on attachment 17939 [details]
> > > Improved hello-test case showing working and failing command lines, with
> > > Makefile
> > > 
> > > Works as expected:
> > > gcc -g -o hello-exec hellomain.o -L. -lhello
> > > 
> > > Triggers the bug:
> > > gcc -g -static -o hello-exec-gccbug35179 hellomain.o -shared -L. -lhello 
> > > -v
> > 
> > Testcase fails to link for me on Darwin due to a difference in linkers:
> > 
> > $ make hello-exec-gccbug35179
> > /usr/local/bin/gcc -o hellomain.o -c -g hellomain.c 
> > hellomain.c: In function ‘main’:
> > hellomain.c:9:2: warning: implicit declaration of function ‘exit’
> > [-Wimplicit-function-declaration]
> >   exit(0);
> >   ^~~~
> > hellomain.c:9:2: warning: incompatible implicit declaration of built-in
> > function ‘exit’
> > hellomain.c:9:2: note: include ‘’ or provide a declaration of
> > ‘exit’
> > /usr/local/bin/gcc -o hello_.o -g -c -fpic -DPIC hello.c 
> > /usr/local/bin/gcc -o libhello.so -shared -g hello_.o 
> > echo Linking with both -static and -shared flags exposes the bug.
> > Linking with both -static and -shared flags exposes the bug.
> > /usr/local/bin/gcc -g -static -o hello-exec-gccbug35179 hellomain.o -shared
> > -L. -lhello -v 
> > Using built-in specs.
> > COLLECT_GCC=/usr/local/bin/gcc
> > COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-
> > wrapper
> > Target: i386-apple-darwin9.8.0
> > Configured with: ../configure --disable-werror --disable-werror-always
> > --enable-languages=c,c++,lto,objc,obj-c++
> > --enable-stage1-checking=release,rtl -C --with-system-libunwind
> > --enable-secureplt --enable-frame-pointer --enable-debug --with-isl
> > --disable-host-shared --enable-maintainer-mode --disable-default-pie
> > --with-ld64 --without-pic --enable-target-optspace CC=/usr/local/bin/gcc
> > CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
> > AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
> > AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
> > AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
> > Thread model: posix
> > gcc version 8.0.0 20170702 (experimental) (GCC) 
> > COMPILER_PATH=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/
> > local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/local/libexec/gcc/i386-
> > apple-darwin9.8.0/:/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/
> > local/lib/gcc/i386-apple-darwin9.8.0/
> > LIBRARY_PATH=/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/local/lib/
> > gcc/i386-apple-darwin9.8.0/8.0.0/../../../
> > COLLECT_GCC_OPTIONS='-g' '-static' '-o' 'hello-exec-gccbug35179'  '-L.' '-v'
> > '-mmacosx-version-min=10.5.8' '-asm_macosx_version_min=10.5' '-mtune=core2'
> > '-Zdynamiclib'
> >  /usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/collect2 -static -dylib
> > -arch i386 -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o
> > hello-exec-gccbug35179 -ldylib1.10.5.o -L.
> > -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0
> > -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/../../.. hellomain.o
> > -lhello -lgcc_eh -lgcc -v -idsym
> > collect2 version 8.0.0 20170702 (experimental)
> > /usr/bin/ld -static -dylib -arch i386 -macosx_version_min 10.5.8
> > -weak_reference_mismatches non-weak -o hello-exec-gccbug35179
> > -ldylib1.10.5.o -L. -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0
> > -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/../../.. hellomain.o
> > -lhello -lgcc_eh -lgcc -v
> > Apple Computer, Inc. version cctools-698.1~1
> > ld_classic: incompatible flag -dylib used (must specify "-dynamic" to be
> > used)
> > collect2: error: ld returned 1 exit status
> > make: *** [hello-exec-gccbug35179] Error 1
> > $
> > 
> > Someone running GNU/Linux will have to try the testcase to move this out of
> > WAITING.
> 
> Now that I have access to the GCC compile farm, the testcase still fails on
> me when I try it there:

"fails" as in "doesn't link" before it even gets to the crashes part. I guess
since it's been in WAITING with no response for so long I'll close this as
INVALID.

[Bug preprocessor/84165] New: #define strlen asdf affects calls to asdf

[manuel.rigger at jku dot at]

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

Bug ID: 84165
   Summary: #define strlen asdf affects calls to asdf
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manuel.rigger at jku dot at
  Target Milestone: ---

Hi,

I have a file asdf.h with the following content:

#define strlen asdf

I have another file test.c with the following content:

#include 
#include 
#include 

unsigned long asdf(const char* s) {
printf("asdf gets called with argument %s.", s);
return 1234;
}

int main(void) {
asdf("asdf");
return 0;
}

After compiling with clang -include asdf.h test.c -o test I get the following
output:

test.c:11:5: warning: ignoring return value of function declared with pure
attribute [-Wunused-value]
asdf("asdf");
^~~~ ~~
1 warning generated.

Executing the executable does not print anything.

I would have expected that the executable calls asdf(), but it seems that
asdf() was expected to be strlen(), which does not have any side effects, and
was thus deleted. Is this the correct behavior? Are defines bidirectional?

GCC version: gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
> 
> Could be a bug in the old Apple as.  However, the testcase is fishy in
> explicitly passing -m16.  For multilibbed x86 targets, that gets
> overridden for the non-default multilibs (either with -m32 or m64).

This shouldn't happen with degagnu after

http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347

[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-02-01
 CC||renlin.li at arm dot com
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #3 from Richard Earnshaw  ---
Doesn't this need backporting?

[Bug tree-optimization/81635] [8 Regression] nvptx SLP test cases regressions

[rsandifo at gcc dot gnu.org]

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

--- Comment #13 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Feb  1 14:17:07 2018
New Revision: 257296

URL: https://gcc.gnu.org/viewcvs?rev=257296=gcc=rev
Log:
Use range info in split_constant_offset (PR 81635)

This patch implements the original suggestion for fixing PR 81635:
use range info in split_constant_offset to see whether a conversion
of a wrapping type can be split.  The range info problem described in:

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01002.html

seems to have been fixed.

The patch is part 1.  There needs to be a follow-on patch to handle:

  for (unsigned int i = 0; i < n; i += 4)
{
  ...[i + 2]...
  ...[i + 3]...

which the old SCEV test handles, but which the range check doesn't.
At the moment we record that the low two bits of "i" are clear,
but we still end up with a maximum range of 0x rather than
0xfffc.

2018-01-31  Richard Sandiford  

gcc/
PR tree-optimization/81635
* tree-data-ref.c (split_constant_offset_1): For types that
wrap on overflow, try to use range info to prove that wrapping
cannot occur.

gcc/testsuite/
PR tree-optimization/81635
* gcc.dg/vect/bb-slp-pr81635-1.c: New test.
* gcc.dg/vect/bb-slp-pr81635-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr81635-1.c
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr81635-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug target/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|target
   Target Milestone|--- |8.0

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
>> /var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//cchNxmiW.s:7:no such
>> instruction: `shrx %eax, 4(%esp),%eax'
> http://www.felixcloutier.com/x86/SARX:SHLX:SHRX.html

Could be a bug in the old Apple as.  However, the testcase is fishy in
explicitly passing -m16.  For multilibbed x86 targets, that gets
overridden for the non-default multilibs (either with -m32 or m64).

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
As C++ now has standardized attributes, the question is what does the standard
say about whether standard attributes on a template are inherited to
specializations or not, and if the standard is fuzzy about it, what do other
compilers do.

[Bug tree-optimization/82726] ICE in verify_ssa during GIMPLE pass: pcom

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Feb  1 12:00:57 2018
New Revision: 257291

URL: https://gcc.gnu.org/viewcvs?rev=257291=gcc=rev
Log:
Backport from mainline
2017-11-15  Bin Cheng  

PR tree-optimization/82726
PR tree-optimization/70754
* tree-predcom.c (order_drefs_by_pos): New function.
(combine_chains): Move code setting has_max_use_after to...
(try_combine_chains): ...here.  New parameter.  Sort combined chains
according to position information.
(tree_predictive_commoning_loop): Update call to above function.
(update_pos_for_combined_chains, pcom_stmt_dominates_stmt_p): New.

testsuite

Backport from mainline
2017-11-15  Bin Cheng  

PR tree-optimization/82726
* gcc.dg/tree-ssa/pr82726.c: New test.

Backport from mainline
2017-01-23  Bin Cheng  

PR tree-optimization/70754
* gfortran.dg/pr70754.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr82726.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70754.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-predcom.c

[Bug tree-optimization/70754] [6 Regression] ICE during predictive commoning

[amker at gcc dot gnu.org]

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

--- Comment #21 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Feb  1 12:00:57 2018
New Revision: 257291

URL: https://gcc.gnu.org/viewcvs?rev=257291=gcc=rev
Log:
Backport from mainline
2017-11-15  Bin Cheng  

PR tree-optimization/82726
PR tree-optimization/70754
* tree-predcom.c (order_drefs_by_pos): New function.
(combine_chains): Move code setting has_max_use_after to...
(try_combine_chains): ...here.  New parameter.  Sort combined chains
according to position information.
(tree_predictive_commoning_loop): Update call to above function.
(update_pos_for_combined_chains, pcom_stmt_dominates_stmt_p): New.

testsuite

Backport from mainline
2017-11-15  Bin Cheng  

PR tree-optimization/82726
* gcc.dg/tree-ssa/pr82726.c: New test.

Backport from mainline
2017-01-23  Bin Cheng  

PR tree-optimization/70754
* gfortran.dg/pr70754.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr82726.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70754.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-predcom.c

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Stranger and stranger. Not only does the removal of a line in a subroutine that
is not called make the testcase work but explicitly using the subroutine to do
the allocation works as well:

module test_case

  implicit none

  type :: array_t
 integer, dimension(:), allocatable :: child
   contains
 procedure :: write_raw => particle_write_raw
 procedure :: read_raw => particle_read_raw
  end type array_t

  type :: container_t
 type(array_t), dimension(:), allocatable :: array
  end type container_t

contains

  subroutine proc ()
type(container_t) :: container
integer :: unit, child

allocate (container%array(1))
!allocate (container%array(1)%child (1), source = [2])
call container%array(1)%read_raw ()

unit = 33
open (unit, action="readwrite", form="unformatted", status="scratch")
print *, 1
call container%array(1)%write_raw (unit)
print *, 2
rewind (unit)
read(unit) child
print *, "value from scratch file = ", child
  end subroutine proc

  subroutine particle_write_raw (array, u)
class(array_t), intent(in) :: array
integer, intent(in) :: u
write (u) array%child
  end subroutine particle_write_raw

  subroutine particle_read_raw (array)
class(array_t), intent(out) :: array
allocate (array%child (1), source = [99])! comment this out
  end subroutine particle_read_raw

end module test_case

program main
  use test_case
  call proc ()
  end program main

I have taken it, although I might need help from you Thomas since I rather
suspect something is bad in the i/o library.

Paul

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #19 from Paul Thomas  ---
I had better take this one :-(

This works as intended:

  subroutine vamp_equivalence_write (eq, unit)
integer, intent(in), optional :: unit
integer :: u
type(vamp_equivalence_t), intent(in) :: eq
integer, dimension(:), pointer :: permutation! copy the component
allocate (permutation, source = eq%permutation)  ! here and all is well
u = 6;  if (present (unit))  u = unit
write (u, "(5x,A,99(1x,I0))") "Permutation:", permutation ! for IO
deallocate (permutation)
  end subroutine vamp_equivalence_write

Paul

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I've just checked a x86_64-apple-darwin11.4.2 build: the test PASSes for
-m64, but FAILs for -m32 with

/var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//cchNxmiW.s:7:no such
instruction: `shrx %eax, 4(%esp),%eax'

[Bug c/84166] New: Wrong warning message emitted for loss of qualifiers

[ttsiodras at gmail dot com]

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

Bug ID: 84166
   Summary: Wrong warning message emitted for loss of qualifiers
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ttsiodras at gmail dot com
  Target Milestone: ---

The code shown below...

#include 
#include 

extern void get_buffer_from_HW_driver(volatile uint32_t **p);

void getBuffer(volatile uint32_t **pp)
{
// Write an address into p, that is obtained from a driver
// The underlying HW will be DMA-ing into this address,
// so the data pointed-to by the pointer returned by this
// call are volatile.
get_buffer_from_HW_driver(pp);
}

void work()
{
uint32_t *p = NULL;
getBuffer((volatile uint32_t **));
}

...is erroneously forgetting to set the `volatile` qualifier for the pointer
`p` declared in `work`. Unfortunately, GCC's related warning indicates that
there is a missing `const` - instead of a missing `volatile`:

$ gcc -c -Wall -Wextra -Wcast-qual constqual.c

constqual.c: In function ‘work’:
constqual.c:20:15: warning: to be safe all intermediate pointers in cast
from 
   ‘uint32_t ** {aka unsigned int **}’ to ‘volatile uint32_t ** 
   {aka volatile unsigned int **}’ must be ‘const’ qualified
   [-Wcast-qual]
 getBuffer((volatile uint32_t **));
   ^

It appears that GCC confuses `const` with `volatile` here.

[Bug c++/84162] Internal compiler error: in tsubst, at cp/pt.c:13617 / SEGFAULT

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-01
  Known to work||8.0.1
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
So fixed?  Or is this a regression or worth fixing anyways?  Confirmed for GCC
7 b ranch head.

[Bug middle-end/81812] [7/8 Regression] Empty virtual function fails to compile

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #8 from Jan Hubicka  ---
Martin,
I seem to recall that this was related to icf trying to merge variadic
function. Would it be possible to work out the patch that fixed this?

[Bug tree-optimization/81661] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5638

[jakub at gcc dot gnu.org]

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

Bug 84117 Summary: [8 Regression] ICE in gimplify_modify_expr, at 
gimplify.c:5798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117

   What|Removed |Added

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

[Bug target/83845] [8 regression] new failures after r256620

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Feb  1 11:02:52 2018
New Revision: 257285

URL: https://gcc.gnu.org/viewcvs?rev=257285=gcc=rev
Log:
[AArch64] Tighten aarch64_secondary_reload condition (PR 83845)

aarch64_secondary_reload enforced a secondary reload via
aarch64_sve_reload_be for memory and pseudo registers, but failed
to do the same for subregs of pseudo registers.  To avoid this and
any similar problems, the patch instead tests for things that the move
patterns handle directly; if the operand isn't one of those, we should
use the reload pattern instead.

The patch fixes an ICE in sve/mask_struct_store_3.c for aarch64_be,
where the bogus target description was (rightly) causing LRA to cycle.

2018-02-01  Richard Sandiford  

gcc/
PR tearget/83845
* config/aarch64/aarch64.c (aarch64_secondary_reload): Tighten
check for operands that need to go through aarch64_sve_reload_be.

Reviewed-by: James Greenhalgh 

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

[Bug target/82795] [7 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 CC||dmalcolm at gcc dot gnu.org
 Resolution|FIXED   |---
   Target Milestone|8.0 |7.4
Summary|[8 Regression] ICE in   |[7 Regression] ICE in
   |predicate_mem_writes, at|predicate_mem_writes, at
   |tree-if-conv.c:2251 |tree-if-conv.c:2251

--- Comment #7 from David Malcolm  ---
You closed out PR 84152 with:
> A dup of PR82795.  Forgot to backport that it seems :/

Hence reopening this one and marking for gcc-7-branch.

[Bug web/84167] New: bugzilla should have a "next bug" button

[rguenth at gcc dot gnu.org]

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

Bug ID: 84167
   Summary: bugzilla should have a "next bug" button
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: LpSolit at netscape dot net
  Target Milestone: ---

I'm currently using the web gcc-bug mailinglist archive to cycle through all
new bugs each morning.  It would be much easier to do and to keep track where I
left if there were a "next bug by ID" button somewhere (right next to the "Bug
ID" link at the top?).

Probably doable on the client side somehow but my web-fu isn't great enough to
do that ;)

[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code

[renlin at gcc dot gnu.org]

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

--- Comment #1 from Renlin Li  ---
Author: renlin
Date: Thu Feb  1 13:02:24 2018
New Revision: 257294

URL: https://gcc.gnu.org/viewcvs?rev=257294=gcc=rev
Log:
[PR83370][AARCH64]Use tighter register constraint for sibcall patterns.

In aarch64 backend, ip0/ip1 register will be used in the prologue/epilogue as
temporary register.

When the compiler is performing sibcall optimization. It has the chance to use
ip0/ip1 register for indirect function call to hold the address. However,
those two register might be clobbered by the epilogue code which makes the
last sibcall instruction invalid.

The patch here renames the register class CALLER_SAVE_REGS to
TAILCALL_ADDR_REGS
to reflect its usage, and remove IP registers from this class.

gcc/

2018-02-01  Renlin Li  

PR target/83370
* config/aarch64/aarch64.c (aarch64_class_max_nregs): Handle
TAILCALL_ADDR_REGS.
(aarch64_register_move_cost): Likewise.
* config/aarch64/aarch64.h (reg_class): Rename CALLER_SAVE_REGS to
TAILCALL_ADDR_REGS.
(REG_CLASS_NAMES): Likewise.
(REG_CLASS_CONTENTS): Rename CALLER_SAVE_REGS to
TAILCALL_ADDR_REGS. Remove IP registers.
* config/aarch64/aarch64.md (Ucs): Update register constraint.

gcc/testsuite/

2018-02-01  Richard Sandiford  

PR target/83370
* gcc.target/aarch64/pr83370.c: New.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr83370.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.h
trunk/gcc/config/aarch64/constraints.md
trunk/gcc/testsuite/ChangeLog

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
The problem still exists, and according to gcc-testresults the test
FAILs on i386-pc-solaris2.11, x86_64-pc-solaris2.11,
x86_64-apple-darwin15.6.0, i686-pc-linux-gnu, and x86_64-pc-linux-gnu.

Should I rather open a new PR for this?

Rainer

[Bug rtl-optimization/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug c/77331] incorrect range location in -Wformat with a concatenated format literal

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Michał Mirosław from comment #1)
> This looks similar (related to PR#52952?): when showing error for
> concatenated format string, caret does not point to the triggering format.

If you replace the '#' with a space, bugzilla will autolink the bug: PR 52952

[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

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

--- Comment #2 from Renlin Li  ---
fix has been commit in trunk.

[Bug target/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Testing a patch.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jason at redhat dot com]

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

--- Comment #17 from Jason Merrill  ---
On Wed, Jan 31, 2018 at 9:45 PM, msebor at gcc dot gnu.org
 wrote:
> Jason, I'm only starting to look into it but if I understand your suggestion
> correctly, I don't think the bug can be fixed by relying on attribute
> exclusions.
>
> Based on the test cases alone (I haven't yet stepped through the code) the
> underlying problem seems to be that explicit specializations "inherit"
> attributes from their primary template rather than starting with a clean 
> slate.

Often that will be correct; I don't think we want to require people to
repeat all attributes on every explicit specialization.  The problem
here is that there's a conflicting attribute on the specialization,
and we want that to win, so I'm suggesting that when we see that, we
go through and remove conflicting attributes which came from the
template.

[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #23 from Thomas Koenig  ---
I just tested it with current trunk and gcc 7.  It is fixed.

Closing.

[Bug middle-end/28831] [6/7/8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[aldyh at gcc dot gnu.org]

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

--- Comment #32 from Aldy Hernandez  ---
errr, slightly LESS worse code

[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist  ---
Author: jb
Date: Thu Feb  1 19:47:15 2018
New Revision: 257310

URL: https://gcc.gnu.org/viewcvs?rev=257310=gcc=rev
Log:
PR 83975 Associate target with non-constant character length

When associating a variable of type character, if the length of the
target isn't known at compile time, generate an error. See PR 83344
for more details.

Regtested on x86_64-pc-linux-gnu.

gcc/fortran/ChangeLog:

2018-02-01  Janne Blomqvist  

PR 83975
PR 83344
* resolve.c (resolve_assoc_var): Generate an error if
target length unknown.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[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|NEW |WAITING
 CC||tkoenig at gcc dot gnu.org

--- Comment #17 from Thomas Koenig  ---
(In reply to janus from comment #15)
> (In reply to Dominique d'Humieres from comment #14)
> > AFAICT the above piece of dump appeared between revisions r241883
> > (2016-11-06, none) and r241924 (2016-11-07, present), likely r241885.
> 
> Yes, very likely. Thanks for pinpointing this, Dominique.
> 
> 
> > If I
> > am correct, I am not sure that the commit qualifies for back port.
> 
> Andre, do you think it would be reasonable to backport r241885?

I think this is a bit too invasive.

My vote would be to close this as FIXED.

[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2018-01/msg02059.ht |patches/2018-01/msg02469.ht
   |ml  |ml
 Resolution|--- |FIXED

--- Comment #7 from Peter Bergner  ---
Fixed on trunk.  Will wait a few days and then will back port it to FSF 7.

[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Feb  1 18:44:41 2018
New Revision: 257307

URL: https://gcc.gnu.org/viewcvs?rev=257307=gcc=rev
Log:
PR c++/84126 - ICE with variadic generic lambda

PR c++/84036
PR c++/82249
* pt.c (tsubst_pack_expansion): Handle function parameter_packs in
PACK_EXPANSION_EXTRA_ARGS.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Feb  1 18:44:41 2018
New Revision: 257307

URL: https://gcc.gnu.org/viewcvs?rev=257307=gcc=rev
Log:
PR c++/84126 - ICE with variadic generic lambda

PR c++/84036
PR c++/82249
* pt.c (tsubst_pack_expansion): Handle function parameter_packs in
PACK_EXPANSION_EXTRA_ARGS.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Feb  1 18:44:41 2018
New Revision: 257307

URL: https://gcc.gnu.org/viewcvs?rev=257307=gcc=rev
Log:
PR c++/84126 - ICE with variadic generic lambda

PR c++/84036
PR c++/82249
* pt.c (tsubst_pack_expansion): Handle function parameter_packs in
PACK_EXPANSION_EXTRA_ARGS.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug c++/84171] [8 Regression] ICE with -Wsign-compare

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-01
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I'll take a look.

[Bug middle-end/33699] [6/7/8 regression] missing optimization on const addr area store

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-04 00:00:00 |2018-2-1
 CC||aldyh at gcc dot gnu.org

--- Comment #25 from Aldy Hernandez  ---
(In reply to Martin Sebor from comment #23)
> No progress in GCC 7.0 which emits the following code for powerpc64le at -O2
> (-Os is slightly different but the same size):

Same thing on mainline still.

[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[dougmencken at gmail dot com]

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

--- Comment #17 from Douglas Mencken  ---
diff of libgcc/unwind-dw2.c between 6.4 and 7.1

--- a/libgcc/unwind-dw2.c
+++ b/libgcc/unwind-dw2.c
@@ -1,5 +1,5 @@
 /* DWARF2 exception handling and frame unwind runtime interface routines.
-   Copyright (C) 1997-2016 Free Software Foundation, Inc.
+   Copyright (C) 1997-2017 Free Software Foundation, Inc.

This file is part of GCC.

@@ -136,6 +136,8 @@ struct _Unwind_Context
 #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
   /* Context which has version/args_size/by_value fields.  */
 #define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 >> 2) + 1)
+  /* Bit reserved on AArch64, return address has been signed with A key.  */
+#define RA_A_SIGNED_BIT ((~(_Unwind_Word) 0 >> 3) + 1)
   _Unwind_Word flags;
   /* 0 for now, can be increased when further fields are added to
  struct _Unwind_Context.  */
@@ -1185,6 +1187,11 @@ execute_cfa_program (const unsigned char *insn_ptr,
  break;

case DW_CFA_GNU_window_save:
+#if defined (__aarch64__) && !defined (__ILP32__)
+ /* This CFA is multiplexed with Sparc.  On AArch64 it's used to
toggle
+return address signing status.  */
+ fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
+#else
  /* ??? Hardcoded for SPARC register window configuration.  */
  if (__LIBGCC_DWARF_FRAME_REGISTERS__ >= 32)
for (reg = 16; reg < 32; ++reg)
@@ -1192,6 +1199,7 @@ execute_cfa_program (const unsigned char *insn_ptr,
fs->regs.reg[reg].how = REG_SAVED_OFFSET;
fs->regs.reg[reg].loc.offset = (reg - 16) * sizeof (void *);
  }
+#endif
  break;

case DW_CFA_GNU_args_size:
@@ -1513,10 +1521,15 @@ uw_update_context (struct _Unwind_Context *context,
_Unwind_FrameState *fs)
stack frame.  */
 context->ra = 0;
   else
-/* Compute the return address now, since the return address column
-   can change from frame to frame.  */
-context->ra = __builtin_extract_return_addr
-  (_Unwind_GetPtr (context, fs->retaddr_column));
+{
+  /* Compute the return address now, since the return address column
+can change from frame to frame.  */
+  context->ra = __builtin_extract_return_addr
+   (_Unwind_GetPtr (context, fs->retaddr_column));
+#ifdef MD_POST_EXTRACT_FRAME_ADDR
+  context->ra = MD_POST_EXTRACT_FRAME_ADDR (context, fs, context->ra);
+#endif
+}
 }

 static void
@@ -1550,6 +1563,9 @@ uw_init_context_1 (struct _Unwind_Context *context,
   void *outer_cfa, void *outer_ra)
 {
   void *ra = __builtin_extract_return_addr (__builtin_return_address (0));
+#ifdef MD_POST_EXTRACT_ROOT_ADDR
+  ra = MD_POST_EXTRACT_ROOT_ADDR (ra);
+#endif
   _Unwind_FrameState fs;
   _Unwind_SpTmp sp_slot;
   _Unwind_Reason_Code code;
@@ -1586,6 +1602,9 @@ uw_init_context_1 (struct _Unwind_Context *context,
  initialization context, then we can't see it in the given
  call frame data.  So have the initialization context tell us.  */
   context->ra = __builtin_extract_return_addr (outer_ra);
+#ifdef MD_POST_EXTRACT_ROOT_ADDR
+  context->ra = MD_POST_EXTRACT_ROOT_ADDR (context->ra);
+#endif
 }

 static void _Unwind_DebugHook (void *, void *)
@@ -1608,6 +1627,21 @@ _Unwind_DebugHook (void *cfa __attribute__
((__unused__)),
 #endif
 }

+/* Frob exception handler's address kept in TARGET before installing into
+   CURRENT context.  */
+
+static inline void *
+uw_frob_return_addr (struct _Unwind_Context *current
+__attribute__ ((__unused__)),
+struct _Unwind_Context *target)
+{
+  void *ret_addr = __builtin_frob_return_addr (target->ra);
+#ifdef MD_POST_FROB_EH_HANDLER_ADDR
+  ret_addr = MD_POST_FROB_EH_HANDLER_ADDR (current, target, ret_addr);
+#endif
+  return ret_addr;
+}
+
 /* Install TARGET into CURRENT so that we can return to it.  This is a
macro because __builtin_eh_return must be invoked in the context of
our caller.  */
@@ -1616,7 +1650,7 @@ _Unwind_DebugHook (void *cfa __attribute__
((__unused__)),
   do   \
 {  \
   long offset = uw_install_context_1 ((CURRENT), (TARGET));   
\
-  void *handler = __builtin_frob_return_addr ((TARGET)->ra);   \
+  void *handler = uw_frob_return_addr ((CURRENT), (TARGET));   \
   _Unwind_DebugHook ((TARGET)->cfa, handler);  \
   __builtin_eh_return (offset, handler);   \
 }  \

[Bug c++/84160] [8 Regression] ICE on valid C++11 code: in build_capture_proxy, at cp/lambda.c:446

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/83344] Use of uninitialized memory with ASSOCIATE and strings

[jb at gcc dot gnu.org]

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

--- Comment #11 from Janne Blomqvist  ---
Author: jb
Date: Thu Feb  1 19:47:15 2018
New Revision: 257310

URL: https://gcc.gnu.org/viewcvs?rev=257310=gcc=rev
Log:
PR 83975 Associate target with non-constant character length

When associating a variable of type character, if the length of the
target isn't known at compile time, generate an error. See PR 83344
for more details.

Regtested on x86_64-pc-linux-gnu.

gcc/fortran/ChangeLog:

2018-02-01  Janne Blomqvist  

PR 83975
PR 83344
* resolve.c (resolve_assoc_var): Generate an error if
target length unknown.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #24 from Dominique d'Humieres  ---
Still failing at r257125 when the test is compiled with -fsanitize=address.

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
-fsanitize=address gives:


==21482==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00402624 at pc 0x7f6d755ede76 bp 0x7ffed65778c0 sp 0x7ffed6577070
READ of size 5 at 0x00402624 thread T0
#0 0x7f6d755ede75 in __interceptor_memmove
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:720
#1 0x40134d in gfcbug145 /tmp/foo.f90:14
#2 0x402323 in main /tmp/foo.f90:17
#3 0x7f6d745f6f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#4 0x400c89 in _start (/tmp/a.out+0x400c89)

0x00402624 is located 60 bytes to the left of global variable '*.LC6'
defined in 'foo.f90' (0x402660) of size 5
0x00402624 is located 0 bytes to the right of global variable '*.LC5'
defined in 'foo.f90' (0x402620) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:720
in __interceptor_memmove
Shadow bytes around the buggy address:
  0x80078470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078490: 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9
  0x800784a0: f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x800784b0: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
=>0x800784c0: f9 f9 f9 f9[04]f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
  0x800784d0: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00
  0x800784e0: f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9 00 00 00 00
  0x800784f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb

This is the   print *,  pack (obstyp% name, mask) line.

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

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2011-02-06 23:54:40 |2018-2-1
 CC||aldyh at gcc dot gnu.org

--- Comment #65 from Aldy Hernandez  ---
Still a problem.  I get a score of 1750.7 on a:

model name  : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

[Bug target/27855] [6/7/8 regression] reassociation causes the RA to be confused

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #54 from Aldy Hernandez  ---
Results from comparing trunk and gcc-4_6-branch on (average of 7 runs):

Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz

4.6.x
-O2 -ffast-math -msse4.1 -DTYPE=double -fno-tree-reassoc
atlasmm   60   1000   0.100 5415.4

-O2 -ffast-math -msse4.1 -DTYPE=double
atlasmm   60   1000   0.082 4797.4

Performance penalty: 12.9%

trunk:
-O2 -ffast-math -msse4.1 -DTYPE=double -fno-tree-reassoc
atlasmm   60   1000   0.105 5217.0

-O2 -ffast-math -msse4.1 -DTYPE=double
atlasmm   60   1000   0.108 4773.0

Performance change: 9.3%

It looks like the penalty for using fno-tree-reassoc now is even less than it
was in 4.6.x.  The original report was for a 30% drop.

Has this been fixed, or am I missing something? (different flags for my 4.6
run?  Is the 4.6 branch not a suitable representation of the 4.6.2 compiler
against which this bug was originally filed against?)

[Bug middle-end/28831] [6/7/8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2010-01-17 13:10:45 |2018-2-1
 CC||aldyh at gcc dot gnu.org

--- Comment #31 from Aldy Hernandez  ---
Still a problem, though we now generate slightly worse code by using rep;movsl
instead of a memcpy:

movl%esp, %esi
subl$12, %esp
pushl   %esi
callf
subl$3988, %esp
movl$1000, %ecx
movl%esp, %edi
rep; movsl
callg

[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[tkoenig at gcc dot gnu.org]

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

--- Comment #25 from Thomas Koenig  ---
Strange, I don't see it; what I get is

ig25@linux-d6cw:/tmp> gfortran -g -fsanitize=address assumed_rank_7.f90 
ig25@linux-d6cw:/tmp> ./a.out

=
==21952==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fa951f6cf30 in __interceptor_malloc
../../../../trunk/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x4013fc in MAIN__ /tmp/assumed_rank_7.f90:18
#2 0x40333b in main /tmp/assumed_rank_7.f90:25
#3 0x7fa950ec3f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)

SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s).

... but the memory leak from an allocate in the main program is
something else

I also don't see anything with valgrind.

Can you post your output?

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner  ---
Author: bergner
Date: Thu Feb  1 18:26:51 2018
New Revision: 257305

URL: https://gcc.gnu.org/viewcvs?rev=257305=gcc=rev
Log:
PR target/56010
PR target/83743
* config/rs6000/driver-rs6000.c: #include "diagnostic.h".
#include "opts.h".
(rs6000_supported_cpu_names): New static variable.
(linux_cpu_translation_table): Likewise.
(elf_platform) : Define new static variable and use it.
Translate kernel AT_PLATFORM name to canonical name if needed.
Error if platform name is unknown.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/driver-rs6000.c

[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
Author: bergner
Date: Thu Feb  1 18:26:51 2018
New Revision: 257305

URL: https://gcc.gnu.org/viewcvs?rev=257305=gcc=rev
Log:
PR target/56010
PR target/83743
* config/rs6000/driver-rs6000.c: #include "diagnostic.h".
#include "opts.h".
(rs6000_supported_cpu_names): New static variable.
(linux_cpu_translation_table): Likewise.
(elf_platform) : Define new static variable and use it.
Translate kernel AT_PLATFORM name to canonical name if needed.
Error if platform name is unknown.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/driver-rs6000.c

[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I think combine is at fault here. The faulty assembly is:
foo:
ldrbw0, [sp, 16]
neg x0, x0, lsl 4
csetm   x3, ne


The csetm is supposed to set the top 64 bits of the TImode value (in x3) to
ones, based on the CC content, but the CC-setting instruction has disappeared.
The correct sequence (by hacking the assembly output and checking that it
passes) would be:
ldrbw0, [sp, 16]
negs x0, x0, lsl 4 // NEG sets the condition code as well.
csetm   x3, ne

There's a few complex combinations going on, but before combine we have (some
RTL edited to tone down verbosity):

(insn 14 12 17 2 (set (reg:DI 87)
(lshiftrt:DI (reg:DI 103)
(const_int 60 [0x3c]))) "wrong.c":9 676
{*aarch64_lshr_sisd_or_int_di3}
(insn 19 17 20 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (reg:DI 85)
(reg:DI 105)))
(set (reg:DI 90)
(minus:DI (reg:DI 85)
(reg:DI 105)))
]) "wrong.c":9 270 {subdi3_compare1}

(insn 20 19 23 2 (set (reg:DI 91)
(minus:DI (minus:DI (reg:DI 85)
(reg:DI 87))
(ltu:DI (reg:CC 66 cc)
(const_int 0 [0] "wrong.c":9 327 {*subdi3_carryin}

where insn 19 sets the CC and insn 20 uses it. After combine we have:
(insn 14 12 17 2 (set (reg:DI 87)
(lshiftrt:DI (reg:DI 103)
(const_int 60 [0x3c]))) "wrong.c":9 676
{*aarch64_lshr_sisd_or_int_di3}
(note 19 17 20 2 NOTE_INSN_DELETED)
(insn 20 19 23 2 (set (reg:DI 91)
(neg:DI (ne:DI (reg:CC 66 cc)
(const_int 0 [0] "wrong.c":9 441 {cstoredi_neg}

with insn 20 still using the CC but the CC setting instruction being deleted.
There's a number of exciting things going on in combine so my analysis may not
be entirely accurate, but I see things like:
Trying 14 -> 20:
   14: r87:DI=r103:DI 0>>0x3c
   20: r91:DI=r85:DI-r87:DI-ltu(cc:CC,0)
  REG_DEAD r87:DI
  REG_DEAD r85:DI
  REG_DEAD cc:CC
  REG_EQUAL -r87:DI-ltu(cc:CC,0)
Successfully matched this instruction:
(set (reg:DI 91)
(neg:DI (ltu:DI (reg:CC 66 cc)
(const_int 0 [0]

and

Trying 19 -> 26:
   19: cc:CC=cmp(r103:DI,0)
  REG_DEAD r103:DI
   26:
{cc:CC_C=zero_extend(r90:DI)+zero_extend(r111:DI)!=zero_extend(r90:DI+r111:DI);r95:DI=r90:DI+r111:DI;}
  REG_DEAD r111:DI
  REG_DEAD r90:DI
Successfully matched this instruction:
(parallel [
(set (reg:CC_C 66 cc)
(ne:CC_C (plus:TI (zero_extend:TI (reg:DI 90))
(zero_extend:TI (reg:DI 111 [ b ])))
(zero_extend:TI (plus:DI (reg:DI 90)
(reg:DI 111 [ b ])
(set (reg:DI 95)
(plus:DI (reg:DI 90)
(reg:DI 111 [ b ])))
])
deferring deletion of insn with uid = 19.

So insn 19 ends up being combined into a subsequent instruction and ends up
being deleted even though insn 20 depends on it's CC-setting effects

[Bug fortran/68560] [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #26 from Thomas Koenig  ---
I have a patch.

[Bug fortran/79886] [6 Regression] ICE in pp_format, at pretty-print.c:681

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #9 from Thomas Koenig  ---
Any plans to backport to gcc-6?

If not, I think we can close this.

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2018-01/msg02059.ht |patches/2018-01/msg02469.ht
   |ml  |ml
 Resolution|--- |FIXED

--- Comment #12 from Peter Bergner  ---
Fixed on trunk.  Will wait a few days and then will back port it to FSF 7.

[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug web/84167] bugzilla should have a "next bug" button

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Frédéric Buclin  ---
(In reply to Richard Biener from comment #0)
> I'm currently using the web gcc-bug mailinglist archive to cycle through all
> new bugs each morning.

Instead of doing this, you should click the "Bugs reported in the last 24
hours" link on the Bugzilla home page. This will generate a list, and the
Prev/Next link will automatically appear on each bug page.

[Bug c++/84171] New: [8 Regression] ICE with -Wsign-compare

[reichelt at gcc dot gnu.org]

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

Bug ID: 84171
   Summary: [8 Regression] ICE with -Wsign-compare
   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
CC: jason at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE on trunk if compiled
with -Wsign-compare (included in -Wall):

=
bool foo (char c)
{
  const int i = 0 = 0;
  return c = i;
}
=

bug.cc: In function 'bool foo(char)':
bug.cc:3:21: error: lvalue required as left operand of assignment
   const int i = 0 = 0;
 ^
bug.cc:4:14: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in warn_for_sign_compare, at c-family/c-warn.c:1926
   return c = i;
  ^
0x788cda tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9375
0x689286 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3255
0x689286 warn_for_sign_compare(unsigned int, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_code)
../../gcc/gcc/c-family/c-warn.c:1926
0x9dae42 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/gcc/cp/typeck.c:5324
0x86e4c1 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/gcc/cp/cvt.c:812
0x86fa1e cp_convert(tree_node*, tree_node*, int)
../../gcc/gcc/cp/cvt.c:623
0x86fa1e cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/gcc/cp/cvt.c:642
0x81de78 convert_like_real
../../gcc/gcc/cp/call.c:7111
0x81eb5f perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:10574
0x9e22aa check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:9371
0x99cf2e finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:890
0x91a054 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12368
0x91a054 cp_parser_statement
../../gcc/gcc/cp/parser.c:10773
0x91add0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11218
0x91aea7 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11172
0x931630 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21710
0x931630 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21747
0x931ee0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26648
0x932bf7 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26564
0x932bf7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19436
Please submit a full bug report, [etc.]

Jason, the regression started with your patch
https://gcc.gnu.org/viewcvs?rev=249083=gcc=rev

Would you mind having a look?

[Bug target/29256] [6/7/8 regression] loop performance regression

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2013-12-09 04:50:02 |2018-2-1
 CC||aldyh at gcc dot gnu.org

--- Comment #65 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #45)
> This problem still exists and can be seen by making the arrays external and
> using -fno-tree-loop-distribute-patterns.
> 
> .L2:
> evlddx 31,10,9
> addi 7,9,8
> addi 0,9,16
> addi 11,9,24
> addi 3,9,32
> evstddx 31,8,9
> addi 4,9,40
> evlddx 31,10,7
> addi 5,9,48
> addi 6,9,56
> evlddx 12,10,6
> addi 9,9,64
> evstddx 31,8,7
> evlddx 7,10,0
> evstddx 7,8,0
> evlddx 0,10,11
> evstddx 0,8,11
> evlddx 11,10,3
> evstddx 11,8,3
> evlddx 3,10,4
> evstddx 3,8,4
> evlddx 4,10,5
> evstddx 4,8,5
> evstddx 12,8,6
> bdnz .L2
> evldd 31,8(1)
> addi 1,1,16
> blr

Still a problem.  I get the same code Jeff got for comment 45.

[Bug fortran/46496] Missing strlen check / interop warnings with BIND(C) and non-C_* kinds

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Tobias Burnus from comment #0)

> f) The following two examples are invalid - but seemingly gfortran does not
> check the string length of DT character components:
> 
> module mytypes
>use ISO_C_BINDING
>implicit none
>private
>public T
>type, bind(C) :: T
>   character(len=2,kind=C_CHAR) item ! INVALID length: 2
>end type T
> end module mytypes
> 
> module mytypes
>use ISO_C_BINDING
>implicit none
>private
>public T
>type, bind(C) :: T
>   character(len=*,kind=C_CHAR) item*(2) ! INVALID length of 2
>end type T
> end module mytypes

This has been fixed with PR84073.

[Bug target/68028] [6/7/8 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #9 from Nick Clifton  ---
Created attachment 43318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43318=edit
Proposed patch

Hi Guys,

Richard was right - there is code that sets extra flags based upon the setting
of -mcpu.  In fact it is just before the code he mentioned:

 /* For the E500 family of cores, reset the single/double FP flags to let us
 check that they remain constant across attributes or pragmas.  */

  switch (rs6000_cpu)
{
case PROCESSOR_PPC8540:
case PROCESSOR_PPC8548:
case PROCESSOR_PPCE500MC:
case PROCESSOR_PPCE500MC64:
case PROCESSOR_PPCE5500:
case PROCESSOR_PPCE6500:
  rs6000_single_float = 0;
  rs6000_double_float = 0;
  break;

default:
  break;
}

This has lead me to propose the attached patch.  Basically what it does is to
tell the rs6000 backend that when it is operating in LTO mode, it should trust
the function attributes and not the command line. 

My assumption here is that if there are any discrepancies between real 
function attributes (ie not ones generated for LTO) and the command line,
then these will have been detected and reported during the original 
compilation.

What do people think ?  Is the patch OK ?

Cheers
  Nick

[Bug target/84128] i686: Stack spilling in -fstack-clash-protection prologue neglects %esp change

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/84128] i686: Stack spilling in -fstack-clash-protection prologue neglects %esp change

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Thu Feb  1 16:22:56 2018
New Revision: 257303

URL: https://gcc.gnu.org/viewcvs?rev=257303=gcc=rev
Log:
PR target/84128
* config/i386/i386.c (release_scratch_register_on_entry): Add new
OFFSET and RELEASE_VIA_POP arguments.  Use SP+OFFSET to restore
the scratch if RELEASE_VIA_POP is false.
(ix86_adjust_stack_and_probe_stack_clash): Un-constify SIZE.
If we have to save a temporary register, decrement SIZE appropriately.
Pass new arguments to release_scratch_register_on_entry.
(ix86_adjust_stack_and_probe): Likewise.
(ix86_emit_probe_stack_range): Pass new arguments to
release_scratch_register_on_entry.

PR target/84128
* gcc.target/i386/pr84128.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr84128.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c/84166] Wrong warning message emitted for loss of qualifiers

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
It's not confused.  It's saying that it's type-safe to convert 
"uint32_t **" to "volatile uint32_t *const *", but not to convert it to 
"volatile uint32_t *".

http://c-faq.com/ansi/constmismatch.html

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #11 from Peter Bergner  ---
I have two patches 1) modify gen_[u]divdi3() to handle calling the lib func
__[u]divdi3 when needed and 2) Call expand_divmod() in the vsx_[u]div_v2di
splitters.  I'm evaluating which generates better code.

[Bug debug/83935] DWARF for a variant part is incorrect

[derodat at adacore dot com]

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

--- Comment #6 from Pierre-Marie de Rodat  ---
Just got a notification that it got assigned issue #180123.1:
http://dwarfstd.org/ShowIssue.php?issue=180123.1

[Bug c++/83796] [6/7 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] Abstract |[6/7 Regression] Abstract
   |classes allowed to be   |classes allowed to be
   |instantiated when   |instantiated when
   |initialised as default  |initialised as default
   |parameter to function or|parameter to function or
   |constructor |constructor

--- Comment #6 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #11 from Uroš Bizjak  ---
Fixed.

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I tested the modified C++ 11 example below with Clang, EDG, GCC, ICC, and MSVC.
 Of these, only MSVC implements the behavior I expect and doesn't warn.  The
others do.  (I verified that MSVC does support the attribute.)

Still, given that it's obviously meaningful to define a specialization that
does return, treating it as noreturn based on the definition of the primary is
incorrect.

Given the difference among implementations I think the standard ought to be
clarified which of the two is intended.

(See https://godbolt.org/g/sYPbD2 for Clang and MSVC output.)

template 
[[noreturn]] T
g (T) { throw "not implemented"; }

template <> int
g (int) { return 0; }

int h (int i)
{
  return g (i);
}

[Bug target/84169] New: [8 Regression] wrong code with u128 multiplication result at aarch64 -O

[zsojka at seznam dot cz]

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

Bug ID: 84169
   Summary: [8 Regression] wrong code with u128 multiplication
result at aarch64 -O
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Output:
$ aarch64-unknown-linux-gnu-gcc testcase.c -static -O
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

The most-significant 64bit are zeros, but should be ones.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-257303-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-257303-checking-yes-rtl-df-extra-aarch64
Thread model: posix
gcc version 8.0.1 20180201 (experimental) (GCC)

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[bergner at gcc dot gnu.org]

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

--- Comment #10 from Peter Bergner  ---
A similar error happens with the __builtin_vsx_udiv_2di() that happens with
__builtin_vsx_div_2di(), which shows the splitter for vsx_udiv_v2di calling
gen_udivdi3() directly:

[bergner@makalu-lp1 PR83926]$ cat udiv.i 
__attribute__ ((altivec(vector__))) unsigned long long
foo (__attribute__ ((altivec(vector__))) unsigned long long a,
 __attribute__ ((altivec(vector__))) unsigned long long b)
{
  return __builtin_vsx_udiv_2di (a, b);
}
[bergner@makalu-lp1 PR83926]$
/home/bergner/gcc/build/gcc-fsf-mainline-pr83926-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr83926-debug/gcc -S -mcpu=power8
-O1 -m32 -mno-fold-gimple udiv.i 
gimple folding of rs6000 builtins has been disabled.
udiv.i: In function ‘foo’:
udiv.i:6:1: error: unrecognizable insn:
 }
 ^
(insn 16 15 17 2 (set (reg:DI 127)
(udiv:DI (reg:DI 125)
(reg:DI 126))) "udiv.i":6 -1
 (nil))
during RTL pass: subreg2
udiv.i:6:1: internal compiler error: in extract_insn, at recog.c:2304
0x10ddd69f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/bergner/gcc/gcc-fsf-mainline-pr83926/gcc/rtl-error.c:108

[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'

[uros at gcc dot gnu.org]

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

--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb  1 16:04:18 2018
New Revision: 257302

URL: https://gcc.gnu.org/viewcvs?rev=257302=gcc=rev
Log:
PR rtl-optimization/84157
* combine.c (change_zero_ext): Use REG_P predicate in
front of HARD_REGISTER_P predicate.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

Your Weekly Breeze - February. 01 - February. 07

[Oasis Living Magazine]

This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
http://ymlptrack7.com/zwbctq



Having problems viewing  Weekly Breeze Click here (
http://myoasisliving.com/weekly_breeze/weekly_breeze.php ).

>> ( y )

-->

Feeling bloated after too much turkey and plates of mince pies? Get
into the shape of your life in 2018 with a new fitness regime – here
are some helpful expert tips >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/b53a230d6e6d918b0a7f1526b2dedefa
)

The end of last year saw the 21st Faldo Series Grand Final tee up
in Al Ain’s AESGC, bringing Sir Nick himself to the greens. Oasis
Living was lucky enough to have a chat with a living legend >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/fac8c74f2e95c9cb9c7741faf6748425
)

Al Ain Rugby Club activities in full swing >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/2d6476579c954312447ad6df5fb08e4c
)

Abu Dhabi set to host over 4,000 tri-athletes on one of the most
unique triathlon courses in the world >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/36d37ef8f848677bebb848d561055902
)

A once-in-a-lifetime opportunity bounces in for youth basketball
players worldwide >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/4fea2c60a18b5d7a466458f897ede786
)

Eighth edition of Abu Dhabi’s famed community sporting event to
take place in February 2018 >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/1df55ebf7501156898d6b16f4e415cc8
)

breeze@ myoasisliving.com for your chance to win aHanayen gift voucher
in Bawadi Mall worth Dh100. To win, simply email your complete name
and indicate Hanayenin the subject and you will qualify for a random
draw.

*If you win, you have 30 days to pick up your prize. If your prize is
not collected within 30 days of notification, it will be cancelled.
Participants who have won before are not eligible to win again within
90 days after winning

-->
www.nascintl.com.

Al Nada Beauty Salon will be having a 50% discount on beauty and hair
services for the first 10 days of Ramadan. Al Nada Beauty Salon
timings will be 10:30 a.m. until 2 p.m. and 8 p.m. until 12 a.m. For
appointments and inquiries call 03-7664017.

-->

Money matters
Looking to create a financial plan for 2018 but don’t know where to
start? Oasis Living chats with expert Catalin Voicu for some insights
– as VAT rolls into the UAE >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/710718018521202fc85448c2b2c1976f
)

What’s hot in health?
Abu Dhabi’s Intercare Wellness Consultants, Dr Nas Al-Jafari and Dr
Mourad Habib, predict some of the wellness trends you will be seeing
everywhere this year >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/46e5535e8caf136bbebd41547cb67aa1
)

What to expect in 2018
Six new things coming to the UAE this year >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/9183cbcbf2b3187e12154b1401ef156b
)

2017 in search
Google releases most trending searches in the UAE of last year >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/175b84862b37613ad8bcd2a6b8b19a56
)

Greener pastures
GCC's first vertical farm launches in Dubai >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/15d9bb997af04708d42e8499fe699a9b
)

Omar Abdulrahman says Al Ain target three points against Al Jazira 'to
get back on a better footing'

Al Ain are out to restore their battered pride when they meet Arabian
Gulf League leaders Al Jazira in their rescheduled Round 1 match on
Monday at the Hazza bin Zayed Stadium. >> (
http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dna/opt/local_news_catch/offset/15
)

Al Ain in talks with 'two potential' replacements for Zlatko Dalic,
with Jorge da Silva one of them

Al Ain say they are yet to finalise a replacement for departed
manager Zlatko Dalic but "are in talks" with two candidates with
experience in the Arabian Gulf League. >> (
http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dn8/opt/local_news_catch/offset/0
)

Zlatko Dalic to depart Al Ain after Al Jazira defeat: 'Thanks for
three great years'

Al Ain manager Zlatko Dalic is leaving the Garden City club after
more than two years in charge following their 3-1 defeat at home to Al
Jazira on Monday night. >> (
http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dn9/opt/local_news_catch/offset/5
)

Get a recap ( ALDAR Young Chef Award : March 14, 2017 )

This year’s ALDAR Young Chef Award, held in collaboration with the
local Ayla hotels, saw talented students present some of their finest
dishes for a panel of judges 

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez  ---
Author: aldyh
Date: Thu Feb  1 17:12:28 2018
New Revision: 257304

URL: https://gcc.gnu.org/viewcvs?rev=257304=gcc=rev
Log:
PR target/84089
* config/pa/predicates.md (base14_operand): Handle E_VOIDmode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/predicates.md

[Bug ipa/80899] [6/7/8 Regression] Devirtualization causes incorrect code generation with placement new in some cases

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #4)
> Is this valid C++? bar.mem is non-POD and is already constructed and it
> seems fishy to placement new it to something different.

It's very fishy; the code should use aligned_storage rather a different
non-trivial type.  My old proposed resolution for wg21.link/cwg1116 would have
clarified that this is undefined, and might still happen to resolve
wg21.link/cwg1027 , but it hasn't been accepted yet.

On the other hand, it is careful to use the pointer returned from placement new
rather than a pointer derived from mem, and it seems like we ought to use the
information from placement new to guide devirtualization.

So...sketchy code in a volatile area of semantics, but it seems like we could
get it right without breaking important optimizations.

[Bug c++/83796] [6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Feb  1 15:36:04 2018
New Revision: 257298

URL: https://gcc.gnu.org/viewcvs?rev=257298=gcc=rev
Log:
/cp
2018-02-01  Paolo Carlini  

PR c++/83796
* call.c (convert_like_real): If w're initializing from {} explicitly
call abstract_virtuals_error_sfinae.

/testsuite
2018-02-01  Paolo Carlini  

PR c++/83796
* g++.dg/cpp0x/abstract-default1.C: New.

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

[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-01
 CC||ktkachov at gcc dot gnu.org
  Known to work||7.3.1
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #2)
> I actually think it is the right thing that the attributes from templates
> are inherited by specializations.

That cannot be correct.  Because there is no way to remove an attribute from a
declaration such a design would make it impossible to declare a specialization
that differed from the primary.

Here's a modified example that should bring the problem into focus:

template  T __attribute__ ((noreturn)) f (T) { __builtin_abort (); }

template <> int f (int) { return 0; }   // bogus warning here

int g (int i)
{
  f (i);   // missing -Wreturn-type
}
t.C: In function ‘T f(T) [with T = int]’:
t.C:3:34: warning: function declared ‘noreturn’ has a ‘return’ statement
 template <> int f (int) { return 0; }
  ^
t.C:3:34: warning: ‘noreturn’ function does return

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #3)
> As C++ now has standardized attributes, the question is what does the
> standard say about whether standard attributes on a template are inherited
> to specializations or not, and if the standard is fuzzy about it, what do
> other compilers do.

To my reading the standard doesn't specify attributes with enough detail to
answer the question, but inheriting attributes wouldn't make sense.  For
another example, consider class templates and alignas:

  template 
  struct alignas (32) A { T a; };

  template <>
  struct A { char c; };

  static_assert (alignof (A) < 32, "alignof A < 32");

This passes with all compilers I tried, including Clang, GCC, ICC, and MSVC. 
It would be most surprising if the rules for class templates were different
than for function templates.

[Bug libstdc++/84170] New: std::find_if performance issues

[barannikov88 at gmail dot com]

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

Bug ID: 84170
   Summary: std::find_if performance issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barannikov88 at gmail dot com
  Target Milestone: ---

Hi,

There are two internal implementations of std::find_if in bits/stl_algo.h. One
is for the input iterator case, the other is for the random access iterator
case. They are almost identical, except that the second is somewhat
"optimized".

>  /// This is an overload used by find algos for the Input Iterator case.
>  template
>inline _InputIterator
>__find_if(_InputIterator __first, _InputIterator __last,
> _Predicate __pred, input_iterator_tag)
>{
>  while (__first != __last && !__pred(__first))
>   ++__first;
>  return __first;
>}
>
>  /// This is an overload used by find algos for the RAI case.
>  template
>_RandomAccessIterator
>__find_if(_RandomAccessIterator __first, _RandomAccessIterator __last,
> _Predicate __pred, random_access_iterator_tag)
>{
>  typename iterator_traits<_RandomAccessIterator>::difference_type
>   __trip_count = (__last - __first) >> 2;
>
>  for (; __trip_count > 0; --__trip_count)
>   {
> if (__pred(__first))
>   return __first;
> ++__first;
>
> if (__pred(__first))
>   return __first;
> ++__first;
>
> if (__pred(__first))
>   return __first;
> ++__first;
>
> if (__pred(__first))
>   return __first;
> ++__first;
>   }
>
>  switch (__last - __first)
>   {
>   case 3:
> if (__pred(__first))
>   return __first;
> ++__first;
>   case 2:
> if (__pred(__first))
>   return __first;
> ++__first;
>   case 1:
> if (__pred(__first))
>   return __first;
> ++__first;
>   case 0:
>   default:
> return __last;
>   }
>}

Manual unrolling increases the code size and reduces the chances of this
function to be inlined. Inlining of this function is critical because it can
contain indirect calls to the predicate function, and inlining can change this
calls to direct improving performance.

I would suggest to revert manual unrolling and let the compiler decide which
optimization steps should be taken.

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #7 from Aldy Hernandez  ---
Fixed in trunk.

[Bug target/84172] option "-O3" create slower code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-suse-linux
  Component|c   |target

--- Comment #2 from Andrew Pinski  ---
Can you provide the output of the following command:
gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c -v

We need to know what -march=native expands to.

[Bug c++/81475] missing -Wsequence-point on a self-referential array access

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-01
 CC||msebor at gcc dot gnu.org
Summary|Missing "undefined  |missing -Wsequence-point on
   |behavior" warning   |a self-referential array
   ||access
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
You can download draft revisions of the C++ standard from the ISO/IEC WG21 C++
site: http://www.open-std.org/jtc1/sc22/wg21
But please keep in mind this is not the right place to ask for language
reference manuals.

That said, I can confirm that the test case has undefined behavior and should
trigger a -Wsequence-point warning.  Here's a smaller C/C++ test case the
demonstrates the same limitation.

No GCC release diagnosed this code so this is not a regression.


int f (void)
{
  int ar[2], *a = ar;

  a[0] = 1;

  return a[(*a)++ - 1];   // missing -Wsequence-point
}

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres  ---
> A temporary fix:
> ...

Preliminary tests look good! Thanks.

[Bug rtl-optimization/84123] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:908, alpha linux.

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb  1 22:22:03 2018
New Revision: 257318

URL: https://gcc.gnu.org/viewcvs?rev=257318=gcc=rev
Log:
PR rtl-optimization/84123
* combine.c (change_zero_ext): Check if hard register satisfies
can_change_dest_mode before calling gen_lowpart_SUBREG.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/combine.c

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

--- Comment #22 from Jürgen Reuter  ---
I'm actually running our code right now. It fixes _almost all_ of our unit and
functional tests. There is still one failing unit test and at least one failing
functional test. Still waiting for the full results. Will try to add a
reproducer for the test. For the unit test that is straightforward, for the
functional test maybe not so much.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter  ---
This fixes almost all of our unit and functional test, but not all of them.
There are still 19 functional tests failing, all of them seem to have to do
with some sort of I/O . And one unit tests, which I cannot see what it directly
does. For the latter I could do a reproducer, however, but it might take me a
day or two.