[Bug target/92999] [armhf] struct with adjacent __fp16's copies wrongly

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

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||13.0
   Last reconfirmed||2022-11-05

--- Comment #2 from Ramana Radhakrishnan  ---
confirmed on trunk.

I think this is an issue in the way the registers are allocated for the VFP
PCS.

[Bug target/107533] New: Inefficient code sequence for fp16 testcase on aarch64

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

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

Bug ID: 107533
   Summary: Inefficient code sequence for fp16 testcase on aarch64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org
  Target Milestone: ---

Derived from PR92999 



struct phalf {
__fp16 first;
__fp16 second;
};

struct phalf phalf_copy(struct phalf* src) __attribute__((noinline));
struct phalf phalf_copy(struct phalf* src) {
return *src;
}

Compiling for AArch64 with a recent enough compiler produces. 

phalf_copy:
ldr w0, [x0]
ubfxx1, x0, 0, 16
lsr w0, w0, 16
dup v0.4h, w1
dup v1.4h, w0
ret


Couldn't it just be ldr h0, [x0]
ldr h1, [x0, 2] 

IIRC this is in base v8 rather than v8.2 


regards
Ramana

[Bug debug/53135] Duplicates cause size explosion (vta/dwarf)

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

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

--- Comment #20 from Ramana Radhakrishnan  ---
(In reply to Jeffrey A. Law from comment #19)
> I think it's just  workaround that got installed in 2012, not a real fix. 
> Of course, 10 years later one could ask if the workaround has become the
> "real fix".

That is of course a jolly good question :P 

Ramana

[Bug target/105929] [AArch64] armv8.4-a allows atomic stp. 64-bit constants can use 2 32-bit halves with _Atomic or volatile

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

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-11-05

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed as an 8 byte aligned store is always going to be fully within a 16
byte block aligned to a 16 byte aligned address.

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

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

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

--- Comment #12 from Aldy Hernandez  ---
Created attachment 53831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53831&action=edit
solution improving MULT_EXPR range-ops

Another solution is just improving the MULT_EXPR range-op entry.  This has no
penalty anywhere.

Though, I still feel we should reflect nonzero masks in the range independently
of this :-/.

Either way, we can solve the PR.

[Bug c++/107531] List of references calls destructors, add warning?

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Why should the compiler warn here? There are no resources being freed. Making
trivial copies and then destroying them is not a bug.

If you give the class some resources to manage (e.g. a pointer member) then
-Weffc++ will warn that you messed up:

dest.C:2:8: warning: ‘struct S’ has pointer data members [-Weffc++]
2 | struct S {
  |^
dest.C:2:8: warning:   but does not declare ‘S(const S&)’ [-Weffc++]
dest.C:2:8: warning:   or ‘operator=(const S&)’ [-Weffc++]
dest.C:5:10: note: pointer member ‘S::p’ declared here
5 | int* p = nullptr;
  |  ^


It would be nice if you could turn on this warning without the rest of -Weffc++
but that's PR 16166.

[Bug c++/107531] List of references calls destructors, add warning?

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to nightstrike from comment #0)
> Maybe adding something from -fsanitize=undefined would be an option?

There's nothing undefined in your example.

But if you actually allocate and free resources, asan aborts on the
double-free:

=
==1035874==ERROR: AddressSanitizer: attempting double-free on 0x60200010 in
thread T0:
#0 0x7f69bd2bc088 in operator delete(void*, unsigned long)
(/lib64/libasan.so.8+0xbc088)
#1 0x401391 in S::~S() (/tmp/a.out+0x401391)
#2 0x401247 in main (/tmp/a.out+0x401247)
#3 0x7f69bca2950f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#4 0x7f69bca295c8 in __libc_start_main_impl ../csu/libc-start.c:389
#5 0x4010f4 in _start (/tmp/a.out+0x4010f4)

0x60200010 is located 0 bytes inside of 4-byte region
[0x60200010,0x60200014)
freed by thread T0 here:
#0 0x7f69bd2bc088 in operator delete(void*, unsigned long)
(/lib64/libasan.so.8+0xbc088)
#1 0x401391 in S::~S() (/tmp/a.out+0x401391)
#2 0x401577 in void f(S const&) (/tmp/a.out+0x401577)
#3 0x40123b in main (/tmp/a.out+0x40123b)
#4 0x7f69bca2950f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58

previously allocated by thread T0 here:
#0 0x7f69bd2bb188 in operator new(unsigned long)
(/lib64/libasan.so.8+0xbb188)
#1 0x4012e3 in S::S() (/tmp/a.out+0x4012e3)
#2 0x40122f in main (/tmp/a.out+0x40122f)
#3 0x7f69bca2950f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.8+0xbc088) in
operator delete(void*, unsigned long)
==1035874==ABORTING

[Bug analyzer/94355] support for C++ new expression

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

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

--- Comment #10 from Jonathan Wakely  ---
struct S {
S() { p = new int(); }
~S() { delete p; }
int* p = nullptr;
};

int main() {
S s;
}


Everything the analyzer says is wrong :-)

dest.C: In function ‘int main()’:
dest.C:9:1: warning: leak of ‘s.S::p’ [CWE-401] [-Wanalyzer-malloc-leak]
9 | }
  | ^
  ‘int main()’: events 1-2
