[Bug rtl-optimization/87096] "Optimised" snprintf is not POSIX conformant

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I don't think we "preserve" exceptional behavior consistently.  That is, we
happily change code with exceptional behavior to code without if the main
computation result is the same.

[Bug ipa/87094] Suboptimal accounting for stack growth in inlining

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-27
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The heuristic isn't flow-sensitive.

[Bug testsuite/78529] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[rguenther at suse dot de]

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

--- Comment #37 from rguenther at suse dot de  ---
On Fri, 24 Aug 2018, joey.ye at arm dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529
> 
> Joey Ye  changed:
> 
>What|Removed |Added
> 
>  CC||joey.ye at arm dot com
> 
> --- Comment #36 from Joey Ye  ---
> Simply applying __attribute__((noipa)) to memset (and all other C lib
> implementations) in chk.c prevents IPA analysis in the local implementation of
> memset, thus avoids the issue when it is later replaced by a library copy.
> 
> The workaround does pass this case in my experiment, which can be turn into a
> patch after additional work and testing. Is it an acceptable workaround to
> upstream?

I guess so.  As said in comment#33 building the -lib.c part w/o -flto
(and optimization) and build it only once would be preferable.

[Bug rtl-optimization/87096] "Optimised" snprintf is not POSIX conformant

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #2 from Andrew Pinski  ---
*** Bug 87111 has been marked as a duplicate of this bug. ***

[Bug c/87111] erroneous builtin snprintf transformations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug c/87111] New: erroneous builtin snprintf transformations

[bugdal at aerifal dot cx]

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

Bug ID: 87111
   Summary: erroneous builtin snprintf transformations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Even at -O0, gcc transforms the call snprintf(buf, (size_t)INT_MAX+1, "") to
the value 0, with a side effect storing a zero byte at *buf, despite the
(disputed) POSIX requirement that snprintf fail when the n exceeds INT_MAX.

This transformation is reported to cause failure of the official POSIX
conformance tests, even when the library implementation for snprintf is
conforming to the requirement.

[Bug c/80528] reimplement gnulib's "useless-if-before-free" script as a compiler warning

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||list+gcc-bugzilla@meyering.
   ||net

--- Comment #3 from Eric Gallager  ---
cc-ing Jim Meyering, the author of the original gnulib script, to see if he has
any input

[Bug c++/44520] improve diagnostic for ambiguous lookup

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug target/87085] with -march=i386, gcc should not generate code including endbr instruction

[chengming at bjuci dot com.cn]

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

--- Comment #6 from chengming at bjuci dot com.cn ---
Created attachment 44604
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44604&action=edit
preprocessed file

[Bug target/87085] with -march=i386, gcc should not generate code including endbr instruction

[chengming at bjuci dot com.cn]

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

--- Comment #5 from chengming at bjuci dot com.cn ---
Created attachment 44603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44603&action=edit
output of gcc

[Bug target/87085] with -march=i386, gcc should not generate code including endbr instruction

[chengming at bjuci dot com.cn]

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

--- Comment #4 from chengming at bjuci dot com.cn ---
Created attachment 44602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44602&action=edit
ELF file

compiled with command
gcc -v -save-temps -m32 -march=i386 -fcf-protection=none -o onlyReturn
onlyReturn.c > output.txt 2>&1

[Bug target/87085] with -march=i386, gcc should not generate code including endbr instruction

[chengming at bjuci dot com.cn]

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

--- Comment #3 from chengming at bjuci dot com.cn ---
Created attachment 44601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44601&action=edit
C source code

[Bug target/52090] FAIL: c-c++-common/simulate-thread/bitfields-4.c -O2 -g thread simulation test

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
I believe this is probably a gdb bug.  Calling the verify routine after each
step can corrupt the register state.

I don't see a way to save and restore all general registers in verify routine.

