[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)

[damian at sourceryinstitute dot org]

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

--- Comment #6 from Damian Rouson  ---
I don't have any specific knowledge of it being fixed, but there have been two
releases since 6.1.0: the latest is 6.3.0 and 7.1.0 is expected to be released
soon so the current trunk is a nearly releasable state.  In case it helps, both
6.3.0 and a relatively recent build of 7.0.0 are available in the virtual
machine here: www.sourceryinstitute.org/store.

On a separate note, I am in the process of trying to decide about whether I
will continue to use allocatable polymorphic function results because they are
not allowed in pure functions of which I'm a big fan both for code clarity and
potential performance benefits and especially for the ease with which one can
parallelize expressions comprised of operators implemented as pure functions.

Last, FORALL will be declared obsolescent in Fortran 2015.  In the example that
you posted, I recommend considering DO CONCURRENT as a replacement wherever
possible.

Damian

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[chefmax at gcc dot gnu.org]

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

--- Comment #19 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Wed Jan 25 07:45:40 2017
New Revision: 244890

URL: https://gcc.gnu.org/viewcvs?rev=244890=gcc=rev
Log:
PR lto/79061

gcc/

* asan.c (get_translation_unit_decl): New function.
(asan_add_global): Extract modules file name from globals
TRANSLATION_UNIT_DECL name.

gcc/fortran/

* f95-lang.c (gfc_create_decls): Include stringpool.h.
Pass main_input_filename to build_translation_unit_decl.

gcc/ada/

* gcc-interface/utils.c (get_global_context): Pass main_input_filename
to build_translation_unit_decl.

gcc/c/

* c-decl.c (pop_scope): Pass main_input_filename to
build_translation_unit_decl.

gcc/cp/

* decl.c (cxx_init_decl_processing): Pass main_input_filename
to build_translation_unit_decl.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/utils.c
trunk/gcc/asan.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
I am leaning toward accepting Bin's patch, but testing whether that hurts
generated code too much still hasn't finished.

[Bug middle-end/79223] missing -Wstringop-overflow on a memmove overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-25
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79222
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/79223] New: missing -Wstringop-overflow on a memmove overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 79223
   Summary: missing -Wstringop-overflow on a memmove overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the test case below, the -Wstringop-overflow detects the buffer overflow in
the call to memmove() in function f() but fails to detect the same overflow in
the call to __builtin_memove().

This is another case I missed when implementing the warning, in addition to bug
79222.

$ cat t.c && gcc -D_FORTIFY_SOURCE=2 -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-vrp=/dev/stdout t.c
#include 

char d[3];

void f (void)
{
  memmove (d, d + 1, 17);
}

void g (void)
{
  __builtin_memmove (d, d + 1, 17);
}


;; Function f (f, funcdef_no=24, decl_uid=2254, cgraph_uid=24, symbol_order=25)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f ()
{
   [100.00%]:
  __builtin___memmove_chk (, [(void *) + 1B], 17, 3);
  return;

}



;; Function f (f, funcdef_no=24, decl_uid=2254, cgraph_uid=24, symbol_order=25)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f ()
{
   [100.00%]:
  __builtin___memmove_chk (, [(void *) + 1B], 17, 3);
  return;

}


In file included from /usr/include/string.h:639:0,
 from t.c:1:
In function ‘memmove’,
inlined from ‘f’ at t.c:7:3:
/usr/include/bits/string3.h:57:10: warning: ‘__builtin___memmove_chk’ writing
17 bytes into a region of size 3 overflows the destination
[-Wstringop-overflow=]
   return __builtin___memmove_chk (__dest, __src, __len, __bos0 (__dest));
  ^~~

;; Function g (g, funcdef_no=25, decl_uid=2257, cgraph_uid=25, symbol_order=26)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



g ()
{
   [100.00%]:
  __builtin_memmove (, [(void *) + 1B], 17);
  return;

}



;; Function g (g, funcdef_no=25, decl_uid=2257, cgraph_uid=25, symbol_order=26)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



g ()
{
   [100.00%]:
  __builtin_memmove (, [(void *) + 1B], 17);
  return;

}

[Bug middle-end/79222] missing -Wstringop-overflow= on a stpcpy overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-25
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Let me fix it.

[Bug middle-end/79222] New: missing -Wstringop-overflow= on a stpcpy overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 79222
   Summary: missing -Wstringop-overflow= on a stpcpy overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The new -Wstrop-overflow added in r243419 fails to diagnose buffer overflows
caused by calls to the stpcpy function.  Looks like I missed that function.

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout t.c
char d[3];

char* f (int i)
{
  const char *s = i < 0 ? "01234567" : "9876543210";
  return __builtin_stpcpy (d, s);
}

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

Removing basic block 3
f (int i)
{
  const char * iftmp.0_1;
  char * _5;

   [100.00%]:
  if (i_2(D) < 0)
goto ; [32.39%]
  else
goto ; [67.61%]

   [67.61%]:

   [100.00%]:
  # iftmp.0_1 = PHI <"01234567"(2), "9876543210"(3)>
  _5 = __builtin_stpcpy (, iftmp.0_1); [tail call]
  return _5;

}

[Bug middle-end/79221] New: missing -Wstringop-overflow= on a strcat overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 79221
   Summary: missing -Wstringop-overflow= on a strcat overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 79220, the -Wstringop-overflow option diagnoses the buffer
overflow in the call to strcat in f() in the program below but fails to do the
same for the strcat() overflow in g().  As in the referenced bug, GCC
transforms the second strcat() to an assignment followed by a call to memcpy,
defeating the overflow detection.  GCC should avoid this transformation when
the destination isn't big enough for the copy.

I expect this bug will be resolved by a comprehensive fix for bug 79220 but it
seems that keeping track of each of these troublesome -- even though not
invalid -- transformations separately might help assure that the fix does, in
fact, resolve all these related problems.

(Both cases of overflow are diagnosed when _FORTIFY_SOURCE is defined.)


$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout t.c
#include 

char d[3];

void f (int i)
{
  const char *s = i < 0 ? "01234567" : "89abcd";
  strcat (d, s);
}


void gf (int i)
{
  const char *s = i < 0 ? "12345678" : "87654321";
  strcat (d, s);
}

;; Function f (f, funcdef_no=14, decl_uid=2196, cgraph_uid=14, symbol_order=15)

Removing basic block 3
f (int i)
{
  const char * iftmp.0_1;

   [100.00%]:
  if (i_2(D) < 0)
goto ; [32.39%]
  else
goto ; [67.61%]

   [67.61%]:

   [100.00%]:
  # iftmp.0_1 = PHI <"01234567"(2), "89abcd"(3)>
  strcat (, iftmp.0_1); [tail call]
  return;

}


