[Bug c++/80655] -Werror=format-truncation inconsistency between x86_32 and x86_64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #5 from Andrew Pinski  ---
Hmm,
  _58 = operator new (_5);
  __builtin_memset (_58, 0, _5);
  _6 = *args#0_11(D);
  _7 = (int) _6;
  snprintf (_58, _5, format_13(D), _7);


I don't see how -m32 could change the above IR.

[Bug c++/80655] -Werror=format-truncation inconsistency between x86_32 and x86_64

[krejzi at email dot com]

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

--- Comment #4 from Armin K.  ---
There is a log file in the tarball with all the options. Package is built with
cmake, so there's lot of them.

[Bug c++/80655] -Werror=format-truncation inconsistency between x86_32 and x86_64

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Also what options is being used to invoke GCC?

[Bug c/80659] New: [7 regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[jim at meyering dot net]

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

Bug ID: 80659
   Summary: [7 regression] -fsanitize=address evokes ICE in in
gimplify_switch_expr
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim at meyering dot net
  Target Milestone: ---

The following gets an ICE with gcc 7 (latest from git at git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/trunk@247659
138bc75d-0d04-0410-961f-82ee72b054a4), yet gets no ICE with fedora 25's 6.3.1
20161221.
FYI, this was minimized using creduce from emacs/src/process.c.

$ cat bad.c
typedef a;
typedef b;
struct c {
  b d
} e() {
  union {
struct c f
  } g;
  switch (g.f.d) {
(a[]){};
h();
  }
}
$ gcc -c -fsanitize=address bad.c  
bad.c:1:9: warning: type defaults to 'int' in declaration of 'a'
[-Wimplicit-int]
 typedef a;
 ^
bad.c:2:9: warning: type defaults to 'int' in declaration of 'b'
[-Wimplicit-int]
 typedef b;
 ^
bad.c:5:1: warning: no semicolon at end of struct or union
 } e() {
 ^  
bad.c: In function 'e':
bad.c:8:3: warning: no semicolon at end of struct or union
   } g;
   ^
bad.c:11:5: warning: implicit declaration of function 'h'
[-Wimplicit-function-declaration]
 h();
 ^
bad.c:10:10: warning: statement will never be executed [-Wswitch-unreachable]
 (a[]){};
  ^
bad.c:9:3: internal compiler error: in gimplify_switch_expr, at gimplify.c:2301
   switch (g.f.d) {
   ^~
0x7c6d6d gimplify_switch_expr
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:2301
0x7c890a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:11466
0x7ca888 gimplify_stmt(tree_node**, gimple**)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:6517
0x7c8e6b gimplify_statement_list
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:1718
0x7c8e6b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:11686
0x7ca888 gimplify_stmt(tree_node**, gimple**)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:6517
0x7cb1c8 gimplify_bind_expr
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:1292
0x7c86ea gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:11458
0x7ca888 gimplify_stmt(tree_node**, gimple**)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:6517
0x7cbbe7 gimplify_body(tree_node*, bool)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:12455
0x7cbf95 gimplify_function_tree(tree_node*)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:12613
0x69cf0f cgraph_node::analyze()
/data/users/meyering/x/w/co/gcc/gcc/cgraphunit.c:657
0x69f6f7 analyze_functions
/data/users/meyering/x/w/co/gcc/gcc/cgraphunit.c:1118
0x6a00d2 symbol_table::finalize_compilation_unit()
/data/users/meyering/x/w/co/gcc/gcc/cgraphunit.c:2603
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/80658] New: Memory leak reported in libstdc++ (zerotier)

[bernd at net2o dot de]

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

Bug ID: 80658
   Summary: Memory leak reported in libstdc++ (zerotier)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd at net2o dot de
  Target Milestone: ---

This not very friendly blog entry contains a report of a memory leak in
libstdc++ ("worst bug of my entire career"):

https://www.zerotier.com/blog/2017-05-05-theleak.shtml

Including a not very easy way to reproduce it (by installing their software and
stress-testing it).  Apparently he didn't file a bug report here.

Solution proposed there: link against jemalloc (it's under BSDL), performance
goes up, memory consumption stays low, i.e. neither use glibc's "too slow"
malloc() nor use libstdc++'s memory allocator (still slower than jemalloc).

I don't like this discovery at all, because the implications are too bad...

1. Using your own allocator by default renders tools like valgrind blind.
2. Having two allocators means two times the possibility for bugs.  Actually
having about 10 different allocators is even worse ;-).
3. If glibc's malloc is slow, make it faster, don't implement your own
allocator.

There are some limited valid reasons to create your own allocator, but
stdlibc++ shouldn't do that by default.  Especially if multi-threading speed of
glibc is too slow, please just fix glibc.

Due to #1, we don't even know how many people are affected by the bug.  Memory
leaks caused by the allocator itself aren't detectable by tools that replace
the allocator to find memory leaks (like valgrind), and what's worse: valgrind
doesn't help people to find memory leaks they caused themselves in libstdc++.

I assume that the mt_allocator is used here, because it is easiest to screw up
a multithreaded allocator.  Things that can go wrong:

* the handover from local free list to global free list doesn't work as it
should (forgets to add free stuff, race conditions)
* the access to the global free list doesn't work as it should (more race
conditions possible).
* threads terminating forget to merge their free list
* allocating big chunks of memory will not be shared in the global freelist, as
only few allocations happen, not enough to exceed the limit of the local
freelist
...

