[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to janus from comment #0)
> Consider the following test case:
> 
> 
> program lazy
> 
>logical :: flag
> 
>flag = .false.
>flag = check() .and. flag  ! 'check' is executed as expected
>flag = flag .and. check()  ! bug: 'check' is not executed
> 
> contains
> 
>logical function check()
>   integer, save :: i = 1
>   print *, "check", i
>   i = i + 1
>   check = .true.
>end function
> 
> end
> 
> 
> The problem here is that gfortran executes the function 'check' only once,
> although it should be executed twice AFAICS.
> 
> Optimizing out the function call might be valid for a PURE function, but for
> an impure one with side effects, I don't think this is allowed.
> 
> Both ifort and flang execute the function twice. For gfortran, the
> optimization level does not seem to influence the result: -O0 and -O3 behave
> in the same way.
> 
> I tried with gfortran versions 5, 6, 7 and 8, which all exhibit the same
> buggy behavior.

The behavior may not be buggy, and it's best not to depend
on side-effects.  From F2018,

10.1.5.4.2 Evaluation of logical intrinsic operations

  Once the interpretation of a logical intrinsic operation is
  established, the processor may evaluate any other expression
  that is logically equivalent, provided that the integrity of
  parentheses in any expression is not violated.

  Two expressions of type logical are logically equivalent
  if their values are equal for all possible values of their
  primaries.

With 'flag = .false.', gfortran can determine that 
check()'s return value is irrelevant.  So, the
the values of 'flag .and. check()' and 'flag' are
logically equivalent.

Note, 'check() .and. flag' is logically equivalent
to 'flag', but the standard does not require any order
in the evaluation of op1 and op2 in a binary operation.

Also, note that this is my interpretation.  I could
be wrong.

[Bug fortran/85603] New: ICE with character array substring assignment

[w6ws at earthlink dot net]

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

Bug ID: 85603
   Summary: ICE with character array substring assignment
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w6ws at earthlink dot net
  Target Milestone: ---

The following test case causes an ICE.  First noticed with v5.4, but also
happens with v4.8 and a 4/26/2018 snapshot of v9.0.0.  Intel and NAG compile
and run this.  PGI v17.10 also gets an ICE...:

program strlen_bug
  implicit none

  character(:), allocatable :: strings(:)
  integer :: maxlen

  strings = [ character(32) ::  &
  'short',  &
  'somewhat longer' ]
  maxlen = maxval (len_trim (strings))
  print *, 'max length =', maxlen
  ! causes ICE !
  strings = strings(:)(:maxlen)
  print *, strings

end program

wws@w6ws-4:/rootsda5/home/wws/fortran/array_cons$
/usr/local/gcc-trunk/bin/gfortran --version
GNU Fortran (GCC) 9.0.0 20180426 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

wws@w6ws-4:/rootsda5/home/wws/fortran/array_cons$
/usr/local/gcc-trunk/bin/gfortran strlen_bug.f90
strlen_bug.f90:13:0:

   strings = strings(:)(:maxlen)

internal compiler error: Segmentation fault
0xce260f crash_signal
../../gcc-trunk/gcc/toplev.c:325
0x7722a7 gfc_alloc_allocatable_for_assignment(gfc_loopinfo*, gfc_expr*,
gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-array.c:9915
0x7a3c24 gfc_trans_assignment_1
../../gcc-trunk/gcc/fortran/trans-expr.c:10329
0x754537 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1828
0x7e7b2f gfc_trans_block_construct(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-stmt.c:2058
0x754327 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1924
0x788f45 gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6507
0x7081d0 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6121
0x7081d0 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6324
0x75107f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
wws@w6ws-4:/rootsda5/home/wws/fortran/array_cons$

[Bug middle-end/85602] New: regression with strncat and -Wall in GCC 8

[eggert at gnu dot org]

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

Bug ID: 85602
   Summary: regression with strncat and -Wall in GCC 8
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

Created attachment 44051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44051=edit
test program illustrating the regression

I ran into some problems building GNU Coreutils with gcc (GCC) 8.0.1 20180324
(Red Hat 8.0.1-0.20) and isolated it to the attached program w.c. The command
"gcc -Wall w.c" reports:

w.c: In function ‘main’:
w.c:11:35: warning: argument to ‘sizeof’ in ‘strncat’ call is the same
expression as the source; did you mean to use the size of the destination?
[-Wsizeof-pointer-memaccess]
   strncat (buf, u.ut_user, sizeof u.ut_user);

This diagnostic is quite wrong, and propagates confusion about strncat. Unlike
strncpy, strncat does not zero-fill the destination, and it is almost always
incorrect to do as GCC suggests which is to specify the size of the destination
as the third argument.

The source code is correct as-is: it is one of the few places where strncat is
the right function to use, as strncat was designed for struct utmp and similar
data structures. GCC 7 does not warn about this usage, and GCC 8 should not
warn either.

[Bug c++/81420] When a reference is bound to a member in the base of a temporary, lifetime of the temporary is not extended

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

  Known to work||8.0
Summary|CPU2006 471.omnetpp fails   |[9 Regression] CPU2006
   |starting with r259771   |471.omnetpp fails starting
   ||with r259771
  Known to fail||9.0

--- Comment #3 from Pat Haugen  ---
Benchmark fails same way with no optimization.

[Bug c++/85580] [8 Regression] "conflicting C language linkage declaration" warning for variables with identical names in `extern "C"` functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||andres at anarazel dot de

--- Comment #6 from Andrew Pinski  ---
*** Bug 85601 has been marked as a duplicate of this bug. ***

[Bug c++/85601] [8 Regression] anonymous struct & union namespace conflict in extern C block

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This was just fixed today: See bug 85580.

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

[Bug c++/85601] New: [8 Regression] anonymous struct & union namespace conflict in extern C block

[andres at anarazel dot de]

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

Bug ID: 85601
   Summary: [8 Regression] anonymous struct & union namespace
conflict in extern C block
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andres at anarazel dot de
  Target Milestone: ---

Hi,

When compiling with g++ anonymous structs / unions inside C functions conflict
based on their variable name.  That wasn't previously the case and doesn't seem
to make much sense.

Ex.:

extern "C"
{
  static inline void funca(void)
  {
  union
  {
int a;
  } myunion;

  (void) myunion;
  }

  static inline void funcb(void)
  {
  union
  {
int a;
  } myunion;

  (void) myunion;
  }
}

andres@alap4:~/src/postgresql$ /usr/lib/gcc-snapshot/bin/g++ --version
g++ (Debian 20180425-1) 9.0.0 20180425 (experimental) [trunk revision 259645]
..

andres@alap4:~/src/postgresql$ /usr/lib/gcc-snapshot/bin/g++ -c -o /tmp/frak.o
/tmp/frak.cc
/tmp/frak.cc: In function 'void funcb()':
/tmp/frak.cc:18:9: warning: conflicting C language linkage declaration
'funcb():: myunion'
   } myunion;
 ^~~
/tmp/frak.cc:8:9: note: previous declaration 'funca():: myunion'
   } myunion;
 ^~~
If I rename one of the *variables* in the *independent* functions the error
vanishes.

This currently triggers inside PostgreSQL's master branch (which now uses C++
for an optional module).