|
|7 | int main() {
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|8 | S s;
|  |   ~
|  |   |
|  |   (2) calling ‘S::S’ from ‘main’
|
+--> ‘S::S()’: events 3-5
   |
   |2 | S() { p = new int(); }
   |  | ^ ~
   |  | |   | |
   |  | |   | (4) allocated here
   |  | |   (5) assuming ‘operator new(4)’ is non-NULL
   |  | (3) entry to ‘S::S’
   |
<--+
|
  ‘int main()’: events 6-7
|
|8 | S s;
|  |   ^
|  |   |
|  |   (6) returning to ‘main’ from ‘S::S’
|9 | }
|  | ~  
|  | |
|  | (7) ‘s.S::p’ leaks here; was allocated at (4)
|
dest.C: In constructor ‘S::S()’:
dest.C:2:13: warning: dereference of possibly-NULL ‘operator new(4)’ [CWE-690]
[-Wanalyzer-possible-null-dereference]
2 | S() { p = new int(); }
  |   ~~^~~
  ‘S::S()’: events 1-2
|
|2 | S() { p = new int(); }
|  |   ^
|  | | |
|  | | (1) this call could return NULL
|  | (2) ‘operator new(4)’ could be NULL: unchecked value
from (1)
|

As already noted above, new can't return null here, and there is no dereference
anyway. And the pointer isn't leaked, but it seems maybe the analyzer doesn't
know about destructors?

[Bug analyzer/94355] support for C++ new expression

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

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

--- Comment #11 from Jonathan Wakely  ---
If we add a real bug (making a shallow copy of the object, which shares the
same heap pointer and then both destructors free the same one):

struct S {
S() { p = new int(); }
~S() { delete p; }
int* p = nullptr;
};

int main() {
S s;
S ss = s;
}

Then the analyzer still tells us the pointer is leaked:

dest.C: In function ‘int main()’:
dest.C:10:1: warning: leak of ‘s.S::p’ [CWE-401] [-Wanalyzer-malloc-leak]
   10 | }
  | ^
  ‘int main()’: events 1-2
|
|7 | int main() {
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|8 | S s;
|  |   ~
|  |   |
|  |   (2) calling ‘S::S’ from ‘main’
|
+--> ‘S::S()’: events 3-5
   |
   |2 | S() { p = new int(); }
   |  | ^ ~
   |  | |   | |
   |  | |   | (4) allocated here
   |  | |   (5) assuming ‘operator new(4)’ is non-NULL
   |  | (3) entry to ‘S::S’
   |
<--+
|
  ‘int main()’: events 6-7
|
|8 | S s;
|  |   ^
|  |   |
|  |   (6) returning to ‘main’ from ‘S::S’
|9 | S ss = s;
|   10 | }
|  | ~  
|  | |
|  | (7) ‘s.S::p’ leaks here; was allocated at (4)
|

But strangely it also tells use there's a use-after-free, which is odd if it
thinks the pointer was nver freed:

dest.C: In destructor ‘S::~S()’:
dest.C:3:22: warning: use after ‘delete’ of ‘s.S::p’ [CWE-416]
[-Wanalyzer-use-after-free]
3 | ~S() { delete p; }
  |  ^
  ‘int main()’: events 1-2
|
|7 | int main() {
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|8 | S s;
|  |   ~
|  |   |
|  |   (2) calling ‘S::S’ from ‘main’
|
+--> ‘S::S()’: events 3-5
   |
   |2 | S() { p = new int(); }
   |  | ^ ~
   |  | |   | |
   |  | |   | (4) allocated here
   |  | |   (5) assuming ‘operator new(4)’ is non-NULL
   |  | (3) entry to ‘S::S’
   |
<--+
|
  ‘int main()’: events 6-7
|
|8 | S s;
|  |   ^
|  |   |
|  |   (6) returning to ‘main’ from ‘S::S’
|9 | S ss = s;
|   10 | }
|  | ~  
|  | |
|  | (7) calling ‘S::~S’ from ‘main’
|
+--> ‘S::~S()’: events 8-11
   |
   |3 | ~S() { delete p; }
   |  | ^  
   |  | |  |  |
   |  | |  |  (10) ...to here
   |  | |  |  (11) deleted here
   |  | |  (9) following ‘true’ branch...
   |  | (8) entry to ‘S::~S’
   |
<--+
|
  ‘int main()’: events 12-13
|
|   10 | }
|  | ^
|  | |
|  | (12) returning to ‘main’ from ‘S::~S’
|  | (13) calling ‘S::~S’ from ‘main’
|
+--> ‘S::~S()’: events 14-17
   |
   |3 | ~S() { delete p; }
   |  | ^    ~
   |  | |  |  |  |
   |  | |  |  |  (17) use after ‘delete’ of
‘*this.S::p’; deleted at (11)
   |  | |  |  (16) ...to here
   |  | |  (15) following ‘true’ branch...
   |  | (14) entry to ‘S::~S’
   |

I think it's (correctly) telling us that the destructor ss.~S() uses the value
after s.~S() already freed it. But it would be nice if it mentioned that the
second destructor is on ss, not s.

The earlier warning tells us the object: "warning: use after ‘delete’ of
‘s.S::p’" 

So it would be nice if the use-after-free was identified as being ss.S::p
(which has the same value as s.S::p).

And it's not actually a use-after-free (and certainly not at the closing brace
of the destructor where the location points to), it's a double-free.

Ideally it would have complained when we copied the pointer value in the
trivial copy constructor and didn't zero out the original. That shallow copy
was the actual bug, the double-free is a symptom of it.


