[Bug c++/86298] New: template argument cannot be narrowed to type 'int'

[zhonghao at pku dot org.cn]

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

Bug ID: 86298
   Summary: template argument cannot be narrowed to type 'int'
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

template 
struct as_nview { };

template  
struct as_nview 
{ };

g++ produces only a warning message, and it points to a wrong location:

warning: overflow in conversion from 'long int' to 'int' changes value from
'9223372036854775807' to '-1' [-Woverflow]
 struct as_nview
 ^

Instead, clang++ rejects the code:

 error: non-type template argument evaluates to
  9223372036854775807, which cannot be narrowed to type 'int'
  [-Wc++11-narrowing]
template 


The error message of clang++ seem to be more reasonable, right?

[Bug fortran/86297] rejects valid code on type extension

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
This is the error message from gfortran:
Error: 'p' at (1) must have the same number of formal arguments as the
overridden procedure

[Bug fortran/86297] New: rejects valid code on type extension

[juergen.reuter at desy dot de]

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

Bug ID: 86297
   Summary: rejects valid code on type extension
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following code is rejected my gfortran 9.0 (I also checked 5.4.0). It is
accepted by nagfor 6.2 and ifort 18 and 19beta, but was rejected by ifort 17
with the same argument as by gfortran. It is rejected by PGI fortran v18.5.
Apparently, it is from an interp F08/0052 in F2008 corrigendum one and was
discussed by Ian Harvey on c.l.f. on July 5, 2016 under the topic
"Interpretation F08/0052 (overriding private bindings) ". Somehow, ifort
changed their minds to accept this code, so it is standard-compliant? 


MODULE example1_m1
  TYPE t1
   CONTAINS
 PROCEDURE,PRIVATE,NOPASS :: p ! (1).
  END TYPE t1
CONTAINS
  SUBROUTINE p
PRINT *,'p'
  END SUBROUTINE p
  SUBROUTINE do_p(x)
CLASS(t1) x
CALL x%p
  END SUBROUTINE do_p
END MODULE example1_m1
MODULE example1_m2
  USE example1_m1
  TYPE,EXTENDS(t1) :: t2
   CONTAINS
 PROCEDURE,NOPASS :: p => p2 ! (2).
  END TYPE t2
CONTAINS
  SUBROUTINE p2(n)
PRINT *,'p2',n
  END SUBROUTINE p2
END MODULE example1_m2
~