Regards,

Andres Freund

[Bug libstdc++/84654] libstdc++ tries to use __float128 when compiling with -mno-float128

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May  1 22:47:33 2018
New Revision: 259813

URL: https://gcc.gnu.org/viewcvs?rev=259813=gcc=rev
Log:
PR libstdc++/84654 Disable __float128 specializations for -mno-float128

2018-05-01  Tulio Magno Quites Machado Filho  

PR libstdc++/84654
* acinclude.m4: Set ENABLE_FLOAT128 instead of _GLIBCXX_USE_FLOAT128.
* config.h.in: Remove references to _GLIBCXX_USE_FLOAT128.
* configure: Regenerate.
* include/Makefile.am: Replace the value of _GLIBCXX_USE_FLOAT128
based on ENABLE_FLOAT128.
* include/Makefile.in: Regenerate.
* include/bits/c++config: Define _GLIBCXX_USE_FLOAT128.
[!defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__)]: Undefine
_GLIBCXX_USE_FLOAT128.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/bits/c++config

[Bug tree-optimization/85143] Loop limit prevents (auto)vectorization

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
Note that the patch still doesn't handle

  _1 = n_15(D) <= i_46;
  _2 = i_46 > 1336;
  _3 = _1 | _2;

because of the mix between strict and large inequalities.

(if I write int m = 1337; and replace i < 1337 with i < m, the transformation
does happen, and with a suitable -march it vectorizes)

[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-01
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
I've tried bootstrap with -flto-partition=none and also get differences in
gengtype and cc1, so it seems to be unrealated to partitioning change.  First
bigger one is:

@@ -2875,506 +2875,507 @@
   40444b:  48 89 05 6e 64 02 00mov%rax,0x2646e(%rip)#
42a8c0 
   404452:  31 ff   xor%edi,%edi
   404454:  44 39 2d 15 65 02 00cmp%r13d,0x26515(%rip)#
42a970 
-  40445b:  7e 49   jle4044a6 
+  40445b:  7e 4e   jle4044ab 
   40445d:  e8 de 37 01 00  callq  417c40 <_ZL16peek_state_tokeni>
   404462:  bf 01 00 00 00  mov$0x1,%edi
-  404467:  49 89 c6mov%rax,%r14
-  40446a:  e8 d1 37 01 00  callq  417c40 <_ZL16peek_state_tokeni>
-  40446f:  bf 02 00 00 00  mov$0x2,%edi
-  404474:  48 89 c5mov%rax,%rbp
-  404477:  e8 c4 37 01 00  callq  417c40 <_ZL16peek_state_tokeni>



+  404467:  49 89 c7mov%rax,%r15
+  40446a:  48 89 04 24 mov%rax,(%rsp)
+  40446e:  e8 cd 37 01 00  callq  417c40 <_ZL16peek_state_tokeni>
+  404473:  bf 02 00 00 00  mov$0x2,%edi
+  404478:  48 89 c5mov%rax,%rbp
+  40447b:  e8 c0 37 01 00  callq  417c40 <_ZL16peek_state_tokeni>

So it seems to be something else than partitioning changes.  Looking at
assembly there are some things that seems like partitioning
differences. This partiuclar one doesn't seem to be.

[Bug tree-optimization/85143] Loop limit prevents (auto)vectorization

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
Author: glisse
Date: Tue May  1 21:41:05 2018
New Revision: 259812

URL: https://gcc.gnu.org/viewcvs?rev=259812=gcc=rev
Log:
Generalize a

PR tree-optimization/85143
gcc/
* match.pd (A