[Bug sanitizer/107963] Support __attribute__((disable_sanitizer_instrumentation))

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc/2021-November/237787.html

If I read this correctly, there is no reason for a new attribute for gcc.

[Bug c/107963] New: Support __attribute__((disable_sanitizer_instrumentation))

[i at maskray dot me via Gcc-bugs]

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

Bug ID: 107963
   Summary: Support
__attribute__((disable_sanitizer_instrumentation))
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

Clang introduced the attribute in https://reviews.llvm.org/D108029 (2021-08).
It disables instrumentations for all kinds of sanitizers.
For non-memory sanitizers, it's like the union of all available
no_sanitize("xxx").
For msan, it disables all instrumentations, therefore the following function
does not unpoison the shadow for *a, which may lead to a false positive for a
subsequent function
(https://clang.llvm.org/docs/MemorySanitizer.html#attribute-disable-sanitizer-instrumentation).
That said, such functionality is useful in some scenarios, e.g. `noinstr` in
the Linux kernel
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9b448bc25b776daab3215393c3ce6953dd3bb8ad)

__attribute__((disable_sanitizer_instrumentation)) int foo(int *a) {
  *a = 42;
  return *a;
}

[Bug bootstrap/105474] GCC fails to bootstrap with --disable-libstdcxx

[creatorsmithmdt at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Zopolis0  ---
If disabling the stdlib but not disabling bootstrapping causes bootstrapping to
break, the user should probably be notified of this before it breaks randomly.

[Bug tree-optimization/71383] Misoptimized branch with inline assembly code.

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
If you marked the variable as used the branch comes back.
This definitely should be referenced too.
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Variable-Attributes.html#index-used-variable-attribute

[Bug c/107738] Top-level inline-asm is not well documented

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-04
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Looks like there was some movement in the past about this:
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-12/msg01184.html
(I have not looked into the replies though).

[Bug middle-end/33932] miscalculation of asm labels with -g3

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||miladfarca at gmail dot com

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

[Bug c/107736] call to a function, generated by inline asm, is off by one byte

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #6 from Andrew Pinski  ---
Dup of bug 33932.

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

[Bug translation/89915] clean up and canonicalize wording in params.def

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||internal-improvement
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-04

--- Comment #5 from Andrew Pinski  ---
>* some parameter descriptions still contain redundant comments. I complained 
>about this one year ago in #79632, but nothing has happened since then.

That was fixed in GCC 10 when they were moved to param.opt.


To expand on this part here:
> params should be considered as internal options which only should be used for 
> debugging and not even documented in the normal documentation.

The documentation in invoke.texi has the following:
```
@item --param @var{name}=@var{value}
@opindex param
In some places, GCC uses various constants to control the amount of
optimization that is done.  For example, GCC does not inline functions
that contain more than a certain number of instructions.  You can
control some of these constants on the command line using the
@option{--param} option.

The names of specific parameters, and the meaning of the values, are
tied to the internals of the compiler, and are subject to change
without notice in future releases.
```

Now saying that, the descriptions in params.opt could use improvements as I
mentioned before so confirmed.

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[nruslan_devel at yahoo dot com via Gcc-bugs]

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

--- Comment #10 from Ruslan Nikolaev  ---
The latter example seems to work well for both gcc and clang. The behavior is
also consistent for both explicit and implicit constructors.

Thank you for clarifying that it was not a bug!

[Bug c++/107962] GCC allows constexpr copy construction despite uninitialized member

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-04
 Ever confirmed|0   |1

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

[Bug middle-end/79632] params.def should not contain redundant comments

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |10.0
 Resolution|--- |FIXED
   Keywords||internal-improvement

--- Comment #3 from Andrew Pinski  ---
Fixed for GCC 10 by the patch set that converts params.def into params.opt.

r10-4558-g76c26af90ea3af
r10-4559-g7e1792c953ec54
r10-4560-g028d409252058d
r10-4561-g0c29cac4a8cc84
r10-4562-g8cc5fcaf1f04f8
r10-4563-g11b5ca6eb718c8
r10-4564-g75d6623156d3e6
r10-4565-g8100e93b72dfe8
r10-4566-g6ed760441a35e3

[Bug c++/107962] New: GCC allows constexpr copy construction despite uninitialized member

[hstong at ca dot ibm.com via Gcc-bugs]

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

Bug ID: 107962
   Summary: GCC allows constexpr copy construction despite
uninitialized member
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

Lvalue-to-rvalue conversion of objects having indeterminate value is not
allowed during evaluation of a core constant expression (see N4919 subclause
7.7 [expr.const] bullet 5.11). GCC allows such lvalue-to-rvalue conversion
during the constant evaluation of trivial copy constructors.

In the case below, the `y` member of `a` has indeterminate value when the
initialization of `b` is performed. Clang and ICC correctly diagnose the issue.

Compiler Explorer link: https://godbolt.org/z/afq1h895a

### SOURCE ():
struct A {
  int x, y;
  constexpr A() {}
};

constexpr int f() {
  A a;
  a.x = 42;
  A b = a;
  return b.x;
}

extern constexpr int x = f();


### COMPILER INVOCATION:
g++ -xc++ -fsyntax-only -std=c++2a -


### ACTUAL OUTPUT:
(Clean compile)


### EXPECTED OUTPUT:
(Error that `x` is not initialized by a constant expression)


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221202 (experimental) (GCC)

[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
r0-92283-g839a3b8ab591c7

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[nruslan_devel at yahoo dot com via Gcc-bugs]

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

--- Comment #9 from Ruslan Nikolaev  ---
Interestingly, if I change the code a little bit and have a pair in the
constructor rather than two arguments, gcc seems to compile the code:

#include 
#include 

struct PairPtr {

PairPtr() {}

PairPtr(const PairPtr &s) {
a = s.a;
b = s.b;
}

explicit PairPtr(const std::pair& pair) {
a = pair.first;
b = pair.second;
}

PairPtr& operator=(const PairPtr &s) {
a = s.a;
b = s.b;
return *this;
}

PairPtr& operator=(const std::pair& pair) {
a = pair.first;
b = pair.second;
return *this;
}

private:
int *a;
int *b;
};

void func(int *a, int *b)
{
PairPtr p({a,b}); // works

p = { a, b }; // also works
}

[Bug c/107961] BFloat16 types are not documented in "Half-Precision Floating Point"

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]   |BFloat16 types are not
   |BFloat16 types are not  |documented in
   |documented in   |"Half-Precision Floating
   |"Half-Precision Floating|Point"
   |Point"  |

--- Comment #1 from Andrew Pinski  ---
Note GCC 11 added support for bf16 for aarch64 but GCC 13 adds it for x86_64
and supports all operations and not just as a storage type.

[Bug c/107961] New: [11/12/13 Regression] BFloat16 types are not documented in "Half-Precision Floating Point"

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107961
   Summary: [11/12/13 Regression] BFloat16 types are not
documented in "Half-Precision Floating Point"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64 x86_64

I noticed that the "Half-Precision Floating Point" part of the C extensions
(https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html) don't document at all
the BFloat16 types. 

Especially now BFloat16 is not just a storage type, it can be used like a
normal type (on x86_64 at least; on aarch64 that is not true yet, referenced in
PR 107703).

[Bug bootstrap/107960] New: opt-gather.awk seems to ignore lines lines that start with whitespace

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107960
   Summary: opt-gather.awk seems to ignore lines lines that start
with whitespace
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

echo -e "aaa\n a\n  a\na" | awk -f opt-gather.awk > t.txt

and then look at the result of t.txt and notice that only aaa^\a is in the
file.

No error message happens either.

The code in the old opts.sh (which is still the awk script) was broken too.


The problem is here:
/^[ \t]*(;|$)/  { flag = 0; next }
/^[^ \t]/   { if (flag == 0) {

Notice how that the pattern is matching all lines that don't start with white
space.

Also notice how a comment is considered a record seperator too. 

Neither of this is documented either.

The documentation for comments is:
Comments may appear on their own line anywhere within the file and are preceded
by semicolons. 

Which to mean it in the middle of a record but the code does not allow that.
Have the ability of the "white space" in the front being a comment inside the
record is a nice feature but I do think it should be documented though.

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to fail||6.5.0
 CC||jason at gcc dot gnu.org
  Known to work||7.5.0
   Target Milestone|--- |7.0
 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Jason Merrill  ---
(In reply to Aso Renji from comment #15)
> No, this warning still appear if (and only if) you use -O2 or -O3
> optimization key (as it be in startpost with "g++ -O3 -Wstrict-aliasing
> test.cc -o /dev/null" line).

I don't see this with any compiler after 6.5.0.

[Bug libstdc++/107940] temp_directory_path testcase broken

[laurent.alfonsi at linaro dot org via Gcc-bugs]

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

laurent.alfonsi at linaro dot org  changed:

   What|Removed |Added

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

--- Comment #8 from laurent.alfonsi at linaro dot org  ---
(In reply to Andrew Pinski from comment #7)
> 
> The uninitialized memory dealing with the stack unwinding is recorded as PR
> 107678 and a patch was sent here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607668.html (maybe
> that will fix the issue recorded here too).

Introducing fix pointed in PR107678 well fixes the crash I am observing.

However, I m not able to ensure the problem is fully fixed. Because, The
valgrind uninit issues I was observing when building in -static are still
present. As far as i have seen, crash not exposed in -static [chance?].

I proposed to mark it as duplicate of 107678.

Thanks Andrew, Thanks Prathamesh.

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

[Bug target/107678] [13 Regression] Segfault in aarch64_fallback_frame_state when running SVE code

[laurent.alfonsi at linaro dot org via Gcc-bugs]

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

laurent.alfonsi at linaro dot org  changed:

   What|Removed |Added

 CC||laurent.alfonsi at linaro dot 
org

--- Comment #7 from laurent.alfonsi at linaro dot org  ---
*** Bug 107940 has been marked as a duplicate of this bug. ***

[Bug fortran/107870] A possible typo in the documentation of 'FLOOR'

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058567.html

[Bug c++/60027] Problem with braced-init-lists and explicit ctors

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/28016

--- Comment #8 from Andrew Pinski  ---
Note clang accepting this code is recorded as
https://github.com/llvm/llvm-project/issues/28016 .

[Bug c++/60027] Problem with braced-init-lists and explicit ctors

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||konstantin.vladimirov@gmail
   ||.com

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

[Bug c++/97220] Overload resolution works wrong when implicit conversion not exists

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #4 from Andrew Pinski  ---
Dup of bug 60027.

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

[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---


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

[Bug c++/60027] Problem with braced-init-lists and explicit ctors

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ldionne.2 at gmail dot com

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

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #8 from Andrew Pinski  ---
Dup of bug 60027.

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

[Bug c++/60027] Problem with braced-init-lists and explicit ctors

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||nruslan_devel at yahoo dot com

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

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
   See Also||https://github.com/llvm/llv
   ||m-project/issues/28016

--- Comment #7 from Andrew Pinski  ---
Yes https://github.com/llvm/llvm-project/issues/28016 is the clang bug which
shows GCC is correct.  This is also
https://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#1228 .

So clang is wrong in accepting the code as not ambiguous .

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> I think GCC and MSVC are correct here:
> [over.match.list]/16.3.1.7
> . In copy-listinitialization, if an explicit constructor is chosen, the
> initialization is ill-formed. [ Note: This differs from
> other situations (16.3.1.3, 16.3.1.4), where only converting constructors
> are considered for copy-initialization.
> This restriction only applies if this initialization is part of the final
> result of overload resolution. — end note ]
> 
> 
> Even though the note is techincally not part of the standard, it describes
> why clang is wrong here. That is the explicit constructors are used too to
> figure out the overload and only if there was no ambiguous, it would be
> considered as ill-formed.

Also see clang bug https://github.com/llvm/llvm-project/issues/28016

[Bug fortran/107899] ICE in resolve_deallocate_expr, at fortran/resolve.cc:7576

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058566.html

[Bug c++/102000] Defaulted consteval default constructor that performs no initialization is not rejected

[hstong at ca dot ibm.com via Gcc-bugs]

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

Hubert Tong  changed:

   What|Removed |Added

 CC||hstong at ca dot ibm.com

--- Comment #4 from Hubert Tong  ---
(In reply to Johel Ernesto Guerrero Peña from comment #3)
> https://bugs.llvm.org/show_bug.cgi?id=51560#c1 points out
> > I'm not sure what you think the problem is here.  The constructor isn't 
> > getting called; see http://eel.is/c++draft/dcl.init.general#8 .
> It seems to me that they are right and the example above is well-formed.

That depends on what "the semantic constraints for default-initialization are
checked" means.

(In reply to Johel Ernesto Guerrero Peña from comment #0)
> ```
> An immediate invocation shall be a constant expression. --
> https://eel.is/c++draft/expr.const#13.sentence-3
> 
> Lots of wording in between...
> 
> 2 A variable or temporary object o is constant-initialized if
> (2.1) either it has an initializer or its default-initialization results
> in some initialization being performed, and
> -- https://eel.is/c++draft/expr.const#2
> 7 To default-initialize an object of type T means:
> (7.3) Otherwise, no initialization is performed.
> -- https://eel.is/c++draft/dcl.init.general#7
> ```

That wording would be relevant for a similar case involving `constinit`. Here,
the relevant wording is in 7.7 [expr.const] paragraph 12 (and the uninitialized
`int` is fine with the current wording). The example needs to be changed to use
pointers:
```
struct A {
  consteval A() = default;
private:
  int *m;
};

struct B {
  consteval B() = default;
private:
  int *m, *n = 0;
};

void f() {
  A a; // GCC accepts this despite pointer with indeterminate value
  B b; // GCC rejects this
}
```

So it seems GCC just doesn't do certain checking when the constructor is
trivial.

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
Actually I think there is some disagreement if dcl.init.list/3.4 (that is
aggregate initialization) applies ...

Because if I make the two fields private, then gcc (and MSVC) accepts it ...

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
I think GCC and MSVC are correct here:
[over.match.list]/16.3.1.7
. In copy-listinitialization, if an explicit constructor is chosen, the
initialization is ill-formed. [ Note: This differs from
other situations (16.3.1.3, 16.3.1.4), where only converting constructors are
considered for copy-initialization.
This restriction only applies if this initialization is part of the final
result of overload resolution. — end note ]


Even though the note is techincally not part of the standard, it describes why
clang is wrong here. That is the explicit constructors are used too to figure
out the overload and only if there was no ambiguous, it would be considered as
ill-formed.

[Bug modula2/107959] Incorrect aggregate constant type causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #2 from Gaius Mulley  ---
Tested and committed bugfix.

[Bug modula2/107959] Incorrect aggregate constant type causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Gaius Mulley  ---
Now fixed in git.

$ gm2 -fiso badipv4.mod 
badipv4.mod:7:12: error: In procedure ‘ForeachIndiceInIndexDo’: expecting CHAR
datatype and not ‘127’ a ‘Modula-2 base Z’ in the 0th component of the ‘IPV4’
array
7 |   Loopback = IPV4 {127, 0, 0, 1} ;
  |   ~^
badipv4.mod:7:12: error: expecting CHAR datatype and not ‘1’ a ‘Modula-2 base
Z’ in the 3rd component of the ‘IPV4’ array
badipv4.mod:7:12: error: expecting CHAR datatype and not ‘0’ a ‘Modula-2 base
Z’ in the 2nd component of the ‘IPV4’ array
badipv4.mod:7:12: error: expecting CHAR datatype and not ‘0’ a ‘Modula-2 base
Z’ in the 1st component of the ‘IPV4’ array

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
Obvious workaround is to do:
p = PairPtr{ a, b };

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Maybe related to C++ defect report 2137 (see PR 85577 for other details on
that) which GCC is known to implement but clang does not:

https://cplusplus.github.io/CWG/issues/2137.html

[Bug c++/107958] Ambiguity with uniform initialization in overloaded operator and explicit constructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Note MSVC (with /std:c++latest) also rejects the source that is in comment #0
for the same reason as GCC:

(39): error C2593: 'operator =' is ambiguous
(25): note: could be 'PairPtr &PairPtr::operator =(const std::pair &)'
(19): note: or   'PairPtr &PairPtr::operator =(const PairPtr &)'
(39): note: while trying to match the argument list '(PairPtr,
initializer list)'

[Bug modula2/107959] New: Incorrect aggregate constant type causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107959
   Summary: Incorrect aggregate constant type causes ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

The module below causes an ICE.

MODULE badipv4 ;
TYPE
  IPV4 = ARRAY [1..4] OF CHAR ;
CONST
  Loopback = IPV4 {127, 0, 0, 1} ;
END badipv4.

[Bug c++/107958] New: Ambiguity with uniform initialization in overloaded operator and explicit constructor

[nruslan_devel at yahoo dot com via Gcc-bugs]

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

Bug ID: 107958
   Summary: Ambiguity with uniform initialization in overloaded
operator and explicit constructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

Suppose we have the following example with a class that has to keep two
pointers. (I actually encountered this error with a more complex example, but
this one is just for illustration.) The problem arises when I attempt to use
the assignment operator and curly braces.

If I understand correctly, two possibilities exist when passing curly braces:

1. Use the overloaded operator= (implicitly convert curly braces to a pair). In
this particular example, we could have probably used make_pair but I
deliberately put curly braces to show how this error is triggered.

2. Use the constructor to create a new PairPtr instance and then copy it to the
old object through operator=

Both clang and gcc complain unless I mark the corresponding constructor as
'explicit'. To avoid the ambiguity with the second case, I mark the
corresponding constructor as 'explicit' and expect that the overloaded
operator= to be used. That seems to work with clang/llvm but not with gcc (see
the error below).

#include 
#include 

struct PairPtr {

PairPtr() {}

PairPtr(const PairPtr &s) {
a = s.a;
b = s.b;
}

explicit PairPtr(int *_a, int *_b) {
a = _a;
b = _b;
}

PairPtr& operator=(const PairPtr &s) {
a = s.a;
b = s.b;
return *this;
}

PairPtr& operator=(const std::pair& pair) {
a = pair.first;
b = pair.second;
return *this;
}

int *a;
int *b;
};

void func(int *a, int *b)
{
PairPtr p;

p = { a, b };
}


Error (note that clang/llvm can compile the above code successfully!):

Note that 'explicit' for the constructor fixes the problem for clang/llvm but
does not fix the problem for gcc.

2.cpp: In function ‘void func(int*, int*)’:
2.cpp:38:20: error: ambiguous overload for ‘operator=’ (operand types are
‘PairPtr’ and ‘’)
   38 | p = { a, b };
  |^
2.cpp:18:18: note: candidate: ‘PairPtr& PairPtr::operator=(const PairPtr&)’
   18 | PairPtr& operator=(const PairPtr &s) {
  |  ^~~~
2.cpp:24:18: note: candidate: ‘PairPtr& PairPtr::operator=(const
std::pair&)’
   24 | PairPtr& operator=(const std::pair& pair) {
  |

[Bug fortran/91316] Derived type finalization failing

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
(In reply to Paul Thomas from comment #2)
> (In reply to Paul Thomas from comment #1)
> > I notice that this is missing from the list of dependencies of PR37336, for
> > which a wider fix will be submitted this afternoon.

This has caught folks twice this last week. I have some ideas on a diagnostic
for it at run time and will submit a separate PR for it.

[Bug target/107957] New: Missed optimization in access to upper-half of a variable

[mrjjot at gmail dot com via Gcc-bugs]

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

Bug ID: 107957
   Summary: Missed optimization in access to upper-half of a
variable
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrjjot at gmail dot com
  Target Milestone: ---

Hello, 

I think I've found an optimization opportunity for AVR GCC. This might be
similar to bug 66511, but also affects variables smaller than 64 bits. Please
consider the following C code:

uint64_t x;
uint32_t y;
uint16_t z;
uint8_t w;

void foo(void)
{
y = x >> 32;
}

void bar(void)
{
z = y >> 16;
}

void rawr(void)
{
w = z >> 8;
}

As you can see, all three functions just assign upper half of one variable to
the another. When compiled with avr-gcc and -Wall -Wextra and -O3 flags, the
following assembly is produced:

foo():
push r16
lds r18,x
lds r19,x+1
lds r20,x+2
lds r21,x+3
lds r22,x+4
lds r23,x+5
lds r24,x+6
lds r25,x+7
ldi r16,lo8(32)
rcall __lshrdi3
sts y,r18
sts y+1,r19
sts y+2,r20
sts y+3,r21
pop r16
ret
bar():
lds r24,y
lds r25,y+1
lds r26,y+2
lds r27,y+3
sts z+1,r27
sts z,r26
ret
rawr():
lds r24,z+1
sts w,r24
ret

I'm not a compiler expert, but I'd say that this is a missed optimization. In
every case there are twice as many lds operations as needed. For comparison,
GCC for x86_64 does generate code which performs DWORD read in foo(), WORD read
in bar() and BYTE read in rawr(). I've found that the following definitions
generate identical assembly on x86_64 and more optimal assembly on AVR:

void foo2(void)
{
y = ((uint32_t*)&x)[1];
}

void bar2(void)
{
z = ((uint16_t*)&y)[1];
}

void rawr2(void)
{
w = ((uint8_t*)&z)[1];
}

foo2():
lds r24,x+4
lds r25,x+4+1
lds r26,x+4+2
lds r27,x+4+3
sts y,r24
sts y+1,r25
sts y+2,r26
sts y+3,r27
ret
bar2():
lds r24,y+2
lds r25,y+2+1
sts z+1,r25
sts z,r24
ret
rawr2():
lds r24,z+1
sts w,r24
ret

I've checked my local installation of AVR GCC 12.2.0 on Manjaro and different
AVR GCC versions on Godbolt. They all seem to produce the same machine code.

$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/12.2.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/12.2.0/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-12.2.0/configure
--disable-install-libiberty --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-linker-build-id --disable-nls
--disable-werror --disable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin
--enable-shared --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld
--with-plugin-ld=ld.gold --with-system-zlib --with-isl
--enable-gnu-indirect-function
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)

I'd appreciate if you could look into this. Thank you!

[Bug c++/103081] [ICE] with "using enum"

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |12.3

--- Comment #11 from Patrick Palka  ---
Fixed on trunk so far.

[Bug c++/103081] [ICE] with "using enum"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:b3912122c9dfaba6c8229e8f095885f69782ceda

commit r13-4477-gb3912122c9dfaba6c8229e8f095885f69782ceda
Author: Patrick Palka 
Date:   Sat Dec 3 10:28:25 2022 -0500

c++: substituting CONST_DECL_USING_P enumerators [PR103081]

We implement class-scope using enum by injecting clones of the enum's
CONST_DECLs as fields of the class, for which CONST_DECL_USING_P is
true, so that qualified lookup naturally finds the enumerators.
Substitution into such a CONST_DECL currently ICEs however, because we
assume the DECL_CONTEXT is always the ENUMERAL_TYPE (which has
TYPE_VALUES) but in this case it's the RECORD_TYPE for the class scope
(which has TYPE_FIELDS).

Since these CONST_DECLs appear to always be non-dependent, this patch
fixes this by shortcutting substitution for CONST_DECLs that have
non-dependent DECL_CONTEXT.  This subsumes the existing (and seemingly
dead) DECL_NAMESPACE_SCOPE_P early exit test and also benefits
substitution into ordinary non-dependent CONST_DECLs.

PR c++/103081

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy) : Generalize
early exit test for namespace-scope decls to check dependence of
the enclosing scope instead.  Remove dead early exit test.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/using-enum-10.C: New test.
* g++.dg/cpp2a/using-enum-10a.C: New test.

[Bug tree-optimization/107956] New: [12/13 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3641) with -fsanitize=float-cast-overflow -ftree-slp-vectorize -fexceptions

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107956
   Summary: [12/13 Regression] ICE: SIGSEGV in
contains_struct_check (tree.h:3641) with
-fsanitize=float-cast-overflow -ftree-slp-vectorize
-fexceptions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 54007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54007&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fsanitize=float-cast-overflow
-fno-delete-dead-exceptions -ftree-slp-vectorize -fexceptions -mavx512f
testcase.c -wrapper valgrind,-q
==25396== Invalid read of size 2
==25396==at 0x2523A88: contains_struct_check (tree.h:3641)
==25396==by 0x2523A88: vect_recog_mask_conversion_pattern(vec_info*,
_stmt_vec_info*, tree_node**) (tree-vect-patterns.cc:4967)
==25396==by 0x2524C98: vect_pattern_recog_1(vec_info*, vect_recog_func*,
_stmt_vec_info*) (tree-vect-patterns.cc:6153)
==25396==by 0x252C491: vect_pattern_recog(vec_info*)
(tree-vect-patterns.cc:6310)
==25396==by 0x165225B: vect_slp_analyze_bb_1 (tree-vect-slp.cc:7310)
==25396==by 0x165225B: vect_slp_region(vec, vec, vec*,
unsigned int, loop*) (tree-vect-slp.cc:7419)
==25396==by 0x165450C: vect_slp_bbs(vec
const&, loop*) (tree-vect-slp.cc:7610)
==25396==by 0x1654786: vect_slp_function(function*) (tree-vect-slp.cc:7698)
==25396==by 0x165D3C1: (anonymous
namespace)::pass_slp_vectorize::execute(function*) (tree-vectorizer.cc:1532)
==25396==by 0x1294D1A: execute_one_pass(opt_pass*) (passes.cc:2644)
==25396==by 0x129560F: execute_pass_list_1(opt_pass*) (passes.cc:2753)
==25396==by 0x1295621: execute_pass_list_1(opt_pass*) (passes.cc:2754)
==25396==by 0x1295621: execute_pass_list_1(opt_pass*) (passes.cc:2754)
==25396==by 0x1295648: execute_pass_list(function*, opt_pass*)
(passes.cc:2764)
==25396==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==25396== 
during GIMPLE pass: slp
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: Segmentation fault
5 | foo (V v)
  | ^~~
0x139d00f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:314
0x2523a88 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/repo/gcc-trunk/gcc/tree.h:3641
0x2523a88 vect_recog_mask_conversion_pattern
/repo/gcc-trunk/gcc/tree-vect-patterns.cc:4967
0x2524c98 vect_pattern_recog_1
/repo/gcc-trunk/gcc/tree-vect-patterns.cc:6153
0x252c491 vect_pattern_recog(vec_info*)
/repo/gcc-trunk/gcc/tree-vect-patterns.cc:6310
0x165225b vect_slp_analyze_bb_1
/repo/gcc-trunk/gcc/tree-vect-slp.cc:7310
0x165225b vect_slp_region
/repo/gcc-trunk/gcc/tree-vect-slp.cc:7419
0x165450c vect_slp_bbs
/repo/gcc-trunk/gcc/tree-vect-slp.cc:7610
0x1654786 vect_slp_function(function*)
/repo/gcc-trunk/gcc/tree-vect-slp.cc:7698
0x165d3c1 execute
/repo/gcc-trunk/gcc/tree-vectorizer.cc:1532
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-4468-20221202115005-g76dd48f8956-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4468-20221202115005-g76dd48f8956-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221202 (experimental) (GCC)

[Bug lto/107078] LTO is causing that firebird build is core dumping

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #19 from Sam James  ---
I get some ODR warnings in gpre:
```
/tmp/firebird/Firebird-4.0.2.2816-0/src/gpre/pat.cpp:60:21: warning: type
‘struct ops’ violates the C++ One Definition Rule [-Wodr]
   60 | static const struct ops
  | ^
/tmp/firebird/Firebird-4.0.2.2816-0/src/gpre/sqe.cpp:124:8: note: a different
type is defined in another translation unit
  124 | struct ops
  |^
/tmp/firebird/Firebird-4.0.2.2816-0/src/gpre/pat.cpp:62:15: note: the first
difference of corresponding definitions is field ‘ops_type’
   62 | pat_t ops_type;
  |   ^
/tmp/firebird/Firebird-4.0.2.2816-0/src/gpre/sqe.cpp:126:15: note: a field with
different name is defined in another translation unit
  126 | nod_t rel_op;
  |   ^
lto-wrapper: warning: using serial compilation of 11 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
rm -f /tmp/firebird/Firebird-4.0.2.2816-0/gen/Release/firebird/bin/gpre_current
```

--

Anyway, as a hack, try this:
```
diff --git a/gen/Makefile b/gen/Makefile
index a121c31..8eabd44 100644
--- a/gen/Makefile
+++ b/gen/Makefile
@@ -438,7 +438,7 @@ yachts.lnk: metadata.fdb

 metadata.fdb:  $(RUN_ISQL) $(SRC_ROOT)/dbs/metadata.sql
-$(RM) $@
-   $(RUN_ISQL) -q -i $(SRC_ROOT)/dbs/metadata.sql
+   gdbserver 127.0.0.1:1234 -- $(RUN_ISQL) -q -i
$(SRC_ROOT)/dbs/metadata.sql
$(RUN_GFIX) -mode read_only $@
$(CHMOD) 0444 $@

@@ -467,9 +467,9 @@ security.fdb:   $(SRC_ROOT)/dbs/security.sql

 msg.timestamp: $(MSG_FILES)
-$(RM) msg.fdb
-   echo create database \'msg.fdb\'\; | $(RUN_ISQL)
+   echo create database \'msg.fdb\'\; | gdbserver 127.0.0.1:1235 --
$(RUN_ISQL)
$(RUN_GFIX) -write async msg.fdb
-   for sql in $(MSG_FILES); do (echo $$sql; $(RUN_ISQL) -i $$sql msg.fdb)
|| exit; done
+   for sql in $(MSG_FILES); do (echo $$sql; gdbserver 127.0.0.1:1236 --
$(RUN_ISQL) -i $$sql msg.fdb) || exit; done
$(TOUCH) $@


```

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #54 from Jonathan Wakely  ---
Because it would be an ABI break. It's a good option if backwards compatibility
is not required, I've suggested it before.

[Bug c++/107955] ICE: trying to capture ‘ARGS#0’ in instantiation of generic lambda

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Duplicate of bug 100295.

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

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||onebit74 at gmail dot com

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

[Bug c++/107955] New: ICE: trying to capture ‘ARGS#0’ in instantiation of generic lambda

[onebit74 at gmail dot com via Gcc-bugs]

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

Bug ID: 107955
   Summary: ICE: trying to capture ‘ARGS#0’ in instantiation of
generic  lambda
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: onebit74 at gmail dot com
  Target Milestone: ---

The code is valid
If you comment out the if, it compiles.
If you comment out the branches in the if, it compiles as well.

But somehow putting them together gives ICE.


#include 

template
struct agg_p {
F f;


void _parse(auto...ARGS){
[&](auto...P_ARGS){
using result =
std::invoke_result_t;
if constexpr(!std::same_as){
f(ARGS...,P_ARGS...);
}else{
f(ARGS...,P_ARGS...);
}
}(1);
}

};

int main(){
auto add = [](auto a, auto b){return a+b;};
auto agg = agg_p(add);
int i;
agg._parse(i);
}

[Bug fortran/91316] Derived type finalization failing

[pault at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Paul Thomas  ---
(In reply to Paul Thomas from comment #1)
> I notice that this is missing from the list of dependencies of PR37336, for
> which a wider fix will be submitted this afternoon.
> 
> Best regards
> 
> Paul

I have returned to this problem. final_s4 generates illegal recursive I/O and
hangs due to a mutex lock. It works fine if the I/O is removed from the final
procedure.

__attribute__((fn spec (". ")))
void final_s4 ()
{
  struct array00_final_t D.4386;

  {
struct __st_parameter_dt dt_parm.6;

dt_parm.6.common.filename = &"/home/pault/prs/pr37336/pr91316.f90"[1]{lb: 1
sz: 1};
dt_parm.6.common.line = 127;
dt_parm.6.common.flags = 128;
dt_parm.6.common.unit = 6;
_gfortran_st_write (&dt_parm.6);
_gfortran_transfer_character_write (&dt_parm.6, &"f4: "[1]{lb: 1 sz: 1},
4);
{
  static integer(kind=4) C.4378 = 4;
  struct final_t D.4379;
  struct final_t D.4380;
  struct array00_final_t desc.7;
  struct final_t D.4387;
  integer(kind=4) D.4388;

  D.4379 = final_set (&C.4378);
  D.4380 = D.4379;
  desc.7.dtype = {.elem_len=4, .rank=0, .type=5};
  desc.7.data = (void * restrict) &D.4379;
  desc.7.span = (integer(kind=8)) desc.7.dtype.elem_len;
  D.4386 = desc.7;
  D.4387 = D.4380;
  D.4388 = final_get (&D.4387);
  _gfortran_transfer_integer_write (&dt_parm.6, &D.4388, 4);
  if (__vtab_final_m_Final_t._final != 0B && (struct final_t * restrict)
D.4386.data != 0B)
{
  __vtab_final_m_Final_t._final (&D.4386, __vtab_final_m_Final_t._size,
0);
}
}
_gfortran_st_write_done (&dt_parm.6);
  }
  return;
}

Cheers

Paul

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

Jamaika  changed:

   What|Removed |Added

 CC||lukaszcz18 at wp dot pl

--- Comment #2 from Jamaika  ---
I shouldn't be writing as an outsider.
I don't know what c2x accepts.
For gcc 11.3.1 and c++20 I am forced to use c2x.
For example, compiling HTJ2K grok c++20 and zlib shows that zlib does not
conform to c++20 standards and some functions are deprecated.

adler32.c: In function 'adler32_z':
adler32.c:63:15: warning: old-style function definition
[-Wold-style-definition]
   63 | uLong ZEXPORT adler32_z(adler, buf, len)
  |   ^
adler32.c: In function 'adler32':
adler32.c:134:15: warning: old-style function definition
[-Wold-style-definition]
  134 | uLong ZEXPORT adler32(adler, buf, len)
  |   ^~~
adler32.c: In function 'adler32_combine_':
adler32.c:143:13: warning: old-style function definition
[-Wold-style-definition]
  143 | local uLong adler32_combine_(adler1, adler2, len2)
  | ^~~~
adler32.c: In function 'adler32_combine':
adler32.c:172:15: warning: old-style function definition
[-Wold-style-definition]
  172 | uLong ZEXPORT adler32_combine(adler1, adler2, len2)
  |   ^~~
adler32.c: In function 'adler32_combine64':
adler32.c:180:15: warning: old-style function definition
[-Wold-style-definition]
  180 | uLong ZEXPORT adler32_combine64(adler1, adler2, len2)
  |   ^
compress.c: In function 'compress2':
compress.c:22:13: warning: old-style function definition
[-Wold-style-definition]
   22 | int ZEXPORT compress2(dest, destLen, source, sourceLen, level)
  | ^
compress.c: In function 'compress':
compress.c:68:13: warning: old-style function definition
[-Wold-style-definition]
   68 | int ZEXPORT compress(dest, destLen, source, sourceLen)
  | ^~~~
compress.c: In function 'compressBound':
compress.c:81:15: warning: old-style function definition
[-Wold-style-definition]
   81 | uLong ZEXPORT compressBound(sourceLen)
  |   ^
crc32.c: In function 'byte_swap':
crc32.c:126:16: warning: old-style function definition [-Wold-style-definition]
  126 | local z_word_t byte_swap(word)
  |^
crc32.c: In function 'multmodp':
crc32.c:551:15: warning: old-style function definition [-Wold-style-definition]
  551 | local z_crc_t multmodp(a, b)
  |   ^~~~
crc32.c: In function 'x2nmodp':
crc32.c:575:15: warning: old-style function definition [-Wold-style-definition]
  575 | local z_crc_t x2nmodp(n, k)
  |   ^~~
crc32.c: In function 'crc_word':
crc32.c:726:15: warning: old-style function definition [-Wold-style-definition]
  726 | local z_crc_t crc_word(data)
  |   ^~~~
crc32.c: In function 'crc_word_big':
crc32.c:735:16: warning: old-style function definition [-Wold-style-definition]
  735 | local z_word_t crc_word_big(data)
  |^~~~
crc32.c: In function 'crc32_z':
crc32.c:748:23: warning: old-style function definition [-Wold-style-definition]
  748 | unsigned long ZEXPORT crc32_z(crc, buf, len)
  |   ^~~
crc32.c: In function 'crc32':
crc32.c:1072:23: warning: old-style function definition
[-Wold-style-definition]
 1072 | unsigned long ZEXPORT crc32(crc, buf, len)
  |   ^