The documentation of mt_allocator is at least somewhat misleading:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/mt_allocator_impl.html

"Notes about deallocation. This allocator does not explicitly release memory."

Well, it does add freed memory to its freelists and reuse it.  It's just not
giving back unused memory to the OS.  However, for bigger allocation, using
mmap() and returning the memory to the OS on free is a very good idea.

Related: I have some griefs with glibc's malloc, as well. If you turn on
debugging, so that your program doesn't get a C abort() and could print it's
own diagnostics (usually you want that when you discover that there are memory
corruption bugs), malloc() stops being thread-safe.  That is just not at all
helpful.  I worked around this by wrapping malloc(), resize() and free() in a
critical section when malloc() debugging is enabled. Ulrich Drepper had that as
"wontfix", because he somehow couldn't see how to implement it.  Note that the
debugging version of malloc() doesn't have to be ultra-fast.  It's there for
debugging.  It can lock a mutex on every call.

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

[Keith.S.Thompson at gmail dot com]

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

--- Comment #4 from Keith Thompson  ---
Then what does

> Issues with DR, accepted, DRWP, and WP status are NOT part of the 
> International Standard for C++.

mean?  The web page itself says that issues with DR status are not
part of C++11.

[Bug tree-optimization/67213] When compiling for size with -Os loops can get bigger after peeling

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #6 from Fredrik Hederstierna 
 ---
Same thing for x86, not only ARM:


bash# gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609


bash# gcc -c test.c -Os --param max-completely-peel-times=5
bash# objdump -dath test.o


Disassembly of section .text:

000f :
   f:   c6 05 00 00 00 00 00movb   $0x0,0x0(%rip)# 16

  16:   c6 05 00 00 00 00 01movb   $0x1,0x0(%rip)# 1d

  1d:   c6 05 00 00 00 00 02movb   $0x2,0x0(%rip)# 24

  24:   c6 05 00 00 00 00 03movb   $0x3,0x0(%rip)# 2b

  2b:   c6 05 00 00 00 00 04movb   $0x4,0x0(%rip)# 32

  32:   c6 05 00 00 00 00 05movb   $0x5,0x0(%rip)# 39

  39:   c3  retq   


bash# gcc -c test.c -Os --param max-completely-peel-times=4
bash# objdump -dath test.o


Disassembly of section .text:

000f :
   f:   31 c0   xor%eax,%eax
  11:   88 80 00 00 00 00   mov%al,0x0(%rax)
  17:   48 ff c0inc%rax
  1a:   48 83 f8 06 cmp$0x6,%rax
  1e:   75 f1   jne11 
  20:   c3  retq

[Bug tree-optimization/67213] When compiling for size with -Os loops can get bigger after peeling

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #5 from Fredrik Hederstierna 
 ---
Still same in GCC-7.1.0.

I analyzed using -fdump-tree-cunroll-details

void test_iter_6(void)
{
  int i;
  for (i = 0; i < 6; i++) {
data[i] = i;
  }
}

The function was generated "test_iter_6":