t.c: In function ‘f’:
t.c:8:3: warning: ‘strcat’ writing 7 bytes into a region of size 3 overflows
the destination [-Wstringop-overflow=]
   strcat (d, s);
   ^

;; Function gf (gf, funcdef_no=15, decl_uid=2200, cgraph_uid=15,
symbol_order=16)

Removing basic block 3
gf (int i)
{
  char[9] * iftmp.1_1;
  long unsigned int _5;
  char[3] * _6;

   [100.00%]:
  if (i_2(D) < 0)
goto ; [32.39%]
  else
goto ; [67.61%]

   [67.61%]:

   [100.00%]:
  # iftmp.1_1 = PHI <"12345678"(2), "87654321"(3)>
  _5 = __builtin_strlen ();
  _6 =  + _5;
  __builtin_memcpy (_6, iftmp.1_1, 9); [tail call]
  return;

}

[Bug c/79216] Feature request: byte order attributes

[hpa at zytor dot com]

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

--- Comment #4 from H. Peter Anvin  ---
As in, I would expect that:

struct foo __attribute__((scalar_storage_order("big-endian")))
{
uint32_t bar;
} foo;

uint32_t *baz = 

... would give an error on a littleendian architecture and a warning on a
bigendian architecture, however, at this point it seems to be completely quiet
about it.

Finally, the section in the manual about type-punning in the presence of this
attribute is very opaque to me.  I am not sure what it means is allowed or
disallowed, or how things would work in the presence of casts.

[Bug c/79216] Feature request: byte order attributes

[hpa at zytor dot com]

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

--- Comment #3 from H. Peter Anvin  ---
It does indeed, I don't know why I missed it.  The only thing that I really see
as a problem with it is that it doesn't allow the assignment of endianness to
scalar pointers, e.g.:

uint32_t __attribute__((scalar_storage_order("big-endian"))) *blah;

blah = /* bigendian field in a structure */

The other thing that seems problematic to me (but this is a
quality-of-implementation issue, not a syntactic problem) is that it seems that
the endianness restrictions only apply on opposite-endian architectures.  This
makes programmer errors more likely.

[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Host||77799

--- Comment #1 from Martin Sebor  ---
See also bug 77799 for a similar problem involving sprintf.

[Bug tree-optimization/70717] missing warning on trivial buffer overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79214,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79220
 Resolution|--- |FIXED
   Severity|normal  |enhancement

--- Comment #4 from Martin Sebor  ---
The -Wstringop-overflow option has been added to warn on many of these types of
problems.

Unfortunately, it doesn't handle this particular case because GCC transforms
the memcpy call to assignment before the warning gets a chance to detect it. 
It's also defeated by the -Wno-system-headers option on systems that define
memcpy et al. as macros in .  Since these limitations are being
tracked in other bugs (the former in bug 79220 and the latter in bug 79214)
I'll go ahead and resolve this enhancement request as fixed.  Please open new
bugs with any additional requests or for new problems in -Wstringop-overflow.

[Bug middle-end/79220] New: missing -Wstringop-overflow= on a memcpy overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 79220
   Summary: missing -Wstringop-overflow= on a memcpy overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Both of the two calls to memcpy in the functions in the test case below
trivially overflow the destination, yet only the one in f() is diagnosed.  The
one in g() is not because GCC transforms the memcpy call to assignment. 
Between the two, from a security point, overflowing a buffer with unknown data
is a more serious problem than overwriting it with data already
present/hardcoded in the program.  GCC should avoid performing the
transformation unless the destination is known to be big enough for the write.

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout t.c
#include 

char d[3];

void f (void)
{
  memcpy (d, "0123456789", 8);
}

void g (const char *s)
{
  memcpy (d, s, 8);
}

;; Function f (f, funcdef_no=14, decl_uid=2196, cgraph_uid=14, symbol_order=15)

f ()
{
   [100.00%]:
  memcpy (, "0123456789", 8); [tail call]
  return;

}


t.c: In function ‘f’:
t.c:7:3: warning: ‘memcpy’ writing 8 bytes into a region of size 3 overflows
the destination [-Wstringop-overflow=]
   memcpy (d, "0123456789", 8);
   ^~~

;; Function g (g, funcdef_no=15, decl_uid=2199, cgraph_uid=15, symbol_order=16)

g (const char * s)
{
  long unsigned int _3;

   [100.00%]:
  _3 = MEM[(char * {ref-all})s_2(D)];
  MEM[(char * {ref-all})] = _3;
  return;

}

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #9 from Bernd Schmidt  ---
Ok, I'll look.

[Bug fortran/49025] gfortran bug: Local variable does not hide generic procedure.

[david.sagan at gmail dot com]

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

--- Comment #2 from David Sagan  ---
Bug present in 5.3.1

[Bug c/79217] Feature request: high half of an integer multiplication

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-24
 Ever confirmed|0   |1

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||bernds at redhat dot com

--- Comment #8 from Jeffrey A. Law  ---
Bernd.  There's a belief this may be a combiner issue, so it might be something
you'd want to poke at.

I can still trigger this failure on the trunk using -ftree-loop-if-convert on
an aarch64 native.  If you need access to an aarch64 system, let me know, I've
got one provisioned.

[Bug c/448] -related issues (C99 issues)

[joseph at codesourcery dot com]

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

--- Comment #33 from joseph at codesourcery dot com  ---
I think it's appropriate for this bug to track the missing pieces, whether 
directly or through dependencies on a series of bugs for each target OS.

[Bug c++/79205] ICE in create_tmp_var, at gimple-expr.c:473

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/448] -related issues (C99 issues)

[msebor at gcc dot gnu.org]

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

--- Comment #32 from Martin Sebor  ---
Thanks.  I wonder if the incomplete support on those targets should be handled
as separate bug reports raised by users if/when they run into problems.  That
way this large bug could be closed as resolved.  Would that work for you?

[Bug c/69602] [6/7 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[msebor at gcc dot gnu.org]

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

--- Comment #16 from Martin Sebor  ---
There are straightforward ways to avoid interspersing code with preprocessor
conditionals:

  #if EAGAIN == EWOULDBLOCK 
  #  #define EAGAIN_OR_WOULDBLOCK(e) (e == EAGAIN)
  #else
  #  #define EAGAIN_OR_WOULDBLOCK(e) (e == EAGAIN || e == EWOULDBLOCK)
  #endif

  ...

  if (cchRead < 0 && EAGAIN_OR_WOULDBLOCK (errno))

The point is that the warning is simple and works as designed.  As others have
noted, handling this case is non-trivial and as with any non-trivial solution
could easily have unforeseen side-effects and even lead to bugs (at a minimum,
likely false negatives).  I ended up here because I've been researching just
such a problem.  So unless the idiom in comment #0 is pervasive and leads to
many warnings I would suggest to leave it to programs to deal with.  Marek and
Jakub will likely have an idea of how common it is once they rebuild Fedora
with GCC 7.  If you have data of your own that might be helpful as well.

[Bug c++/79205] ICE in create_tmp_var, at gimple-expr.c:473

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 24 22:33:41 2017
New Revision: 244885

URL: https://gcc.gnu.org/viewcvs?rev=244885=gcc=rev
Log:
PR c++/79205
* cp-gimplify.c (cp_genericize_r): Add result of
convert_from_reference on invisiref parm to p_set.

* g++.dg/cpp1z/decomp22.C: New test.
* g++.dg/cpp1z/decomp23.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp22.C
trunk/gcc/testsuite/g++.dg/cpp1z/decomp23.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c/79216] Feature request: byte order attributes

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
Does the scalar_storage_order attribute added in GCC 6 help for at least 
some of this?

