[Bug c++/88446] New: __builtin_is_constant_evaluated rejects some converted constant expressions.

[eric at efcs dot ca]

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

Bug ID: 88446
   Summary: __builtin_is_constant_evaluated rejects some converted
constant expressions.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

__builtin_is_constant_evaluated() is not a constant expression when used in
array bounds or new expressions.


// g++ -fsyntax-only -std=c++2a 
char CA[__builtin_is_constant_evaluated()]; // rejects-valid
auto CP = new char[3][__builtin_is_constant_evaluated()]; // rejects-valid

[Bug c++/88555] New: [9 Regression] Pack expansion fails

[eric at efcs dot ca]

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

Bug ID: 88555
   Summary: [9 Regression] Pack expansion fails
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

GCC fails to expand parameter packs when used in certain contexts. This is a
regression from 8.2.

https://godbolt.org/z/9MrTQQ

Reproducer:

// g++ -std=c++17
template  struct T {};

template 
void test() {
using Test = T;
}

[Bug c++/89158] New: [8/9 Regression] by-value capture of ICE variable isn't an lvalue?

[eric at efcs dot ca]

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

Bug ID: 89158
   Summary: [8/9 Regression] by-value capture of ICE variable
isn't an lvalue?
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The following code is incorrectly rejected.

// g++ -std=c++14
struct T { T(const int&); };
void Func(T);

void test() {
constexpr int Val = 42;
[Val]() { Func(Val); }; // error: lvalue required as unary '&' operand
}

My understanding is that `Val` is captured by copy, and the call to `Func`
makes it ODR used?

Regardless, I believe this code is well-formed and should be accepted.

It is accepted in 8.1, but rejected in 8.2 and trunk.

[1] https://godbolt.org/z/wrCQ53

[Bug c++/83921] New: GCC rejects constexpr initialization of empty aggregate.

[eric at efcs dot ca]

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

Bug ID: 83921
   Summary: GCC rejects constexpr initialization of empty
aggregate.
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:
// g++ -std=c++14
struct Foo {};
constexpr void test() {
  Foo f; // error: uninitialized variable 'f' in 'constexpr' function
}


This error is obviously correct for non-empty types, however surely an empty
struct doesn't need an initializer?

If we agree this is a bug, it is a regression from the 6x release series, which
doesn't diagnose this code.

[Bug c++/83921] [7/8 Regression] GCC rejects constexpr initialization of empty aggregate.

[eric at efcs dot ca]

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

--- Comment #3 from Eric Fiselier  ---
The problem also reproduces when the empty type has an explicitly defaulted
default constructor. Example:

struct Foo { Foo() = default; };
constexpr void test() { Foo f; };

[Bug c++/89580] New: overload resolution for pointers fails to consider conversion operator

[eric at efcs dot ca]

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

Bug ID: 89580
   Summary: overload resolution for pointers fails to consider
conversion operator
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

I believe the following code is valid and should be accepted.

// g++ -std=c++11
struct Foo {
  template  operator T() const;
};
// error: no match for 'operator==' (operand types are 'Foo' and 'void*')
bool R = (Foo{} == static_cast(nullptr));


Note that when Foo's conversion operator is declared as `operator T*()`, the
code is accepted.

See https://godbolt.org/z/nc43wx

[Bug c++/86641] Regression: non-ODR used auto class data members fail to deduce.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Fiselier  ---
I can't reproduce anymore. It must have been fixed.

[Bug c++/68975] Request: Provide alternate keyword for decltype in C++03

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Fiselier  ---
Apparently I don't need this as bad as I thought. And nobody else seems to be
asking for it. Closing.

[Bug c++/65799] Allows constexpr conversion from cv void * to other type

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||eric at efcs dot ca

--- Comment #4 from Eric Fiselier  ---
Hi Jonathan,

Can you re-open this bug? GCC still accepts a number of conversions from void
that it shouldn't.

// g++ -std=c++2a 
float dummy = {};
static_assert((int*)(void*)&dummy);

https://godbolt.org/z/_DtmUc

[Bug c++/90383] New: [9 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)

[eric at efcs dot ca]

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

Bug ID: 90383
   Summary: [9 Regression] GCC generates invalid constexpr
copy/move assignment operators for types with trailing
padding. (Again)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

When a type has trailing padding GCC generates an invalid copy-assignment
operator for that type. (Similar to gcc.gnu.org/PR77945)

This time the copy assignment operator calls the default constructor, and does
not copy assign the value.

If the default constructor is deleted, GCC rejects-valid and the code fails to
compile. If the default constructor is available, GCC miscompiles the program.

This is a regression from the GCC 8.


Godbolt examples:
  * rejects-valid: https://godbolt.org/z/FGIyiM
  * miscompile: https://godbolt.org/z/7gL7iy

Reproducer:

// g++ -std=c++1z
struct alignas(8) data {
  constexpr data(bool) : value(true) {}

  // shouldn't be called. change to 'default' to see miscompile.
  data() = delete;

  bool value;
  // ... implicit padding ...
};

struct wrap { data member; };

constexpr bool always_true() {
wrap w{data(true)};
w.member = data(true);
return w.member.value; // should always return true
}

bool test() {
// emits-error {{use of deleted function 'data::data()'}}
// emits-note {{in 'constexpr' expansion of 'always_true()' }}
return always_true();

// returns 0 when miscompiled.
}

