[Bug sanitizer/78204] ‘no_sanitize’ attribute directive ignored [-Wattributes]

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  ---
(In reply to Martin Liška from comment #3)
> As I'm reading the source code, there's no option to do that.
> Apart from 'no_sanitize' attribute, GCC supports 'no_sanitize_undefined'
> attribute (clang does not) and clang has 'no_sanitize_memory' (not handled
> by GCC).
> 
> I welcome the ability to have finer attributes for sanitizer and I can do
> that.
> What's Jakub thinking about it?

(In reply to Martin Liška from comment #1)
> Ok, do I understand it properly that you're missing support of
> no_sanitize("string literals"), as defined here:
> 
> http://clang.llvm.org/docs/AttributeReference.html#no-sanitize-clang-no-
> sanitize

It looks like GCC does not support this feature in any compilers (GCC 4 through
7). Is that correct?

(I'm trying to get some macros tuned based on Clang and GCC versions).

[Bug c++/70265] ICE on code with constexpr on x86_64-linux-gnu in tree check: expected statement_list, have nop_expr in tsi_start, at tree-iterator.h:42

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from Paolo Carlini  ---
Done.

[Bug c++/70265] ICE on code with constexpr on x86_64-linux-gnu in tree check: expected statement_list, have nop_expr in tsi_start, at tree-iterator.h:42

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sun May 21 22:20:05 2017
New Revision: 248313

URL: https://gcc.gnu.org/viewcvs?rev=248313=gcc=rev
Log:
2017-05-21  Paolo Carlini  

PR c++/70265
* g++.dg/cpp1y/constexpr-70265-1.C: New.
* g++.dg/cpp1y/constexpr-70265-2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-70265-1.C
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-70265-2.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/70265] ICE on code with constexpr on x86_64-linux-gnu in tree check: expected statement_list, have nop_expr in tsi_start, at tree-iterator.h:42

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
This is fixed in 7.1.0. I'm adding testcases and closing the bug.

[Bug libfortran/80850] New: Sourced allocate() fails to allocate a pointer

[liakhdi at ornl dot gov]

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

Bug ID: 80850
   Summary: Sourced allocate() fails to allocate a pointer
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liakhdi at ornl dot gov
  Target Milestone: ---

Hello,
Code repo:
https://gitlab.com/DmitryLyakh/GFC
Build:
Type make.
Problem (bug):
Please run the binary test_gfc.x 5-10 times (it is quick). On my Ubuntu laptop
some (not all) of these identical runs crash with a message from allocate():
"Attempt to allocate an allocated object"
This crash happens in gfc_base.F90 line 343. As you will see, the allocate()
statement is trying to clone an object via the sourced allocation. The
corresponding class(*) pointer "new_el" is explicitly nullified in line 342.
Thus, I do not see how I could get the above "Attempt to allocate an allocated
object" error.
If you change the BUILD_TYPE in Makefile (line 9) from "DEV" to "OPT"
(optimized), the problem disappears. New versions of GCC have the same problem
(up to 6.3). The Intel and IBM XL compilers pass all tests without any
problems.

Thanks,
Dmitry

[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls

[db0451 at gmail dot com]

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

--- Comment #11 from DB  ---
This still occurs in 6.3.0

In the duplicate

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

I showed that whether or not this occurs can sometimes (I say because my
results don't seem consistent with everyone else's) depend on the number of
arguments that are given to (all of) the constructors.

I could not replicate the problem with my test case if the constructors were
invoked with brace syntax and all had no or 1 argument, but I could when they
had 2 or more arguments.

[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls

[db0451 at gmail dot com]

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

--- Comment #10 from DB  ---
*** Bug 80849 has been marked as a duplicate of this bug. ***

[Bug c++/80849] Brace-init causes multiple runs of virtual base constructor if any ctor in the hierarchy has >1 argument

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

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

--- Comment #4 from DB  ---
...yeah, it's a dupe. By adding debug couts of the this pointer, we see that,
like in the older bug, the spurious calls get different/wrong values for it:

@0x7ffe9600e660: V42
@0x7ffe9600e660: V42
@0x7ffe9600e660: A42?
@0x7ffe9600e668: V42
@0x7ffe9600e668: B42?
@0x7ffe9600e660: C42?

Specifically, in addition to the first call to V() with the correct address,
there is an extra call to V() for every intermediate class (A and B), with the
this pointer being the address of THAT subject, not the real address of V
(although sometimes they happen to be the same).

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

[Bug c++/80849] Brace-init causes multiple runs of virtual base constructor if any ctor in the hierarchy has >1 argument

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

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

--- Comment #3 from DB  ---
Actually, I'm not sure whether this is directly related to that other one, so
I'll reopen it and let the devs decide.

[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

 CC||db0451 at gmail dot com

--- Comment #9 from DB  ---
*** Bug 80849 has been marked as a duplicate of this bug. ***

[Bug c++/80849] Brace-init causes multiple runs of virtual base constructor if any ctor in the hierarchy has >1 argument

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

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

--- Comment #2 from DB  ---
Whoops, this already exists as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55922

I'll link back to here with this test case, in case it's useful as another data
point.

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

[Bug c++/80849] Brace-init causes multiple runs of virtual base ctor if its signature differs from its derived classes' ctors

[db0451 at gmail dot com]

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

--- Comment #1 from DB  ---
(In reply to DB from comment #0)
> With additional testing, on 6.3.0, I determined that - much like that other
> old bug - this problem only occurs if the virtual base constructor and the
> constructors of the intermediate derived classes have different argument
> signatures.
> [...]
> Like the other bug, if you alter the constructors of V, A, and B to have the
> same number/type of arguments, then the problematic extra calls are
> suppressed.

Huh, no. It seems that any number of arguments > 1 causes the problem, even if
all the ctor signatures match.

Thus I think the pattern is as follows: Only if the ctors are single-argument,
will brace-initialisation not result in spurious extra calls to the virtual
base constructor.

[Bug c++/80849] New: Brace-init causes multiple runs of virtual base ctor if its signature differs from its derived classes' ctors

[db0451 at gmail dot com]

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

Bug ID: 80849
   Summary: Brace-init causes multiple runs of virtual base ctor
if its signature differs from its derived classes'
ctors
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: db0451 at gmail dot com
  Target Milestone: ---

This appears to be a lingering offshoot of this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617

which I was reminded of via:
http://stackoverflow.com/questions/38466871/invoking-constructors-during-virtual-inheritance-with-c


As the user on SO reported, and verified with GDB, when they are initialised
using braces, the intermediate classes' constructors also invoke the virtual
base class's constructor, redundantly. They were using 5.4.0


With additional testing, on 6.3.0, I determined that - much like that other old
bug - this problem only occurs if the virtual base constructor and the
constructors of the intermediate derived classes have different argument
signatures.


reduced test case:

#include 

// Choose one:
//#define DB_INITIALISE(...) (__VA_ARGS__)
#define DB_INITIALISE(...) {__VA_ARGS__}

struct V {
V(int i) { std::cout << 'V' << i << std::endl; }
};

struct A:  virtual V {
A(int i, char c): V DB_INITIALISE(i) { std::cout << 'A' << i <<
c << std::endl; }
};

struct B:  virtual V {
B(int i, char c): V DB_INITIALISE(i) { std::cout << 'B' << i <<
c << std::endl; }
};

struct C:  A,  B {
C(int i, char c): V DB_INITIALISE(i), A DB_INITIALISE(i, c), B
DB_INITIALISE(i, c) { std::cout << 'C' << i << c << std::endl; }
};

int main()
{
C c{42, '?'};
}

Expected output, obtained when DB_INITIALISE causes initialisation with ():

V42
A42?
B42?
C42?

Actual output, obtained when DB_INITIALISE causes initialisation with {}:

V42
V42
A42?
V42
B42?
C42?

Like the other bug, if you alter the constructors of V, A, and B to have the
same number/type of arguments, then the problematic extra calls are suppressed.

[Bug sanitizer/80847] UBSAN: yet another false positive (part2)

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #2 from Marc Glisse  ---
.

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

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||babokin at gmail dot com

--- Comment #14 from Marc Glisse  ---
*** Bug 80847 has been marked as a duplicate of this bug. ***

[Bug fortran/80766] [7/8 Regression] [OOP] ICE with type-bound procedure returning an array

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #9)
> (In reply to janus from comment #8)
> > This shows one ICE in the testsuite:
> > 
> > FAIL: gfortran.dg/typebound_proc_32.f90   -O  (internal compiler error)
> 
> Is this before or after submission of patch to list?

That's an old patch. The one posted on the mailing list does the resolution
only if the vtab was freshly found via 'gfc_find_derived_vtab' and thus avoids
the ICE. Should have mentioned that, sorry!

[Bug fortran/80766] [7/8 Regression] [OOP] ICE with type-bound procedure returning an array

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #9 from Jerry DeLisle  ---
(In reply to janus from comment #8)
> (In reply to janus from comment #5)
> > This rather simple patch fixes the ICE on trunk:
> > 
> > Index: gcc/fortran/resolve.c
> > ===
> > --- gcc/fortran/resolve.c   (revision 247818)
> > +++ gcc/fortran/resolve.c   (working copy)
> > @@ -13833,6 +13833,9 @@ resolve_fl_derived (gfc_symbol *sym)
> >   gcc_assert (vtab);
> >   vptr->ts.u.derived = vtab->ts.u.derived;
> > }
> > +
> > +  if (!resolve_fl_derived0 (vptr->ts.u.derived))
> > +   return false;
> >  }
> >  
> >if (!resolve_fl_derived0 (sym))
> 
> This shows one ICE in the testsuite:
> 
> FAIL: gfortran.dg/typebound_proc_32.f90   -O  (internal compiler error)


Is this before or after submission of patch to list?

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #12 from Daniel Santos  ---
Created attachment 41398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41398=edit
proposed fix v2 part 2

Formatting, comments and other aesthetic changes.

[Bug fortran/80256] Cygwin test fail: bind_c_array_params_2.f90 scan-assembler-times

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
Patch applied and tested. I will commit to trunk shortly and then backport a
few

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

Daniel Santos  changed:

   What|Removed |Added

  Attachment #41396|0   |1
is obsolete||

--- Comment #11 from Daniel Santos  ---
Created attachment 41397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41397=edit
proposed fix v2 part 1

Oops, I forgot to re-add my parallelize.exp script to the commit.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

Daniel Santos  changed:

   What|Removed |Added

  Attachment #41386|0   |1
is obsolete||

--- Comment #10 from Daniel Santos  ---
Created attachment 41396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41396=edit
proposed fix v2 part 1

So I've moved the body of do_test_(un)aligned into inline gcc where I can use
the template to pass the offsets within test_data.  This splits up the assembly
and makes it a bit harder to decipher, but it also cleans up access to
test_data struct members.

I've hard-coded the "-m64" into the CFLAGS for now and this should be fine
since the test only runs on 64-bit x86 and only when the remote is native.  If
I ever figure out where this is usually fed from, I'll swap that out. :)

Anyway, if you can test it again for me and let me know what you think I would
appreciate it.  I've got some other code formatting changes I want to send with
it, but I separated it out from this patch to simplify reading.  I'll post the
second patch anyway though.

Thanks,
Daniel

[Bug c++/80848] New: /crtend.o(.eh_frame); no .eh_frame_hdr table will be created

[mitalis at iiitd dot ac.in]

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

Bug ID: 80848
   Summary: /crtend.o(.eh_frame); no .eh_frame_hdr table will be
created
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mitalis at iiitd dot ac.in
  Target Milestone: ---

I am trying to compile a C++ code using a cross-compiler built using
crosstool-ng. It is throwing the following error:


:~/Desktop$ alphaev4-unknown-linux-gnu-g++ -static new1.cpp -o hello  
/home/iiitd/local/x-tools/alphaev4-unknown-linux-gnu/lib/gcc/alphaev4-unknown-linux-gnu/6.3.1/../../../../alphaev4-unknown-linux-gnu/bin/ld:
error in
/home/iiitd/local/x-tools/alphaev4-unknown-linux-gnu/lib/gcc/alphaev4-unknown-linux-gnu/6.3.1/crtend.o(.eh_frame);
no .eh_frame_hdr table will be created.

crosstool-NG version: crosstool-ng-1.23.0.rc2
Binutils Version: 2.28
glibc version 2.25
gcc linaro 6.3-2017.02
Host OS: ubuntu 16.04 LTS, 64-bit

[Bug sanitizer/80847] UBSAN: yet another false positive (part2)

[babokin at gmail dot com]

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

Dmitry Babokin  changed:

   What|Removed |Added

 CC||babokin at gmail dot com,
   ||mpolacek at gcc dot gnu.org,
   ||vsevolod.livinskij at frtk dot 
ru

--- Comment #1 from Dmitry Babokin  ---
Seems like UBSAN instrumentation is done too late.

[Bug sanitizer/80847] New: UBSAN: yet another false positive (part2)

[babokin at gmail dot com]

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

Bug ID: 80847
   Summary: UBSAN: yet another false positive (part2)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev248312, x86_64.

> cat f.cpp
long long int a = -8619712598616233901LL;
long long int b = -2492839055825936744LL;
long long int c = 0;
int main() {
  if (c * a + b * c)
return 1;
  return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp

> ./a.out
f.cpp:5:13: runtime error: signed integer overflow: -8619712598616233901 +
-2492839055825936744 cannot be represented in type 'long long int'

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #41375|0   |1
is obsolete||

--- Comment #15 from Martin Liška  ---
Created attachment 41395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41395=edit
Patch v3

This can compile also the original test, changing epsilon to 1/1000.

[Bug c++/80830] [8 Regression] ICE in tsubst_copy, at cp/pt.c:14569

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Reduced test-case:

template  class a;
class b
{
  friend int operator>> (int, b);
};
template  int >> (int &, a &);
template  class a
{
  friend int >><> (int &, a &);
  a<>
  d ()
  {
  }
};

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
Results on a Corei7 2.8Ghz with 16Gb of RAM 

for 512^3

% time gfc pr80610_db.f90 -finit-real=nan
329.364u 16.328s 5:58.24 96.4%  0+0k 3+1197io 599275pf+0w
% ll ./a.out
-rwxr-xr-x 1 dominiq staff 536879568 May 20 16:22 a.out*

for 1024*512^2

% time gfc pr80610_db.f90 -finit-real=nan
688.772u 40.163s 12:43.51 95.4% 0+0k 7179+2546io 1553879pf+0w
% ll ./a.out
-rwxr-xr-x 1 dominiq staff 1073751008 May 20 20:12 ./a.out*

for 1024^2*512

% time gfc pr80610_db.f90 -finit-real=nan
1237.208u 106.464s 23:48.15 94.0%   0+0k 7360+5316io 3284084pf+0w
% ll ./a.out
-rwxr-xr-x 1 dominiq staff 2147492832 May 20 22:02 ./a.out*

Note that 80% of the time is taken by the clang as and that the total time and
the size of the executable scale roughly linearly.

For 1024^3 the behavior depends on the mood of my laptop (with only 80Gb left
on my SSD): I got

% time gfc pr80610.f90 -finit-real=nan
gfc: internal compiler error: Killed: 9 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
42.811u 88.529s 2:28.47 88.4%   0+0k 4+8io 2pf+0w

or

% time gfc pr80610.f90 -finit-real=nan
clang -cc1as: fatal error: error in backend: IO failure on output stream.
2704.570u 1196.828s 1:08:28.71 94.9%0+0k 20192+24435io 4719854pf+0w

> Basically to initialize all of the values of a static array, the array
> is stored in gfortan memory.  To do a 1GB array, you need at least 32times
> that amount of virtual memory available.  Related to bug 56671.

On my darwin box it looks that I rather need 64 times the size of the array,
also it seems that darwin compress the memory rather than using virtual memory.
What is the origin of this factor 8/16 increase in the memory size?

[Bug tree-optimization/80842] [7/8 Regression] ICE at -O3 on x86_64-linux-gnu in "set_lattice_value"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-05-21
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|gcc ICE at -O3 on   |[7/8 Regression] ICE at -O3
   |x86_64-linux-gnu in |on x86_64-linux-gnu in
   |"set_lattice_value" |"set_lattice_value"
  Known to fail||7.1.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r242921.

[Bug c++/80840] [7/8 Regression] ICE in convert_nontype_argument reference to double

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-21
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||6.3.0
Summary|ICE in  |[7/8 Regression] ICE in
   |convert_nontype_argument|convert_nontype_argument
   |reference to double |reference to double
 Ever confirmed|0   |1
  Known to fail||7.1.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r241425.

[Bug c++/80830] [8 Regression] ICE in tsubst_copy, at cp/pt.c:14569

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-21
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
  Known to work||7.1.0
   Target Milestone|--- |8.0
Summary|ice in tsubst_copy, at  |[8 Regression] ICE in
   |cp/pt.c:14569   |tsubst_copy, at
   ||cp/pt.c:14569
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r248250. I'll try to isolate a valid C++ test-case.

[Bug c++/80831] [6/7/8 Regression] ICE: Segmentation fault with -fsyntax-only

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
 Ever confirmed|0   |1
  Known to fail||6.3.0, 7.1.0, 8.0

[Bug c++/80831] [6/7/8 Regression] ICE: Segmentation fault with -fsyntax-only

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2017-5-21
 CC||aldyh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|internal compiler error:|[6/7/8 Regression] ICE:
   |Segmentation fault with |Segmentation fault with
   |-fsyntax-only   |-fsyntax-only

--- Comment #1 from Martin Liška  ---
Back-trace:

Program received signal SIGSEGV, Segmentation fault.
c_parse_final_cleanups() () at ../../gcc/cp/decl2.c:4769
4769  if (node->cpp_implicit_alias)
(gdb) bt
#0  c_parse_final_cleanups() () at ../../gcc/cp/decl2.c:4769
#1  0x013c0ee9 in compile_file() () at ../../gcc/toplev.c:463
#2  0x00d7f700 in do_compile () at ../../gcc/toplev.c:1986
#3  toplev::main(int, char**) () at ../../gcc/toplev.c:2094
#4  0x00d80ec7 in main (argc=15, argv=0x7fffdf88) at
../../gcc/main.c:39

Started with merge of early debug, r224161.

[Bug fortran/52473] CSHIFT slow - inline it?

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Created attachment 41394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41394=edit
Benchmark of straight DO loops vs. library version

Some numbers from

https://groups.google.com/forum/#!topic/comp.lang.fortran/AI0F1Vpkc3I

show that using straight DO loops could both help and hurt:

$ ./a.out
 Testing explicit DO loops
 Dim =1  Elapsed CPU time =2.82861114
 Dim =2  Elapsed CPU time =2.93245506
 Dim =3  Elapsed CPU time =2.94523525
 Testing built-in cshift
 Dim =1  Elapsed CPU time =1.65619278
 Dim =2  Elapsed CPU time =2.80988693
 Dim =3  Elapsed CPU time =7.13671684 

I'll see what could be done using an explicit call to memcpy
for the innermost loops.

[Bug bootstrap/80838] PGO/LTO bootstrapped compiler 5% slower than pure PGO bootstrapped one

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #1)
> If it is easy to do, can you attach profiles please?
> i will try to reproduce this...

Thanks. 
(There is still some tooling missing (perf, etc.) on the Ryzen machines.
So sorry, no additional numbers for now.)

[Bug middle-end/80743] [8 Regression] ICE in estimate_node_size_and_time, at ipa-inline-analysis.c:3385

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug target/80845] nvptx backend generates cvt.u32.u32

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Created attachment 41393
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41393=edit
tentative patch

[Bug target/80845] nvptx backend generates cvt.u32.u32

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Likewise, a split reg example in gcc/testsuite/gcc.target/nvptx/abi-vararg-2.c:
...
//(insn 29 27 30 4
// (set (reg:DI 40)
//  (subreg:DI (reg:TI 23) 0))  5 {*movdi_insn}
// (nil))
cvt.u64.u64 %r40, %r23$0;   // 29   *movdi_insn/1
...

With dst_inner == DI and src_inner == TI we end up printing cvt.u64.u64 instead
of mov.u64.