dest.C: In constructor ‘S::S()’:
dest.C:2:13: warning: dereference of possibly-NULL ‘operator new(4)’ [CWE-690]
[-Wanalyzer-possible-null-dereference]
2 | S() { p = new int(); }
  |   ~~^~~
  ‘S::S()’: events 1-2
|
|2 | S() { p = new int(); }
|  |   ^
|  | | |
|  | | (1) this call could return NULL
|  | (2) ‘operator new(4)’ could be NU

[Bug c++/107531] List of references calls destructors, add warning?

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

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

--- Comment #5 from Jonathan Wakely  ---
Unsurprisingly, -fanalyzer doesn't say anything useful about this, because it
doesn't support C++. PR 94355 tracks some of that (and the meta-bug that it
blocks tracks more).

[Bug target/107453] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2022-10-31 00:00:00 |2022-11-5
 CC||tschwinge at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
Similarly -- I guess had to be expeced -- commit
r13-3549-g4fe34cdcc80ac225b80670eabc38ac5e31ce8a5a "c: tree: target: C2x (...)
function prototypes and va_start relaxation" needs some follow-on work for
nvptx target.  A number of the test cases PASS, but the following ones don't:


+FAIL: gcc.dg/c2x-stdarg-4.c (test for excess errors)
+UNRESOLVED: gcc.dg/c2x-stdarg-4.c compilation failed to produce executable

ptxas /tmp/cc2o4IWl.o, line 912; error   : Call has wrong number of
parameters
ptxas /tmp/cc2o4IWl.o, line 912; error   : Type of argument does not match
formal parameter '%in_ar0'
ptxas /tmp/cc2o4IWl.o, line 912; error   : Alignment of argument does not
match formal parameter '%in_ar0'
ptxas /tmp/cc2o4IWl.o, line 960; error   : Call has wrong number of
parameters
ptxas /tmp/cc2o4IWl.o, line 960; error   : Type of argument does not match
formal parameter '%in_ar0'
ptxas /tmp/cc2o4IWl.o, line 996; error   : Call has wrong number of
parameters
ptxas /tmp/cc2o4IWl.o, line 996; error   : Type of argument does not match
formal parameter '%in_ar0'
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status


+PASS: gcc.dg/torture/c2x-stdarg-split-1a.c   -O0  (test for excess errors)
+FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O0  execution test
+PASS: gcc.dg/torture/c2x-stdarg-split-1a.c   -O1  (test for excess errors)
+FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O1  execution test
+PASS: gcc.dg/torture/c2x-stdarg-split-1a.c   -O2  (test for excess errors)
+FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O2  execution test
+PASS: gcc.dg/torture/c2x-stdarg-split-1a.c   -O3 -g  (test for excess
errors)
+FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O3 -g  execution test
+PASS: gcc.dg/torture/c2x-stdarg-split-1a.c   -Os  (test for excess errors)
+FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -Os  execution test

error   : Prototype doesn't match for 'f' in 'input file 2 at offset
14552', first defined in 'input file 2 at offset 14552'
error   : Prototype doesn't match for 'g' in 'input file 2 at offset
14552', first defined in 'input file 2 at offset 14552'
nvptx-run: cuLinkAddData failed: unknown error (CUDA_ERROR_UNKNOWN, 999)

[Bug analyzer/107534] New: Analyzer should flag shallow copies of resources

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

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

Bug ID: 107534
   Summary: Analyzer should flag shallow copies of resources
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 97110
  Target Milestone: ---

As shown in PR 94355 comment 11, this code reports a use-after-free (and a
spurious leak and spurious null deref):

struct S {
S() { p = new int(); }
~S() { delete p; }
int* p = nullptr;
};

int main() {
S s;
S ss = s;
}

Ideally the copy construction of 'ss' would flag that we end up with two owners
of the heap pointer. The new object should either make a deep copy (allocate a
new object as a copy of *s.p) or should clear the source so it's left empty
(which would require a move constructor, not just the trivial copy constructor
that makes the shallow copy here).