001c :
  1c:   e59f3030ldr r3, [pc, #48]   ; 54 
  20:   e3a02000mov r2, #0
  24:   e5c32000strbr2, [r3]
  28:   e3a02001mov r2, #1
  2c:   e5c32001strbr2, [r3, #1]
  30:   e3a02002mov r2, #2
  34:   e5c32002strbr2, [r3, #2]
  38:   e3a02003mov r2, #3
  3c:   e5c32003strbr2, [r3, #3]
  40:   e3a02004mov r2, #4
  44:   e5c32004strbr2, [r3, #4]
  48:   e3a02005mov r2, #5
  4c:   e5c32005strbr2, [r3, #5]
  50:   e12fff1ebx  lr
  54:   .word   0x

With "--param max-completely-peel-times=4" (instead of default 5) it became

001c :
  1c:   e59f2014ldr r2, [pc, #20]   ; 38 
  20:   e3a03000mov r3, #0
  24:   e7c33002strbr3, [r3, r2]
  28:   e2833001add r3, r3, #1
  2c:   e3530006cmp r3, #6
  30:   1afbbne 24 
  34:   e12fff1ebx  lr
  38:   .word   0x

It seems like "try_unroll_loop_completely()" in file "tree-ssa-loop-ivcanon.c"
think it could fold counting variable, but maybe its not possible since its
used as both index and as RHS value?

;; Function test_iter_6 (test_iter_6, funcdef_no=1, decl_uid=4067,
cgraph_uid=1)

Analyzing # of iterations of loop 1
  exit condition [5, + , 4294967295] != 0
  bounds on difference of bases: -5 ... -5
  result:
# of iterations 5, bounded by 5
Analyzing # of iterations of loop 1
  exit condition [5, + , 4294967295] != 0
  bounds on difference of bases: -5 ... -5
  result:
# of iterations 5, bounded by 5
Statement (exit)if (ivtmp_7 != 0)
 is executed at most 5 (bounded by 5) + 1 times in loop 1.
Induction variable (int) 0 + 1 * iteration does not wrap in statement data[i_9]
= _4;
 in loop 1.
Statement data[i_9] = _4;
 is executed at most 9 (bounded by 9) + 1 times in loop 1.
Induction variable (int) 1 + 1 * iteration does not wrap in statement i_6 = i_9
+ 1;
 in loop 1.
Statement i_6 = i_9 + 1;
 is executed at most 2147483646 (bounded by 2147483646) + 1 times in loop 1.
Loop 1 iterates 5 times.
Loop 1 iterates at most 5 times.
Estimating sizes for loop 1
 BB: 3, after_exit: 0
  size:   0 _4 = (char) i_9;
   Induction variable computation will be folded away.
  size:   1 data[i_9] = _4;
  size:   1 i_6 = i_9 + 1;
   Induction variable computation will be folded away.
  size:   1 ivtmp_7 = ivtmp_1 - 1;
   Induction variable computation will be folded away.
  size:   2 if (ivtmp_7 != 0)
   Exit condition will be eliminated in peeled copies.
 BB: 4, after_exit: 1
size: 5-4, last_iteration: 5-2
  Loop size: 5
  Estimated size after unrolling: 5

Though produced code with peeling become

test_iter_6 ()
{
  int i;
  char _4;
  unsigned int ivtmp_7;
  char _12;
  unsigned int ivtmp_15;
  char _19;
  unsigned int ivtmp_22;
  char _26;
  unsigned int ivtmp_29;
  char _33;
  unsigned int ivtmp_36;
  char _40;
  unsigned int ivtmp_43;

  :
  _12 = 0;
  data[0] = _12;
  i_14 = 1;
  ivtmp_15 = 5;
  _19 = (char) i_14;
  data[i_14] = _19;
  i_21 = i_14 + 1;
  ivtmp_22 = ivtmp_15 + 4294967295;
  _26 = (char) i_21;
  data[i_21] = _26;
  i_28 = i_21 + 1;
  ivtmp_29 = ivtmp_22 + 4294967295;
  _33 = (char) i_28;
  data[i_28] = _33;
  i_35 = i_28 + 1;
  ivtmp_36 = ivtmp_29 + 4294967295;
  _40 = (char) i_35;
  data[i_35] = _40;
  i_42 = i_35 + 1;
  ivtmp_43 = ivtmp_36 + 4294967295;
  _4 = (char) i_42;
  data[i_42] = _4;
  i_6 = i_42 + 1;
  ivtmp_7 = ivtmp_43 + 4294967295;
  return;

}

instead of original and shorter

test_iter_6 ()
{
  int i;
  unsigned int ivtmp_1;
  char _4;
  unsigned int ivtmp_7;

  :

  :
  # i_9 = PHI 
  # ivtmp_1 = PHI 
  _4 = (char) i_9;
  data[i_9] = _4;
  i_6 = i_9 + 1;
  ivtmp_7 = ivtmp_1 - 1;
  if (ivtmp_7 != 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  return;

}

Could it be that somewhat since that index also is used as data that variable
cannot be folded away like
  size:   1 i_6 = i_9 + 1;
   Induction variable computation will be folded away.

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #10 from Vittorio Zecca  ---
Fixed in 7.1.0

[Bug fortran/61908] load of invalid value for 'expr_t' in interface.c compare_actual_formal

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #7 from Vittorio Zecca  ---
Fixed in 7.1.0

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

[zeccav at gmail dot com]

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

Bug 61908 Summary: load of invalid value for 'expr_t' in interface.c 
compare_actual_formal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61908

   What|Removed |Added

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

[Bug fortran/67498] interface.c sanitizer runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #6 from Vittorio Zecca  ---
Fixed in 7.1.0

[Bug tree-optimization/62058] Undefined behaviour in tree-data-ref.c with options -O1 -ftree-loop-vectorize

[zeccav at gmail dot com]

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

--- Comment #6 from Vittorio Zecca  ---
Still there in 7.1.0

[Bug middle-end/77383] -fcheck-pointer-bounds -mmpx ICE with VLA struct return type

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
Still in 7.1.0

[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
Still in 7.1.0

[Bug fortran/80657] New: Loop in character function declaration

[zeccav at gmail dot com]

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

Bug ID: 80657
   Summary: Loop in character function declaration
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

The following forces gfortran into a loop:

function f(x)
implicit character(len(f)) (x)
character(len(x)) f
end

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
It's a DR, we (In reply to Keith Thompson from comment #2)
> > [Moved to DR status at the April, 2013 meeting.]

Which means it's a DR against C++11, because it can't be a DR against C++14 in
2013 because there was no C++14 in 2013. So as a DR against C++11 we implement
it in C++11 mode.

[Bug c++/80649] value-initialization rather than default-initialization at some optimization levels

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Your example has undefined behaviour, you can't assume that a value present
before a constructor is still present afterwards.

See "More aggressive optimization of -flifetime-dse" at
https://gcc.gnu.org/gcc-6/porting_to.html

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

[Keith.S.Thompson at gmail dot com]

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

Keith Thompson  changed:

   What|Removed |Added

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

--- Comment #2 from Keith Thompson  ---
http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#903

I don't believe this DR applies to C++11.

The header does say "Status: CD3", but the next line is:

> [Moved to DR status at the April, 2013 meeting.]

with an this  at the bottom:

Additional note (January, 2013):

> Concerns were raised at the Portland (October, 2012) meeting that
> the value false has been used in existing code as a null pointer
> constant, and such code would be broken by this change. This issue
> has been returned to "review" status to allow discussion of whether
> to accommodate such code or not.

And at the very top of the cwg_defects.html page:

> Issues with DR, accepted, DRWP, and WP status are NOT part of the 
> International Standard for C++.

[Bug bootstrap/80656] mips64-linux cross build fails: Link tests are not allowed after GCC_NO_EXECUTABLES

[felix-gcc at fefe dot de]

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

--- Comment #1 from felix-gcc at fefe dot de ---
Turns out my libc was installed incorrectly.
Retrying now. I'm still getting this build error in libgomp and libstdc++.

[Bug bootstrap/80656] New: mips64-linux cross build fails: Link tests are not allowed after GCC_NO_EXECUTABLES

[felix-gcc at fefe dot de]

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

Bug ID: 80656
   Summary: mips64-linux cross build fails: Link tests are not
allowed after GCC_NO_EXECUTABLES
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

The build fails at least in libquadmath or libssp.

checking whether the /tmp/build/./gcc/xgcc -B/tmp/build/./gcc/
-B/opt/cross/mips64-linux/bin/ -B/opt/cross/mips64-linux/lib/ -isystem
/opt/cross/mips64-linux/include -isystem /opt/cross/mips64-linux/sys-include   
linker (/tmp/build/./gcc/collect-ld) supports shared libraries... yes
checking dynamic linker characteristics... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:11673: configure-target-libssp] Error 1
make[1]: Leaving directory '/tmp/build'
make: *** [Makefile:894: all] Error 2

[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Here are two problems involved:

1) std::vector's copy constructor is not SFINAE-friendly and causes
std::is_copy_constructible to evaluate to true regradless of it's element type.
This is a QoI issue but not a violation of the requirements of the standard.

2) The more serious problem is that the intrinsic __is_trivially_constructible
is the actual cause of the non-silent response here. This can be demonstrated
by evaluating the statement

__is_trivially_constructible(std::vector, const std::vector&);

which results in the following compiler error:

//
H:\Develop\Cpp\C++0x\ScratchBook\main.cpp||In function 'int main()':|
H:\Develop\Cpp\C++0x\ScratchBook\main.cpp|28|warning: statement has no effect
[-Wunused-value]|
c:\program files\develop\gcc\include\c++\8.0.0\bits\stl_construct.h||In
instantiation of 'void std::_Construct(_T1*, _Args&& ...) [with _T1 = nocopy;
_Args = {const nocopy&}]':|
c:\program
files\develop\gcc\include\c++\8.0.0\bits\stl_uninitialized.h|83|required from
'static _ForwardIterator
std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*; bool _TrivialValueTypes = false]'|
c:\program
files\develop\gcc\include\c++\8.0.0\bits\stl_uninitialized.h|134|required from
'_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator >; _ForwardIterator = nocopy*]'|
c:\program
files\develop\gcc\include\c++\8.0.0\bits\stl_uninitialized.h|289|required from
'_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator,
_ForwardIterator, std::allocator<_Tp>&) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*; _Tp = nocopy]'|
c:\program files\develop\gcc\include\c++\8.0.0\bits\stl_vector.h|331|required
from 'std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with
_Tp = nocopy; _Alloc = std::allocator]'|
H:\Develop\Cpp\C++0x\ScratchBook\main.cpp|28|required from here|
c:\program files\develop\gcc\include\c++\8.0.0\bits\stl_construct.h|75|error:
use of deleted function 'nocopy::nocopy(const nocopy&)'|
H:\Develop\Cpp\C++0x\ScratchBook\main.cpp|18|note: declared here|
||=== Build failed: 1 error(s), 7 warning(s) (0 minute(s), 0 second(s)) ===|
//

Note that evaluating

std::is_copy_constructible

alone doesn't spit at the programmer, but happily instantiates.

The only clean choice is to fix the __is_trivially_constructible intrinsic.
Wrapping the current call of that intrinsic by expanding the current
std::is_trivially_copy_constructible definition as follows

  template
  struct __is_trivially_constructible_delayed
  : public integral_constant
  { };

  template
  struct is_trivially_copy_constructible
  : public __and_,
__is_trivially_constructible_delayed<_Tp>>
  { };

wouldn't solve the problem, because due to the wrong positive result of
std::is_copy_constructible the protected
__is_trivially_constructible_delayed would still be instantiated.

[Bug tree-optimization/78496] [7/8 Regression] Missed opportunities for jump threading

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Sat May  6 18:20:31 2017
New Revision: 247722

URL: https://gcc.gnu.org/viewcvs?rev=247722=gcc=rev
Log:
PR tree-optimization/78496
* tree-vrp.c (simplify_assert_expr_using_ranges): Remove debugging
code.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c

[Bug c++/80655] -Werror=format-truncation inconsistency between x86_32 and x86_64

[krejzi at email dot com]

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

--- Comment #2 from Armin K.  ---
Created attachment 41333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41333=edit
Preprocessed source files

Here are the requested files. I apologize for having to compress them, but a
single file exceeded bugzilla file size limit (1.1 MB).

[Bug c++/80655] -Werror=format-truncation inconsistency between x86_32 and x86_64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-06
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source?

What the warning is saying is longer_message.data() in one path to the snprintf
will be null.   Without the preprocessed source there is no way to figure that
out.

[Bug c++/80655] New: -Werror=format-truncation inconsistency between x86_32 and x86_64

[krejzi at email dot com]

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

Bug ID: 80655
   Summary: -Werror=format-truncation inconsistency between x86_32
and x86_64
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krejzi at email dot com
  Target Milestone: ---

When building SPIRV-Tools with gcc-7.1.0 (stock, self-built), it builds fine
for 64 bit, but not for 32 bit (multilib setup).

The part of the code in question can be seen at [1]. I am getting the following
error when building SPIRV-Tools with "gcc -m32" and "g++ -m32"

In file included from
/home/armin/src/pacman/pkgbuild/vulkan-loader/src/Vulkan-LoaderAndValidationLayers32-sdk-1.0.46.0/external/spirv-tools/source/opt/ir_loader.cpp:17:0:
/home/armin/src/pacman/pkgbuild/vulkan-loader/src/Vulkan-LoaderAndValidationLayers32-sdk-1.0.46.0/external/spirv-tools/source/opt/log.h:
In function ‘void spvtools::Logf(const MessageConsumer&, spv_message_level_t,
const char*, const spv_position_t&, const char*, Args&& ...) [with Args =
{const SpvOp_&}]’:
/home/armin/src/pacman/pkgbuild/vulkan-loader/src/Vulkan-LoaderAndValidationLayers32-sdk-1.0.46.0/external/spirv-tools/source/opt/log.h:113:13:
error: null destination pointer [-Werror=format-truncation=]
 snprintf(longer_message.data(), longer_message.size(), format,
 ^~
  std::forward(args)...);
  

The very same package built fine with gcc-6.3.0.

[1]
https://github.com/KhronosGroup/SPIRV-Tools/blob/87a3f651e2416c830cb1eab410b3616068395985/source/opt/log.h#L111

[Bug libstdc++/80654] New: is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects

[bugs at mm dot beanwood.com]

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

Bug ID: 80654
   Summary: is_trivially_copy_constructible fails with compiler
error with vector of uncopyable objects
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugs at mm dot beanwood.com
  Target Milestone: ---

Created attachment 41332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41332=edit
Pre-processed file that triggers bug

std::is_trivially_copy_constructible::value, where nocopy
is a non-copyable type (e.g. std::unique_ptr), causes a compiler error instead
of producing a value of false as expected.

A practical consequence of this bug is that it is not possible to
move-construct a std::optional, because std::optional uses
std::is_trivially_copy_constructible internally.

Preprocessed file is attached.

Compiler output:

Using built-in specs.
COLLECT_GCC=/usr/local/gcc-7/current.x86_64/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-7/7.1.0.x86_64/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /usr/local/gcc-7/tmp-build/gcc-7.1.0/configure
--prefix=/usr/local/gcc-7/7.1.0.x86_64 --enable-languages=c,c++,go
--with-arch-32=i586
Thread model: posix
gcc version 7.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/gcc-7/7.1.0.x86_64/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1plus -E
-quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE bug.cpp -mtune=generic
-march=x86-64 -fpch-preprocess -o bug.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../include/c++/7.1.0

/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../include/c++/7.1.0/x86_64-pc-linux-gnu

/usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../include/c++/7.1.0/backward
 /usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include
 /usr/local/include
 /usr/local/gcc-7/7.1.0.x86_64/include
 /usr/local/gcc-7/7.1.0.x86_64/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/gcc-7/7.1.0.x86_64/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1plus
-fpreprocessed bug.ii -quiet -dumpbase bug.cpp -mtune=generic -march=x86-64
-auxbase bug -version -o bug.s
GNU C++14 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b73243a43f922df6e56feb5c73c5449a
In file included from
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/vector:62:0,
 from bug.cpp:3:
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_construct.h: In
instantiation of 'void std::_Construct(_T1*, _Args&& ...) [with _T1 = nocopy;
_Args = {const nocopy&}]':
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_uninitialized.h:83:18:
  required from 'static _ForwardIterator
std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*; bool _TrivialValueTypes = false]'
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_uninitialized.h:134:15:
  required from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*]'
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_uninitialized.h:289:37:
  required from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator,