[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined

[jvg1981 at aim dot com]

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

--- Comment #20 from Joshua Green  ---
> "But if we don't know which pointer is greater, it gets more complicated:
> ..."
> 
> I'm not sure that this is true.  For types that are larger than 1 byte, it
> seems that one can do the subtraction after any division(s), hence only
> costing an additional division (or shift):
> 
> T * p;
> T * q;
> 
> .
> .
> .
> 
> intptr_t pVal = ((uintptr_t) p)/(sizeof *p);
> intptr_t qVal = ((uintptr_t) q)/(sizeof *q);
> 
> ptrdiff_t p_q = pVal - qVal;
> 
> This should work in well-defined cases, for if p and q are pointers into the
> same array then (presumably) ((uintptr_t) p) and ((uintptr_t) q) must have
> the same remainder modulo sizeof(T).
> 
> Of course, even an additional shift may be too expensive in some cases, so
> it's not entirely clear that this change should be made.

It occurred to me that such contortions can be avoided in the (possibly) common
case when (say) q is actually an array.

[Bug preprocessor/87088] Attached program doesn't finish compiling and linking

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
You're still doing it wrong.

As I already said, to include a file you should be using -include not
-Xpreprocessor.

Stop using the -Xpreprocessor option to name a file for inclusion, that's not
what it does.

[Bug preprocessor/87088] Attached program doesn't finish compiling and linking

[miltonkbenjamin at verizon dot net]

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

miltonkbenjamin  changed:

   What|Removed |Added

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

--- Comment #8 from miltonkbenjamin  ---
C:\parser>g++ -Xpreprocessor "C:\MinGW\msys\1.0\include\FlexLexer.h"  lex.yy.cc 
lex.yy.cc:1:0: fatal error: inter-module optimizations not implemented for C++
 #line 2 "lex.yy.cc"

compilation terminated. 

[Bug preprocessor/87088] Attached program doesn't finish compiling and linking

[miltonkbenjamin at verizon dot net]

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

--- Comment #7 from miltonkbenjamin  ---
(In reply to miltonkbenjamin from comment #5)
> (In reply to Jonathan Wakely from comment #2)
> > (In reply to miltonkbenjamin from comment #0)
> > > Created attachment 44589 [details]
> > > Output from win_flex
> > > 
> > > C:\parser>g++ -Xpreprocessor "C:\MinGW\msys\1.0\include\FlexLexer.h" 
> > > lex.yy.cc 
> > 
> > -Xpreprocessor passes an option to the preprocessor, but you're giving it a
> > filename.
> > 
> > Are you trying to have that file included?
=
I did this and it failed the same way
Thanks,
Milt
> > 
> > That would be -include "C:\MinGW\msys\1.0\include\FlexLexer.h" 
> > 
=
> > Also, GCC 5.4.0 is not supported, the oldest supported release is 6.4.0
> 
> I am currently using version g++ 7.3.0 and it fails the same way.
> Thanks, Milt

[Bug target/86662] [7/8/9 Regression] msp430-elf segfault with -flto and -mlarge

[jozef.l at mittosystems dot com]

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

Jozef Lawrynowicz  changed:

   What|Removed |Added

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

--- Comment #6 from Jozef Lawrynowicz  ---
Fixed on all branches, marking resolved.

[Bug c/86647] Test on constant expression (unsigned) -1 < 0 triggers a spurious -Wtype-limits warning

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #2 from Bernd Edlinger  ---
possible workaround:

#define SIGNED(T) ((T) -1 < 1)

[Bug preprocessor/87088] Attached program doesn't finish compiling and linking

[miltonkbenjamin at verizon dot net]

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

--- Comment #6 from miltonkbenjamin  ---
(In reply to miltonkbenjamin from comment #5)
> (In reply to Jonathan Wakely from comment #2)
> > (In reply to miltonkbenjamin from comment #0)
> > > Created attachment 44589 [details]
> > > Output from win_flex
> > > 
> > > C:\parser>g++ -Xpreprocessor "C:\MinGW\msys\1.0\include\FlexLexer.h" 
> > > lex.yy.cc 
> > 
> > -Xpreprocessor passes an option to the preprocessor, but you're giving it a
I TRIED THIS AND IT FAILED THE SAME WAY AS BEFORE
Thanks, Mil

> > filename.
> > 
> > Are you trying to have that file included?
> > 
> > That would be -include "C:\MinGW\msys\1.0\include\FlexLexer.h" 
> > 
> > Also, GCC 5.4.0 is not supported, the oldest supported release is 6.4.0
> 
> I am currently using version g++ 7.3.0 and it fails the same way.
> Thanks, Milt

[Bug preprocessor/87088] Attached program doesn't finish compiling and linking

[miltonkbenjamin at verizon dot net]

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

--- Comment #5 from miltonkbenjamin  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to miltonkbenjamin from comment #0)
> > Created attachment 44589 [details]
> > Output from win_flex
> > 
> > C:\parser>g++ -Xpreprocessor "C:\MinGW\msys\1.0\include\FlexLexer.h" 
> > lex.yy.cc 
> 
> -Xpreprocessor passes an option to the preprocessor, but you're giving it a
> filename.
> 
> Are you trying to have that file included?
> 
> That would be -include "C:\MinGW\msys\1.0\include\FlexLexer.h" 
> 
> Also, GCC 5.4.0 is not supported, the oldest supported release is 6.4.0

I am currently using version g++ 7.3.0 and it fails the same way.
Thanks, Milt

[Bug fortran/29550] Optimize -fexternal-blas calls for conjg()

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Created attachment 44600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44600&action=edit
Patch which has a problem

The attached patch shows how something could be done, but it
has one problem: The handling of -fblas-matmul-limit .

If we change the arguments to the matmul call, it would be
_necessary_ to always call the external function, otherwise
there would be wrong code.

[Bug c/87110] New: tree check fail in to_wide, at tree.h:5523

[dcb314 at hotmail dot com]

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

Bug ID: 87110
   Summary: tree check fail in to_wide, at tree.h:5523
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Somewhere between revisions 263799 and 263849, this C code

enum a { b, c };
struct d {
  _Bool e;
  enum a f
};
g, h;
i() {
  struct d j[h];
  j[0] = (struct d){.f = c};
  for (; g;)
(struct d){};
}

goes wrong:

/home/dcb/gcc/results.263799.asan/bin/gcc
/home/dcb/gcc/results.263849/bin/gcc
during GIMPLE pass: dse
bug460.c: In function ‘i’:
bug460.c:12:1: internal compiler error: tree check: expected integer_cst, have
v
ar_decl in to_wide, at tree.h:5523
12 | }
   | ^
0x6b17b1 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk/gcc/tree.c:9370
0x6b3f9d tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3376
0x6b3f9d wi::to_wide(tree_node const*)
../../trunk/gcc/tree.h:5523
0x6b3f9d tree_int_cst_sgn(tree_node const*)
../../trunk/gcc/tree.c:6872

with compiler flag -O2.

[Bug fortran/86328] [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from janus at gcc dot gnu.org ---
I think PR 86760 may be a duplicate of this one, or at least related.

[Bug c++/87109] Wrong overload picked with ref-qualifiers

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
I guess this can serve as a run-time testcase:

#include 

struct C { int i; };
struct A {
  operator C() & { return { 1 }; }
  operator C() && { return { 2 }; }
};

C f(A a)
{
  return a;
}

C f2(A a)
{
  return std::move (a);
}

int
main ()
{
  C c1 = f (A());
  if (c1.i != 1)
__builtin_abort ();
  C c2 = f2 (A());
  if (c2.i != 2)
__builtin_abort ();
}

[Bug fortran/86760] [8/9 Regression] FORTRAN: polymorphic arrays inside a user-defined type generate segmentation faults

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
Further reduced test case:


MODULE test_nesting_mod
  IMPLICIT NONE
  TYPE :: test_obj1
  CONTAINS
PROCEDURE :: destroy
  END TYPE

  TYPE :: obj_ptr
CLASS(test_obj1), POINTER :: f => NULL()
  END TYPE

  TYPE :: obj_container
TYPE(obj_ptr), POINTER, DIMENSION(:) :: v => NULL()
  END TYPE

CONTAINS

  SUBROUTINE destroy(self)
CLASS(test_obj1), INTENT(INOUT) :: self
WRITE(*,*)'Obj1'
  END SUBROUTINE

  SUBROUTINE container_destroy(self)
type(obj_container), INTENT(INOUT) :: self
INTEGER :: i
DO i=1,ubound(self%v,1)
  CALL self%v(i)%f%destroy()
END DO
  END SUBROUTINE

END MODULE


PROGRAM test_nesting_ptr
  USE test_nesting_mod
  IMPLICIT NONE
  INTEGER :: i
  INTEGER, PARAMETER :: n = 2
  TYPE(obj_container) :: var

  ALLOCATE(var%v(n))
  DO i=1,n
ALLOCATE(test_obj1::var%v(i)%f)
  END DO
  CALL container_destroy(var)
END


This one does not always segfault, but when compiled with trunk and -O3,
valgrind reliably shows the error:


==24015== Invalid read of size 8
==24015==at 0x400989: __test_nesting_mod_MOD_container_destroy
(test.f90:27)
==24015==by 0x40075C: test_nesting_ptr (test.f90:45)
==24015==by 0x40075C: main (test.f90:35)


When compiled with gfortran 8 and -O3, valgrind only shows:

==24605== Use of uninitialised value of size 8
==24605==at 0x108B65: __test_nesting_mod_MOD_container_destroy
(test.f90:27)
==24605==by 0x108912: test_nesting_ptr (test.f90:45)
==24605==by 0x108912: main (test.f90:35)


When compiled with gfortran 7, valgrind shows no errors. Both errors above
reference the line where 'destroy' is called.

[Bug c++/87109] New: Wrong overload picked with ref-qualifiers

[mpolacek at gcc dot gnu.org]

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

Bug ID: 87109
   Summary: Wrong overload picked with ref-qualifiers
   Product: gcc
   Version: 9.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 in , g++
chooses the wrong overload for f1:

#include 

struct C { };
struct A {
  operator C() &;
  operator C() &&;
};

C f1(A a)
{
   return a; // should call operator C()&, but calls operator C()&&
}

C f2(A a)
{
   return std::move(a); // calls operator C()&&
}

[Bug c++/87029] Add -Wredundant-move warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Implemented for GCC 9.  This warning should still be extended to handle
initializers, where the std::move can also be redundant.

[Bug c++/87029] Add -Wredundant-move warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Sun Aug 26 16:45:51 2018
New Revision: 263863

URL: https://gcc.gnu.org/viewcvs?rev=263863&root=gcc&view=rev
Log:
PR c++/87029, Implement -Wredundant-move.
* c.opt (Wredundant-move): New option.

* typeck.c (treat_lvalue_as_rvalue_p): New function.
(maybe_warn_pessimizing_move): Call convert_from_reference.
Warn about redundant moves.

* doc/invoke.texi: Document -Wredundant-move.

* g++.dg/cpp0x/Wredundant-move1.C: New test.
* g++.dg/cpp0x/Wredundant-move2.C: New test.
* g++.dg/cpp0x/Wredundant-move3.C: New test.
* g++.dg/cpp0x/Wredundant-move4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wredundant-move1.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wredundant-move2.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wredundant-move3.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wredundant-move4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/87108] New: Template partial specialization is ignored

[ghabriel.nunes at hotmail dot com]

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

Bug ID: 87108
   Summary: Template partial specialization is ignored
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ghabriel.nunes at hotmail dot com
  Target Milestone: ---

Created attachment 44599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44599&action=edit
Code to reproduce the problem

Compiling the attached code with g++ bug.cpp (no other flags required) results
in two errors:

bug.cpp: In function ‘ExampleScaling foo()’:
bug.cpp:26:17: error: could not convert ‘{42}’ from ‘’ to ‘ExampleScaling’ {aka ‘HowAboutNo’}
 return { 42 };
 ^
bug.cpp: In function ‘int main(int, char**)’:
bug.cpp:30:24: error: ‘using ExampleScaling = scale_t<1000, amount<1> >’ {aka
‘struct HowAboutNo’} has no member named ‘value’
 std::cout << foo().value << std::endl;
^

I've tested all versions from 6.1 to 8.2 (in godbolt) and 8.1.1 (locally) and
all of them yield the same result. The code compiles fine in Clang and MSVC.

[Bug c++/87080] [9 Regression] ice in cp_get_fndecl_from_callee, at cp/cvt.c:965

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/87080] [9 Regression] ice in cp_get_fndecl_from_callee, at cp/cvt.c:965

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Sun Aug 26 16:31:27 2018
New Revision: 263862

URL: https://gcc.gnu.org/viewcvs?rev=263862&root=gcc&view=rev
Log:
PR c++/87080
* typeck.c (maybe_warn_pessimizing_move): Do nothing in a template.

* g++.dg/cpp0x/Wpessimizing-move5.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

Reducing the Transaction Memory test case

[sameeran joshi]

Hi,
I have found an ICE in the transaction memory extension while
compiling a program with gcc,but unfortunately for filing a bug in the
gcc bugzilla I am unable to reduce the buggy file with creduce .

I have included the command line option -fgnu-tm while compiling it.
Does creduce support transactional memory for reduction?

Below is the shell file attached for the interestingness test .It
always returns 1, if somehow hacking it returns  0 following message
is displayed:

C-Reduce cannot run because the interestingness test does not return
zero. Please ensure that it does so not only in the directory where
you are invoking C-Reduce, but also in an arbitrary temporary
directory containing only the files that are being reduced. In other
words, running these commands:

  DIR=`mktemp -d`
  cp /home/swamimauli/upload/csmith/runtime/del/testcase.c $DIR
  cd $DIR
  /home/swamimauli/upload/csmith/runtime/del/check.sh
  echo $?

should result in "0" being echoed to the terminal.

See "creduce --help" for more information.

Thanks,
Sameeran Joshi


check.sh
Description: Bourne shell script

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[kobalicek.petr at gmail dot com]

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

--- Comment #6 from Petr  ---
I think the test-case can even be simplified to something like this:

#include 
#include 

struct Point {
  double x, y;

  void reset(double x, double y) {
this->x = x;
this->y = y;
  }
};

void f1(Point* p, Point* a) {
  p->reset(std::max(std::sqrt(p->x), a->x),
   std::max(std::sqrt(p->y), a->y));
}

GCC is unable to vectorize it:

  [-std=c++17 -O3 -mavx2 -fno-math-errno]
  f1(Point*, Point*):
vsqrtsd xmm0, xmm0, QWORD PTR [rdi+8]
vmovsd  xmm1, QWORD PTR [rsi+8]
vsqrtsd xmm2, xmm2, QWORD PTR [rdi]
vmaxsd  xmm1, xmm1, xmm0
vmovsd  xmm0, QWORD PTR [rsi]
vmaxsd  xmm0, xmm0, xmm2
vunpcklpd   xmm0, xmm0, xmm1
vmovups XMMWORD PTR [rdi], xmm0
ret

whereas clang can:

  [-std=c++17 -O3 -mavx2 -fno-math-errno]
  f1(Point*, Point*):
vsqrtpd xmm0, xmmword ptr [rdi]
vmovupd xmm1, xmmword ptr [rsi]
vmaxpd  xmm0, xmm1, xmm0
vmovupd xmmword ptr [rdi], xmm0
ret

I think this is a much simpler test-case to start with.

[Bug fortran/86481] [OOP] Memory leak with sourced allocation

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
I am just about to post a patch for this PR.

Paul

[Bug web/87050] Bump wwwdocs to html5

[gerald at pfeifer dot com]

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

--- Comment #9 from Gerald Pfeifer  ---
(In reply to jos...@codesourcery.com from comment #6)
> A replacement for MetaHTML is already available, we just need to switch to 
> using it.
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00176.html

So, I took this report as nudge to speed up completing the transition
from XHTML to HTML 5 that I started earlier this year and expect to be
complete (short of, perhaps, our main page) by next weekend.

That should, as a side effect, allow making David's nice script even a
bit simpler. :-)

[Bug c++/87107] New: Template instantiation is 50x slower than with clang++

[ufospoke at gmail dot com]

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

Bug ID: 87107
   Summary: Template instantiation is 50x slower than with clang++
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ufospoke at gmail dot com
  Target Milestone: ---

Created attachment 44598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44598&action=edit
File to reproduce the issue

The new IO extension from GIL (boost 1.68.0) takes a very long time to compile
with g++ 8.2.0 compared to clang++ 5 or 6. Note that this is also true with g++
6 and 7 but not with g++ 5. I also opened an issue at boost::gil:
https://github.com/boostorg/gil/issues/131

I was able to identify which code exactly takes so much time to compile and I
was able to make it independent from any external libraries, in particular from
boost (MPL and GIL). See the attached file
"gcc-is-long-minimum-and-standalone.cpp".

With this particular program, g++ 8.2.0 is 53x longer than clang 6.0 on my
x86_64 linux computer (8.175 s vs 0.152 s).

The command line is:
g++-8.2.0 -o out.o -c -O2 -DNDEBUG -std=c++14
Progs/gcc-is-long-minimum-and-standalone.cpp

clang++ -o out.o -c -O2 -DNDEBUG -std=c++14
Progs/gcc-is-long-minimum-and-standalone.cpp

[Bug fortran/86704] [8/9 Regression] Segmentation fault when using matmul in combination with transpose

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
Fixed on all affected branches, closing.

Thanks for the bug report!

[Bug fortran/86704] [8/9 Regression] Segmentation fault when using matmul in combination with transpose

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Aug 26 12:02:28 2018
New Revision: 263861

URL: https://gcc.gnu.org/viewcvs?rev=263861&root=gcc&view=rev
Log:
2018-08-26  Thomas Koenig  

Backport from trunk
PR libfortran/86704
* m4/matmul_internal.m4: Correct calculation of needed buffer size
for arrays of shape (1,n).
* generated/matmul_c10.c: Regenerated
* generated/matmul_c16.c: Regenerated
* generated/matmul_c4.c: Regenerated
* generated/matmul_c8.c: Regenerated
* generated/matmul_i1.c: Regenerated
* generated/matmul_i16.c: Regenerated
* generated/matmul_i2.c: Regenerated
* generated/matmul_i4.c: Regenerated
* generated/matmul_i8.c: Regenerated
* generated/matmul_r10.c: Regenerated
* generated/matmul_r16.c: Regenerated
* generated/matmul_r4.c: Regenerated
* generated/matmul_r8.c: Regenerated
* generated/matmulavx128_c10.c: Regenerated
* generated/matmulavx128_c16.c: Regenerated
* generated/matmulavx128_c4.c: Regenerated
* generated/matmulavx128_c8.c: Regenerated
* generated/matmulavx128_i1.c: Regenerated
* generated/matmulavx128_i16.c: Regenerated
* generated/matmulavx128_i2.c: Regenerated
* generated/matmulavx128_i4.c: Regenerated
* generated/matmulavx128_i8.c: Regenerated
* generated/matmulavx128_r10.c: Regenerated
* generated/matmulavx128_r16.c: Regenerated
* generated/matmulavx128_r4.c: Regenerated
* generated/matmulavx128_r8.c: Regenerated

2018-08-26  Thomas Koenig  

Backport from trunk
PR libfortran/86704
* gfortran.dg/matmul_19.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/matmul_19.f90
Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/libgfortran/ChangeLog
branches/gcc-8-branch/libgfortran/generated/matmul_c10.c
branches/gcc-8-branch/libgfortran/generated/matmul_c16.c
branches/gcc-8-branch/libgfortran/generated/matmul_c4.c
branches/gcc-8-branch/libgfortran/generated/matmul_c8.c
branches/gcc-8-branch/libgfortran/generated/matmul_i1.c
branches/gcc-8-branch/libgfortran/generated/matmul_i16.c
branches/gcc-8-branch/libgfortran/generated/matmul_i2.c
branches/gcc-8-branch/libgfortran/generated/matmul_i4.c
branches/gcc-8-branch/libgfortran/generated/matmul_i8.c
branches/gcc-8-branch/libgfortran/generated/matmul_r10.c
branches/gcc-8-branch/libgfortran/generated/matmul_r16.c
branches/gcc-8-branch/libgfortran/generated/matmul_r4.c
branches/gcc-8-branch/libgfortran/generated/matmul_r8.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_c10.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_c16.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_c4.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_c8.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_i1.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_i16.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_i2.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_i4.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_i8.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_r10.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_r16.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_r4.c
branches/gcc-8-branch/libgfortran/generated/matmulavx128_r8.c
branches/gcc-8-branch/libgfortran/m4/matmul_internal.m4

[Bug libstdc++/87106] New: Group move and destruction of the source, where possible, for speed

[glisse at gcc dot gnu.org]

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

Bug ID: 87106
   Summary: Group move and destruction of the source, where
possible, for speed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Just a random testcase so I can give numbers, I don't claim this is a good
testcase at all

#include 
#include 

__attribute__((flatten))
void f(){
  int n = 1024*1024;
  std::vector v(n);
  v.resize(n+1);
}
int main(){
  for(int i=0;i<256;++i) f();
}

runs in about 2.4s now. In _M_default_append, we have a first loop that copies
(moves) strings from old to new, and a second loop that destroys old. If I
comment out the destroying loop (not something we should do in general, this is
just for the numbers), the running time goes down to 2.0s. If I replace the 2
loops with a single loop that does both move and destroy, the running time is
now 1.6s. Move+destroy (aka destructive move, relocation, etc) are 2 operations
that go well together and are not unlikely to simplify. Ideally the compiler
would merge the 2 loops (loop fusion) for us, but it doesn't. Doing the
operations in this order is only valid here because std::string can be
moved+destroyed nothrow.

I think it would be nice to introduce a special case for nothrow-relocatable
types in several functions for std::vector (_M_default_append is just one among
several, and probably not the most important one). If that makes the code
simpler, we could use if constexpr and limit the optimization to recent
standards. If one of the relocation papers ever makes it through the committee,
it will likely require this optimization (or at least make it an important QoI
point).

There are probably places outside of vector that could also benefit, but vector
looks like a good starting point.

[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.

[vincent-gcc at vinc17 dot net]

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

--- Comment #8 from Vincent Lefèvre  ---
(In reply to Florian Weimer from comment #7)
> Furthermore, if I don't misread the standard, the expectation is that if an
> implementation does not support threads, it still recognizes _Thread_local
> and mostly ignores it,

I suppose that the goal is to be able to compile multithread-aware programs on
platforms that do not support threads. Since there is only one thread, thread
storage duration is equivalent to static storage duration.

> so that it is available even if __STDC_NO_THREADS__
> is not defined.  (Which is of course rather dodgy if you need to conform to
> an existing ABI for thread-local variables, so I think the committee made a
> mistake here.)

The ABI is out of the scope of the standard, so that I don't see any issue
here. The conformance to the existing ABI is something above the standard.

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
We don't manage to use MIN_EXPR and get branchy code that gets optimized for
boundary cases (when min/max pick 0.0/1.0). For the minimal input

double f(double x, double y)
{
   return y < x ? y : x;
}

we get MIN_EXPR in .gimple dump with C frontend and -ffinite-math-only
-fno-signed-zeros, but not with C++ frontend.

(and even then, hacking the source to use __builtin_fmin to get straight-line
code, SLP does not manage to vectorize that)

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[kobalicek.petr at gmail dot com]

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

--- Comment #4 from Petr  ---
I think this code is vectorizable without --fast-math. However, it seems that
once a min/max (or something else) is kept scalar it poisons the rest of the
code.

The following code works perfectly (scalar):

```
#include 

template constexpr T altMinT(const T& a, const T& b) noexcept
{ return b < a ? b : a; }
template constexpr T altMaxT(const T& a, const T& b) noexcept
{ return a < b ? b : a; }

double std_min(double a, double b) { return std::min(a, b); }
double std_max(double a, double b) { return std::max(a, b); }

double alt_min(double a, double b) { return altMinT(a, b); }
double alt_max(double a, double b) { return altMaxT(a, b); }

```

I think that's the main problem - little samples are optimized well, complex
code isn't.

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
With -ffast-math we (awkwardly) vectorize a couple min/max at the beginning,
but clearly not the whole thing like llvm.