[Bug c++/108231] malloc attribute vs extern "C" in a namespace and global and using of one in the namespace in the global one

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

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

--- Comment #1 from Andrew Pinski  ---
A little more reduced:
```
namespace g {
extern "C" void free(void *);
}
using g::free;
extern "C" void free (void *);

void foo1 (void *p) { free (p); }
void (*foo2) (void *) = free;
extern "C" {
void foo3 (void *p) { free (p); }
void (*foo4) (void *) = free;
}

extern "C" wchar_t * wcsdup (const wchar_t *s) 
__attribute__ ((__malloc__)) __attribute__ ((__malloc__ (free, 1)));
```

[Bug c++/108231] New: g++ mistakenly reports ambiguity between equivalent function declarations

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 108231
   Summary: g++ mistakenly reports ambiguity between equivalent
function declarations
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 54156
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54156&action=edit
test case

The attached code, i1.cc, contains two equivalent function declarations for the
function 'free'. They are equivalent because they have the same signature and
both have "C" linkage.

In lines 9, 10, 12, 13, referencing the function 'free' works fine.

However, referencing it in line 17, as part of a
__attribute__ ((__malloc__ (free, 1)))
attribute, leads to an error "‘malloc’ attribute argument 1 is ambiguous".

I would expect no error, no warning.

How to reproduce:
$ g++ -S i1.cc
i1.cc:17:67: error: ‘malloc’ attribute argument 1 is ambiguous
   17 | __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (free, 1)));
  |   ^
i1.cc:17:67: note: use a cast to the expected type to disambiguate

[Bug target/102993] -fcf-protection=full produces segfaulting code when targeting 32-bit x86 (i686)

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #9 from nightstrike  ---
Maybe it's time to disable sjlj support on windows.  dwarf or SEH is better on
average.

[Bug target/103327] Do not search MINGW in the search dir

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
This is intentional, and goes back to at least gcc 3.  The idea here is that
the path /mingw, which has to be in your sysroot and is usually a symlink to
$target, is the place to find the mingw-w64 headers and import libraries.  This
is the equivalent of /usr/local in a posix environment, which doesn't exist for
this target.

[Bug tree-optimization/108227] Unnecessary division when looping over array with size of elements not a power of two

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed. No compiler I tried does this transformation either.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to David Shin from comment #5)
> Indeed, no warning on trunk! Sorry, should have checked trunk version before
> reporting this.

No it is a good thing to report as we might want to get it fixed for gcc 12.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

[shin.david at gmail dot com via Gcc-bugs]

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

--- Comment #5 from David Shin  ---
Indeed, no warning on trunk! Sorry, should have checked trunk version before
reporting this.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization,
   ||needs-bisection,
   ||needs-reduction
  Known to work||13.0

--- Comment #4 from Andrew Pinski  ---
There is a missed jump threading before uninit1:

  if (_12 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 12992276]:
  D.172541 ={v} {CLOBBER(eol)};
  if (_12 == 0)
goto ; [51.12%]
  else
goto ; [48.88%]

   [local count: 6802844]:
  _130 = MEM[(const float &)&e];


The jump threading is fully fixed on the trunk for GCC 13.

For GCC 11, the jump threading is also missed but missed for a different
reason:
  _20 = __builtin_popcountl (_12);
...
  _24 = (long int) _20;
...
  if (_12 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 105119324]:
  if (_24 != 0)
goto ; [99.96%]
  else
goto ; [0.04%]

So there is no optimization of ((long)popcount(_12))!=0 into _12 != 0 in GCC 11
but that happens in GCC 12 and the jump threading is then missed but was fixed
in GCC 13.

The assert there causes the usage of _20 (d) in place of c in some cases which
causes some IR differences which influences the warning ...

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to David Shin from comment #2)
> The preprocessed source is 3.5M, which exceeds the file attachment size
> limit of 1000K.

You can compress it since it is above the max attachment size limit.

[Bug c/88944] Suggested alternative C stdbool.h

[jg at jguk dot org via Gcc-bugs]

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

Jonny Grant  changed:

   What|Removed |Added

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

--- Comment #9 from Jonny Grant  ---
gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0

Saw it is suggested and works.

