https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #24 from Kewen Lin ---
(In reply to Richard Biener from comment #22)
> I see the mems properly get their base adjusted:
>
> (insn 384 383 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars)
> (const_int 16
Here's a refreshed and retested version of the patch for hardened
booleans in C. It is unchanged aside from some conflict resolution,
compared with the previous version posted back in June.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622668.html
Regstrapped on x86_64-linux-gnu and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50856
--- Comment #4 from Andrew Pinski ---
Here is a full testcase (f3 is caught via fold_cond_expr_with_comparison):
```
int f(int a, int b)
{
int t = a - b;
if (t > 0) return t;
return b - a;
}
int f1(int a, int b)
{
if (a > b) return a -
On Mon, Jul 12, 2021 at 4:47 AM Richard Biener via Gcc-patches
wrote:
>
> On Sun, Jul 11, 2021 at 4:12 AM apinski--- via Gcc-patches
> wrote:
> >
> > From: Andrew Pinski
> >
> > This patch moves the (a-b) CMP 0 ? (a-b) : (b-a) optimization
> > from fold_cond_expr_with_comparison to match.
>
>
> >
> > Based on what you've said, I assume that OFFSET_REF handles static
> > member functions that are overloaded. But as I've said this seems to
> > contradict the comments I'm reading, so I'm not sure that I'm
> > understanding you correctly.
>
>
> That's right. For instance,
>
> struct A
On Oct 19, 2023, Thomas Schwinge wrote:
> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
>> I guess I can ask, why there is not a recursive approach for configuring
>> GCC. e.g. AC_SUBDIRS in the top level?
> ('AC_CONFIG_SUBDIRS' you mean.) You know, often it just takes
On Oct 19, 2023, Thomas Schwinge wrote:
> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
>> I guess I can ask, why there is not a recursive approach for configuring
>> GCC. e.g. AC_SUBDIRS in the top level?
> ('AC_CONFIG_SUBDIRS' you mean.) You know, often it just takes
Committed after the commited of the vsetvl pass refactor patch, thanks
Robin.
On 2023/10/19 16:43, Robin Dapp wrote:
Hi Juzhe,
as discussed off-list this approach generally makes sense to me so
the patch LGTM once the vsetvl rework is upstream and settled.
Independently, we still need to
Committed, thanks Patrick and Juzhe.
On 2023/10/20 2:04, Patrick O'Neill wrote:
I tested it this morning on my machine and it passed!
Tested against:
04d6c74564b7eb51660a00b35353aeab706b5a50
Using targets:
glibc rv32gcv qemu
glibc rv64gcv qemu
This patch series does not introduce any new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111725
--- Comment #1 from CVS Commits ---
The trunk branch has been updated by Lehua Ding :
https://gcc.gnu.org/g:29331e72d0ce9fe8aabdeb8c320b99943b9e067a
commit r14-4773-g29331e72d0ce9fe8aabdeb8c320b99943b9e067a
Author: Lehua Ding
Date: Fri Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Lehua Ding :
https://gcc.gnu.org/g:29331e72d0ce9fe8aabdeb8c320b99943b9e067a
commit r14-4773-g29331e72d0ce9fe8aabdeb8c320b99943b9e067a
Author: Lehua Ding
Date: Fri Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111848
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Lehua Ding :
https://gcc.gnu.org/g:f0e28d8c13713f509fde26fbe7dd13280b67fb87
commit r14-4774-gf0e28d8c13713f509fde26fbe7dd13280b67fb87
Author: Juzhe-Zhong
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Lehua Ding :
https://gcc.gnu.org/g:29331e72d0ce9fe8aabdeb8c320b99943b9e067a
commit r14-4773-g29331e72d0ce9fe8aabdeb8c320b99943b9e067a
Author: Lehua Ding
Date: Fri Oct
Hi Richard,
I'm hitting a couple of testcase ICEs for RISC-V while testing with the
latest trunk code, it looks like these two patches are causing it, can
you help me look at it? ICE log like bellow:
➜ vsetvl git:(tintin-dev)
On Oct 19, 2023, Richard Biener wrote:
> OK. Maybe time to do s/make_eh_edges/make_eh_edge/ though.
Thanks, will do, ideally on top of the already-tested refreshed patches
that I'm going to post shortly.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111888
Bug ID: 111888
Summary: RISC-V: Horrible redundant number vsetvl instructions
in vectorized codes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101631
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:1d260ab0e39ea63644e3af3ab2e0db946026b5a6
commit r14-4771-g1d260ab0e39ea63644e3af3ab2e0db946026b5a6
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:1d260ab0e39ea63644e3af3ab2e0db946026b5a6
commit r14-4771-g1d260ab0e39ea63644e3af3ab2e0db946026b5a6
Author: Nathaniel Shead
Date:
On 10/11/23 11:41, Marek Polacek wrote:
On Wed, Oct 11, 2023 at 10:57:06AM +1100, Nathaniel Shead wrote:
On Mon, Oct 09, 2023 at 04:10:20PM -0400, Jason Merrill wrote:
On 10/9/23 06:03, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu with
On 10/12/23 18:05, Nathaniel Shead wrote:
On Thu, Oct 12, 2023 at 04:24:00PM -0400, Jason Merrill wrote:
On 10/12/23 04:53, Nathaniel Shead wrote:
On Wed, Oct 11, 2023 at 12:48:12AM +1100, Nathaniel Shead wrote:
On Mon, Oct 09, 2023 at 04:46:46PM -0400, Jason Merrill wrote:
On 10/8/23 21:03,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111887
--- Comment #2 from wierton <141242068 at smail dot nju.edu.cn> ---
Thanks for you reply, I got it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111887
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
On Mar 10, 2021, Alexandre Oliva wrote:
> ppc configurations that have -mstrict-align enabled by default fail
> gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into
> MEM_REFs, which defeats the tested-for strlen optimization.
I've combined this patch with other patches that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111887
Bug ID: 111887
Summary: GCC: 14: A potential miscompilation with __builtin_inf
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101195
Andrew Pinski changed:
What|Removed |Added
CC||141242068 at smail dot
nju.edu.cn
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111886
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111886
Bug ID: 111886
Summary: GCC: 14: internal compiler error: in tree_to_uhwi, at
tree.cc:6467
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
On 10/19/23 19:35, waffl3x wrote:
(waffl3x (me))
At a glance it seems like all I need to do then is disable the
PTRMEM_OK_P flag then.
I'm just now realizing that I'm almost certainly wrong about this. It
still needs PTRMEM_OK_P set if there are any implicit-object member
functions in the
>So with pow being available this limit shouldn't be necessary any more and
>the testcase adjustment can be avoided?
I tries, compile time still hogs on mpz_powm(3, INT_MAX), so i'll just
keep this.
>and to avoid undefined behavior with too large shift just go the gmp
>way unconditionally.
Hi Patrick,
Thanks a lot for helping to test these patchs!
On 2023/10/20 2:04, Patrick O'Neill wrote:
I tested it this morning on my machine and it passed!
Tested against:
04d6c74564b7eb51660a00b35353aeab706b5a50
Using targets:
glibc rv32gcv qemu
glibc rv64gcv qemu
This patch series does
On Tue, 3 Oct 2023, David Malcolm wrote:
> As mentioned in my Cauldron talk, this patch adds a call to
> diagnostic_show_locus to the "required from here" messages
> in print_instantiation_partial_context_line, so that e.g., rather
> than the rather mystifying:
>
> In file included from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111885
Patrick Palka changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50856
--- Comment #3 from Andrew Pinski ---
The second case will be solved by updating the patch at:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574892.html
For the review at
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574948.html
> (waffl3x (me))
> At a glance it seems like all I need to do then is disable the
> PTRMEM_OK_P flag then.
I'm just now realizing that I'm almost certainly wrong about this. It
still needs PTRMEM_OK_P set if there are any implicit-object member
functions in the overload set. That is, if
On Wed, Oct 18, 2023 at 09:11:43PM +, Qing Zhao wrote:
> As I replied to Martin in another email, I plan to do the following to
> resolve this issue:
>
> 1. No specification for signed or unsigned for counted_by field.
> 2. Add a sanitizer option -fsanitize=counted-by-bound to catch the
On Thu, Oct 19, 2023 at 5:08 PM Florian Weimer wrote:
>
> The existing -Wreturn-type option covers both constraint violations
> (which are mandatory to diagnose) and warnings that have known
> false positives. The new -Wreturn-mismatch warning is only about
> the constraint violations (missing
On Thu, Oct 19, 2023 at 08:49:00PM +, Qing Zhao wrote:
> > On Sep 25, 2023, at 2:24 PM, Tobias Burnus wrote:
> > Secondly, if this is deprecated, shouldn't then the warning enabled by,
> > e.g., -Wall or made
> > otherwise more prominent? (-std=?) - Currently, one either has to find the
> >
On Thu, Oct 19, 2023 at 6:43 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2023-10-19T11:57:33+0200, Andreas Schwab wrote:
> > On Okt 19 2023, Thomas Schwinge wrote:
> >> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
> >>> I guess I can ask, why there is not a recursive approach
On Thu, Oct 19, 2023 at 6:43 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2023-10-19T11:57:33+0200, Andreas Schwab wrote:
> > On Okt 19 2023, Thomas Schwinge wrote:
> >> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
> >>> I guess I can ask, why there is not a recursive approach
On Thu, Oct 19, 2023 at 7:52 AM Martin Uecker wrote:
>
>
>
> Note that the C++ warning is for jumping over a declaration,
> which is generally allowed in C but not in C++.
>
> Martin
(Also note that in C, there's -Wjump-misses-init for this, which is
enabled by -Wc++-compat, which isn't enabled
> A BASELINK expresses the result of name lookup for a member function,
> since we need to pass information about the name lookup context along to
> after overload resolution.
>
> An OFFSET_REF (with PTRMEM_OK_P) is used to express that we saw the
> ::f syntax, so we could build a pointer to
Snapshot gcc-11-20231019 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20231019/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 79021, which changed state.
Bug 79021 Summary: attribute noreturn on function template ignored in generic
lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79021
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79021
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79021
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108238
--- Comment #4 from Andrew Pinski ---
Here is one which is a little more complex for templated function too:
```
template
[[gnu::returns_nonnull]]
auto f() {
return new T(42);
}
auto g(void)
{
return f();
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
"juzhe.zh...@rivai.ai" writes:
> Hi, this patch fix V4 issue:
>
> Previously as Richard S commented:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633178.html
>
> slp_op and mask_vectype are only initialised when mask_index >= 0.
> Shouldn't this code be under mask_index >= 0 too?
>
On 10/19/23 17:05, waffl3x wrote:
Also, I'm not sure what %qs is, should I be using that instead of %s
for strings?
The q prefix means quoted, with ' or other quotation marks, depending on
the locale.
On another topic, I have been trying to fix taking pointers to explicit
object member
"Kewen.Lin" writes:
> Hi,
>
> As comments[1][2], this patch is to change the costing way
> on some adjacent vector loads/stores from costing one by
> one to costing them together with the total number once.
>
> It helps to fix the exposed regression PR111784 on aarch64,
> as aarch64 specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
--- Comment #5 from Iain Sandoe ---
for the record an __fp16 implementation works as expected;
* when the target does not support +fp16, the code-gen promotes to float and
does the multiply with __mulsc3
* when the target supports +fp16, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108238
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Andrew
Hi Richard,
> On 19 Oct 2023, at 22:49, Richard Sandiford wrote:
> Iain Sandoe writes:
>> I am being bitten by a problem that falls out from the code that emits
>>
>> .arch Armv8.n-a+crc
>>
>> when the arch is less than Armv8-r.
>> The code that does this, in gcc/common/config/aarch64
On Thu, Oct 19, 2023 at 09:31:06PM +, waffl3x wrote:
> Ah alright, I see what you're saying, I see what the difference is now.
> It's a shame we can't have the translated string insert a %s and format
> into that :^). Ah well, I guess this code is just doomed to look poor
> then, what can you
Iain Sandoe writes:
> Hi Richard,
>
>
> I am being bitten by a problem that falls out from the code that emits
>
> .arch Armv8.n-a+crc
>
> when the arch is less than Armv8-r.
> The code that does this, in gcc/common/config/aarch64 is quite recent
> (2022-09).
Heh. A workaround for one
On 9/25/23 16:43, Patrick Palka wrote:
This much more mechanical patch removes build_non_dependent_expr
(and make_args_non_dependent) and adjusts callers accordingly,
no functional change.
These two patches are OK either separately or squashed, whichever you
prefer.
gcc/cp/ChangeLog:
On 10/4/23 15:23, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
After the previous patch, we currently have two tsubst entry points
for expression trees: tsubst_copy_and_build and tsubst_expr. But the
latter is just a
On 10/4/23 12:08, Patrick Palka wrote:
On Tue, 3 Oct 2023, Jason Merrill wrote:
On 10/3/23 08:41, Patrick Palka wrote:
On Mon, 2 Oct 2023, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The relationship between
On Thu, 19 Oct 2023, Florian Weimer wrote:
> diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
> index 6e044b4afbc..1da622160a3 100644
> --- a/gcc/c/c-typeck.cc
> +++ b/gcc/c/c-typeck.cc
> @@ -11281,17 +11281,10 @@ c_finish_return (location_t loc, tree retval, tree
> origtype)
>if
> No, that wouldn't be appropriate for translation.
> None of non-member, static member and explicit object member are
> something that should be printed verbatim untranslated.
> "%s function %qD cannot have cv-qualifier", _("non-member")
> etc. is still inappropriate, some language might need to
Tamar Christina writes:
> Hi All,
>
> This adds an implementation for masked copysign along with an optimized
> pattern for masked copysign (x, -1).
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> PR
Tamar Christina writes:
> Hi All,
>
> copysign (x, -1) is effectively fneg (abs (x)) which on AArch64 can be
> most efficiently done by doing an OR of the signbit.
>
> The middle-end will optimize fneg (abs (x)) now to copysign as the
> canonical form and so this optimizes the expansion.
>
> If
On Thu, Oct 19, 2023 at 09:05:38PM +, waffl3x wrote:
> Okay so taking what you guys are saying here it sounds like it would be
> appropriate to refactor the code I was reluctant to refactor. The code
> (in grokfndecl) conditionally selects one of the two (now three with my
> changes) following
The existing -Wreturn-type option covers both constraint violations
(which are mandatory to diagnose) and warnings that have known
false positives. The new -Wreturn-mismatch warning is only about
the constraint violations (missing or extra return expressions),
and should eventually be turned into
> (Jakub)
> There are different kinds of format strings in GCC, the most common
> are the gcc-internal-format strings. If you call a function which
> is expected to take such translatable format string (in particular
> a function which takes a gmsgid named argument like error, error_at,
> pedwarn,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111885
Bug ID: 111885
Summary: source code after "required from here" note sometimes
printed strangely
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
--- Comment #4 from Tom Honermann ---
(In reply to Marek Polacek from comment #3)
> Thanks, I can test
Thank you. That change looks right. My apologies for introducing the
regression.
Hi, Tobias,
Sorry for the late reply (just came back from a long vacation after Cauldron).
And thank you for reporting this issue.
Please see my reply embedded below:
> On Sep 25, 2023, at 2:24 PM, Tobias Burnus wrote:
>
> Hi all,
>
> I stumbled over this as I found the wording in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111883
--- Comment #3 from Marek Polacek ---
Did you mean like the following? I have no idea if that's correct but is
suppresses the warnings I see.
In C++23 I don't see the code in the .ii file at all, so it doesn't warn.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
Andrew Pinski changed:
What|Removed |Added
Summary|unsigned char no longer |[13/14 Regression] unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111883
--- Comment #2 from Jakub Jelinek ---
Why doesn't it fail with -std=c++23 though? Was there some C++26 change I'm
not aware of?
In the to_chars cases, we already use float(__value) casts in the
_Float16/__bfloat16_t cases (but others too), so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
--- Comment #2 from joseph at codesourcery dot com ---
I'm going to guess this was introduced by the char8_t changes ("C:
Implement C2X N2653 char8_t and UTF-8 string literal changes", commit
703837b2cc8ac03c53ac7cc0fb1327055acaebd2).
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
Sam James changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
I noticed that Patrick is missing here.
gcc/ChangeLog:
* doc/contrib.texi: Add entry for Patrick Palka.
---
gcc/doc/contrib.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/doc/contrib.texi b/gcc/doc/contrib.texi
index 031c4ec44ce..0fe4a874616 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111883
--- Comment #1 from Jonathan Wakely ---
I think Jakub wrote that code, but it looks like we just want the explicit
casts. I can add those.
On 10/19/23 14:45, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 01:02:33PM -0400, Jason Merrill wrote:
On 10/19/23 12:55, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 12:32:49PM -0400, Jason Merrill wrote:
On 10/19/23 10:14, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 10:06:01AM -0400,
Ugh, I didn't push yet because with a rebased trunk I am
seeing different behavior for some riscv testcases.
A reduction is not recognized because there is yet another
"double use" occurrence in check_reduction_path. I guess it's
reasonable to loosen the restriction for conditional operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
Bug ID: 111884
Summary: unsigned char no longer aliases anything under
-std=c2x
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Keywords: wrong-code
I noticed that we only tagged half of the 5.0 deprecations in the omp_lib
module;
this added the other half. (omp_lock_hint_* was renamed to omp_sync_hint_*.)
Currently, this patch has has no visible effect - but once we bump the OpenMP
version
from 4.5 to 5.0, there will warnings of the
Manolis Tsamis writes:
> Currently the operations allowed for if conversion of a basic block with
> multiple sets are few, namely REG, SUBREG and CONST_INT (as controlled by
> bb_ok_for_noce_convert_multiple_sets).
>
> This commit allows more operations (arithmetic, compare, etc) to participate
>
Manolis Tsamis writes:
> This is an extension of what was done in PR106590.
>
> Currently if a sequence generated in noce_convert_multiple_sets clobbers the
> condition rtx (cc_cmp or rev_cc_cmp) then only seq1 is used afterwards
> (sequences that emit the comparison itself). Since this applies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645
Carl Love changed:
What|Removed |Added
CC||carll at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
Andrew Pinski changed:
What|Removed |Added
Target|aarch64 |aarch64 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
--- Comment #3 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This could either be wrong code for not doing the promotion or just missing
> > the libgcc functions (which could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
--- Comment #2 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #1)
> This could either be wrong code for not doing the promotion or just missing
> the libgcc functions (which could be implemented as doing the promotion).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111878
Andrew Pinski changed:
What|Removed |Added
Summary|[14 Regression] ICE: in |[14 Regression] ICE: in
On Thu, Oct 19, 2023 at 01:02:33PM -0400, Jason Merrill wrote:
> On 10/19/23 12:55, Marek Polacek wrote:
> > On Thu, Oct 19, 2023 at 12:32:49PM -0400, Jason Merrill wrote:
> > > On 10/19/23 10:14, Marek Polacek wrote:
> > > > On Thu, Oct 19, 2023 at 10:06:01AM -0400, Jason Merrill wrote:
> > > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111878
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111873
Andrew Pinski changed:
What|Removed |Added
Summary|runtime Segmentation fault |[12/13/14 Regression]
On Thu, Oct 19, 2023 at 01:33:51PM +0100, Sam James wrote:
>
> Richard Biener writes:
>
> > On Wed, Oct 11, 2023 at 10:48 PM Marek Polacek wrote:
> >>
> >> On Tue, Sep 19, 2023 at 10:58:19AM -0400, Marek Polacek wrote:
> >> > On Mon, Sep 18, 2023 at 08:57:39AM +0200, Richard Biener wrote:
> >>
On Wed, Oct 18, 2023 at 08:12:37PM +, Qing Zhao wrote:
> Marek,
>
> Sorry for the late comment (I was just back from a long vacation immediate
> after Cauldron).
No worries.
> One question:
>
> Is the option “-fhandened” for production build or for development build?
I intend
I tested it this morning on my machine and it passed!
Tested against:
04d6c74564b7eb51660a00b35353aeab706b5a50
Using targets:
glibc rv32gcv qemu
glibc rv64gcv qemu
This patch series does not introduce any new failures.
Here's a list of *resolved* failures by this patch series:
rv64gcv:
FAIL:
Hi Jeff,
On 19/10/2023 08:54, Jeff Law wrote:
>
>
> On 10/17/23 14:48, Alex Coplan wrote:
> > haifa-sched.cc:remove_notes asserts that it lands on a real (non-note)
> > insn after advancing past NOTE_INSN_EPILOGUE_BEG, but with the upcoming
> > post-RA aarch64 load pair pass enabled, we can
On Thu, 2023-10-19 at 16:13 +0200, Andreas Schwab wrote:
> On Okt 19 2023, David Malcolm wrote:
[...]
> > + /* First, check for a null-terminated string *without*
> > + emitting emitting warnings (via a null context), to
>
> -emitting
>
Thanks; I've fixed this in my working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111883
Bug ID: 111883
Summary: Wstringop-overflow-6.C FAILs with -std=c++26
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880
--- Comment #3 from Steve Kargl ---
On Thu, Oct 19, 2023 at 05:20:46PM +, zed.three at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880
>
> --- Comment #2 from zed.three at gmail dot com ---
> The common block is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110485
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:8b704ed0b8f35ec1a57e70bd8e6913ba0e9d1f24
commit r14-4765-g8b704ed0b8f35ec1a57e70bd8e6913ba0e9d1f24
Author: Andre Vieira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880
--- Comment #2 from zed.three at gmail dot com ---
The common block is in 'third_party_module', rather than 'foo', unless you mean
that it is visible from 'foo'? It is still a surprising warning in this
location at any rate!
1 - 100 of 299 matches
Mail list logo
