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
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
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
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 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
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
> 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/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
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
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
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.
>>
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
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 = _OPERAND
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
> 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 @@
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
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
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
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
>
> 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,
"* 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
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
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**)':
>
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
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
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
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
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
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
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,
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
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
+++
"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
>
> *
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
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 =
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 =
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 +
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
> 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
../../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)
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
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,
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
43 matches
Mail list logo
