[Bug tree-optimization/79977] [6/7 Regression] [graphite] ICE in outermost_loop_in_sese, at sese.c:300 w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
The region in question is not single-exit.  merge_sese has

  basic_block pdom = nearest_common_dominator (CDI_POST_DOMINATORS,
   get_exit_bb (first),
   get_exit_bb (second));
  pdom = nearest_common_dominator (CDI_POST_DOMINATORS, dom, pdom);

  edge exit = get_nearest_pdom_with_single_exit (pdom);

  if (!exit || (exit->flags & EDGE_IRREDUCIBLE_LOOP))
return invalid_sese;

but that doesn't catch the case where we have a loop exit to an outer loop
latch.

I have a patch.

[Bug middle-end/79753] [7 Regression][CHKP] ICE in ix86_expand_builtin, at config/i386/i386.c:36869

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 40937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40937&action=edit
Untested patch draft

I'm sending patch for that. Problem is that we return false
__builtin_ia32_bndret (_1), where _1 is SSA NAME. False is returned because
BNDRET builtin accepts void *, which is not compatible to TREE_TYPE(_2), which
is int type.

With my patch, return_bounds variable is properly assigned at
tree-inline.c:4660.

Thoughts?

[Bug tree-optimization/77975] [6/7 Regression] Missed optimization for some small constants

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 9 Mar 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77975
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #4 from Jakub Jelinek  ---
> Created attachment 40936
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40936&action=edit
> gcc7-pr77975.patch
> 
> Actually I think your patch is fully correct.

It's been some time but I think I have tested my patch and it
failed somewhere, but maybe I just thought it was too simple.

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Mar  9 14:43:17 2017
New Revision: 246003

URL: https://gcc.gnu.org/viewcvs?rev=246003&root=gcc&view=rev
Log:
2017-03-09  Vladimir Makarov  

PR rtl-optimization/79949
* lra-constraints.c (process_alt_operands): Check memory when
trying to predict a cycle.  Print about the overall increase.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #17 from Jakub Jelinek  ---
David, can you reproduce with latest trunk?  Any chance to have some reduced
self-contained testcase (including main that invokes it)?

