https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #5 from Richard Biener ---
Meh, similar to build_common_tree_nodes we should have a function to build
those common builtin decls in the middle-end. They are C ABI after all and
it's fine to use standard C named types there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
Richard Biener changed:
What|Removed |Added
Component|middle-end |c
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #6 from niXman ---
I think you don't understand me.
with your patch after preprocessing the `unlink_if_ordinary()` will look like:
```
int
unlink_if_ordinary (const char *name)
{
if (stricmp (name, "nul") == 0)
return 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108422
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183
--- Comment #9 from niXman ---
looks like it's fixed for x86_64-w64-mingw32.
I used the test from the: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
I run it on bash loop for the night and it successfully executed for ~179k
times.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
--- Comment #8 from Hongtao.liu ---
> But, if you're going to improve constant generation, please make it so that
> it can recognize not only the particular pattern described in this bug. More
> importantly, it should recognize the all-ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #10 from Roger Sayle ---
Status update: The x86 backend pieces of my proposed fix have been approved and
committed, but the remaining middle-end pieces have been making slow progress:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
--- Comment #4 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #3)
> (In reply to Kewen Lin from comment #2)
> > Unfortunately we don't have the testing coverage in testsuite for the
> > expected name vec_vsubcuq (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #4 from Ian Lance Taylor ---
Thanks Andrew, I'm testing the patch myself, but go ahead and commit if you are
satisfied with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-bisection |ABI, ice-checking,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #5 from Himal ---
(In reply to niXman from comment #4)
> (In reply to niXman from comment #2)
>
> > I don't think the patch is correct because for WIN32 platform `unlink()`
> > will never be called even for non-"nul" files.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404
--- Comment #4 from Iain Sandoe ---
Works for me - now the failing test cases produce a diagnostic;
/src-local/gcc-master/libgm2/libm2iso/RTco.cc:373:in initThread has caused
failed to set stack size attribute
Although it does not seem to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
--- Comment #6 from pefoley2 at pefoley dot com ---
The attached file repos the issue for me.
I avoided trying to compress it per https://gcc.gnu.org/bugs/ "An attached
archive (tar, zip, shar, whatever) containing all (or some) of the above."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427
--- Comment #2 from Andrew Pinski ---
So this is basically just a testsuite failure and it might just need
pcc_bitfield_type_matters check in the dg-warning for the target and such.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427
--- Comment #1 from Andrew Pinski ---
-mms-bitfields is enabled by default.
See TARGET_MS_BITFIELD_LAYOUT_P and
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/x86-Options.html#index-mms-bitfields
The layout of bitfields are different here ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #11 from H.J. Lu ---
Created attachment 54288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54288=edit
An updated patch
Try this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427
Bug ID: 108427
Summary: bitfield tests fail with missing warnings
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #17 from joseph at codesourcery dot com ---
It's not part of the ABI for the Arm 32-bit Architecture (AAPCS32).
https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst
You can file an issue there if you want, though I
Source: gcc-snapshot
Version: 20230108-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org
Hi,
gcc-snapshot in sid FTBFS on hurd-i386 due to that some patches are not
applied when building gcc-snapshot. After the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #9 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:a396a123596d82d4a2f14dc43a382cb17826411c
commit r13-5218-ga396a123596d82d4a2f14dc43a382cb17826411c
Author: H.J. Lu
Date: Mon Jan 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
> The following builtins are missing from the go front-end:
> BUILT_IN_CLZL
> BUILT_IN_CTZL
>
> The {,LL} versions are there but not the L version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #1 from Andrew Pinski ---
Simple fix until we figure out if the go front-end should be initializing these
builtins are not:
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 65b960461ae..0a0873bb572 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #35 from Florian Weimer ---
I backported the fixes for building glibc to 2.34 last week, I really expect
the testsuite to be clean there (on x86-64), and on later releases as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |13.0
-solaris2.11
Between 20230113 (9b6c624820050cd5e11b2fbd9c997f94b691295a) and 20230116
(b22634281fff352fcf71dd4fbbf6e6fcbc9a46cf),
Solaris/SPARC bootstrap broke compiling 64-bit strconv.lo:
during GIMPLE pass: evrp
In function 'strconv.atofHex':
go1: internal compiler error: Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #34 from Romain Geissler ---
>From what I wrote here
https://sourceware.org/pipermail/libc-alpha/2022-November/143633.html
apparently I already tried gcc 12 back in end of november 2022 and all float
issues in glibc testsuite were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #33 from Jakub Jelinek ---
Isn't that PR106805 ? More importantly, do those FAIL also with GCC 12 or just
the trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #32 from Romain Geissler ---
Hi,
Thanks for the fix, indeed it has fixed quite some glibc maths tests ;)
FYI, most likely it's totally unrelated to this bug, for right now with latest
gcc trunk and glibc trunk on x86-64, I still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #10 from Brecht Sanders ---
I can confirm GCC 12.2.0 builds fine with that patch and without CFLAG
-D__USE_MINGW_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #7 from Jakub Jelinek ---
Ah, the crash is actually when destructing the map_t temporary (D.5613) and
because it shares the stack slot with bias, it isn't surprising. So now to
figure out why the stack sharing happens and why even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #6 from Jakub Jelinek ---
The expand dump shows:
Partition 4: size 64 align 16
cov_jn
Partition 0: size 48 align 16
D.5642 biasD.5613
Partition 1: size 32 align 16
D.5615
Partition 2: size 32 align 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106075
--- Comment #6 from Jan Hubicka ---
The SRA issue is fixed now, but I am not quite sure what is desrable solution
here...
This blocks modref from understanding side effects of functions doing EH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
--- Comment #6 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #3)
> short a;
> int *null;
> int
> test(int val1, int val2)
> {
> a=1;
> int r = val1/val2;
> a=3;
> return r;
> }
Which is already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
--- Comment #4 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #3)
> We do not delete the stmt causing EH. Also the flag does not fix it:
Because it was broken in GCC 12 but was fixed on the trunk ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
Jan Hubicka changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Andrew Macleod changed:
What|Removed |Added
Attachment #54286|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
--- Comment #2 from anlauf at gcc dot gnu.org ---
I'm regtesting the following patch which fixes both cases:
diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
index 711e9178ad4..33794f0a858 100644
--- a/gcc/fortran/iresolve.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Code-Gen-Options.html#index-fdelete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
Bug ID: 108425
Summary: Invalid DSE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #10 from Andrew Macleod ---
Created attachment 54286
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54286=edit
proposed patch
There is a bug in the implementation of range-ops for shifts when the shift is
guaranteed to be out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #29 from niXman ---
Created attachment 54285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54285=edit
patch
another version of the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #9 from H.J. Lu ---
Created attachment 54284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54284=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #9 from Jan Hubicka ---
>
> Feel free to grab my initial patch in c#0 and upstream it. I tried that some
> time ago in the following email thread:
> https://gcc.gnu.org/pipermail/gcc/2021-May/236096.html
Actually I was shooting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #8 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610035.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #4 from niXman ---
(In reply to niXman from comment #2)
> I don't think the patch is correct because for WIN32 platform `unlink()`
> will never be called even for non-"nul" files.
moreover, according to the man:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #28 from niXman ---
in rebuilding stage...
one more issue: when the symlink called `gcc.exe` and I exec it as `gcc.exe
a.c` - all works as it should, but when I exec it as `gcc a.c` - I get the same
result as before - `fatal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #7 from Jakub Jelinek ---
Can you post it to gcc-patches?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424
Bug ID: 108424
Summary: [13 Regression] ICE in perform_integral_promotions, at
c/c-typeck.cc:2277
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
Bug ID: 108423
Summary: [12/13 Regression] ICE in make_ssa_name_fn, at
tree-ssanames.cc:360
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108422
Bug ID: 108422
Summary: [13 Regression] ICE: base pointer cycle detected
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421
Bug ID: 108421
Summary: ICE in get_expr_storage_size, at
fortran/interface.cc:2862
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
Bug ID: 108420
Summary: [13 Regression] ICE in check_charlen_present, at
fortran/iresolve.cc:98
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:1dfe15e534adba21e680b8128f0631e8054a5e42
commit r12-9047-g1dfe15e534adba21e680b8128f0631e8054a5e42
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183
Jonathan Wakely changed:
What|Removed |Added
CC||bjornsundin02 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
--- Comment #5 from Jakub Jelinek ---
Created attachment 54282
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54282=edit
gcc13-pr106523.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to niXman from comment #5)
> > > can't the example be checked using thread sanitizer?
> >
> > ... on Linux.
>
> The implementation is completely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
--- Comment #7 from niXman ---
> The implementation is completely different on linux, so that would require
> some code changes at least.
I didn't think so...
I think conceptually the solution looks the same for all platforms...
OK, got it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96844
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #27 from niXman ---
ah, got it.
thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #26 from Bill Zissimopoulos ---
(In reply to niXman from comment #25)
> updated patch there:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html
A couple of things:
1. If the GetFinalPathNameByHandle method fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106077
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:b1f30bf42d8d47228e52de998f3172b2f5dd7265
commit r13-5215-gb1f30bf42d8d47228e52de998f3172b2f5dd7265
Author: Jan Hubicka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
--- Comment #5 from niXman ---
(In reply to niXman from comment #4)
> I don't think it is mingw/windows related.
> can't the example be checked using thread sanitizer?
... on Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
niXman changed:
What|Removed |Added
CC||i.nixman at autistici dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #25 from niXman ---
updated patch there:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #3 from niXman ---
and I propose to use `strcasecmp()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #3 from Marek Polacek ---
Sorry about the long delay. Unfortunately I'm not sure yet how to fix it.
We have
Ref::inner (_EXPR )
which returns a ref and its arg is a temporary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
--- Comment #3 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #2)
> Yes, it's a typo, which makes the macro definition change to:
>
> #define vec_vsubcuqP __builtin_vec_vsubcuq
Yup.
> Unfortunately we don't have the testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #2 from niXman ---
@Himal
```
+#ifdef _WIN32
+if (stricmp (name, "nul") == 0)
+ return 1;
+#else
struct stat st;
if (lstat (name, ) == 0
&& (S_ISREG (st.st_mode) || S_ISLNK (st.st_mode)))
return unlink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #4 from m.cencora at gmail dot com ---
(In reply to Andrew Pinski from comment #3)
> I am 99% sure this is the same issue as pr98995 even though this is a crash.
> The ice is the same as PR 93711.
>
> This code has both an abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86426
--- Comment #11 from David Binderman ---
Probably still broken. One for Jason ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419
Bug ID: 108419
Summary: [13 Regression] Dead Code Elimination Regression at
-O2 since r13-440-g98e475a8f58
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108346
--- Comment #2 from Jan Hubicka ---
Sadly the win/loss cases does not seem to suggest a simple cost scheme.
We currently compute gather/scatter costs as static startup cost + cost per
lane and they are set to approximately match actual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108418
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108418
--- Comment #1 from Коренберг Марк ---
Sorry, but such kind of code happens as a result of C-code automatic
generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108418
Bug ID: 108418
Summary: gcc does not optimize trivial code
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #24 from niXman ---
BTW, I have no ideas how can I test the patch for UNC ('\\?\UNC' prefixed) ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #1 from m.cencora at gmail dot com ---
The problem seems to occur if base class has a tail padding, and derived class
is trying to reuse it to store its members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #23 from niXman ---
Created attachment 54280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54280=edit
patch
looks like I have finished!
boostrapped successfully as x86_64-mingw-w64.
@Bill Zissimopoulos, @Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #22 from Bill Zissimopoulos ---
(In reply to niXman from comment #21)
> another strange problem is that `CreateFile()` is able to open the special
> file `nul` for reading, but `GetFinalPathNameByHandle()` cannot get the full
> name
1 - 100 of 146 matches
Mail list logo
