https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
Bug ID: 113575
Summary: [14 Regression] memory hog building insn-opinit.o
(i686-linux-gnu -> riscv64-linux-gnu)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #15 from Andrew Pinski ---
(In reply to Richard Biener from comment #14)
> a >= 16 ? 0 : 32872 >> MIN (a, 15) (the MIN is still required to
> avoid requiring masking).
Note maybe instead of MIN here we use `a & 0xf` since that will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110075
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
Richard Biener changed:
What|Removed |Added
Blocks||110838
--- Comment #14 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #42 from Patrick O'Neill ---
(In reply to JuzheZhong from comment #41)
> Hi, Patrick.
>
> Could you trigger test again base on latest trunk GCC?
>
> We have recent memory-hog fix patch:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
--- Comment #19 from Tamar Christina ---
*** Bug 113555 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113555
Tamar Christina changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
Tamar Christina changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113561
Tamar Christina changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
--- Comment #17 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:72429448fd16733f876b282bb37a0653049c446d
commit r14-8382-g72429448fd16733f876b282bb37a0653049c446d
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #21 from Richard Biener ---
(In reply to Tamar Christina from comment #20)
> (In reply to rguent...@suse.de from comment #19)
> > > Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org
> > > :
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #41 from JuzheZhong ---
Hi, Patrick.
Could you trigger test again base on latest trunk GCC?
We have recent memory-hog fix patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3132d2d36b4705bb762e61b1c8ca4da7c78a8321
I want to
On 22 January 2024 21:33:17 CET, Kwok Cheung Yeung
wrote:
>Hi
>
>There was a bug in the declare-target-indirect-2.c libgomp testcase (testing
>indirect calls in offloaded target regions, spread over multiple
>teams/threads) that due to an errant fallthrough in a switch statement
>resulted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113550
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
The split for movv8di is not ready to handle the case where the setting
register overlaps with the address of the memory that is being load.
Fixing the split than just making the output constraint as an early clobber
for this alternative. The split would first need to figure out which register
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113574
--- Comment #3 from Andrew Pinski ---
Note I was thinking I might hit this with 1 sized bit field but that seems to
work:
```
struct f
{
unsigned ub1:1;
}t;
void
foo(unsigned short ub16)
{
t.ub1 = (ub16 << 2);
}
int
main(void)
{
unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11264
Andrew Pinski changed:
What|Removed |Added
Resolution|WORKSFORME |WONTFIX
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
--- Comment #2 from Robin Dapp ---
I'm pretty certain this is "works as intended" and -Ofast causes the precision
to be different than with -O3 (and dependant on the target). See also:
It has been reported that with gfortran -Ofast
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/libstdc++/api/a10385.html
should be the latest. I thought there is a std::string/char* constructor.
-Original Message-
From: Ming Cheng
Sent: Wednesday, January 24, 2024 2:20 PM
To: Jonathan Wakely
Cc: GCC Development
Subject: RE: GCC Decimal128
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote:
>
> > - If I get this right, to take one example, the Fortran front-end will emit
> > a call to gfortran_acospi_r4(), libgfortran provides this as a wrapper
> > calling acospif(), which is called either from libm or from
on 2024/1/24 11:11, Peter Bergner wrote:
> On 1/23/24 8:30 PM, Kewen.Lin wrote:
>>> - output_operand_lossage ("invalid %%x value");
>>> + output_operand_lossage ("invalid %%%c value", (code == 'S' ? 'S' :
>>> 'x'));
>>
>> Nit: Seems simpler with
>>
>> output_operand_lossage ("invalid
Change the style from & to && to reflect boolean result with boolean
operation (instead of bitwise operation)
>From 10b501ffa8a11c7f10fd6e6ab5d9a876a321fe13 Mon Sep 17 00:00:00 2001
From: Jasmine
Date: Tue, 23 Jan 2024 21:18:13 -0800
Subject: [PATCH] Fix compiler warning: Boolean result is used
Thanks, I'll check them out.
On Wed, 24 Jan, 2024, 03:52 Martin Jambor, wrote:
> Hello,
>
> We are delighted you found contributing to GCC interesting. GCC has
> applied to be part of GSoC 2024 but of course selected organizations
> have not been announced yet.
>
> On Fri, Jan 12 2024, Gaurang
Change the style from & to && to reflect boolean result with boolean
operation (instead of bitwise operation)
David Binderman 2017-07-01 13:24:44 UTC
trunk/gcc/cp/lex.c:116]: (style) Boolean result is used in bitwise
operation. Clarify expression with parentheses.
Source code is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113574
--- Comment #2 from Andrew Pinski ---
convert uses TYPE_SIZE
/* If shift count is less than the width of the truncated type,
really shift. */
if (tree_int_cst_lt (TREE_OPERAND (expr,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113574
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-24
Ever confirmed|0
n algorithms: zlib zstd
gcc version 14.0.1 20240123 (experimental) (GCC)
From: Takayuki 'January June' Suwa
gcc/ChangeLog:
* config/xtensa/constraints.md (R, T, U):
Change define_constraint to define_memory_constraint.
* config/xtensa/predicates.md (move_operand): Don't check that a
constant pool operand size is a multiple of
Hi Suwa-san,
I've finally processed the new issues introduced by this change.
On Wed, May 10, 2023 at 2:10 AM Max Filippov wrote:
> On Mon, May 8, 2023 at 6:38 AM Takayuki 'January June' Suwa
> wrote:
> >
> > gcc/ChangeLog:
> >
> > * config/xtensa/constraints.md (R, T, U):
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113550
--- Comment #2 from Andrew Pinski ---
Thinking about this, maybe it is too complex to figure out which register
overlaps with the memory. So the easiest is just to mark `=r/m` alternative as
an early clobber.
On Linux/x86_64,
a98d5130a6dcff2ed4db371e500550134777b8cf is the first bad commit
commit a98d5130a6dcff2ed4db371e500550134777b8cf
Author: Richard Biener
Date: Mon Jan 15 12:55:20 2024 +0100
rtl-optimization/113255 - base_alias_check vs. pointer difference
caused
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113398
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
--- Comment #5 from Andrew Pinski ---
Note the issue is really:
9730rtx op = lowpart_subreg (mode, operands[1],
mode);
We have:
(subreg:V8QI (reg/v:V4x8QI 110 [ input_pixels ]) 8)
And then lowpart_subreg returns null.
Note I still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Andrew Pinski changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113573
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113573
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
From: Pan Li
According to the issue as below.
https://hub.fgit.cf/riscv-non-isa/riscv-elf-psabi-doc/pull/416
When the mode size of vls integer mode is less than 2 * XLEN, we will
take the gpr/fpr for both the args and the return values. Instead of
the reference. For example the below code:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113573
Bug ID: 113573
Summary: aarch64: internal compiler error in mark_label_nuses
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On 1/23/24 8:30 PM, Kewen.Lin wrote:
>> -output_operand_lossage ("invalid %%x value");
>> +output_operand_lossage ("invalid %%%c value", (code == 'S' ? 'S' :
>> 'x'));
>
> Nit: Seems simpler with
>
> output_operand_lossage ("invalid %%%c value", (char) code);
Agreed, good catch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112437
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
--- Comment #2 from Andrew Pinski ---
#6 0x015646e1 in aarch64_sve::vector_cst_all_same (v=0x76be4d20,
step=8) at ../../gcc/config/aarch64/aarch64-sve-builtins.cc:3477
3477if (!operand_equal_p (VECTOR_CST_ENCODED_ELT (v,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113571
--- Comment #3 from Halalaluyafail3 ---
The way the standard is written doesn't make any distinction between a
preprocessor constant expression and a language constant expression (from what
I have seen). The standard just says integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113571
--- Comment #2 from Andrew Pinski ---
No compiler (GCC, MSVC and clang) I tested accepts this code. I am thinking you
misunderstand something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Hi Mike,
on 2024/1/12 01:29, Michael Meissner wrote:
> This is version 2 of the patch. The only difference is I made the test case
> simpler to read.
>
> In looking at support for load vector pair and store vector pair for the
> PowerPC in GCC, I noticed that we were missing a print_operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113571
--- Comment #1 from Andrew Pinski ---
The preprocessor constant expression != language constant expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #26 from LIU Hao ---
Created attachment 57199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57199=edit
Draft patch Ver. 2
1. Fix a typo in `ASM_OUTPUT_SYMBOL_REF` (`x` => `SYM`)
2. For Intel syntax, if the name does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
Bug ID: 113572
Summary: aarch64: internal compiler error in
aarch64_sve::vector_cst_all_same
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113571
Bug ID: 113571
Summary: Preprocessor if directive does not correctly recognize
all C++ integral constant expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80036
Bug 80036 depends on bug 43486, which changed state.
Bug 43486 Summary: Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
Bug 7 depends on bug 43486, which changed state.
Bug 43486 Summary: Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77733
Bug 77733 depends on bug 43486, which changed state.
Bug 43486 Summary: Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
Bug 61534 depends on bug 43486, which changed state.
Bug 43486 Summary: Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70730
Bug 70730 depends on bug 43486, which changed state.
Bug 43486 Summary: Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Bug 69602 depends on bug 43486, which changed state.
Bug 43486 Summary: Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302
Bug 71302 depends on bug 43486, which changed state.
Bug 43486 Summary: Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
What|Removed |Added
The reduced testcase for pr113429 (cam4 failure) needed additional
modules so it wasn't committed.
The fuzzer found a c testcase that was also fixed with pr113429's fix.
Adding it as a regression test.
PR target/113429
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #12 from GCC Commits ---
The master branch has been updated by Patrick O'Neill :
https://gcc.gnu.org/g:7f7d9c525c694e36ae525ed93ccd5b6ffad0f1d8
commit r14-8379-g7f7d9c525c694e36ae525ed93ccd5b6ffad0f1d8
Author: Patrick O'Neill
ok
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2024-01-24 08:50
To: gcc-patches
CC: juzhe.zhong; kito.cheng; law; rdapp; vineetg; Patrick O'Neill
Subject: [PATCH] RISC-V: Add regression test for vsetvl bug pr113429
The reduced testcase for pr113429 (cam4 failure) needed additional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #40 from Patrick O'Neill ---
(In reply to Patrick O'Neill from comment #39)
> FYI I ran spec2017 last night and got:
>
> zvl128b:
> no fails!
>
> zvl256b:
> 549.fotonik3d (runtime) - pr113570
GCC hash:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #39 from Patrick O'Neill ---
FYI I ran spec2017 last night and got:
zvl128b:
no fails!
zvl256b:
549.fotonik3d (runtime) - pr113570
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
The reduced testcase for pr113429 (cam4 failure) needed additional
modules so it wasn't committed.
The fuzzer found a c testcase that was also fixed with pr113429's fix.
Adding it as a regression test.
PR 113429
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr113429.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #18 from Yuxuan Shui ---
(In reply to Andrew Pinski from comment #17)
> (In reply to Yuxuan Shui from comment #16)
> > ...
>
> So -fno-strict-overflow does -fno-wrapv-pointer so we can assume pointer
> arithmetic wraps now and then
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #32 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:3132d2d36b4705bb762e61b1c8ca4da7c78a8321
commit r14-8378-g3132d2d36b4705bb762e61b1c8ca4da7c78a8321
Author: Juzhe-Zhong
Date: Tue Jan
Since the result type of the call to .ACCESS_WITH_SIZE is a pointer to
the element type. The original array_ref is converted to an indirect_ref,
which introduced two issues for the instrumenation of bound sanitizer:
A. The index for the original array_ref was mixed into the offset
expression for
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This
Hi,
This is the 4th version of the patch.
It based on the following proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635884.html
Represent the missing dependence for the "counted_by" attribute and its
consumers
**The summary of the proposal is:
* Add a new internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #17 from Andrew Pinski ---
(In reply to Yuxuan Shui from comment #16)
> I see. but if it's undefined, why was the `if (dso)` only removed when
> -fno-strict-overflow is enabled? and it still happens with
>
On Tue, 23 Jan 2024, 23:53 Patrick Palka, wrote:
> This is consistent with std::tuple's __const_assignable member function,
> and will be reused when implementing the new pair::operator= overloads
> from P2165R4.
>
OK
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_pair.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #16 from Yuxuan Shui ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Yuxuan Shui from comment #12)
>> ...
>
> Except that is undefined ...
> Manually unswitching introduces the undefined behavior in the code.
> So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #15 from Yuxuan Shui ---
(In reply to Marek Polacek from comment #14)
> I don't see a complete testcase that I could bisect.
Please use the code sample in the original comment. since there are questions
that the manually unswitched
Tested on x86_64-pc-linux-gnu, does this look OK for trunK?
-- >8 --
This implements the C++23 paper P2165R4 Compatibility between tuple,
pair and tuple-like objects, which builds upon many changes from the
earlier C++23 paper P2321R2 zip.
Some declarations had to be moved around so that
This is consistent with std::tuple's __const_assignable member function,
and will be reused when implementing the new pair::operator= overloads
from P2165R4.
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h (pair::_S_const_assignable): Define,
factored out from ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #14 from Marek Polacek ---
I don't see a complete testcase that I could bisect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #13 from Andrew Pinski ---
(In reply to Yuxuan Shui from comment #12)
> I think this is the MRE:
>
>
> void bug(struct obj *dso) {
> if (>i) {
> if (dso == (void *)0)
> return;
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #12 from Yuxuan Shui ---
I think this is the MRE:
void bug(struct obj *dso) {
if (>i) {
if (dso == (void *)0)
return;
assert_not_null(dso);
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #11 from Yuxuan Shui ---
reduced it a bit:
void bug(struct obj **root, struct obj *dso) {
if (>i) {
while (1) {
struct obj *this = *root;
if (dso == (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #10 from Yuxuan Shui ---
the manually unswitched version can probably be reduced further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
Yuxuan Shui changed:
What|Removed |Added
Summary|[13 Regression] |[13 Regression]
>> Why that change? Was no-schedule necessary before and is not anymore?
>> Is it a result from the changes? I'd hope not.
Yes. But reasonable. So adapt testcase is enough.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-24 05:12
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100058
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
>
> Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
> > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
> >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
> >>>
> >>> From: Björn Schäpers
> >>>
> >>> Fixes
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
>
> Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
> > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
> >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
> >>>
> >>> From: Björn Schäpers
> >>>
> >>> Fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109640
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113256
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hello,
We are delighted you found contributing to GCC interesting. GCC has
applied to be part of GSoC 2024 but of course selected organizations
have not been announced yet.
On Fri, Jan 12 2024, Gaurang Aswal via Gcc wrote:
> Hey I am Gaurang Aswal a 4th year B.E. Computer Science student from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111607
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
--- Comment #1 from Vineet Gupta ---
This one is a headache as we don't know where the problem is. And that it takes
~7hr for a QEMU run to finish.
Good this is there is a comparison point as VLA build works fine.
(1). bloat-o-meter (from
On Linux/x86_64,
a98d5130a6dcff2ed4db371e500550134777b8cf is the first bad commit
commit a98d5130a6dcff2ed4db371e500550134777b8cf
Author: Richard Biener
Date: Mon Jan 15 12:55:20 2024 +0100
rtl-optimization/113255 - base_alias_check vs. pointer difference
caused
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
Bug ID: 113570
Summary: RISC-V: SPEC2017 549 fotonik3d miscompilation in
autovec VLS 256 build
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 311 matches
Mail list logo