[Bug c/448] -related issues (C99 issues)

[joseph at codesourcery dot com]

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

--- Comment #31 from joseph at codesourcery dot com  ---
The following targets still appear to be missing this type information in 
GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64), 
VxWorks, SymbianOS, LynxOS, QNX, TPF.  Others have either been fixed, or 
obsoleted and removed.

[Bug lto/69188] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[anthonyfk at gmail dot com]

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

anthonyfk at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #28 from anthonyfk at gmail dot com ---
The plot thickens.

Before trying a newer gcc, I ran a quick sanity check to make sure that the bug
in comment 26 was repeatable. It compiled fine! So I set the compilation of
lapack-3.6.1 up in a loop which would break on failure. After several
iterations I got a different failure:

lto1: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2761
0x54dcb9 read_cgraph_and_symbols
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2761
0xc9045a lto_main()
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:3310
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /usr/local/solido/tools/20170120/bin/gfortran
returned 1 exit status
compilation terminated.
/usr/local/solido/tools/20170120/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:134: ../xeigtstc] Error 1

My best guess is that this is some race condition (I have 12 cores going at
once) but I can't imagine how. Regardless, I'm convinced that this is a
different issue that may have more to do with the environment than gcc. Sorry
for the noise! If I have time, I'll try to make a reduced, reproducible case as
a new bug.

Thanks again!

