On 3/19/24 2:05 PM, Vineet Gupta wrote:
On 3/19/24 06:10, Jeff Law wrote:
On 3/19/24 12:48 AM, Andrew Waterman wrote:
On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
On 3/16/24 13:21, Jeff Law wrote:
| 59944:add s0,sp,2047 <
| 59948:mv a2,a0
| 5994c:
Hi!
The task of the build_bitint_stmt_ssa_conflicts hook for
tree-ssa-coalesce.cc next to special casing the
multiplication/division/modulo is to ignore statements with
large/huge _BitInt lhs which isn't in names bitmap and on the
other side pretend all uses of the stmt are used in a later stmt
Hi!
We ICE on the following testcase, because handle_cast was incorrectly
testing !m_first to see whether it should use m_data[m_bitfld_load + 1]
or fresh SSA_NAME for a PHI result.
Now, m_first is in the routine sometimes temporarily cleared in between
doing prepare_data_in_out and the !m_first
On 3/18/24 6:07 PM, Vineet Gupta wrote:
Naive question: why is define_split more natural vs. define_insn_and_split.
Is it because of the syntax/implementation or that one is more Combine
"centric" and other is more of a Split* Pass thing (roughly speaking of
course) or something else
Hi!
On the following testcases, there is no overlap between data references
within a single iteration, but the data references have size which is twice
as large as the step, which means the data references overlap with the next
iteration which predcom doesn't take into account.
As discussed in
On Wed, Mar 20, 2024 at 10:20 PM Thomas Schwinge wrote:
> Hi!
Hi Thomas,
> Sergey, great work on aarch64 GNU/Hurd! (... where these GCC bits
> clearly were the less complicated part...) ;-)
thanks! (and indeed they were :)
> Please re-submit with ChangeLog updates added to the Git commit
Per the standard, the return type of a generators ranges iterator op*
should be the reference type rather than the yielded type.
The yielded type was used here by mistake.
libstdc++-v3/ChangeLog:
* include/std/generator (generator::_Iterator::operator*): Fix
return type.
From: Arsen Arsenović
Afternoon!
These couple of patches fix two minor issues in the generator
implementation that were informally reported a while ago.
Tested on x86_64-pc-linux-gnu.
OK for trunk?
TIA, have a lovely day!
Arsen Arsenović (2):
libstdc++: fix _V badname in
libstdc++: fix
libstdc++-v3/ChangeLog:
* include/std/generator: Fix _V badname.
---
libstdc++-v3/include/std/generator | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/libstdc++-v3/include/std/generator
b/libstdc++-v3/include/std/generator
index
Tested aarch64-linux. Pushed to trunk.
-- >8 --
We already have __is_in_place_type_v for in_place_type_t so adding an
equivalent for in_place_index_t allows us avoid a class template
instantiation for the __not_in_place_tag constraint on the most
commonly-used std::variant::variant(T&&)
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This was just approved in Tokyo as a DR for C++23. It doesn't affect us
yet, because we don't implement the __cpp_lib_format_ranges features. We
can add the disabled specializations and add a testcase now though.
libstdc++-v3/ChangeLog:
*
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The difference between __type_identity_t and std::type_identity_t is
observable, as demonstrated in the PR. Nobody in LWG seems to think this
an example we should really care about, but it seems easy and harmless
to change this.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9646-g80a0cb37456c49.
gcc/analyzer/ChangeLog:
PR analyzer/114408
* engine.cc (impl_run_checkers): Free up any dominance info
Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. Committed
to trunk.
Dave
---
hppa: Fix LO_SUM DLTIND14R address support in PRINT_OPERAND_ADDRESS
This bug was hidden since LO_SUM DLTIND14R addresses are normally
handled by the A constraint in the move patterns.
2024-03-23 John
Since it's not i386-specific; this makes it possible to reuse it for other
architectures.
Also, add a warning for the case gnu.h is specified before gnu-user.h, which
would cause gnu-user's version of the spec to override gnu's, and not the other
way around as it's intended. The i?86-gnu target
There is currently no unwinding implementation.
libgcc/ChangeLog:
* config.host: Recognize aarch64*-*-gnu* hosts.
* config/aarch64/gnu-unwind.h: New file.
* config/aarch64/heap-trampoline.c
(allocate_trampoline_page): Support GNU/Hurd.
Signed-off-by: Sergey
Coupled with a corresponding binutils patch, this produces a toolchain that can
sucessfully build working binaries targeting aarch64-gnu.
gcc/Changelog:
* config.gcc: Recognize aarch64*-*-gnu* targets.
* config/aarch64/aarch64-gnu.h: New file.
Signed-off-by: Sergey Bugaev
---
Hello,
Can the build experts say what needs to be changed? The dependencies I added
are missing in the build configuration (@if gcc-bootstrap).
I cannot say if libbacktrace should or should not be a bootstrap=true module.
If there are no better patches, I kindly ask to integrate this patch
Hello Peter:
Sent version-3 of the patch addressing below review comments.
Thanks & Regards
Ajit
On 23/03/24 3:03 pm, Ajit Agarwal wrote:
> Hello Peter:
>
> On 23/03/24 10:07 am, Peter Bergner wrote:
>> On 3/22/24 5:15 AM, Ajit Agarwal wrote:
>>> When using FlexiBLAS with OpenBLAS we noticed
Hello All:
When using FlexiBLAS with OpenBLAS, we noticed corruption of the caller
stack frame when calling OpenBLAS functions. This was caused by the
FlexiBLAS C/C++ caller and OpenBLAS Fortran callee disagreeing on the
number of function parameters in the callee due to hidden Fortran
Hello Peter:
On 23/03/24 10:07 am, Peter Bergner wrote:
> On 3/22/24 5:15 AM, Ajit Agarwal wrote:
>> When using FlexiBLAS with OpenBLAS we noticed corruption of
>> the parameters passed to OpenBLAS functions. FlexiBLAS
>> basically provides a BLAS interface where each function
>> is a stub that
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436
This is a small fix for the issue mentioned in the PR that _Pragma("GCC
system_header") does not work completely. I believe it was always the case
since _Pragma() support was first added. bootstrap + regtested all languages
on x86-64
Pushed.
Gerald
---
htdocs/index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/index.html b/htdocs/index.html
index 90f2a838..909cae75 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -55,7 +55,7 @@ mission statement.
News
On 23/03/24 9:33 pm, Peter Bergner wrote:
> On 3/23/24 4:33 AM, Ajit Agarwal wrote:
- else if (align_words < GP_ARG_NUM_REG)
+ else if (align_words < GP_ARG_NUM_REG
+ || (cum->hidden_string_length
+ && cum->actual_parm_length <= GP_ARG_NUM_REG))
>>>
Pushed.
Gerald
---
htdocs/readings.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index e4e68909..ee77d969 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -283,7 +283,7 @@ names.
Manufacturer: Renesas,
> Am 23.03.2024 um 08:49 schrieb Jakub Jelinek :
>
> Hi!
>
> On the following testcases, there is no overlap between data references
> within a single iteration, but the data references have size which is twice
> as large as the step, which means the data references overlap with the next
>
> Am 23.03.2024 um 08:56 schrieb Jakub Jelinek :
>
> Hi!
>
> The task of the build_bitint_stmt_ssa_conflicts hook for
> tree-ssa-coalesce.cc next to special casing the
> multiplication/division/modulo is to ignore statements with
> large/huge _BitInt lhs which isn't in names bitmap and on
> Am 23.03.2024 um 08:59 schrieb Jakub Jelinek :
>
> Hi!
>
> We ICE on the following testcase, because handle_cast was incorrectly
> testing !m_first to see whether it should use m_data[m_bitfld_load + 1]
> or fresh SSA_NAME for a PHI result.
> Now, m_first is in the routine sometimes
On 3/23/24 4:33 AM, Ajit Agarwal wrote:
>>> - else if (align_words < GP_ARG_NUM_REG)
>>> + else if (align_words < GP_ARG_NUM_REG
>>> + || (cum->hidden_string_length
>>> + && cum->actual_parm_length <= GP_ARG_NUM_REG))
>> {
>> if (TARGET_32BIT &&
29 matches
Mail list logo