_InputIterator, _ForwardIterator, std::allocator<_Tp>&) [with _InputIterator =
__gnu_cxx::__normal_iterator >;
_ForwardIterator = nocopy*; _Tp = nocopy]'
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/bits/stl_vector.h:331:31:  
required from 'std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp,
_Alloc>&) [with _Tp = nocopy; _Alloc = std::allocator]'
/usr/local/gcc-7/7.1.0.x86_64/include/c++/7.1.0/type_traits:1409:12:   required
from 'struct 

[Bug c++/50184] Segmentation fault. Copy Constructor.

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
Fixed in 7.1.0

[Bug sanitizer/71158] ICE in tree_to_uhwi with -fsanitize=address

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #5 from Vittorio Zecca  ---
Fixed in 7.1.0

[Bug c++/16994] [meta-bug] VLA and C++

[zeccav at gmail dot com]

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

Bug 71158 Summary: ICE in tree_to_uhwi with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71158

   What|Removed |Added

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

[Bug sanitizer/70878] [5/6 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7680

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #5 from Vittorio Zecca  ---
Fixed in 7.1.0

[Bug c++/80652] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

--- Comment #3 from Peter Boyle  ---
Can confirm (5.4) that -O2 also fails, 
   -O1 passes.

[Bug c++/80652] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

--- Comment #2 from Peter Boyle  ---
Thanks for the quick response. Hope this more complete info is helpful.

Should give (1,0) but does give (0,0) under G++ 5.0-6.2 under -O3.

peterboyle$ g++-mp-5 --version
g++-mp-5 (MacPorts gcc5 5.4.0_0) 5.4.0

Under -O3: I THINK THIS IS WRONG AND A COMPILER ERROR

c010200:~ peterboyle$ g++-mp-5 Gcc-test.cc -std=c++11 -O3 
c010200:~ peterboyle$ ./a.out 
(0,0) 

c010200:~ peterboyle$ g++-mp-5 Gcc-test.cc -std=c++11 
c010200:~ peterboyle$ ./a.out 
(1,0) 

Under g++4.9
c010200:~ peterboyle$ g++-4.9 Gcc-test.cc -std=c++11 -O3 
c010200:~ peterboyle$ ./a.out 
(1,0) 

Under llvm xcode
c010200:~ peterboyle$ g++ Gcc-test.cc -std=c++11 -O3 
c010200:~ peterboyle$ ./a.out 
(1,0) 

I also used wandbox to to test many versions, and filed an issue
on my own codebase where I first hit it (prior to small example reduction).

Here is my issue report: https://github.com/paboyle/Grid/issues/100



https://wandbox.org/permlink/tzssJza6R9XnqANw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80652

Getting Travis fails under gcc-5 for Test_simd, now that I added more
comprehensive testing to the
CI test suite. The limitations of Travis runtime limits & weak cores are being
shown.

Travis uses 5.4.1 for g++-5.

We are going to move to a new CI server we bought for the purpose soon.

Working (-) Broken (X):
4.9.0 -
4.9.1 -
5.1.0 X
5.2.0 X
5.3.0 X
5.4.0 X
6.1.0 X
6.2.0 X
6.3.0 -
7.1.0 -
8.0.0 (HEAD) -

Clang 3.5 through 5.0 are good on this test.

Options:
a) Drop to -O2 under broken G++ versions
b) Refuse to build with broken G++ versions.

