Regarding shortening it: no need to duplicate what's in the git commit
log, just keep it at the minimum for at-a-glance use.
-- >8 --
* config/cris/cris.cc (cris_option_override_after_change): Fix up
comment regarding disabling late_combine.
---
gcc/config/cris/cris.cc | 7
Heads-up to xtensa maintainers, who might similarly want to move the
option-override to TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (and call it
from TARGET_OPTION_OVERRIDE).
Regarding disabling that optimization: with the brief description per
the below, I think I've done due diligence when it comes to
On Wed, Jul 10, 2024 at 12:49 PM Ian Lance Taylor wrote:
> On Sun, May 26, 2024 at 11:51 PM Max Filippov wrote:
> > diff --git a/libbacktrace/internal.h b/libbacktrace/internal.h
> > index 4fa0af8cb6c9..456911166026 100644
> > --- a/libbacktrace/internal.h
> > +++ b/libbacktrace/internal.h
> >
Translate DW_TAG_subprogram DIEs into CodeView LF_FUNC_ID types and
S_GPROC32_ID / S_LPROC32_ID symbols. ld will then transform these into
S_GPROC32 / S_LPROC32 symbols, which map addresses to unmangled function
names.
gcc/
* dwarf2codeview.cc (enum cv_sym_type): Add new values.
Updated version with common code for C/C++ extracted in c-family.
Other than that no changes.
Is this version ok to commit?
---
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed
Here's an updated patch with your feedback addressed.
Is this version ok?
The common code is in the C++ patch.
---
Implement a C23 clang compatible musttail attribute similar to the earlier
C++ implementation in the C parser.
gcc/c/ChangeLog:
PR c/83324
* c-parser.cc (struct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
This marks structures which include a byte array
as typeless storage for all C language modes.
Bootstrapped and regression tested on x86_64.
c: Add support for byte arrays in C2Y
To get correct aliasing behavior requires that
Hi All,
Harald has pointed out that I attached the ChangeLog twice and the patch
not at all :-(
Please find the patch duly attached.
Paul
On Sat, 13 Jul 2024 at 10:58, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> After messing around with argument mapping, where
When transforming multiple lane-reducing operations in a loop reduction chain,
originally, corresponding vectorized statements are generated into def-use
cycles starting from 0. The def-use cycle with smaller index, would contain
more statements, which means more instruction dependency. For
For lane-reducing operation(dot-prod/widen-sum/sad) in loop reduction, current
vectorizer could only handle the pattern if the reduction chain does not
contain other operation, no matter the other is normal or lane-reducing.
This patches removes some constraints in reduction analysis to allow
Vector stmts number of an operation is calculated based on output vectype.
This is over-estimated for lane-reducing operation, which would cause vector
def/use mismatched when we want to support loop reduction mixed with lane-
reducing and normal operations. One solution is to refit lane-reducing
Extend original vect_get_num_copies (pure loop-based) to calculate number of
vector stmts for slp node regarding a generic vect region.
Thanks,
Feng
---
gcc/
* tree-vectorizer.h (vect_get_num_copies): New overload function.
(vect_get_slp_num_vectors): New function.
*
> > Hi, Richard,
> >
> > Let me explain some idea that has to be chosen for lane-reducing. The key
> > complication is that these ops are associated with two kinds of vec_nums,
> > one is number of effective vector stmts, which is used by partial
> > vectorzation
> > function such as
In g:44fc801e97a8dc626a4806ff4124439003420b20 I'd extended
insn_propagation to handle simple cases of hard-reg mode punning.
One of the checks was that the new use mode occupied the same
number of registers as the original definition mode. However,
as PR115901 shows, we need to avoid increasing
The asm in the testcase has a memory operand and also clobbers ax.
The clobber means that ax cannot be used to hold inputs, which
extends to the address of the memory.
I think I had an implicit assumption that constrain_operands
would enforce this, but in hindsight, that clearly wasn't going
to
Changes since v4:
- No functional changes.
- Use int iterator and attr to implement expanders in md
(inspired by loongarch patch. Thx Xi Ruoyao)
Changes since v3:
- Remove '*' from define_insn for fclass
- Remove the dummy expander for fclass.
- De-duplicate the expanders code by
Since r6-4582-g8a64515099e645 (which added class rich_location), ranges
of quoted source code have been colorized using the following rules:
- the primary range used the same color of the kind of the diagnostic
i.e. "error" vs "warning" etc (defaulting to bold red and bold magenta
respectively)
-
Hello Richard:
On 12/07/24 6:20 pm, Richard Biener wrote:
> On Fri, Jul 12, 2024 at 12:09 PM Ajit Agarwal wrote:
>>
>> Hello Richard:
>>
>> On 11/07/24 2:21 pm, Richard Biener wrote:
>>> On Thu, Jul 11, 2024 at 10:30 AM Ajit Agarwal
>>> wrote:
Hello All:
Unroll factor is
Hello Richard:
On 12/07/24 6:20 pm, Richard Biener wrote:
> On Fri, Jul 12, 2024 at 12:09 PM Ajit Agarwal wrote:
>>
>> Hello Richard:
>>
>> On 11/07/24 2:21 pm, Richard Biener wrote:
>>> On Thu, Jul 11, 2024 at 10:30 AM Ajit Agarwal
>>> wrote:
Hello All:
Unroll factor is
On Fri, 12 Jul 2024 at 21:31, Patrick Palka wrote:
>
> Interesting, thanks for the detailed write-up!
Thank you very much.
> FWIW it should be much easier to obtain the partially specialised
> tmpl/args of a class/variable specialization since GCC 14, by looking
> at TI_PARTIAL_INFO of
Hi All,
After messing around with argument mapping, where I found and fixed another
bug, I realised that the problem lay with simplification of len_trim with
an argument that is the element of a parameter array. The fix was then a
straightforward lift of existing code in expr.cc. The mapping bug
From: Mikael Morin
Hello,
I'm currently testing this on x86_64-linux.
I plan to push to master if all goes well.
Mikael
-- 8< --
Add the preliminary code that the generated expression for MASK may depend
on when generating the inline code to evaluate MINLOC or MAXLOC with a
scalar MASK.
The
gcc/ChangeLog:
* config/loongarch/loongarch-protos.h
(loongarch_split_128bit_move): Delete.
(loongarch_split_128bit_move_p): Delete.
(loongarch_split_256bit_move): Delete.
(loongarch_split_256bit_move_p): Delete.
(loongarch_split_vector_move): Add a
The entire osl.iu.edu site has gone away without direct replacement.
---
htdocs/gcc-3.1/criteria.html | 3 +--
htdocs/gcc-3.3/criteria.html | 3 +--
htdocs/gcc-3.4/criteria.html | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/htdocs/gcc-3.1/criteria.html
Hi,
According to the instruction spec of AVX512BF16, the convert from float
to BF16 is not a simple truncation. It has special handling for
denormal/nan, even for normal float it will add an extra bias according
to the least significant bit for bf number. This means we cannot use the
The new site does not offer https, so staying with http.
Pushed.
Gerald
On the way remove a mailto: link to offer g77 help from 1999.
---
htdocs/news.html | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/htdocs/news.html b/htdocs/news.html
index 5e782349..6fac4ea5
26 matches
Mail list logo
