On 23/09/24 11:06 -0400, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
Yes please, I've wanted this for years, but it wasn't practical until
you changed some of the warnings recently.
Thanks!
On Fri, 20 Sep 2024, Tobias Burnus wrote:
> Comments, remarks to, approval of the attached wwwdocs patch?
+ Experimental support for unsigned integers; enabled by the
+ -funsigned, see https://gcc.gnu.org/onlinedocs/gfortran/Experimental-features-for-Fortran-202Y.html";
+ >gfortran docu
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
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 r
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
Hi!
Regarding ongoing maintenance efforts, and avoiding to build multilib
variants that probably nobody uses apart from a few of us testing these
out of routine (via building/linking with explicit '-mptx=3.1'), I
propose: "GCC 15: nvptx '-mptx=3.1' multilib variants are
On Thu, 19 Sep 2024, Haochen Jiang wrote:
> When I was backporting my doc patch in gcc trunk today, I found when
> adding -march=gracemont in GCC14, the corresponding wwwdoc is missing.
> This patch is adding that.
This looks fine, thank you.
Gerald
Hi all,
When I was backporting my doc patch in gcc trunk today, I found when adding
-march=gracemont in GCC14, the corresponding wwwdoc is missing. This patch
is adding that.
Ok for wwwdocs trunk?
Thx,
Haochen
---
htdocs/gcc-14/changes.html | 4
1 file changed, 4 insertions(+)
diff
On Tue, Sep 17, 2024 at 3:40 AM Dora, Sunil Kumar
wrote:
>
> Hi Andrew,
>
> Initially, I thought to address long command line options (when exceeding
> 128KB) without disrupting the existing GCC driver behavior.
>
> As you suggested, I implemented changes to use the
On Tue, Sep 17, 2024 at 11:13:09AM +0200, Jakub Jelinek wrote:
> So maybe better
> tree arg = e_p->value;
> tree f;
> if ((in_typeof || in_alignof)
> && TREE_CODE (arg) == COMPONENT_REF
> && (f = TREE_OPERAND (arg, 1))
> && TRE
On Sat, Sep 14, 2024 at 08:58:28PM +0200, Jakub Jelinek wrote:
> if (has_counted_by_object (e_p->value))
> expr.value = get_counted_by_ref (e_p->value);
> else if (in_typeof && TREE_CODE (e_p->value) == COMPONENT_REF)
> {
> tree counted_by_t
> On Sep 14, 2024, at 8:59 PM, Jakub Jelinek wrote:
>
> On Wed, Sep 11, 2024 at 09:13:40PM +, Qing Zhao wrote:
>> @@ -11741,6 +11770,55 @@ c_parser_postfix_expression (c_parser *parser)
>>set_c_expr_source_range (&expr, loc, close_paren_loc);
>>break;
>> }
>> +case
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This
On Wed, Sep 11, 2024 at 09:13:40PM +, Qing Zhao wrote:
> @@ -11741,6 +11770,55 @@ c_parser_postfix_expression (c_parser *parser)
> set_c_expr_source_range (&expr, loc, close_paren_loc);
> break;
> }
> + case RID_BUILTIN_COUNTED_BY_REF:
> + {
> + vec
t; available at [1].
>
> To check whether the assembler being used to build the toolchain
> supports these directives, a new gcc configure check is added in
> gcc/configure.ac.
>
> If the assembler support these directives, .aeabi_subsection and
> .aeabi_attribute directiv
bler being used to build the toolchain
> supports these directives, a new gcc configure check is added in
> gcc/configure.ac.
>
> If the assembler support these directives, .aeabi_subsection and
> .aeabi_attribute directives are emitted in the generated assembly,
> when -mbran
;>*__p = kmalloc(__size); \
>> })
>>
>> Right now, any addition of a counted_by annotation must also
>> include an open-coded assignment of the counter variable after
>> the allocation:
>>
>> p = alloc(p, array, how_many);
>> p->counter =
; \
> *__p = kmalloc(__size); \
> })
>
> Right now, any addition of a counted_by annotation must also
> include an open-coded assignment of the counter variable after
> the allocation:
>
> p = alloc(p, array, how_many);
> p->counter = how_many;
>
>
ually adding
the open-coded counted-by intializations everywhere in the Linux
kernel, a new GCC builtin __builtin_counted_by_ref will be very useful
to be added to help the adoption of the counted-by attribute.
-- Built-in Function: TYPE __builtin_counted_by_ref (PTR)
The built-in function '__bu
available at [1].
To check whether the assembler being used to build the toolchain
supports these directives, a new gcc configure check is added in
gcc/configure.ac.
If the assembler support these directives, .aeabi_subsection and
.aeabi_attribute directives are emitted in the generated asse
Qing Zhao writes:
> Hi,
>
> I was trying to study an old posted patch (but was not approved and
> committed) in the following link:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561096.html
>
> However, I cannot get the patch from the atta
> On Sep 10, 2024, at 17:47, Jakub Jelinek wrote:
>
> On Tue, Sep 10, 2024 at 09:28:04PM +, Qing Zhao wrote:
>> @@ -11741,6 +11770,54 @@ c_parser_postfix_expression (c_parser *parser)
>>set_c_expr_source_range (&expr, loc, close_paren_loc);
>>break;
>> }
>> + case RID_BUILTIN_COUNT
Hi,
I was trying to study an old posted patch (but was not approved and committed)
in the following link:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561096.html
However, I cannot get the patch from the attachment part as following:
-- next part --
A non
On Tue, Sep 10, 2024 at 09:28:04PM +, Qing Zhao wrote:
> @@ -11741,6 +11770,54 @@ c_parser_postfix_expression (c_parser *parser)
> set_c_expr_source_range (&expr, loc, close_paren_loc);
> break;
> }
> + case RID_BUILTIN_COUNTED_BY_REF:
> + {
> + vec
rone work of manually adding
the open-coded counted-by intializations everywhere in the Linux
kernel, a new GCC builtin __builtin_counted_by_ref will be very useful
to be added to help the adoption of the counted-by attribute.
-- Built-in Function: TYPE __builtin_counted_by_ref (PTR
offsetof(__typeof(*__p), FAM),
>> you can't have an offset outside of a structure (ok, except doing something
>> like use fld[100] as FAM). offsetof + sizeof (elt) * count is the actually
>> needed size, say if it is
>
> (offset + sizeof * c) could be smaller than si
Am Dienstag, dem 10.09.2024 um 20:36 +0200 schrieb Jakub Jelinek:
> On Tue, Sep 10, 2024 at 06:31:23PM +, Qing Zhao wrote:
> >
> >
> > > On Sep 10, 2024, at 14:09, Jakub Jelinek wrote:
> > >
> > > On Tue, Sep 10, 2024 at 06:02:45PM +, Qing Zhao wrote:
> > > > > #define alloc(P, FAM, COU
On Tue, Sep 10, 2024 at 06:31:23PM +, Qing Zhao wrote:
>
>
> > On Sep 10, 2024, at 14:09, Jakub Jelinek wrote:
> >
> > On Tue, Sep 10, 2024 at 06:02:45PM +, Qing Zhao wrote:
> >>> #define alloc(P, FAM, COUNT) ({ \
> >>> __auto_type __p = &(P); \
> >>> __auto_type __c = (COUNT); \
> >>>
> On Sep 10, 2024, at 14:09, Jakub Jelinek wrote:
>
> On Tue, Sep 10, 2024 at 06:02:45PM +, Qing Zhao wrote:
>>> #define alloc(P, FAM, COUNT) ({ \
>>> __auto_type __p = &(P); \
>>> __auto_type __c = (COUNT); \
>>> size_t __size = sizeof(*(*__p)) + sizeof(*(*__p)->FAM) * __c; \
>
> Shouldn
dious and error-prone work of manually adding
the open-coded counted-by intializations everywhere in the Linux
kernel, a new GCC builtin __builtin_counted_by_ref will be very useful
to be added to help the adoption of the counted-by attribute.
-- Built-in Function: TYPE __builtin_counted_by_ref (P
On Tue, Sep 10, 2024 at 06:02:45PM +, Qing Zhao wrote:
> > #define alloc(P, FAM, COUNT) ({ \
> > __auto_type __p = &(P); \
> > __auto_type __c = (COUNT); \
> > size_t __size = sizeof(*(*__p)) + sizeof(*(*__p)->FAM) * __c; \
Shouldn't that be
size_t __size = offsetof(__typeof(*__p), FAM) +
Thanks a lot for the tips.
I updated the 2 testing cases per your suggestion, they work well.
I will send the 3rd version of the patch soon.
Qing
> On Sep 10, 2024, at 11:42, Martin Uecker wrote:
>
> Am Dienstag, dem 10.09.2024 um 13:51 + schrieb Qing Zhao:
>> #define alloc(P, FAM, COUN
Am Dienstag, dem 10.09.2024 um 13:51 + schrieb Qing Zhao:
> #define alloc(P, FAM, COUNT) ({ \
> typeof(P) __p; \
> size_t __size = sizeof(*P) + sizeof(*P->FAM) * COUNT; \
> __p = kmalloc(__size, GFP); \
> typeof(_Generic(__builtin_counted_by_ref(__p->FAM), \
>
_many;
In order to avoid the tedious and error-prone work of manually adding
the open-coded counted-by intializations everywhere in the Linux
kernel, a new GCC builtin __builtin_counted_by_ref will be very useful
to be added to help the adoption of the counted-by attribute.
-- Built-i
Ada build on SPARC:
>>
>> In file included from ./tm_p.h:4,
>> from
>> /vol/gcc/src/hg/master/local/gcc/ada/gcc-interface/misc.cc:31:
>> /vol/gcc/src/hg/master/local/gcc/config/sparc/sparc-protos.h:46:47: error:
>> use of enum ‘memmodel’ without prev
On Sun, Sep 8, 2024 at 3:07 AM Martin Uecker wrote:
>
> Am Sonntag, dem 08.09.2024 um 02:09 -0700 schrieb Bill Wendling:
> > On Fri, Sep 6, 2024 at 10:50 PM Martin Uecker wrote:
> > >
> > > Am Freitag, dem 06.09.2024 um 13:59 -0700 schrieb Bill Wendling:
> > > > On Fri, Sep 6, 2024 at 12:32 PM Ma
> On Sep 9, 2024, at 10:20, Jakub Jelinek wrote:
>
> On Mon, Sep 09, 2024 at 02:10:05PM +, Qing Zhao wrote:
>> Okay, now after finishing reading all the discussion so far, I realized that
>> we are back to the previous pointer approach:
>>
>> __builtin_get_counted_by (p->FAM)
>>
>> Works
On Mon, Sep 09, 2024 at 02:10:05PM +, Qing Zhao wrote:
> Okay, now after finishing reading all the discussion so far, I realized that
> we are back to the previous pointer approach:
>
> __builtin_get_counted_by (p->FAM)
>
> Works as:
>
> If (has_counted_by (p->FAM))
> return &p->COUNT;
>
Okay, now after finishing reading all the discussion so far, I realized that we
are back to the previous pointer approach:
__builtin_get_counted_by (p->FAM)
Works as:
If (has_counted_by (p->FAM))
return &p->COUNT;
else
return (void *)0;
Then the user will use it as:
auto p = __builtin_get
t;>>> Hi,
>>>>>>>
>>>>>>> Thanks for the information.
>>>>>>>
>>>>>>> Yes, providing a unary operator similar as __counted_by(PTR) as
>>>>>>> suggested by mu
On 8/23/24 09:41, Jan Hubicka wrote:
Since this is a pure compile test it makes sense to inform dejagnu of
it.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/gcov-23.c: Use dg-compile, not gcc -c
OK,
Honza
Thanks,
Pushed.
---
gcc/testsuite/gcc.misc-tests/gcov-23.c | 3 ++-
1 file
Am Sonntag, dem 08.09.2024 um 02:09 -0700 schrieb Bill Wendling:
> On Fri, Sep 6, 2024 at 10:50 PM Martin Uecker wrote:
> >
> > Am Freitag, dem 06.09.2024 um 13:59 -0700 schrieb Bill Wendling:
> > > On Fri, Sep 6, 2024 at 12:32 PM Martin Uecker wrote:
> > > > > > >
...
> > > >
> > > > My reco
. The idea is that if the
> counter can't be used as an l-value, we wouldn't add an implicit
> r-value -> l-value cast (an internal Clang AST node). In the cases
> where it can be used as an l-value, we add the implicit cast. I
> imagine GCC has some kind of analogue to tha
On Fri, Sep 6, 2024 at 11:16 PM Martin Uecker wrote:
>
> Am Samstag, dem 07.09.2024 um 00:12 + schrieb Qing Zhao:
> > Now, if
> >
> > 1. __builtin_get_counted_by should return a LVALUE instead of a pointer
> > (required by CLANG’s design)
> > And
> > 2. It’s better not to change the behavior
t; Yes, providing a unary operator similar as __counted_by(PTR) as
> >>>>> suggested by multiple people previously is a cleaner approach.
> >>>>>
> >>>>> Then the programmer will use the following:
> >>>>>
> >>>>&
unted_by(PTR) as
> > > > > > suggested by multiple people previously is a cleaner approach.
> > > > > >
> > > > > > Then the programmer will use the following:
> > > > > >
> > > > > > __builtin_choose_expr(
&
On Sat, Sep 07, 2024 at 07:50:29AM +0200, Martin Uecker wrote:
> > 2. Apple's implementation supports expressions in the '__counted_by'
> > attribute, thus the 'count' may be an R-value that can't have its
> > address taken.
> >
> > [1]
> > https://discourse.llvm.org/t/rfc-introducing-new-clang
gt; > > >
> > > > > > > Yes, providing a unary operator similar as __counted_by(PTR) as
> > > > > > > suggested by multiple people previously is a cleaner approach.
> > > > > > >
> > > > > > > Then the programm
; > > > > >
> > > > > > Yes, providing a unary operator similar as __counted_by(PTR) as
> > > > > > suggested by multiple people previously is a cleaner approach.
> > > > > >
> > > > > > Then the pro
n the programmer will use the following:
> > > > >
> > > > > __builtin_choose_expr(
> > > > > __builtin_has_attribute (__p->FAM, "counted_by”)
> > > > > __builtin_get_counted_by(__p->FAM) = COUNT, 0
ggested
>>>>> by multiple people previously is a cleaner approach.
>>>>>
>>>>> Then the programmer will use the following:
>>>>>
>>>>> __builtin_choose_expr(
>>>>>__builtin_has_attribute (__p->FAM, "counte
d_by”)
> > > > __builtin_get_counted_by(__p->FAM) = COUNT, 0);
> > > >
> > > > From the programmer’s point of view, it’s cleaner too.
> > > >
> > > > However, there is one issue with “__builtin_choose_expr” currently in
> >
rogrammer will use the following:
> > >
> > > __builtin_choose_expr(
> > > __builtin_has_attribute (__p->FAM, "counted_by”)
> > > __builtin_get_counted_by(__p->FAM) = COUNT, 0);
> > >
> > > From the programmer’s point of view, it’s
Following your suggestion, I have updated the logic to avoid hardcoding
> /tmp.
> Please find the revised version of patch at the following link:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662519.html
>
> Thanks,
> Sunil Dora
>
ed the logic to avoid hardcoding /tmp.
Please find the revised version of patch at the following link:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662519.html
Thanks,
Sunil Dora
From: Andrew Pinski
Sent: Friday, August 30, 2024 8:05 PM
To: Hemraj, Deept
_builtin_get_counted_by(__p->FAM) = COUNT, 0);
>>
>> From the programmer’s point of view, it’s cleaner too.
>>
>> However, there is one issue with “__builtin_choose_expr” currently in GCC,
>> its documentation explicitly mentions this limitation:
>> (https:
From: Deepthi Hemraj
For excessively long environment variables i.e >128KB
Store the arguments in a temporary file and collect them back together in
collect2.
This commit patches for COLLECT_GCC_OPTIONS issue:
GCC should not limit the length of command line passed to collect2.
ht
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Ukrainian team of translators. The file is available at:
https://translationproject.org/latest/gcc/uk.po
(This file, 'gcc-14.
file included from ./tm_p.h:4,
> from
> /vol/gcc/src/hg/master/local/gcc/ada/gcc-interface/misc.cc:31:
> /vol/gcc/src/hg/master/local/gcc/config/sparc/sparc-protos.h:46:47: error:
> use of enum ‘memmodel’ without previous declaration 46 | extern void
> sparc_e
/gcc/src/hg/master/local/gcc/ada/gcc-interface/misc.cc:31:
/vol/gcc/src/hg/master/local/gcc/config/sparc/sparc-protos.h:46:47: error: use
of enum ‘memmodel’ without previous declaration
46 | extern void sparc_emit_membar_for_model (enum memmodel, int, int
the programmer will use the following:
>
> __builtin_choose_expr(
> __builtin_has_attribute (__p->FAM, "counted_by”)
> __builtin_get_counted_by(__p->FAM) = COUNT, 0);
>
> From the programmer’s point of view, it’s cleaner too.
>
> However, there is o
Tested x86_64-linux. Pushed to gcc-14.
-- >8 --
For the backport, rejecting array types is only done in strict modes.
libstdc++-v3/ChangeLog:
PR libstdc++/116381
* include/std/variant (variant): Fix conditions for
static_assert to match the spec.
* testsu
---
htdocs/gcc-15/changes.html | 7 +++
1 file changed, 7 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index edce138e..7c372688 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -123,6 +123,13 @@ a work-in-progress.
+AMD
The old name was misleading.
While at it, also rename some temporary variables that are used with
this function, for consistency.
Link:
<https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120>
gcc/Cha
On Fri, Aug 30, 2024 at 12:34 AM wrote:
>
> From: Deepthi Hemraj
>
> For excessively long environment variables i.e >128KB
> Store the arguments in a temporary file and collect them back together in
> collect2.
>
> This commit patches for COLLECT_GCC_OPTIONS issue:
Thank you, Richard, for your feedback. I have removed the FILE_GCC_OPTION and
used COLLECT_GCC_OPTION exclusively to manage the long command line option. The
revised V2 patch has been posted and can be found at the following link:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661842
From: Deepthi Hemraj
For excessively long environment variables i.e >128KB
Store the arguments in a temporary file and collect them back together in
collect2.
This commit patches for COLLECT_GCC_OPTIONS issue:
GCC should not limit the length of command line passed to collect2.
ht
unted_by”)
__builtin_get_counted_by(__p->FAM) = COUNT, 0);
From the programmer’s point of view, it’s cleaner too.
However, there is one issue with “__builtin_choose_expr” currently in GCC, its
documentation explicitly mentions this limitation:
(https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins
> -Original Message-
> From: Gerald Pfeifer
> Sent: Thursday, August 29, 2024 3:20 AM
>
> On Wed, 28 Aug 2024, Haochen Jiang wrote:
> > Sorry for the disturb since I mis-typoed gcc-patches to gcc-patchs,
> > resend the patch.
>
> No worries.
>
>
On Wed, 28 Aug 2024, Haochen Jiang wrote:
> Sorry for the disturb since I mis-typoed gcc-patches to gcc-patchs,
> resend the patch.
No worries.
> This patch will add documentation for recent update in x86-64 backend.
Thank you!
> + Xeon Phi CPUs support (a.k.a. Knight Landing and
Pushed to wwwdocs.
---
htdocs/gcc-15/changes.html | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index d0d6d147..91c020dd 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Georgian team of translators. The file is available at:
https://translationproject.org/latest/gcc/ka.po
(This file, 'gcc-14.
Hi all,
Sorry for the disturb since I mis-typoed gcc-patches to gcc-patchs, resend
the patch.
This patch will add documentation for recent update in x86-64 backend.
Ok for wwwdocs trunk?
Thx,
Haochen
---
Mention AVX10.2 support and Xeon Phi removal in GCC 15.
---
htdocs/gcc-15/changes.html
;> for the testing cases, and then I narrowed down to a
> >>>>> small testing case that shows the problem without any change to GCC.
> >>>>>
> >>>>> [opc@qinzhao-ol8u3-x86 gcc]$ cat t1.c
> >>>>> struct annotated {
> &
on, Aug 26, 2024 at 07:30:15PM +, Qing Zhao wrote:
>>>>> Hi, Martin,
>>>>>
>>>>> Looks like that there is some issue when I tried to use the _Generic for
>>>>> the testing cases, and then I narrowed down to a
>>>>> small te
d to use the _Generic for
>>> the testing cases, and then I narrowed down to a
>>> small testing case that shows the problem without any change to GCC.
>>>
>>> [opc@qinzhao-ol8u3-x86 gcc]$ cat t1.c
>>> struct annotated {
>>> char b;
>>>
;> small testing case that shows the problem without any change to GCC.
>>
>> [opc@qinzhao-ol8u3-x86 gcc]$ cat t1.c
>> struct annotated {
>> char b;
>> int c[];
>> } *array_annotated;
>> extern void * counted_by_ref (int *);
>>
>&
like:
>
> #define alloc(PTR, COUNT, FAM, COUNTER)
>
> If the FAM doesn't have a 'counted_by' field:
>
> #define alloc(PTR, COUNT, FAM)
>
> (It would use VAR_ARGS of course). Why not simply have the compiler
> automatically adjust the return type?
What do you
On Tue, 27 Aug 2024, Dora, Sunil Kumar wrote:
> Dear GCC Team,
>
> Please consider this as a gentle reminder to review the patch I posted at the
> following link: [
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660223.html ].
>
> BUG Link : [ https:/
Dear GCC Team,
Please consider this as a gentle reminder to review the patch I posted at the
following link: [
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660223.html ].
BUG Link : [ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 ]
Your feedback or approval would be greatly
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This
Martin,
> > > >
> > > > Looks like that there is some issue when I tried to use the _Generic
> > > > for the testing cases, and then I narrowed down to a
> > > > small testing case that shows the problem without any change to GCC.
> > > >
when I tried to use the _Generic for
> > > the testing cases, and then I narrowed down to a
> > > small testing case that shows the problem without any change to GCC.
> > >
> > > [opc@qinzhao-ol8u3-x86 gcc]$ cat t1.c
> > > struct annotated {
> > >
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This
to a
> > small testing case that shows the problem without any change to GCC.
> >
> > [opc@qinzhao-ol8u3-x86 gcc]$ cat t1.c
> > struct annotated {
> > char b;
> > int c[];
> > } *array_annotated;
> > extern void * counted_by_ref (int *);
On Mon, Aug 26, 2024 at 07:30:15PM +, Qing Zhao wrote:
> Hi, Martin,
>
> Looks like that there is some issue when I tried to use the _Generic for the
> testing cases, and then I narrowed down to a
> small testing case that shows the problem without any change to GCC.
>
&g
Am Montag, dem 26.08.2024 um 19:30 + schrieb Qing Zhao:
> Hi, Martin,
>
> Looks like that there is some issue when I tried to use the _Generic for the
> testing cases, and then I narrowed down to a
> small testing case that shows the problem without any change to GCC.
>
&g
On Thu, Aug 22, 2024 at 8:03 AM Qing Zhao wrote:
> > On Aug 21, 2024, at 18:08, Bill Wendling wrote:
> >> For the unary operator __counted_by(PTR), “PTR” must have a counted_by
> >> attribute, if not, there will be a compilation time error.
> >>
> >> Then the user could write the following cod
On Wed, Aug 21, 2024 at 8:43 AM Martin Uecker wrote:
>
> Am Mittwoch, dem 21.08.2024 um 15:24 + schrieb Qing Zhao:
> > >
> > > But if we changed it to return a void pointer, we could make this
> > > a compile-time check:
> > >
> > > auto ret = __builtin_get_counted_by(__p->FAM);
> > >
> > > _
Hi, Martin,
Looks like that there is some issue when I tried to use the _Generic for the
testing cases, and then I narrowed down to a
small testing case that shows the problem without any change to GCC.
[opc@qinzhao-ol8u3-x86 gcc]$ cat t1.c
struct annotated {
char b;
int c
> Since this is a pure compile test it makes sense to inform dejagnu of
> it.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.misc-tests/gcov-23.c: Use dg-compile, not gcc -c
OK,
Honza
> ---
> gcc/testsuite/gcc.misc-tests/gcov-23.c | 3 ++-
> 1 file changed,
Ping.
On 8/15/24 10:15, Jørgen Kvalsvik wrote:
Ping. Since the last patch I have fixed a few bugs in the path count
limit aborting, and a few minor rephrases in docs.
Jørgen Kvalsvik (4):
testsuite: Use dg-compile, not gcc -c
gcov: Cache source files
gcov: branch, conds, calls in
> On Aug 21, 2024, at 18:08, Bill Wendling wrote:
>
>>>
>>> to test.
>>
>> For the unary operator __counted_by(PTR), “PTR” must have a counted_by
>> attribute, if not, there will be a compilation time error.
>>
>> Then the user could write the following code:
>>
>> If __builtin_has_att
> On Aug 21, 2024, at 17:54, Bill Wendling wrote:
>
>> if (__builtin_get_counted_by(p->array)) {
>>size_t max_value =
>> type_max(typeof(*__builtin_get_counted_by(p->array)));
>>if (count > type_max)
>>...fail cleanly...
>>*__builtin_get_counted_by(p->ar
Hi, Bill,
Thank you for the info.
> On Aug 21, 2024, at 17:36, Bill Wendling wrote:
>
>>
>> Bill, could you please provide a little bit more info on the possibility of
>> a new builtin __builtin_has_attribute() in CLANG?
>>
> From what I gathered, it would require some moderate surgery to
debugging/fixing the testsuite issue will be much easier.
> >
> > Does a int main(){} also segfault?
>
> I can run the LRA-enabled GCC normally, if you mean that:
>
> (unstable-sh4-sbuild)glaubitz@acrux:/srv/glaubitz/gcc/build$ ./prev-gcc/xgcc
> --version
> xgcc
segfault?
I can run the LRA-enabled GCC normally, if you mean that:
(unstable-sh4-sbuild)glaubitz@acrux:/srv/glaubitz/gcc/build$ ./prev-gcc/xgcc
--version
xgcc (GCC) 15.0.0 20240818 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for cop
On Thu, Aug 22, 2024 at 12:54 PM John Paul Adrian Glaubitz
wrote:
>
> Hi Richard,
>
> On Thu, 2024-08-22 at 12:49 +0200, Richard Biener wrote:
> > If this is stage2 or stage3 it hints at a miscompile of the stage2/3
> > compiler. I'd concentrate on other
> > issues first and suggest to use --disa
Hi Richard,
On Thu, 2024-08-22 at 12:49 +0200, Richard Biener wrote:
> If this is stage2 or stage3 it hints at a miscompile of the stage2/3
> compiler. I'd concentrate on other
> issues first and suggest to use --disable-bootstrap to see if that
> gets you to running the testsuite.
I have actual
1 - 100 of 1404 matches
Mail list logo