In other words, rather than flagging three symptoms, flag the cause. The type
manages dynamic resources but doesn't have a user-provided copy or move
constructor and so manages them unsafely.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110
[Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer

[Bug analyzer/94355] support for C++ new expression

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #11)
> Ideally it would have complained when we copied the pointer value in the
> trivial copy constructor and didn't zero out the original. That shallow copy
> was the actual bug, the double-free is a symptom of it.

I've created PR 107534 for that.

[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code.

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
I will have a look.

[Bug target/107453] [13 Regression] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Keywords||testsuite-fail
Summary|New stdarg tests in |[13 Regression] New stdarg
   |r13-3549-g4fe34cdcc80ac2|tests in
   |fail|r13-3549-g4fe34cdcc80ac2
   ||fail
   Target Milestone|--- |13.0

[Bug target/107459] microblaze moddi3 implementation is buggy

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #2 from Richard Biener  ---
Please post patches to gcc-patc...@gcc.gnu.org

[Bug c/107465] [10/11/12/13 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3

[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code since r11-6434

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]   |[11/12/13 Regression]
   |Segmentation fault with |Segmentation fault with
   |vectorized code.|vectorized code since
   ||r11-6434
   Keywords|needs-bisection |

--- Comment #6 from Jakub Jelinek  ---
Started with r11-6434-g8837f82e4bab1b5405cf034eab9b3e83afc563ad

[Bug tree-optimization/107467] [12/13 Regression] Miscompilation involing -Os , -flto and -fno-strict-aliasing

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
doesn't reproduce with -fwhole-program instead of -flto or with
-flto-partition=max added.  -fno-ipa-modref avoids the issue.

[Bug ada/107475] [10/11/12/13 Regression] libgnat fails to link libgnat.so on systems with older glibc on x86_64-linux-gnux32

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
   Keywords||build

[Bug rtl-optimization/107482] [10/11/12/13 Regression] out-of-bounds heap access in IRA since r6-3496-g86f0bef37378a0

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||vmakarov at gcc dot gnu.org

[Bug c++/107484] [13 Regression] ICE: Segmentation fault (in decls_match)

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Keywords||ice-checking

[Bug middle-end/107485] [10 Regression] gcc-10 ICE with -fnon-call-exception

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/107493] [13 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I will have a look, possibly fallout of the PR107176 fix.

[Bug tree-optimization/107499] [13 Regression] 433.milc regressed by 6-8% on zen3 at -O2 -flto

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

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

Richard Biener  changed:

   What|Removed |Added

Version|12.0|13.0
   Keywords||missed-optimization
   Target Milestone|--- |13.0
   Last reconfirmed||2022-11-05
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|433.milc regressed by 6-8%  |[13 Regression] 433.milc
   |on zen3 at -O2 -flto|regressed by 6-8% on zen3
   ||at -O2 -flto

--- Comment #1 from Richard Biener  ---
It should be possible to constrain the "fix" to niter analysis, it also affects
IVOPTs which might be the issue here.  I'll investigate during stage3.

[Bug tree-optimization/107503] tail call missed with struct wrapper

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-11-05
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Biener  ---
Probably target dependent (requires single member aggregate to be returned with
the same ABI as the element type).

[Bug tree-optimization/107505] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-11-05
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Biener  ---
That looks about correct - patch is OK if testing succeeds.

[Bug c++/107514] quick crash of gcc due to noexcept specification

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Richard Biener  ---
Please attach the full example.

[Bug c++/107516] [13 Regression] ICE with -fwide-exec-charset=latin1

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c/41041] Documentation: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-3694-ge50ea3a42f058c14ee29327d5277ab0435e3d36b
Author: Jonathan Wakely 
Date:   Fri Nov 4 12:10:32 2022 +

doc: Document correct -fwide-exec-charset defaults [PR41041]

As shown in the PR, the default is not UTF-32 but rather UTF-32BE or
UTF-32LE, avoiding the need for a byte order mark in literals.

gcc/ChangeLog:

PR c/41041
* doc/cppopts.texi: Document -fwide-exec-charset defaults
correctly.

[Bug c/41041] Documentation: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:1342c7f46e6e3f8f29d7971531a0af18cd8429bc

commit r12-8893-g1342c7f46e6e3f8f29d7971531a0af18cd8429bc
Author: Jonathan Wakely 
Date:   Fri Nov 4 12:10:32 2022 +

doc: Document correct -fwide-exec-charset defaults [PR41041]

As shown in the PR, the default is not UTF-32 but rather UTF-32BE or
UTF-32LE, avoiding the need for a byte order mark in literals.

gcc/ChangeLog:

PR c/41041
* doc/cppopts.texi: Document -fwide-exec-charset defaults
correctly.

(cherry picked from commit e50ea3a42f058c14ee29327d5277ab0435e3d36b)

[Bug c++/107535] New: Shouldn't -fvisibility=hidden hide C++17 inline static variables?

[junchao.zhang at gmail dot com via Gcc-bugs]

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

Bug ID: 107535
   Summary: Shouldn't -fvisibility=hidden hide C++17 inline static
variables?
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: junchao.zhang at gmail dot com
  Target Milestone: ---

I think inline static variables are global. However, they could be hidden by
-fvisibility=hidden.
This is dangerous, since with C++17 inline static variables,  they will appear
in headers and be included in *.cpp files. If the *.cpp files are compiled with
-fvisibility=hidden, each will get their own storage.

$ cat foo.hpp 
struct Foo {static inline int s = 100; };
extern __attribute__ ((visibility ("default"))) void DumpLibFoo();

$ cat foo.cpp
#include 
#include 
void DumpLibFoo() { printf("In libfoo, Foo::s (%p) = %d\n", &Foo::s, Foo::s); }

$ cat test.cpp
#include 
#include 

int main() {
  Foo::s = 200;
  printf("In main,   Foo::s (%p) = %d\n", &Foo::s, Foo::s);

  DumpLibFoo();
  return 0;
}

-
gcc -std=c++17 -c -fPIC -I./ test.cpp -fvisibility=hidden
gcc -std=c++17 -c -fPIC -I./ foo.cpp
gcc -o libfoo.so -shared foo.o
gcc -std=c++17 -o test test.o -Wl,-rpath ./ -L ./ -lfoo

./test
In main,   Foo::s (0x5604c2741010) = 200
In libfoo, Foo::s (0x7f4e5173d028) = 100

[Bug c/41041] Documentation: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-10365-gae31f6acb2cf9d43a265f42c12f95e4687ac1fa4
Author: Jonathan Wakely 
Date:   Fri Nov 4 12:10:32 2022 +

doc: Document correct -fwide-exec-charset defaults [PR41041]

As shown in the PR, the default is not UTF-32 but rather UTF-32BE or
UTF-32LE, avoiding the need for a byte order mark in literals.

gcc/ChangeLog:

PR c/41041
* doc/cppopts.texi: Document -fwide-exec-charset defaults
correctly.

(cherry picked from commit e50ea3a42f058c14ee29327d5277ab0435e3d36b)

[Bug c/41041] Documentation: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:87b0935ed43d971a6eeebca963fb673628f138dd

commit r10-11071-g87b0935ed43d971a6eeebca963fb673628f138dd
Author: Jonathan Wakely 
Date:   Fri Nov 4 12:10:32 2022 +

doc: Document correct -fwide-exec-charset defaults [PR41041]

As shown in the PR, the default is not UTF-32 but rather UTF-32BE or
UTF-32LE, avoiding the need for a byte order mark in literals.

gcc/ChangeLog:

PR c/41041
* doc/cppopts.texi: Document -fwide-exec-charset defaults
correctly.

(cherry picked from commit e50ea3a42f058c14ee29327d5277ab0435e3d36b)

[Bug c/41041] Documentation: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #16 from Jonathan Wakely  ---
Docs fixed for 10.5, 11.4 and 12.3

[Bug bootstrap/80677] LIMITS_H_TEST is wrong

[helmut at subdivi dot de via Gcc-bugs]

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

Helmut Grohne  changed:

   What|Removed |Added

 CC||helmut at subdivi dot de

--- Comment #3 from Helmut Grohne  ---
Created attachment 53832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53832&action=edit
eliminate the need for LIMITS_H_TEST entirely

Rather than fix LIMITS_H_TEST, I now propose deleting it. The check that we try
to perform at build time with wrong paths can be deferred to runtime and then
operated with correct paths. I'm using this patch since at least gcc-11 and
only encountered one regression thus far. It triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 on hurd, but this is a plain
gcc bug that needs fixing anyway, so this should be good to go.

[Bug c++/107514] quick crash of gcc due to noexcept specification

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Janez Zemva  ---
Created attachment 53833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53833&action=edit
example

[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:7c6008e75df80607f8104e665e0448a0a9cbf85a

commit r13-3695-g7c6008e75df80607f8104e665e0448a0a9cbf85a
Author: Jonathan Wakely 
Date:   Fri Nov 4 15:05:41 2022 +

libstdc++: Do not use SFINAE for propagate_const conversions [PR107525]

As the PR notes, the current conversion operators are defined as
function templates so that we can use SFINAE. But this changes how they
are considered for overload resolution. This moves those operators into
base classes that can be specialized so the operators are obsent unless
the constraints are satisfied.

libstdc++-v3/ChangeLog:

PR libstdc++/107525
* include/experimental/propagate_const (operator element_type*()):
Move into base class that can be partially specilized to iompose
constraints.
(operator const element_type*()): Likewise.
* testsuite/experimental/propagate_const/observers/107525.cc: New
test.

[Bug libstdc++/105387] libstdc++: with -fno-rtti, pointer type info class incorrectly matches non-pointer type info classes

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-3696-gb83f01d0057578ebc1785f858fbfd46cdc210560
Author: Jakob Hasse <0xja...@users.noreply.github.com>
Date:   Tue Apr 26 12:03:47 2022 +0800

libstdc++: fix pointer type exception catch (no RTTI) [PR105387]

__pbase_type_info::__do_catch(), used to catch pointer type exceptions,
did not check if the type info object to compare against is a pointer
type info object before doing a static down-cast to a pointer type info
object. If RTTI is disabled, this leads to the following situation:
Since a pointer type info object has additional fields, they would
end up being undefined if the actual type info object was not a pointer
type info object.

A simple check has been added before the down-cast happens.

Note that a consequence of this check is that exceptions of type
pointer-to-member cannot be caught anymore.

In case RTTI is enabled, this does not seem to be a problem because
RTTI-based checks would run before and prevent running into the bad
down-cast. Hence, the fix is disabled if RTTI is enabled and exceptions
of type pointer-to-member can still be caught.

libstdc++-v3/ChangeLog:

PR libstdc++/105387
* libsupc++/pbase_type_info.cc (__do_catch) [!__cpp_rtti]: Add
check that the thrown type is actually a pointer.
* testsuite/18_support/105387.cc: New test.
* testsuite/18_support/105387_memptr.cc: New test.

Signed-off-by: Jakob Hasse 

[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Fixed on trunk, thanks for the report (and the library issue submission).

[Bug libstdc++/105387] libstdc++: with -fno-rtti, pointer type info class incorrectly matches non-pointer type info classes

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk now, thanks for the report and the patch.

[Bug middle-end/106725] LTO semantics for __attribute__((leaf))

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-05
   Keywords||wrong-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #8 from Richard Biener  ---
I think that shows we have a correctness issue here (if 'leaf' should be
usable).

Honza - can you please investigate?

[Bug middle-end/106811] GENERIC and GIMPLE IL undefined behavior needs documenting

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #2 from rguenther at suse dot de  ---
On Wed, 2 Nov 2022, nunoplopes at sapo dot pt wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106811
> 
> Nuno Lopes  changed:
> 
>What|Removed |Added
> 
>  CC||nunoplopes at sapo dot pt
> 
> --- Comment #1 from Nuno Lopes  ---
> I suggest adopting the concept of poison that LLVM has. It allows operations 
> to
> have undefined behavior, while still allow them to be moved freely.
> I have some slides that may serve as an introduction to the topic:
> https://web.ist.utl.pt/nuno.lopes/pres/ub-vmcai19.pdf
> 
> Happy to discuss further.

I've seen this before but I don't really see how that manages to avoid
issues when making conditional undefined behavior invoking stmts
unconditional.

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

https://gcc.gnu.org/g:3ad2167bbac8ae83b1e91305b105ab5287bdac55

commit r13-3697-g3ad2167bbac8ae83b1e91305b105ab5287bdac55
Author: Lewis Hyatt 
Date:   Wed Jun 15 18:06:53 2022 -0400

c++: libcpp: Support raw strings with newlines in directives [PR55971]

It's not currently possible to use a C++11 raw string containing a newline
as
part of the definition of a macro, or in any other preprocessing directive,
such as:

 #define X R"(two
lines)"

 #error R"(this error has
two lines)"

Add support for that by relaxing the conditions under which
_cpp_get_fresh_line() refuses to get a new line. For the case of lexing a
raw
string, it's OK to do so as long as there is another line within the
current
buffer. The code in cpp_get_fresh_line() was refactored into a new function
get_fresh_line_impl(), so that the new logic is applied only when
processing a
raw string and not any other times.

libcpp/ChangeLog:

PR preprocessor/55971
* lex.cc (get_fresh_line_impl): New function refactoring the code
from...
(_cpp_get_fresh_line): ...here.
(lex_raw_string): Use the new version of get_fresh_line_impl() to
support raw strings containing new lines when processing a
directive.

gcc/testsuite/ChangeLog:

PR preprocessor/55971
* c-c++-common/raw-string-directive-1.c: New test.
* c-c++-common/raw-string-directive-2.c: New test.

gcc/c-family/ChangeLog:

PR preprocessor/55971
* c-ppoutput.cc (adjust_for_newlines): Update comment.

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

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

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

Lewis Hyatt  changed:

   What|Removed |Added

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

--- Comment #10 from Lewis Hyatt  ---
Fixed for GCC 13.

[Bug analyzer/94355] support for C++ new expression

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

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

--- Comment #13 from David Malcolm  ---
(In reply to Jonathan Wakely from comment #10)

[...snip...]

> As already noted above, new can't return null here, and there is no
> dereference anyway. And the pointer isn't leaked, but it seems maybe the
> analyzer doesn't know about destructors?

FWIW the analyzer (presumably incorrectly) considers the case where operator
new returns NULL, and then attempts to write 0 to it.

The leak is due to the analyzer (presumably incorrectly) following the EH cfg
edge from BB 2 to BB 5 below.

int main ()
{
  struct S s;
  int D.2800;
  int _5;

   :
  S::S (&s);

   :
  S::~S (&s);
  s ={v} {CLOBBER(eol)};
  _5 = 0;

   :
:
  return _5;

   :
:
  s ={v} {CLOBBER(eol)};
  resx 1

}

[Bug ada/107536] New: [12 regression] Wrong 'not referenced' warning on renamed variable

[simon at pushface dot org via Gcc-bugs]

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

Bug ID: 107536
   Summary: [12 regression] Wrong 'not referenced' warning on
renamed variable
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

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

If a record has aspect Volatile_Full_Access, a renaming of one of the record’s
components will be reported as unreferenced even though it plainly is.

$ gnatmake -gnatwa -c -u -f renaming.adb -gnatl
gcc -c -gnatwa -gnatl renaming.adb

GNAT 12.2.0
Copyright 1992-2022, Free Software Foundation, Inc.


Compiling: renaming.adb
Source file time stamp: 2022-11-05 16:48:11
Compiled at: 2022-11-05 16:50:40

 1. procedure Renaming is
 2.
 3.type T is record
 4.   Item : Integer;
 5.end record;
 6.A_T : T;
 7.Item : Integer renames A_T.Item;
 8.
 9.type VFA_T is record
10.   Item : Integer;
11.end record
12.with Volatile_Full_Access;
13.A_VFA_T : VFA_T;
14.VFA_Item : Integer renames A_VFA_T.Item;
   |
>>> warning: renamed variable "VFA_Item" is not referenced [-gnatwu]

15.
16. begin
17.Item := 42;
18.VFA_Item := 42;
19. end Renaming;

 19 lines: No errors, 1 warning

This is also present on 12.1.0.

[Bug target/81036] -fcall-saved-X does not work for floating-point registers

[570070308 at qq dot com via Gcc-bugs]

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

--- Comment #2 from 。 <570070308 at qq dot com> ---
gcc 12.2 -fcall-saved-xmm0 not work too, target and host is x86-64.

[Bug gcov-profile/107537] New: gcov skips throw/fallthrough annotations for 'never executed' branches

[grregd at gmail dot com via Gcc-bugs]

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

Bug ID: 107537
   Summary: gcov skips throw/fallthrough annotations for 'never
executed' branches
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: grregd at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) 

$ gcov -v
gcov (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0

$ cat prog.cpp
#include 
void foo1()
{
try { 
std::cout << "here\n";
}
catch (...) {}
}
void foo2()
{
try {
std::cout << "there\n";
}
catch (...) {}
}
int main()
{
foo1();
}


$ g++ --coverage prog.cpp -o prog && ./prog && gcov -b -o . prog && cat
prog.cpp.gcov
here
File 'prog.cpp'
Lines executed:54.55% of 11
Branches executed:50.00% of 4
Taken at least once:25.00% of 4
Calls executed:40.00% of 5
Creating 'prog.cpp.gcov'

File '/usr/include/c++/11/iostream'
No executable lines
No branches
No calls

Removing 'iostream.gcov'

Lines executed:54.55% of 11
-:0:Source:prog.cpp
-:0:Graph:./prog.gcno
-:0:Data:./prog.gcda
-:0:Runs:1
-:1:#include 
-:2:
function _Z4foo1v called 1 returned 100% blocks executed 60%
1:3:void foo1()
-:4:{
-:5:try { 
1:6:std::cout << "here\n";
call0 returned 100%
branch  1 taken 100% (fallthrough)
branch  2 taken 0% (throw)
-:7:}
=:8:catch (...) {}
call0 never executed
1:9:}
-:   10:
function _Z4foo2v called 0 returned 0% blocks executed 0%
#:   11:void foo2()
-:   12:{
-:   13:try {
#:   14:std::cout << "there\n";
call0 never executed
branch  1 never executed
branch  2 never executed
-:   15:}
=:   16:catch (...) {}
call0 never executed
#:   17:}
-:   18:
function main called 1 returned 100% blocks executed 100%
1:   19:int main()
-:   20:{
1:   21:foo1();
call0 returned 100%
1:   22:}


Both functions foo1 and foo2 are essentially the same. foo1 is called once,
foo2 is never called. foo1 contains 2 branches in line 6, both branches labeled
with annotations (fallthrough/throw). The same code in foo2 in line 14 also has
2 branches, however these are not labeled with annotations.

Accoding to the source code of gcov it always skips throw/fallthrough
annotations for 'never executed' branches
(https://github.com/gcc-mirror/gcc/blob/50bc9185c2821350f0b785d6e23a6e9dcde58466/gcc/gcov.c#L2861)

Is there any reason why gcov skips throw/fallthrough annotations for branches
which were never executed?

According to my investigation, those flags are there and after modifying gcov
to print annotations always, it produces output with annotations for those
never executed branches. But perhaps those flags are invalid in this case and
can't be used?

In some specific conditions, those annotations would be very helpful for tools
like lcov or gcovr. Problem that occurrs in gcovr is described here -
https://github.com/gcovr/gcovr/issues/677#issuecomment-1282355159

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[vital.had at gmail dot com via Gcc-bugs]

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

Sergey Fedorov  changed:

   What|Removed |Added

 CC||vital.had at gmail dot com

--- Comment #18 from Sergey Fedorov  ---
(In reply to Iain Sandoe from comment #15)
> Sorry that there hasn't been much progress on this - it *was* top of my
> GCC11 TODO list, and then Apple Si. came along and torpedoed that...

Any updates ever since? It seems that we need blocks to build libdispatch, and
we need libdispatch on PPC to build some useful stuff.

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #17 from John David Anglin  ---
glibc issue:

commit 8c77e26ba8b360c851b2b9485bb4431aacc51ad1
Author: Szabolcs Nagy 
Date:   Tue Oct 11 13:23:25 2022 +0100

Remove unused scratch_buffer_dupfree

Turns out scratch_buffer_dupfree internal API was unused since

commit ef074bf0dccf493a5e8e21f71d9e7972ea9f
stdlib: Simplify buffer management in canonicalize

And the related test in malloc/tst-scratch_buffer had issues
so it's better to remove it completely.

[Bug analyzer/94355] support for C++ new expression

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

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to David Malcolm from comment #13)
> (In reply to Jonathan Wakely from comment #10)
> 
> [...snip...]
> 
> > As already noted above, new can't return null here, and there is no
> > dereference anyway. And the pointer isn't leaked, but it seems maybe the
> > analyzer doesn't know about destructors?
> 
> FWIW the analyzer (presumably incorrectly) considers the case where operator
> new returns NULL, and then attempts to write 0 to it.

Yeah, that's incorrect, the write is guaranteed to be OK because if new fails
it throws an exception before the write ever happens.

If a non-throwing form of new is used, e.g. p = new(std::nothrow) int(), then
the compiler *does* insert a null check before writing to it. So in the case
where a null check is necessary, the compiler inserts one.

See the -fcheck-new option:

  Check that the pointer returned by "operator new" is non-null before
attempting to modify the storage allocated.  This check is normally unnecessary
because the C++ standard specifies that "operator new" only returns 0 if it is
declared "throw()", in which case the compiler always checks the return value
even without this option.  In all other cases, when "operator new" has a
non-empty exception specification, memory exhaustion is signalled by throwing
"std::bad_alloc".  See also new (nothrow).

[Bug libstdc++/107538] New: std::pow(10, std::complex(NaN, 1)) aborts with -D_GLIBCXX_ASSERTIONS

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

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

Bug ID: 107538
   Summary: std::pow(10, std::complex(NaN, 1)) aborts with
-D_GLIBCXX_ASSERTIONS
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#define _GLIBCXX_ASSERTIONS
#include 
#include 

int main()
{
  double nan = std::numeric_limits::quiet_NaN();
  std::pow(10, std::complex(nan, 1));
}


/usr/include/c++/12/complex:703: std::complex<_Tp> std::polar(const _Tp&, const
_Tp&) [with _Tp = double]: Assertion '__rho >= 0' failed.
Aborted (core dumped)


The standard says that pow(x,y) should be exp(y * log(x)) so by using
std::polar we introduce a precondition that shouldn't be there.

[Bug libstdc++/107538] std::pow(10, std::complex(NaN, 1)) aborts with -D_GLIBCXX_ASSERTIONS

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

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

--- Comment #1 from Jonathan Wakely  ---
Taken from https://savannah.gnu.org/bugs/?55547#comment0 but I don't think
anybody ever reported it here.

[Bug libstdc++/107538] std::pow(10, std::complex(NaN, 1)) aborts with -D_GLIBCXX_ASSERTIONS

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Our use of polar seems to have been introduced specifically to deal with a
different edge case, see r0-50043-g1db0418ae570ef for PR libstdc++/10689.

When https://wg21.link/lwg2459 added the non-negative precondition to polar
that introduced this problem for pow.

[Bug c++/107539] New: internal compiler error: same canonical type node for different types

[franckbehaghel_gcc at protonmail dot com via Gcc-bugs]

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

Bug ID: 107539
   Summary: internal compiler error: same canonical type node for
different types
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: franckbehaghel_gcc at protonmail dot com
  Target Milestone: ---

Created attachment 53835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53835&action=edit
preprocessed source

When compiling gimp 2.10 with a fresh gcc version :
3ad2167bbac8ae83b1e91305b105ab5287bdac55 , I get the following error :

gimppaintcore-loops.cc: In lambda function:
gimppaintcore-loops.cc:472:61: internal compiler error: same canonical type
node for different types ‘AlgorithmTemplate’ and ‘AlgorithmTemplate’
  472 | visitor (identity> ());
  | ^~
0xc4306c comptypes(tree_node*, tree_node*, int)
/GIT_REPO/build/gcc/gcc/gcc/cp/typeck.cc:1717
0xb99717 template_args_equal(tree_node*, tree_node*, bool)
/GIT_REPO/build/gcc/gcc/gcc/cp/pt.cc:9284
0xb993fc template_args_equal(tree_node*, tree_node*, bool)
/GIT_REPO/build/gcc/gcc/gcc/cp/pt.cc:9247
0xb993fc comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
/GIT_REPO/build/gcc/gcc/gcc/cp/pt.cc:9329
0xba42c3 spec_hasher::equal(spec_entry*, spec_entry*)
/GIT_REPO/build/gcc/gcc/gcc/cp/pt.cc:1668
0xbecf73 hash_table::find_with_hash(spec_entry* const&, unsigned int)
/GIT_REPO/build/gcc/gcc/gcc/hash-table.h:926
0xbd4dac lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/GIT_REPO/build/gcc/gcc/gcc/cp/pt.cc:9945
0xc044ed finish_template_type(tree_node*, tree_node*, int)
/GIT_REPO/build/gcc/gcc/gcc/cp/semantics.cc:3755
0xb6a808 cp_parser_template_id
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:18368
0xb6aaab cp_parser_class_name
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:25826
0xb60f6e cp_parser_qualifying_entity
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:7183
0xb60f6e cp_parser_nested_name_specifier_opt
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:6865
0xb7a848 cp_parser_simple_type_specifier
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:19809
0xb5e98c cp_parser_postfix_expression
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:7640
0xb469bc cp_parser_binary_expression
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:10091
0xb47792 cp_parser_assignment_expression
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:10431
0xb4c9ee cp_parser_parenthesized_expression_list_elt
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:8054
0xb4cfb1 cp_parser_parenthesized_expression_list
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:8523
0xb5ef71 cp_parser_postfix_expression
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:7798
0xb469bc cp_parser_binary_expression
/GIT_REPO/build/gcc/gcc/gcc/cp/parser.cc:10091
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.


To reproduce : g++ -x c++ ccYvosm6.out1

Or copy&paste ccYvosm6.out1 in compiler explorer ( https://godbolt.org/ ).
Similar output is generated.


Regards,
Franck

[Bug c++/107539] internal compiler error: same canonical type node for different types

[franckbehaghel_gcc at protonmail dot com via Gcc-bugs]

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

--- Comment #1 from Franck Behaghel  
---
Created attachment 53836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53836&action=edit
main.cpp

reduced testcase :

g++ main.cpp 
main.cpp: In lambda function:
main.cpp:222:61: internal compiler error: same canonical type node for
different types ‘AlgorithmTemplate’ and
‘AlgorithmTemplate’
  222 | visitor (identity> ());
  | ^~

[Bug c++/107539] internal compiler error: same canonical type node for different types

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

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

--- Comment #2 from Andrew Pinski  ---
Note the ICE only shows up with checking enabled.  It is definitely a bug but
one which most users won't see.

[Bug c++/107539] internal compiler error: same canonical type node for different types

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 53837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53837&action=edit
reduced further

Here is even more reduced testcase.

[Bug c++/107539] [13 Regression] ICE, same canonical type node for different types with decltype inside an generic lambda inside a templated method of a templated class using a templated class argumen

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||needs-bisection
   Last reconfirmed||2022-11-06
Summary|internal compiler error:|[13 Regression] ICE, same
   |same canonical type node|canonical type node for
   |for different types |different types with
   ||decltype inside an generic
   ||lambda inside a templated
   ||method of a templated class
   ||using a templated class
   ||argument
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
Confirmed.
I am not 100% of the summary.
Also I am not 100% sure of it being a 13 regression but GCC 12 compiles this
fine even with -fchecking (GCC 13 compiles it also fine with -fno-checking).

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |MOVED