[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Root cause of the crash in comment #0 is an out-of-bounds memory write in the
RTL dump reader when handling SYMBOL_REFs with SYMBOL_FLAG_HAS_BLOCK_INFO set.

What's happening is that
  gcc/read-rtl-function.c:selftest::test_loading_symbol_ref
loads
  SRCDIR "/gcc/testsuite/selftests/symbol-ref.rtl"
which contains a "(symbol_ref)" with flags with SYMBOL_FLAG_HAS_BLOCK_INFO set.

Such SYMBOL_REFs are normally created by varasm.c:create_block_symbol, which
has:

  /* Create the extended SYMBOL_REF.  */
  size = RTX_HDR_SIZE + sizeof (struct block_symbol);

A normal SYMBOL_REF has the RTX_HDR_SIZE plus two rtunion
  (which on a x86_64 host is 8 + (2 * 8) = 24 bytes),
whereas a SYMBOL_REF with SYMBOL_REF_HAS_BLOCK_INFO_P () has RTX_HDR_SIZE +
sizeof (struct block_symbol);
  (which on a x86_64 host is 8 + 32 = 40 bytes)

So the reader allocates a 24-byte symbol_ref, and then this line:

1142SYMBOL_REF_BLOCK (x) = NULL;

implicitly assumes we have a 40-byte allocation, and writes zeros to whatever
is in memory after the 24-byte allocation.

In my tests, this happened to hit a cached INTEGER_CST for the "int" type,
converting its code to 0 (ERROR_MARK), and hence chaos ensues; in particular,
this leads to a crash in the garbage-collector when the pointer-walking visits
the corrupted tree, and attempts to access fields for the wrong TREE_CODE.

I'm testing a fix.

[Bug c++/70768] [6/7 Regression] Increased compilation time

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #11 from Jakub Jelinek  ---
Closing as not a bug, if you compare the same preprocessed sources, there is no
regression, if you compare different sources, the headers are changing, new
templates etc. are being added all the time.

[Bug rtl-optimization/79593] [6/7 Regression] Poor/Worse code generation for FPU on versions after 6

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #15)
> For the remaining issue:
> 
>mov eax, DWORD PTR [eax+4]
>...
>mov DWORD PTR [esp], eax # worse than v6: spills to stack!
>fld DWORD PTR [esp]  # instead of 'fsubr DWORD PTR [eax+4]'
>fsubrp  st(2), st
> 
> register allocator doesn't figure out that it loaded eax from [eax+4] a
> couple of insns above - instead of a spill, it can access the value from the
> same location.
> 
> This is a RA regression from gcc-5.

Vlad, do you think you could have a look at this?  I presume wants to spill a
reg to stack for "m" input and it has been loaded earlier from some other
memory location that hasn't been changed in between, it should be fine to use
the earlier memory location and omit the spill.

[Bug c/79979] New: For loop fails to exit

[jdowdells at hotmail dot com]

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

Bug ID: 79979
   Summary: For loop fails to exit
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdowdells at hotmail dot com
  Target Milestone: ---

Created attachment 40938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40938&action=edit
Test code which shows this issue

When I compile this code:


#include 
#include 
#include 
#include 

typedef enum
{
e_0,
e_1,
e_2,
e_3,
e_4,
e_5,
e_6,
e_7,
e_8,
e_9
};

int dummy_array[8];

int main(void)
{
int x = dummy_array[8];
 e;


printf("X = %d\n", x);
printf("address of dummy_array[0] = %p\n", &dummy_array[0]);
printf("address of dummy_array[100] = %p\n", &dummy_array[100]);

for (e = e_0; e

[Bug target/79935] DJGPP: misaligned stack in static constructors

[jwjagersma at gmail dot com]

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

--- Comment #4 from jwjagersma at gmail dot com ---
> More likely, DJGPP just doesn't support more than 8-byte alignment.
I just had the same problem in a normal function too, so I suppose that is the
case then. I do think djgpp should support 16-byte alignment since programs
compiled with it could potentially use SSE instructions (which is what I'm
trying to do, using -O3 -march=pentium3) which cause GP faults on misaligned
memory access.
Where do I submit this to the djgpp list? The bug tracker on delorie.com seems
very inactive.

[Bug c/79979] For loop fails to exit

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Given the UB you're invoking, all bets are off and the compiler is free to do
anything.  I don't think we want to change anything here.  Even -Warray-bounds
warns here.

[Bug target/79935] DJGPP: misaligned stack in static constructors

[dj at redhat dot com]

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

--- Comment #5 from DJ Delorie  ---
DJGPP issues should be sent to the dj...@delorie.com mailing list, or
comp.os.msdos.djgpp newsgroup.

[Bug c/79979] For loop fails to exit

[jdowdells at hotmail dot com]

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

--- Comment #2 from jdowdells at hotmail dot com ---
Thanks for your quick reply.

However, this is not intuitive, the compiler should be "free to do anything" in
a sensible intuitive manner.

The for loop is well defined and there is no conceivable circumstance that
should allow it to loop forever.

The optimized/unoptimized code should work the same but it does not.

If you want to make the unoptimized code loop for ever I'll be more than happy

Thanks again.

[Bug c/79979] For loop fails to exit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
No, undefined behavior means undefined behavior, anything can happen once you
trigger it, it can format your disk, launch missiles, do nothing, do what you
expect, do somethng different.  The compiler optimizes on the assumption that
the code is valid and does not invoke undefined behavior.

[Bug c/79979] For loop fails to exit

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Please read e.g. http://blog.regehr.org/archives/213 or other articles about UB
and just fix your code.

[Bug tree-optimization/79977] [6 Regression] [graphite] ICE in outermost_loop_in_sese, at sese.c:300 w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0.1
Summary|[6/7 Regression] [graphite] |[6 Regression] [graphite]
   |ICE in  |ICE in
   |outermost_loop_in_sese, at  |outermost_loop_in_sese, at
   |sese.c:300 w/ -O2   |sese.c:300 w/ -O2
   |-floop-nest-optimize|-floop-nest-optimize
  Known to fail|7.0 |

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/79977] [6 Regression] [graphite] ICE in outermost_loop_in_sese, at sese.c:300 w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  9 16:19:37 2017
New Revision: 246006

URL: https://gcc.gnu.org/viewcvs?rev=246006&root=gcc&view=rev
Log:
2017-03-09  Richard Biener  

PR tree-optimization/79977
* graphite-scop-detection.c (scop_detection::merge_sese):
Handle the case of extra exits to blocks dominating the entry.

* gcc.dg/graphite/pr79977.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr79977.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-scop-detection.c
trunk/gcc/testsuite/ChangeLog

[Bug c/79979] For loop fails to exit

[jdowdells at hotmail dot com]

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

jdowdells at hotmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #5 from jdowdells at hotmail dot com ---
Thanks for your feedback.

[Bug c++/79687] [5/6/7 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

--- Comment #22 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar  9 16:36:37 2017
New Revision: 246008

URL: https://gcc.gnu.org/viewcvs?rev=246008&root=gcc&view=rev
Log:
PR c++/79687
* init.c (constant_value_1): Break if the variable has a dynamic
initializer.

* g++.dg/expr/ptrmem8.C: New test.
* g++.dg/expr/ptrmem9.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/expr/ptrmem8.C
trunk/gcc/testsuite/g++.dg/expr/ptrmem9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79687] [5/6 Regression] Wrong code with pointer-to-member

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Wrong|[5/6 Regression] Wrong code
   |code with pointer-to-member |with pointer-to-member

--- Comment #23 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c/79969] C FE emits locus of forward enum declaration rather than definition into debug info

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  9 16:42:45 2017
New Revision: 246009

URL: https://gcc.gnu.org/viewcvs?rev=246009&root=gcc&view=rev
Log:
PR c/79969
* c-decl.c (start_enum): Adjust DECL_SOURCE_LOCATION of
TYPE_STUB_DECL.

* gcc.dg/debug/dwarf2/enum-loc1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/enum-loc1.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

a21s58j97pm6t44b

[Duncan Ratliff]

Hi
The Payment should appear within 30 minutes. Check up the bill 
(a21s58j97pm6t44b.docx) attached. 

Doc Access Key: B8YOH4wf2wg


Duncan Ratliff

a21s58j97pm6t44b.docx
Description: Attached file: a21s58j97pm6t44b.docx

[Bug c/79969] C FE emits locus of forward enum declaration rather than definition into debug info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug libstdc++/79980] New: Possible bug in codecvt.cpp bitmask setting code

[thakis at chromium dot org]

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

Bug ID: 79980
   Summary: Possible bug in codecvt.cpp bitmask setting code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thakis at chromium dot org
  Target Milestone: ---

codecvt.cpp has this snippet:

if (read_utf16_bom(from, mode) == little_endian)
  mode = codecvt_mode(mode & little_endian);

That probably should read

if (read_utf16_bom(from, mode) == little_endian)
  mode = codecvt_mode(mode | little_endian);

instead?

[Bug sanitizer/79757] ICE in declare_vars, at gimplify.c:634

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 7.

[Bug sanitizer/79757] ICE in declare_vars, at gimplify.c:634

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar  9 16:58:17 2017
New Revision: 246010

URL: https://gcc.gnu.org/viewcvs?rev=246010&root=gcc&view=rev
Log:
PR sanitizer/79757
* c-parser.c (c_parser_declaration_or_fndef): Don't sanitize old-style
parameter declarations with initializers.

* gcc.dg/ubsan/pr79757-1.c: New test.
* gcc.dg/ubsan/pr79757-2.c: New test.
* gcc.dg/ubsan/pr79757-3.c: New test.
* gcc.dg/ubsan/pr79757-4.c: New test.
* gcc.dg/ubsan/pr79757-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ubsan/pr79757-1.c
trunk/gcc/testsuite/gcc.dg/ubsan/pr79757-2.c
trunk/gcc/testsuite/gcc.dg/ubsan/pr79757-3.c
trunk/gcc/testsuite/gcc.dg/ubsan/pr79757-4.c
trunk/gcc/testsuite/gcc.dg/ubsan/pr79757-5.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/79981] New: Forwprop not working for __atomic_compare_exchange_n

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 79981
   Summary: Forwprop not working for __atomic_compare_exchange_n
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
  Target Milestone: ---

