On 11/13/24 7:16 AM, Mariam Arutunian wrote:
To address this, I added code in |target-supports.exp| and modified the
relevant tests.
I've attached the patch. Could you please check whether it is correct?
Just a few more notes.
I revamped the changes to emit_crc. I think the right way t
The problem here is c_parser_skip_until_found stops at a closing nesting
delimiter without consuming it. So if we don't consume it in
c_parser_gimple_compound_statement, we would go into an infinite loop. The C
parser similar code in c_parser_statement_after_labels to handle this specific
case too.
Hi,
another common source of unnecesary throw_bad_alloc calls is
basic_string::_M_create.
basic_string<_CharT, _Traits, _Alloc>::
_M_create(size_type& __capacity, size_type __old_capacity)
{
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 83. String::npos vs. string::max_size()
i
On Mon, 11 Nov 2024, Haochen Jiang wrote:
> This patch will add recent new ISA and arch support for x86_64 backend into
> gcc-wwwdocs.
> + New ISA extension support for Intel AMX-AVX512 was added.
In all these cases, can we just sasy "ISA extension support ... was
added" and drop the "New"?
>
On Sat, Nov 23, 2024 at 07:26:55PM +0100, Heiko Eißfeldt wrote:
> --- a/gcc/varasm.cc
> +++ b/gcc/varasm.cc
> @@ -993,9 +993,12 @@ decode_reg_name_and_count (const char *asmspec, int
> *pnregs)
> break;
>if (asmspec[0] != 0 && i < 0)
> {
> - i = atoi (asmspec);
> -
Hi,
looking into reason why we still do throw_bad_alloc in clang binary I noticed
that quite few calls come from deque::_M_reallocate_map. This patch adds
unreachable to limit the size of realloc_map. _M_reallocate_map is called only
if new size is smaller then max_size. map is an array holding
On Nov 21, 2024, at 7:49 AM, Carl Love wrote:
>
> Ping 6
>
> On 11/14/24 1:36 PM, Carl Love wrote:
>> Ping 5
>>
>> On 11/5/24 8:27 AM, Carl Love wrote:
>>> Ping 4
>>>
>>> On 10/28/24 4:28 PM, Carl Love wrote:
Ping 3
On 10/17/24 1:31 PM, Carl Love wrote:
> Ping 2
>
On 11/23/24 10:59 AM, Harald Anlauf wrote:
Am 23.11.24 um 19:35 schrieb Jerry D:
Suggested docs change regarding fix to PR88052.
See attached diff file.
OK to push?
Regards,
Jerry
Jerry,
for clarification: isn't it the language standard option used when
compiling the main that is relevant
Hi!
On 2024-08-01T16:56:44+0200, Arthur Cohen wrote:
> --- a/libgrust/libformat_parser/src/lib.rs
> +++ b/libgrust/libformat_parser/src/lib.rs
> [...]
> +let rust_string = RustString {
> +len: str.len(),
> +cap: str.capacity(),
> +ptr: str.leak().as_ptr(),
> +};
>
On Sat, Nov 23, 2024 at 7:25 AM Thomas Schwinge wrote:
>
> Hi Andrew!
>
> On 2024-11-22T13:15:13-0800, Andrew Pinski wrote:
> > Since diagnostic.h is included in over half of the sources, requiring to
> > `#define INCLUDE_MEMORY`
> > does not make sense. Instead lets unconditionally include memo
This patch tries fixes the errors we have because of
flexible array members. I am bit unsure about the exception
for the mode.
Bootstrapped and regression tested on x86_64.
Fix type compatibility for types with flexible array member
[PR113688,PR114014,PR117724]
verify_type che
Am 23.11.24 um 19:35 schrieb Jerry D:
Suggested docs change regarding fix to PR88052.
See attached diff file.
OK to push?
Regards,
Jerry
Jerry,
for clarification: isn't it the language standard option used when
compiling the main that is relevant? The main might be compiled
separately fro
Thanks for considering (when the time is right),
but in the meantime I found a technical problem with my patch, so I am
replacing it with a correct one (please ignore the older one).
The problem was assigning to an integer from a long result was plain
wrong, because ERANGE checking in strtol() w
Suggested docs change regarding fix to PR88052.
See attached diff file.
OK to push?
Regards,
Jerry
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 46dad391..2dc222e3 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -143,6 +143,10 @@ a work-
Hi Paul,
Am 23.11.24 um 17:05 schrieb Paul Richard Thomas:
Hi All,
I was going through some of the older regressions and found pr84674, which
was distinctly low hanging fruit because the contributor has found the
offending bit of code. However, buried in this PR, on the grounds that it
looked s
On 11/23/24 12:40 AM, Thomas Koenig wrote:
Hi Jerry,
I had originally created this patch in 2018 and we did not get back to
it. This results in more restrictive runtime behavior. I will go
through the front-end code with another patch to catch this at compile
time.
Changelog and new test ca
Hi Maciej,
On Sat, 2024-11-23 at 12:28 +, Maciej W. Rozycki wrote:
> > Thanks a lot for your work, much appreciated!
>
> You are welcome!
>
> > I gave this a try on gcc.git master with LRA enabled for both non-BWX and
> > BWX targets. BWX targets build fine with almost all languages enabled
Hi All,
I was going through some of the older regressions and found pr84674, which
was distinctly low hanging fruit because the contributor has found the
offending bit of code. However, buried in this PR, on the grounds that it
looked similar, was what has now become pr117730. This was quite diffi
Hi Andrew!
On 2024-11-22T13:15:13-0800, Andrew Pinski wrote:
> Since diagnostic.h is included in over half of the sources, requiring to
> `#define INCLUDE_MEMORY`
> does not make sense. Instead lets unconditionally include memory in system.h.
>
> The majority of this patch is just removing `#def
On 11/6/24 9:39 PM, Mark Harmstone wrote:
Translate DW_TAG_inlined_subroutine DIEs into S_INLINESITE CodeView
symbols, marking inlined functions.
gcc/
* dwarf2codeview.cc (enum cv_sym_type): Add S_INLINESITE and
S_INLINESITE_END.
(get_func_id): Add declaration.
On 11/6/24 9:39 PM, Mark Harmstone wrote:
Add a parameter to the begin_block debug hook that is a pointer to the
tree_node of the block in question. CodeView needs this as it records
line numbers of inlined functions in a different manner, so we need to
be able to tell if the block is actually
On 11/6/24 9:39 PM, Mark Harmstone wrote:
When outputting the .debug$S CodeView section, also write an
S_INLINEELINES subsection, which records the filename and line number of
the start of each inlined function.
gcc/
* dwarf2codeview.cc (DEBUG_S_INLINEELINES): Define.
(CV_INLI
On 11/6/24 9:39 PM, Mark Harmstone wrote:
If we encounter an inlined function, treat it as another
codeview_function, and skip over these when outputting line numbers.
This information will instead be output as part of the S_INLINESITE
symbols.
gcc/
* dwarf2codeview.cc (struct codevie
On 11/12/24 5:57 PM, Mark Harmstone wrote:
If a function is contained in two sections, for instance if it is
partially cold, it gets a DW_AT_ranges attribute in its DIE rather than
the normal DW_AT_low_pc and DW_AT_high_pc.
There's no way to express this in CodeView, so rather than skipping t
On Mon, 18 Nov 2024, Richard Sandiford wrote:
> > gcc/
> > * function.h (struct function): Add
> > `split_basic_blocks_after_reload' member.
> > * lra.cc (lra): Handle it.
> > * reload1.cc (reload): Likewise.
>
> OK, thanks.
Thank you for your review. I'll commit the chang
On Tue, 19 Nov 2024, Jeff Law wrote:
> > gcc/testsuite/
> > * gcc.c-torture/execute/memcpy-a1.c: New file.
> > * gcc.c-torture/execute/memcpy-a2.c: New file.
> > * gcc.c-torture/execute/memcpy-a4.c: New file.
> > * gcc.c-torture/execute/memcpy-a8.c: New file.
> > * gcc.c-to
On Tue, 19 Nov 2024, Joseph Myers wrote:
> > The $(GCC_PARTS) variable was deleted with the Makefile rework in commit
> > fa9585134f6f ("libgcc move to the top level")[1] back in 2007, and yet
> > the Ada and Modula 2 frontends added references to this variable later
> > on, with commit e972fd5
Andrew Pinski writes:
> I missed these in r15-5603-gb3f1b9e2aa079f8ec73e because they
> were no in a `.cc` or `.h` file or they were outside of the gcc
> subdirectory.
>
> Bootstrapped and tested on x86_64-linux-gnu.
>
> gcc/m2/ChangeLog:
>
> * mc/keyc.mod: Don't print `#define INCLUDE_MEMO
Hi!
Another DW_LANG_* code has been added recently...
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2024-11-23 Jakub Jelinek
* dwarf2.h (enum dwarf_source_language): Add DW_LANG_Fortran23
enumerator.
--- include/dwarf2.h.jj 2024-11-21
Hi Adrian,
> > This has come out of a discussion[1] around the removal of non-BWX Alpha
> > support from the Linux kernel due to data races affecting RCU algorithms.
> > (...)
> > Comments, questions, voices of concern or appreciation, all very welcome.
>
> Thanks a lot for your work, much ap
On Tue, 19 Nov 2024, Maciej W. Rozycki wrote:
> > time I think the RMW sequence on _Atomic variables is a clear
> > bug that you'd need to fix also for -mno-safe-bwa.
>
> That's weird indeed, GCC internals manual clearly says:
>
> "'atomic_storeMODE'
> This pattern implements an atomic sto
Correct an issue with 8-bit/16-bit stores to `_Atomic' QI and HI data
objects producing non-BWX assembly such as:
mb
insql $17,$16,$17
ldq_u $1,0($16)
mskwl $1,$16,$1
bis $17,$1,$17
stq_u $17,0($16)
mb
for:
void
atomic_store16 (_Atomic uns
Applied as obvious.
Johann
--
AVR: target/117744 - Fix asm for partial clobber of address reg,
gcc/
PR target/117744
* config/avr/avr.cc (out_movqi_r_mr): Fix code when a load
only partially clobbers an address register due to
changing the address register tempo
Andrew Pinski writes:
> Since diagnostic.h is included in over half of the sources, requiring to
> `#define INCLUDE_MEMORY`
> does not make sense. Instead lets unconditionally include memory in system.h.
>
> The majority of this patch is just removing `#define INCLUDE_MEMORY` from the
> sources
> What I didn’t say before is that, if for example an exception is raised
> in Ada Language Server and the code uses s-trasym to output a report,
> what you get on macOS is, for example,
>
> ALS.MAIN] in GNATformat Format
> [ALS.MAIN] raised CONSTRAINT_ERROR : erroneous memory access
> _ALS.MAIN_
From: yulong
This patch modifies the char string from __riscv_xsfvcp to __riscv_xsfcease.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-sf-2.c: Modify the char string.
---
gcc/testsuite/gcc.target/riscv/predef-sf-2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
Hi Jerry,
I had originally created this patch in 2018 and we did not get back to
it. This results in more restrictive runtime behavior. I will go through
the front-end code with another patch to catch this at compile time.
Changelog and new test case. See attached patch.
OK for trunk
Yes, O
37 matches
Mail list logo
