On 2024-09-20 21:42, Siddhesh Poyarekar wrote:
On 2024-09-20 20:20, Sam James wrote:
Siddhesh Poyarekar writes:
This series makes a few improvements to get static object size
estimates in
more cases, thus improving the success rate of the static
__builtin_object_size. This should fully fix
On 2024-09-20 20:20, Sam James wrote:
Siddhesh Poyarekar writes:
This series makes a few improvements to get static object size estimates in
more cases, thus improving the success rate of the static
__builtin_object_size. This should fully fix PR116556 and also covers a bulk
of use cases for
Tested x86_64-pc-linux-gnu. OK for trunk?
-- 8< --
We've been using -Wno-narrowing since gcc 4.7, but at this point narrowing
diagnostics seem like a stable part of C++ and we should adjust.
This patch changes -Wno-narrowing to -Wno-error=narrowing so that narrowing
issues will still not break
Siddhesh Poyarekar writes:
> This series makes a few improvements to get static object size estimates in
> more cases, thus improving the success rate of the static
> __builtin_object_size. This should fully fix PR116556 and also covers a bulk
> of use cases for PR77608. I started to try and fi
Hi Thomas, hello all,
the attached follow-up patch does:
* It fixes an issue (thinko) related to Fortran and \0 terminated,
which fails for at least substring strings.
* Includes some minor fixes, e.g. ensuring the device is initialized
in omp_get_uid_from_device, the superfluous 'omp_', or
There are numerous "dump" member functions in the analyzer with
copied-and-pasted logic. Simplify them by moving the shared code
to a new class tree_dump_pretty_printer.
As well as reducing code duplication, this eliminates numerous
uses of pp_show_color (global_dc->m_printer), which should
ultim
Add an m_printer to sarif_builder and use throughout, rather than
using the context's printer. For now this is the same printer, but
eventually this should help with transitioning to multiple output sinks.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-g
The diagnostic_starter and diagnostic_finalizer callbacks and most of
their support subroutines are only used by the "text" output format.
Emphasize this and reduce the binding with diagnostic_context
by renaming the callbacks to add "_text" in their names, and converting
the first param from diag
This patch adds an experimental diagnostics output format that
writes HTML. It isn't ready yet for end-users, but seems worth
keeping in the tree as I refactor the diagnostics subsystem, to
ensure that this code still builds, and to verify that it's possible to
implement new diagnostic output form
diagnostic_manager::emit_saved_diagnostic makes a useless clone
of global_dc->m_printer; remove it.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-3748-g37604edf37b379.
gcc/analyzer/ChangeLog:
PR other/116613
*
On 9/20/24 12:40 AM, Jakub Jelinek wrote:
On Fri, Sep 20, 2024 at 06:18:15PM -0400, Marek Polacek wrote:
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1473,6 +1473,20 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
that case, strip it in favor of this one. */
On Sun, 15 Sept 2024 at 16:24, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> PR 116529 shows that std::unique_ptr is currently unusable
> because the constructor taking std::auto_ptr (which is a non-standard
> extension since C++17) tries to form the invalid type X&* during
> ove
Hi Thomas,
See attached patch for adding the include lines:
+ if (gcn_stack_size)
+{
+ fprintf (cfile, "#include \n");
+ fprintf (cfile, "#include \n\n");
but contrary to previously there is no 'stdint.h'
and they are also not unconditionally included.
(The 'stdbool.h' is only u
Pushed to trunk.
-- >8 --
There are several features that are not supported when using the old
std::string ABI. It's possible that PR 81967 will get fixed, but the
missing C++20 features almost certainly won't be. Document this in the
manual.
libstdc++-v3/ChangeLog:
PR libstdc++/116777
On Fri, Sep 20, 2024 at 06:18:15PM -0400, Marek Polacek wrote:
> --- a/gcc/cp/cp-gimplify.cc
> +++ b/gcc/cp/cp-gimplify.cc
> @@ -1473,6 +1473,20 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void
> *data_)
>that case, strip it in favor of this one. */
>if (tree &init = TARGET_EX
On 9/20/24 12:18 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR reports a missed optimization. When we have:
Str str{"Test"};
callback(str);
as in the test, we're able to evaluate the Str::Str() call at compile
time. But when we h
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR reports a missed optimization. When we have:
Str str{"Test"};
callback(str);
as in the test, we're able to evaluate the Str::Str() call at compile
time. But when we have:
callback(Str{"Test"});
we are not. W
From: Pietro Monteiro
SH: Document extended asm operand modifers
gcc/ChangeLog:
* doc/extend.texi (SH Operand Modifiers): New.
Signed-off-by: Pietro Monteiro
---
Tested by running "make info pdf html" and looking at the pdf and html output.
I used the comment on "gcc/config/sh.cc:sh_p
On Fri, Sep 20, 2024 at 1:53 AM Thomas Schwinge wrote:
>
> Hi Sam!
>
> On 2024-09-20T05:12:19+0100, Sam James wrote:
> > In this case, they were all harmless in reality (no diff in test logs).
>
> > -/* { dg-do compile ) */
> > +/* { dg-do compile } */
>
> DejaGnu directives are matched by '{ dg
On 9/20/24 7:34 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/20/24 6:51 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'
On 9/20/24 8:48 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
As a follow-up to r15-3741-gee3efe06c9c49c, which was only concerned
with usings, it seems we should also compare contexts of a reversed
vs non-reversed (memb
Hello,
Hope this email finds you well.
A ticket has been opened about gcc14 not building on MacOS x64 (Macports).
Please see here https://trac.macports.org/ticket/70641
This is the error it returns
Undefined symbols for architecture x86_64:
"___deregister_frame_info", referenced from:
-r
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
As a follow-up to r15-3741-gee3efe06c9c49c, which was only concerned
with usings, it seems we should also compare contexts of a reversed
vs non-reversed (member) candidate during operator overload
resolution.
On Fri, 20 Sep 2024, Jason Merrill wrote:
> On 9/20/24 6:51 PM, Patrick Palka wrote:
> > On Fri, 20 Sep 2024, Jason Merrill wrote:
> >
> > > On 9/18/24 10:59 PM, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > > > look OK for trunk? I'm not sure this
On 9/20/24 6:51 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since it'll m
On Fri, 20 Sep 2024, Jason Merrill wrote:
> On 9/18/24 10:59 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk? I'm not sure this is worth backporting
> > without the previous CWG 2273 tweak since it'll mean inconsistent
> > behavior b
Propogate constant additions and subtractions to an offset when
computing an estimate for a PHI of constants.
gcc/ChangeLog:
PR tree-optimization/PR116556
* tree-object-size.cc (try_collapsing_offset): New parameters
CST and CODE. Use them to propagate PLUS_EXPR and MINUS
Don't bail out early if the offset to a pointer in __builtin_object_size
is a variable, return the wholesize instead since that is a better
fallback for maximum estimate. This should keep checks in place for
fortified functions to constrain overflows to at lesat some extent.
gcc/ChangeLog:
When wholesize != size, there is a reasonable opportunity for static
object sizes also to be computed using size_for_offset, so use that.
gcc/ChangeLog:
* tree-object-size.cc (plus_stmt_object_size): Call
SIZE_FOR_OFFSET for some negative offset cases.
* testsuite/gcc.dg/b
This series makes a few improvements to get static object size estimates in
more cases, thus improving the success rate of the static
__builtin_object_size. This should fully fix PR116556 and also covers a bulk
of use cases for PR77608. I started to try and fix PR77608 fully, but in the
end it lo
In PTR + OFFSET cases, try harder to see if the target offset could
result in a constant. Specifically, if the offset is a PHI node with
all constant branches, return the minimum (or maximum for OST_MINIMUM)
of the possible values.
gcc/ChangeLog:
PR tree-optimization/116556
* tre
Tamar Christina writes:
> Hi All,
>
> Consider low overhead loops like:
>
> void
> foo (char *restrict a, int *restrict b, int *restrict c, int n)
> {
> for (int i = 0; i < 9; i++)
> {
> int res = c[i];
> int t = b[i];
> if (a[i] != 0)
> res = t;
> c[i] = res;
On 9/16/24 4:07 PM, Simon Martin wrote:
Hi Jason,
On 14 Sep 2024, at 18:44, Simon Martin wrote:
Hi Jason,
On 14 Sep 2024, at 18:11, Jason Merrill wrote:
On 9/13/24 11:06 AM, Simon Martin wrote:
Hi Jason,
On 12 Sep 2024, at 16:48, Jason Merrill wrote:
On 9/12/24 7:23 AM, Simon Martin wro
On 9/20/24 5:21 PM, Simon Martin wrote:
The following code triggers an ICE
=== cut here ===
class base {};
class derived : virtual public base {
public:
template constexpr derived(Arg) {}
};
int main() {
derived obj(1.);
}
=== cut here ===
The problem is that cxx_bind_parameters_in_call e
On 9/19/24 4:37 PM, Jakub Jelinek wrote:
On Thu, Sep 19, 2024 at 10:21:15AM -0400, Jason Merrill wrote:
On 9/19/24 7:57 AM, Richard Biener wrote:
On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
I'm fine with this in
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, September 20, 2024 3:48 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; ktkac...@gcc.gnu.org
>> Subject: Re: [PATCH]AArch64: Take into acco
Claudio Bantaloukas writes:
> The ACLE defines a new scalar type, __mfp8. This is an opaque 8bit types that
> can only be used by fp8 intrinsics. Additionally, the mfloat8_t type is made
> available in arm_neon.h and arm_sve.h as an alias of the same.
>
> This implementation uses an unsigned INTEG
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 20, 2024 3:48 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: Take into account when VF is higher than known
> On 17 Sep 2024, at 22:05, Jason Merrill wrote:
>
> On 8/29/24 9:10 PM, Iain Sandoe wrote:
>> + /* deref the frame pointer, to use in member access code. */
>> + tree deref_fp
>> += cp_build_indirect_ref (loc, coro_fp, RO_UNARY_STAR,
>> + tf_warning_or_error);
Tested on i686-darwin9, 17; x86_64-darwin17,19,21,23, pushed to trunk
thanks
Iain
--- 8< ---
Recent versions of Xcode as require a dash to read from standard
input. We can use this on all supported OS versions so make it
unconditional. Patch from Mark Mentovai.
gcc/ChangeLog:
* config
The following code triggers an ICE
=== cut here ===
class base {};
class derived : virtual public base {
public:
template constexpr derived(Arg) {}
};
int main() {
derived obj(1.);
}
=== cut here ===
The problem is that cxx_bind_parameters_in_call ends up attempting to
convert a REAL_CST (the
Tamar Christina writes:
>>
>> So my gut instinct is that we should instead tweak the condition for
>> using latency costs, but I'll need to think about it more when I get
>> back from holiday.
>>
>
> I think that's a separate problem.. From first principals it should already
> be very wrong to c
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since it'll mean inconsistent
behavior between implict vs explicit object members in GCC 14: the ca
On 9/20/24 4:02 PM, Patrick Palka wrote:
On Wed, 18 Sep 2024, Patrick Palka wrote:
Our implementation of the CWG 2273 inheritedness tiebreaker seems to be
incorrectly considering all inherited members, not just inherited
constructors. This patch restricts the tiebreaker accordingly.
D
Ping.
The patch still applies cleanly and fixes the following fails:
FAIL: 26_numerics/headers/cmath/equivalent_functions.cc -std=gnu++17 (test for
excess errors)
UNRESOLVED: 26_numerics/headers/cmath/equivalent_functions.cc -std=gnu++17
compilation failed to produce executable
FAIL: 26_numer
Hi!
I'd like to ping 16 C++ patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660046.html
c++: Implement C++23 P2718R0 - Wording for P2644R1 Fix for Range-based for
Loop [PR107637]
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662507.html
https://gcc.gnu.org/pipermail/
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 20, 2024 3:02 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: Take into account when VF is higher than known
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, September 20, 2024 2:10 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd
>> Subject: Re: [PATCH 3/4][rtl]: simplify boolean vector EQ and NE comparisons
>>
>> Tamar Christina writes:
The ACLE defines a new scalar type, __mfp8. This is an opaque 8bit types that
can only be used by fp8 intrinsics. Additionally, the mfloat8_t type is made
available in arm_neon.h and arm_sve.h as an alias of the same.
This implementation uses an unsigned INTEGER_TYPE, with precision 8 to
represen
On Wed, 18 Sep 2024, Patrick Palka wrote:
> Our implementation of the CWG 2273 inheritedness tiebreaker seems to be
> incorrectly considering all inherited members, not just inherited
> constructors. This patch restricts the tiebreaker accordingly.
>
> DR 2273
>
> gcc/cp/ChangeLog:
>
>
Tamar Christina writes:
> Hi All,
>
> Consider low overhead loops like:
>
> void
> foo (char *restrict a, int *restrict b, int *restrict c, int n)
> {
> for (int i = 0; i < 9; i++)
> {
> int res = c[i];
> int t = b[i];
> if (a[i] != 0)
> res = t;
> c[i] = res;
On Fri, 20 Sep 2024, Tobias Burnus wrote:
> A minor update for a bug fix / impl.-quality feature and a proper new
> feature.
Looks fine to me.
Gerald
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 20, 2024 2:10 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 3/4][rtl]: simplify boolean vector EQ and NE comparisons
>
> Tamar Christina writes:
> >> For variable-sized vectors,
The gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c testcase shows
that we sometimes fail to use store-lanes even though it should be
profitable. We're currently relying on vect_slp_prefer_store_lanes_p
at the point we run into the first SLP discovery mismatch with obviously
limited informatio
Tamar Christina writes:
>> For variable-sized vectors, I suppose the question is whether the
>> first unequal element is found in the minimum vector length, or whether
>> it only occurs for larger lengths. In the former case we can fold at
>> compile time, but in the latter case we can't.
>>
>>
Hi Tobias!
I've not verified, but I very much suspect that this change:
On 2024-09-13T16:24:47+0200, Tobias Burnus wrote:
> commit 508ef585243d4674d06b0737bfe8769fc18f824f
> Author: Tobias Burnus
> Date: Fri Sep 13 16:18:46 2024 +0200
>
> gcn/mkoffload.cc: Use #embed for including the gen
gcc.dg/vect/vect-live-2.c shows it's important to handle live but
otherwise unused pattern stmts.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (vect_analyze_slp): Lookup patterns when
discovering from only-live roots.
---
gcc/tree-vect-slp.cc |
Today the following logic is in-place for loading spec files:
* Discover /specs
** If available, load it
** Else generate builtin specs (equivalent of -dumpspecs)
** `%include`, `%include_noerr`, `%rename` not allowed
* If `-specs=` passed, load them in order
** `%include`, `%include_noerr`, `%re
Previously either "specs" file was read, or built-in specs were
generated.
With this change, always load generated "built-in" specs, prior to
discovering and loading optional "specs" file.
Also relax, and allow using "%include", "%include_noerr", and
"%rename" commands in the "specs" file.
Then
After automatically discovered "specs" file is loaded, or in its
absence "built-in" specs are generated; attempt to discover
"specs.overlay" and load it.
Unlike "specs", "specs.overlay" allows using "%include",
"%include_noerr" and "%rename" commands, similar to user provided
`-specs` on the comma
Hi All,
The testcase for this tests needs Neoverse V2 to be used
since due to costing the other cost models don't pick this
particular SVE mode.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
committed as obvious.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tree-optimiz
Hi everyone,
I am writing the internals for the modulo scheduler,
that I will join together with my incoming serie of patches.
I would like your opinion on the attached texinfo file, and are these utf-8
box characters legal for our doc ?
It is still a work in progress. I have focused on detailing
Hi Tobias!
On 2024-09-19T19:11:32+0200, Tobias Burnus wrote:
> OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines
'[omp_]get_device_from_uid'.
> Those TR13/OpenMP 6.0 routines permit a reproducible offloading to
> a specific device by mapping an OpenMP device number to a
> unique
Hi All,
Consider low overhead loops like:
void
foo (char *restrict a, int *restrict b, int *restrict c, int n)
{
for (int i = 0; i < 9; i++)
{
int res = c[i];
int t = b[i];
if (a[i] != 0)
res = t;
c[i] = res;
}
}
For such loops we use latency only costin
> For variable-sized vectors, I suppose the question is whether the
> first unequal element is found in the minimum vector length, or whether
> it only occurs for larger lengths. In the former case we can fold at
> compile time, but in the latter case we can't.
>
> So we probably do want the loop
With SLP this token appears a lot, when looking for what gets code
generated instead look for " = VEC_PERM_EXPR"
Pushed.
PR testsuite/116397
* gcc.dg/vect/slp-reduc-3.c: Look for " = VEC_PERM_EXPR"
instead of "VEC_PERM_EXPR".
---
gcc/testsuite/gcc.dg/vect/slp-reduc-3.c |
On Fri, Sep 20, 2024 at 12:58 PM wrote:
>
> From: Pan Li
>
> This patch would like to support the form 2 of the vector signed
> integer .SAT_ADD. Aka below example:
>
> Form 2:
> #define DEF_VEC_SAT_S_ADD_FMT_2(T, UT, MIN, MAX) \
> void __attribute__((noinline))
gcc.dg/vect/vect-pr111779.c is a case where non-SLP manages to vectorize
using VMAT_ELEMENTWISE but SLP currently refuses because doing a regular
access with permutes would cause excess vector loads with at most one
element used. The following makes us fall back to elementwise accesses
for that, t
From: Pan Li
This patch would like to support the form 2 of the vector signed
integer .SAT_ADD. Aka below example:
Form 2:
#define DEF_VEC_SAT_S_ADD_FMT_2(T, UT, MIN, MAX) \
void __attribute__((noinline)) \
vec_sat_s_add_##T##_fmt_
From: Pan Li
Form 2:
#define DEF_VEC_SAT_S_ADD_FMT_2(T, UT, MIN, MAX) \
void __attribute__((noinline)) \
vec_sat_s_add_##T##_fmt_2 (T *out, T *op_1, T *op_2, unsigned limit) \
{
On 9/19/24 16:05, Stefan Schulze Frielinghaus wrote:
I have been missing the two test cases and removed them since they
depend on -mno-lra.
-- 8< --
Since the old reload pass is about to be removed and we defaulted to LRA
for over a decade, remove option -m{,no-}lra.
PR target/113953
gcc/Chan
On Fri, Sep 20, 2024 at 11:12 AM Eric Botcazou wrote:
>
> Hi,
>
> the attached C testcase exhibits a wrong-code regression present since the
> specific support for the static chain was added to the IPA mod/ref pass (GCC
> 12 and later) although the underlying issue might have been present before.
On Fri, Sep 20, 2024 at 10:23 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> > On 17 Sep 2024, at 7:36 pm, Richard Biener
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Sep 17, 2024 at 10:31 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi
Hi Saurabh,
On 9/18/24 21:53, Saurabh Jha wrote:
Hi Wilco,
Thanks for the patch. This mostly looks good. Just added a couple
clarifications.
On 9/18/2024 8:17 PM, Wilco Dijkstra wrote:
v2: Add more testcase fixes.
The current copysign pattern has a mismatch in the predicates and
constrain
Wilco Dijkstra writes:
> v2: Add more testcase fixes.
>
> The current copysign pattern has a mismatch in the predicates and constraints
> -
> operand[2] is a register_operand but also has an alternative X which allows
> any
> operand. Since it is a floating point operation, having an integer
>
For svmul, if one of the operands is a constant vector with a uniform
power of 2, this patch folds the multiplication to a left-shift by
immediate (svlsl).
Because the shift amount in svlsl is the second operand, the order of the
operands is switched, if the first operand contained the powers of 2.
Hi,
the attached C testcase exhibits a wrong-code regression present since the
specific support for the static chain was added to the IPA mod/ref pass (GCC
12 and later) although the underlying issue might have been present before.
When a memory copy operation is analyzed by analyze_ssa_name, i
This is supposed to document that GCC now supports offloading,
e.g., from an ARM CPU to a Nvidia GPU (i.e. Grace<->Hopper)
or, e.g., x86-64 to RISC-V. → https://gcc.gnu.org/PR96265
and https://gcc.gnu.org/PR111937 for the associated PRs.
I think it is important enough to get it into the release n
Hi Sam!
On 2024-09-20T05:12:19+0100, Sam James wrote:
> In this case, they were all harmless in reality (no diff in test logs).
> -/* { dg-do compile ) */
> +/* { dg-do compile } */
DejaGnu directives are matched by '{ dg-[...] }' (simplified; see
'/usr/share/dejagnu/dg.exp:dg-get-options' for
Fix typos in comments.
Signed-off-by: Andrew Kreimer
---
libobjc/Makefile.in | 2 +-
libobjc/configure| 2 +-
libobjc/encoding.c | 4 ++--
libobjc/exception.c | 4 ++--
libobjc/hash.c | 2 +-
libobjc/init.c
Hi Richard,
> On 17 Sep 2024, at 7:36 pm, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, Sep 17, 2024 at 10:31 AM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>>> On 10 Sep 2024, at 9:33 pm, Richard Biener
>>> wrote:
>>>
>>> External em
A minor update for a bug fix / impl.-quality feature and a proper new
feature.
Any comments before I apply it?
Tobias
gcc-15: Update OpenMP section for constr/destr on devices + UID routines
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 7c372688..14514131 100644
--
Hi all,
I thought it makes sense to have a look at what went into GCC 15 to
update the Fortran section. However, while several bugs were fixed
(and extended some features a tiny bit) [hooray!], I did not really
see many newsworthy features.
Comments, remarks to, approval of the attached wwwdocs
> On 19 Sep 2024, at 15:39, Claudio Bantaloukas
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> On 9/19/2024 2:18 PM, Kyrylo Tkachov wrote:
>> Hi Claudio,
>>
>>> On 19 Sep 2024, at 15:09, Claudio Bantaloukas
>>> wrote:
>>>
>>> External email: Use caution openi
On Wed, Sep 18, 2024 at 02:50:39PM -0600, Sandra Loosemore wrote:
> Here's the revised patch, covering both restrictions. OK to commit?
Thanks.
> + /* Each trait-property can only be specified once in a trait-selector
> + other than the construct selector set. FIXME: only handles
Now applied as r15-3730-gbf4a5efa80ef84 /
https://gcc.gnu.org/r15-3730-gbf4a5efa80ef84
(with a few minor tailing whitespace/indentation issues fixed).
Post-commit comments are still highly welcome. By tomorrow, you will
find the documentation at https://gcc.gnu.org/onlinedocs/libgomp/
(routi
Fix some target-specific 'do-' (rather than 'dg-') typos.
gcc/testsuite/ChangeLog:
* gcc.target/m68k/pr108640.c: Fix dg directive typo.
* gcc.target/m68k/pr110934.c: Ditto.
* gcc.target/m68k/pr82420.c: Ditto.
* gcc.target/powerpc/pr99708.c: Ditto.
---
Committed as
On Fri, Sep 20, 2024 at 9:08 AM Richard Biener
wrote:
>
> On Fri, Sep 20, 2024 at 8:32 AM Jakub Jelinek wrote:
> >
> > On Fri, Sep 20, 2024 at 08:01:58AM +0200, Richard Biener wrote:
> > > > P.S. I have a patch to replace UNSPEC_IEEE_M{AX,IN} with IF_THEN_ELSE
> > > > (except for the 3dNOW! PFMIN
On Fri, Sep 20, 2024 at 8:32 AM Jakub Jelinek wrote:
>
> On Fri, Sep 20, 2024 at 08:01:58AM +0200, Richard Biener wrote:
> > > P.S. I have a patch to replace UNSPEC_IEEE_M{AX,IN} with IF_THEN_ELSE
> > > (except for the 3dNOW! PFMIN/MAX, those actually are documented to behave
> > > differently), b
89 matches
Mail list logo