Trying to figure out why this sample program results on not so good Rtl code on
s390x:

--
extern void locked (void *lock);
extern void not_locked (void);
void csi (int *lock)
{
  int oldval = 0;

  if (__atomic_compare_exchange_n (lock, (void *) &oldval, 1, 1, 2, 0))
locked ((void *)lock);
  else
not_locked ();
}
--

Before forwprop2:

--
  _Bool _1;
  __complex__ unsigned int _8;
  unsigned int _9;

   [100.00%]:
  _8 = ATOMIC_COMPARE_EXCHANGE (lock_4(D), 0, 1, 260, 2, 0);
  _9 = IMAGPART_EXPR <_8>;
  _1 = (_Bool) _9;
  if (_1 != 0)
  ...
--

Although Gcc seems to know that the SImode value from the complex number can
only have values 0 and 1, it fails to propagate _9 into the condition: "if (_9
!= 0)".

For similar code that calls a normal function, forwprop does exactly that:

--
extern _Complex int func(int *lock, void *old, int new);
extern void locked (void *lock);
extern void not_locked (void);
void foo(int *lock)
{
  int oldval = 0;
  int i = __imag__ func(lock, (void *)&oldval, 1);
  _Bool b = (_Bool)i;

  if (b)
locked ((void *)lock);
  else
not_locked ();
}
--