[Bug c++/90383] [9 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)

[eric at efcs dot ca]

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

--- Comment #1 from Eric Fiselier  ---
It's important to note that this bug affects any struct with tail padding. For
example `struct optional { T value; bool has_value; /*...*/ };` would hit it.

https://godbolt.org/z/VX9VTh

[Bug libstdc++/86595] New: directory_entry::refresh(error_code&) should be noexcept.

[eric at efcs dot ca]

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

Bug ID: 86595
   Summary: directory_entry::refresh(error_code&) should be
noexcept.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

According to the current specification, the error_code version of
directory_entry::refresh should be marked noexcept [1].

Libstdc++ incorrectly omits the `noexcept`.


[1] http://eel.is/c++draft/fs.dir.entry.mods#4

[Bug libstdc++/86597] New: directory_entry::exist et al forget to clear the error_code.

[eric at efcs dot ca]

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

Bug ID: 86597
   Summary: directory_entry::exist et al forget to clear the
error_code.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The "file type observers" of directory entry like exists and is_regular_file
don't clear the error code they are given when no errors occurs.

Reproducer:

#include 
#include 
using namespace std::filesystem;
using namespace std;

int main() {
error_code ec = make_error_code(errc::address_in_use);
directory_entry ent("/tmp");
assert(ent.exists(ec));
assert(!ec);
}

https://wandbox.org/permlink/TpQwW1VwBosGaHXZ

[Bug c++/86641] New: Regression: non-ODR used auto class data members fail to deduce.

[eric at efcs dot ca]

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

Bug ID: 86641
   Summary: Regression: non-ODR used auto class data members fail
to deduce.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

In some situations, GCC will fail to resolve the storage size of auto variables
which are not not directly ODR used:

For example:
// std=c++17
struct MyT {
constexpr MyT(long x) : value(x) {}
long value;
};

namespace {
template 
struct test_case {
  // error: storage size of '{anonymous}::test_case::value' isn't known
  static constexpr auto value = T(100);
  static constexpr T use_value = value;
};
}

test_case TC;

This only occurs in C++17 and newer. It seems to be a regression from GCC 8.x.
According to jwakely, this seems related to r260150.

[Bug c++/77923] GCC emits "declares nothing" diagnostic on meaningful declarations.

[eric at efcs dot ca]

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

--- Comment #1 from Eric Fiselier  ---
Ping. I keep hitting this more and more.

GCC seems to be warning because the declaration includes the CXX scope
specifier "::foo". Removing the "::" seems to work. However, removing the "::"
causes the code to take on a different semantic meaning.

The warning shouldn't be issued in either case.

[Bug c++/86678] New: constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[eric at efcs dot ca]

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

Bug ID: 86678
   Summary: constexpr evaluation incorrectly diagnoses unevaluated
call to non-constexpr function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:

#include 

template 
constexpr int foo() {
if (sizeof(T))
return 1;
assert(false && "BOOM!");
}

constexpr int V = foo();

