Re: -Wformat-truncation outputs emtpy lines instead of source

[Martin Sebor]

On 05/01/2017 01:39 PM, Simon Sobisch wrote:

Hi,

I've just got GCC7 (build from svn worked like a charm, even if it took hours 
but I was warned) and like the new warnings and hints very much.

When compiling GnuCOBOL from vcs (sources on mount, therefore the long path) I 
got one warning with multiple and very long tilde lines.

/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c: In function 
'cb_build_registers':
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:30: 
warning: 'snprintf' output may be truncated before the last format character 
[-Wformat-truncation=]
  snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
  ^~~~
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:2: note: 
'snprintf' output between 17 and 63 bytes into a destination of size 17

  ^~

   ~~~

   

   ~

   

   ~~
   current_compile_time.second);
   

It looks like the source in the lines between are missing (the number of tildes 
is correct).
The source reads:

snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
current_compile_time.day_of_month,
current_compile_time.month,
current_compile_time.year % 100,
current_compile_time.hour, '.',
current_compile_time.minute, '.',
current_compile_time.second);


Hmm, that's quite odd.  I'm not able to reproduce this "effect"
and I have never seen anything like it.  My first thought was
that it could be a problem with the terminal you are using (try
compiling with -fno-diagnostics-color to see if it improves)
but since you presumably copied the error message above from
the terminal that's probably not going to help.  If it doesn't,
can you please create a new bug and attach to it a preprocessing
translation unit (compile the source file with -E and save the
output)?  Also include the full set of command line options you
invoked the compiler with when you got the "invisible" message.



Thank you for this compiler!
Simon

BTW: is it really useful to have the complete function in the output message?
The output may get *very* long...


You mean the complete function call in the note, including
the arguments?  GCC tries to provide as much useful context
in diagnostic messages as necessary to help users see their
root cause.  The trend has been toward more verbose messages,
and so some message can get long (that's especially true for
C++ code heavy on templates).  In this case, showing the full
call is probably not particularly helpful but I have never
though about it as being a problem.  Each diagnostic message
printed by GCC is associated with some location in the source
code, often a declaration or a full expression, but sometimes
a subexpression.  In this case the choice is between the location
of the format string and that of the function call. The warning
is associated with the location of the format so the note is
attached to the whole call.  Off the top of my head I can't
think of anything else to attach it to that would make sense.

Martin

PS gcc-bugs is used for automated emails sent in response to
changes to the GCC Bugzilla.  Please use gcc-help for questions
about GCC (or open new bugs for suspected defects).

[Bug c++/80038] [6/7/8 Regression] Random segfault using local vectors in Cilk function

[law at gcc dot gnu.org]

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

--- Comment #31 from Jeffrey A. Law  ---
Author: law
Date: Mon May  1 22:26:02 2017
New Revision: 247446

URL: https://gcc.gnu.org/viewcvs?rev=247446=gcc=rev
Log:
2017-05-01  Xi Ruoyao  

PR c++/80038
* cilk_common.c (expand_builtin_cilk_detach): Move pedigree
operations here.
* gimplify.c (gimplify_cilk_detach): New function.
(gimplify_call_expr, gimplify_modify_expr): Call it as needed.
* tree-core.h: Document EXPR_CILK_SPAWN.
* tree.h (EXPR_CILK_SPAWN): Define.

PR c++/80038
* c-common.h (cilk_gimplify_call_params_in_spawned_fn): Remove
prototype.
(cilk_install_body_pedigree_operations): Likewise.
* cilk.c (cilk_set_spawn_marker): Mark functions that should be
detatched.
(cilk_gimplify_call_params_in_spawned_fn): Remove.
(cilk_install_body_pedigree_operations): Likewise.
(gimplify_cilk_spawn): Add EXPR_STMT and CLEANUP_POINT_EXPR
unwrapping.

PR c++/80038
* c-gimplify.c (c_gimplify_expr): Remove calls to
cilk_gimplifY_call_params_in_spawned_fn.

PR c++/80038
* cp-cilkplus.c (cilk_install_body_with_frame_cleanup): Don't
add pedigree operation and detach call here.
* cp-gimplify.c (cp_gimplify_expr): Remove the calls to
cilk_cp_gimplify_call_params_in_spawned_fn.
(cilk_cp_gimplify_call_params_in_spawned_fn): Remove function.
* semantics.c (simplify_aggr_init_expr): Copy EXPR_CILK_SPAWN.

PR c++/80038
* lto-lang.c (lto_init): Set in_lto_p earlier.

PR c++/80038
* g++.dg/cilk-plus/CK/pr80038.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr80038.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-gimplify.c
trunk/gcc/c-family/cilk.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cilk-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-cilkplus.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/semantics.c
trunk/gcc/gimplify.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree.h

[Bug other/80589] New: Typing mistakes in two messages

[goeran at uddeborg dot se]

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

Bug ID: 80589
   Summary: Typing mistakes in two messages
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goeran at uddeborg dot se
  Target Milestone: ---

The translation reviewer Anders Jonsson pointed out two message ids with what
appears to be misspellings.



#: params.def:351
#, no-c-format
msgid "The maximum number of insns in loop header duplicated by he copy loop
headers pass."

This should read "by the copy" pass, we believe.



#: common.opt:2495
msgid "Detect paths that trigger erroneous or undefined behavior due a null
value being used …

This should read "due to a null", we believe.

[Bug tree-optimization/80588] GCC can't simplify static inline function with xor/xnor

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Thanks. Let me copy what I had in the other PR:

we have an old optimization in fold_unary (like other "do ... if ...
simplifies" it is not straightforward to move it to match.pd) and thus it only
applies when everything is part of the same expression in the source code.

  /* Convert ~(X ^ Y) to ~X ^ Y or X ^ ~Y if ~X or ~Y simplify.  */

If you use even less macros and more lines, things optimize a bit better:
m_xnor:
  TYPE tmp=!!a^!!b;
  return !tmp;
but we still have some discrepancy where we optimize (a^b)==0 but not ~(a^b)
(for _Bool type).

[Bug middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation

[already5chosen at yahoo dot com]

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

--- Comment #14 from Michael_S  ---
Created attachment 41293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41293=edit
another case of bad vector register allocation

Here is another case of bad allocation of SIMD register that hopefully can help
Berndt.
This case does not appear to depend on optimization level or on -fno-tree-ter.
Bad allocation happens with all versions of gcc that I tested on godbolt, but 
the level of damage is higher with newer versions.

# of spills of accumulators in the inner loop as function of value of UNROLL
and of version of gcc:
UNROLL 1 2 3 4
gcc 4.9.4  0 2 1 1
gcc 5.40 2 1 1
gcc 6.30 2 1 2
gcc 7  0 2 1 2

Link to goldbolt:
https://godbolt.org/g/N49vBs

[Bug tree-optimization/80588] New: GCC can't simplify static inline function with xor/xnor

[SztfG at yandex dot ru]

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

Bug ID: 80588
   Summary: GCC can't simplify static inline function with
xor/xnor
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

GCC can't simplify static inline function for xor/xnor, but can, if used macro
instead. Testcase:

#include 

#define TYPE uint8_t

#define M_XOR(a,b) ((!!(a))^(!!(b)))
#define M_NXOR(a,b) (!((!!(a))^(!!(b

__attribute__((__always_inline__, const))
static inline TYPE m_xor (const TYPE a, const TYPE b)
{
return M_XOR(a,b);
}

__attribute__((__always_inline__, const))
static inline TYPE m_xnor (const TYPE a, const TYPE b)
{
return M_NXOR(a,b);
}

// bad assembly output
int test1b(const TYPE a, const TYPE b)
{
return m_xor(a,b) == !m_xnor(a,b);
}

int test2b(const TYPE a, const TYPE b)
{
return !m_xor(a,b) == m_xnor(a,b);
}

int test3b(const TYPE a, const TYPE b)
{
return M_XOR(a,b) == !m_xnor(a,b);
}

// good assembly output
int test1g(const TYPE a, const TYPE b)
{
return m_xor(a,b) == M_XOR(a,b);
}

int test2g(const TYPE a, const TYPE b)
{
return M_XOR(a,b) == !M_NXOR(a,b);
}

int test3g(const TYPE a, const TYPE b)
{
return M_XOR(a,b) != !M_NXOR(a,b);;
}

[Bug c++/80587] New: Incorrect type from outer scope inside lambda under some conditions

[jas...@3db-labs.com]

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

Bug ID: 80587
   Summary: Incorrect type from outer scope inside lambda under
some conditions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jas...@3db-labs.com
  Target Milestone: ---

Created attachment 41292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41292=edit
Test case source file

I observed this error on an Ubuntu 17.04 system; here is the output of `g++
-v`:

-

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.3.0-12ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2) 

-

The nature of the bug is tough to explain, so see the attached test case. I
minimized it as much as possible, but I ran into it when using Boost.Hana from
Boost v1.64. Based on the test case, this appears to be a compiler bug, not an
issue with the library.

In the test, I create a `boost::hana::tuple<>` object, then use
`boost::hana::for_each()` to invoke a callable with each element of the tuple.
In my test case, I provide a lambda as the callable. I've noticed that, if I
try to use the enclosing tuple type from within the lambda, g++ uses the
incorrect type in some cases. I would expect the program to print:

-

working example:
tuple type before for_each: boost::hana::tuple
tuple type inside for_each: boost::hana::tuple
tuple type inside for_each: boost::hana::tuple

non-working example:
tuple type before for_each: boost::hana::tuple
tuple type inside for_each: boost::hana::tuple
tuple type inside for_each: boost::hana::tuple

-

However, when I compile and run the program using g++ as follows:

g++ tuple_test.cc -o tuple_test -std=c++14

I get the following output:

-

working example:
tuple type before for_each: boost::hana::tuple
tuple type inside for_each: boost::hana::tuple
tuple type inside for_each: boost::hana::tuple

non-working example:
tuple type before for_each: boost::hana::tuple
tuple type inside for_each: int
tuple type inside for_each: int

-

I see this error on every version of gcc that I've tried: 6.1, 6.2, 6.3, 7.0,
and 8.0 trunk (https://wandbox.org/permlink/4zKtIIZ9k7sI7Ckv). All versions of
clang that I've tried that are supported by Hana seem to work fine. I've
minimized the test case as much as I can, but I haven't been able to identify a
workaround.

[Bug tree-optimization/80574] GCC fail to optimize nested ternary

[SztfG at yandex dot ru]

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

--- Comment #5 from SztfG at yandex dot ru ---
> He did not claim it was always better...

Ahh, so I need to do some research to figure out, in which cases static inline
function is better, and in which macro is better. It's bad

> Please don't mix unrelated issues

OK, will fill this in another bugreport

[Bug target/80586] New: vsqrtss with AVX should avoid a dependency on the destination register.

[peter at cordes dot ca]

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

Bug ID: 80586
   Summary: vsqrtss with AVX should avoid a dependency on the
destination register.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

#include 
float sqrt_depcheck(float a, float b) {
return sqrtf(b);
}

compiles to (with gcc 8.0.0 20170429  -march=haswell -O3 -fno-math-errno):

  vsqrtss %xmm1, %xmm0, %xmm0
  ret


recent clang (4.0) avoids the unwanted dependency on %xmm0 by using the source
register as *both* source operands:

  vsqrtss %xmm1, %xmm1, %xmm0
  ret


This of course doesn't work when the source is a different type (e.g. memory,
or for int->float conversion, an integer register.  See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80571 for a suggestion to track
cold registers that can be safely used read-only without delaying OOO
execution, without putting vxorps-zeroing everywhere).


float sqrt_from_mem(float *fp) {
return sqrtf(*fp);
}

ICC17 breaks the dep on xmm0 this way:
vmovss(%rdi), %xmm0 #8.12
vsqrtss   %xmm0, %xmm0, %xmm0   #8.12

gcc and clang both decide to risk it with:
   vsqrtss (%rdi), %xmm0, %xmm0


code on https://godbolt.org/g/mJmjdh.

GCC7 (gcc-7-branch rev 247415) suggest function name in expression

[Simon Sobisch]

Hi,

the suggestions are cool and they obviously can't be always correct.
I guess it matches this against different valid identifiers and somehow
counting a score for these and showing the identifier with the highest
score. I did not found anything about the "how" in the GCC annotation.


But I do wonder if the following is the ideal:

/media/dev/gnu-cobol-2.0/cobc/cobc.c: In function 'process_command_line':
/media/dev/gnu-cobol-2.0/cobc/cobc.c:3010:6: error: 'cb_fatal_error'
undeclared (first use in this function); did you mean 'cob_fatal_error'?
  if (cb_fatal_error) {
  ^~
  cob_fatal_error

OK, so we used a wrong variable name. But GCC suggests a function
address...
The definition of cob_fatal_error is

void
cob_fatal_error(const int fatal_error)

declared in an included header file as

extern void cob_fatal_error (const int) __attribute__((noreturn));


changing it as suggested raises


/media/dev/gnu-cobol-2.0/cobc/cobc.c: In function 'process_command_line':
/media/dev/gnu-cobol-2.0/cobc/cobc.c:3010:6: warning: the address of
'cob_fatal_error' will always evaluate as 'true' [-Waddress]
  if (cob_fatal_error) {
  ^~~

(I first thought this warning was wrong, too as
__attribute__((noreturn)) explicit tells the compiler that this function
will never return, but it is actually using the function address...)


The correct version is

  if (fatal_error) {

and the definition of fatal_error, local to cobc.c is:

int fatal_error = 0;


Suggestions for this hard to always guess right area:

* document how the suggestion is calculated, link this in places where
this feature is referenced like https://gcc.gnu.org/gcc-7/changes.html
* don't suggest a function address if any other possible candidates exist
* give local variables a higher score

Thank you for this wonderful and evolving compiler!

Simon


I'm not subscribed to the list, please answer directly (CCing the list
of course), otherwise I can't read your response.
Thank you.

[Bug target/80571] AVX allows multiple vcvtsi2ss/sd (integer -> float/double) to reuse a single dep-breaking vxorps, even hoisting it out of loops

[peter at cordes dot ca]

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

--- Comment #1 from Peter Cordes  ---
Tracking "cold" registers that are safe to use as a read-only source (whether
or not they're holding a useful value like a constant) has a couple other
applications for x86:

 * vcvtsi2ss/sd %src,%merge_into, %xmm destination
 * vsqrtss (mem),%merge_into, %xmm
 * vpcmpeqd%same,%same, %dest# false dep on KNL / Silvermont
 * vcmptrueps  %same,%same, %ymm # splat -1 without AVX2.  false dep on all
known uarches
 * _mm_undefined_ps()

Or before clobbering a dead reg, whether we can skip the xor-zeroing before:

 * any of the above without AVX, e.g. sqrtss %src, %dst
 * vpternlogd  $0xff,any,any, src3/dst   # zmm splat -1: false dep

See https://bugs.llvm.org/show_bug.cgi?id=32863 for a more detailed writeup of
this idea.



Current out-of-order execution designs always retire in-order, so a register is
guaranteed to be ready if it hasn't been written in the last N instructions,
where N is the out-of-order window size.  (AKA ROB size, 224 on Skylake for
example).

[Bug libstdc++/80493] std::experimental::optional::swap is ill formed

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Yep, that's why I've left the PR open.

-Wformat-truncation outputs emtpy lines instead of source

[Simon Sobisch]

Hi,

I've just got GCC7 (build from svn worked like a charm, even if it took hours 
but I was warned) and like the new warnings and hints very much.

When compiling GnuCOBOL from vcs (sources on mount, therefore the long path) I 
got one warning with multiple and very long tilde lines.

/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c: In function 
'cb_build_registers':
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:30: 
warning: 'snprintf' output may be truncated before the last format character 
[-Wformat-truncation=]
  snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
  ^~~~
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:2: note: 
'snprintf' output between 17 and 63 bytes into a destination of size 17

  ^~

   ~~~

   

   ~

   

   ~~
   current_compile_time.second);
   

It looks like the source in the lines between are missing (the number of tildes 
is correct).
The source reads:

snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
current_compile_time.day_of_month,
current_compile_time.month,
current_compile_time.year % 100,
current_compile_time.hour, '.',
current_compile_time.minute, '.',
current_compile_time.second);

Thank you for this compiler!
Simon

BTW: is it really useful to have the complete function in the output message?
The output may get *very* long...

I'm not subscribed to the list, please answer directly (CCing the list of 
course), otherwise I can't read your response.
Thank you.