We get (before forwprop1):

--
  complex int _1;

   [0.00%]:
  oldval = 0;
  _1 = func (lock_5(D), &oldval, 1);
  i_7 = IMAGPART_EXPR <_1>;
  b_8 = i_7 != 0;
  if (b_8 != 0)
--

=>

--
;; Function foo (foo, funcdef_no=0, decl_uid=2024, cgraph_uid=0,
symbol_order=0)

Applying pattern match.pd:932, gimple-match.c:164
Applying pattern match.pd:3002, gimple-match.c:61428
gimple_simplified to if (b_8 != 0)
Applying pattern match.pd:932, generic-match.c:136
Applying pattern match.pd:3002, generic-match.c:31977
  Replaced 'b_8 != 0' with 'i_7 != 0'
...
  _1 = func (lock_5(D), &oldval, 1);
  i_7 = IMAGPART_EXPR <_1>;
  if (i_7 != 0)
  ...
--

What can be done to get rid of the _Bool stuff in the first program?  (The Rtl
code generated by the _Bool logic stays around too long, until Combine, and
foils optimizations in the s390x pattern for compare-and-swap.)

[Bug driver/79875] diagnostics: missing question mark after "did you mean"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-09
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

I grepped the rest of the source tree; this seemed to be the only instance.

Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00448.html

[Bug target/79925] aarch64: misplaced quote in diagnostic

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00447.html

[Bug translation/79923] diagnostics: some diagnostics have trailing period

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00450.html

[Bug c/79921] missing translation for "...this statement, but the latter is misleadingly indented"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-09
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00449.html

[Bug fortran/79852] diagnostics should not end with exclamation mark

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00445.html

[Bug ipa/79848] diagnostics: too complicated %<%s%>

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00444.html

[Bug target/79926] i386: untranslated placeholder "exception/interrupt" in diagnostic

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00446.html

[Bug middle-end/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM)

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

--- Comment #5 from Marc Mutz  ---
Why is this only "missed-optimization"? Don't these architecture's ABIs
stipulate passing in registers, as well as the Itanium ABI? So why is this not
a platform ABI conformance issue?

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-09
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Oops. Bits are hard.

[Bug libgcc/79982] New: Compiler crashes when using illegal concepts (nested requirements)

[gcc.bugzilla at cpockrandt dot de]

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

