Tuesday, April 23, 2025
Richard Sandiford wrote:
> Thanks the summary. Does the entry below look ok?
>
> Support has been added for the AArch64 MinGW target
>(aarch64-w64-mingw32). At present, this target
>supports C and C++ for base Armv8-A, but with some caveats:
>
> Although
Tuesday, April 22, 2025
"Richard Sandiford" wrote:
> + Support has been added for the AArch64 MinGW target
> + (aarch64-w64-mingw32). At present, this target only
> + supports C, but further work is planned.
> +
Thank you for the release summary for AArch64 and for mentioning the new
> This patch series adds SEH, stack unwinding and C++ exceptions
> implementation to the aarch64-w64-mingw32 target.
This patch series is supported by the binutils patch series.
https://sourceware.org/pipermail/binutils/2025-April/140495.html
The Boost library testing identified some issues that
-
Phillip Jordan pmj
Tim Josling timjosling
Victor Kaplanskyvictork
+Evgeny Karpov -
Filip Kastl pheeck
Geoffrey Keating
From 69ce2026b10711b32595d58e23f92f54e6c718c2 Mon Sep 17 00:00:00 2001
From: Evgeny Karpov
Date: Fri, 15 Nov 2024 13:14:18 +0100
Subject: [PATCH v1 4/4] aarch64: Add SEH, stack unwinding and C++ exceptions
This patch reuses the existing SEH, stack unwinding and C++ exceptions
from ix86 and
From 4274d1126a1aa60d16dca1cbf7dde1c5ee344bf7 Mon Sep 17 00:00:00 2001
From: Evgeny Karpov
Date: Fri, 15 Nov 2024 13:36:41 +0100
Subject: [PATCH v1 3/4] Rename SEH functions for reuse in AArch64
This patch renames functions related to SEH functionality. These
functions will be reused in the
v1-0003-Rename-SEH-functions-for-reuse-in-AArch64.patch
Description: v1-0003-Rename-SEH-functions-for-reuse-in-AArch64.patch
This patch adds stdcall and cdecl attributes, which might be used for
DLL export/import in MinGW.
gcc/ChangeLog:
* config/aarch64/aarch64.cc: Update.
---
gcc/config/aarch64/aarch64.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64
The patch bypasses missing prototypes warnings in MinGW until it is
fixed.
libgcc/ChangeLog:
* config/aarch64/t-mingw: Update.
---
libgcc/config/aarch64/t-mingw | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcc/config/aarch64/t-mingw b/libgcc/config/aarch64/t-min
eek.
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668484.html
This patch series is supported by the binutils patch series, which
will be posted next week and a link will be provided.
Prepared, refactored and validated by
Radek Barton ,
Martin Vejbora (Microsoft) and
Evgeny Karpov
Coau
Thursday, November 14, 2024
Richard Sandiford wrote:
> Ah, ok, great! Could you add yourself to MAINTAINERS in that case?
Sure, I will do that.
Regards,
Evgeny
Tuesday, November 12, 2024
Richard Sandiford wrote:
> Thanks for the update. As usual, I can only comment on the GCC internals,
> without much knowledge of how mingw actually behaves. On that basis,
> I've replied to two of the patches individually, but the series otherwise
> looks good to me.
The patch bypasses hidden attribute warnings in MinGW until it is
implemented.
libgcc/ChangeLog:
* config.host: Update.
* config/aarch64/t-mingw: New.
---
libgcc/config.host| 1 +
libgcc/config/aarch64/t-mingw | 2 ++
2 files changed, 3 insertions(+)
create mode 1006
The patch reuses the configuration for LTO from ix86 and adds the
aarch64 architecture to the list of supported COFF headers.
gcc/ChangeLog:
* config/aarch64/cygming.h (TARGET_ASM_LTO_START): New.
(TARGET_ASM_LTO_END): Likewise.
* config/i386/cygming.h (TARGET_ASM_LTO_STAR
This patch allows using an offset of up to 16MB in "symbol + offset",
instead of 1MB limit that was used previously.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_load_symref_appropriately):
Update.
---
gcc/config/aarch64/aarch64.cc | 19 +++
1 file changed,
LOCAL_LABEL_PREFIX has been changed to help the assembly
compiler recognize local labels. Emitting locals has been
replaced with the .lcomm directive to declare uninitialized
data without defining an exact section. Functions and objects
were missing declarations. Binutils was not able to distinguis
Symbols using GOT are not supported by the aarch64-w64-mingw32
target and should be excluded from the code models.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_classify_symbol):
Disable GOT for PECOFF target.
---
gcc/config/aarch64/aarch64.cc | 6 --
1 file changed, 4
The patch resolves compilation issues for the C++ language. Previous
patch series contributed to C++ as well, however, C++ could not be
tested until we got a C++ compiler and could build at least a "Hello
World" C++ program, and in reality, more than that.
Another issue has been fixed in the libst
ded.
- Bypass hidden attribute warnings in MinGW until it is implemented.
Regards,
Evgeny
Evgeny Karpov (8):
Support weak references
aarch64: Add debugging information
aarch64: Add minimal C++ support
aarch64: Exclude symbols using GOT from code models
aarch64: Multiple adjustments t
This patch enables DWARF and allows compilation with debugging
information by using "gcc -g". The unwind info is disabled for
the moment and will be revisited after SEH implementation for
the target.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (TARGET_ASM_UNALIGNED_HI_OP):
Enable D
;dr"
.globl .refptr.weak_fn2
.linkonce discard
.refptr.weak_fn2:
.quad weak_fn2
This is the first commit in the third patch series with SMALL code
model fixes, optimization fixes, LTO, and minimal C++ enablement.
Prepared, refactored and validated by
Radek Barton and
Evgeny Karpov
Con
Patch 5 has been changed to
"," HOST_WIDE_INT_PRINT_UNSIGNED "\n",
Patch 6 has been updated here
Patch 7 will be dropped.
Patch 9 will be dropped.
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667205.html
And the patch series will be extended with one more patch to handle an issue
wi
Wednesday, October 30, 2024
Richard Sandiford wrote:
> So for the change in question, I was expecting, say, a 1024-byte-aligned
> float[3] to be defined using:
>
> .lcomm array, 1024
Thank you for noticing this. The patch series has been rebased from the
upstream
before reproducing the
> Symbols in the object file also look good.
>
> 015 SECT2 notype External | large_aligned_array
> 016 0010 SECT2 notype External | large_aligned_array2
> 017 0020 SECT2 notype External | large_aligned_array3
> 018 0040 SECT2 notype Exte
Tuesday, October 29, 2024
Richard Sandiford wrote:
> Hmm, I see. I think this is surprising enough that it would be worth
> a comment. How about:
>
> /* Since the assembly directive only specifies a size, and not an
> alignment, we need to follow the default ASM_OUTPUT_LOCAL behavior
>
Thursday, September 19
Richard Sandiford wrote:
>
> Thanks for the update. Aside from the points raised in the discussion
> about patches 5, 6, and 9 (and taking into account what you said about
> patch 7), the series looks good.
Thank you for the review Richard.
Patch 5 has been changed to
",
> Wednesday, October 23, 2024
> Richard Sandiford wrote:
>
>> Or, even if that does work, it isn't clear to me why patching
>> ASM_OUTPUT_ALIGNED_LOCAL is a complete solution to the problem.
>
> This patch reproduces the same code as it was done without declaring
> ASM_OUTPUT_ALIGNED_LOCAL.
> AS
Wednesday, October 23, 2024
Richard Sandiford wrote:
> Or, even if that does work, it isn't clear to me why patching
> ASM_OUTPUT_ALIGNED_LOCAL is a complete solution to the problem.
This patch reproduces the same code as it was done without declaring
ASM_OUTPUT_ALIGNED_LOCAL.
ASM_OUTPUT_ALIGNE
Tuesday, October 22, 2024
Richard Sandiford wrote:
>> If ASM_OUTPUT_ALIGNED_LOCAL uses an alignment less than BIGGEST_ALIGNMENT,
>> it might trigger a relocation issue.
>>
>> relocation truncated to fit: IMAGE_REL_ARM64_PAGEOFFSET_12L
>
> Sorry to press the issue, but: why does that happen?
#def
Thursday, September 19, 2024
Richard Sandiford wrote:
> abs_hwi (const_offset) (since const_offset has HOST_WIDE_INT type).
abs_hwi has been applied.
> It might be easier to pass base and const_offset from the caller
> (aarch64_expand_mov_immediate). We are then guaranteed that the
> offset is
Thursday, October 17, 2024
Richard Sandiford wrote:
For instance:
float __attribute__((aligned (32))) large_aligned_array[3];
BIGGEST_ALIGNMENT could be up to 512 bits on x64.
This patch has been added to cover this case without needing to
change the FFmpeg code.
>>>
Thursday, September 19, 2024
Richard Sandiford wrote:
>> For instance:
>> float __attribute__((aligned (32))) large_aligned_array[3];
>>
>> BIGGEST_ALIGNMENT could be up to 512 bits on x64.
>> This patch has been added to cover this case without needing to
>> change the FFmpeg code.
>
> What goes
Friday, September 13, 2024
Martin Storsjö wrote:
>> When the offset is >= 1MB:
>>
>> adrp x0, symbol + offset % (1 << 20) // it prevents relocation overflow in
>> IMAGE_REL_ARM64_PAGEBASE_REL21
>> add x0, x0, (offset & ~0xf) >> 12, lsl #12 // a workaround to support
>> 4GB offset
>> add x0,
Thursday, September 12, 2024
Martin Storsjö wrote:
> This looks very reasonable - I presume this will make sure that you only
> use the other code form if the offset actually is larger than 1 MB.
>
> For the case when the offset actually is larger than 1 MB, I guess this
> also ends up generating
This patch is not needed anymore, more information here.
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662903.html
Regards,
Evgeny
The current binutils implementation does not support offset up to 4GB in
IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
This is related to differences in ELF and COFF relocation records.
There are ways to fix this. This work on relocation change will be extracted to
a separate bin
Friday, September 6, 2024
Martin Storsjö wrote:
> Sorry, but no.
>
> You can't just redefine how relocations in your object file format works,
> just because you feel like it.
This patch changes how symbol with offset will be emitted.
It will change:
adrp x0, symbol + offset
to:
adrp x0, sym
In some cases, the alignment can be bigger than BIGGEST_ALIGNMENT.
The issue was detected while building FFmpeg.
It creates structures, most likely for AVX optimization.
For instance:
float __attribute__((aligned (32))) large_aligned_array[3];
BIGGEST_ALIGNMENT could be up to 512 bits on x64.
Th
The patch reuses the configuration for LTO from ix86 and adds the
aarch64 architecture to the list of supported COFF headers.
gcc/ChangeLog:
* config/aarch64/cygming.h (TARGET_ASM_LTO_START): New.
(TARGET_ASM_LTO_END): Likewise.
* config/i386/cygming.h (TARGET_ASM_LTO_STAR
The anchors have been disabled as they use symbol + offset, which is
not applicable for COFF AArch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (TARGET_MIN_ANCHOR_OFFSET):
Keep default TARGET_MAX_ANCHOR_OFFSET for PECOFF target.
(TARGET_MAX_ANCHOR_OFFSET): Likewise.
---
aarch64.cc has been updated to prevent emitting "symbol + offset"
for SYMBOL_SMALL_ABSOLUTE for the PECOFF target. "symbol + offset"
cannot be used in relocations for aarch64-w64-mingw32 due to
relocation requirements.
Instead, it will adjust the address by an offset with the
"add" instruction.
T
LOCAL_LABEL_PREFIX has been changed to help the assembly
compiler recognize local labels. Emitting locals has been
replaced with the .lcomm directive to declare uninitialized
data without defining an exact section. Functions and objects
were missing declarations. Binutils was not able to distinguis
The patch resolves compilation issues for the C++ language. Previous
patch series contributed to C++ as well, however, C++ could not be
tested until we got a C++ compiler and could build at least a "Hello
World" C++ program, and in reality, more than that.
Another issue has been fixed in the libst
Symbols using GOT are not supported by the aarch64-w64-mingw32
target and should be excluded from the code models.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_classify_symbol):
Disable GOT for PECOFF target.
---
gcc/config/aarch64/aarch64.cc | 6 --
1 file changed, 4
This patch enables DWARF and allows compilation with debugging
information by using "gcc -g". The unwind info is disabled for
the moment and will be revisited after SEH implementation for
the target.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (TARGET_ASM_UNALIGNED_HI_OP):
Enable D
The patch adds support for weak references. The original MinGW
implementation targets ix86, which handles weak symbols differently
compared to AArch64. In AArch64, the weak symbols are replaced by
other symbols which reference the original weak symbols, and the
compiler does not track the original
Hello,
Thank you for reviewing v1!
v2 Changes:
- Add extra comments and extend patch descriptions.
- Extract libstdc++ changes to a separate patch.
- Minor style refactoring based on the reviews.
- Unify mingw_pe_declare_type for functions and objects.
Regards,
Evgeny
Evgeny Karpov (9
Monday, September 2, 2024
Richard Sandiford wrote:
> Thanks for submitting this. I've responded with minor comments to
> some individual patches, but the rest (1, 2, 7, and 8) look good to
> me as-is.
Thank you for the review. The patch series v2 will be submitted after
the validation.
Regards
Monday, September 2, 2024
Richard Sandiford wrote:
> I realise this is pre-existing, bue the last line should probably be:
>
> fprintf ((FILE), "," HOST_WIDE_INT_PRINT_UNSIGNED "\n", (ROUNDED)))
>
> to avoid silent truncation. (Even if the format only supports 32-bit
> code and data, it's bett
Monday, September 2, 2024
Richard Sandiford wrote:
> On patch 1, do you have a reference for how AArch64 and x86 handle weak
> references for MinGW? The code looks good, but I didn't really follow
> why it was doing what it was doing.
Monday, September 2, 2024
Martin Storsjö
>> The patch adds
Monday, September 4, 2024
Martin Storsjö wrote:
>> Let's consider the following example, when symbol is located at 3072.
>>
>> 1. Example without the fix
>> compilation time
>> adrp x0, (3072 + 256) & ~0xFFF // x0 = 0
>> add x0, x0, (3072 + 256) & 0xFFF // x0 = 3328
>>
>> linking t
Monday, September 2, 2024
Andrew Pinski wrote:
> Could you expand on this and why you think disabling is correct?
> It is so you could do:
> adrp x0, .LANCHOR0
> add x2, x0, :lo12:.LANCHOR0
> ldr w1, [x0, #:lo12:.LANCHOR0]
> ldr w0, [x2, 4]
>
> Rathe
Monday, September 2, 2024
Martin Storsjö wrote:
> The only non-obvious thing, is that for IMAGE_REL_ARM64_PAGEBASE_REL21,
> i.e. "adrp" instructions, the immediate that gets stored in the
> instruction, is the byte offset to the symbol.
>
> After linking, when the instruction is interpreted at ex
Monday, September 2, 2024 5:36 PM
Richard Sandiford wrote:
>> In some cases, the alignment can be bigger than BIGGEST_ALIGNMENT.
>> The patch handles these cases.
>>
>> gcc/ChangeLog:
>>
>>* config/aarch64/aarch64-coff.h (ASM_OUTPUT_ALIGNED_LOCAL):
>>Change alignment.
>
> Can you
Monday, September 2, 2024 5:00 PM
Richard Sandiford wrote:
> I think we should instead patch the callers that are using
> aarch64_symbol_binds_local_p for GOT decisions. The function itself
> is checking for a more general property (and one that could be useful
> in other contexts).
The patch h
Monday, September 2, 2024 3:15 PM
Kyrylo Tkachov wrote:
>> libstdc++-v3/ChangeLog:
>>
>> * src/c++17/fast_float/fast_float.h (defined): Adjust a condition
>> for AArch64.
>
> libstdc++ is reviewed on its own list (CC’ed here) so I’d suggest splitting
> the libstdc++-v3 hunk into its
In some cases, the alignment can be bigger than BIGGEST_ALIGNMENT.
The patch handles these cases.
gcc/ChangeLog:
* config/aarch64/aarch64-coff.h (ASM_OUTPUT_ALIGNED_LOCAL):
Change alignment.
---
gcc/config/aarch64/aarch64-coff.h | 10 ++
1 file changed, 10 insertions(+)
The patch reuses the configuration for LTO from ix86 and adds the
aarch64 architecture to the list of supported COFF headers.
gcc/ChangeLog:
* config/aarch64/cygming.h (TARGET_ASM_LTO_START): New.
(TARGET_ASM_LTO_END): Likewise.
* config/i386/cygming.h (TARGET_ASM_LTO_STAR
The anchors have been disabled as they use symbol + offset, which is
not applicable for COFF AArch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (TARGET_MIN_ANCHOR_OFFSET):
Keep default TARGET_MAX_ANCHOR_OFFSET for PECOFF target.
(TARGET_MAX_ANCHOR_OFFSET): Likewise.
---
aarch64.cc has been updated to prevent emitting "symbol + offset"
for SYMBOL_SMALL_ABSOLUTE for the PECOFF target. "symbol + offset"
cannot be used in relocations for aarch64-w64-mingw32 due to
relocation requirements.
Instead, it will adjust the address by an offset with the
"add" instruction.
gc
LOCAL_LABEL_PREFIX has been changed to help the assembly
compiler recognize local labels. Emitting locals has been
replaced with the .lcomm directive to declare uninitialized
data without defining an exact section. Functions and objects
were missing declarations. Binutils was not able to distinguis
Symbols using GOT are not supported by the aarch64-w64-mingw32
target and should be excluded from the code models.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_symbol_binds_local_p):
Disable GOT for PECOFF target.
---
gcc/config/aarch64/aarch64.cc | 3 +++
1 file changed,
The patch resolves compilation issues for the C++ language. Previous
patch series contributed to C++ as well, however, C++ could not be
tested until we got a C++ compiler and could build at least a "Hello
World" C++ program, and in reality, more than that.
gcc/ChangeLog:
* config.gcc: Add
This patch enables DWARF and allows compilation with debugging
information by using "gcc -g". The unwind info is disabled for
the moment and will be revisited after SEH implementation for
the target.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (TARGET_ASM_UNALIGNED_HI_OP):
Enable D
The patch adds support for weak references. The original MinGW
implementation targets ix86, which handles weak symbols differently
compared to AArch64. In AArch64, the weak symbols are replaced by
other symbols which reference the original weak symbols, and the
compiler does not track the original
ctored and validated by
Radek Barton and
Evgeny Karpov
Contributor: Zac Walker
Special thanks to Linaro, especially Christophe Lyon,
for the internal review!
Regards,
Evgeny
Thursday, June 27, 2024 8:13 PM
Uros Bizjak wrote:
>
> So, there is no problem having #endif just after else.
>
> Anyway, it's your call, this is not a hill I'm willing to die on. ;)
>
> Thanks,
> Uros.
It looks like the patch resolves 3 reported issues.
Uros, I suggest merging the patch as i
Thursday, June 27, 2024 11:31 AM
Christophe Lyon wrote:
>
> Hi Evgeny,
>
> Minor comments:
> - the patch title should end with [PRn, ...] (choose the most
> relevant bug number)
> - ChangeLog should mention every bug with PR component/n
> so that the bugzilla hooks will notice the commit.
Thursday, June 27, 2024 10:39 AM
Uros Bizjak wrote:
> > diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
> > index 5dfa7d49f58..20adb42e17b 100644
> > --- a/gcc/config/i386/i386-expand.cc
> > +++ b/gcc/config/i386/i386-expand.cc
> > @@ -414,6 +414,10 @@ ix86_expand_mov
removed by the mail client.
Regards,
Evgeny
From 6b1448e9ba651657dccdb41590a51a7c3c371e50 Mon Sep 17 00:00:00 2001
From: Evgeny Karpov
Date: Wed, 26 Jun 2024 22:10:55 +0200
Subject: [PATCH] i386: Fix regression after refactoring
legitimize_pe_coff_symbol, ix86_GOT_ali
Wednesday, June 26, 2024 5:56 PM
Andrew Pinski wrote:
>
> I think this caused profilebootstrap failure on x86_64-linux-gnu.
> I notice the definition of GOT_ALIAS_SET for all non mingw targets is
> now just -1. That seems very wrong to me.
> It was originally:
> ```
> alias_set_type
> x86_GOT_ali
The patch fixes the issue introduced in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=63512c72df09b43d56ac7680cdfd57a66d40c636
and reported at
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655599.html .
Regards,
Evgeny
The patch fixes the issue with compilation on x86_64-gnu-linux
when war
Tuesday, June 25, 2024 12:03 PM
Tobias Burnus wrote:
>
> Hi Evgeny,
>
> I am not sure whether I have chosen the right email in the thread but:
> a x86-64 GNU Linux build currently fails as follows.
>
> At a glance, it seems to be sufficient to remove the prototype
> declaration in i386.cc.
>
>
Monday, June 10, 2024 7:03 PM
Richard Sandiford wrote:
> Thanks for the update. Parts 1-5 look good to me. Some minor comments
> below about part 6:
>
> If the TARGET_DLLIMPORT_DECL_ATTRIBUTES condition can be dropped, the
> series is OK from my POV with that change and with the changes above.
The patch series has been successfully verified by patchwork,
after resolving the issue with the mailing client.
https://patchwork.sourceware.org/project/gcc/list/?series=34865
The x86_64-w64-mingw32 build has been tested, and no regressions
have been detected after applying the patch series.
htt
This patch reuses the MinGW implementation to enable DLL import/export
functionality for the aarch64-w64-mingw32 target. It also modifies
environment configurations for MinGW.
gcc/ChangeLog:
* config.gcc: Add winnt-dll.o, which contains the DLL
import/export implementation.
The DLL import/export mingw implementation, originally from ix86, requires
minor adjustments to be compatible with AArch64.
gcc/ChangeLog:
* config/i386/cygming.h (PE_COFF_EXTERN_DECL_SHOULD_BE_LEGITIMIZED):
Declare whether an external declaration should be legitimized.
(H
This patch extends the aarch64 attributes list with the selectany
attribute for the aarch64-w64-mingw32 target and reuses the mingw
implementation to handle it.
* config/aarch64/aarch64.cc:
Extend the aarch64 attributes list.
* config/aarch64/cygming.h (SUBTARGET_ATTRIBUTE_
This patch renames functions related to dllimport/dllexport
and selectany functionality. These functions will be reused
in the aarch64-w64-mingw32 target.
gcc/ChangeLog:
* config/i386/cygming.h (mingw_pe_record_stub):
Rename functions in mingw folder which will be reused for
From 8f6fd4775792b443a72dfbc8d95bf3ff5b516d18 Mon Sep 17 00:00:00 2001
From: Evgeny Karpov
Date: Thu, 6 Jun 2024 22:38:35 +0200
Subject: [PATCH v3 2/6] Extract ix86 dllimport implementation to mingw
This patch extracts the ix86 implementation for expanding a SYMBOL
into its corresponding
v3-0002-Extract-ix86-dllimport-implementation-to-mingw.patch
Description: v3-0002-Extract-ix86-dllimport-implementation-to-mingw.patch
Harmstone and
Ron Riddle
Refactored, prepared, and validated by
Radek Barton and
Evgeny Karpov
gcc/ChangeLog:
* config.gcc: Move mingw_* declations to mingw.
* config/aarch64/aarch64-protos.h
(mingw_pe_maybe_record_exported_symbol): Likewise
I am resubmitting the patch series without changes to the patchwork due to an
issue with the mail client in the previous submission.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653894.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653952.html
Regards,
Evgeny
Evgeny Karpov (6
I am resubmitting the patch series without changes to the patchwork due to an
issue with the mail client in the previous submission.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653894.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653952.html
Regards,
Evgeny
Evgeny Karpov (6
I am resubmitting the patch series without changes to the patchwork due to an
issue with the mail client in the previous submission.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653894.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653952.html
Regards,
Evgeny
Evgeny Karpov (6
This patch makes changes to the i386.cc file, which contains the ASCII 0x0C
character. However, this character was replaced by the mail client, and the
patchwork could not validate the series. I am resubmitting the patch as an
attachment.
v2-0002-Extract-ix86-dllimport-implementation-to-mingw
This patch reuses the MinGW implementation to enable DLL import/export
functionality for the aarch64-w64-mingw32 target. It also modifies
environment configurations for MinGW.
gcc/ChangeLog:
* config.gcc: Add winnt-dll.o, which contains the DLL
import/export implementation.
The DLL import/export mingw implementation, originally from ix86, requires
minor adjustments to be compatible with AArch64.
gcc/ChangeLog:
* config/i386/cygming.h (PE_COFF_EXTERN_DECL_SHOULD_BE_LEGITIMIZED):
Declare whether an external declaration should be legitimized.
(H
This patch extends the aarch64 attributes list with the selectany
attribute for the aarch64-w64-mingw32 target and reuses the mingw
implementation to handle it.
* config/aarch64/aarch64.cc:
Extend the aarch64 attributes list.
* config/aarch64/cygming.h (SUBTARGET_ATTRIBUTE_
This patch renames functions related to dllimport/dllexport
and selectany functionality. These functions will be reused
in the aarch64-w64-mingw32 target.
gcc/ChangeLog:
* config/i386/cygming.h (mingw_pe_record_stub):
Rename functions in mingw folder which will be reused for
This patch extracts the ix86 implementation for expanding a SYMBOL
into its corresponding dllimport, far-address, or refptr symbol.
It will be reused in the aarch64-w64-mingw32 target.
The implementation is copied as is from i386/i386.cc with
minor changes to follow to the code style.
Also this pa
Harmstone and
Ron Riddle
Refactored, prepared, and validated by
Radek Barton and
Evgeny Karpov
gcc/ChangeLog:
* config.gcc: Move mingw_* declations to mingw.
* config/aarch64/aarch64-protos.h
(mingw_pe_maybe_record_exported_symbol): Likewise
.
- Replace intermediate functions for PECOFF with ifdef checks in ix86.
- Update the copyright date in winnt-dll.cc.
- Correct the style.
- Rebase from 7th June 2024
Regards,
Evgeny
Evgeny Karpov (6):
Move mingw_* declarations to the mingw folder
Extract ix86 dllimport implementation to mingw
Thursday, June 6, 2024 1:42 AM
Jonathan Yong <10wa...@gmail.com> wrote:
>
> Where is HAVE_64BIT_POINTERS used?
>
Sorry, it was missed in the posted changes for review.
Regards,
Evgeny
diff --git a/gcc/config/mingw/mingw32.h b/gcc/config/mingw/mingw32.h
index 8a6f0e8e8a5..0c9d5424942 100644
---
Richard and Uros, could you please review the changes for v2?
Additionally, we have detected an issue with GCC GC in winnt-dll.cc. The fix
will be included in v2.
>> -ix86_handle_selectany_attribute (tree *node, tree name, tree, int,
>> +mingw_handle_selectany_attribute (tree *node, tree name, tr
Thursday, May 23, 2024 10:35 AM
Uros Bizjak wrote:
> Richard Sandiford wrote:
> >
> > > This looks good to me apart from a couple of very minor comments
> > > below, but please get approval from the x86 maintainers as well. In
> > > particular, they might prefer to handle ix86_legitimize_pe_co
Wednesday, May 22, 2024 1:06 PM
Richard Sandiford wrote:
> This looks good to me apart from a couple of very minor comments below, but
> please get approval from the x86 maintainers as well. In particular, they
> might
> prefer to handle ix86_legitimize_pe_coff_symbol in some other way.
Thanks
Monday, May 13, 2024 3:49 PM wrote:
David Malcolm wrote:
> >
> > It might be a "make" dependencies issue:
> > "make regenerate-opt-urls" has dependencies on OPT_URLS_HTML_DEPS
> > which is currently defined as:
> > OPT_URLS_HTML_DEPS = $(build_htmldir)/gcc/Option-Index.html \
> > $(build_
Sunday, May 12, 2024
Mark Wielaard wrote:
> The new cygming.opt.urls and mingw.opt.urls in the
> gcc/config/mingw/cygming.opt.urls directory need to generated by make
> regenerate-opt-urls in the gcc subdirectory. They still contained references
> to
> the gcc/config/i386 directory from which th
This patch reuses the MinGW implementation to enable DLL import/export
functionality for the aarch64-w64-mingw32 target. It also modifies
environment configurations for MinGW.
gcc/ChangeLog:
* config.gcc: Add winnt-dll.o, which contains the DLL
import/export implementation.
1 - 100 of 179 matches
Mail list logo
