Hi!
As mentioned in the PR, my estimations on needed buffer size for wide_int
and especially widest_int printing were incorrect, I've used get_len ()
in the estimations, but that is true only for !wi::neg_p (x) values.
Under the hood, we have 3 ways to print numbers.
print_decs which if
if ((wi.
On Sat, 14 Oct 2023, 00:33 Benjamin Brock, wrote:
> This is my first time submitting a patch, so my apologies if I'm
> submitting incorrectly or missing something.
>
Thanks for contributing!
I don't think this patch counts as legally significant, but if you
contribute again in future you should
> Am 14.10.2023 um 10:21 schrieb Jakub Jelinek :
>
> Hi!
>
> As mentioned in the PR, my estimations on needed buffer size for wide_int
> and especially widest_int printing were incorrect, I've used get_len ()
> in the estimations, but that is true only for !wi::neg_p (x) values.
> Under the h
Hi!
On Sat, Oct 14, 2023 at 10:41:28AM +0200, Richard Biener wrote:
> Can we somehow abstract this common pattern?
So like this? With room for the future tweaks like printing decimal
instead of hex numbers by print_dec*, where we'd only need to adjust
the inlines. The XALLOCAVEC call is left fo
> Am 14.10.2023 um 11:50 schrieb Jakub Jelinek :
>
> Hi!
>
>> On Sat, Oct 14, 2023 at 10:41:28AM +0200, Richard Biener wrote:
>> Can we somehow abstract this common pattern?
>
> So like this? With room for the future tweaks like printing decimal
> instead of hex numbers by print_dec*, where
Hi,
This is a small refactoring ahead of the next merge from upstream, where
a few more front-end routines will stop doing the file handling
themselves.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* d-lang.cc (
Hi,
The internal error in analyzer turned out to be caused by a subtly
invalid tree representation of STRING_CSTs in the D front-end, fixed by
including the terminating NULL as part of the TREE_STRING_POINTER.
When adding a first analyzer test for D, it flagged up another subtle
mismatch in one a
Bootstrapped and regression tested on x86_64.
c: error for function with external and internal linkage [PR111708]
Declaring a function with both external and internal linkage
in the same TU is translation-time UB. Add an error for this
case as already done for objects.
On 10/13/23 18:15, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In C++23, since P2448, a constexpr function F that calls a non-constexpr
function N is OK as long as we don't actually call F in a constexpr
context. So instead of giving an erro
On 10/12/23 04:53, Tobias Burnus wrote:
libgomp.texi: Note to 'Memory allocation' sect and missing mem-memory routines
This commit completes the documentation of the OpenMP memory-management
routines, except for the unimplemented TR11 additions. It also makes clear
in the 'Memory allocation' s
I wonder why I missed the following – but it now works :-/
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Regis
When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html
First, I found especially the Fortran part difficult to read. Secondly,
it missed the C++ attribute syntax. And I also missed a reference to
-fopenmp-simd.
The attached patch tries to improve thi
I was recently suggesting someone to use ACC_DEVICE_TYPE; I did not point to the
documentation it only contains the title:
https://gcc.gnu.org/onlinedocs/libgomp/ACC_005fDEVICE_005fTYPE.html
Admittedly, there is also "Reference:" pointing to the OpenACC specification,
but the latter just states
On 10/12/23 10:37, Tobias Burnus wrote:
@@ -3133,15 +3134,25 @@ variable can be set to one of three values -
@code{MANDATORY}, @code{DISABLED}
or @code{DEFAULT}.
If set to @code{MANDATORY}, the program will terminate with an error if
-the offload device is not present or is not supported.
On 10/14/23 13:43, Tobias Burnus wrote:
When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>>
First, I found especially the Fortran part difficult to read. Secondly,
it missed the C++ attribute syntax. And I also missed a reference to
-fopenmp-si
On Sat, Oct 14, 2023 at 03:46:52PM -0600, Sandra Loosemore wrote:
> On 10/14/23 13:43, Tobias Burnus wrote:
> > When browsing libgomp doc, I came across
> > https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>> First, I
> > found especially the Fortran part difficult to read. Secondly,
> >
This patch is my proposed solution to PR rtl-optimization/91865.
Normally RTX simplification canonicalizes a ZERO_EXTEND of a ZERO_EXTEND
to a single ZERO_EXTEND, but as shown in this PR it is possible for
combine's make_compound_operation to unintentionally generate a
non-canonical ZERO_EXTEND of
On 10/14/23 13:51, Tobias Burnus wrote:
@@ -5003,6 +5001,17 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic
purposes.
@node ACC_DEVICE_TYPE
@section @code{ACC_DEVICE_TYPE}
@table @asis
+@item @emph{Description}:
+Control the default device type to use when executing compute regio
On 10/14/23 16:14, Roger Sayle wrote:
This patch is my proposed solution to PR rtl-optimization/91865.
Normally RTX simplification canonicalizes a ZERO_EXTEND of a ZERO_EXTEND
to a single ZERO_EXTEND, but as shown in this PR it is possible for
combine's make_compound_operation to unintentiona
This patch improves the initial RTL expanded for double word shifts
on architectures with conditional moves, so that later passes don't
need to clean-up unnecessary and/or unused instructions.
Consider the general case, x << y, which is expanded well as:
t1 = y & 32;
t2 = 0;
When checking to see if we have a function declaration has a conflict due to
promotations, there is no test to see if the type was an error mark and then
calls
c_type_promotes_to. c_type_promotes_to is not ready for error_mark and causes an
ICE.
This adds a check for error before the call of c_ty
This is a simple error recovery issue when c_safe_arg_type_equiv_p
was added in r8-5312-gc65e18d3331aa999. The issue is that after
an error, an argument type (of a function type) might turn
into an error mark node and c_safe_arg_type_equiv_p was not ready
for that. So this just adds a check for err
RVVM2x2QI should be rvvm2qi instead of rvvmq1i.
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Fix vsingle incorrect attribute for
RVVM2x2QI.
---
gcc/config/riscv/vector-iterators.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/vector-iterato
On 10/14/23 17:32, Roger Sayle wrote:
This patch improves the initial RTL expanded for double word shifts
on architectures with conditional moves, so that later passes don't
need to clean-up unnecessary and/or unused instructions.
Consider the general case, x << y, which is expanded well as:
24 matches
Mail list logo