[Bug c++/96412] format suggestion issue

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #2 from Jonny Grant  ---
Just posted this on bug 90205 but maybe more appropriate here
gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0

Another example, but suggesting the same %ld from a sizeof


printf("sizeof time_t %zu\n", sizeof(time_t));

broken.c:35:35: warning: format ‘%ld’ expects argument of type ‘long int’, but
argument 2 has type ‘long unsigned int’ [-Wformat=]
   35 | printf("sizeof unsigned int %ld\n", sizeof(unsigned int));
  | ~~^ 
  |   | |
  |   | long unsigned int
  |   long int
  | %ld

[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #11 from Jonny Grant  ---
That last comment was using 
gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0

[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #10 from Jonny Grant  ---
printf("sizeof time_t %ld\n", sizeof(time_t));

Another example, but suggesting the same %ld from a sizeof

broken.c:34:29: error: format ‘%ld’ expects argument of type ‘long int’, but
argument 2 has type ‘long unsigned int’ [-Werror=format=]
   34 | printf("sizeof time_t %ld\n", sizeof(time_t));
  |   ~~^ ~~
  | | |
  | | long unsigned int
  | long int
  |   %ld


Probably %zu is the appropriate format to be suggested?

[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #2 from Jonny Grant  ---

2022-12-26  Jonathan Grant 
* gcc/doc/extend.texi: Bugzilla 88860 - Clarify online manual
infelicities


>From 8b142ad8973dc67289e197e30966490a944e4819 Mon Sep 17 00:00:00 2001
From: Jonathan Grant 
Date: Mon, 26 Dec 2022 20:58:29 +
Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual infelicities

Signed-off-by: Jonathan Grant 
---
 gcc/doc/extend.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index adba057c190..88fc625050b 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9190,7 +9190,7 @@ have to optimize it to just @code{return 42 + 42;}.
 This section describes the syntax with which @code{__attribute__} may be
 used, and the constructs to which attribute specifiers bind, for the C
 language.  Some details may vary for C++ and Objective-C@.  Because of
-infelicities in the grammar for attributes, some forms described here
+limitations in the grammar for attributes, some forms described here
 may not be successfully parsed in all cases.

 There are some problems with the semantics of attributes in C++.  For
-- 
2.37.2

[Bug sanitizer/88997] Implicit constructors created with line numbers

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #3 from Jonny Grant  ---
(In reply to Jonny Grant from comment #2)
> 2022-12-26  Jonathan Grant 
>   * gcc/doc/extend.texi: Bugzilla 88860 - Clarify online manual 
> infelicities
>   
> 
> >From 8b142ad8973dc67289e197e30966490a944e4819 Mon Sep 17 00:00:00 2001
> From: Jonathan Grant 
> Date: Mon, 26 Dec 2022 20:58:29 +
> Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual infelicities


Darn, wrong ticket.

[Bug sanitizer/88997] Implicit constructors created with line numbers

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #2 from Jonny Grant  ---

2022-12-26  Jonathan Grant 
* gcc/doc/extend.texi: Bugzilla 88860 - Clarify online manual
infelicities


>From 8b142ad8973dc67289e197e30966490a944e4819 Mon Sep 17 00:00:00 2001
From: Jonathan Grant 
Date: Mon, 26 Dec 2022 20:58:29 +
Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual infelicities

Signed-off-by: Jonathan Grant 
---
 gcc/doc/extend.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index adba057c190..88fc625050b 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9190,7 +9190,7 @@ have to optimize it to just @code{return 42 + 42;}.
 This section describes the syntax with which @code{__attribute__} may be
 used, and the constructs to which attribute specifiers bind, for the C
 language.  Some details may vary for C++ and Objective-C@.  Because of
-infelicities in the grammar for attributes, some forms described here
+limitations in the grammar for attributes, some forms described here
 may not be successfully parsed in all cases.

 There are some problems with the semantics of attributes in C++.  For
-- 
2.37.2

[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #1 from Jonny Grant  ---
2022-12-26  Jonathan Grant 
* gcc/doc/extend.texi: Bugzilla 88860 - Add attribute format printf
example



>From 1668dc58206428ee92ff142bafb5f545dba029ae Mon Sep 17 00:00:00 2001
From: Jonathan Grant 
Date: Mon, 26 Dec 2022 21:02:35 +
Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual attribute format
 printf example

Signed-off-by: Jonathan Grant 
---
 gcc/doc/extend.texi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 88fc625050b..9b200c6f3a0 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9353,6 +9353,13 @@ __attribute__((noreturn)) void d0 (void),
 the @code{noreturn} attribute applies to all the functions
 declared; the @code{format} attribute only applies to @code{d1}.

+@noindent
+The following __attribute__ causes gcc to check run printf argument checks on
argument '3' which is 'const char * string format' (when visible at compile
time), against argument '4' the '...' variadic ellipsis.  In the example below,
arguments '1' and '2' are not checked.
+
+@smallexample
+void string_format(const char * prefix, size_t line, const char * const
format, ...) __attribute__ ((format (printf,3,4)));
+@end smallexample
+
 An attribute specifier list may appear immediately before the comma,
 @code{=} or semicolon terminating the declaration of an identifier other
 than a function definition.  Such attribute specifiers apply
-- 
2.37.2

[Bug ada/108202] [13 Regression] Many new acats fails on 32bit Darwin hosts.

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Sandoe  ---
it seems that this is fallout from a recent change in the trunk libgcc unwinder
(which we should not be using on Darwin)

fixed by:

r13-4870-ga846817739c1e7b930d593cd51963d6b46b5dfc6
r13-4883-g163f0f2267370575a9950e7e30a2c9cd72f559f0

and 
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609110.html

fix this by ensuring that we do not try to use the newly-built libgcc_s
unwinder for Ada executables that also pull in system libraries that refer to
the installed unwinder).

[Bug sanitizer/81649] Instrumentation Options page grammar

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #2 from Jonny Grant  ---
(In reply to Jakub Jelinek from comment #1)
> That doesn't look correct to me, as it is the option that ensures that the
> executables are linked against such a library, after all, it is the only
> purpose of the option.  Maybe we should just replace the " and t" with ". T".

That sounds good. I made a patch with your change and will email to
gcc-patches. If you could review please.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

[shin.david at gmail dot com via Gcc-bugs]

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

--- Comment #2 from David Shin  ---
The preprocessed source is 3.5M, which exceeds the file attachment size limit
of 1000K.

[Bug libstdc++/108210] error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #6 from niXman  ---
(In reply to niXman from comment #5)
> (In reply to niXman from comment #4)
> > (In reply to nightstrike from comment #2)
> > > Is this before or after this patch set was applied?
> > > 
> > > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html
> > 
> > I think it can be so because of unspecified `--enable-libstdcxx-threads=yes`
> > option.
> 
> will try to build now without that option.

it built successfully.

[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691

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

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

--- Comment #6 from Jerry DeLisle  ---
Regression testing looks good. The patch wiggles on the error messages given
for:

pr85779.f90

class_result_4.f90

In both cases they are reasonable.  I don't think we need any new test cases
since we are obviously exercising the patch.  If anyone insists I add the z1
and z2 cases to the testsuite, let me know and i will do so.

[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle  ---
After exploring a while and looking for other places I have concluded that for
invalid code Steve's patch is adequate.

I will regression test it next.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

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

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

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source?

[Bug c++/108230] New: assert() spuriously activates maybe-initialized warning

[shin.david at gmail dot com via Gcc-bugs]

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

Bug ID: 108230
   Summary: assert() spuriously activates maybe-initialized
warning
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shin.david at gmail dot com
  Target Milestone: ---

gcc-12.2 reports a maybe-uninitialized warning for the last line of the below
code if-and-only-if the macro ADD_ASSERT is defined:

#include 
#include 

using Array = Eigen::Array;

struct Tree {
  Array array;
  std::bitset<8> bitset;
};

auto func(Tree* tree) {
  int c = tree->array.rows();
  int d = tree->bitset.count();
#ifdef ADD_ASSERT
  assert(c==d);
#endif  // ADD_ASSERT
  Array e(c);
  for (int k = 0; k < d; ++k) e(k) = k;
  return e.sum() / (e + 1);
}

int main() {
  Tree tree;
  func(&tree);
}

This is a bug because adding this assert() should have no bearing on whether or
not the return statement might entail uninitialized memory usage.

gcc cmd1, generates warning: -Wmaybe-uninitialized -O3 -DADD_ASSERT
gcc cmd2, no warning:-Wmaybe-uninitialized -O3

Godbolt link, which includes full gcc warning output:
https://godbolt.org/z/nv11aaKb6

This example, convoluted as it seems, appears to be a minimal reproducible
example. For example:

- Removing the for-loop makes the warning appear with both gcc cmds
- Replacing the return expression with something simpler like (e + 1) makes the
warning disappear with both gcc cmds
- Replacing std::bitset with something else also makes the warning disappear
with both gcc cmds

Eigen library version is 3.4.0.

[Bug c++/93480] Defaulted <=> doesn't expand array elements

[rhalbersma at gmail dot com via Gcc-bugs]

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

--- Comment #9 from rhalbersma  ---
Could this fix also be back-ported to gcc 10?

[Bug c++/93480] Defaulted <=> doesn't expand array elements

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug target/108229] New: [13 Regression] unprofitable STV transform

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

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

Bug ID: 108229
   Summary: [13 Regression] unprofitable STV transform
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

In the following example, STV is making a very unprofitable transformation on
trunk, but not on gcc-12:

#include 
#include 

struct b {
struct b *next;
uint64_t data[511];
};

typedef uint64_t u64v2 __attribute__((vector_size(16)));
static inline
void vsum(u64v2 s[], uint64_t *x, size_t n)
{
typedef u64v2 u64v2_u __attribute__((may_alias));
u64v2_u *vx = (void *)x;
for (; n; vx += 4, n -= 8) {
s[0] += vx[0];
s[1] += vx[1];
s[2] += vx[2];
s[3] += vx[3];
}
}

uint64_t sum(struct b *b)
{
uint64_t s = 0;
u64v2 vs[4] = { 0 };
do {
vsum(vs, b->data + 7, 511-7);
#pragma GCC unroll(7)
for (int i = 0; i < 7; i++)
s += b->data[i];
} while ((b = b->next));
vs[0] += vs[1] + vs[2] + vs[3];
return s + vs[0][0] + vs[0][1];
}

gcc -O2 -mavx (-mavx is not necessary, plain -O2 also triggers it):

sum:
vpxor   xmm2, xmm2, xmm2
vmovdqa xmm1, xmm2
vmovdqa xmm3, xmm2
vmovdqa xmm0, xmm2
vmovdqa xmm5, xmm2
.L3:
lea rax, [rdi+64]
lea rdx, [rdi+4096]
.L2:
vpaddq  xmm0, xmm0, XMMWORD PTR [rax]
vpaddq  xmm3, xmm3, XMMWORD PTR [rax+16]
add rax, 64
vpaddq  xmm1, xmm1, XMMWORD PTR [rax-32]
vpaddq  xmm2, xmm2, XMMWORD PTR [rax-16]
cmp rdx, rax
jne .L2
vmovq   xmm6, QWORD PTR [rdi+16]
vmovq   xmm4, QWORD PTR [rdi+8]
vpaddq  xmm4, xmm4, xmm6
vpaddq  xmm4, xmm4, xmm5
vmovq   xmm5, QWORD PTR [rdi+24]
vpaddq  xmm4, xmm4, xmm5
vmovq   xmm5, QWORD PTR [rdi+32]
vpaddq  xmm4, xmm4, xmm5
vmovq   xmm5, QWORD PTR [rdi+40]
vpaddq  xmm4, xmm4, xmm5
vmovq   xmm5, QWORD PTR [rdi+48]
vpaddq  xmm4, xmm4, xmm5
vmovq   xmm5, QWORD PTR [rdi+56]
mov rdi, QWORD PTR [rdi]
vpaddq  xmm5, xmm4, xmm5
testrdi, rdi
jne .L3
vpaddq  xmm1, xmm1, xmm2
vpaddq  xmm0, xmm0, xmm3
vpaddq  xmm0, xmm0, xmm1
vmovdqa xmm1, xmm0
vpsrldq xmm0, xmm0, 8
vpaddq  xmm0, xmm1, xmm0
vpaddq  xmm0, xmm0, xmm5
vmovq   rax, xmm0
ret

compare with gcc -O2 -mavx -mno-stv:

sum:
vpxor   xmm2, xmm2, xmm2
xor edx, edx
vmovdqa xmm1, xmm2
vmovdqa xmm3, xmm2
vmovdqa xmm0, xmm2
.L3:
lea rax, [rdi+64]
lea rcx, [rdi+4096]
.L2:
vpaddq  xmm0, xmm0, XMMWORD PTR [rax]
vpaddq  xmm3, xmm3, XMMWORD PTR [rax+16]
add rax, 64
vpaddq  xmm1, xmm1, XMMWORD PTR [rax-32]
vpaddq  xmm2, xmm2, XMMWORD PTR [rax-16]
cmp rcx, rax
jne .L2
mov rax, QWORD PTR [rdi+16]
add rax, QWORD PTR [rdi+8]
add rdx, rax
add rdx, QWORD PTR [rdi+24]
add rdx, QWORD PTR [rdi+32]
add rdx, QWORD PTR [rdi+40]
add rdx, QWORD PTR [rdi+48]
add rdx, QWORD PTR [rdi+56]
mov rdi, QWORD PTR [rdi]
testrdi, rdi
jne .L3
vpaddq  xmm0, xmm0, xmm3
vpaddq  xmm1, xmm1, xmm2
vpaddq  xmm0, xmm0, xmm1
vmovq   rcx, xmm0
vpextrq rax, xmm0, 1
add rax, rcx
add rax, rdx
ret

[Bug c++/99631] decltype of non-type template-parameter shouldn't be const

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||danakj at orodu dot net

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

[Bug c++/108169] class type template parameters are const in GCC (differs from other compilers)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Andrew Pinski  ---
Yes it is a dup of bug 99631.

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

[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #13 from cqwrteur  ---
(In reply to cqwrteur from comment #12)
> (In reply to nightstrike from comment #10)
> > (In reply to cqwrteur from comment #5)
> > > I think the copy to bin behavior should be removed. It should be just like
> > > normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32.
> > 
> > This is a feature of Windows.  Windows will find dlls in PATH, not in lib
> > directories.
> > 
> > Multilib toolchains do face issues with versioned runtime libraries.  You
> > can try configuring with --enable-version-specific-runtime-libs.  Generally
> > speaking, it's easier to just build two separate toolchains than to try
> > getting multilib to work.  I made the mistake of pushing for multilib to be
> > enabled by default, and we never got it working quite well.
> > 
> > Anyway, I don't think this is a bug as stated.
> 
> yes this is a bug. because I can fix it easily.
> 
> You are wrong. Because cross toolchain for multilib would put DLLs in the
> lib and lib32, not bin

https://github.com/cppfastio/fast_io/blob/master/examples/0009.filesystem/gccx86canadianfix.cc

[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #12 from cqwrteur  ---
(In reply to nightstrike from comment #10)
> (In reply to cqwrteur from comment #5)
> > I think the copy to bin behavior should be removed. It should be just like
> > normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32.
> 
> This is a feature of Windows.  Windows will find dlls in PATH, not in lib
> directories.
> 
> Multilib toolchains do face issues with versioned runtime libraries.  You
> can try configuring with --enable-version-specific-runtime-libs.  Generally
> speaking, it's easier to just build two separate toolchains than to try
> getting multilib to work.  I made the mistake of pushing for multilib to be
> enabled by default, and we never got it working quite well.
> 
> Anyway, I don't think this is a bug as stated.

yes this is a bug. because I can fix it easily.

You are wrong. Because cross toolchain for multilib would put DLLs in the lib
and lib32, not bin

[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #11 from nightstrike  ---
Possible duplicate of PR39947

[Bug c++/94924] Default equality operator for C-array compares addresses, not data

[rhalbersma at gmail dot com via Gcc-bugs]

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

--- Comment #4 from rhalbersma  ---
Is there any chance that this bug fix can be backported to gcc 10 also?

[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #10 from nightstrike  ---
(In reply to cqwrteur from comment #5)
> I think the copy to bin behavior should be removed. It should be just like
> normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32.

This is a feature of Windows.  Windows will find dlls in PATH, not in lib
directories.

Multilib toolchains do face issues with versioned runtime libraries.  You can
try configuring with --enable-version-specific-runtime-libs.  Generally
speaking, it's easier to just build two separate toolchains than to try getting
multilib to work.  I made the mistake of pushing for multilib to be enabled by
default, and we never got it working quite well.

Anyway, I don't think this is a bug as stated.

[Bug libstdc++/108228] New: /usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_ZN9__gnu_cxx21zoneinfo_dir_ov errideEv'

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

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

Bug ID: 108228
   Summary: /usr/lib/pa20_64/dld.sl: Unsatisfied code symbol
'_ZN9__gnu_cxx21zoneinfo_dir_ov errideEv'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jwakely.gcc at gmail dot com
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../ exceptions_enabled16691.cc
-fdiagnostics-plain-output -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-h
pux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/
hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/l
ibsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu
/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -S -o
exceptions_enabled
16691.s
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol
'_ZN9__gnu_cxx21zoneinfo_dir_ov
errideEv' in load module
'/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libs
tdc++-v3/src/.libs/libstdc++.sl.6'.
compiler exited with status 1
FAIL: g++.dg/compat/abi/bitfield1 cp_compat_main_tst.o compile

[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend since r12-299-ga0fdff3cf33f72

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #4 from nightstrike  ---
This appears to be fixed in GCC 13

[Bug libstdc++/108210] error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #5 from niXman  ---
(In reply to niXman from comment #4)
> (In reply to nightstrike from comment #2)
> > Is this before or after this patch set was applied?
> > 
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html
> 
> I think it can be so because of unspecified `--enable-libstdcxx-threads=yes`
> option.

will try to build now without that option.

[Bug libstdc++/108210] error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #4 from niXman  ---
(In reply to nightstrike from comment #2)
> Is this before or after this patch set was applied?
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html

I think it can be so because of unspecified `--enable-libstdcxx-threads=yes`
option.

[Bug libstdc++/108210] error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #3 from niXman  ---
(In reply to cqwrteur from comment #0)
> /home/cqwrteur/toolchains_build/gcc/libstdc++-v3/src/c++20/tzdb.cc:565:5:
> error: 'mutex' does not name a type; did you mean 'minutes'?
>   565 | mutex infos_mutex;
>   | ^
>   | minutes
> 
> Win32 thread model does not provide mutex, lock_guard, and other threading
> mechanism.
> 
> However. this can be implemented easily with win32 CriticalSection API.
> https://github.com/cppfastio/fast_io/blob/master/include/fast_io_hosted/
> threads/mutex/win32_critical_section.h

please provide the configure's options you used.

[Bug libstdc++/108210] error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||i.nixman at autistici dot org,
   ||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
Is this before or after this patch set was applied?

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html

[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #7 from Brecht Sanders  
---
Any update on this?
This issue makes GCC12 really slow on Windows because PCH support doesn't work.

If mman-win32 support could be made to work it might solve this issue. The
problem is that this requires linking with -lmman (and this flag needs to be
near the end of the list of linked libraries)

[Bug target/107548] STV doesn't consider vec_select

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||roger at nextmovesoftware dot 
com
   Target Milestone|--- |13.0

--- Comment #3 from Roger Sayle  ---
This should now be fixed/implemented on mainline.

[Bug libstdc++/108222] windows 9x support for libstdc++ threads and probably other features like std::filesystem

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #8 from cqwrteur  ---
then what's wrong with me myself submitting patches to fix them? tbh. i would
like to help maintaining future windows support for libstdc++ since i think i
am probably more familiar than you on windows.

Like nt openat etc

Get Outlook for Android

From: redi at gcc dot gnu.org 
Sent: Monday, December 26, 2022 5:31:22 AM
To: unlv...@live.com 
Subject: [Bug libstdc++/108222] windows 9x support for libstdc++ threads and
probably other features like std::filesystem

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Stop reopening. I already said in Bug 107930 and older bugs that this isn't
going to be supported. If you want to build for win95 you need to use a
compiler that supports that OS, but GCC does not.

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.

[Bug libstdc++/108222] windows 9x support for libstdc++ threads and probably other features like std::filesystem

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Stop reopening. I already said in Bug 107930 and older bugs that this isn't
going to be supported. If you want to build for win95 you need to use a
compiler that supports that OS, but GCC does not.

[Bug c++/108169] class type template parameters are const in GCC (differs from other compilers)

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

 CC||johelegp at gmail dot com

--- Comment #8 from Johel Ernesto Guerrero Peña  ---
This seems to be the same as Bug 99631.

[Bug libstdc++/103445] build failure for old versions of mingw32 (not mingw-w64)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Just don't use old junk, or stick to older versions of gcc.

[Bug libstdc++/100376] __gnu_cxx::stdio_filebuf does not work correctly on windows for GCC 12

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
User error

[Bug libstdc++/108222] windows 9x support for libstdc++ threads and probably other features like std::filesystem

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

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

--- Comment #6 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #5)
> It's not a supported target.

Then how do I port programs that would run on windows 95?

[Bug libstdc++/108222] windows 9x support for libstdc++ threads and probably other features like std::filesystem

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
It's not a supported target.

[Bug tree-optimization/108227] Unnecessary division when looping over array with size of elements not a power of two

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Thomas Koenig  ---
This could also impact Fortran's array descriptor reform if we ever switch to
the specified BIND(C) descriptors as our native format - there, we would have
generate loops just like that, preferably without division.

[Bug tree-optimization/108227] New: Unnecessary division when looping over array with size of elements not a power of two

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

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

Bug ID: 108227
   Summary: Unnecessary division when looping over array with size
of elements not a power of two
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Consider

typedef struct coord {
  double x, y, z;
} coord;

void foo(coord *from, coord *to)
{
  unsigned long int n = to - from;
  for (unsigned long int i=0; i < n; i++)
{
  from[i].x = from[i].x + 1.0;
}
}

void bar (coord *from, coord *to)
{
  char *c_from = (char *) from, *c_to = (char *) to;
  coord *p = from;
  long int c_n = c_to - c_from;
  for (long int i=0; i < c_n; i+= sizeof(coord))
{
  p->x = p->x + 1.0;
  p++;
}
}

The code is functionally equivalent, but the assembly somewhat different:

foo has

foo:
.LFB0:
.cfi_startproc
movabsq $-6148914691236517205, %rax
movq%rsi, %rdx
subq%rdi, %rdx
sarq$3, %rdx
imulq   %rax, %rdx
cmpq%rdi, %rsi
je  .L1
movsd   .LC0(%rip), %xmm1
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
movsd   (%rdi), %xmm0
addq$1, %rax
addq$24, %rdi
addsd   %xmm1, %xmm0
movsd   %xmm0, -24(%rdi)
cmpq%rdx, %rax
jb  .L3
.L1:
ret

so it first divides by 12 (efficiently) to determine n. There are 7
instructions in the loop itself.

bar has

bar:
.LFB1:
.cfi_startproc
subq%rdi, %rsi
testq   %rsi, %rsi
jle .L6
movsd   .LC0(%rip), %xmm1
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L8:
movsd   (%rdi,%rax), %xmm0
addsd   %xmm1, %xmm0
movsd   %xmm0, (%rdi,%rax)
addq$24, %rax
cmpq%rax, %rsi
jg  .L8
.L6:
ret

no need to divide, and one instruction less in the loop.

I would expect foo to match bar.

[Bug c/108224] Suggest stdlib.h header for rand

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #5 from Jonny Grant  ---
(In reply to Sam James from comment #4)
> (In reply to Jonny Grant from comment #3)
> > Great! I just saw it is the same for random(), srandom(), initstate(),
> > setstate()
> > 
> > Is there an easy way to add them all based on the C API to save opening
> > separate tickets?
> > 
> > I added those :
> 
> Could you send the patch to gcc-patches (the mailing list)? Thanks.

Sure, just sent :-)

[Bug c++/42011] linker error with typedef struct

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
 Status|NEW |RESOLVED
   Keywords||ABI
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=55877
 Resolution|--- |FIXED

--- Comment #3 from Andrew Pinski  ---
Fixed in GCC 4.9.0 by r0-128625-g944b63dbc00d48
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55877#c10) .

[Bug c++/7221] wrong linkage of typedef-named classes

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.8.5
  Known to work||4.9.0
   Target Milestone|--- |4.9.0