[Bug fortran/86566] New: The preprocessor cpp6 loses line concatenation on FreeBSD

[yuri at tsoft dot com]

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

Bug ID: 86566
   Summary: The preprocessor cpp6 loses line concatenation on
FreeBSD
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yuri at tsoft dot com
  Target Milestone: ---

How to repeat:
create the file a.f90 with this one line (it is also attached):
> call iotk_strcat(string,trim(adjustl(tmpval))//" ",ierr)

Run the command:
> cpp8 a.f90 -o atmp.f90

The result isn't a valid fortran:
>  call iotk_strcat(string,trim(adjustl(tmpval))

The problem observed on gcc8 and gcc6.

The FreeBSD port bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229855

[Bug target/85624] ICE when initializing array that is 128-byte aligned

[saaadhu at gcc dot gnu.org]

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

--- Comment #2 from Senthil Kumar Selvaraj  ---
When cfgexpand invokes gen_setmemhi, operands[1] is (const_int 6) -  it's the
pattern which copies it to (reg:QI). Setting the mode of operands[1] to HImode
makes the problem go away - clrmemhi matches the generated pattern.

Need to check why clrmemqi doesn't match.

[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to Jonny Grant from comment #11)
> Hi Richard
> 
> I have a smaller test case which. It shows only part of the error.
> "Dwarf Error: Invalid abstract instance DIE ref"
> 
> Richard, would this be useful?

Unfortunately this is only a spurious error caused by the later undefined
reference ones.  I have opened
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 for this issue.

Given the original issue also reports undefined references the
DWARF error emitted there looks like hitting the very same issue.

Can you reproduce the DWARF errors without undefined references?

> 
> g++-8 -std=c++11 -g -ggdb -pthread -O0  -Wnonnull -fstack-protector-strong 
> -Wdiv-by-zero -Wsign-conversion -Wnull-dereference -flto
> -Wno-nonnull-compare -o proc whois_if.cpp test_whois.cpp stdio_cx.c
> cpputil.cpp 
> /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Invalid abstract instance DIE ref.
> /tmp/cctwveUb.ltrans0.ltrans.o: In function `test_whois(bool)':
> :(.text+0xae6): undefined reference to `get_err_whois(int,
> std::__cxx11::basic_string,
> std::allocator >&)'
> /tmp/cctwveUb.ltrans0.ltrans.o: In function `strerrno[abi:cxx11](int)':
> :(.text+0x2c2a): undefined reference to `strerrno_s(char*,
> unsigned long, int)'
> collect2: error: ld returned 1 exit status
> makefile:3: recipe for target 'all' failed
> make: *** [all] Error 1

[Bug middle-end/86554] Incorrect code generation with signed/unsigned comparison

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I will have a look.

[Bug fortran/85599] warn about short-circuiting of logical expressions for non-pure functions

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
   Assignee|tkoenig at gcc dot gnu.org |janus at gcc dot gnu.org
Summary|Prevent short-circuiting of |warn about short-circuiting
   |logical expressions for |of logical expressions for
   |non-pure functions  |non-pure functions

--- Comment #36 from janus at gcc dot gnu.org ---
I'm changing the title of this PR, in order to reflect the state to which the
longish discussion converged, namely that we plan to keep gfortran's
short-circuiting behavior as is for now, but throw warnings for affected code
(with -Wfuction-elimination).

Also: Assigning to myself. Latest patch at
https://gcc.gnu.org/ml/fortran/2018-07/msg00065.html

[Bug fortran/86566] The preprocessor cpp6 loses line concatenation on FreeBSD

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
cpp is the C/C++ preprocessor.  If you want to preprocess Fortran use gcc -cpp.

[Bug middle-end/86554] Incorrect code generation with signed/unsigned comparison

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
The issue seems to be that we do

Value numbering ret_10 stmt = ret_10 = (int) _9;
Setting value number of ret_10 to ret_11 (changed)

so we correctly figure both ret are the same.  We then continue

Value numbering ret_12 stmt = ret_12 = PHI 
Setting value number of ret_12 to ret_11
...
Visiting control stmt ending BB 5: if (ret_12 <= 0)
Marking all edges out of BB 5 but (5 -> 6) as not executable

oops.  We seem to have simplified this as

 if (_8 + -2147483647 <= 0)

which given strict overflow rules is always true.

The issue here is that we did expression simplification of a value expression,
and this is a really really hard issue to fix.  I'm currently working on a
complete rewrite of FRE for GCC9 which doesn't exhibit this issue (by design).

For some reason PRE code-hoisting re-introduces the issue by hoisting
the signed operation.

[Bug middle-end/86554] [7/8/9 Regression] Incorrect code generation with signed/unsigned comparison

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.4.0
Summary|Incorrect code generation   |[7/8/9 Regression]
   |with signed/unsigned|Incorrect code generation
   |comparison  |with signed/unsigned
   ||comparison
  Known to fail|7.0.1   |7.1.0, 8.1.0, 9.0

--- Comment #5 from Richard Biener  ---
This regressed with moving fold-const.c patterns to match.pd, specifically

/* Non-equality compare simplifications from fold_binary  */
(for cmp (lt gt le ge)
 /* Comparisons with the highest or lowest possible integer of
the specified precision will have known values.  */
 (simplify
  (cmp (convert?@2 @0) INTEGER_CST@1)
...
   (if (cmp == LE_EXPR)
{ constant_boolean_node (true, type); })

and

/* Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 -+ C1.  */
(for cmp (lt le gt ge)
 (for op (plus minus)
  rop (minus plus)
  (simplify
   (cmp (op@3 @0 INTEGER_CST@1) INTEGER_CST@2)
...
  (if (single_use (@3))
   (with
{
  fold_overflow_warning (("assuming signed overflow does not occur "
  "when changing X +- C1 cmp C2 to "
  "X cmp C2 -+ C1"),
 WARN_STRICT_OVERFLOW_COMPARISON);
}
(cmp @0 { res; })

The latter only appeared with GCC7.

The issue itself is latent at least since match-and-simplify but possibly
earlier as well where SCCVN used GENERIC expression simplification for
"combining" stmt defs.

It will take some time to fix this (if a fix is possible with reasonable
amount of work), do not hold your breath.

[Bug middle-end/86554] [7/8/9 Regression] Incorrect code generation with signed/unsigned comparison

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.4

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[bernd.edlinger at hotmail dot de]

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

--- Comment #24 from Bernd Edlinger  ---
Hope you don't mind, but may I suggest to do the comparison in unsigned
arithmetics, like:

  /* We don't know the starting offset, but we do know that the string
 has no internal zero bytes.  If the offset falls within the bounds
 of the string subtract the offset from the length of the string,
 and return that.  Otherwise the length is zero.  Take care to
 use SAVE_EXPR in case the OFFSET has side-effects.  */
  tree offsave = TREE_SIDE_EFFECTS (byteoff) ? save_expr (byteoff) :
byteoff;
  offsave = fold_convert (sizetype, offsave);
  tree condexp = fold_build2_loc (loc, LE_EXPR, boolean_type_node, offsave,
  size_int (len * eltsize));
  tree lenexp = size_diffop_loc (loc, size_int (len * eltsize), offsave);
  return fold_build3_loc (loc, COND_EXPR, ssizetype, condexp, lenexp,
  build_zero_cst (ssizetype));


That would have the advantage, that all undefined cases including i>len and
i<0 return 0, instead of an unlimited value.  This should not have any
extra cost.

BTW: the line "tree offsave = ...;" is 81 chars long and could be split up.

I don't know how to emit a trap in the false path of COND_EXPR.
All examples I see, use gimple for that.

[Bug debug/86523] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24933 starting from r262560

[dimhen at gmail dot com]

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

--- Comment #11 from Dmitry G. Dyachenko  ---
r262850 works for me.
Thanks!

[Bug target/86555] unaligned address for ldrd/strd on armv5e

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
If dirent has alignof() == 8 then you have to make sure de is properly aligned
inside buf[].  I assume off_t is 8 bytes.

The issue might be that buf[] itself is only 4 byte aligned when you
use lock[1] instead of lock[2].  You can do

volatile int lock[1]; /* was 2, with 1 we get ldrd unalignment */
char buf[2048] __attribute__((aligned(8)));
};

to get 8-byte alignment for buf (or add a int pad; member)

[Bug tree-optimization/86544] Popcount detection generates different code on C and C++

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-18
 Ever confirmed|0   |1

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to kugan from comment #2)
> Patch posted at https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00975.html

Thanks for picking this up.
Marking as assign. Can you please add yourself to the assignee field?

[Bug rtl-optimization/86334] wrong code with -march=athlon -mmemcpy-strategy=libcall:-1:noalign

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Uroš Bizjak  ---
The issue here is that g escapes as an argument to memcpy, but this is not
reported form local_variable_can_escape:

Breakpoint 1, local_variable_can_escape (decl=0x7fffe9ba3240) at
../../git/gcc/gcc/dse.c:910
910   if (TREE_ADDRESSABLE (decl))
Missing separate debuginfos, use: dnf debuginfo-install gmp-6.1.2-7.fc28.x86_64
isl-0.16.1-6.fc28.x86_64 libgcc-8.1.1-1.fc28.x86_64 libmpc-1.0.2-9.fc28.x86_64
libstdc++-8.1.1-1.fc28.x86_64 mpfr-3.1.6-1.fc28.x86_64
(gdb) p debug_generic_expr (decl)
g
$1 = void
(gdb) fin
Run till exit from #0  local_variable_can_escape (decl=0x7fffe9ba3240) at
../../git/gcc/gcc/dse.c:910
0x013fb758 in can_escape (expr=0x7fffe9ba3240) at
../../git/gcc/gcc/dse.c:942
942&& local_variable_can_escape (base)))
Value returned is $2 = false

DSE just removes all stores to g as dead.

CC Honza.

[Bug tree-optimization/86557] missed vectorization with std::vector compared to icc 18

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||53947

--- Comment #2 from Richard Biener  ---
But even with that we seem to need AVX512F to vectorize it, with AVX2 we get

t.C:5:31: note:   not vectorized: relevant stmt not supported: patt_45 =
patt_44 >> 2;

thus, somehow V2DI arithmetic right shifts are not available.  Indeed
it looks like we only have named patterns for V4SI arithmetic right shifts for
AVX2.

I'm going to bootstrap / test the vectorizer fix.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug fortran/86566] The preprocessor cpp6 loses line concatenation on FreeBSD

[yuri at tsoft dot com]

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

--- Comment #2 from Yuri  ---
Replacing cpp with gcc6 -cpp fails:

$ gcc6 -cpp -fno-omit-frame-pointer -D__FFTW3
-I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/include
-I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/FoX/finclude
-I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/S3DE/iotk/include/
iotk_base.f90 -o iotk_base_tmp.f90
/usr/lib/crt1.o: In function `_start':
/usr/src/lib/csu/amd64/crt1.c:(.text+0x17b): undefined reference to `main'
collect2: error: ld returned 1 exit status


It seems like it tries to link the executable?

[Bug tree-optimization/86557] missed vectorization with std::vector compared to icc 18

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
ICC seems to emulate this even for SSE2 where I'm not sure this is profitable:

..B1.2: # Preds ..B1.2 ..B1.1
# Execution count [1.02e+03]
movdqu.L_2il0floatpacket.0(%rip), %xmm2 #6.19
lea   x(,%rax,8), %rdx  #6.12
movdqu(%rdx), %xmm1 #6.12
movdqa%xmm2, %xmm0  #6.19
pand  %xmm1, %xmm0  #6.19
movdqa%xmm1, %xmm3  #6.19
psrlq $1, %xmm3 #6.19
psrad $1, %xmm0 #6.19
por   %xmm0, %xmm3  #6.19
psrlq $62, %xmm3#6.19
paddq %xmm1, %xmm3  #6.19
pand  %xmm3, %xmm2  #6.19
psrlq $2, %xmm3 #6.19
psrad $2, %xmm2 #6.19
por   %xmm2, %xmm3  #6.19
movdqu%xmm3, (%rdx) #6.5
addq  $2, %rax  #5.3
cmpq  $1024, %rax   #5.3
jb..B1.2# Prob 99%  #5.3


and for AVX2:

..B1.2: # Preds ..B1.2 ..B1.1
# Execution count [1.02e+03]
lea   x(,%rax,8), %rdx  #6.12
vmovdqu   (%rdx), %ymm4 #6.12
vpsrlq$1, %ymm4, %ymm0  #6.19
vpsrad$1, %ymm4, %ymm1  #6.19
vpblendw  $204, %ymm1, %ymm0, %ymm2 #6.19
vpsrlq$62, %ymm2, %ymm3 #6.19
vpaddq%ymm4, %ymm3, %ymm5   #6.19
vpsrlq$2, %ymm5, %ymm6  #6.19
vpsrad$2, %ymm5, %ymm7  #6.19
vpblendw  $204, %ymm7, %ymm6, %ymm8 #6.19
vmovdqu   %ymm8, (%rdx) #6.5
addq  $4, %rax  #5.3
cmpq  $1024, %rax   #5.3
jb..B1.2# Prob 99%  #5.3


long x[1024];

void foo()
{
  for (int i = 0; i < 1024; ++i)
x[i] = x[i] / 4;
}

[Bug tree-optimization/86557] missed vectorization with std::vector compared to icc 18

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c++/86558] ICE on template code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-18
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
template 
struct IP
{
 static const bool r = IP::r;
};

is that self-reference even valid?  clang seems to "ignore" it which at least
breaks the recursion.

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[bernd.edlinger at hotmail dot de]

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

--- Comment #25 from Bernd Edlinger  ---
Sorry again Martin,

but with the latest patch I see the following:


FAIL: gcc.target/i386/avx-vdppd-2.c (internal compiler error)
FAIL: gcc.target/i386/avx-vdppd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx-vdpps-2.c (internal compiler error)
FAIL: gcc.target/i386/avx-vdpps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx-vinsertps-1.c (internal compiler error)
FAIL: gcc.target/i386/avx-vinsertps-1.c (test for excess errors)
FAIL: gcc.target/i386/avx-vinsertps-4.c (internal compiler error)
FAIL: gcc.target/i386/avx-vinsertps-4.c (test for excess errors)
FAIL: gcc.target/i386/sse4_1-dppd-2.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-dppd-2.c (test for excess errors)
FAIL: gcc.target/i386/sse4_1-dpps-2.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-dpps-2.c (test for excess errors)
FAIL: gcc.target/i386/sse4_1-insertps-1.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-insertps-1.c (test for excess errors)
FAIL: gcc.target/i386/sse4_1-insertps-4.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-insertps-4.c (test for excess errors)

/home/ed/gnu/gcc-9-20180715-1/gcc/testsuite/gcc.target/i386/sse4_1-dppd-2.c: In
function 'avx_test':^M
/home/ed/gnu/gcc-9-20180715-1/gcc/testsuite/gcc.target/i386/sse4_1-dppd-2.c:70:7:
internal compiler error: Segmentation fault^M
0xcd1b6f crash_signal^M
../../gcc-9-20180715-1/gcc/toplev.c:324^M
0x9ccabd string_constant(tree_node*, tree_node**)^M
../../gcc-9-20180715-1/gcc/expr.c:11360^M
0x9f9219 c_getstr(tree_node*, unsigned long*, unsigned long*)^M
../../gcc-9-20180715-1/gcc/fold-const.c:14591^M
0xa2439e fold_const_call(combined_fn, tree_node*, tree_node*, tree_node*,
tree_node*)^M
../../gcc-9-20180715-1/gcc/fold-const-call.c:1712^M
0x8a6431 fold_builtin_3^M
../../gcc-9-20180715-1/gcc/builtins.c:9355^M
0x8a6431 fold_builtin_n(unsigned int, tree_node*, tree_node**, int, bool)^M
../../gcc-9-20180715-1/gcc/builtins.c:9432^M
0xa1f2b1 fold(tree_node*)^M
../../gcc-9-20180715-1/gcc/fold-const.c:11964^M
0x814aeb c_fully_fold_internal^M
../../gcc-9-20180715-1/gcc/c/c-fold.c:626^M
0x8171b7 c_fully_fold(tree_node*, bool, bool*, bool)^M
../../gcc-9-20180715-1/gcc/c/c-fold.c:125^M
0x7e1dba build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
bool)^M
../../gcc-9-20180715-1/gcc/c/c-typeck.c:12015^M
0x7cbe40 c_objc_common_truthvalue_conversion(unsigned int, tree_node*)^M
../../gcc-9-20180715-1/gcc/c/c-typeck.c:12188^M
0x7fdd5e c_parser_condition^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:5569^M
0x7fde07 c_parser_paren_condition^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:5588^M
0x8099cd c_parser_if_statement^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:5767^M
0x8099cd c_parser_statement_after_labels^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:5399^M
0x80b4a9 c_parser_compound_statement_nostart^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:5078^M
0x80b9d6 c_parser_compound_statement^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:4912^M
0x8093da c_parser_statement_after_labels^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:5393^M
0x80ee0e c_parser_statement^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:5366^M
0x80ee0e c_parser_c99_block_statement^M
../../gcc-9-20180715-1/gcc/c/c-parser.c:5605^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[bernd.edlinger at hotmail dot de]

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

--- Comment #26 from Bernd Edlinger  ---
../../gcc-9-20180715-1/gcc/expr.c:11360 is:

  while (TREE_CODE (chartype) != INTEGER_TYPE)
chartype = TREE_TYPE (chartype);

[Bug target/85624] ICE when initializing array that is 128-byte aligned

[saaadhu at gcc dot gnu.org]

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

Senthil Kumar Selvaraj  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-18
 Ever confirmed|0   |1

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #2 from The Written Word  
---
gcc-6.4.0 on AIX 5.3 exhibits a similar failure.

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-07-18
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Please provide preprocessed source for math_stubs_long_double.o

(change dir to
/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/c++98
and run the /opt/build/china/gcc-8.1.0/.obj/./gcc/xgcc command, adding
-save-temps to produce a .ii file)

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
We might need something like:

--- a/libstdc++-v3/src/c++98/math_stubs_long_double.cc
+++ b/libstdc++-v3/src/c++98/math_stubs_long_double.cc
@@ -31,6 +31,7 @@
 extern "C"
 {
 #ifndef _GLIBCXX_HAVE_FABSL
+#undef fabsl
   long double
   fabsl(long double x)
   {


Either that, or figure out why _GLIBCXX_HAVE_FABSL is not defined when
apparently it's a macro for fabs

[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jul 18 10:27:12 2018
New Revision: 262851

URL: https://gcc.gnu.org/viewcvs?rev=262851&root=gcc&view=rev
Log:
/cp
2018-07-18  Paolo Carlini  

* class.c (note_name_declared_in_class): Prefer permerror + inform
to a pair of permerrors; use DECL_SOURCE_LOCATION.

/testsuite
2018-07-18  Paolo Carlini  

* g++.dg/ext/uow-3.C: Adjust.
* g++.dg/ext/uow-4.C: Likewise.
* g++.dg/lookup/name-clash11.C: Likewise.
* g++.dg/lookup/name-clash7.C: Likewise.
* g++.dg/lookup/redecl1.C: Likewise.
* g++.dg/warn/changes-meaning.C: Likewise.
* g++.old-deja/g++.jason/scoping8.C: Likewise.
* g++.old-deja/g++.law/nest1.C: Likewise.

/cp
2019-07-18  Paolo Carlini  

PR c++/59480, DR 136
* decl.c (check_no_redeclaration_friend_default_args): New.
(duplicate_decls): Use the latter; also check that a friend
declaration specifying default arguments is a definition.

/testsuite
2019-07-18  Paolo Carlini  

PR c++/59480, DR 136
* g++.dg/other/friend8.C: New.
* g++.dg/other/friend9.C: Likewise.
* g++.dg/other/friend10.C: Likewise.
* g++.dg/other/friend11.C: Likewise.
* g++.dg/other/friend12.C: Likewise.
* g++.dg/parse/defarg4.C: Compile with -fpermissive -w.
* g++.dg/parse/defarg8.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/friend10.C
trunk/gcc/testsuite/g++.dg/other/friend11.C
trunk/gcc/testsuite/g++.dg/other/friend12.C
trunk/gcc/testsuite/g++.dg/other/friend8.C
trunk/gcc/testsuite/g++.dg/other/friend9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/uow-3.C
trunk/gcc/testsuite/g++.dg/ext/uow-4.C
trunk/gcc/testsuite/g++.dg/lookup/name-clash11.C
trunk/gcc/testsuite/g++.dg/lookup/name-clash7.C
trunk/gcc/testsuite/g++.dg/lookup/redecl1.C
trunk/gcc/testsuite/g++.dg/parse/defarg4.C
trunk/gcc/testsuite/g++.dg/parse/defarg8.C
trunk/gcc/testsuite/g++.dg/warn/changes-meaning.C
trunk/gcc/testsuite/g++.old-deja/g++.jason/scoping8.C
trunk/gcc/testsuite/g++.old-deja/g++.law/nest1.C

[Bug libgomp/38935] Openmp reduction with - (minus) does not produce correct result

[subc2 at wp dot pl]

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

--- Comment #2 from Paweł Zacharek  ---
GCC behaves correctly, according to OpenMP 4.0
(https://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf#page=175) and OpenMP
4.5 (https://www.openmp.org/wp-content/uploads/openmp-4.5.pdf#page=211)
Specifications. The TR7 OpenMP 5.0 Draft hadn't changed that as well.

[Bug c++/86567] New: [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation

[amonakov at gcc dot gnu.org]

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

Bug ID: 86567
   Summary: [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect
code generation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

#include 

std::vector
f()
{
  std::vector r;
  return r;
}

starting with gcc-8 ICEs using 'g++ -fcompare-debug=-Wnonnull' (as well as
Wformat, Wrestrict, Wsuggest-attribute=format)


cp/call.c:build_over_call() has:

  if (warn_nonnull
  || warn_format
  || warn_suggest_attribute_format
  || warn_restrict)
{
  tree *fargs = (!nargs ? argarray
: (tree *) alloca (nargs * sizeof (tree)));
  for (j = 0; j < nargs; j++)
{
  /* For -Wformat undo the implicit passing by hidden reference
 done by convert_arg_to_ellipsis.  */
  if (TREE_CODE (argarray[j]) == ADDR_EXPR
  && TYPE_REF_P (TREE_TYPE (argarray[j])))
fargs[j] = TREE_OPERAND (argarray[j], 0);
  else
fargs[j] = maybe_constant_value (argarray[j]);
}

  warned_p = check_function_arguments (input_location, fn, TREE_TYPE (fn),
   nargs, fargs, NULL);
}


which if bypassed does not cause the ICE, which indicates that something in the
snippet may affect code generation (not investigating further).

[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
GCC 7 sadly has a similar list of miscomparing files. Did not check GCC 6 yet.

So far I managed to catch one set of misbehaving warnings by checking testsuite
fallout with -fcompare-debug=-Wall, but unfortunately fixing those would not
reduce the number of bootstrap miscompares: PR 86567.

[Bug bootstrap/86559] Build failure on AIX 5.3

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to The Written Word from comment #1)
> Might be a duplicate of PR64081.

Wrong bug number?

You might need -mcmodel=large

[Bug c++/86567] [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.1.1
   Target Milestone|--- |8.2

--- Comment #1 from Richard Biener  ---
I think maybe_constant_value has a cache which may cause side-effects.

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
Surely static_cast is good enough, and doesn't rule out making the function
constexpr?

[Bug c++/86562] Missing warning (error in C++11) for passing nontrivial object to varargs function via function pointer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Not a bug. The standard says passing non-trivial types through varargs is
"conditionally-supported" so an implementation can either support it, or reject
it with a diagnostic.

GCC supports it, Clang doesn't.

[Bug target/45996] -falign-functions=X does not work

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Fixed on trunk, not planning to backport that.

[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning and is ignored

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Liška  ---
Fixed on trunk, not planning to backport that.

[Bug c++/86561] a function definition must occur in a standalone declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-18
 Ever confirmed|0   |1

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #5 from The Written Word  
---
Created attachment 44405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44405&action=edit
Preprocessed source for math_stubs_long_double.cc

[Bug tree-optimization/86557] missed vectorization with std::vector compared to icc 18

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jul 18 12:57:15 2018
New Revision: 262854

URL: https://gcc.gnu.org/viewcvs?rev=262854&root=gcc&view=rev
Log:
2018-07-18  Richard Biener  

PR tree-optimization/86557
* tree-vect-patterns.c (vect_recog_divmod_pattern): Also handle
EXACT_DIV_EXPR.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug c++/86563] catch reference to incomplete type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-18
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This might depend on the point of instantiation of the function template. The
type is complete when the template is instantiated (although T is not dependent
in the template body, so maybe it should be diagnosed earlier).

[Bug target/86560] FAIL: c-c++-common/asan/swapcontext-test-1.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=38207

--- Comment #2 from H.J. Lu  ---
LLVM bug is

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

[Bug bootstrap/86559] Build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #3 from The Written Word  
---
(In reply to Jonathan Wakely from comment #2)
> (In reply to The Written Word from comment #1)
> > Might be a duplicate of PR64081.
> 
> Wrong bug number?

I was looking at bug 64081 comment 31.

[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jul 18 13:13:11 2018
New Revision: 262855

URL: https://gcc.gnu.org/viewcvs?rev=262855&root=gcc&view=rev
Log:
PR c++/86190 - bogus -Wsign-conversion warning
* typeck.c (cp_build_binary_op): Fix formatting.  Add a warning
sentinel.

* g++.dg/warn/Wsign-conversion-3.C: New test.
* g++.dg/warn/Wsign-conversion-4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wsign-conversion-3.C
trunk/gcc/testsuite/g++.dg/warn/Wsign-conversion-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||build
 Status|WAITING |NEW

--- Comment #6 from Jonathan Wakely  ---
Thanks

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #4 from The Written Word  
---
(In reply to The Written Word from comment #3)
> (In reply to David Edelsohn from comment #2)
> > Group Bull, Perzl, and I have been able to build it.  Are you using an up to
> > date AIX Assembler?
> 
> Hmm. Let me try upgrading. Thanks.

I upgraded the system to the following:
  $ oslevel -s
  7100-04-05-1720
  $ lslpp -h bos.rte.bind_cmds
  Fileset Level Action   Status   Date Time
  
Path: /usr/lib/objrepos
  bos.rte.bind_cmds
  7.1.0.0   COMMIT   COMPLETE 11/13/10 21:01:20
 7.1.0.15   COMMIT   COMPLETE 06/18/12 19:54:09
 7.1.0.16   COMMIT   COMPLETE 10/12/16 21:23:45
 7.1.2.19   COMMIT   COMPLETE 10/17/16 20:41:47
 7.1.3.47   COMMIT   COMPLETE 07/10/18 21:18:33
 7.1.4.32   APPLYCOMPLETE 07/10/18 21:31:27

Path: /etc/objrepos
  bos.rte.bind_cmds
  7.1.0.0   COMMIT   COMPLETE 11/13/10 21:01:20
 7.1.0.15   COMMIT   COMPLETE 06/18/12 19:54:10
 7.1.0.16   COMMIT   COMPLETE 10/12/16 21:23:45
 7.1.2.19   COMMIT   COMPLETE 10/17/16 20:41:47
 7.1.3.47   COMMIT   COMPLETE 07/10/18 21:18:33
 7.1.4.32   APPLYCOMPLETE 07/10/18 21:31:29

I built gcc-4.9.4 and I still get the error:
g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-
W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-peda
ntic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-D
HAVE_CONFIG_H -I. -I. -I/opt/build/china/gcc-4.9.4/gcc
-I/opt/build/china/gcc-4.
9.4/gcc/. -I/opt/build/china/gcc-4.9.4/gcc/../include -I./../intl
-I/opt/build/c
hina/gcc-4.9.4/gcc/../libcpp/include -I/opt/TWWfsw/libgmp61/include
-I/opt/TWWfs
w/libmpfr31/include -I/opt/TWWfsw/libmpc10/include 
-I/opt/build/china/gcc-4.9.4
/gcc/../libdecnumber -I/opt/build/china/gcc-4.9.4/gcc/../libdecnumber/dpd
-I../l
ibdecnumber -I/opt/build/china/gcc-4.9.4/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/
opt/TWWfsw/libcloog018/include -I/opt/TWWfsw/libisl015/include  -o
insn-output.o
 -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo insn-output.c
/tmp//ccGCJgTB.s: Assembler messages:
/tmp//ccGCJgTB.s:1361: Error: value of 00012990 too large for field of
2
 bytes at 046e
/tmp//ccGCJgTB.s:1495: Error: value of 00012990 too large for field of
2
 bytes at 05ee
/tmp//ccGCJgTB.s:1628: Error: value of 00012990 too large for field of
2
 bytes at 0772
/tmp//ccGCJgTB.s:1761: Error: value of 00012990 too large for field of
2
 bytes at 08f6
/tmp//ccGCJgTB.s:1913: Error: value of 00012994 too large for field of
2
 bytes at 0aa6
/tmp//ccGCJgTB.s:2047: Error: value of 00012990 too large for field of
2
 bytes at 0c2a
/tmp//ccGCJgTB.s:2183: Error: value of 00012990 too large for field of
2
 bytes at 0db6
/tmp//ccGCJgTB.s:2289: Error: value of 00012998 too large for field of
2
 bytes at 0eca
...

I was able to build gcc-8.1.0 on this system. Trying gcc-5.5.0, 6.4.0, and
7.2.0 now.

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
As I suspected, something is doing:

#define fabsl(X) fabs((double) (X))
#define acosl(X) acos((double) (X))
etc.

This would probably be solved by any fix for PR 79700, which would have to add
this to :

#undef fabsl

But I'm not sure when PR 79700 will get fixed.

[Bug bootstrap/68663] Build failure on AIX 7.1

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
GCC 4.9 is quite old now and out of service.  If there is a bug in GCC 4.9, it
will not be fixed because there are no bug fix releases planned.

You never showed an example of the assembly line representing the error message
to allow someone to observe the exact assembly instruction and operands in
question.

Maybe some other build tool corrupted the generated parameter. Or some bug in
AIX C library corrupted the parameter. There are a huge number of
possibilities.

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Created attachment 44406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44406&action=edit
Undefine macros for long double math functions

Does this fix the build?

This isn't really a proper fix, as it just allows the file to build. Code
including  will still see those macros and won't use the stubs defined
in math_stubs_long_double.cc

Maybe that's good enough though - I'm not sure precisely what the stubs are
for.

[Bug c++/86190] [6/7/8 Regression] -Wsign-conversion ignores explicit conversion in some cases

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6/7/8/9 Regression]|[6/7/8 Regression]
   |-Wsign-conversion ignores   |-Wsign-conversion ignores
   |explicit conversion in some |explicit conversion in some
   |cases   |cases

--- Comment #9 from Marek Polacek  ---
Fixed on trunk so far.  Unsure about backporting (the fix is simple, but is it
worth it?  I guess).

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #9 from The Written Word  
---
(In reply to Jonathan Wakely from comment #7)
> As I suspected, something is doing:
> 
> #define fabsl(X) fabs((double) (X))
> #define acosl(X) acos((double) (X))
> etc.

/usr/include/math.h on this platform has:
#ifdef _ISOC99_SOURCE
#ifdef __LONGDOUBLE128
...
#else
...
#define acosl(__x)  acos((double) (__x))
#define fabsl(__x)  fabs((double) (__x))
...
#endif

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #10 from The Written Word  
---
(In reply to Jonathan Wakely from comment #8)
> Created attachment 44406 [details]
> Undefine macros for long double math functions
> 
> Does this fix the build?

I am trying a similar patch. I basically #undef'd everything to get a clean
build of that file and restarted the build from scratch so we'll see.

[Bug c++/86480] [8/9 Regression] error: parameter packs not expanded with '...' in a recursive variadic lambda

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Jul 18 13:42:02 2018
New Revision: 262858

URL: https://gcc.gnu.org/viewcvs?rev=262858&root=gcc&view=rev
Log:
PR c++/86480 - nested variadic lambda and constexpr if.

* pt.c (find_parameter_packs_r) [IF_STMT]: Don't walk into
IF_STMT_EXTRA_ARGS.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if24.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/86480] [8/9 Regression] error: parameter packs not expanded with '...' in a recursive variadic lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 8.2/9.

[Bug middle-end/86554] [7/8/9 Regression] Incorrect code generation with signed/unsigned comparison

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Anton has been able to work around the problem with a source change (this code
is unnecessarily baroque anyway), so I don't think anybody is urgently awaiting
a fix.  If this will be fixed in your eventual rewrite of FRE, I think that's
more than sufficient.  Thanks!

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #6 from The Written Word  
---
(In reply to David Edelsohn from comment #5)
> GCC 4.9 is quite old now and out of service.  If there is a bug in GCC 4.9,
> it will not be fixed because there are no bug fix releases planned.

Understood.

> You never showed an example of the assembly line representing the error
> message to allow someone to observe the exact assembly instruction and
> operands in question.

I've attached insn-output.s. Looks like the problematic lines are of the form:
bl ._Z17gen_rtx_CONST_INT12machine_modex
nop
mr 0,3
stw 0,0(28)
.line   3466
lwz 0,LC..1(2)  <-- line 1361
.eb 3466
.line   3468
mr 3,0
addi 1,31,96
...
bl ._Z17gen_rtx_CONST_INT12machine_modex
nop
mr 0,3
stw 0,0(28)
.line   14
lwz 0,LC..2(2)  <-- line 1495
.eb 14
.line   16
mr 3,0
addi 1,31,96

...
bl ._Z17gen_rtx_CONST_INT12machine_modex
nop
mr 0,3
stw 0,0(28)
.line   14
lwz 0,LC..3(2)  <-- line 1628
.eb 14
.line   16
mr 3,0
addi 1,31,96

gcc-5.5.0 and 7.2.0 errored out in the same way but I am able to build
gcc-8.1.0 successfully. gcc-6.4.0 seems to have built insn-output.c
successfully.

[Bug c++/86562] Missing warning (error in C++11) for passing nontrivial object to varargs function via function pointer

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
 Resolution|INVALID |DUPLICATE

--- Comment #2 from Eric Gallager  ---
I think this is actually a dup of bug 64867

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

[Bug c++/64867] warning for passing non-POD to varargs function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||zhonghao at pku dot org.cn

--- Comment #24 from Eric Gallager  ---
*** Bug 86562 has been marked as a duplicate of this bug. ***

[Bug c++/86562] Missing warning (error in C++11) for passing nontrivial object to varargs function via function pointer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |INVALID

--- Comment #3 from Jonathan Wakely  ---
I disagree. This report states "g++ accepts it, but clang++ rejects it" and
that is not a bug, it's a feature. If a diagnostic is desired it can be
requested with -Wconditionally-supported or -Werror-conditionally-supported

64867 says "It would be nice to have a distinct warning flag for this feature"
which is different.

This bug is invalid.

[Bug bootstrap/68663] Build failure on AIX 7.1

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
I use GCC 4.6 to bootstrap. It appears that the error is caused by the "system"
bootstrap compiler, which I think is GCC 4.4 in your case. It is generating
code with too large displacements.

Also, some of the configure options are unusual.

[Bug c++/64867] warning for passing non-POD to varargs function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #8 from The Written Word  
---
(In reply to The Written Word from comment #6)
> gcc-5.5.0 and 7.2.0 errored out in the same way but I am able to build
> gcc-8.1.0 successfully. gcc-6.4.0 seems to have built insn-output.c
> successfully.

gcc-6.4.0 just died somewhere else with the same error:
g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasync
hronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing
-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-ma
cros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/opt/build/c
hina/gcc-6.4.0/gcc -I/opt/build/china/gcc-6.4.0/gcc/.
-I/opt/build/china/gcc-6.4
.0/gcc/../include -I./../intl
-I/opt/build/china/gcc-6.4.0/gcc/../libcpp/include
 -I/opt/TWWfsw/libgmp61/include -I/opt/TWWfsw/libmpfr31/include
-I/opt/TWWfsw/li
bmpc10/include  -I/opt/build/china/gcc-6.4.0/gcc/../libdecnumber
-I/opt/build/ch
ina/gcc-6.4.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I/opt/build/china/gcc-6
.4.0/gcc/../libbacktrace -I/opt/TWWfsw/libisl016/include  -o rs6000.o -MT
rs6000
.o -MMD -MP -MF ./.deps/rs6000.TPo
/opt/build/china/gcc-6.4.0/gcc/config/rs6000/
rs6000.c
/tmp//ccsn8s2Z.s: Assembler messages:
/tmp//ccsn8s2Z.s:177152: Error: value of 0001 too large for field
of
 2 bytes at 0007e722
/tmp//ccsn8s2Z.s:177680: Error: value of 00010004 too large for field
of
 2 bytes at 0007ed12
/tmp//ccsn8s2Z.s:178850: Error: value of 00010008 too large for field
of
 2 bytes at 0007fb5e
/tmp//ccsn8s2Z.s:179521: Error: value of 0001000c too large for field
of
 2 bytes at 00080246
...

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #9 from The Written Word  
---
(In reply to David Edelsohn from comment #7)
> I use GCC 4.6 to bootstrap. It appears that the error is caused by the
> "system" bootstrap compiler, which I think is GCC 4.4 in your case. It is
> generating code with too large displacements.
> 
> Also, some of the configure options are unusual.

Ok, will try something later than 4.4. Thanks.

[Bug target/86555] unaligned address for ldrd/strd on armv5e

[raj.khem at gmail dot com]

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

--- Comment #2 from Khem Raj  ---
we can avoid the problem by altering the structure, thats not an issue, but do
you think compiler is right here by assuming to generate LDRD on a 4byte
aligned address when it is told that architecture (-march=armv5te) its building
for does not support 4byte aligned address for LDRD but only 8-byte aligned ?

[Bug c++/86567] [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed (both the error and that maybe_constant_value has a cache).

$ cat t.C && gcc -S -fcompare-debug=-Wrestrict t.C
#include 

std::vector
f()
{
  std::vector r;
  return r;
}
xg++: error: t.C: -fcompare-debug failure

[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3

[amonakov at gcc dot gnu.org]

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

--- Comment #7 from Alexander Monakov  ---
cp/mangle.o miscompares due to -Wsign-compare, possibly due to caching in
maybe_constant_value as in the above PR.

[Bug target/86555] unaligned address for ldrd/strd on armv5e

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #3 from Bernd Edlinger  ---
(In reply to Khem Raj from comment #2)
> we can avoid the problem by altering the structure, thats not an issue, but
> do you think compiler is right here by assuming to generate LDRD on a 4byte
> aligned address when it is told that architecture (-march=armv5te) its
> building for does not support 4byte aligned address for LDRD but only 8-byte
> aligned ?

the structure has to be aligned by 8 bytes. (due to the long long member)
Therefore the compiler assumes that the DIR->lock is also aligned by 8 bytes.
I do not see why lock[2] vs. lock[1] makes a difference.
If you cannot make it aligned, you need to mark the structure with
__attribute__((__packed__)) for instance.

[Bug target/86555] unaligned address for ldrd/strd on armv5e

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  ---

(In reply to Khem Raj from comment #2)
> we can avoid the problem by altering the structure, thats not an issue, but
> do you think compiler is right here by assuming to generate LDRD on a 4byte
> aligned address when it is told that architecture (-march=armv5te) its
> building for does not support 4byte aligned address for LDRD but only 8-byte
> aligned ?

It is correct for the compiler to be doing this - the compiler has just not
been given enough information. buf can only get aligned to 8 bytes if there is
an input attribute setting the alignment properly otherwise it's a char array
and the compiler is within it's rights not to have to force align upwards to 8
bytes in this case. When the compiler is derefencing de->d_off it expects it to
be naturally 8 byte aligned. 


Fix the source.

[Bug c++/86568] New: -Wnonnull warnings should highlight the relevant argument not the closing parenthesis

[redi at gcc dot gnu.org]

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

Bug ID: 86568
   Summary: -Wnonnull warnings should highlight the relevant
argument not the closing parenthesis
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

void f(void*, void*) __attribute__((nonnull(2)));

struct A {
  void f(void*, void*) __attribute__((nonnull(2)));
};

int main()
{
  f(0, 0);
  A().f(0, 0);
}

nonnull.cc: In function 'int main()':
nonnull.cc:9:9: warning: null argument where non-null required (argument 2)
[-Wnonnull]
   f(0, 0);
 ^
nonnull.cc:10:13: warning: null argument where non-null required (argument 2)
[-Wnonnull]
   A().f(0, 0);
 ^


The location of the caret diagnostic is not helpful. It's especially confusing
for member functions where the argument number includes the implicit 'this'
parameter.

Expected result:

nonnull.cc: In function 'int main()':
nonnull.cc:9:9: warning: null argument where non-null required (argument 2)
[-Wnonnull]
   f(0, 0);
^
nonnull.cc:10:13: warning: null argument where non-null required (argument 2)
[-Wnonnull]
   A().f(0, 0);
 ^

[Bug libstdc++/86450] Bootstrap failure due to -Wabi

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
No, I needed far more than that. Obviously I needed the right versions of
autoconf and automake first in my PATH, which is simple. But I also needed to
use contrib/gcc_update to fix all the timestamps, so that there weren't loads
of errors caused by reconf'ing files in libbacktrace, zlib and lto-plugin.

contrib/gcc_update prevented those, but that means a simple "svn up" or "git
pull" doesn't work when using maintainer mode, and the script can't be used if
you have any uncommitted changes in a git tree.

After solving those issues I got a load of errors from libtool macros:

configure.ac:40: warning: macro `AM_PROG_LIBTOOL' not found in library

I have no idea what that's caused by. Obviously I have libtool installed (in
/usr/bin and I also tried a symlink to it in /opt/autotools-gcc/bin where I
have the old versions of autoconf and automake). I'm not aware of any
dependency on a specific libtool version.

[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #10 from Paolo Carlini  ---
Fixed.

[Bug c++/86569] New: -Wnonnull-compare affects code generation

[amonakov at gcc dot gnu.org]

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

Bug ID: 86569
   Summary: -Wnonnull-compare affects code generation
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

bool b;

int main ()
{
  return ((!b) != 0);
}

ICEs with g++ -fcompare-debug=-Wnonnull-compare (this is bool6.C in the
testsuite). It looks as if the warning prevents folding '!b != 0' to '!b'.

[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
Other files seem to miscompare due to -Wnonnull-compare: PR 86569.

[Bug target/86555] unaligned address for ldrd/strd on armv5e

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #5 from Rich Felker  ---
Indeed this is a bug in musl, not gcc. The alignment requirement of the type is
8 so the compiler is completely justified in generating loads and stores that
require such alignment. I'll fix it on our side.

[Bug fortran/86566] The preprocessor cpp6 loses line concatenation on FreeBSD

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
The proper way to preprocess Fortran code is with the Fortran
compiler.  You can and should use 'gfortran -cpp'.  See the
documentation that comes with your compiler.

If you think you need to use gcc, then you must use the
--tradition-cpp option.  The Fortran concatenation operator
// conflicts with modern C's comment delimiter //.

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor  ---
Author: msebor
Date: Wed Jul 18 17:20:05 2018
New Revision: 262859

URL: https://gcc.gnu.org/viewcvs?rev=262859&root=gcc&view=rev
Log:
Backport from trunk.

PR middle-end/85602 - -Wsizeof-pointer-memaccess for strncat with size of
source

gcc/c-family/ChangeLog:

PR middle-end/85602
* c-warn.c (sizeof_pointer_memaccess_warning): Check for attribute
nonstring.

gcc/ChangeLog:

PR middle-end/85602
* calls.c (maybe_warn_nonstring_arg): Handle strncat.
* tree-ssa-strlen.c (is_strlen_related_p): Make extern.
Handle integer subtraction.
(maybe_diag_stxncpy_trunc): Handle nonstring source arguments.
* tree-ssa-strlen.h (is_strlen_related_p): Declare.
* doc/invoke.texi (-Wstringop-truncation): Update.

gcc/testsuite/ChangeLog:

PR middle-end/85602
* gcc.dg/attr-nonstring-2.c: Adjust text of expected warning.
* c-c++-common/attr-nonstring-8.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/attr-nonstring-8.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/c-family/ChangeLog
branches/gcc-8-branch/gcc/c-family/c-warn.c
branches/gcc-8-branch/gcc/calls.c
branches/gcc-8-branch/gcc/doc/invoke.texi
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-ssa-strlen.c
branches/gcc-8-branch/gcc/tree-ssa-strlen.h

[Bug tree-optimization/86570] New: Conditional statement doesn't trigger sincos transform

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 86570
   Summary: Conditional statement doesn't trigger sincos transform
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

For the following test-case:

double f2(double x, double a, double b)
{
  if (a == b)
return __builtin_sin (a * x) + __builtin_cos (b * x);
  return 0;
}

Optimized dump with -O2 -ffast-math -funsafe-math-optimizations yields:

f2 (double x, double a, double b)
{
  double _1;
  double _2;
  double _3;
  double _4;
  double _5;
  double _9;

   [local count: 1073741825]:
  if (a_6(D) == b_7(D))
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 365072220]:
  _1 = a_6(D) * x_8(D);
  _2 = __builtin_sin (_1);
  _3 = b_7(D) * x_8(D);
  _4 = __builtin_cos (_3);
  _9 = _2 + _4;

   [local count: 1073741825]:
  # _5 = PHI <_9(3), 0.0(2)>
  return _5;

}

I assume the sincos transform would have been valid in the above case ?
Similarly missed for the divmod transform.

Thanks,
Prathamesh

[Bug tree-optimization/86571] New: AIX NaNQ and NaNS output format conflicts with __builtin_sprintf

[dje at gcc dot gnu.org]

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

Bug ID: 86571
   Summary: AIX NaNQ and NaNS output format conflicts with
__builtin_sprintf
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

AIX sprintf generates NaNQ and NaNS, probably as extensions defined by IBM XL
Fortran. The recent __builtin_sprintf optimization assumes a 3 character output
of "nan" or "NAN".  NAN(S) and NAN(Q) optionally may be allowed. IBM libc is
unlikely to change because customers depend on the current extension.

[Bug tree-optimization/86571] AIX NaNQ and NaNS output format conflicts with __builtin_sprintf

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-18
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug tree-optimization/86572] New: unsafe strlen folding of const arguments with non-const offset

[msebor at gcc dot gnu.org]

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

Bug ID: 86572
   Summary: unsafe strlen folding of const arguments with
non-const offset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This came up in a conversation of a change in this area (bug 86532).  The
following test case has undefined behavior so anything can happen, but the
result in GCC is unnecessarily and arbitrarily "hostile" in that the value
computed by the strlen expression is excessive large, so large in fact as to be
meaningless (no object can be as large as 18446744073709551615 or SIZE_MAX
bytes).

$ cat c.c && gcc -Wall -fdump-tree-gimple=/dev/stdout c.c && ./a.out 
const char a[] = "123";

__attribute__ ((noipa))
__SIZE_TYPE__ f (int i)
{
  return __builtin_strlen (a + i);
}

int main (void)
{
  __SIZE_TYPE__ n = f (4);

  __builtin_printf ("%zu\n", n);
}
__attribute__((noipa, noinline, noclone, no_icf))
f (int i)
{
  long unsigned int D.1964;

  _1 = (ssizetype) i;
  _2 = 3 - _1;   // strlen folded into this
  D.1964 = (long unsigned int) _2;
  return D.1964;
}


main ()
{
  int D.1966;

  {
long unsigned int n;

n = f (4);
__builtin_printf ("%zu\n", n);
  }
  D.1966 = 0;
  return D.1966;
}


18446744073709551615

[Bug tree-optimization/86572] unsafe strlen folding of const arguments with non-const offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
See also bug 86434 which discusses another couple of problems with this
transformation.  The solution in this case isn't necessarily to defer the
folding until later but do it in a way that avoids these excessive results for
undefined input.  For example, returning zero would be safer and in line with
what GCC does in other cases, such as in some instances of out-of-bounds array
accesses:

$ cat c.c && gcc -O2 -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c
const char a[4] = { 1, 2, 3 };

int f (void)
{
  return a[8];   // missing -Warray-bounds, folded to zero
}

;; Function f (f, funcdef_no=0, decl_uid=1899, cgraph_uid=1, symbol_order=1)

f ()
{
   [local count: 1073741825]:
  return 0;

}

[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).

[jg at jguk dot org]

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

--- Comment #14 from Jonny Grant  ---
Hello Richard

My archive of the original problem didn't show it. But when I tried to
re-create I got the following. I'll try also make a small test case for this
one while I have it.

/usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Could not find abbrev number 120.

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[msebor at gcc dot gnu.org]

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

--- Comment #27 from Martin Sebor  ---
I don't think it would be appropriate to introduce dependencies on the
sanitizer for the same reason we can't do that for warnings.  But as I
mentioned in comment 16, I think performing these sorts of simplifications this
early (this one it happens during parsing) prevents subsequent analysis from
making use of the information that can be derived from in the original code. 
Deferring this non-constant folding until later (see bug 86434) would make it
possible not only to detect some of these bugs but also transform them into
traps/unreachable without any runtime overhead (when we know the non-constant
offset's range is out-of-bounds).

I did the comparison in signed because that's what the function returns but I
do agree that folding to zero rather than arbitrary value.  I opened bug 86572
for this idea.  Let me propose making the change separately (here I just want
to fix the wrong code without preventing  existing optimizations).  I would
also be open to emitting __builtin_unreachable().

The chartype loop needs to change to avoid assuming the element type is
necessarily an integer type.  I can reproduce the problem on my local machine
but I don't know why the full regression test run that I run on my team's
server didn't expose this or the previous ICE.  I'll look into it.

I very much appreciate your testing and feedback.  I would just ask you to
comment on the patch on the list so we don't clutter with details that are not
important to the record of the bug.

[Bug fortran/85599] warn about short-circuiting of logical expressions for non-pure functions

[janus at gcc dot gnu.org]

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

--- Comment #37 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Jul 18 18:31:59 2018
New Revision: 262860

URL: https://gcc.gnu.org/viewcvs?rev=262860&root=gcc&view=rev
Log:
2018-07-18  Janus Weil  
Thomas Koenig  

PR fortran/85599
* dump-parse-tree.c (show_attr): Add handling of implicit_pure.
* frontend-passes.c (do_warn_function_elimination): Do not warn for
pure functions.
* gfortran.h: Add prototypes for gfc_pure_function and
gfc_implicit_pure_function.
* gfortran.texi: Add chapter on evaluation of logical expressions.
* invoke.texi: Mention that -Wfunction-elimination is implied
by -Wextra.
* lang.opt: Make -Wextra imply -Wfunction-elimination.
* resolve.c (pure_function): Rename to gfc_pure_function.
(gfc_implicit_pure_function): New function.
(check_pure_function): Use it here.
(impure_function_callback): New function.
(resolve_operator): Call it via gfc_expr_walker.


2018-07-18  Janus Weil  

PR fortran/85599
* gfortran.dg/function_optimize_5.f90: Add option
'-faggressive-function-elimination' and update dg-warning clauses.
* gfortran.dg/short_circuiting.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/short_circuiting.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/function_optimize_5.f90

[Bug tree-optimization/86571] AIX NaNQ and NaNS output format conflicts with __builtin_sprintf

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
The test below fails because of this discrepancy:

  FAIL: gcc.dg/torture/builtin-sprintf.c   -O0  execution test

GCC should relax the upper bound on the amount of output for NaN.  The standard
specifies two forms of output "nan" or "nan(n-char-sequence)"  The latter
doesn't seem to be output by any known implementations (plus the length of the
n-char-sequence is unspecified, making it useless for portability) and there
have been voices to deprecate or remove it from the C standard.  I plan to
propose one of the two for C2X.  Until then, bumping up the upper bound either
for all targets, or just for AIX (under some sort of a target hook) is probably
the best solution.

[Bug c++/86569] -Wnonnull-compare affects code generation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-18
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86567
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  See also bug 86567.

$ cat t.C && gcc -S -fcompare-debug=-Wnonnull-compare t.C

bool b;

int main ()
{
  return ((!b) != 0);
}
xg++: error: t.C: -fcompare-debug failure (length)

[Bug c++/86573] New: Failure to optimise passing simple values to inlined function

[s_gccbugzilla at nedprod dot com]

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

Bug ID: 86573
   Summary: Failure to optimise passing simple values to inlined
function
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

#include 

inline size_t calc(std::string a, std::string b)
{
return a.size() + b.size();
}

int main()
{
std::string a = "Hello world", b = "Goodbye world";
return calc(std::move(a), std::move(b));
}

This should generate:

main:   # @main
mov eax, 24
ret

Like clang does. See https://godbolt.org/g/EAggKH.

But it instead generates this spew with gcc trunk:

https://godbolt.org/g/3LmfTc

Also it should generate the above return of 24 if passing by value. clang
currently fails that, I have reported a bug to them about it.

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[bernd.edlinger at hotmail dot de]

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

--- Comment #28 from Bernd Edlinger  ---
Yes, agreed.

Should I send a patch to take out the statement in comment #17,
or will you do that in your follow-up patch?

[Bug bootstrap/81397] mistakes in .opt files not detected

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Liška from comment #1)
> You are right, various checking can be done with option handling. Let me
> take it, can be subject for GCC 9.

Changing status to ASSIGNED since you put yourself as the assignee

[Bug c++/86573] Failure to optimise passing simple values to inlined function

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Try renaming 'main' to any other name and gcc does optimize...

[Bug c++/86574] New: ICE on std::prev with ranges::view::transform

[tower120 at gmail dot com]

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

Bug ID: 86574
   Summary: ICE on std::prev with ranges::view::transform
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tower120 at gmail dot com
  Target Milestone: ---

The following code cause ICE on gcc 9. And have malfunction build on all 
previous versions (program compiles, but hangs); clang compiles with error
about bidirectional iterator.

https://wandbox.org/permlink/bPT0llOGPqouv3CM

#include 
#include 
#include 


struct Data{
int x,y;
};

int main() {
std::vector datas = { Data{0,1}, Data{1,2}, Data{1,3} };

const auto xs = datas
| ranges::view::transform([](const Data& data) -> int{
return data.x; });

// no compiler errors / ICEs, but assembled executable - malfunction -
// program hungs, as soon as reach std::prev
//auto j = std::prev(xs.end());  

auto j = std::prev(xs.end(), 1);

std::cout << "Done" << std::endl;

return 0;
}


Error message:

In file included from
/opt/wandbox/range-v3/include/range/v3/view/transform.hpp:26,
 from prog.cc:3:
/opt/wandbox/range-v3/include/range/v3/view_adaptor.hpp: In instantiation of
'constexpr ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor
>::adaptor_cursor(Args&& ...) [with Args = {__gnu_cxx::__normal_iterator > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor};
typename
meta::v1::detail::_if_::type::value ...>, std::integer_sequence::type::value) || true ...> >, int>,
std::integral_constant >::type  = 0][inherited from
ranges::v3::compressed_tuple_detail::compressed_tuple_ > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >,
std::integer_sequence >]':
/opt/wandbox/range-v3/include/range/v3/view_adaptor.hpp:183:16:   required from
'constexpr ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor
>::adaptor_cursor(Args&& ...) [with Args = {__gnu_cxx::__normal_iterator > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor};
typename
meta::v1::detail::_if_::type::value ...>, std::integer_sequence::type::value) || true ...> >, int>,
std::integral_constant >::type  = 0][inherited from
ranges::v3::compressed_tuple_detail::compressed_tuple_ > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >,
std::integer_sequence >]'
/opt/wandbox/range-v3/include/range/v3/view_adaptor.hpp:405:63:   required from
'static constexpr ranges::v3::adaptor_cursor_t
ranges::v3::view_adaptor::begin_cursor_(D&) [with D =
const
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; Derived =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; BaseRng =
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >;
ranges::v3::cardinality Cardinality = (ranges::v3::cardinality)-1;
ranges::v3::adaptor_cursor_t =
ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >;
typename std::decay(), 42))>::type =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor;
typename std::decay(),
42))>::type>().begin(declval()))>::type =
__gnu_cxx::__normal_iterator >]'
/opt/wandbox/range-v3/include/range/v3/view_adaptor.hpp:423:13:   required by
substitution of 'template > >, __gnu_cxx::__normal_iterator > > >,
ranges::v3::indirected > > >::type() &&
ranges::v3::concepts::models > >, __gnu_cxx::__normal_iterator > > > >())), void>::type*  >
constexpr decltype
(ranges::v3::view_adaptor >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >,
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >,
(ranges::v3::cardinality)-1>::begin_cursor_(declval()))
ranges::v3::view_adaptor >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >,
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >,
(ranges::v3::cardinality)-1>::begin_cursor >() const [with D =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; bool
_concept_requires_421 = false; typename std::enable_if<(_concept_requires_421
|| (typename ranges::v3::concepts::Same::same > >, __gnu_cxx::__normal_iterator > > >,
ranges::v3::indirected > > >::type() &&
ranges::v3::concepts::model

[Bug c++/86573] Failure to optimise passing simple values to inlined function

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
When passing by copy, gcc seems to manage with default flags, but your
-std=c++2a -fno-exceptions hinder it somehow.

[Bug middle-end/86575] New: -Wimplicit-fallthrough affects code generation

[amonakov at gcc dot gnu.org]

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

Bug ID: 86575
   Summary: -Wimplicit-fallthrough affects code generation
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

void
f2 (int a, int b, int c, int d)
{
  switch (b)
{
default:
  for (int e = 0; e < c; ++e)
if (e == d)
  break;
}
}

ICEs as both C and C++ using 'gcc -fcompare-debug=-Wimplicit-fallthrough'. This
is minimized from pr81275-1.C in the testsuite (the -2 and -3 variants of the
original test also fail).

[Bug tree-optimization/86573] Failure to optimise passing simple values to inlined function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |RESOLVED
  Component|c++ |tree-optimization
Version|tree-ssa|7.0
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
Using f instead of main allows it be optimized so closing as invalid.  NOTE GCC
has a heuristic around main function being done as ever called once so it does
less inlining into it.

[Bug tree-optimization/86570] Conditional statement doesn't trigger sincos transform (with -ffast-math)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-18
Summary|Conditional statement   |Conditional statement
   |doesn't trigger sincos  |doesn't trigger sincos
   |transform   |transform (with
   ||-ffast-math)
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
-0.0 == 0.0 so definitely -ffast-math is required.

Basically many floating point replacement like this is not done.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[clhamilto at gmail dot com]

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

--- Comment #8 from Curtis Hamilton  ---
Based on you last comment, I attempted a build using FreeBSD 11.2 RC1 on the
same hardware (PowerMac G5 Quad) and got the same results.

Are you using native hardware or emulation?

[Bug c/69558] [6/7/8/9 Regression] glib2 warning pragmas stopped working

[edlinger at gcc dot gnu.org]

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

--- Comment #25 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Jul 18 19:36:01 2018
New Revision: 262861

URL: https://gcc.gnu.org/viewcvs?rev=262861&root=gcc&view=rev
Log:
libcpp:
2018-07-18  Bernd Edlinger  

PR 69558
* macro.c (enter_macro_context): Change the location info for builtin
macros and _Pragma from location of the closing parenthesis to location
of the macro expansion point.

testsuite:
2018-07-18  Bernd Edlinger  

PR 69558
* c-c++-common/cpp/diagnostic-pragma-2.c: New test.
* c-c++-common/pr69558.c: Remove xfail.
* gcc.dg/cpp/builtin-macro-1.c: Adjust test expectations.
* gcc.dg/pr61817-1.c: Likewise.
* gcc.dg/pr61817-2.c: Likewise.
* g++.dg/plugin/pragma_plugin.c: Warn at expansion_point_location.

Added:
trunk/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69558.c
trunk/gcc/testsuite/g++.dg/plugin/pragma_plugin.c
trunk/gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c
trunk/gcc/testsuite/gcc.dg/pr61817-1.c
trunk/gcc/testsuite/gcc.dg/pr61817-2.c
trunk/libcpp/ChangeLog
trunk/libcpp/macro.c

[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3

[amonakov at gcc dot gnu.org]

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

--- Comment #9 from Alexander Monakov  ---
One more: -Wimplicit-fallthrough issue uncovered by the testsuite: PR 86575.

So far all issues appeared in gcc-6 or more recent.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor  ---
I haven't tried to recreate the problem on FreeBSD.  I've just tried various
inputs to GCC 7 -fgo-dump-spec.

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #11 from The Written Word  
---
(In reply to Jonathan Wakely from comment #7)
> As I suspected, something is doing:
> 
> #define fabsl(X) fabs((double) (X))
> #define acosl(X) acos((double) (X))
> etc.
> 
> This would probably be solved by any fix for PR 79700, which would have to
> add this to :
> 
> #undef fabsl
> 
> But I'm not sure when PR 79700 will get fixed.

Is it just a matter of someone finding the time to fix 79700 or is it just too
low a priority?

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[clhamilto at gmail dot com]

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

--- Comment #10 from Curtis Hamilton  ---
Is it -fgo-dump-spec or -fdump-go-spec?  Below is an extract of my build log:

checking for hypotf... /usr/ports/lang/gcc7/work/.build/./gcc/xgcc
-B/usr/ports/lang/gcc7/work/.build/./gcc/
-B/usr/local/powerpc64-portbld-freebsd11.2/bin/
-B/usr/local/powerpc64-portbld-freebsd11.2/lib/ -isystem
/usr/local/powerpc64-portbld-freebsd11.2/include -isystem
/usr/local/powerpc64-portbld-freebsd11.2/sys-include-DHAVE_CONFIG_H -I.
-I/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo  -I
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/runtime
-I/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/../libffi/include
-I../libffi/include -pthread  -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O -fdump-go-spec=tmp-gen-sysinfo.go -std=gnu99 -S -o
sysinfo.s /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/sysinfo.c
yes
checking for hypot... rm -f sysinfo.s
/bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/mvifdiff.sh
tmp-gen-sysinfo.go gen-sysinfo.go
echo timestamp > s-gen-sysinfo
rm -f libcalls.go.tmp
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/../install-sh -c -d runtime/internal;
dir=`echo runtime/internal/sys.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/match.sh --goarch=ppc64
--goos=freebsd --srcdir=/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/$dir
--extrafiles="version.go" `; /bin/sh
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/godeps.sh `echo
runtime/internal/sys.lo.dep | sed -e 's/.dep$//'` $files >
runtime/internal/sys.lo.dep.tmp; if ! cmp runtime/internal/sys.lo.dep.tmp
runtime/internal/sys.lo.dep >/dev/null 2>/dev/null; then rm -f `echo
runtime/internal/sys.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f
runtime/internal/sys.lo.dep.tmp runtime/internal/sys.lo.dep
/usr/bin/awk -f
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/mksyscall.awk `cat
libcalls-list` > libcalls.go.tmp
/bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/mksysinfo.sh
/bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/mvifdiff.sh libcalls.go.tmp
libcalls.go
echo timestamp > s-libcalls
/bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/mkrsysinfo.sh

[Bug c++/86574] ICE on std::prev with ranges::view::transform

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-07-18
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: range/v3/view/transform.hpp: No such file or directory

Please provide a preprocessed source file so that we can reproduce.