[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[glisse at gcc dot gnu.org]

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

--- Comment #15 from Marc Glisse  ---
(In reply to Martin Sebor from comment #14)
> > You say that
> > 
> >  struct { int a; int b; } s, s2;
> >  memcpy (, , sizeof (s));
> > 
> > is invalid, aka not copying the whole structure since you pass in a
> > pointer to s2.a rather than s2?
> 
> Yes.

Let's give the struct a name and introduce some casts

typedef struct { int a; int b; } S;
S s, s2;
memcpy ((S*), (S*), sizeof(s));

The standard makes it valid to convert  to S* and makes it equivalent to
 Because of the call to memcpy, it gets converted to void* afterwards. So
you are saying that (void*) is not the same as (void*)(S*) (note that
no arithmetic is involved at this point). This looks like it is going to cause
trouble...

[Bug c++/86296] New: Creating a pointer class for a unique_ptr<>() deleter fails with optimizations

[alexis at m2osw dot com]

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

Bug ID: 86296
   Summary: Creating a pointer class for a unique_ptr<>() deleter
fails with optimizations
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexis at m2osw dot com
  Target Milestone: ---

Created attachment 44317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44317=edit
Source exhibiting the template deleter with a pointer problem

I created a C++ deleter template for unique_ptr<>() that includes a pointer
class. It works as expected when no optimizations are applied (-O0) however,
when I add any level of optimizations (-O1, -O2, -O3) the compiler doesn't work
right. At that point the pointer can't be retrieved correctly. The pointer
operator (T & operator * ()) function returns zero even though within that
function, the pointer value is correct.

main() creates a unique pointer. I immediately check for the value and it
returns -1 as expected when I use -O0, but zero when I use a higher level of
optimization.

Then I reset the pointer to the value of a file descriptor (safe_fd.reset(fd))
and at that point the pointer operator still returns zero when the code is
optimized.

The following is the output when I compile with -O0

default initialization: safe_fd = -1
fd = 3
safe_fd after the reset(3) = 3
second close returned -1 (errno = 9)

The wrong output when I compile with -O1, -O2, -O3

default initialization: safe_fd = 0
fd = 3
safe_fd after the reset(3) = 0
second close returned -1 (errno = 9)

The output is expected to be the same as with -O0.

I tested with stock g++ on Ubuntu 16.04

g++ (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609

And also on Ubuntu 18.04

g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0

Both versions failed in a similar way.

I'm attaching my source file. It compiles as is on those versions of Ubuntu and
I would imagine any Unix system with the same or similar compiler version. The
command line I use to compile.

No optimization (working as expected):

g++ --std=c++14 -O0 ~/tmp/b.cpp -o b

Any level of optimization (1 to 3 at least) and the pointer operator breaks:

g++ --std=c++14 -O3 ~/tmp/b.cpp -o b

[Bug libstdc++/86295] New: Missing exception safety when inserting range into vector

[kristian.spangsege at gmail dot com]

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

Bug ID: 86295
   Summary: Missing exception safety when inserting range into
vector
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristian.spangsege at gmail dot com
  Target Milestone: ---

When inserting a range into a `std::vector`, and the copy, or move constructor
for the value type throws at an unfortunate time, some constructed objects of
the value type will never be destroyed.

More specifically, the version of `std::vector::_M_range_insert()`, that is for
forward iterators, has calls to `std::__uninitialized_copy_a()` and
`std::__uninitialized_move_a()` at various places. If I understand correctly,
these functions construct a number of new objects of the value type. After each
such call, the logical size of the vector is then increased by the number of
new objects.

The problem occurs when either `std::__uninitialized_copy_a()` or
`std::__uninitialized_move_a()` throws due to throwing from the copy or move
constructor of the value type. In this case, the logical size of the vector
remains at its prior value, which means that if any objects were created, they
will be forgotten about (leaked).

As far as I can see, a solution would be to the carry out these copy and move
operations one value at a time, and update the logical size after each step.

I am referring to the version of libstdc++ that comes with GCC 8.0.1 here.

[Bug c++/71220] ICE on instantiation using variadic template

[rippey.e at gmail dot com]

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

rippey.e at gmail dot com changed:

   What|Removed |Added

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

--- Comment #2 from rippey.e at gmail dot com ---
No longer fails in g++ 8.1.0.

[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor  ---
> You say that
> 
>  struct { int a; int b; } s, s2;
>  memcpy (, , sizeof (s));
> 
> is invalid, aka not copying the whole structure since you pass in a
> pointer to s2.a rather than s2?

Yes.  It's invalid for the same reason as the following:

  int *p = 
  int *q = 

  *q = *p;// okay
  ++q, ++p;   // okay
  *q = *p;// undefined #1
  ++q, ++p;   // undefined #2

In s.a and s.b are effectively arrays of one element, i.e., int[1].  As Joseph
explained in comment #13, pointer arithmetic is defined only for and within
each array object, irrespective of whether the array is itself an element of
another array or a member of a struct.  So above, #1 is undefined because it
accesses a past-the-end element of an array, and #2 is undefined because the
only valid arithmetic on a past-the-end pointer is to subtract one from it.

This is specified in 6.5.6 Additive operators, p8 of C11.  In C89, the
corresponding text is in section 3.3.6.  The same restriction applies to all
library functions, including memcpy and strcpy.

> Alternatively
> 
>  struct { int x; int a; int b; } s, s2;
>  memcpy (, , sizeof (s) - sizeof (int));
> 
> is similarly invalid, not copying the last two elements?

Yes.  It's invalid for the same reasons as above.  This would be valid:

  struct S { int x; int a; int b; } s, s2;
  memcpy ((char*) + offseof (struct S, a),
  (char*)&2 + offseof (struct S, a),
  sizeof (s) - offseof (struct S, a));

This is valid because  and  point to the objects s and s2.  Any object can
be interpreted as an array of char with a size equal to the object itself and
the pointer arithmetic is valid anywhere within the object.

> 
> I don't see how str* are in anyway less special than mem* here in case you
> come up with an exception for mem*.

In the standard, the restrictions above apply equally to expressions as well as
library functions.  For better or worse, GCC treats memxxx() functions
differently than strxxx() functions because of legacy invalid code that relies
on the second memcpy example working.  This is evident from the effects of
_FORTIFY_SOURCE.  For example, the following gets a warning when compiled with
_FORTIFY_SOURCE=1 and aborts with a buffer overflow error at runtime:

  #include 

  int main (void)
  {
struct {
  char a[4];
  char b[3];
} a;

a[0] = '0';
strcpy (a.a + 1, "12345");

__builtin_puts (a.a);
  }

In function ‘strcpy’,
inlined from ‘main’ at c.c:12:5:
/usr/include/bits/string3.h:110:10: warning: ‘__builtin___memcpy_chk’ writing 6
bytes into a region of size 3 overflows the destination [-Wstringop-overflow=]
...
*** buffer overflow detected ***: ./a.out terminated

(The region of 3 is the amount of space in the a.a array at offset 1.)

but because the special treatment applies only to the memxxx functions and not
to string functions, the equivalent program using memcpy() compiles without a
warning and runs successfully to completion:

  #include 

  int main (void)
  {
struct {
  char a[4];
  char b[3];
} a;

a[0] = '0';
memcpy (a.a + 1, "12345", 6);

__builtin_puts (a.a);
  }

Because the special treatment applies only to raw memory functions like memcpy
and memmove and not to string functions like strcpy or strlen, none of the test
cases here is valid even under GCC's relaxed rules.

[Bug c++/82373] syntax error in error message

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/82507] [concepts] premature substitution into constraint of non-template member function

[Casey at Carter dot net]

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

--- Comment #1 from Casey Carter  ---
Gentle ping: working around this bug is making it incredibly hard to prototype
the Ranges design for C++20.

[Bug c++/84767] [6 Regression] ICE with pointer to VLA

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |pointer to VLA  |pointer to VLA

--- Comment #7 from Volker Reichelt  ---
Fixed for GCC 7.4

[Bug c++/85068] [6 Regression] ICE with invalid covariant return type hierarchy

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |invalid covariant return|invalid covariant return
   |type hierarchy  |type hierarchy

--- Comment #6 from Volker Reichelt  ---
Fixed for GCC 7.4

[Bug c++/85076] [6 Regression] ICE with invalid template used as lambda argument

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |invalid template used as|invalid template used as
   |lambda argument |lambda argument

--- Comment #9 from Volker Reichelt  ---
Fixed for GCC 7.4

[Bug c++/85140] [6 Regression] ICE with invalid use of alignas

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |invalid use of alignas  |invalid use of alignas

--- Comment #6 from Volker Reichelt  ---
Fixed for GCC 7.4

[Bug c++/85208] ICE with #pragma weak and structured binding

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.4

--- Comment #6 from Volker Reichelt  ---
Fixed for GCC 7.4

[Bug c++/85210] [7 Regression] ICE with broken structured binding in template

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #7 from Volker Reichelt  ---
Fixed for GCC 7.4

[Bug debug/86257] Program compiled with fPIC crashes while stepping over thread-local variable GDB

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01505.html

[Bug tree-optimization/86136] Modular multiplication optimization

[mcccs at gmx dot com]

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

--- Comment #3 from MCCCS  ---
What about

unsigned int k (unsigned int a) {
if (a > 5) {
__builtin_unreachable();
}
return (a * 83) % 5;
}

[Bug c++/86256] Lambda will not add ref count for class intelligent pointer member when capture 'this' or & as argument

[kangchuanbo at 126 dot com]

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

--- Comment #4 from kangchuanbo at 126 dot com ---
OK, thanks for your response, I just met this issue and think it's better to
give warn or error when Lambda capture this or reference with std::shared_ptr
member inside.
So add one Lambda usage attention maybe a better way to prevent such issue
happen again.
Have a nice day, thanks.






At 2018-06-24 14:15:37, "redi at gcc dot gnu.org" 
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86256
>
>Jonathan Wakely  changed:
>
>   What|Removed |Added
>
> Status|WAITING |RESOLVED
> Resolution|--- |INVALID
>
>--- Comment #3 from Jonathan Wakely  ---
>But this is true for any lambda that captured 'this' or captures by reference.
>It doesn't make sense to warn for every use of that language feature, just in
>case it's used incorrectly.
>
>-- 
>You are receiving this mail because:
>You reported the bug.

[Bug fortran/71612] [Coarray] Wrongly rejects coindexed variables in READ

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from Jürgen Reuter  ---
This is still not resolved. I don't know whether the snippet provided by Tobias
is only a proof-of-principle way how a solution could look like or whether this
is a definite proposal for a fix.

[Bug libstdc++/86292] Missing exception safety when constructing vector from input iterator pair

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-24
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Ouch. We use push_back in a loop, but because we're still in the constructor if
an exception occurs we don't run the destructor.

[Bug c++/86256] Lambda will not add ref count for class intelligent pointer member when capture 'this' or & as argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Jonathan Wakely  ---
But this is true for any lambda that captured 'this' or captures by reference.
It doesn't make sense to warn for every use of that language feature, just in
case it's used incorrectly.