Bug ID: 79982
   Summary: Compiler crashes when using illegal concepts (nested
requirements)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.bugzilla at cpockrandt dot de
  Target Milestone: ---

Created attachment 40939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40939&action=edit
output when compiler crashes

I'm using the latest snapshot of g++-7 (7-20170305) and compile with
"-fconcepts -std=c++17". When using nested requirements with "auto" or when the
type inside the requirements is not known, the compiler crashes.

template 
concept bool my_concept = requires(T t)
{
requires requires (int val) { { t.serialize(val) } -> void; };
};

class my_class
{
void serialize(int);
};

static_assert(my_concept);

The compiler *also* crashes with this line of code (not sure whether it's
actually illegal code or not)

requires requires (T t, auto val) { { t.serialize(val) } -> void; };

Complete crash output and both code samples are attached.

[Bug jit/77355] FAIL: jit.dg/test-threads.c: error: static declaration of 'dejagnu_pass' follows non-static declaration

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
I believe I fixed this as r244597; please reopen if you still see issues with
test-threads.c.

[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00454.html

[Bug c/79983] New: Improve enum and struct redefinition diagnostic

[mpolacek at gcc dot gnu.org]

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

Bug ID: 79983
   Summary: Improve enum and struct redefinition diagnostic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As discussed here 
we should do better enum/struct redefinition.

Here

enum E;
enum E { A, B, C };
enum E { D, F };

and here

struct S;
struct S { int i; };
struct S { int i, j; };

gcc gives suboptimal

ll.c:3:8: error: redefinition of ‘struct S’
 struct S { int i, j; };
^
ll.c:1:8: note: originally defined here
 struct S;
^

while clang gets it right:
ll.c:3:8: error: redefinition of 'S'
struct S { int i, j; };
   ^
ll.c:2:8: note: previous definition is here
struct S { int i; };
   ^

[Bug c/79983] Improve enum and struct redefinition diagnostic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-09
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/79984] New: [6/7 Regression] ICE with -Wnonnull-compare

[mpolacek at gcc dot gnu.org]

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

Bug ID: 79984
   Summary: [6/7 Regression] ICE with -Wnonnull-compare
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

While working on PR79962 I found another ICE:

enum { r = 1 };

__attribute__ ((nonnull (r))) int
f (int *p)
{
  return *p;
}


$ ./cc1plus -quiet -Wnonnull-compare ice.cc
ice.cc: In function ‘int f(int*)’:
ice.cc:7:1: internal compiler error: tree check: expected integer_cst, have
const_decl in decompose, at tree.h:5256
 }
 ^
0x137035e tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marek/src/gcc/gcc/tree.c:9819
0x78e322 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/home/marek/src/gcc/gcc/tree.h:3320
0x78e656 wi::int_traits::decompose(long*, unsigned int,
tree_node const*)
/home/marek/src/gcc/gcc/tree.h:5256
0xc849e9 wide_int_ref_storage::wide_int_ref_storage(tree_node const* const&, unsigned int)
/home/marek/src/gcc/gcc/wide-int.h:976
0xc82ec4 generic_wide_int
>::generic_wide_int(tree_node const* const&, unsigned int)
/home/marek/src/gcc/gcc/wide-int.h:753
0x138531d bool wi::eq_p(tree_node const* const&, int
const&)
/home/marek/src/gcc/gcc/wide-int.h:1747
0x13679a9 tree_int_cst_sgn(tree_node const*)
/home/marek/src/gcc/gcc/tree.c:7365
0x1368797 compare_tree_int(tree_node const*, unsigned long)
/home/marek/src/gcc/gcc/tree.c:7574
0x13822b5 nonnull_arg_p(tree_node const*)
/home/marek/src/gcc/gcc/tree.c:14349
0x19d3f97 do_warn_nonnull_compare
/home/marek/src/gcc/gcc/gimple-ssa-nonnull-compare.c:42
0x19d433a execute
/home/marek/src/gcc/gcc/gimple-ssa-nonnull-compare.c:142
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/79984] [6/7 Regression] ICE with -Wnonnull-compare

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Started with r233472.