[Bug fortran/80524] [F03] Problematic behaviour with a finalization subroutine in gfortran

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
(In reply to janus from comment #4)
> (In reply to Jerry DeLisle from comment #3)
> > I think this depends a lot on the compiler implementation.
> 
> I don't actually think the calling of finalization routines is supposed to
> depend on the compiler implementation. F08 is rather clear on where it
> should happen, I guess.
> 
> For the missing cases, see also:
> * PR 64290 (No finalization at deallocation of LHS)
> * PR 65347 (Final subroutine not called for function result)
> 
> and PR 37336 comment 27 which includes both of them.

My only thought here is that those conditions may be A or B or C vs A and B and
C

If the finalization is to for example deallocate something, would we end up
trying to deallocate more than once? It seems to me that it depends on how many
actual instances of the object were created.

[Bug tree-optimization/80574] GCC fail to optimize nested ternary

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to SztfG from comment #3)
> Georg-Johann Lay, GCC not always do things better if use static inline
> function instead macro.

He did not claim it was always better...

> For example, this code:

Please don't mix unrelated issues, you can file a different bug if you want
that one addressed. In that case, it is because we have an old optimization in
fold_unary (like other "do ... if ... simplifies" it is not straightforward to
move it to match.pd) and thus only applies when everything is part of the same
expression in the source code.

  /* Convert ~(X ^ Y) to ~X ^ Y or X ^ ~Y if ~X or ~Y simplify.  */

If you use even less macros and more lines, things optimize a bit better:
m_xnor:
  TYPE tmp=!!a^!!b;
  return !tmp;
but we still have some discrepancy where we optimize (a^b)==0 but not ~(a^b)
(for _Bool type). This will be much more convenient to analyze in a different
bug report.

[Bug target/79581] VFP4 slower than VFP3 in C-ray on Cortex A5

[tulipawn at gmail dot com]

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

--- Comment #5 from PeteVine  ---
Unchanged in gcc version 8.0.0 20170501.

[Bug fortran/37131] inline matmul for small matrix sizes

[tkoenig at gcc dot gnu.org]

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

--- Comment #32 from Thomas Koenig  ---
Author: tkoenig
Date: Mon May  1 17:45:52 2017
New Revision: 247441

URL: https://gcc.gnu.org/viewcvs?rev=247441=gcc=rev
Log:
2017-05-01  Thomas Koenig  

PR fortran/37131
* frontend-passes.c (inline_matmul_assign): Also check bounds
for allocatable lhs and matrix-vector-multiplication.

2017-05-01  Thomas Koenig  

PR fortran/37131
* gfortran.dg/matmul_bounds_11.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/matmul_bounds_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/80581] [8 Regression] ICE: in estimate_node_size_and_time, at ipa-inline-analysis.c:3425

[helloqirun at gmail dot com]

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

Qirun Zhang  changed:

   What|Removed |Added

 CC||helloqirun at gmail dot com

--- Comment #3 from Qirun Zhang  ---
The following smaller code also crashes the current trunk version of gcc.

It occurs only at -O2 and -O3 in 32-bit mode.

It also starts with r247417. I thought it should be a duplicate. Therefore, I
report it here.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 8.0.0 20170501 (experimental) [trunk revision 247436] (GCC)


$ gcc-trunk -m32 -O2 abc.c
abc.c:14:1: internal compiler error: in estimate_node_size_and_time, at
ipa-inline-analysis.c:3425
 void fn3() { fn2(b); }
 ^~~~
0x98ef05 estimate_node_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:3425
0x991513 do_estimate_edge_time(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3935
0x991a67 do_estimate_edge_size(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3989
0x991cbf estimate_edge_size
../../gcc/gcc/ipa-inline.h:304
0x991cbf estimate_edge_growth
../../gcc/gcc/ipa-inline.h:315
0x991cbf estimate_size_after_inlining(cgraph_node*, cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:4064
0x1315832 caller_growth_limits
../../gcc/gcc/ipa-inline.c:184
0x1315832 can_inline_edge_p
../../gcc/gcc/ipa-inline.c:382
0x131b622 inline_small_functions
../../gcc/gcc/ipa-inline.c:1822
0x131b622 ipa_inline
../../gcc/gcc/ipa-inline.c:2438
0x131b622 execute
../../gcc/gcc/ipa-inline.c:2849
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ cat abc.c
int a, g;
char b, e;
short c, d, f;
long long h;
void fn1() {
  for (;;)
;
}
void fn2(char p1) {
  b |= 5 > a < (f ?: e);
  fn1(a % c || (f -= 0) || 0, d < b,
  c < h % (h > d) ^ g ^ d ? 7 / (c /= b) : (h /= a %= a));
}
void fn3() { fn2(b); }

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

[mirq-gccboogs at rere dot qmqm.pl]

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

Michał Mirosław  changed:

   What|Removed |Added

 CC||mirq-gccboogs at rere dot 
qmqm.pl

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

void foo(const char *fmt, ...) __attribute__((format(printf, 1, 2)));

#define PREFIX "a:"
#define A(fmt, args...) foo(PREFIX fmt ".", ##args)

void bar()
{
A("%");
}

$ arm-linux-gnueabihf-gcc-7 -fsyntax-only -Wformat foo.c 

foo.c: In function ‘bar’:
foo.c:3:16: warning: conversion lacks type at end of format [-Wformat=]
 #define PREFIX "a:"
^
foo.c:4:29: note: in expansion of macro ‘PREFIX’
 #define A(fmt, args...) foo(PREFIX fmt ".", ##args)
 ^~
foo.c:8:2: note: in expansion of macro ‘A’
  A("%");
  ^
foo.c:4:41: note: format string is defined here
 #define A(fmt, args...) foo(PREFIX fmt ".", ##args)
 ^

The same happens with gcc-6.3.0.

[Bug tree-optimization/80576] dead strcpy and strncpy followed by memset not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
See also bug 79715.

[Bug c/80585] -Wformat location

[mirq-gccboogs at rere dot qmqm.pl]

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

Michał Mirosław  changed:

   What|Removed |Added

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

--- Comment #1 from Michał Mirosław  ---
Missclick, sorry for the noise.

[Bug c/80585] New: -Wformat location

[mirq-gccboogs at rere dot qmqm.pl]

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

Bug ID: 80585
   Summary: -Wformat location
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mirq-gccboogs at rere dot qmqm.pl
  Target Milestone: ---

[Bug tree-optimization/79715] hand-rolled strdup with unused result not eliminated

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Mon May  1 16:46:49 2017
New Revision: 247440

URL: https://gcc.gnu.org/viewcvs?rev=247440=gcc=rev
Log:
gcc/testsuite/ChangeLog:
PR tree-optimization/79715
* gcc.dg/pr79715.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr79715.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/79715] hand-rolled strdup with unused result not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
This works as expected on trunk and in GCC 7.  I have a feeling this has
actually worked since r233267.  The test case in comment #0 uses
-fdump-tree-printf-return-value instead of -fdump-tree-optimized to look at the
assembly and the printf-return-value pass runs before the DSE pass that
optimizes it.  Resolving as fixed.

[Bug tree-optimization/79697] unused realloc(0, n) not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Fixed by Prathamesh's patch in comment #8.

[Bug fortran/80467] Function Without Arguments Fails to Generate Error When Declared Later

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-01
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Dominique d'Humieres  ---
If the compiler is configures with --enable-checking=yes

I get

pr80467.f90:10:0:

 Subroutine TestArgs
 ^
Error: invalid types in conversion to floating point
real(kind=4)
real(kind=4) (*) (void)
compareto = (real(kind=4)) getvalue;
pr80467.f90:10:0: internal compiler error: verify_gimple failed

Per

R1221 function-reference is procedure-designator ( [ actual-arg-spec-list ] )

the code is invalid and it's the user's responsibility to provide the
parentheses.

If I remove the Function GetValue, I get the expected error

 compareTo = GetValue
1
Error: Symbol 'getvalue' at (1) has no IMPLICIT type

It would probably more user friendly to get this error with the original test.

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|i?86-*-*|x86
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-01
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

[Bug fortran/80554] [f08] variable redefinition in submodule

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
Note that if I replace the two lines

   integer :: i = ...

with

   integer :: i

I get the same error.

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May  1 15:38:14 2017
New Revision: 247439

URL: https://gcc.gnu.org/viewcvs?rev=247439=gcc=rev
Log:
PR target/68491
* config/i386/cpuid.h (__get_cpuid): Always return 0 when
__get_cpuid_max returns 0.
(__get_cpuid_count): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cpuid.h

[Bug fortran/80554] [f08] variable redefinition in submodule

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-01
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> I think GFortran should also accept the code. As far as I know, entities
> from the ancestor module are host associated, and we should be allowed
> to specify a local entity in the submodule with the same name.
> Or is there any restriction in the standard which forbids it?

How do you parse

> 16.3 Local identifiers
> 16.3.1 Classes of local identifiers
> 1 Identifiers of entities in the classes
>   (1) except for statement or construct entities (16.4), named variables,
>   named constants, named constructs, statement functions, internal
>   procedures, module procedures, dummy procedures, intrinsic procedures,
>   external procedures that have binding labels, intrinsic modules,
>   abstract interfaces, generic interfaces, derived types, namelist groups,
>   external procedures accessed via USE, and statement labels,
>   (2) type parameters, components, and type-bound procedure bindings,
>   in a separate class for each type,
>   (3) argument keywords, in a separate class for each procedure with an
>   explicit interface, and
>   (4) common blocks that have binding labels
> are local identifiers.
> 2 Within its scope, a local identifier of an entity of class (1) or class (4)
>   shall not be the same as a global identifier used in that scope unless
>   the global identifier
> • is used only as the use-name of a rename in a USE statement,
> • is a common block name (16.3.2),
> • is an external procedure name that is also a generic name, or
> • is an external function name and the inclusive scope is its defining
>   subprogram (16.3.3).

?

Why do you want to use such constructs? IMO, if they are not forbidden, using
them is asking for trouble.

[Bug testsuite/65941] FAIL: g++.dg/other/pr59492.C: no such instruction: rdrand

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

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

[Bug testsuite/65941] FAIL: g++.dg/other/pr59492.C: no such instruction: rdrand

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Mon May  1 14:15:33 2017
New Revision: 247438

URL: https://gcc.gnu.org/viewcvs?rev=247438=gcc=rev
Log:
Add and use effective target rdrand

2017-05-01  Tom de Vries  

PR testsuite/65941
* lib/target-supports.exp (check_effective_target_rdrand): New proc.
* g++.dg/other/pr59492.C: Require effective target rdrand.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/pr59492.C
trunk/gcc/testsuite/lib/target-supports.exp

[Bug target/78460] [7/8 Regression] [SH] OOM building glibc string tst-cmp.c

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
FWIW, my build-many-glibcs.py bots for GCC 7 and mainline are run with 
"ulimit -v 16777216" to limit the effects of this bug.

[Bug target/78460] [7/8 Regression] [SH] OOM building glibc string tst-cmp.c

[fw at gcc dot gnu.org]

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

--- Comment #3 from Florian Weimer  ---
I see ~500 GiB with GCC 7.0.1 20170501 (prerelease) [gcc-7-branch revision
247430].  This interferes rather badly with cross-compiler-based testing.

[Bug libstdc++/80493] std::experimental::optional::swap is ill formed

[a...@cloudius-systems.com]

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

--- Comment #3 from Avi Kivity  ---
Please consider a backport to older branches (5, 6, 7).

[Bug fortran/80524] [F03] Problematic behaviour with a finalization subroutine in gfortran

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #3)
> I think this depends a lot on the compiler implementation.

I don't actually think the calling of finalization routines is supposed to
depend on the compiler implementation. F08 is rather clear on where it should
happen, I guess.

For the missing cases, see also:
* PR 64290 (No finalization at deallocation of LHS)
* PR 65347 (Final subroutine not called for function result)

and PR 37336 comment 27 which includes both of them.

[Bug middle-end/80584] New: Combine some float tests using bit ops

[glisse at gcc dot gnu.org]

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

Bug ID: 80584
   Summary: Combine some float tests using bit ops
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

Some (ieee) float tests amount to bit operations, and some of the usual
optimizations on bit operations may thus apply.

d == 0 tests if all non-sign bits are 0, so
(d1 == 0) & (d2 == 0) is equivalent to (d1 | d2) == 0

!isfinite tests if the exponent is all ones, so
isfinite(d1) | isfinite(d2) is equivalent to isfinite(d1 & d2)

(I may have gotten one of those wrong, but something similar should work)

on platforms like x86 (SSE) that provide bit operations for floats, this could
be an interesting optimization. I don't think d1 can produce sNaN unless d1
or d2 is already sNaN, but d1|d2 can, so care might be needed there.

Doing it in gimple is problematic, after querying the target to see if it
provides IOR for double, we would have to cast to some integer type before
doing the bit operation then back, and trust that float bitops will be
generated, which works better since Jakub worked on it but still not perfectly.
Doing the transformation too early may also hinder other optimizations by
obfuscating the condition.

After expansion, the representation becomes quite large (setting the flags,
reading the flags, if_then_else, etc) and there is no hope for combine to
notice some special pattern.

I expect the most convenient place for this transformation would be during
expansion, when we get as input 3 simple statements and can directly write the
output using float bitops (if available).

[Bug target/80583] [6/7/8 Regression] ICE with target_clones and vectorized float: internal compiler error: in convert_move, at expr.c:270

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|WAITING |NEW
  Component|c++ |target
  Known to work||5.4.0
Summary|ICE with target_clones and  |[6/7/8 Regression] ICE with
   |vectorized float: internal  |target_clones and
   |compiler error: in  |vectorized float: internal
   |convert_move, at expr.c:270 |compiler error: in
   ||convert_move, at expr.c:270

--- Comment #3 from Markus Trippelsdorf  ---
markus@x4 tmp % cat main.ii
struct S {
  __attribute__((__vector_size__(8 * sizeof(0 int a;
};
int __attribute__((target_clones("default", "avx2"))) main() {
  S *b{};
  auto c(b->a);
}

markus@x4 tmp % g++ -c main.ii
main.ii: In function ‘int main.avx2.0()’:
main.ii:6:8: internal compiler error: in convert_move, at expr.c:231
   auto c(b->a);
^
0xa29043 convert_move(rtx_def*, rtx_def*, int)
/home/markus/gcc/gcc/expr.c:231
0xa30069 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/home/markus/gcc/gcc/expr.c:5629
0xa31783 expand_assignment(tree_node*, tree_node*, bool)
/home/markus/gcc/gcc/expr.c:5321
0x90e7b7 expand_gimple_stmt_1
/home/markus/gcc/gcc/cfgexpand.c:3639
0x90e7b7 expand_gimple_stmt
/home/markus/gcc/gcc/cfgexpand.c:3737
0x91087f expand_gimple_basic_block
/home/markus/gcc/gcc/cfgexpand.c:5744
0x91647e execute
/home/markus/gcc/gcc/cfgexpand.c:6357

[Bug c++/70528] [5 Regression] bogus error: constructor required before non-static data member

[dimitry at andric dot com]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||dimitry at andric dot com

--- Comment #17 from Dimitry Andric  ---
(In reply to Jason Merrill from comment #15)
> How important is it to fix this in GCC 5?

For the FreeBSD ports system, gcc 5.4 is currently still the default version
for programs requiring gcc.  So it would be nice to have this fix in the
branch.  And the fix itself does not seem to be very invasive.

[Bug c++/80583] ICE with target_clones and vectorized float: internal compiler error: in convert_move, at expr.c:270

[blaffablaffa at gmail dot com]

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

--- Comment #2 from Lorenzo Pistone  ---
Created attachment 41291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41291=edit
test case

My bad.

[Bug fortran/80392] [5/6/7/8 Regression] [OOP] ICE with allocatable polymorphic function result in a procedure pointer component

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
Fixed on trunk plus the 5 and 6 branches so far. Will apply to the 7-branch
once it reopens.

[Bug c++/80583] ICE with target_clones and vectorized float: internal compiler error: in convert_move, at expr.c:270

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-01
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Please attach the compressed testcase.

[Bug fortran/80392] [5/6/7/8 Regression] [OOP] ICE with allocatable polymorphic function result in a procedure pointer component

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon May  1 10:51:22 2017
New Revision: 247435

URL: https://gcc.gnu.org/viewcvs?rev=247435=gcc=rev
Log:
2017-05-01  Janus Weil  

Backport from trunk
PR fortran/80392
* trans-types.c (gfc_get_derived_type): Prevent an infinite loop when
building a derived type that includes a procedure pointer component
with a polymorphic result.

2017-05-01  Janus Weil  

Backport from trunk
PR fortran/80392
* gfortran.dg/proc_ptr_comp_49.f90: New test case.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_49.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

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

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
The last successful bootstrap is r247298; r247301 fails as reported in comment
0; r247299 fails for a different reason:

/opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/
-B/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/bin/
-B/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/lib/ -isystem
/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/include -isystem
/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/sys-include-c -g -O2 
-fno-common  -W -Wall -gnatpg -nostdinc   s-excmac.ads -o s-excmac.o
cannot generate code for file s-excmac.ads (package spec)

[Bug c++/80583] New: ICE with target_clones and vectorized float: internal compiler error: in convert_move, at expr.c:270

[blaffablaffa at gmail dot com]

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

Bug ID: 80583
   Summary: ICE with target_clones and vectorized float: internal
compiler error: in convert_move, at expr.c:270
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blaffablaffa at gmail dot com
  Target Milestone: ---

The test case in attachment unfortunately is relatively large, but I couldn't
isolate the issue.

The main() of this source file is prepended with

#ifdef __x86_64__
__attribute__((target_clones("default","avx","avx2")))
#endif

I use some operations on vector float types:

typedef float __attribute__((vector_size(32))) float8;
typedef float __attribute__((vector_size(16))) float4;
typedef float __attribute__((vector_size(8))) float2;

The compiler appears to stumble on some arithmetic operations on these

Compile with "g++ -std=c++1y -Wall -c -o main.o main.cpp". Error is:

In file included from /usr/include/c++/6.3.1/bits/stl_algo.h:61:0,
 from /usr/include/c++/6.3.1/algorithm:62,
 from main.cpp:4:
/usr/include/c++/6.3.1/bits/stl_heap.h: In function ‘void
std::__adjust_heap(_RandomAccessIterator, _Distance, _Distance, _Tp, _Compare)
[with _RandomAccessIterator = armorset*; _Distance = long int; _Tp = armorset;
_Compare = __gnu_cxx::__ops::_Iter_less_iter]’:
/usr/include/c++/6.3.1/bits/stl_heap.h:209:5: note: The ABI for passing
parameters with 32-byte alignment has changed in GCC 4.6
 __adjust_heap(_RandomAccessIterator __first, _Distance __holeIndex,
 ^
main.cpp: In function ‘int main.avx.298(int, char**)’:
main.cpp:477:85: internal compiler error: in convert_move, at expr.c:270
auto body_legs_abs = (body->absorptions.all - 100) * (legs->absorptions.all
- 100);
   
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccUaXkg3.out file, please attach this to
your bugreport.
[pisto@pisto ds3]$ g++  -std=c++1y -Wall -c -o main.o main.cpp
In file included from /usr/include/c++/6.3.1/bits/stl_algo.h:61:0,
 from /usr/include/c++/6.3.1/algorithm:62,
 from main.cpp:4:
/usr/include/c++/6.3.1/bits/stl_heap.h: In function ‘void
std::__adjust_heap(_RandomAccessIterator, _Distance, _Distance, _Tp, _Compare)
[with _RandomAccessIterator = armorset*; _Distance = long int; _Tp = armorset;
_Compare = __gnu_cxx::__ops::_Iter_less_iter]’:
/usr/include/c++/6.3.1/bits/stl_heap.h:209:5: note: The ABI for passing
parameters with 32-byte alignment has changed in GCC 4.6
 __adjust_heap(_RandomAccessIterator __first, _Distance __holeIndex,
 ^
main.cpp: In function ‘int main.avx.0(int, char**)’:
main.cpp:477:44: internal compiler error: in convert_move, at expr.c:270
auto body_legs_abs = (body->absorptions.all - 100) * (legs->absorptions.all
- 100);
  ~~^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc8Qjc34.out file, please attach this to
your bugreport.

[Bug target/79430] [8 Regression] action of statement incorrectly optimised away

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #85 from Jakub Jelinek  ---
Should be fixed now even on the trunk.

[Bug fortran/80392] [5/6/7/8 Regression] [OOP] ICE with allocatable polymorphic function result in a procedure pointer component

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon May  1 09:56:52 2017
New Revision: 247430

URL: https://gcc.gnu.org/viewcvs?rev=247430=gcc=rev
Log:
2017-05-01  Janus Weil  

Backport from trunk
PR fortran/80392
* trans-types.c (gfc_get_derived_type): Prevent an infinite loop when
building a derived type that includes a procedure pointer component
with a polymorphic result.

2017-05-01  Janus Weil  

Backport from trunk
PR fortran/80392
* gfortran.dg/proc_ptr_comp_49.f90: New test case.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_49.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-types.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/79430] [8 Regression] action of statement incorrectly optimised away

[jakub at gcc dot gnu.org]

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

--- Comment #84 from Jakub Jelinek  ---
Author: jakub
Date: Mon May  1 09:50:59 2017
New Revision: 247429

URL: https://gcc.gnu.org/viewcvs?rev=247429=gcc=rev
Log:
PR target/79430
* rtlanal.c (reg_set_p): If reg is a stack_pointer_rtx, also
check for stack push/pop autoinc.
* config/i386/i386.c (ix86_agi_dependent): Return false
if the only reason why modified_in_p returned true is that
addr is SP based and set_insn is a push or pop.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/rtlanal.c

[Bug target/69460] ARM Cortex M0 produces suboptimal code vs Cortex M3

[strntydog at gmail dot com]

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

--- Comment #5 from strntydog at gmail dot com ---
I also just calculated the number of cycles each function takes:

Test 1 - 50% More CPU Cycles
Test 2 - 25% More CPU Cycles
Test 3 - 5% More CPU Cycles
Test 4 - 39% More CPU Cycles
Test 5 - 6% More CPU Cycles
Test 6 - 46% More CPU Cycles

This assumes Zero Wait state access to memory, any wait states will make these
differences worse, as the excess cycles are the result of extra flash accesses.

So, even Test 3 and 5 which have the same code size will run ~5% slower than it
should, which is significant.  But the worst cases will be dramatically slower.

This bug leads not only to slower execution, but that has a direct impact on
Power Efficiency and battery life in battery powered devices (which are a
target market for M0/M0+ processors).

These are extremely common and simple memory access patterns, and every single
M0/M0+ program will be negatively effected by it.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #25 from John Paul Adrian Glaubitz  ---
Hi Segher!

Your patch fixes the issue for me. I had issues building ghc on powerpcspe.
With gcc-6 it failed in the expected way, with gcc-7, it went past the
problematic source code file.

Would it be possible that your backport your fix to the gcc-6 branch so we can
use it in the current Debian release?

Thanks,
Adrian

[Bug tree-optimization/80574] GCC fail to optimize nested ternary

[SztfG at yandex dot ru]

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

--- Comment #3 from SztfG at yandex dot ru ---
Georg-Johann Lay, GCC not always do things better if use static inline function
instead macro. For example, this code:

#include 

#define TYPE uint8_t

#define M_XOR(a,b) ((!!a)^(!!b))
#define M_NXOR(a,b) (!((!!a)^(!!b)))

__attribute__((__always_inline__, const))
static inline TYPE m_xor (const TYPE a, const TYPE b)
{
return M_XOR(a,b);
}

__attribute__((__always_inline__, const))
static inline TYPE m_xnor (const TYPE a, const TYPE b)
{
return M_NXOR(a,b);
}

// bad assembly output
int test1b(const TYPE a, const TYPE b)
{
return m_xor(a,b) == !m_xnor(a,b);
}

int test2b(const TYPE a, const TYPE b)
{
return !m_xor(a,b) == m_xnor(a,b);
}

int test3b(const TYPE a, const TYPE b)
{
return M_XOR(a,b) == !m_xnor(a,b);
}

// good assembly output
int test1g(const TYPE a, const TYPE b)
{
return m_xor(a,b) == M_XOR(a,b);
}

int test2g(const TYPE a, const TYPE b)
{
return M_XOR(a,b) == !M_NXOR(a,b);
}

int test3g(const TYPE a, const TYPE b)
{
return M_XOR(a,b) != !M_NXOR(a,b);;
}

[Bug ipa/80581] [8 Regression] ICE: in estimate_node_size_and_time, at ipa-inline-analysis.c:3425

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-01
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
Thanks.
Here is another one:

trippels@gcc2-power8 llvm_build % cat SelectionDAG.ii
struct A;
__attribute__((noreturn)) void report_fatal_error(A);
struct A {
  enum NodeKind {};
  struct Child {
int cString;
int decUI;
  } LHS;
  Child RHS;
  NodeKind LHSKind;
  NodeKind RHSKind;
  void m_fn1() const;
  A(char *);
  A(int) : RHSKind() { LHS.decUI = 0; }
  A m_fn2(const A &) const;
};
A A::m_fn2(const A ) const {
  int a, b;
  a = LHSKind == 0;
  if (a)
return 0;
  b = LHSKind == 1;
  if (b)
return p1;
  m_fn1();
}
inline A operator+(const A , const A ) { return p1.m_fn2(p2); }
void checkAddrSpaceIsValidForLibcall(int) {
  A c = "" + A(0);
  report_fatal_error(c);
}
void getMemcpy() { checkAddrSpaceIsValidForLibcall(0); }


trippels@gcc2-power8 llvm_build % g++ -c -w -O2 SelectionDAG.ii
SelectionDAG.ii:32:56: internal compiler error: in estimate_node_size_and_time,
at ipa-inline-analysis.c:3425
 void getMemcpy() { checkAddrSpaceIsValidForLibcall(0); }
^

[Bug target/80582] New: Missing intrinsics _mm256_set_m128*

[glisse at gcc dot gnu.org]

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

Bug ID: 80582
   Summary: Missing intrinsics _mm256_set_m128*
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

Apparently, Intel and clang have added a few intrinsics that we do not have,
like _mm256_set_m128. See
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150518/129430.html
for the list.

[Bug ipa/80581] [8 Regression] ICE: in estimate_node_size_and_time, at ipa-inline-analysis.c:3425

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #1 from Arseny Solokha  ---
Maybe not the smallest one, but still:

int ev, k8, le;

void
vp (int d5)
{
  if (ev != 0)
ev = 0;

  while (k8 != 0)
{
  k8 = 0;
  while (k8 != 0)
{
  k8 = ev;
  while (ev != 0)
{
  ev = 1;
  while (ev != 0)
le = 0;
  ++ev;
}
}

  le = ev;
  while (ev != 0)
{
qd:
  for (k8 = 0; k8 < 1; ++k8)
{
  k8 /= ev;
  le /= le / ((le + 1) / (k8 != 0));
  if (le != 0)
{
  ++k8;
  ev /= k8;
}
}
  ++ev;
}
  ev = 0;
}

  while (ev != 0)
{
  while (le != 0)
{
  for (k8 = 0; k8 < 1; ++k8)
{
  k8 /= le + 1;
  if (k8 != 0)
goto qd;
  while (le < 1)
++le;
}
  ++le;
  ++le;
}

  if (k8 != 0)
return;
}

  vp (d5);
}

% gcc-8.0.0-alpha20170430 -O1 -c uazbaemc.c 
uazbaemc.c:64:1: internal compiler error: in estimate_node_size_and_time, at
ipa-inline-analysis.c:3425
 }
 ^

[Bug ipa/80581] New: [8 Regression] ICE: in estimate_node_size_and_time, at ipa-inline-analysis.c:3425

[trippels at gcc dot gnu.org]

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

Bug ID: 80581
   Summary: [8 Regression] ICE: in estimate_node_size_and_time, at
ipa-inline-analysis.c:3425
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

Since r247417:

trippels@gcc2-power8 llvm_build % g++ -c -O2 SelectionDAG.ii
/home/trippels/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:7855:1: internal
compiler error: in estimate_node_size_and_time, at ipa-inline-analysis.c:3425
 }
 ^
0x108cff07 estimate_node_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:3425
0x108d0623 do_estimate_edge_time(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3937
0x108d0ce7 do_estimate_edge_size(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3989
0x108d19f7 estimate_edge_size
../../gcc/gcc/ipa-inline.h:304
0x108d19f7 estimate_edge_growth
../../gcc/gcc/ipa-inline.h:315
0x108d19f7 estimate_size_after_inlining(cgraph_node*, cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:4064
0x113d554b caller_growth_limits
../../gcc/gcc/ipa-inline.c:184
0x113d554b can_inline_edge_p
../../gcc/gcc/ipa-inline.c:382
0x113da34b update_caller_keys
../../gcc/gcc/ipa-inline.c:1348
0x113dc537 inline_small_functions
../../gcc/gcc/ipa-inline.c:2044
0x113dc537 ipa_inline
../../gcc/gcc/ipa-inline.c:2438
0x113dc537 execute
../../gcc/gcc/ipa-inline.c:2849
Please submit a full bug report

It also causes boostrap on on x86_64:
https://gcc.gnu.org/ml/gcc-regression/2017-05/msg0.html

Reducing..

[Bug tree-optimization/79224] [7/8 Regression] Large C-Ray slowdown

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #15 from Markus Trippelsdorf  ---
The patch causes bootstrap failure on x86_64:
https://gcc.gnu.org/ml/gcc-regression/2017-05/msg0.html