Opinions sought.

Attempting to work around with

#if (GNUC == 5 ) || ( ( GNUC == 6 ) && GNUC_MINOR < 3 )
#pragma GCC push_options
#pragma GCC optimize ("O0")
#endif

and same to pop options around the SimdApply in Grid_vector_types.

But, I now have very, very, VERY poor confidence in these compiler versions.

e.g. Where else do we hit this? It is dangerous to not apply this globally
(which we could force) but that will cripple performance.

Do we unsupport a whole swathe of G++ versions?

I posted on stack overflow to try to get a double check on the legality of the
union use.

http://stackoverflow.com/questions/2906365/gcc-strict-aliasing-and-casting-through-a-union/43820916#43820916

But, I think this is legal code.

[Bug c++/80652] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
I didn't study the testcase (a bit long), but I am getting the same output with
any version of gcc or clang I tried, at any level of optimization. Are you
certain about your example? What is the expected output? And since you
specifically mention -O3, what difference did it make for you?

[Bug tree-optimization/78496] [7/8 Regression] Missed opportunities for jump threading

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Sat May  6 15:03:40 2017
New Revision: 247721

URL: https://gcc.gnu.org/viewcvs?rev=247721=gcc=rev
Log:
PR tree-optimization/78496
* tree-vrp.c (simplify_assert_expr_using_ranges): New function.
(simplify_stmt_using_ranges): Call it.
(vrp_dom_walker::before_dom_children): Extract equivalences
from an ASSERT_EXPR with an equality comparison against a
constant.