[Bug c++/79984] [6/7 Regression] ICE with -Wnonnull-compare

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-09
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.4
 Ever confirmed|0   |1

[Bug c++/79984] [6/7 Regression] ICE with -Wnonnull-compare

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
The fix is same as for PR79962.

[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-09
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig  ---
A couple of points:

First, the slow random number generation.  While I do not
understand why using the loop the way you do makes things
slower with optimization, it is _much_ faster to generate
random numbers in large chunks, as in

call random_number(NU)
call random_number(NV)

Second, the optimization.  With current trunk, you have
to add statements to make sure that the optimizers do
not notice you don't actually use your results :-)

I added

s_total = 0.0_dp

...

do i = 1, i_max
  tp = TP_SUM(NU(:,i), P(1:4,1:4), NV(:,i))
  s_total = s_total + sum(tp%vec)
end do

...

print *,s_total

to the test cases so that the tests don't suddenly use zero
CPU seconds.

Third, you really have to look to what you are doing
with your specific test cases, together with LTO and
data analysis.

Looking at your test case, your Tensor P is always the same.
I don't know if this is representative of your problem or not.
It has a huge effect on speed, because your routines are
completely inlined (and unrolled) with -flto -Ofast.
Not having to reload the data for P makes things much faster.

Compare:

ig25@linux-d6cw:~/Krempel/Tensor> gfortran -march=native -Ofast -fno-inline
tp_array_2.f90 
ig25@linux-d6cw:~/Krempel/Tensor> ./a.out
 This code variant uses intrinsic arrays to represent the contents of
Type(Vect3D).
 Random Numbers, time: 1.4114
 Using SUM, time: 0.88811
 Using MATMUL (L), time:  0.81236
 Using MATMUL (R), time:  0.89508
   2415021069.9784665 
ig25@linux-d6cw:~/Krempel/Tensor> gfortran -march=native -Ofast -flto
tp_array_2.f90 
ig25@linux-d6cw:~/Krempel/Tensor> ./a.out
 This code variant uses intrinsic arrays to represent the contents of
Type(Vect3D).
 Random Numbers, time: 1.4114
 Using SUM, time: 0.74707
 Using MATMUL (L), time:  0.132000208
 Using MATMUL (R), time:  0.13518

[Bug c/35441] pretty-printer cannot handle some expressions

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
This is a problem with deducing through what I'm calling "non-transparent"
aliases in partial ordering.  When partial ordering compares, say, const and
const volatile, we deduce "volatile __has_tuple_size" and then substitute
it, producing the odd

const volatile __has_tuple_size>

which compares as different from

const volatile __has_tuple_size

so we decide that they are unordered.  Oops.

My alias-equiv proposal would prevent the deduction in the first place, as
pointed out on the committee IRC the other day, which I guess would entirely
prevent constraining partial specializations.  It would be nice if you could
write instead

template > 
  struct tuple_size 

this seems like an oversight, much like the former prohibition of default
template arguments on functions.

Hmm.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[adam at aphirst dot karoo.co.uk]

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

--- Comment #12 from Adam Hirst  ---
Created attachment 40940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40940&action=edit
call graph of my "real" application

Thanks Thomas,

My "real" application is of course not using random numbers for the NU and NV,
but I will bear in mind the point about generating large chunks for the future.

I noticed too that enough optimisation flags resulted in an execution time of 0
seconds. I worked around it by writing all the results into an array,
evaluating the second "timing" variable, then asking for user input to specify
which result(s) to print.

In my "real" application, the Tensor P (or D, whatever I'm calling it this
week) is a 4x4 segment of a larger 'array' of Type(Vector), whose elements keep
varying (they're the control points of a B-Spline surface, and I'm more-or-less
doing shape optimisation on that surface).

The whole reason I was looking into this in the first place is that gprof
(along with useful plots by gprof2dot, one of which is attached) consistently
shows that it is this TensorProduct routine which BY FAR dominates. So my
options are either i) make it faster, or 2) need to call it less (which is more
a matter of algorithm design, and is a TODO for later investigation).