[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
This is a bug according to [expr.const]p2 which states:

> An expression e is a core constant expression unless the evaluation of e, 
> following the rules of the abstract machine, would evaluate one of the 
> following expressions:
> [...]

The key phrase being "would evaluate one of". The example never evaluates a
non-constant expression. GCC correctly accepts the control flow:

template 
constexpr int foo() {
if (sizeof(T))
return 1;
else
  assert(false && "BOOM!");
}

template 
constexpr int bar() { return sizeof(T) ? 1 : throw 42; }

static_assert(foo() && bar());

In all both cases the unevaluated expressions do not cause constant evaluation
to fail.


[1] http://eel.is/c++draft/expr.const#2

[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[eric at efcs dot ca]

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

--- Comment #3 from Eric Fiselier  ---
The `if (1)` isn't essential either.

void fail();

template 
constexpr int foo() {
if (sizeof(T))
return 1;
fail();
}

constexpr int x = foo();

It seems to have something to do with whether the initial `if` statement is
fully covered, regardless of what's actually evaluated. (Note that the branches
of the initial `if` are evaluated, or not evaluated, correctly).

int fail();

template 
constexpr int foo() {
if (sizeof(T))
return 1;
else if (fail())
  fail(); // OK
   // Fallthrough is also OK
}

constexpr int x = foo();

[Bug c++/78489] Substitution failure does not happen in lexical order for NTTP declarations.

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
Created attachment 43737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43737&action=edit
reproducer2.cpp

Another reproducer: This one is a regression from 7.3
https://godbolt.org/g/UEti9f

Could somebody please take a look at this?

[Bug c++/87766] New: ICE using __PRETTY_FUNCTION__ in dependent context

[eric at efcs dot ca]

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

Bug ID: 87766
   Summary: ICE using __PRETTY_FUNCTION__ in dependent context
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

// g++ -std=c++1z test.cpp

template 
void test() {
[](auto rhs) { auto ptr = __PRETTY_FUNCTION__; }(42);
}
template void test<>();


The above code ICE's with the error:

internal compiler error: in output_constant, at varasm.c:4971

[Bug c++/87766] ICE using __PRETTY_FUNCTION__ in dependent context

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84925

--- Comment #1 from Eric Fiselier  ---
This doesn't appear to be fixed by gcc.gnu.org/PR84925.

It only seems to occur in GCC trunk and not GCC 8.1/8.2.

[Bug c++/69523] New: -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

Bug ID: 69523
   Summary: -Wliteral-suffix should not warn within namespace std
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37497&action=edit
reproducer.cpp

While developing for libc++ I enable warnings in the headers. Unfortunately
 always emits the warning:

> libcxx/include/string:4267:36: error: literal operator suffixes not preceded 
> by ‘_’ are reserved for future standardization [-Werror]

Obviously this is a false positive. Since the warning is on by default and
-Wno-literal-suffix doesn't disable it, then it needs to ignore user defined
literals within namespace std.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
@Andrew I'm a libc++ developer and I really like using compiler warnings when
developing and testing libc++. Using -isystem prevents this entirely. Normally
they are system headers but this is explicitly turned off during development.

[Bug c++/69701] New: "v.operator T()" incorrectly parsed if "v.T()" present.

[eric at efcs dot ca]

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

Bug ID: 69701
   Summary: "v.operator T()" incorrectly parsed if "v.T()"
present.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
      Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37603&action=edit
reprodu

If a class "B" provides a conversion operator to class "A" and a method named
"A", then trying to explicitly call B's conversion operator will fail to
compile.

I'm not exactly sure what the standard requires, but IMHO B::A shouldn't affect
calls to "b.operator A()" outside of the class body.

[Bug libstdc++/69703] New: char16_t conversions broken in filesystem::path

[eric at efcs dot ca]

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

Bug ID: 69703
   Summary: char16_t conversions broken in filesystem::path
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37605&action=edit
reproducer.cpp

Hi Jonathan,

While running the libc++ filesystem tests against libstdc++ I found that my
character conversion tests worked for wchar_t and char32_t but not char16_t.

IDK a lot about character encoding, so I apologize if the bug is on my end.

[Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
@Andrew The in-class diagnostics are pretty good. My concern is that users
outside the class cannot name the conversion operator. I don't think they care
that "A" changes meaning *within* B.

I don't think any error should be emitted for the reproducer.

[Bug libstdc++/70940] New: pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.

[eric at efcs dot ca]

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

Bug ID: 70940
   Summary: pmr::resource_adaptor requires optional allocator
requirements and incorrectly aligns returned pointers.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

resource_adapter incorrectly requires that the Allocator provide:
  * A pointer typedef.
  * A default constructor.

Furthermore it seems that do_allocate returns ill-aligned pointers. It seems
that do_allocate(s, a) returns the pointers from
'Allocator.allocate(...)' directly even though they have no alignment
guarantees.

[Bug libstdc++/70966] New: new_delete_resource() has deinit lifetime issues.

[eric at efcs dot ca]

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

Bug ID: 70966
   Summary: new_delete_resource() has deinit lifetime issues.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 38422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38422&action=edit
example.cpp

The value returned from 'new_delete_resource()' should be usable at all stages
of program startup and termination.

In the current implementation the static deinitialization order fiasco can
occur when a static object 'obj' is constructed before the first call to
'new_delete_resource()' and 'obj' references 'new_delete_resource()' in its
destructor.

[Bug libstdc++/71004] New: recursive_directory_iterator does not have a user-provided default ctor

[eric at efcs dot ca]

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

Bug ID: 71004
   Summary: recursive_directory_iterator does not have a
user-provided default ctor
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Hi Jonathan,

The default ctor provided for recursive_directory_iterator won't allow it to it
to be constructed as const.

// reproducer.cpp
#include 

int main() {
using namespace std::experimental::filesystem;
const recursive_directory_iterator endIt2;
}

[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor

[eric at efcs dot ca]

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

--- Comment #1 from Eric Fiselier  ---
Additionally this seems to be affecting the value returned from
"recursion_pending()". The following code compiles and runs without asserting
on my machine.

#include 
#include 

using namespace std::experimental::filesystem;

int main() {
recursive_directory_iterator it;
assert(it.recursion_pending() == false);
assert(it.recursion_pending() == true);
}

[Bug libstdc++/71005] New: recursive_directory_iterator::operator++(int) incorrectly implemented

[eric at efcs dot ca]

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

Bug ID: 71005
   Summary: recursive_directory_iterator::operator++(int)
incorrectly implemented
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Hi Jonathan,

The postfix increment operator returns the incremented value of the iterator,
not the previous one.

For example:

directory_iterator it(".");
path elem = *it;
path elem2 = *it++;
assert(elem == elem2); // fires

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

--- Comment #5 from Eric Fiselier  ---
Would it be possible to add a -Wno-literal-suffix flag? I really want to use
warning with GCC, but I need to disable this one.

[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor

[eric at efcs dot ca]

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

--- Comment #6 from Eric Fiselier  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Eric Fiselier from comment #1)
> > recursive_directory_iterator it;
> > assert(it.recursion_pending() == false);
> > assert(it.recursion_pending() == true);
> 
> N.B. This test is undefined, those observer functions have preconditions
> that they are not called on the end iterator.

That's true, my mistake.

[Bug libstdc++/71036] New: create_directory(p, ...) reports a failure when 'p' is an existing directory

[eric at efcs dot ca]

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

Bug ID: 71036
   Summary: create_directory(p, ...) reports a failure when 'p' is
an existing directory
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The create_directory functions should not report an error when the directory
they are trying to create already exists. The create_directory(...) functions
seem to report this error.

#include 
#include 

using namespace std::experimental::filesystem;

int main() {
  path p = "/tmp/foo";
  assert(!exists(p));
  create_directory(p); // create the directory once
  create_directory(p); // THROWS!
}

[Bug libstdc++/71037] New: Exceptions thrown from "filesystem::canonical(...)" should contain both paths.

[eric at efcs dot ca]

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

Bug ID: 71037
   Summary: Exceptions thrown from "filesystem::canonical(...)"
should contain both paths.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The filesystem error thrown from canonical only contains the first path, not
the base. Since the base path can be user specified the exception should
contain this as well.

#include 
#include 

using namespace std::experimental::filesystem;

int main() {
  const path p = "DNE"
  const path base = "BASE";
  try {
canonical(p, base);
assert(false);
  } catch (filesystem_error const& err) {
assert(err.path1() == p);
assert(err.path2() == base); // FIRES
  }
}

[Bug libstdc++/71038] New: copy_file(...) returns false on successful copy.

[eric at efcs dot ca]

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

Bug ID: 71038
   Summary: copy_file(...) returns false on successful copy.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The title says it all. copy_file always seems to return false.

Example:

#include 
#include 
#include 

using namespace std::experimental::filesystem;

int main() {
std::ofstream out("/tmp/foo.txt");
out << "hello world!\n";
out.close();
const path p = "/tmp/foo.txt";
const path to = "/tmp/bar.txt";
bool ret = copy_file(p, to);
assert(ret == true);
}

[Bug inline-asm/71246] New: "+g" assembly constraint causes error: inconsistent operand constraints in an 'asm'

[eric at efcs dot ca]

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

Bug ID: 71246
   Summary: "+g" assembly constraint causes error: inconsistent
operand constraints in an 'asm'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
      Reporter: eric at efcs dot ca
  Target Milestone: ---

The following code fails to compile with the error "inconsistent operand
constraints in an 'asm'". It seems to also be triggered when the constrain is
stated as "+rm" which makes more sense.

Previous versions of GCC ICE'd on this code.

template 
inline __attribute__((__always_inline__)) 
void DoNotOptimize(Tp const& value) {
asm volatile("" : "+g" (const_cast(value)));
}

struct Foo {
  int Arr[42];
};

void test2() {
  Foo f = {};
  DoNotOptimize(f);
}

There are a couple of similar bugs but I'm not certain they are duplicates so
I'm filing this separately.

[Bug libstdc++/71320] New: filesystem::permissions does not respect add_perms/remove_perms

[eric at efcs dot ca]

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

Bug ID: 71320
   Summary: filesystem::permissions does not respect
add_perms/remove_perms
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 38585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38585&action=edit
reproducer.cpp

filesystem::permissions ignores add_perms and remove_perms, instead always
setting the file permissions to the specified value.

For example:

permissions(file, perms::owner_all);
assert(status(file).permissions() == perms::owner_all); // works

// Add some additional permissions
permissions(file, perms::group_all | perms::add_perms);
assert(status(file).permissions() == (perms::owner_all | perms::group_all)); //
FIRES
assert(status(file).permissions() == perms::group_all); // Doesn't fire

[Bug libstdc++/71322] New: std::filesystem::permissions always follows symlinks

[eric at efcs dot ca]

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

Bug ID: 71322
   Summary: std::filesystem::permissions always follows symlinks
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 38586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38586&action=edit
repr

Currently "permissions(sym, perms::none)" resolves the symlink and sets the
permissions on the file. I believe this is incorrect.

[Bug libstdc++/71337] New: temp_directory_path(error_code&) shouldn't throw from !exists(p) || !is_directory(p)

[eric at efcs dot ca]

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

Bug ID: 71337
   Summary: temp_directory_path(error_code&) shouldn't throw from
!exists(p) || !is_directory(p)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Most of the time these two function will not throw. However if 'p' points to a
directory that the user doesn't have permission to read then they will.

For example:

create_directories("/tmp/foo/bar");
permissions("/tmp/foo", perms::none);
setenv("TMPDIR", "/tmp/foo/bar", 1);
std::error_code ec;
temp_directory_path(ec); // THROWS!

[Bug c++/71376] New: __cpp_noexcept_function_type feature test macro not defined.

[eric at efcs dot ca]

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

Bug ID: 71376
   Summary: __cpp_noexcept_function_type feature test macro not
defined.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

GCC has recently implemented "noexcept as part of the type system" but the
feature test macro is not defined.

Reproducer:

void foo() noexcept {}

int main() {
auto fn = &foo;
#if !defined(__cpp_noexcept_function_type)
static_assert(noexcept(fn()) == false, "");
 #else
static_assert(noexcept(fn()), "");
#endif
}

[Bug c++/71537] New: GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[eric at efcs dot ca]

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

Bug ID: 71537
   Summary: GCC rejects consetxpr boolean conversions and
comparisons on the result of pointer arithmetic.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

For example:

constexpr int n[42] = {1};
constexpr int x = n ? 1 : 0; // Accepted.
constexpr int xx = n + 1 ? 1 : 0; // Rejected
constexpr int xxx = "abc" + 1 ? 1 : 0; // Also Rejected

This has a significant impact on constexpr algorithms which operate over raw
pointers since pointer comparisons are not considered constant expressions.

For example this bug breaks libc++'s implementation of string_view::find and
renders the "char_traits::find(...)" interface useless since it returns a
possibly null pointer.

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
Hi Martin,

The  'xx' case is only accepted if it occurs at a global scope. If it appears
in a function body it is still rejected.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

--- Comment #7 from Eric Fiselier  ---
> The warning should be controlled by *some* flag, but I'm not sure whether or 
> not linking it with -Wliteral-suffix makes sense. I'll prepare a patch and 
> see what people think.

Any update? I would be happy with anything so long as I can enable warnings
again.

[Bug libstdc++/80448] New: #include fails with Clang 5.0

[eric at efcs dot ca]

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

Bug ID: 80448
   Summary: #include  fails with Clang
5.0
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Simply including  fails to compile when using Clang.
The first error in the stack is:

/opt/gcc-tot/lib/gcc/x86_64-pc-linux-gnu/7.0.1/../../../../include/c++/7.0.1/experimental/bits/fs_dir.h:265:5:
error: default member initializer for '_M_options' needed within definition of
enclosing
  class 'recursive_directory_iterator' outside of member functions
recursive_directory_iterator() noexcept = default;

The complete reproducer is:

// clang++ -std=c++1z -fsyntax-only --gcc-toolchain=/opt/gcc-tot test.cpp
// test.cpp
#include 

[Bug c++/80465] New: [7 Regression] ICE when evaluating a lamba noexcept spec with captures in C++1z

[eric at efcs dot ca]

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

Bug ID: 80465
   Summary: [7 Regression] ICE when evaluating a lamba noexcept
spec with captures in C++1z
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:
// g++ -fsyntax-only -std=c++1z test.cpp
int foo(...);
int main() {
  [](auto a) noexcept(noexcept(foo(a))){}(42);
}

The ICE gives the message: internal compiler error: in nothrow_spec_p, at
cp/except.c:1159

Note that this is a regression and does not occur with GCC 6 with -std=c++1z.

[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||eric at efcs dot ca

--- Comment #1 from Eric Fiselier  ---
Note that the instantiation is not spurious, but instead required by the core
language. All overloads of _Bind::operator() are considered during the call to
the forwarding call wrapper.

While considering the const qualified overload the compiler is forced to
instantiate the lambda to deduce the return type. This causes a error in a
non-immediate context which causes the compile error.

[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
Note that explicitly providing a return type for the lambda avoids this compile
error. Example:

---
#include 

int main() {
int i;
std::bind([] (auto& x) -> void {x = 1;}, i)(); // OK!
}

---

[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

[eric at efcs dot ca]

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

--- Comment #3 from Eric Fiselier  ---
Here is an example of why `_Bind::operator()(...) const` must be considered
during overload resolution even if the call wrapper itself is not const.

--
#include 

struct Func {
  template 
  void operator()(Args&&...) = delete;

  template 
  void operator()(Args&&...) const {}
};

int main() {
Func f;
std::bind(f)();
}
-

[Bug c++/80682] New: __is_trivially_constructible(void, int) returns true.

[eric at efcs dot ca]

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

Bug ID: 80682
   Summary: __is_trivially_constructible(void, int) returns true.
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:

// g++ -std=c++11 -fsyntax-only
static_assert(!__is_trivially_constructible(void, int), "");

This seems blatantly incorrect.

[Bug c++/68905] [DR496] __is_trivially_copyable returns True for volatile class types.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Eric Fiselier  ---
DR 496 has been superseded by DR2094 which requires the behavior GCC currently
has:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2094

Closing as INVALID.

[Bug c++/78488] New: ICE when building call to inherited default constructor.

[eric at efcs dot ca]

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

Bug ID: 78488
   Summary: ICE when building call to inherited default
constructor.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

GCC ICE's when default initializing a type T when T's default constructor is an
inherited constructor. Note that this only happens when T doesn't define its
own default ctor, either implicitly or explicitly.

The below reproducer is rejected by GCC 5.3 and earlier. GCC 6 exits with
status 1 and without producing any diagnostics or an output file, and GCC 7
segfaults.

Reproducer: 

// g++ -std=c++1z test.cpp
struct Foo { Foo() {} };

struct Bar : Foo {
  using Foo::Foo;
  Bar(void*); // Define another constructor so Foo() isn't generated.
};

int main() {
 Bar f;
}

[Bug c++/78488] ICE when building call to inherited default constructor.

[eric at efcs dot ca]

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

--- Comment #1 from Eric Fiselier  ---
>  GCC 6 exits with status 1 and without producing any diagnostics or an output 
> file

Disregard that I was using a broken GCC 6. IDK how GCC 6 handles this bug.

[Bug c++/78489] New: Subsitution failure does not happen in lexical order for SFINAE in NTTP.

[eric at efcs dot ca]

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

Bug ID: 78489
   Summary: Subsitution failure does not happen in lexical order
for SFINAE in NTTP.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

When substitution failure occurs in the declaration of a NTTP GCC
will incorrectly continue to perform substitution on later template
parameters. This is incorrect since substitution should occur in
lexical order. Note that this does not occur when the substitution
happens in the declaration of a type template parameter.


Reproducer:
// g++ -std=c++1z test.cpp
template  struct enable_if { typedef T type; };
template  struct enable_if {};

template  struct blows_up { static_assert(Idx != Idx, ""); };

template ::type = 0,
  // GCC evaluates this statement
  class = typename blows_up::type 
>
void Foo() {}

template ::type,
  class = typename blows_up::type // OK. Not evaluated
>
constexpr void Bar() {}
// Check the constructor in as SFINAE context
template  constexpr auto test(int) -> decltype((Foo(), true)) {
return true; }
templateconstexpr bool test(long) { return false; }

template  constexpr auto test_bar(int) -> decltype((Bar(), true)) {
return true; }
templateconstexpr bool test_bar(long) { return false; }

static_assert(!test<3>(0), ""); // Blows up
static_assert(!test_bar<4>(0), ""); // OK.

[Bug c++/78489] Substitution failure does not happen in lexical order for SFINAE in NTTP.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

Summary|Subsitution failure does|Substitution failure does
   |not happen in lexical order |not happen in lexical order
   |for SFINAE in NTTP. |for SFINAE in NTTP.

--- Comment #1 from Eric Fiselier  ---
Substitution

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||eric at efcs dot ca

--- Comment #9 from Eric Fiselier  ---
Bump. This should get fixed as it's not just wrong-code but also
accepts-invalid and rejects-valid.

The relevant wording from the standard:

C++1z [expr.cond]p2:
> (2) If either the second or the third operand has type void,
> one of the following shall hold:
> (2.1) The second or the third operand (but not both) is a
>   (possibly parenthesized) throw-expression (5.17); the result
>   is of the type and value category of the other.

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #3 from Eric Fiselier  ---
Ping and CC Jason the Wizard. This is needed to implement C++17 constexpr
char_traits (See wg21.link/P0426R1).

[Bug libstdc++/78441] [variant] variant_alternative doesn't allow cv qualifiers

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Fiselier  ---
Closing as RESOLVED FIXED based on the last comment.

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Eric Fiselier  ---
> Ping and CC Jason the Wizard. This is needed to implement C++17 constexpr 
> char_traits (See wg21.link/P0426R1).

Same as above but correctly CC Jason.

[Bug c++/55004] [meta-bug] constexpr issues

[eric at efcs dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 71537, which changed state.

Bug 71537 Summary: GCC rejects consetxpr boolean conversions and comparisons on 
the result of pointer arithmetic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537

   What|Removed |Added

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

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #17 from Eric Fiselier  ---
This has not been fixed. As mentioned the original reproducer still fails to
compile when it appears at block scope:

// g++ -std=c++1z test.cpp
constexpr bool foo() {
  constexpr int n[42] = {1};
  constexpr int x = n ? 1 : 0; // Accepted.
  constexpr int xx = n + 1 ? 1 : 0; // Rejected
  constexpr int xxx = "abc" + 1 ? 1 : 0; // Newly accepted.
  return true;
}

int main() { static_assert(foo(), ""); }

[Bug libstdc++/78723] New: [variant] P0393r3: "Making variant greater equal again" is unimplemented

[eric at efcs dot ca]

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

Bug ID: 78723
   Summary: [variant] P0393r3: "Making variant greater equal
again" is unimplemented
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Link to paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0393r3.html

Reproducer:
// g++ -std=c++1z test.cpp
#include 
#include 
#include 

struct MakeEmptyT {
  MakeEmptyT() = default;
  MakeEmptyT(MakeEmptyT &&) { throw 42; }
  MakeEmptyT &operator=(MakeEmptyT &&) { throw 42; }
};
inline bool operator<(const MakeEmptyT &, const MakeEmptyT &) {
  assert(false);
  return false;
}

template  void makeEmpty(Variant &v) {
  Variant v2(std::in_place_type);
  try {
v = std::move(v2);
assert(false);
  } catch (...) {
assert(v.valueless_by_exception());
  }
}

int main() {
using V = std::variant;
V v1;
V v2;
makeEmpty(v2);
assert((v1 < v2) == false);
}

[Bug libstdc++/78723] [variant] P0393r3: "Making variant greater equal again" is unimplemented

[eric at efcs dot ca]

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

--- Comment #3 from Eric Fiselier  ---
The joke title was a lot funnier a year ago.

[Bug libstdc++/79384] New: Clang doesn't like variant's std::visit

[eric at efcs dot ca]

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

Bug ID: 79384
   Summary: Clang doesn't like variant's std::visit
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The following example doesn't compile when using Clang to target libstdc++

Minimal reproducers:

// clang++ -std=c++1z test.cpp
#include 
int main()
{
  std::visit([](auto&&) { }, std::variant());
}

Example output:

https://godbolt.org/g/kSmBTg

[Bug c++/79452] Provide builtin to detect compile-time execution

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||eric at efcs dot ca

--- Comment #7 from Eric Fiselier  ---
There are definitely opportunities for ODR violations here, or at least
something like them. Consider the following case:

template 
constexpr bool foo(T) {
  if constexpr(__ctfe__)
return true;
  else
return false
}

static_assert(foo(0));
auto runtime = foo(0);

Both calls instantiate foo with the same template arguments, so they should
seemingly both get the same instantiation with the w/e value of `__ctfe__` was
when the implicit instantiations occurred. Therefore one of the two calls to
foo() will return the wrong answer.

This problem is made ever worse if `__builtin_constant_expression` allows you
to generate non-dependent compile-time expressions based on the function
arguments.

One solution would be to consider the instantiation of `foo` to be value
dependent on a "implicit template parameter" representing `__ctfe__`.

[Bug c++/79452] Provide builtin to detect compile-time execution

[eric at efcs dot ca]

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

--- Comment #9 from Eric Fiselier  ---
I think it would be nice to be able to dispatch differently depending on being
called at compile time or runtime. However the ability to dispatch on that
condition doesn't have to be usable in "if constexpr". That way we don't run
into any instantiation problems.

If that behavior is desireable enough I think it could be simply implemented as
an invented __ctfe__ function local variable that changes value.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Fiselier  ---
It appears as though this patch was never applied, or it was applied and then
reverted.

Re-opening for a new, permanent, solution.

[Bug libstdc++/77495] New: optional assignment from {} acts weirdly

[eric at efcs dot ca]

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

Bug ID: 77495
   Summary: optional assignment from {} acts weirdly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Assignment to optional from {} acts differently depending on if 'T' can be
constructed from {} without a used defined conversion. If so then then
operator=(U&&) is selected. Otherwise operator=(optional&&) is selected after
converting {} to optional.

Reproducer:

#include 
#include 

using namespace std;

struct T { T() = default; };

int main() {
optional oi(in_place);
oi = {}; // converts {} to int because conversion isn't user defined.
assert(oi.has_value() == true);
optional ot(in_place);
ot = {}; // converts {} to optional then calls operator=(optional&&)
assert(ot.has_value() == false);
}

[Bug c++/77923] New: GCC emits "declares nothing" diagnostic on meaningful declarations.

[eric at efcs dot ca]

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

Bug ID: 77923
   Summary: GCC emits "declares nothing" diagnostic on meaningful
declarations.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

I ran into this error defining a typedef for "struct ::stat" where "stat" names
both a function and type on POSIX systems.

Reduced reproducer:
// g++ -std=c++14 -Werror test.cpp
struct foo {};
void foo() {}
using FooType = struct ::foo; // emits error {{declaration 'struct ::foo' does
not declare anything}}

[Bug c++/77945] New: GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[eric at efcs dot ca]

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

Bug ID: 77945
   Summary: GCC generates invalid constexpr copy/move assignment
operators for types with trailing padding.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The copy/move assignment operators generated by GCC result in compile time
error when used in a constant expression if the type contains trailing padding
bytes (but one bytes between members).

Reproducer:
// g++ -std=c++1z test.cpp
struct OK {
  char no_padding = 0;
  constexpr OK() {}
};
static_assert((OK{} = OK{}, true), "");

struct T {
  alignas(2) char with_padding = 0;
  constexpr T() {}
};
// emits-error {{non-constant condition in static assert}}
// emits-error {{error accessing value of '' through a 'char [1]'
glvalue in a constant expression}}
static_assert((T{} = T{}, true), "");

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Fiselier  ---
This bug has been fixed by adding -Wno-literal-suffix. Thanks.

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[eric at efcs dot ca]

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

--- Comment #3 from Eric Fiselier  ---
> if the type contains trailing padding bytes (but one bytes between members).

The last bit is nonsense. I meant to say that padding between members seemed
OK.

[Bug c++/77999] New: GCC leaks system header diagnostic about reserved names.

[eric at efcs dot ca]

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

Bug ID: 77999
   Summary: GCC leaks system header diagnostic about reserved
names.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:
// g++ -std=c++14 -Werror test.cpp
#include 
using std::chrono::operator ""h; // error emitted on this line.
// {{error: literal operator suffixes not preceded by '_' are reserved for
future standardization}}

[Bug libstdc++/78441] New: [variant] variant_alternative doesn't allow cv qualifiers

[eric at efcs dot ca]

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

Bug ID: 78441
   Summary: [variant] variant_alternative doesn't allow cv
qualifiers
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The below reproducer fails to compile.

// Reproducer
#include 

using V = std::variant;
using T = std::variant_alternative_t<0, const V>;
static_assert(std::is_same_v, "");

[Bug libstdc++/78442] New: [variant] std::get<...>(Variant) is not constexpr.

[eric at efcs dot ca]

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

Bug ID: 78442
   Summary: [variant] std::get<...>(Variant) is not constexpr.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

See the below reproducer:

#include 

constexpr bool test() {
  std::variant v(42);
  auto const& cv = v;
  static_assert(std::get<0>(v) == 42, "");
  static_assert(std::get<0>(cv) == 42, "");
  return true;
}
static_assert(test(), "");

int main() {}

[Bug libstdc++/78442] [variant] std::get<...>(Variant) is not constexpr.

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
I'm sorry your right. That's a garbage reproducer. Here's an actual one:

#include 
#include 

constexpr bool test_tuple() {
 std::tuple t(42);
 return std::get<0>(t) == 42;
}
static_assert(test_tuple(), ""); // OK

constexpr bool test() {
  std::variant v(42);
  auto const& cv = v;
  return std::get<0>(v) == 42 &&
 std::get<0>(cv) == 42; 

}
static_assert(test(), "");

[Bug c++/66150] New: [C++11] cv-qualifiers on function types are not ignored.

[eric at efcs dot ca]

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

Bug ID: 66150
   Summary: [C++11] cv-qualifiers on function types are not
ignored.
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Currently GCC does not ignore cv-qualifiers applied to a function type.

Example:

typedef void T();
static_assert(std::is_same::value, "");

According to the C++11 standard:
[dcl.fct]p7:
The effect of a cv-qualifier-seq in a function declarator is not the
same as adding cv-qualification on top of the function type. In the
latter case, the cv-qualifiers are ignored.

[Bug c++/66150] [C++11] cv-qualifiers on function types are not ignored.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Fiselier  ---
Woops... Everybody is right. GCC correctly handled this code. I'm not sure how
I came to think this was failing.

Sorry.

[Bug c++/68905] New: __is_trivially_copyable returns True for volatile class types.

[eric at efcs dot ca]

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

Bug ID: 68905
   Summary: __is_trivially_copyable returns True for volatile
class types.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37034&action=edit
reproducer.cpp

The __is_trivially_copyable builtin returns true for volatile qualified
trivially copyable class types. However the current C++ draft says:

3.9[basic.types] p9 says:
> Cv-unqualified scalar types, trivially copyable class types (Clause 9),
> arrays of such types, and non-volatile const-qualified versions of these 
> types (3.9.3) are collectively called trivially copyable types.

I believe it should return false for any volatile qualified type.

[Bug c++/68929] New: GCC hangs in nested template instantiations even after static_assert fails.

[eric at efcs dot ca]

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

Bug ID: 68929
   Summary: GCC hangs in nested template instantiations even after
static_assert fails.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

GCC currently hangs when compiling the attached reproducer. The reproducer is a
stripped down libc++ test that ensures that  "std::make_integer_sequence" causes a static assertion. 

GCC will emit the assertion but then continue to run and consume more memory
until its killed for being OOM.

[Bug c++/68929] GCC hangs in nested template instantiations even after static_assert fails.

[eric at efcs dot ca]

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

--- Comment #1 from Eric Fiselier  ---
Created attachment 37044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37044&action=edit
reproducer.cpp

standalone reproducer

[Bug c++/68975] New: Request: Provide alternate keyword for decltype in C++03

[eric at efcs dot ca]

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

Bug ID: 68975
   Summary: Request: Provide alternate keyword for decltype in
C++03
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

`__typeof__` does not make a good replacement for `decltype` because it doesn't
deduce references. It would be nice if decltype were provided under an
alternate keyword in C++03 and earlier.

[Bug c++/69372] New: GCC allows array and function types to be caught by reference.

[eric at efcs dot ca]

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

Bug ID: 69372
   Summary: GCC allows array and function types to be caught by
reference.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37396&action=edit
reproducer for array types

The current C++ draft states:

[expr.throw]/p2 states:
> Evaluating a throw-expression with an operand throws an exception (15.1); the 
> type of the exception object
> is determined by removing any top-level cv-qualifiers from the static type of 
> the operand and adjusting the
> type from “array of T” or function type T to “pointer to T”.

Therefore it should not be possible to catch a function or array by reference.
However GCC allows this.

[Bug c++/69372] GCC allows array and function types to be caught by reference.

[eric at efcs dot ca]

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

--- Comment #1 from Eric Fiselier  ---
Created attachment 37397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37397&action=edit
reproducer for function types

attached a reproducer for function types.

[Bug c++/69373] New: GCC emits incorrect warning that "exception of type ‘void (*)()’ will be caught by earlier handler for 'void*'"

[eric at efcs dot ca]

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

Bug ID: 69373
   Summary: GCC emits incorrect warning that "exception of type
‘void (*)()’ will be caught by earlier handler for
'void*'"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
      Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37398&action=edit
reproducer

Since function pointers cannot be converted to void* this warning is incorrect
and the "void*" catch site will not be selected.

[Bug c++/69375] New: GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const"

[eric at efcs dot ca]

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

Bug ID: 69375
   Summary: GCC allows PMF type "void (T::*)()" to be caught as
"void (T::*)() const"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
      Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37399&action=edit
reproducer

I don't see where [except.handle] allows such a conversion.

[Bug c/69425] New: __atomic_load should diagnose const output parameter

[eric at efcs dot ca]

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

Bug ID: 69425
   Summary: __atomic_load should diagnose const output parameter
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The __atomic_load builtin takes a pointer to an output parameter. Obviously the
output parameter cannot point to a const object. Unfortunatly GCC doesn't
diagnose this case at compile time and this makes it much harder for users to
find their bug. 

The reproducer is contrived, but I ran into this while writing generic code.

#include 

int main() {
  const int source = 4;
  const int dest = 0;
  __atomic_load(&source, &dest, __ATOMIC_RELAXED); // Should emit
-Wdiscards-qualifiers
  assert(dest == 4); // FAILS! 'dest' is still 0.
}

[Bug c++/71376] __cpp_noexcept_function_type feature test macro not defined.

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
I was wrong about the "GCC has recently implemented "noexcept as part of the
type system"" part.  Closing as invalid.

[Bug c++/71376] __cpp_noexcept_function_type feature test macro not defined.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Fiselier  ---
I was wrong about the "GCC has recently implemented "noexcept as part of the
type system"" part.  Closing as invalid.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

--- Comment #8 from Eric Fiselier  ---
Created attachment 39069
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39069&action=edit
fix.patch

Add a suggested fix with make -Wno-literal-suffix suppress the reserved
identifier warnings.

@Jonathan Could you help me land this?

[Bug c++/116490] New: Crash in explicitly instantiated Function Contracts

[eric at efcs dot ca via Gcc-bugs]

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

Bug ID: 116490
   Summary: Crash in explicitly instantiated Function Contracts
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 59005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59005&action=edit
stack trace

```
// g++ -fcontracts  -std=c++26
template
void foo()
[[pre : T{}]] { 
}

template void foo(); 
```

The above code causes GCC to crash, please see the attached stack trace for
details of the crash.