PR tree-optimization/78496
* gcc.dg/tree-ssa/ssa-thread-16.c: New test.
* gcc.dg/tree-ssa/ssa-thread-17.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug target/79709] Subobtimal code with -mavx and explicit vector

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
Created attachment 41331
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41331=edit
recognize a VEC_CONCAT from a constructor (not clean)

One piece of the issue is v4di = { v2di, v2di } where we currently generate
vmovdqa %xmm3, -48(%rsp)
vmovdqa %xmm5, -32(%rsp)
vmovdqa -48(%rsp), %ymm0
and the attached patch generates
vinsertf128 $0x1, %xmm1, %ymm0, %ymm0

I am not very familiar with expansion and RTL, the patch probably has many
issues. I don't know if there is something significantly more general to try. I
was tempted to cast (aka subreg) V2DI to TI, construct a V2TI, and cast back to
V4DI, since the code nearby is supposed to handle constructors with only scalar
elements, but an experiment with __int128 seems to indicate that we don't
discover vec_concat for scalars either :-(

[Bug c/80653] New: Enhancement: better location info for -Wunsafe-loop-optimizations

[egall at gwmail dot gwu.edu]

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

Bug ID: 80653
   Summary: Enhancement: better location info for
-Wunsafe-loop-optimizations
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---

Currently, with a for-loop, -Wunsafe-loop-optimizations points to the "for":

reloc.c: In function 'bfd_generic_get_relocated_section_contents':
reloc.c:6000:7: warning: missed loop optimization, the loop counter may
overflow [-Wunsafe-loop-optimizations]
   for (parent = reloc_vector; (parent != NULL) && (*parent != NULL);
   ^~~

and with a while-loop, it points to the opening parenthesis:

pef.c: In function 'bfd_pef_parse_symbols':
pef.c:893:13: warning: missed loop optimization, the loop counter may overflow
[-Wunsafe-loop-optimizations]
   while (((codepos + 4UL) <= codelen) && (codepos < (size_t)UINT_MAX))
 ^
pef.c:723:13: warning: missed loop optimization, the loop counter may overflow
[-Wunsafe-loop-optimizations]
   while (((pos + 4UL) <= len) && (pos < (size_t)UINT_MAX))
 ^

It'd be more useful if the caret instead pointed to the variable being used as
the loop counter, and/or the point in the loop where it actually overflows

[Bug c++/80652] New: Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

Bug ID: 80652
   Summary: Union conversion between __m128d and double array does
not work under 5.0 through 6.2
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paboyle at ph dot ed.ac.uk
  Target Milestone: ---

Union conversion between __m128d and double array does not work under 
-O3 for g++ versions 5.0 to 6.2. Compiled with -std=c++11 -O3 .

https://wandbox.org/permlink/tzssJza6R9XnqANw

Code:

#include 
#include 
#include 

template 
class simd {
 public:
  typedef Vector_type vector_type;
  typedef Scalar_type scalar_type;
  typedef union conv_t_union {
Vector_type v;
Scalar_type s[sizeof(Vector_type) / sizeof(Scalar_type)];
conv_t_union(){};
  } conv_t;

  static inline constexpr int Nsimd(void) {
return sizeof(Vector_type) / sizeof(Scalar_type);
  }

  Vector_type v;

  template 
  friend inline simd SimdApply(const functor , const simd ) {
simd ret;
simd::conv_t conv;

conv.v = v.v;
for (int i = 0; i < simd::Nsimd(); i++) {
  conv.s[i] = func(conv.s[i]);
}
ret.v = conv.v;
return ret;
  }

};

template 
struct RealFunctor {
  scalar operator()(const scalar ) const {
return std::real(a);
  }
};

template 
inline simd real(const simd ) {
  return SimdApply(RealFunctor(), r);
}

typedef simd vcomplexd;

int main(int argc, char **argv)
{
  vcomplexd a,b;
  a.v=_mm_set_pd(2.0,1.0);
  b = real(a);

  vcomplexd::conv_t conv;
  conv.v = b.v;
  for(int i=0;i

[Bug c++/80649] value-initialization rather than default-initialization at some optimization levels

[john.duncan at oracle dot com]

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

--- Comment #1 from J.D. Duncan  ---
Created attachment 41330
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41330=edit
g++ -v output

[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak

[janus at gcc dot gnu.org]

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

--- Comment #20 from janus at gcc dot gnu.org ---
(In reply to janus from comment #19)
> And IIRC we even use the finalization
> wrapper for deallocating polymorphic variables in other cases (even if they
> have no actual FINAL procedures).

In fact the finalization wrapper itself does not take care of deallocating the
variable (since finalization also applies to non-allocatable variables), but it
does deallocate any allocatable components (if existent).

Plus: For any polymorphic variable, we need to check at *runtime* whether
finalization is necessary, since an extended type may have finalizers, even if
the base class does not.

The typical code that is generated for the deallocation of a polymorphic
variable 'c' looks like this:

  if (c._data != 0B)
{
  if (c._vptr->_final != 0B)
{
  {
struct array0_t desc.0;

desc.0.dtype = 40;
desc.0.data = (void * restrict) c._data;
c._vptr->_final (, c._vptr->_size, 0);
  }
}
  __builtin_free ((void *) c._data);
}

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #10 from Rainer Orth  ---
Interestingly, a i386-apple-darwin16 bootstrap *does* work fine.

[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #19 from janus at gcc dot gnu.org ---
I think this PR is very much related to PR 65347 ("Final subroutine not called
for function result") ...

Deallocation and finalization of function results are very similar. Both
require a temporary to be generated. And IIRC we even use the finalization
wrapper for deallocating polymorphic variables in other cases (even if they
have no actual FINAL procedures). Such an approach would fix both PRs in one
go.

[Bug target/80527] SSE4 Compiling issue

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #4 from Marc Glisse  ---
(In reply to Milo from comment #3)
> We are using Ubuntu 12.04. It used gcc 4.8.5 and also has the same issue.
> Furthermore, some tools from an EDA company are using gcc 4.8.3 as the only
> compiler.
> 
> We believed that would help if it could be fixed.

You will have to contact whoever provides your gcc (either Ubuntu or the EDA
company) and see if they are willing to backport the relevant patches for you.

> By the way, you mentioned about 4.9 version. Is that means 4.9 is still be
> maintaining?

No, the maintained release branches are listed on
https://gcc.gnu.org/

[Bug rtl-optimization/75964] insn combiner removes comparison after ABS

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.  It doesn't look like it's a regression, but maybe we want to
backport anyway?

[Bug rtl-optimization/75964] insn combiner removes comparison after ABS

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Sat May  6 07:44:13 2017
New Revision: 247719

URL: https://gcc.gnu.org/viewcvs?rev=247719=gcc=rev
Log:
PR 75964: Invalid integer ABS handling in simplify-rtx.c

RTL has no distinction between signed and unsigned values, so it
doesn't make sense to test for signed overflow.

2017-05-06  Richard Sandiford  

gcc/
PR rtl-optimization/75964
* simplify-rtx.c (simplify_const_relational_operation): Remove
invalid handling of comparisons of integer ABS.

gcc/testsuite/
PR rtl-optimization/75964
* gcc.dg/torture/pr75964.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr75964.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/80606] avx-vtestpd-1.c contains outdated line number

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #2 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

[Bug testsuite/80606] avx-vtestpd-1.c contains outdated line number

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Author: vries
Date: Sat May  6 07:31:27 2017
New Revision: 247718

URL: https://gcc.gnu.org/viewcvs?rev=247718=gcc=rev
Log:
Remove default_packed lines from i386/avx-vtestp{d,s}*

2017-05-06  Tom de Vries  

PR testsuite/80606
* gcc.target/i386/avx-vtestpd-1.c: Remove default_packed lines.
* gcc.target/i386/avx-vtestpd-2.c: Same.
* gcc.target/i386/avx-vtestpd-256-1.c: Same.
* gcc.target/i386/avx-vtestpd-256-2.c: Same.
* gcc.target/i386/avx-vtestpd-256-3.c: Same.
* gcc.target/i386/avx-vtestpd-3.c: Same.
* gcc.target/i386/avx-vtestps-1.c: Same.
* gcc.target/i386/avx-vtestps-2.c: Same.
* gcc.target/i386/avx-vtestps-256-1.c: Same.
* gcc.target/i386/avx-vtestps-256-2.c: Same.
* gcc.target/i386/avx-vtestps-256-3.c: Same.
* gcc.target/i386/avx-vtestps-3.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx-vtestpd-1.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestpd-2.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-1.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-2.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-3.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestpd-3.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestps-1.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestps-2.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestps-256-1.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestps-256-2.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestps-256-3.c
trunk/gcc/testsuite/gcc.target/i386/avx-vtestps-3.c

[Bug c++/80649] New: value-initialization rather than default-initialization at some optimization levels

[webrown.cpp at gmail dot com]

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

Bug ID: 80649
   Summary: value-initialization rather than
default-initialization at some optimization levels
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.duncan at oracle dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

This problem concerns a placement-new statement within a loop:

new (ptr.p) TestRecord;

In this case "new TestRecord" without any parentheses or braces should perform
default-initialization. My experience with gcc 6.3 shows default-initialization
at some -O levels, but apparent value-initialization at other levels. In the
example submitted here in the bug report, the problem appears at -O1 but not at
-O2. In the actual large codebase where I first observed the problem, it was
seen at -O2 but not at -O1.

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
Author: vries
Date: Sat May  6 07:17:05 2017
New Revision: 247716

URL: https://gcc.gnu.org/viewcvs?rev=247716=gcc=rev
Log:
Replace absolute line numbers in gcc.target/powerpc

2017-05-06  Tom de Vries  

PR testsuite/80557
* gcc.target/powerpc/altivec-macros.c: Replace absolute line numbers.
* gcc.target/powerpc/altivec-types-1.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/altivec-macros.c
trunk/gcc/testsuite/gcc.target/powerpc/altivec-types-1.c

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries  ---
Author: vries
Date: Sat May  6 07:16:43 2017
New Revision: 247714

URL: https://gcc.gnu.org/viewcvs?rev=247714=gcc=rev
Log:
Replace absolute line numbers in gcc.target/arm

2017-05-06  Tom de Vries  

PR testsuite/80557
* gcc.target/arm/pr69180.c: Replace absolute line numbers.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/pr69180.c

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
Author: vries
Date: Sat May  6 07:16:33 2017
New Revision: 247713

URL: https://gcc.gnu.org/viewcvs?rev=247713=gcc=rev
Log:
Replace absolute line numbers in gcc.target/aarch64

2017-05-06  Tom de Vries  

PR testsuite/80557
* gcc.target/aarch64/spellcheck_1.c: Replace absolute line numbers.
* gcc.target/aarch64/spellcheck_2.c: Same.
* gcc.target/aarch64/spellcheck_3.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_2.c
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_3.c

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
Author: vries
Date: Sat May  6 07:16:53 2017
New Revision: 247715

URL: https://gcc.gnu.org/viewcvs?rev=247715=gcc=rev
Log:
Replace absolute line numbers in gcc.target/spu

2017-05-06  Tom de Vries  

PR testsuite/80557
* gcc.target/spu/Wmain.c: Replace absolute line numbers.
* gcc.target/spu/intrinsics-1.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/spu/Wmain.c
trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
Author: vries
Date: Sat May  6 07:16:17 2017
New Revision: 247712

URL: https://gcc.gnu.org/viewcvs?rev=247712=gcc=rev
Log:
Replace absolute line numbers in g++.dg/{debug,goacc}

2017-05-06  Tom de Vries  

PR testsuite/80557
* g++.dg/debug/dwarf2/dwarf2-1.C: Replace absolute line numbers.
* g++.dg/debug/dwarf2/dwarf2-2.C: Same.
* g++.dg/debug/dwarf2/pr46123-2.C: Same.
* g++.dg/debug/dwarf2/typedef5.C: Same.
* g++.dg/goacc/data-1.C: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-1.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-2.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr46123-2.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
trunk/gcc/testsuite/g++.dg/goacc/data-1.C

[Bug c++/80650] New: #pragma do not control -Wcpp

[akim.demaille at gmail dot com]

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

Bug ID: 80650
   Summary: #pragma do not control -Wcpp
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akim.demaille at gmail dot com
  Target Milestone: ---

Hi!

When compiling C, -Wcpp can be controlled by the diagnostics pragmas, but not
in C++ mode.

$ cat bar.c
#pragma GCC diagnostic ignored "-Wcpp"
#warning Foo

int i;
$ gcc-mp-7 -c bar.c
$ cp bar.c bar.cc
$ g++-mp-7 -c bar.c
bar.c:2:2: warning: #warning Foo [-Wcpp]
 #warning Foo
  ^~~

$ g++-mp-7 --version
g++-mp-7 (MacPorts gcc7 7-20170420_0) 7.0.1 20170420 (prerelease)
Copyright (C) 2017 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.

I have observed this with 4.9, 5.5, 6.2 and 7.0.

Cheers!