In any case, switching my TensorProduct routine to the one where the matmul()
and dot_product() are computed separately (though with no further array
temporaries, see one of my earlier comments in this thread) yielded the best
speed-up in my "real" application. Not as drastic as the reduced test case, but
still much more than a factor of two faster, whether building with -O2 or
-Ofast -flto.

[Bug c++/79962] [5/6/7 Regression] ICE nonnull_check_p on a function template with a type-dependent attribute nonnull

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar  9 22:45:39 2017
New Revision: 246016

URL: https://gcc.gnu.org/viewcvs?rev=246016&root=gcc&view=rev
Log:
PR c++/79962
PR c++/79984
* c-attribs.c (handle_nonnull_attribute): Save the result of default
conversion to the attribute list.

* c-c++-common/nonnull-3.c: New test.
* g++.dg/warn/Wnonnull3.C: New test.

Added:
trunk/gcc/testsuite/c-c++-common/nonnull-3.c
trunk/gcc/testsuite/g++.dg/warn/Wnonnull3.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79984] [6/7 Regression] ICE with -Wnonnull-compare

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar  9 22:45:39 2017
New Revision: 246016

URL: https://gcc.gnu.org/viewcvs?rev=246016&root=gcc&view=rev
Log:
PR c++/79962
PR c++/79984
* c-attribs.c (handle_nonnull_attribute): Save the result of default
conversion to the attribute list.

* c-c++-common/nonnull-3.c: New test.
* g++.dg/warn/Wnonnull3.C: New test.

Added:
trunk/gcc/testsuite/c-c++-common/nonnull-3.c
trunk/gcc/testsuite/g++.dg/warn/Wnonnull3.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79984] [6 Regression] ICE with -Wnonnull-compare

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |-Wnonnull-compare   |-Wnonnull-compare

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/79962] [5/6 Regression] ICE nonnull_check_p on a function template with a type-dependent attribute nonnull

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE  |[5/6 Regression] ICE
   |nonnull_check_p on a|nonnull_check_p on a
   |function template with a|function template with a
   |type-dependent attribute|type-dependent attribute
   |nonnull |nonnull

--- Comment #6 from Marek Polacek  ---
Fixed on trunk so far.

[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Guess forwprop would need to ask get_range_info here and if that says the value
is really just [0, 1], propagate.

[Bug tree-optimization/77975] [6/7 Regression] Missed optimization for some small constants

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 10 07:53:57 2017
New Revision: 246021

URL: https://gcc.gnu.org/viewcvs?rev=246021&root=gcc&view=rev
Log:
PR tree-optimization/77975
* tree-ssa-loop-niter.c (get_base_for): Allow phi argument from latch
edge to be constant.
(get_val_for): For constant x return it.  Formatting fix.
(loop_niter_by_eval): Avoid pointless looping if the next iteration
would use the same bases as the current one.

* gcc.dg/pr77975.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr77975.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug tree-optimization/79972] ICE in tree check: expected ssa_name, have var_decl in get_range_info, at tree-ssanames.c:377 w/ -Walloca -Wvla-larger-than=364854541

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 10 07:55:00 2017
New Revision: 246022

URL: https://gcc.gnu.org/viewcvs?rev=246022&root=gcc&view=rev
Log:
PR tree-optimization/79972
* gimple-ssa-warn-alloca.c (alloca_call_type): Only call
get_range_info on SSA_NAMEs.  Formatting fixes.

* gcc.dg/pr79972.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr79972.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-alloca.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/79909] [7 Regression] ICE error: invalid rtl sharing found in the insn on ppc64le

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 10 07:57:45 2017
New Revision: 246023

URL: https://gcc.gnu.org/viewcvs?rev=246023&root=gcc&view=rev
Log:
PR rtl-optimization/79909
* combine.c (try_combine): Use simplify_replace_rtx on individual
CALL_INSN_FUNCTION_USAGE elements instead of replace_rtx on copy_rtx
of the whole CALL_INSN_FUNCTION_USAGE.

* gcc.target/powerpc/pr79909.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79909.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog