On Tue, 27 Feb 2024, Tobias Burnus wrote:
> Minor update for older and more recent changes.
> supported for stack variables in C and Fortran, including the OpenMP 5.1
> - align modifier. For Fortran, OpenMP allocators can now be
> + align modifier. In C and C++, the map clause
> n
On e.g. gcc211 the use of "%li" with unsigned HOST_WIDE_INT led to this warning:
../../src/gcc/analyzer/access-diagram.cc: In member function ‘void
ana::string_literal_spatial_item::add_column_for_byte(text_art::table&, const
ana::bit_to_table_map&, text_art::style_manager&, ana::byte_offset_t,
On 2/27/24 6:40 AM, Segher Boessenkool wrote:
> On Tue, Feb 27, 2024 at 02:02:38AM +0530, jeevitha wrote:
>> There is no immediate value splatting instruction in Power. Currently, those
>> values need to be stored in a register or memory. To address this issue, I
>> have updated the predicate for t
>> I don't think it's that simple. On some uarchs vsetvls are nearly free
>>while on others they can be fairly expensive. It's not clear (to me)
>>yet if one approach or the other is going to be the more common.
That's uarch dependent which is not the stuff I am talking about.
What's I want to s
On 2/27/24 15:56, 钟居哲 wrote:
>> I don't think it's that simple. On some uarchs vsetvls are nearly free
while on others they can be fairly expensive. It's not clear (to me)
yet if one approach or the other is going to be the more common.
That's uarch dependent which is not the stuff I am
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641247.html
There was a request on the PR
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755#c5) for me to ping
this again, so I am complying :). Might anyone have a minute to take a
look please? Thanks...
-Lewis
On Thu, Jan 11,
On Tue, 27 Feb 2024 15:53:19 PST (-0800), jeffreya...@gmail.com wrote:
On 2/27/24 15:56, 钟居哲 wrote:
>> I don't think it's that simple. On some uarchs vsetvls are nearly free
while on others they can be fairly expensive. It's not clear (to me)
yet if one approach or the other is going to be
All,
Consider,
! { dg-do run }
program foo
implicit none
real y
associate (x => log(cmplx(-1,0)))
y = x%im
if (int(100*y)-314 /= 0) stop 1
end associate
end program
% gfcx -c a.f90
a.f90:6:13:
6 | y = x%im
| 1
Error: Symbol 'x' at (1) has no I
On Tue, Feb 27, 2024 at 1:18 PM Evgeny Karpov
wrote:
>
> SEH is not implemented yet and needs to be disabled in mingw/winnt.cc.
> Disabling every SEH function that uses references to these macros might
> trigger significant refactoring, and to avoid this, required macros are
> defined with 0. I
Add proper hints for implicit declaration of strerror.
The results could be confusing depending on the other included headers.
These example messages are from compiling a trivial program to print the
string for an errno value. It only includes stdio.h (cstdio for C++).
Before:
$ /tmp/gcc-master/b
> Pan, can you confirm what path we take through extract_low_bits?
Thanks Jeff for comments, will have a try soon and keep you posted.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, February 27, 2024 11:03 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.c
> -Original Message-
> Friday, February 23, 2024 6:16 PM
> Richard Sandiford wrote:
>
> > +
> > +#undef TARGET_SEH
> > +#define TARGET_SEH 0
> > +
> > +#define SSE_REGNO_P(N) 0
> > +#define GENERAL_REGNO_P(N) 0
>
> Could you add a comment to explain how these two macros are consumed?
> What
On 2/27/24 1:00 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes invalid Fortran in testcase
gfortran.dg/pr101026.f, which might prohibit progress
in fixing pr111781. (Note that the testcase was for a
tree-optimizer issue, not the Fortran frontend.)
OK for mainline?
Will commit wit
On Tue, Feb 27, 2024 at 11:59:46AM -0500, Patrick Palka wrote:
> On Fri, 16 Feb 2024, Nathaniel Shead wrote:
>
> > On Tue, Feb 13, 2024 at 07:52:01PM -0500, Jason Merrill wrote:
> > > On 2/10/24 17:57, Nathaniel Shead wrote:
> > > > The fix for PR107398 weakened the restrictions that lambdas must
From: Pan Li
This patch would like to introduce one new gcc option for RVV. To
appoint the bits size of one RVV vector register. Valid arguments to
'-mrvv-vector-bits=' are:
* zvl
The zvl will pick up the zvl*b from the march option. For example,
the mrvv-vector-bits will be 1024 when march=rv6
> if (!targetm.modes_tieable_p (src_int_mode, src_mode))
> return NULL_RTX;
> if (!targetm.modes_tieable_p (int_mode, mode))
> return NULL_RTX;
Yes, will return NULL_RTX for in the first if, given src_int_mode is E_DImode
while src_mode is
E_V2SFmode and mode is E_V4QImode. The extra
Keep SCALABLE, since it has different semantics with ZVL:
-mrvv-vector-bits=scalble means zvl*b specify the minimal VLEN
-mrvv-vector-bits=zvl means zvl*b specify the exactly VLEN
What's difference exactly?
-mrvv-vector-bits=scalble with zvl128b can run on any machine with VLEN >= 128
-mrvv-vect
Harald,
Jerry helped me figure out my editor settings so that I could fix
whitespace and formatting issues in my code. With my editor configured
correctly, I saw that my code was not conforming to coding standards
as I previously thought it was. I have fixed those things and updated
my patch. Than
Oh, I see, that indicates simply convert this option value to
riscv_vector_chunks is not good enough here.
I thought the term zvl* indicates the minimal vector length(somehow similar to
the concept of scalable)
in previous, which is mentioned in the RVV 1.0 spec if my memory is correct.
Looks m
On Tue, Feb 27, 2024 at 10:20 PM Robert Dubner wrote:
>
> Richard,
>
> Thank you very much for your comments.
>
> When I set out to create the capability, I had a "specification" in mind.
>
> I didn't have a clue how to create a GENERIC tree that could be fed to the
> middle end in a way that woul
Hi!
The following patch changes the memcpy etc. folding to use bitwise vector
types rather than huge INTEGER_TYPEs for copying of > MAX_FIXED_MODE_SIZE
lengths. The problem with the huge INTEGER_TYPEs is that they aren't
supported very much, usually there are just optabs to handle moves of them,
101 - 121 of 121 matches
Mail list logo
