On 11/24/23 03:18, Tsukasa OI wrote:
From: Tsukasa OI
Along with RV32E, RV64E is ratified. Though ILP32E and LP64E ABIs are
still draft, it's worth supporting it.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_ext_version_table): Set version to ratified 2.0.
On 11/23/23 10:06, Hans-Peter Nilsson wrote:
Anyone using contrib/regression/btest-gcc.sh besides me?
It has, besides a copyright update, not seen love and attention in a
decade. Also, the original author and maintainer hasn't been visibly
active with gcc. I've contributed the other
On 11/20/23 11:56, Dimitar Dimitrov wrote:
On Sun, Nov 19, 2023 at 05:47:56PM -0700, Jeff Law wrote:
...
+/* Process uses in INSN. Set appropriate bits in LIVENOW for any chunks of
+ pseudos that become live, potentially filtering using bits from LIVE_TMP.
+
+ If MODIFIED is true
On 11/21/23 11:04, Manolis Tsamis wrote:
This code used to handle SUBREG for register replacement when ifcvt was doing
the replacements manually. This special handling is not needed anymore
because simplify_replace_rtx is used for the replacements and it properly
handles these cases.
On 11/21/23 16:27, Palmer Dabbelt wrote:
I was poking around with this test failure and noticed it was exercising
undefined behavior. The return type doesn't matter for what's being
tested, so just mark it as void.
gcc/testsuite/ChangeLog:
* gcc.dg/unroll-8.c: Remove UB.
I just
On 11/20/23 11:26, Richard Sandiford wrote:
+
+/* If we know the destination of CODE only uses some low bits
+ (say just the QI bits of an SI operation), then return true
+ if we can propagate the need for just the subset of bits
+ from the destination to the sources. */
+
+static
On 11/20/23 02:55, Florian Weimer wrote:
This revision addresses Marek's comment about handing
-Wdeclaration-missing-parameter-type properly in conjunction with
-fpermissive. A new test (permerror-fpermissive-nowarning.c)
demonstrates the expected behavior. I added a test for -std=gnu89
On 11/22/23 07:24, Christoph Müllner wrote:
On Wed, Nov 22, 2023 at 2:52 PM 钟居哲 wrote:
I am totally ok to approve theadvector on GCC-14 before stage 3 close
as long as it doesn't touch the current RVV codes too much and binutils
supports theadvector.
I have provided the draft approach:
On 11/21/23 16:27, Palmer Dabbelt wrote:
The vectorizer picks up these loops and disables unrolling on targets
with variable vector factors. That result in better code here, but it
trips up the unrolling tests. So just disable vectorization for these.
gcc/testsuite/ChangeLog:
PR
On 11/20/23 20:09, Xi Ruoyao wrote:
On Tue, 2023-11-21 at 08:00 +0800, Xi Ruoyao wrote:
/* snip */
This has broken libgcc builds when target libc isn't yet available.
In file included from
/scratch/jmyers/glibc-bot/src/gcc/libgcc/../gcc/config/loongarch/loongarch-def.h:49,
On 11/20/23 15:46, David Malcolm wrote:
On Fri, 2023-11-17 at 14:09 -0700, Jeff Law wrote:
On 11/17/23 14:08, Antoni Boucher wrote:
In contrast with the other frontends, libgccjit can be executed
multiple times in a row in the same process.
Yup. I'm aware of that. Even so calling
On 11/20/23 01:39, Richard Biener wrote:
On Mon, 20 Nov 2023, Jakub Jelinek wrote:
On Mon, Nov 20, 2023 at 07:54:54AM +, Richard Biener wrote:
On Fri, 17 Nov 2023, Jakub Jelinek wrote:
Per the earlier discussions on this PR, the following patch folds
popcount (x) == 1 (and != 1) into
On 10/30/23 01:25, Fei Gao wrote:
diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc
index 6e341fc4d4b..cfa9bc4b850 100644
--- a/gcc/ifcvt.cc
+++ b/gcc/ifcvt.cc
@@ -2911,7 +2911,7 @@ noce_try_sign_mask (struct noce_if_info *if_info)
static bool
noce_cond_zero_binary_op_supported (enum rtx_code op)
On 10/30/23 01:25, Fei Gao wrote:
+static bool
+noce_cond_zero_binary_op_supported (enum rtx_code op)
Function needs function comment.
And again in your new tests, don't require explicit registers unless you
know (due to use as function argument/return value) which register will
be
On 10/30/23 01:25, Fei Gao wrote:
Conditional add, if zero
rd = (rc == 0) ? (rs1 + rs2) : rs1
-->
czero.nez rd, rs2, rc
add rd, rs1, rd
Conditional add, if non-zero
rd = (rc != 0) ? (rs1 + rs2) : rs1
-->
czero.eqz rd, rs2, rc
add rd, rs1, rd
Co-authored-by: Xiao Zeng
gcc/ChangeLog:
On 10/30/23 21:35, Fei Gao wrote:
So just a few notes to further illustrate why I'm currently looking to
take the VRULL+Ventana implementation. The code above would be much
better handled by just calling noce_emit_cmove. noce_emit_cmove will go
through the conditional move expander. So
On 11/19/23 20:32, Xi Ruoyao wrote:
On Sun, 2023-11-19 at 19:52 -0700, Jeff Law wrote:
/* snip */
Unfortunately, I get some ICE building stage 1 libgcc with this patch on
loongarch64-linux-gnu:
during RTL pass: ext_dce
../../../gcc/libgcc/libgcc2.c: In function ‘__absvdi2’:
../../../gcc
On 11/19/23 19:33, Alexandre Oliva wrote:
I got spurious fails of tests that required arm_thumb1_movt_ok on a
target cpu that did not support movt. Looking into it, I found the
arm_movt property to have been cut into various procs that
checked for different properties. They shouldn't share
On 11/19/23 19:23, Xi Ruoyao wrote:
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's really
focused
On 11/19/23 18:22, Oleg Endo wrote:
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's really
focused
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's really
focused on a relatively narrow part of the extension problem.
What Joern's patch does is introduce a
On 11/19/23 04:27, Maciej W. Rozycki wrote:
We have an issue with `scan-assembler-times' handling expressions using
subexpressions as produced by capturing parentheses `()' in an odd way,
and one that is inconsistent with `scan-assembler', `scan-assembler-not',
etc. The problem comes from
On 11/12/23 07:52, Richard Sandiford wrote:
This patch adds a target-independent aligned_register_operand
predicate, for use with register constraints that use filters
to impose an alignment. The definition deliberately jetisons
some of the historical baggage in general_operand.
gcc/
On 11/12/23 07:52, Richard Sandiford wrote:
The main (but simplest) part of this patch makes constrain_operands
take register filters into account.
The rest of the patch adds register filter information to
operand_alternative. Generally, if two register constraints
have different register
On 11/12/23 07:52, Richard Sandiford wrote:
The main way of enforcing registers to be aligned is through
HARD_REGNO_MODE_OK. But this is a global property that applies
to all operands. A given (regno, mode) pair is either globally
valid or globally invalid.
This patch instead adds a way of
On 11/16/23 19:53, Andrew Carlotti wrote:
This patch changes the handling of mutual exclusions involving the
target and target_clones attributes to use the generic attribute
exclusion lists. Additionally, the duplicate handling for the
always_inline and noinline attribute exclusion is
On 11/16/23 22:12, Li Xu wrote:
From: xuli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537
-mmemcpy-strategy=[auto|libcall|scalar|vector]
auto: Current status, use scalar or vector instructions.
libcall: Always use a library call.
scalar: Only use scalar instructions.
vector: Only use
): Define.
(TARGET_SCHED_MACRO_FUSION_PAIR_P): Likewise.
(extract_base_offset_in_addr): Moved into riscv.cc from...
* config/riscv/thead.cc: Here.
Co-authored-by: Raphael Zinsly
Co-authored-by: Jeff Law
diff --git a/gcc/config/riscv/riscv
On 11/18/23 22:43, Maciej W. Rozycki wrote:
We have no FNE.fmt machine instructions, but we can emulate them for the
purpose of conditional-move and conditional-add operations by using the
respective FEQ.fmt instruction and then swapping the data input operands
or complementing the mask for
On 11/18/23 22:43, Maciej W. Rozycki wrote:
Verify, for generic floating-point conditional-add operations that have
a corresponding conditional-set machine instruction, that if-conversion
triggers via `noce_try_addcc' at `-mbranch-cost=3' setting, which makes
branchless code sequences emitted
On 11/18/23 22:43, Maciej W. Rozycki wrote:
Verify, for generic floating-point conditional-add operations that have
a corresponding conditional-set machine instruction, that if-conversion
does *not* trigger at `-mbranch-cost=2' setting, which makes original
branched code sequences cheaper
On 11/18/23 22:43, Maciej W. Rozycki wrote:
Verify, for generic floating-point conditional-move operations that have
a corresponding conditional-set machine instruction, that if-conversion
triggers (via `cond_move_convert_if_block', which doesn't report) at
`-mbranch-cost=5' setting, which
On 11/18/23 22:42, Maciej W. Rozycki wrote:
Verify, for generic floating-point conditional-move operations that have
a corresponding conditional-set machine instruction, that if-conversion
does *not* trigger at `-mbranch-cost=4' setting, which makes original
branched code sequences cheaper
On 11/18/23 22:42, Maciej W. Rozycki wrote:
We have floating-point coditional-set machine instructions for a subset
of FP comparisons, so avoid going through a comparison against constant
zero in `riscv_expand_float_scc' where not necessary, preventing an
extraneous RTL instruction from being
On 11/18/23 22:42, Maciej W. Rozycki wrote:
Do not expand floating-point conditional-branch RTL instructions right
away that use a comparison operation that is either directly available
as a machine conditional-set instruction or is NE, which can be emulated
by EQ. This is so that
on and an UNSPEC source, but the REG
has no mode in the pattern. Since it wasn't clear what mode to give the
UNSPEC, I left those alone.
Pushing to the trunk.
jeff
commit 07da9b7f13c92a21d12172a9df85ad762591b998
Author: Jeff Law
Date: Sun Nov 19 11:56:57 2023 -0700
[committed] Fix missi
On 11/18/23 22:36, Maciej W. Rozycki wrote:
The generic branch costing model for if-conversion assumes a fixed cost
of COSTS_N_INSNS (2) for a conditional branch, and that one half of that
cost comes from a preceding condition-set instruction, such as with
MODE_CC targets, and then the other
On 11/18/23 22:40, Maciej W. Rozycki wrote:
Code in `riscv_expand_conditional_move' for Ventana and Zicond targets
seems like bolted on as an afterthought rather than properly merged so
as to handle all the cases together.
You could characterize it that way. It was mostly a desire to not
On 11/18/23 22:42, Maciej W. Rozycki wrote:
In `riscv_expand_conditional_move' we only let integer conditions
through at the moment, even though code has already been prepared to
handle floating-point conditions as well.
Lift this restriction and only bail out if a non-word-mode integer
On 11/18/23 22:42, Maciej W. Rozycki wrote:
A subsequent change to enable the processing of conditional moves on a
floating-point condition by `riscv_expand_conditional_move' will cause
`riscv_expand_float_scc' to be called for word-mode target RTX with RV64
targets. In that case an invalid
On 11/18/23 22:41, Maciej W. Rozycki wrote:
Verify, for generic integer conditional-add operations, if-conversion
to trigger via `noce_try_addcc' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion cheaper than their
On 11/18/23 22:41, Maciej W. Rozycki wrote:
Verify, for generic integer conditional-add operations, if-conversion
*not* to trigger at the respective sufficiently low `-mbranch-cost='
settings that make original branched code sequences cheaper than their
branchless equivalents if-conversion
On 11/18/23 22:41, Maciej W. Rozycki wrote:
Provide RTL expansion of conditional-add operations for generic targets
using a suitable sequence of base integer machine instructions according
to cost evaluation by if-conversion. Use existing `-mmovcc' command
line option to enable this
On 11/18/23 22:41, Maciej W. Rozycki wrote:
Verify, for generic integer conditional-move operations, if-conversion
to trigger via `noce_try_cmove' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion cheaper than their
On 11/18/23 22:40, Maciej W. Rozycki wrote:
Verify, for generic integer conditional-move operations, if-conversion
*not* to trigger at the respective sufficiently low `-mbranch-cost='
settings that make original branched code sequences cheaper than their
branchless equivalents if-conversion
On 11/18/23 22:40, Maciej W. Rozycki wrote:
Provide RTL expansion of conditional-move operations for generic targets
using a suitable sequence of base integer machine instructions according
to cost evaluation by if-conversion. Add `-mmovcc' command line option
to enable this transformation,
On 11/18/23 22:40, Maciej W. Rozycki wrote:
Add a `riscv_emit_unary' helper for unary operations, complementing
`riscv_emit_binary'.
gcc/
* config/riscv/riscv-protos.h (riscv_emit_unary): New prototype.
* config/riscv/riscv.cc (riscv_emit_unary): New function.
OK
On 11/18/23 22:40, Maciej W. Rozycki wrote:
Verify, for T-Head targets and the non-equality integer conditional-move
operations, that if-conversion triggers via `noce_try_cmove' at
`-mbranch-cost=2' setting, which makes branchless code sequences
produced by if-conversion cheaper than their
On 11/18/23 22:40, Maciej W. Rozycki wrote:
Verify, for T-Head targets and the non-equality integer conditional-move
operations, that if-conversion does *not* trigger at `-mbranch-cost=1'
setting, which makes original branched code sequences cheaper than their
branchless equivalents
On 11/18/23 22:39, Maciej W. Rozycki wrote:
There is no need for the requirement for conditional-move data input
operands to be stricter for T-Head targets than for short forward branch
targets and limit them to registers only. They are keyed according to
the `sfb_alu_operand' predicate,
On 11/18/23 22:39, Maciej W. Rozycki wrote:
There is no need for the requirement for conditional-move comparison
operands to be stricter for T-Head targets than for other targets and
limit them to registers only. Constants will be reloaded if required
just as with branches or other-target
On 11/18/23 22:39, Maciej W. Rozycki wrote:
Verify, for Ventana and Zicond targets and the equality conditional-move
operations, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbranch-cost=' settings that make
branchless code sequences produced by
On 11/18/23 22:38, Maciej W. Rozycki wrote:
Verify, for Ventana and Zicond targets and the equality conditional-move
operations, that if-conversion does *not* trigger at the respective
sufficiently low `-mbranch-cost=' settings that make original branched
code sequences cheaper than their
On 11/18/23 22:38, Maciej W. Rozycki wrote:
In the non-zero case there is no need for the conditional value used by
Ventana and Zicond integer conditional operations to be specifically 1.
Regardless we canonicalize it by producing an extraneous conditional-set
operation, such as with the
On 11/18/23 22:38, Maciej W. Rozycki wrote:
Verify, for Ventana and Zicond targets and the GEU and LEU
conditional-move operations, that if-conversion does *not* trigger at
`-mbranch-cost=3' setting, which makes original branched code sequences
cheaper than their branchless equivalents
On 11/19/23 00:36, Alexandre Oliva wrote:
On targets that have -fshort-enums enabled by default, the type casts
in the pr108251 analyzer tests warn that the byte-aligned enums may
not be sufficiently aligned to be a struct connection *. The function
can't know better, the warning is
On 11/19/23 00:30, Alexandre Oliva wrote:
I've recently patched scev-3.c and scev-5.c because it only passed by
accident on ia32. It also fails on some (but not all) arm-eabi
variants. It seems hard to characterize the conditions in which the
optimization is supposed to pass, but expecting
On 11/19/23 04:24, Maciej W. Rozycki wrote:
Remove our RISC-V-specific `order_operator' predicate, which is exactly
the same as generic `ordered_comparison_operator' one.
gcc/
* config/riscv/predicates.md (order_operator): Remove predicate.
* config/riscv/riscv.cc
On 11/15/23 17:03, Patrick O'Neill wrote:
Ping.
Testsuite fixup similar to:
https://inbox.sourceware.org/gcc-patches/974e9e5e-8f07-46dd-b9b9-db8aa4685...@gmail.com/T/#t
https://inbox.sourceware.org/gcc-patches/7e78cd70-70c9-41b1-8a98-6977a1034...@rivosinc.com/T/#t
OK.
Jeff
On 11/10/23 11:00, Patrick O'Neill wrote:
On 11/9/23 17:34, Jeff Law wrote:
On 11/3/23 00:18, Patrick O'Neill wrote:
On non-vector targets dejagnu attempts dg-do compile for pr95401.cc.
This produces a command like this:
g++ pr95401.cc pr95401a.cc -S -o pr95401.s
which isn't valid (gcc
On 11/18/23 03:27, Jakub Jelinek wrote:
Hi!
On Fri, Nov 17, 2023 at 03:01:04PM +0100, Jakub Jelinek wrote:
As a follow-up, I'm considering changing in this routine the popcount
call to IFN_POPCOUNT with 2 arguments and during expansion test costs.
Here is the follow-up which does the rtx
On 11/17/23 07:01, Jakub Jelinek wrote:
Hi!
Per the earlier discussions on this PR, the following patch folds
popcount (x) == 1 (and != 1) into (x ^ (x - 1)) > x - 1 (or <=)
if the corresponding popcount optab isn't implemented (I think any
double-word popcount or call will be necessarily
On 11/17/23 15:19, Lewis Hyatt wrote:
Hello-
I often find it convenient to run a new c-c++-common test from the
main build dir like:
$ make -j 2 RUNTESTFLAGS=dg.exp=new-test.c check-gcc-{c,c++}
I noticed that sometimes this produces a corrupted site.exp and then no
tests work until it is
On 11/18/23 09:50, Maciej W. Rozycki wrote:
Verify, for short forward branch, T-Head, Ventana and Zicond targets and
the ordered floating-point conditional-move operations that already work
as expected, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high
On 11/17/23 16:16, 钟居哲 wrote:
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
may also need to add '^' to the punct_valid_p hook. But yes, this is
the preferred way to go when all we need to do is prefix the instruction
with "th.".
No. I don't think we need to
On 11/17/23 14:08, Antoni Boucher wrote:
In contrast with the other frontends, libgccjit can be executed
multiple times in a row in the same process.
Yup. I'm aware of that. Even so calling init_emit_once more than one
time still seems wrong.
jeff
On 11/16/23 15:36, Antoni Boucher wrote:
Hi.
This patch fixes a RTL bug when using some target-specific builtins in
libgccjit (bug 112576).
The test use a function from an unmerged patch:
https://gcc.gnu.org/pipermail/jit/2023q1/001605.html
Thanks for the review!
The natural question here
On 11/17/23 04:39, juzhe.zh...@rivai.ai wrote:
90% theadvector extension reusing current RVV 1.0 instructions patterns:
Just change ASM, For example:
@@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
(match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")]
VMULH)
On 11/17/23 07:18, Kito Cheng wrote:
I didn’t take a closer look yet on the ira/lra dump yet, but my feeling
is that may cause by the earlyclober modifier isn’t work as expect?
Let me take closer look tomorrow.
Remember that constraints aren't checked until register allocation. So
the
On 11/17/23 01:27, John David Anglin wrote:
On 2023-11-16 10:00 p.m., Jeff Law wrote:
I'm not seeing any obvious problems in the gcc testsuite. It needs testing on
packages that do extensive
floating point calculations.
OK, I'll focus on those.
THe more likely scenario is xmpy which
On 11/16/23 18:20, Sam James wrote:
Jeff, I don't suppose you could dig out the old bugs/commits just out of
interest?
That work goes back to the early 90s when I was primarily responsible
for the PA platform. But the core issue hasn't changed in that not
enough context is provided for
So looking for thoughts from the community on this one
Let's take this RTL:
(insn 10 9 11 2 (set (reg:SI 144)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_FRFLAGS)) "j.c":11:3 discrim 1 362 {riscv_frflags}
(nil))
(insn 11 10 55 2 (set (reg:DI 140
On 11/16/23 10:54, John David Anglin wrote:
Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. Committed
to trunk.
This patch works around problem compiling python3.11 by improving
REG+D address handling. The change results in smaller code and
reduced register pressure.
Dave
---
On 11/15/23 22:33, Fangrui Song wrote:
I have used this to check rtld and linker behavior. I think we need
some `scan-assembler`.
To make it a runnable test, some assembler feature check may be
needed. Perhaps Jeff can make some suggestion or contribute code!
TLS isn't really on my radar
On 11/15/23 18:51, Tatsuyuki Ishi wrote:
On Nov 16, 2023, at 10:07, Jeff Law wrote:
Based on what I have read in the AArch64 backend, there are two ways to
do this: introduce a custom calling convention, or put in a RTX insn
that covers the whole sequence. Ideally we should do
On 11/15/23 18:39, Tatsuyuki Ishi wrote:
As mentioned in the commit message, the use of relaxation-only labels
does not seem well supported in current GCC. Creating a label seems to
force a basic block and I’m not sure how we can avoid it.
If there’s a better way to implement this I’m
On 11/15/23 18:17, Fangrui Song wrote:
It seems that x86-64 supports non-adjacent code sequence. Writing the
pattern this way does not allow interleaving, but I assume
interleaving doesn't enable much.
It's of marginal benefit. We could always split them before scheduling
if it turned out
On 9/8/23 04:49, Tatsuyuki Ishi via Gcc-patches wrote:
This implements TLS Descriptors (TLSDESC) as specified in [1].
In TLSDESC instruction sequence, the first instruction relocates against
the target TLS variable, while subsequent instructions relocates against
the address of the first.
On 11/14/23 22:30, Tom Tromey wrote:
The gdb tests of the libcc1 plugin have been failing lately. I
tracked this down to a crash trying to access an enum's underlying
type. This patch fixes the crash by setting this type.
libcc1/ChangeLog
* libcc1plugin.cc
On 11/14/23 15:08, Sebastian Huber wrote:
Sebastian Huber (4):
gcov: Remove TARGET_GCOV_TYPE_SIZE target hook
Add TARGET_HAVE_LIBATOMIC
gcov: Add gen_counter_update()
gcov: Improve -fprofile-update=atomic
gcc/c-family/c-cppbuiltin.cc | 4 +-
gcc/config/rtems.h |
On 11/12/23 23:02, Iain Sandoe wrote:
This patch set is not actually particualry new, I have been maintaining
it locally one Darwin branches and it has been tested on several versions
of Darwin both with and without Alex's __has_{feature, extension} patch.
This is one of the three most
On 11/12/23 20:37, Juzhe-Zhong wrote:
This patch optimization of combine 2 duplicate vectors when their elements are
not equal.
typedef char v16qi __attribute__ ((vector_size (16)));
void
foo (char a, char b, char *out)
{
v16qi v = {a, a, a, a, a, b, b, b, b, b, b, b, b, b, b, b};
On 11/13/23 13:22, Maciej W. Rozycki wrote:
On Mon, 16 Oct 2023, Maciej W. Rozycki wrote:
The testcase is generic enough I thought it wouldn't hurt to place it in
a generic part of the testsuite, where it has been verified to pass with
the `powerpc64le-linux-gnu', `riscv64-linux-gnu', and
On 11/12/23 20:22, pan2...@intel.com wrote:
From: Pan Li
Update in v4:
* Merge upstream and removed some independent changes.
Update in v3:
* Take known_le instead of known_lt for vector size.
* Return NULL_RTX when gap is not equal 0 and not constant.
Update in v2:
* Move vector type
On 11/13/23 06:11, Florian Weimer wrote:
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-typeck.cc (build_conditional_expr): Use pedpermerror-
equivalent for pointer type mismatches in conditional
expression.
On 11/13/23 06:11, Florian Weimer wrote:
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-typeck.cc (c_finish_return): Issue a permerror
for mismatching pointers to builtins. For mismatching
other pointers, issue a pedpermerror.
On 11/13/23 06:11, Florian Weimer wrote:
There is a missed opportunity here to issue spelling diagnostics
in prototype declarations (e.g., for “extern int foo (int32t);”).
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-decl.cc (warn_defaults_to):
On 11/13/23 06:10, Florian Weimer wrote:
In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change here only changes the kind of the diagnostic, not
its wording or consequences.
gcc/c/
*
On 11/13/23 06:10, Florian Weimer wrote:
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-typeck.cc (build_conditional_expr): Use pedpermerror for
pointer/integer type mismatches, based on -Wint-conversion.
(pedwarn_pedpermerror_init,
On 11/13/23 06:09, Florian Weimer wrote:
It turns out that permerror_opt is not directly usable for
-fpermissive in the C front end. The front end uses pedwarn
extensively, and pedwarns are not overridable by -Wno-* options,
yet permerrors are. Add new pedpermerror helpers that turn into
On 11/12/23 23:53, Richard Biener wrote:
On Sun, Nov 12, 2023 at 12:12 AM Brendan Shanks wrote:
bad-mapper-1.C has been failing since the posix_spawn codepath was added
to libiberty, adjust the check to accept the changed error message.
Patch has been verified on x86_64 Linux.
OK
And
On 11/13/23 07:47, Robin Dapp wrote:
As per Jeff's remark I'm going to push the attached.
Regards
Robin
Subject: [PATCH v4] RISC-V: vsetvl: Refine REG_EQUAL equality.
This patch enhances the equality check for REG_EQUAL notes in the vsetvl
pass by using the == operator instead of
On 11/13/23 01:15, juzhe.zh...@rivai.ai wrote:
I know the root cause is:
(reg:DI 15 a5 [orig:175 _103 ] [175])
(reg:DI 15 a5 [orig:174 _100 ] [174])
is considered as true on rtx_equal_p.
I think return note1 == note2; will simplify your codes and fix this issue.
NOTEs are not shared
On 11/12/23 19:16, Jin Ma wrote:
Unfortunately this patch has triggered a bootstrap comparison failure on
loongarch64-linux-gnu: https://gcc.gnu.org/PR112497.
It's also causing simple build failures on other targets. For example
c6x-elf aborts when compiling gcc.c-torture/execute/pr82210
On 11/12/23 10:41, Xi Ruoyao wrote:
On Sat, 2023-11-11 at 13:12 -0700, Jeff Law wrote:
On 8/14/23 05:22, Jin Ma wrote:
CLOBBER and USE does not represent real instructions, but in the
process of pipeline optimization, they will wait for transmission
in ready list like other insns, without
On 8/14/23 05:22, Jin Ma wrote:
CLOBBER and USE does not represent real instructions, but in the
process of pipeline optimization, they will wait for transmission
in ready list like other insns, without considering resource
conflicts and cycles. This results in a multi-issue CPU architecture
On 6/11/23 21:38, Jin Ma wrote:
Why do you need a different cost based on what's in the ready list?
Isn't the only property we're looking for whether or not the USE/CLOBBER
opens a live range?
Jeff
For this, I found that if I only look for the USE/CLOBBER that opens a live
range,
when
On 11/11/23 05:11, Eric Botcazou wrote:
Hi,
IPA-CP can currently handle addresses of scalar constants (CONST_DECL) so this
extends that to addresses of constants in the pool (DECL_IN_CONSTANT_POOL).
Again this is helpful for so-called fat pointers in Ada, i.e. objects that are
semantically
On 11/10/23 15:06, Florian Weimer wrote:
gcc/testsuite/
* gcc.c-torture/compile/20080613-1.c (hop_sendmsg): Call
__builtin_memcpy instead of memcpy.
* gcc.c-torture/compile/complex-6.c (bar): Declare.
* gcc.c-torture/compile/pr23445.c (__brelse): Declare.
On 11/10/23 15:06, Florian Weimer wrote:
These tests use obsolete language constructs, but they are not
clearly targeting C89, either. So use -fpermissive to keep
future errors as warnings.
The reasons why obsolete constructs are used used vary from
test to test. Some tests deliberately
601 - 700 of 14622 matches
Mail list logo
