On Thu, Jan 30, 2025 at 8:49 PM Alexandre Oliva wrote:
>
>
> The test expects transformations that depend on -Ofast on x86*, but
> that option is only passed when the avx_runtime is available.
>
> Split -Ofast out of the avx conditional, so that it is passed on the
> same targets that expect the t
On Fri, Jan 31, 2025 at 3:55 AM Michael Meissner wrote:
>
> Fix PR 118541, do not generate unordered fp cmoves for IEEE compares.
>
> In bug PR target/118541 on power9, power10, and power11 systems, for the
> function:
>
> extern double __ieee754_acos (double);
>
> double
>
pr113689 testcases use -fprofile without testing for profiling
support. Fix them.
Regstrapped on x86_64-linux-gnu, also tested with gcc-14 targeting
x86_64-elf. Ok to install?
for gcc/testsuite/ChangeLog
PR target/113689
* gcc.target/i386/pr113689-1.c: Require profiling sup
The test expects transformations that depend on -Ofast on x86*, but
that option is only passed when the avx_runtime is available.
Split -Ofast out of the avx conditional, so that it is passed on the
same targets that expect the transformation.
Regstrapped on x86_64-linux-gnu, also tested with g
On Thu, Jan 30, 2025 at 04:46:49PM -0300, Alexandre Oliva wrote:
>
> The test expects transformations that depend on -Ofast on x86*, but
> that option is only passed when the avx_runtime is available.
>
> Split -Ofast out of the avx conditional, so that it is passed on the
> same targets that exp
On 1/29/25 10:30 AM, Jerry D wrote:
Follow-up:
On 1/28/25 1:33 PM, Harald Anlauf wrote:
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang
disagree with it.
--- snip ---
The following adjustment to the patc
Hi, Bill,
Sorry for the late reply (just be back from a short vacation).
> On Jan 23, 2025, at 17:44, Bill Wendling wrote:
>
> On Fri, Jan 17, 2025 at 8:20 AM Qing Zhao wrote:
>>
>> Hi, Bill,
>>
>> Thanks a lot for your testing case.
>>
>> I studied this testing case and realized that we ne
Fix PR 118541, do not generate unordered fp cmoves for IEEE compares.
In bug PR target/118541 on power9, power10, and power11 systems, for the
function:
extern double __ieee754_acos (double);
double
__acospi (double x)
{
double ret = __ieee754_acos (x) /
This patch from pgerell at GitHub adds some casts to libbacktrace to
avoid undefined shifts. These shifts are OK on all real systems but
may as well get it right. Bootstrapped and ran libbacktrace tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
libbacktrace: add casts to avoid undefined
On 12/7/24 5:34 AM, Jakub Jelinek wrote:
Hi!
On the pr117516.C testcase check_flexarrays and its helper functions
have exponential complexity, plus it reports the same bug over and over
again in some cases instead of reporting perhaps other bugs.
The functions want to diagnose flexible array mem
Dear all,
analyzing the the PR (by Gerhard) turned out to two slightly related
issues. The first one, where a variable in a COMMON block is falsely
resolved to a derived type declared in the host, leads to a false
freeing of the symbol, resulting in memory corruption and ICE.
If we already know
On 1/29/25 3:49 PM, Patrick Palka wrote:
Built on x86_64-pc-linux-gnu, does this look OK for trunk?
OK.
-- >8 --
This unused accessor is just a simple alias of LAMBDA_EXPR_THIS_CAPTURE
and contrary to the documentation doesn't actually use TREE_LANG_FLAG_0.
Might as well remove it.
gcc/cp/C
On 1/30/25 3:19 AM, Iain Sandoe wrote:
Fixes a regression in handling Objective-C++ strings.
Tested on x86_64-darwin21, OK for trunk?
OK.
thanks
Iain
--- 8< ---
Objective-C++ uses CONST_DECLs to hold constant string objects
these should also be treated as mergable lvalues.
PR c++/1
On 1/21/25 8:48 AM, Thomas Schwinge wrote:
Hi!
On 2025-01-16T15:57:52+0100, I wrote:
I have noticed that '-fdump-tree-original-lineno' for Fortran (for
example) does dump location information, but for C/C++ it does not.
The reason is that Fortran (and other front ends) use code like:
/* O
Hi!
The following testcase is miscompiled on s390x-linux with e.g. -march=z13
(both -O0 and -O2) starting with r15-7053.
The problem is in the splitters which emulate TImode/V1TImode GT and GTU
comparisons.
For GT we want to do
(ior (gt (hi op1) (hi op2))
(and (eq (hi op1) (hi op2)) (gtu (lo
This documents some constraints on TYPE_ADDR_SPACE in tcc_reference
trees.
Documentation around types seems to be mostly non-existient ... but
since I opened this bug I might as well try to fix it (minimally).
OK?
PR middle-end/113762
* generic.texi (Types): Document TYPE_ADDR_SP
On Thu, 2025-01-30 at 12:01 +, Bader, Lucas wrote:
> Thanks a lot for your detailed feedback!
> I will rework my patch, especially to make the
> get_source_line_preprocessed function
> more readable and more efficient.
>
> Some comments in the mean time:
>
> > This may sound silly, but please
Thanks a lot for your detailed feedback!
I will rework my patch, especially to make the get_source_line_preprocessed
function
more readable and more efficient.
Some comments in the mean time:
> This may sound silly, but please use "num" rather than "no" as an
> abbreviation for "number": to my u
On Thu, 30 Jan 2025, Jakub Jelinek wrote:
> On Thu, Jan 30, 2025 at 11:34:16AM +0100, Richard Biener wrote:
> > When MEM_REF expansion of a non-MEM falls back to a stack temporary
> > we fail to handle the case where the offset adjusted reference to
> > the temporary is not aligned according to th
For easier review, I broke that patch into two parts:
One for the strlen built-ins, and one to handle built-ins
that are only available in C.
Delta is the same.
Johann
Am 30.01.25 um 11:42 schrieb Georg-Johann Lay:
AVR: Provide built-ins for strlen where the string lives in some AS.
This pa
The std::latch::max() function assumes that the returned value can be
represented by ptrdiff_t, which is true when __platform_wait_t is int
(e.g. on Linux) but not when it's unsigned long, which is the case for
most other 64-bit targets. We should use the smaller of PTRDIFF_MAX and
std::numeric_lim
On Thu, Jan 30, 2025 at 05:11:54PM +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled on s390x-linux with e.g. -march=z13
> (both -O0 and -O2) starting with r15-7053.
> The problem is in the splitters which emulate TImode/V1TImode GT and GTU
> comparisons.
> For GT we want
On Wed, 2024-08-21 at 16:05 -0400, Jason Merrill wrote:
> On 8/21/24 3:34 PM, Arsen Arsenović wrote:
> > Jason Merrill writes:
> >
> > > On 8/21/24 1:52 PM, Arsen Arsenović wrote:
> > > > For clarity, here's the entire split-up patch I intend to push,
> > > > if it
> > > > looks OK. Tested on x8
On Wed, Jan 29, 2025 at 08:03:37AM -0500, Jason Merrill wrote:
> On 1/27/25 6:19 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
> >
> > -- >8 --
> > We've had a wrong-code problem since r14-4140, due to which we
> > forget to initialize a variable.
> >
On 1/30/25 12:45 PM, Alexandre Oliva wrote:
pr113689 testcases use -fprofile without testing for profiling
support. Fix them.
Regstrapped on x86_64-linux-gnu, also tested with gcc-14 targeting
x86_64-elf. Ok to install?
for gcc/testsuite/ChangeLog
PR target/113689
* gcc
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
This PR describes a few issues, both ICE and rejects-valid, but
ultimately the problem is that we don't properly synthesize the
second auto in:
int
g (auto fp() -> auto)
{
return fp ();
}
since r12-5860, which d
Fixes a regression in handling Objective-C++ strings.
Tested on x86_64-darwin21, OK for trunk?
thanks
Iain
--- 8< ---
Objective-C++ uses CONST_DECLs to hold constant string objects
these should also be treated as mergable lvalues.
PR c++/118673
gcc/cp/ChangeLog:
* tree.cc (lva
Hi Sandra,
Sandra Loosemore wrote:
* Unless it is quickly fixable, we agreed on deferring the bogus message
"Error: ‘target’ construct with nested ‘teams’ construct contains
directives
outside of the ‘teams’ construct"
to a new PR. That's for:
OpenMP_VV's
tests/5.0/metadirect
When MEM_REF expansion of a non-MEM falls back to a stack temporary
we fail to handle the case where the offset adjusted reference to
the temporary is not aligned according to the requirement of the
mode. We have to go through bitfield extraction or movmisalign
in this case. Fortunately there's a
AVR: Provide built-ins for strlen where the string lives in some AS.
This patch adds built-in functions __builtin_avr_strlen_flash,
__builtin_avr_strlen_flashx and __builtin_avr_strlen_memx.
Purpose is that higher-level functions can use __builtin_constant_p
on strlen without raising a diagnostic
On Thu, Jan 30, 2025 at 11:34:16AM +0100, Richard Biener wrote:
> When MEM_REF expansion of a non-MEM falls back to a stack temporary
> we fail to handle the case where the offset adjusted reference to
> the temporary is not aligned according to the requirement of the
> mode. We have to go through
31 matches
Mail list logo
