Hi!
In this case the STATIC_CAST_EXPR expressions in the call aren't
type nor value dependent, but maybe_constant_value still ICEs on those
when processing_template_decl. Calling fold_non_dependent_expr on it
instead fixes the ICE and folds them to INTEGER_CSTs.
Bootstrapped/regtested on x86_64-
Hi!
The following testcase ICEs because there is NON_LVALUE_EXPR (location
wrapper) around a VAR_DECL and has TYPE_MODE V2SImode and
SCALAR_INT_TYPE_MODE on that ICEs. Or for -m32 -march=i386 TYPE_MODE
is DImode, but SCALAR_INT_TYPE_MODE still uses the raw V2SImode and ICEs
too.
Fixed thusly, bo
Hi,
On 16/6/2022 下午 7:24, Segher Boessenkool wrote:
> There is no normal way to get at bit 3 of a CR field. We can use some
> unspec though, which is total cheating but it does work, and it is
> safe, albeit sometimes suboptimal.
Thanks so much for your advice. I will use an unspec for setting r
../../gcc/config/riscv/bitmanip.md: In function 'rtx_insn* gen_split_44(rtx_ins\
n*, rtx_def**)':
../../gcc/config/riscv/bitmanip.md:110:28: error: comparison of integer express\
ions of different signedness: 'int' and 'long unsigned int' [-Werror=sign-compa\
re]
110 | if ((scale + bias)
> Am 17.06.2022 um 10:11 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> The following testcase ICEs because there is NON_LVALUE_EXPR (location
> wrapper) around a VAR_DECL and has TYPE_MODE V2SImode and
> SCALAR_INT_TYPE_MODE on that ICEs. Or for -m32 -march=i386 TYPE_MODE
> is DImod
On 2022/06/16 23:23 UTC+8, Gerald Pfeifer wrote:
On Thu, 16 Jun 2022, Chung-Ju Wu wrote:
Recently we added arm star-mc1 cpu support to upstream:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596379.html
It would be great if we can describe it on gcc-13 changes.html as well.
Attached is th
Expressions of the form "X + CST < Y + CST" where:
* CST is an unsigned integer constant with only the MSB set, and
* X and Y's types have integer conversion ranks <= CST's
can be simplified to "(signed) X < (signed) Y".
This is because, assuming a 32-bit signed numbers,
(unsigned) INT_MIN + 0x8
On Fri, Jun 17, 2022 at 10:37:45AM +0200, Richard Biener wrote:
> > --- gcc/varasm.cc.jj2022-06-06 12:18:12.792812888 +0200
> > +++ gcc/varasm.cc2022-06-17 09:49:21.918029072 +0200
> > @@ -4716,7 +4716,8 @@ narrowing_initializer_constant_valid_p (
> > {
> > tree inner = TREE_OPERA
A bug in the ordering of the operands in the mve_mov pattern
meant that all literal values were being pushed to the literal pool.
This patch fixes that and simplifies some of the logic slightly so
that we can use as simple switch statement.
For example:
void f (uint32_t *a)
{
int i;
for (i =
Hi,
This follows Richi's suggestion in PR105940, it aims to avoid
inconsistent slp decision between when the suggested unroll
factor is worked out and when the suggested unroll factor is
applied.
If the previous slp decision is true when the suggested unroll
factor is worked out, when we are appl
"Andre Vieira (lists)" writes:
> Hi,
>
> This patch adds support for the ACLE Data Intrinsics to the AArch64 port.
>
> Bootstrapped and regression tested on aarch64-none-linux.
>
> OK for trunk?
Sorry for the slow review.
>
> gcc/ChangeLog:
>
> 2022-06-10 Andre Vieira
>
> * config/aa
libgomp/ChangeLog:
* libgomp.texi: Add table header for new features of
OpenMP 5.2.
---
libgomp/libgomp.texi | 1 +
1 file changed, 1 insertion(+)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index a5e54456746..2c4622c1092 100644
--- a/libgomp/libgomp.texi
+++ b/libgo
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, I noticed
that the GCC 9.1 warning is not emitted in all the cases where it
should be. This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.
I sp
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated,
On Thu, 16 Jun 2022 at 20:23, Jonathan Wakely via Libstdc++
wrote:
>
> Tested x86_64-linux, pushed to trunk.
Somehow I messed up the test in the commit I pushed (but not the one I
tested ... weird).
Fixed at r13-1151-g0f96ac43fa0a5f by the attached patch.
-- >8 --
libstdc++: Add missing #in
On Thu, Jun 16, 2022 at 3:37 PM Vit Kabele wrote:
>
> When the compiler warns about padding struct to alignment boundary, it
> now also informs the user about the size of the alignment that needs to
> be added to get rid of the warning.
Hi, thanks for taking the time to improve -Wpadded; I have b
Sigh, another instance where I incorrectly used XUINT instead of
UINTVAL.
I've also made the code here a little more robust (although I think
this case can't in fact be reached) if the 32-bit clear mask includes
bit 31. This case, if reached, would print out an out-of-range value
based on the si
On 6/17/22 03:28, Jakub Jelinek wrote:
Hi!
In this case the STATIC_CAST_EXPR expressions in the call aren't
type nor value dependent, but maybe_constant_value still ICEs on those
when processing_template_decl. Calling fold_non_dependent_expr on it
instead fixes the ICE and folds them to INTEGER
Storing integer constants into litpool in the early stage of compilation
hinders some integer optimizations. In fact, such integer constants are
not subject to the constant folding process.
For example:
extern unsigned int value;
extern void foo(void);
void test(void) {
if (val
erratum:
- extern unsigned int value;
+ extern unsigned short value;
On 2022/06/17 22:47, Takayuki 'January June' Suwa via Gcc-patches wrote:
> Storing integer constants into litpool in the early stage of compilation
> hinders some integer optimizations. In fact, such integer constan
Hi Andreas:
Fixed via
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d6b423882a05d7b4f40ae1e9d942c9c4c13761b7,
thanks!
On Fri, Jun 17, 2022 at 4:34 PM Andreas Schwab wrote:
>
> ../../gcc/config/riscv/bitmanip.md: In function 'rtx_insn*
> gen_split_44(rtx_ins\
> n*, rtx_def**)':
> ../../gcc/conf
On Thu, Jun 16, 2022 at 09:37:32PM +0200, Vit Kabele wrote:
> When the compiler warns about padding struct to alignment boundary, it
> now also informs the user about the size of the alignment that needs to
> be added to get rid of the warning.
>
> This removes the need of using pahole or similar
"* something" isn't a type. "something *" is.
Tested and committed.
Segher
2022-06-17 Segher Boessenkool
* config/rs6000/rs6000.cc (rs6000_invalid_conversion): Correct some
types.
---
gcc/config/rs6000/rs6000.cc | 8
1 file changed, 4 insertions(+), 4 deletions(-
> PING^2
Sorry, I thought it is approved once we settled down the multiplicatoin
datatype, but apparently never sent the email.
Patch is oK.
Honza
>
> On 5/24/22 13:35, Martin Liška wrote:
> > PING^1
> >
> > On 5/5/22 20:15, Martin Liška wrote:
> >> On 5/5/22 15:49, Jan Hubicka wrote:
> >>> Hi,
Kito, thanks: you were a few minutes ahead of my fix there.
On Fri, 17 Jun 2022 at 16:00, Kito Cheng wrote:
> Hi Andreas:
>
> Fixed via
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d6b423882a05d7b4f40ae1e9d942c9c4c13761b7
> ,
> thanks!
>
> On Fri, Jun 17, 2022 at 4:34 PM Andreas Schwab
> wro
REGNO should not be used with register_operand before reload because
subregs of registers or even subregs of memory match the predicate.
The build with RTL checking enabled does not tolerate REGNO with
non-reg operand.
The patch splits the splitter into two related splitters and uses
(match_dup ...
The mode of pointer argument should equal ptr_mode, not Pmode.
2022-06-17 Uroš Bizjak
gcc/ChangeLog:
PR target/105970
* config/i386/i386.cc (ix86_function_arg): Assert that
the mode of pointer argumet is equal to ptr_mode, not Pmode.
gcc/testsuite/ChangeLog:
PR target/105970
This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal
compiler error) in the generic store_data_bypass_p function.
While at it, also remove ev4_ist_c reservation, store_data_bypass_p
can handle the patterns wit
> Am 17.06.2022 um 11:20 schrieb Jakub Jelinek via Gcc-patches
> :
>
> On Fri, Jun 17, 2022 at 10:37:45AM +0200, Richard Biener wrote:
>>> --- gcc/varasm.cc.jj2022-06-06 12:18:12.792812888 +0200
>>> +++ gcc/varasm.cc2022-06-17 09:49:21.918029072 +0200
>>> @@ -4716,7 +4716,8 @@ narrowi
On Thu, Jun 16, 2022 at 09:32:02PM +0100, Jonathan Wakely wrote:
> It looks like clang has addressed this deficiency now:
>
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage
Thanks, that is roughly what I'd implement anyway and apparently they have
it already since 2015, we've a
On Fri, Jun 10, 2022 at 09:57:06PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Jun 10, 2022 at 01:27:28PM -0400, Jason Merrill wrote:
> > Doesn't this assert mean that complex_expr will always be == valp?
>
> No, even when handling the pushed *PART_EXPR, it will set
> valp = &TREE_OPERAN
New linking implementation is complete, gcc bootstraps and hello
world links. I'll git push the changes, then test/debug/polish and
produce new patch sets
regards,
Gaius
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, June 13, 2022 9:41 AM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
>> Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to
>> set the lowpart.
>>
>>
Hi Yonghong.
> On 6/15/22 1:57 PM, David Faust wrote:
>>
>> On 6/14/22 22:53, Yonghong Song wrote:
>>>
>>>
>>> On 6/7/22 2:43 PM, David Faust wrote:
Hello,
This patch series adds support for:
- Two new C-language-level attributes that allow to associate (to
"annot
Hi!
On Fri, Jun 17, 2022 at 04:19:37PM +0800, HAO CHEN GUI wrote:
> On 16/6/2022 下午 7:24, Segher Boessenkool wrote:
> > You shouldn't need anything like this, bcdinvalid will work just fine if
> > written as bcdadd_ov (with vector of 0 as the second op)?
>
> The vector of 0 is not equal to BCD 0,
On 6/17/22 11:34, Jakub Jelinek via Gcc-patches wrote:
On Thu, Jun 16, 2022 at 09:32:02PM +0100, Jonathan Wakely wrote:
It looks like clang has addressed this deficiency now:
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage
Thanks, that is roughly what I'd implement anyway an
> Am 17.06.2022 um 19:09 schrieb Gaius Mulley via Gcc-patches
> :
>
>
> New linking implementation is complete, gcc bootstraps and hello
> world links. I'll git push the changes, then test/debug/polish and
> produce new patch sets
Great!
Thanks,
Richard
> regards,
> Gaius
On 6/17/2022 9:22 AM, Uros Bizjak via Gcc-patches wrote:
This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal
compiler error) in the generic store_data_bypass_p function.
While at it, also remove ev4_ist_
On Thu, Jun 16, 2022 at 3:59 AM Tamar Christina via Gcc-patches
wrote:
>
> Hi All,
>
> For IEEE 754 floating point formats we can replace a sequence of alternative
> +/- with fneg of a wider type followed by an fadd. This eliminated the need
> for
> using a permutation. This patch adds a math.p
Related to PR104642, the current situation where we get less return checking
with just -fsanitize=unreachable than no sanitize flags seems undesirable; I
propose that we do return checking when -fsanitize=unreachable.
Looks like clang just traps on missing return if not -fsanitize=return, but
the
On Tue, May 31, 2022 at 12:41 PM Sören Tempel wrote:
>
> PING.
>
> If there is anything else that needs to be addressed please let me know.
Thanks. Committed as follows. Sorry for the delay.
Ian
e584afe7976a40df42eed4df6ce6852abab74030
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/M
Hello-
The attached fixes PR preprocessor/55971:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971
, which is the issue that we don't currently allow raw string literals
containing embedded newlines to appear in #define. With the patch, they can be
used in any preprocessing directive.
While I w
The initial commit that added opaque types thought that there couldn't
be any valid initializations for variables of these types, but the test
case in the bug report shows that isn't true. The solution is to handle
OPAQUE_TYPE initializations just like the other scalar types.
This passed bootstra
On Fri, Jun 17, 2022 at 6:48 AM Takayuki 'January June' Suwa
wrote:
>
> Storing integer constants into litpool in the early stage of compilation
> hinders some integer optimizations. In fact, such integer constants are
> not subject to the constant folding process.
>
> For example:
>
> extern
44 matches
Mail list logo