[Bug c/40528] Add a new ifunc attribute

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #17 from Yuri Gribov  ---
(In reply to Agner Fog from comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > (In reply to comment #13)
> > > > What is the status of this issue?
> > > 
> > > It is implemented on ifunc branch.
> > > 
> > > > Is option 3 implemented?
> > > 
> > > Yes, on ifunc branch.
> > > 
> > > > Which versions of Linux and binutils support IFUNC?
> > Still doesn't work. 
> > "warning: ‘ifunc’ attribute directive ignored"
> > GNU Binutils for Ubuntu 2.21.0.20110327
> 
> The ifunc attribute is described in
> http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html but it doesn't
> work (see my previous comment).

Works fine in Ubuntu 16.04 (GCC 5.4, BU 2.26, Glibc 2.23).  Could someone close
this?

[Bug c/69602] [6/7 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[eblake at redhat dot com]

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

--- Comment #15 from Eric Blake  ---
(In reply to Martin Sebor from comment #14)
> I would suggest to keep the warning simple and avoid overdesigning it with
> workarounds for this case.  The solution in comment #12 (copied below) seems
> like a good approach for avoiding the duplication and the warning.  It's
> already commonly used to deal with non-standard implementation-specific
> macros that portable programs cannot otherwise rely on.
> 
>   1149if (   cchRead < 0 
>   1150&& (   errno == EAGAIN 
>   1151#if EAGAIN != EWOULDBLOCK 
>   1152|| errno == EWOULDBLOCK 
>   1153#endif 
>   1154))

Yuck. Mid-expression #ifdefs are awful - I much prefer it when #ifdefs can be
limited to a per-statement or per-function scope.  You're seriously proposing
forcing software to uglify their code with mid-expression warnings to shut up
compiler warnings that only occur on platforms where the two values are
synonyms, and which can't even be portably seen as necessary when testing as
platforms where the two values are distinct?

[Bug c/69602] [6/7 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #14 from Martin Sebor  ---
I would suggest to keep the warning simple and avoid overdesigning it with
workarounds for this case.  The solution in comment #12 (copied below) seems
like a good approach for avoiding the duplication and the warning.  It's
already commonly used to deal with non-standard implementation-specific macros
that portable programs cannot otherwise rely on.

1149if (   cchRead < 0 
1150&& (   errno == EAGAIN 
1151#if EAGAIN != EWOULDBLOCK 
1152|| errno == EWOULDBLOCK 
1153#endif 
1154))

[Bug target/79202] On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
(In reply to Peter Bergner from comment #2)
> Can we instead do:
> 
> xscvdpsxws 32,1
> vupkhsw 1,0
> xvcvsxwdp 3,33

Replying to myself, the answer is no, the vupkhsw doesn't write its results in
the correct words for xvcvsxwdp.

[Bug target/79218] Missed swap optimization on powerpc64le simple test case

[bergner at gcc dot gnu.org]

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

--- Comment #1 from Peter Bergner  ---
Actually, gcc6 produces the same result (unnecessary swaps) if we use the
-mvsx-timode option, which is not on by default in gcc6.

[Bug c/79219] New: Feature request: double width/single width division and remainder

[hpa at zytor dot com]

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

Bug ID: 79219
   Summary: Feature request: double width/single width division
and remainder
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

A fair number of numerical algorithms could use a double width/single width
division (and remainder) operation.  This is not part of standard C, and
although gcc has __int128 on 64-bit platforms only, there is always the
fundamental problem that there is going to be a largest integer size.

Hopefully this could eventually be added to the C standard, but an
implementation would be a major step in that direction.  I believe we already
have algorithms that could use this feature in the Linux kernel.

[Bug target/79218] New: Missed swap optimization on powerpc64le simple test case

[bergner at gcc dot gnu.org]

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

Bug ID: 79218
   Summary: Missed swap optimization on powerpc64le simple test
case
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

The following test case has some unnecessary swaps:

bergner@genoa:~/gcc/BUGS$ cat ptr5.i 
void
ptr5 (__int128_t *dst, __int128_t *src)
{
  *dst = ~*src;
}
bergner@genoa:~/gcc/BUGS$ gcc7 -O2 -mcpu=power8 -S ptr5.i 
bergner@genoa:~/gcc/BUGS$ cat ptr5.s 
ptr5:
lxvd2x 0,0,4
xxpermdi 0,0,0,2
xxlnor 0,0,0
xxpermdi 0,0,0,2
stxvd2x 0,0,3
blr

This is still better than what GCC6 which produces:

bergner@genoa:~/gcc/BUGS$ gcc6 -O2 -mcpu=power8 -S ptr5.i 
bergner@genoa:~/gcc/BUGS$ cat ptr5.s 
ptr5:
ld 10,0(4)
ld 11,8(4)
not 10,10
not 11,11
std 10,0(3)
std 11,8(3)
blr

I'll note that GCC7 using -mcpu=power9 does not have any swaps due to the new
endian friendly dform load/stores:

bergner@genoa:~/gcc/BUGS$ gcc7 -O2 -mcpu=power9 -S ptr5.i 
bergner@genoa:~/gcc/BUGS$ cat ptr5.s 
ptr5:
lxv 0,0(4)
xxlnor 0,0,0
stxv 0,0(3)
blr

[Bug c/79217] New: Feature request: high half of a multiplication

[hpa at zytor dot com]

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

Bug ID: 79217
   Summary: Feature request: high half of a multiplication
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

There is no standard way in C to obtain the high half of a multiplication for
the largest integer data type supported.  gcc has __int128 on 64-bit platforms,
but not on 32-bit platforms; futhermore, it is sort of an infinite loop of
adding integer data types.

We could certainly use this in the Linux kernel, and hopefully should
eventually be included in the C standard.

[Bug c/79216] Feature request: byte order attributes

[hpa at zytor dot com]

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

--- Comment #1 from H. Peter Anvin  ---
The idea being that assignments to/from such a data item would make the
compiler generate the appropriate byte-swapping instructions appropriate for
the architecture.  If part of a packed structure, this would combine with the
appropriate instructions for unaligned references.

[Bug c/57612] add builtin to assert that expression does not have side effects

[hpa at zytor dot com]

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

H. Peter Anvin  changed:

   What|Removed |Added

 CC||hpa at zytor dot com

--- Comment #2 from H. Peter Anvin  ---
I would like to second this request, however, I would like to request that it
issues a warning rather than an error.  It can always be promoted to an error
via -Werror= or the equivalent pragma.

[Bug c/79216] New: Feature request: byte order attributes

[hpa at zytor dot com]

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

Bug ID: 79216
   Summary: Feature request: byte order attributes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

It is pretty crazy that the C language doesn't have any way to indicate the
layout of external data, even though it is incredibly frequently used that way.
 It ought to be a major improvement to the C language if a particular data item
could be declared with a specific byte order, either as part of a structure or
for a single data item.

Perhaps something like:

__attribute__((byteorder(little|big)))

Eventually I believe this needs to go into the C standard, but getting an
implementation in gcc would be a major step toward this.

[Bug c/79215] -Wpedantic doesn't warn if UINT64_MAX is used as enum constant

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
Confirmed as a duplicate of bug 71613 (and a number of other bugs caused by
-Wno-system-headers).

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

[Bug c/71613] Useful warnings silenced when macros from system headers are used

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||wellnhofer at aevum dot de

--- Comment #7 from Martin Sebor  ---
*** Bug 79215 has been marked as a duplicate of this bug. ***

[Bug preprocessor/79214] -Wno-system-header defeats strncat buffer overflow warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78989,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71613,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=43167

--- Comment #2 from Martin Sebor  ---
A few other problem reports caused by -Wno-system-header: bug 78989, bug 71613,
and bug 43167.

[Bug c/448] -related issues (C99 issues)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #30 from Martin Sebor  ---
Is anything still outstanding here or can the bug be resolved as fixed?

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-24
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.3.0, 7.0

--- Comment #15 from Martin Sebor  ---
I can confirm that the warnings are still suppressed in GCC 7.0:

Without -Wsystem-headers:

$ /build/gcc-git/gcc/xg++ -B /build/gcc-git/gcc -nostdinc++ -I
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include -I
/src/gcc/git/libstdc++-v3/libsupc++ -I
/src/gcc/git/libstdc++-v3/include/backward -I
/src/gcc/git/libstdc++-v3/testsuite/util -L
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -S -Wall -Wextra
-Wpedantic -Wconversion t.C
$

With -Wsystem-headers:

$ /build/gcc-git/gcc/xg++ -B /build/gcc-git/gcc -nostdinc++ -I
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include -I
/src/gcc/git/libstdc++-v3/libsupc++ -I
/src/gcc/git/libstdc++-v3/include/backward -I
/src/gcc/git/libstdc++-v3/testsuite/util -L
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -S -Wall -Wextra
-Wpedantic -Wconversion -Wsystem-headers t.C
In file included from /usr/include/inttypes.h:27:0,
 from t.C:4:
/build/gcc-git/gcc/include/stdint.h:9:3: warning: #include_next is a GCC
extension
 # include_next 
   ^~~~
In file included from
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:60:0,
 from t.C:2:
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h: In
function ‘constexpr int std::__lg(int)’:
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:1001:44:
warning: conversion to ‘int’ from ‘long unsigned int’ may alter its value
-Wconversion]
   { return sizeof(int) * __CHAR_BIT__  - 1 - __builtin_clz(__n); }
^
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h: In
function ‘constexpr unsigned int std::__lg(unsigned int)’:
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:1005:44:
warning: conversion to ‘unsigned int’ from ‘long unsigned int’ may alter its
value [-Wconversion]
   { return sizeof(int) * __CHAR_BIT__  - 1 - __builtin_clz(__n); }
^
In file included from
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/numeric:62:0,
 from t.C:3:
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_numeric.h: In
instantiation of ‘_Tp std::accumulate(_InputIterator, _InputIterator, _Tp)
[with _InputIterator = __gnu_cxx::__normal_iterator >; _Tp = int]’:
t.C:7:57:   required from here
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_numeric.h:127:18:
warning: conversion to ‘int’ from ‘long int’ may alter its value [-Wconversion]
  __init = __init + *__first;
  ^

[Bug c/79215] New: -Wpedantic doesn't warn if UINT64_MAX is used as enum constant

[wellnhofer at aevum dot de]

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

Bug ID: 79215
   Summary: -Wpedantic doesn't warn if UINT64_MAX is used as enum
constant
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wellnhofer at aevum dot de
  Target Milestone: ---

When compliling the program

#include 

enum e {
v = UINT64_MAX
};

with -Wpedantic, no warning is emitted. When I change UINT64_MAX to
18446744073709551615ULL, I get

warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]

as expected. It looks like the reason is the preprocessor output

enum e {
v =
# 4 "test.c" 3 4
   (18446744073709551615ULL)

# 5 "test.c"

According to the documentation, the '3' flag "indicates that the following text
comes from a system header file, so certain warnings should be suppressed."

[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-24
 CC||acsawdey at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Probably same problem for:

#include 

static unsigned char a[8] = {26, 54, 241, 144, 14, 86, 52, 58};
static unsigned char b[8] = {242, 38, 231, 126, 43, 254, 247, 41};

int main()
{
  if (__builtin_memcmp (a, b, 8) >= 0)
__builtin_abort ();
}

Started with r240455.

[Bug c++/79205] ICE in create_tmp_var, at gimple-expr.c:473

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 40570 [details]
> gcc7-pr79205.patch
> 
> Untested fix.

Looks good.

[Bug target/79185] [5/6/7 Regression] register allocation in the addition of two 128 bit ints

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
I suspect this is ultimately a DUP of an existing P2 issue.  Obviously we'd
have to get inside the dumps to be sure.

[Bug c++/78469] [7 Regression] defaulted default constructor causes bogus requirement for accessible destructor

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r244882.

[Bug c++/79118] [7 Regression] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #11 from Nathan Sidwell  ---
Fixed r244881.

[Bug c++/78469] [7 Regression] defaulted default constructor causes bogus requirement for accessible destructor

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan 24 19:29:44 2017
New Revision: 244882

URL: https://gcc.gnu.org/viewcvs?rev=244882=gcc=rev
Log:
PR c++/78469 - defaulted ctor and inaccessible dtor
* cp-tree.h (tsubst_flags): Add tf_no_cleanup.
* init.c (build_new_1): Pass tf_no_cleanup to build_value_init.
* tree.c (build_target_expr): Check tf_no_cleanup.

PR c++/78469
* g++.dg/cpp0x/pr78469.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr78469.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79118] [7 Regression] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan 24 19:25:32 2017
New Revision: 244881

URL: https://gcc.gnu.org/viewcvs?rev=244881=gcc=rev
Log:
PR c++/79118 - anon-members and constexpr
* constexpr.c (cx_check_missing_mem_inits): Caller passes type not
ctor decl.  Recursively check anonymous members.
(register_constexpr_fundef): Adjust cx_check_missing_mem_inits
call.
(explain_invalid_constexpr_fn): Likewise.


PR c++/79118
* g++.dg/cpp0x/pr79118.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr79118.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2017-01-24 1:34 PM, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190
>
> --- Comment #8 from Jonathan Wakely  ---
> Would you be able to test the patch at
> https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01910.html on HPUX 11?
Yes.  I'm doing a quick check on HPUX 11.00 as a full build and check 
takes a long time.
Started a hppa64 build on 11.11 with patch as well.

Dave

[Bug preprocessor/79214] -Wno-system-header defeats strncat buffer overflow warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=16358,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78000

--- Comment #1 from Martin Sebor  ---
See also bug 16358 and bug 78000 for a discussion of the underlying problem.

[Bug preprocessor/79214] New: -Wno-system-header defeats strncat buffer overflow warnings

[msebor at gcc dot gnu.org]

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

Bug ID: 79214
   Summary: -Wno-system-header defeats strncat buffer overflow
warnings
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the following program the -Wstringop-overflow= function detects the
incorrectly bounded call to __builtin_strncat in function f() but fails to
detect the same problem in the call to strncat in function g().  On this system
(Fedora 21) strncat is a macro defined in  to __builtin_strncat so
the code in both f() and g() is identical.  The problem is that because the
strncat macro is defined in a system header and the -Wno-system-headers option
is enabled by default the warning in the second instance is suppressed.

$ cat t.c && gcc -O2 -S -Wall -Wextra t.c
#include 

void foo (void*);

void f (const char *fname)
{
  char d[8];
  __builtin_strncpy (d, "/tmp/", sizeof d);
  __builtin_strncat (d, fname, sizeof d);

  foo (d);
}

void g (const char *fname)
{
  char d[8];
  strncpy (d, "/var/", sizeof d);
  strncat (d, fname, sizeof d);

  foo (d);
}

t.c: In function ‘f’:
t.c:9:3: warning: specified bound 8 equals the size of the destination
[-Wstringop-overflow=]
   __builtin_strncat (d, fname, sizeof d);
   ^~

[Bug target/68664] PowerPC: speculative sqrt in c-ray main loop causes large slow down

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||tulipawn at gmail dot com

--- Comment #4 from James Greenhalgh  ---
*** Bug 77468 has been marked as a duplicate of this bug. ***

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #20 from James Greenhalgh  ---
I just spotted the profile data in Comment 1. The analysis I posted above holds
for render_scanline and trace too.

This is pr68664.

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

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #19 from James Greenhalgh  ---
(In reply to Aldy Hernandez from comment #18)
> (In reply to Aldy Hernandez from comment #17)
> > Created attachment 40573 [details]
> > preprocessed testcase
> 
> Here's the preprocessed testcase generated on:
> 
> openSUSE Leap 42.1 (aarch64)

It would be interesting to see the x86_64 analysis, but if shade is the hot
function in your reduced testcase (I still can't run the binary, so would
appreciate your help with analysis here), then I think the problem is sched1
moving a sqrt out from inside an if in a loop. i.e. something like:

  while (foo)
if (bar) {
  j = sqrt(x)
  [...]
}

Becomes:

  while (foo)
  {
j = sqrt(x)
if (bar) {
  [...]
}
  }

GCC might do that if it thinks the if statement is mostly taken. The basic
block frequencies suggest that entry in to the if is 80.9%.

Making that transformation is not helpful as a sqrt is one of the more
expensive operations, and certainly too expensive to pull from conditionally
executed to always executed on a core like Cortex-A53.

[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Would you be able to test the patch at
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01910.html on HPUX 11?

[Bug target/79202] On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
(In reply to Michael Meissner from comment #0)
> It may be more optimal to generate something like:
> 
> xscvdpsxws 32,1
> vupkhsw 1,0
> xxpermdi 2,33,33,3
> fcfid 3,2

Can we instead do:

xscvdpsxws 32,1
vupkhsw 1,0
xvcvsxwdp 3,33

[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Dimitry Andric from comment #4)
> As I discussed with libc++ maintainer Eric Fiselier, it would be nice if
> those functions called terminate() in the 'fatal' case instead.  Then you at
> least have some standardized way of overriding the termination with your own
> mechanism, which appears to be what the Mozilla authors wanted to achieve.

I thought the point of the mozilla hacks is to ensure that the functions
terminate the program instead of throwing an exception (which is the default).
Simply changing __builtin_abort to std::terminate won't help: the default will
still be to throw an exception.

Whether they should terminate or abort is an entirely separate question, and
unrelated to the mozilla hacks AFAICS.

[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)

[cmacmackin at gmail dot com]

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

--- Comment #5 from Chris  ---
Has there been any progress on this bug? It is making a large piece of
scientific software I have written unusable for decent resolution simulations.
I'm running gfortran 6.1.0, compiled with OpenCoarrays support.

Also, I've reduced the size of the reproducer:


Module Groups

  Type, abstract :: Group
   CONTAINS
 Generic, Public :: Operator   (*) => prod
 Generic, Public :: Assignment (=) => equal

 Procedure (gpr), deferred :: prod
 Procedure (geq), deferred :: equal
  End type Group

  Type, extends (Group), abstract :: GaugeGroup
  End type GaugeGroup

  Abstract Interface
 Function gpr(a, b)
   Import :: Group

   Class (Group), Intent (in) :: a, b
   Class (Group), Allocatable :: gpr
 End Function gpr
  End Interface

  Abstract Interface
 Subroutine geq(a, b)
   Import :: Group

   Class (Group), Intent (in)  :: b
   Class (Group), Intent (out) :: a
 End Subroutine geq
  End Interface

End Module Groups


MODULE Group_SU2

  USE Groups

  IMPLICIT NONE

  ! Represent SU(2) element through quaternions
  ! (a_0, a_1, a_2, a_3)
  Type, Extends (GaugeGroup) :: SU2
 Real (kind=8) :: Comp(0:3)
   CONTAINS
 Procedure :: prod=> prodsu2
 Procedure :: equal   => equalSU2
  End Type SU2

CONTAINS

! ***
! *
  Subroutine EqualSU2(a, b)
! *
! ***
! * Equals g1 to g2
! ***

Class (SU2), Intent (out) :: a
Class (Group), Intent (in) :: b

select type (b)
class is (SU2)
   a%Comp(0:3) = b%Comp(0:3)
class default
   error stop
End select

Return
  End Subroutine EqualSU2

! ***
! *
  Function Prodsu2(a,b) Result(g3)
! *
! ***
! * Multiplies g1 by g2
! ***

Class (SU2),   Intent (in) :: a
Class (Group), Intent (in) :: b
Class (Group), allocatable :: g3

Allocate(SU2::g3)
select type (b)
class is (SU2)
   select type (g3)
   class is (SU2)
  g3%Comp(0) = a%Comp(0)*b%Comp(0) - &
   &   Dot_Product(a%Comp(1:3),b%Comp(1:3))

  g3%Comp(1) = a%Comp(0)*b%Comp(1) + a%Comp(1)*b%Comp(0) &
   & + a%Comp(2)*b%Comp(3) - a%Comp(3)*b%Comp(2)

  g3%Comp(2) = a%Comp(0)*b%Comp(2) - a%Comp(1)*b%Comp(3) &
   & + a%Comp(2)*b%Comp(0) + a%Comp(3)*b%Comp(1)

  g3%Comp(3) = a%Comp(0)*b%Comp(3) + a%Comp(1)*b%Comp(2) &
   & - a%Comp(2)*b%Comp(1) + a%Comp(3)*b%Comp(0)
   end select
class default
   error stop
end select

Return
  End Function Prodsu2

End MODULE GROUP_SU2


Program Testoo

  USE Groups
  USE Group_SU2

  type(SU2) :: g1, g2, g3

  ForAll (I=0:3) g1%comp(I) = 0.23_8*(I+1)
  ForAll (I=0:3) g2%comp(I) = 0.32_8*(I+1)

  Do I = 1, 2000
 g3=g1*g2
  End Do

  Stop
End Program Testoo

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Interesting to see stack issues after IPA-CP changes.

Please try compiling with -fno-devirtualize

If it does not help, try -fno-ipa-cp (or both).

If any of the above does help, adding it to just the file in which the
miscompiled function is should help, so please verify that.

If devirtualization causes the weird behavior, trying what
-fsanitize-undefined-trap-on-error does might also shed some light on
it.

After we have identified the miscompiled source file and confirmed
that an IPA option causes it, we may try to minimize the testcase or
inspect dumps (-fump-tree-release_ssa -fdump-ipa-all-details
-fdump-tree-fixup_cfg4) for suspect behavior.

Also, we will need to confirm this is indeed a compiler bug and not
source code with undefined behavior.

[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced

[dimitry at andric dot com]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||dimitry at andric dot com

--- Comment #4 from Dimitry Andric  ---
(In reply to Jonathan Wakely from comment #3)
> Following discussion with one of the libc++ developers, we're considering
> some common API that would allow an aplication to globally turn those throws
> into aborts, so that redefining them would be unnecessary.

As I discussed with libc++ maintainer Eric Fiselier, it would be nice if those
functions called terminate() in the 'fatal' case instead.  Then you at least
have some standardized way of overriding the termination with your own
mechanism, which appears to be what the Mozilla authors wanted to achieve.

(Note that even gcc redefines abort() so it can catch it in its own way... :)

[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)

[cmacmackin at gmail dot com]

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

Chris  changed:

   What|Removed |Added

 CC||cmacmackin at gmail dot com

--- Comment #4 from Chris  ---
Has there been any progress on this bug? It is making a large piece of
scientific software I have written unusable for decent resolution simulations.

[Bug target/77439] [6/7 regression] wrong code for sibcall with longcall, APCS frame and VFP

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
.

[Bug target/77439] [6/7 regression] wrong code for sibcall with longcall, APCS frame and VFP

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Jan 24 17:18:02 2017
New Revision: 244880

URL: https://gcc.gnu.org/viewcvs?rev=244880=gcc=rev
Log:
PR target/77439
* config/arm/arm.c (arm_function_ok_for_sibcall): Add back restriction
for long calls with APCS frame and VFP.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/vfp-longcall-apcs.c
  - copied unchanged from r244879,
trunk/gcc/testsuite/gcc.target/arm/vfp-longcall-apcs.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/arm.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug target/46676] ix86_option_override_internal i18n problems

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
Full sentences appear now to be used - but all the diagnostic function 
calls now use main_args_p ? "diag 1" : "diag 2" as the msgid argument, 
which results in only diag 1 and not diag 2 being picked up for 
translation.  When conditional expressions are used like that in 
diagnostic function calls, both halves should be marked up with G_() so 
both get extracted into gcc.pot.  So there's still a problem here.

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[amker at gcc dot gnu.org]

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

--- Comment #12 from amker at gcc dot gnu.org ---
(In reply to amker from comment #10)
> (In reply to amker from comment #9)
> > Root cause should be in VRP, looks like the iterative algorithm depends on
> > order of ssa operands and computes different range.
> 
> Testing a patch, though is kind of a workaround.

Turns out a real fix in VRP is possible, and straightforward.  Testing.(In
reply to Richard Biener from comment #11)
> Yes, VRP doesn't thread a jump because of improved iteration order (and
> improved ranges).  And due to the fact that we can't register multiple
> ranges from a single assert expression (both the trivial symbolic one and
> one using ranges from the operands).

Turns out a real fix in VRP is possible, and straightforward.  It's not a case
we have to make decision between useful numeric and symbolic range, it's a case
we wrongly discard symbolic range info and drop to VARYING.  Testing new fix.

Thanks.

[Bug target/77439] [6/7 regression] wrong code for sibcall with longcall, APCS frame and VFP

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Jan 24 17:15:02 2017
New Revision: 244879

URL: https://gcc.gnu.org/viewcvs?rev=244879=gcc=rev
Log:
PR target/77439
* config/arm/arm.c (arm_function_ok_for_sibcall): Add back restriction
for long calls with APCS frame and VFP.

Added:
trunk/gcc/testsuite/gcc.target/arm/vfp-longcall-apcs.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/79207] Special trigonometric simplification for solving cubics with -ffast-math

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
It's hardly specific to those arguments.  Any case of two or more calls of 
(sin or cos) (+/- x + constant) for same x, possibly different constant, 
could be converted (given -funsafe-math-optimizations) to sincos plus 
multiplications by constants (i.e. by +/- sin and cos of the constant part 
of the argument in the original call) and additions.  (You also need 
-funsafe-math-optimizations to convert the example 
cos((alpha+2*M_PI)*ONETHIRD) into cos(alpha*ONETHIRD+2*M_PI*ONETHIRD) to 
get all three expressions using the same x.)

(This is not an assertion of whether or not such a transformation is a 
good idea, simply that the transformation is generic for arbitrary 
constants.  It may be that recognizing particular constants helps you get 
a form like

>   ret[1] = -0.5 * (t_ss3 + t_cos);
>   ret[2] = 0.5 * (t_ss3 - t_cos);

rather than something more complicated where there are four slightly 
different constants multiplied by the outputs of sincos.)

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[aldyh at gcc dot gnu.org]

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

--- Comment #18 from Aldy Hernandez  ---
(In reply to Aldy Hernandez from comment #17)
> Created attachment 40573 [details]
> preprocessed testcase

Here's the preprocessed testcase generated on:

openSUSE Leap 42.1 (aarch64)

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[aldyh at gcc dot gnu.org]

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

--- Comment #17 from Aldy Hernandez  ---
Created attachment 40573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40573=edit
preprocessed testcase

[Bug tree-optimization/79213] FAIL: gcc.target/aarch64/ldp_vec_64_1.c scan-assembler ldp\td[0-9]+, d[0-9]

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-24
 Ever confirmed|0   |1

[Bug tree-optimization/79213] New: FAIL: gcc.target/aarch64/ldp_vec_64_1.c scan-assembler ldp\td[0-9]+, d[0-9]

[amker at gcc dot gnu.org]

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

Bug ID: 79213
   Summary: FAIL: gcc.target/aarch64/ldp_vec_64_1.c scan-assembler
ldp\td[0-9]+, d[0-9]
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

This AArch64 test fails because IVOPT starts not choosing [base+offset]
addressing mode.  Given auto-increment macros are disabled for IVOPT on AArch64
at the moment, it makes more sense to xfail the test now.

File this bug tracking the lack of auto-increment addressing mode support in
IVOPT, which may be visited in the next stage1.  The reason why we disable it
now is it's too aggressive for AArch64.  We may only want to fine tune it for
small loops.

[Bug sanitizer/79168] [7 Regression] libtsan fails to link when cross compiling GCC tip for Aarch64 target

[brzycki at gmail dot com]

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

--- Comment #5 from Brian Rzycki  ---
Hi Jakub, I just manually ran our nightly snapshot script and successfully
built a GCC AArch64 compiler. The SHA used was d889d15 which contains your fix
in its history.

I have verified this as fixed.  Thank you for the fast turnaround!

[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Following discussion with one of the libc++ developers, we're considering some
common API that would allow an aplication to globally turn those throws into
aborts, so that redefining them would be unnecessary.

One possibility is to link to some new lib (say, libnothrow.so) which would run
a static initializer or provide a definition for a weak symbol, causing the
__throw_xxx functions to unconditionally abort. That would not require a
special libstdc++ built without exceptions, and would mean that the choice is
fixed by the app at link-time (not dependent on which libstdc++.so happens to
be chosen by the dynamic linker, one that throws or one that aborts).

[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-24
 CC||froydnj at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Nathan Froyd  ---
Firefox's custom implementation of the __throw_* functions also wound up biting
us when libc++ started defining functions with identical names:

https://bugzilla.mozilla.org/show_bug.cgi?id=1329520

[Bug libstdc++/62187] std::string==const char* could compare sizes first

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
Ignoring strange specializations of char_traits, we could also consider a
specialized version of memcmp/strncmp that checks for a terminating 0 in only
one of the 2 strings. This would avoid the call to strlen when the 2 strings
are long but differ early, but on average it would probably turn out slower
than the well optimized strlen+memcmp from libc.

[Bug middle-end/79212] New: internal compiler error: in maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134

[davids at gcc dot gnu.org]

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

Bug ID: 79212
   Summary: internal compiler error: in
maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davids at gcc dot gnu.org
  Target Milestone: ---

When compiling the espresso-5.4.0 fortran package with FFLAGS-fopenmp I get the
following assertion:

internal compiler error: in maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134
0xa941e6 maybe_lookup_decl_in_outer_ctx
/work/davshe01/oban-work-shoji/src/gcc/gcc/omp-low.c:4134
0xa9cadc scan_sharing_clauses
/work/davshe01/oban-work-shoji/src/gcc/gcc/omp-low.c:1975
...

[Bug target/79202] On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
This could be a register preference thing in IRA, similar to what I'm looking
at. In this case, we probably choose a int reg which forces the move to/from
the int reg file rather than keeping things in Altivec regs.

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Fixed by Bin's change on the trunk.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #58 from Iain Sandoe  ---
(In reply to Francois-Xavier Coudert from comment #57)
> (In reply to Iain Sandoe from comment #55)
> > nope, it needs back-porting to 6.x and 5.x - will do that after it's been on
> > trunk a while.
> 
> Is backport to 5.x still planned?

Yes, when time permits.

[Bug libstdc++/62187] std::string==const char* could compare sizes first

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
I've also created an LWG issue about this, so I hope before Stage 1 starts
we'll have LWG guidance saying it's OK to do this for all basic_string, not
only std::string and std::wstring.

We should also make __is_char and __is_char true.

[Bug libstdc++/62187] std::string==const char* could compare sizes first

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Oops, no, not that overload. The other one ;)

[Bug libstdc++/62187] std::string==const char* could compare sizes first

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Ah yes, of course. So we can move that traits::length into the operator== and
then call the compare(size_type, size_type, const CharT*) overload instead.

I'll take care of this in Stage 1.

[Bug rtl-optimization/56069] [5/6/7 Regression] RA pessimization

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
OK.  Changing milestone to gcc-8.  I think we can reasonably allow guality to
regress here.  Waiting until gcc-8 also gives the updated gdb more time to get
deployed in the wild.

[Bug libstdc++/62187] std::string==const char* could compare sizes first

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-24
 Ever confirmed|0   |1

[Bug libstdc++/62187] std::string==const char* could compare sizes first

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
I was also confused when re-reading this PR, but if you check the current code,
we already start by computing the length of the char*... (I think the main
issue is when the string starts the same as the char*, terminating 0 included,
and then continues)

[Bug target/69264] [5/6/7 regression] ICE building spidermonkey -mcpu=970 -maltivec -O3: rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:4350

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This is a consequence of the r198767 change IMHO, which changed:
@@ -4736,9 +4730,10 @@
   if (!known_alignment_for_access_p (dr))
is_packed = not_size_aligned (DR_REF (dr));

- if (targetm.vectorize.
- support_vector_misalignment (mode, type,
- DR_MISALIGNMENT (dr), is_packed))
+ if ((TYPE_USER_ALIGN (type) && !is_packed)
+|| targetm.vectorize.
+ support_vector_misalignment (mode, type,
+  DR_MISALIGNMENT (dr), is_packed))
return dr_unaligned_supported;
 }

i.e. the support_vector_misalignment target hook is not even considered when
TYPE_USER_ALIGN (type), which is this case.  Richard, that was your change, can
you please have a look?  Either the backends need to accept that even when they
return false in support_vector_misalignment, it might be asked for costs of
some misaligned load (and thus should not assert it will not happen, but
instead say return very high cost), or the r198767 change was wrong, or we need
to ask if support_vector_misalignment decision is an optimization decision or
ISA decision, if it is just optimization decision, TYPE_USER_ALIGN could
override it, while if it is ISA decision, it should not.

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[aldyh at gcc dot gnu.org]

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

--- Comment #16 from Aldy Hernandez  ---
> 
> Could you dump me the assembly of the hot loop before and after that change
> - I'll see if we're doing anything particularly offensive with the
> scheduling, though I still don't have access to the source code for this
> benchmark so a reduced testcase would be appreciated.

James, comment 9 has instructions on what I did to get the source.  It's a
simple  file with no dependencies but system header files.

Is this sufficient, or do _really_ want me to preprocess and reduce the
testcase ;-)??

[Bug libstdc++/62187] std::string==const char* could compare sizes first

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
If I understand correctly, that would require doing two passes over the const
char* argument, one to find its length and another (when the lengths are equal)
to compare each character. That would be beneficial sometimes, and not other
times.

[Bug tree-optimization/56049] [7 Regression] Simplification to constants not done

[law at redhat dot com]

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

--- Comment #21 from Jeffrey A. Law  ---
c#19 (WRT guality regressing) was for a different BZ.  Sorry.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[fxcoudert at gcc dot gnu.org]

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

--- Comment #57 from Francois-Xavier Coudert  ---
(In reply to Iain Sandoe from comment #55)
> nope, it needs back-porting to 6.x and 5.x - will do that after it's been on
> trunk a while.

Is backport to 5.x still planned?

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #15 from James Greenhalgh  ---
(In reply to Aldy Hernandez from comment #13)
> The aarch64-linux-gnu regression originally reported for -mcpu=cortex-a53
> was caused by:
> 
> commit 08993ad1c669cab64baf352f79cd7f8584dd8e0c
> Author: jgreenhalgh 
> Date:   Thu Oct 1 09:33:40 2015 +
> 
> [Patch 2/2 ARM/AArch64] Add a new Cortex-A53 scheduling model
> 
> * config/arm/aarch-common-protos.h
> (aarch_accumulator_forwarding): New.
> (aarch_forward_to_shift_is_not_shifted_reg): Likewise.
> * config/arm/aarch-common.c (aarch_accumulator_forwarding): New.
> (aarch_forward_to_shift_is_not_shifted_reg): Liekwise.
> * config/arm/cortex-a53.md: Rewrite.
> 
> 
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@228324
> 138bc75d-0d04-0410-961f-82ee72b054a4

Could you dump me the assembly of the hot loop before and after that change -
I'll see if we're doing anything particularly offensive with the scheduling,
though I still don't have access to the source code for this benchmark so a
reduced testcase would be appreciated.

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[aldyh at gcc dot gnu.org]

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

--- Comment #14 from Aldy Hernandez  ---
Since the culprit for the reported regression is aarch64 specific, I think we
should open an independent x86-64 PR (or an architecture independent PR if the
other reported problem by Richi is reproducible on multiple architectures).

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[aldyh at gcc dot gnu.org]

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

--- Comment #13 from Aldy Hernandez  ---
The aarch64-linux-gnu regression originally reported for -mcpu=cortex-a53 was
caused by:

commit 08993ad1c669cab64baf352f79cd7f8584dd8e0c
Author: jgreenhalgh 
Date:   Thu Oct 1 09:33:40 2015 +

[Patch 2/2 ARM/AArch64] Add a new Cortex-A53 scheduling model

* config/arm/aarch-common-protos.h
(aarch_accumulator_forwarding): New.
(aarch_forward_to_shift_is_not_shifted_reg): Likewise.
* config/arm/aarch-common.c (aarch_accumulator_forwarding): New.
(aarch_forward_to_shift_is_not_shifted_reg): Liekwise.
* config/arm/cortex-a53.md: Rewrite.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@228324
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[vhaisman at gmail dot com]

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

--- Comment #17 from Václav Haisman  ---
This is still an issue in 2017 with GCC 5.4.0.

[Bug debug/78363] [7 Regression] ICE in in force_type_die, at dwarf2out.c:24864

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
For the expand_omp_target hunk, a testcase would be e.g.

int
main ()
{
  int n = 0;
#pragma omp target map(tofrom:n)
#pragma omp for reduction (+: n)
  for (int i = [](){ return 3; }(); i < 10; ++i)
n++;
  if (n != 7)
__builtin_abort ();
}

For tasking as opposed to parallel, testcase that ICEs is e.g.:

int
main ()
{
  int n = 0;
#pragma omp task shared (n)
  for (int i = [](){ return 3; }(); i < 10; ++i)
n = i;
#pragma omp taskwait
  if (n != 7)
__builtin_abort ();
}

For grid, you want Martin to write a testcase ;).
Regarding finalize_task_copyfn, this is for an artificial function created for
constructors of firstprivate vars in task, like:
struct S { S (); ~S (); S (const S &); };
void foo (S &);

void
bar ()
{
  S s;
#pragma omp task firstprivate (s)
  foo (s);
}
The *cpyfn* for this looks like:
  try
{
  {
.omp_data_o.3_1 = .omp_data_o;
_2 = &.omp_data_o.3_1->s;
_3 = .omp_data_i->s;
S::S (_2, _3);
return;
  }
}
  catch
{
  <<>>
}
and is not actually outlined from the original function, but rather constructed
from scratch.  Couldn't get ICE on it, so let's ignore that for now.

[Bug target/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|--- |5.5