https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38264
--- Comment #6 from Andrew Pinski ---
I actually just ran into a problem caused by having this check here.
I was modifying tree-ssa-ifcombine to optimize the case where we have the same
condition on both bb from a bb like:
```
int g();
int h();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #8 from john.harper at vuw dot ac.nz ---
I couldn't see the program teste0es0en0.f90 that is in your bugzilla but
I could see that it does have 691 bytes. So does one of the two versions
that I now have in my own computer. The
(หากคุณกำลังมองหาเงินทุนหมุนเวียนระยะสั้น)
สำหรับผู้ประกอบการ โรงงานฯ หจก. บริษัท ธุรกิจ SME
อนุมัติง่ายกว่าธนาคาร | ไม่เช็คบูโร | ลดต้น ลดดอกเบี้ย | ไม่ต้องมีคนค้ำ |
อนุมัติทันที หลังส่งเอกสารครบถ้วน 1 ช.ม
หากคุณสนใจบริการของเรา โทรด่วนหาเรา
โทร 082 5928519 คุณเอก
โทร 063 2543219 ตะวัน
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from Jerry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70290
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70744
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.5
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60
Bug ID: 60
Summary: ICE on assigning volatile through ternary operator
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #5 from Paul Eggert ---
(In reply to Alexander Monakov from comment #4)
> To evaluate scheduling aspect, keep 'mov eax, 1' while changing 'add rbx,
> rax' to 'add rbx, 1'.
Adding the (unnecessary) 'mov eax, 1' doesn't affect the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Andrew Pinski changed:
What|Removed |Added
Known to work||2.95.3
Committed, thanks Robin.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Robin Dapp via Gcc-patches
Sent: Thursday, August 24, 2023 6:23 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; kito.ch...@gmail.com; kito.ch...@sifive.com;
jeffreya...@gmail.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed|2023-08-08 00:00:00 |2023-08-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
Priority|P3 |P1
This adds dump on the full result of the match-and-simplify
for phiopt and specifically to know if we are rejecting something
due to being in early phi-opt.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (gimple_simplify_phiopt):
Somehow when I was testing the new testcase, it was working but
when I re-ran the full testsuite it was not. Anyways the issue
was just a simple space before the `}` for dg-options directive.
Committed as obvious.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/phi-opt-34.c: Fix dg-options
On 8/25/23 19:37, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) When saying that a conversion is erroneous because it would use
an explicit constructor, it might be nice to show where exactly
the explicit constructor is located. For example,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #2 from Andrew Pinski ---
So I think this is because ethread can understand `(a & b)!=0` but not
`(a*c)!=0` that is a*c != 0 means that a or c will both be non-zero (especially
since a*c is known to not to overflow as c as a range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110503
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> One thing I noticed (I don't know if causes the missed optimization) is that
> we have before PRE:
> ```
>[local count: 1073531371]:
> if (a.0_1 != 0)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
--- Comment #3 from Andrew Pinski ---
One thing I noticed (I don't know if causes the missed optimization) is that we
have before PRE:
```
[local count: 1073531371]:
if (a.0_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local
On 8/25/2023 11:53 AM, Jeff Law via Gcc-patches wrote:
On 8/24/23 15:19, Edwin Lu wrote:
Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/
This patch updates the sync instructions to ensure that no insn is left
without a type
* MAINTAINERS: Add myself
Signed-off-by: Edwin Lu
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e706df6522..da2817a547c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -541,6 +541,7 @@ Gabor Loki
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) When saying that a conversion is erroneous because it would use
an explicit constructor, it might be nice to show where exactly
the explicit constructor is located. For example, with this patch:
[...]
explicit.C:4:12:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
--- Comment #2 from Andrew Pinski ---
Looks to be fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59
Bug ID: 59
Summary: [13 Regression] False positive -Wdangling-reference
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Thu, Aug 24, 2023 at 11:47 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > Now that MIN/MAX can sometimes be transformed into BIT_AND/BIT_IOR,
> > we should allow BIT_AND and BIT_IOR in the early phiopt.
> > Also we
Snapshot gcc-12-20230825 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20230825/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Spurred by Jivan's patch and a desire for cleaner testresults, I went
ahead and make the stack_save_restore tests independent of the precise
stack size by using a regexp.
Pushed to the trunk.
Jeffcommit e1f096a3cc96c71907cfbc7b8baf67a3d863cb6d
Author: Jeff Law
Date: Fri Aug 25 16:34:17
I thought I had already fixed this, but clearly if I did, I didn't
include it in any upstream commits.
With -Og the optimizers are hindered in various ways and this prevents
using zicond. So skip this test with -Og (it was already being skipped
at -O0).
Pushed to the trunk.
Jeff
commit
On 8/25/23 6:20 AM, Kewen.Lin wrote:
> Assuming the current PCREL_SUPPORTED_BY_OS unchanged, when
> PCREL_SUPPORTED_BY_OS is true, all its required conditions are
> satisfied, it should be safe. while PCREL_SUPPORTED_BY_OS is
> false, it means the given subtarget doesn't support it, or one
> or
On 8/13/23 23:50, Jin Ma wrote:
This patch adds the 'Zfa' extension for riscv, which is based on:
https://github.com/riscv/riscv-isa-manual/commits/zfb
The binutils-gdb for 'Zfa' extension:
https://sourceware.org/pipermail/binutils/2023-April/127060.html
What needs special explanation is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #54 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #53)
> Additional comment: the commit which fixed/"fixed" this offending commit
> came between July 3 and July 10.
Wildly speculating, it would be this commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #53 from Jürgen Reuter ---
Additional comment: the commit which fixed/"fixed" this offending commit came
between July 3 and July 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #52 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #51)
> The easiest would be to bisect gcc in the suspected ranges, that way you'd
> know for sure which git commit introduced the problem and which
> fixed/"fixed"
On Fri, 2023-08-25 at 16:12 -0400, Michael Welsh Duggan via Gcc wrote:
> I am attempting to debug an issue in gcc (PR 110827, if curious). In
> order to do this I have built a stage 1 compiler with debugging and
> without optimization as discussed here:
>
>
On 8/14/23 06:51, Jin Ma wrote:
This code is great and completely different from the way I implemented it.
I'm not sure which one is better, but my idea is that the fli instruction
corresponds to three tables (HF, SF and DF), all of which represent
specific values. the library in gcc's
Hi!
This paper voted in as DR makes some multi-character literals ill-formed.
'abcd' stays valid, but e.g. 'á' is newly invalid in UTF-8 exec charset
while valid e.g. in ISO-8859-1, because it is a single character which needs
2 bytes to be encoded.
The following patch does that by checking
After more investigations, it seems like the fault was on our side as
we were calling `gcc_jit_type_get_restrict` on types that weren't
pointers.
I added a check for that in `gcc_jit_type_get_restrict` directly as well.
We will continue our investigation to be sure we didn't miss anything.
Le
Hello-
This is adding a testcase for a PR that was already incidentally fixed. OK
to commit please? Thanks...
-Lewis
-- >8 --
The PR was fixed by r12-5454. Since the fix was somewhat incidental,
although related, add a testcase from PR90400 too before closing it out.
gcc/testsuite/ChangeLog:
Michael Welsh Duggan via Gcc writes:
> I am attempting to debug an issue in gcc (PR 110827, if curious). In
> order to do this I have built a stage 1 compiler with debugging and
> without optimization as discussed here:
>
> https://gcc.gnu.org/wiki/DebuggingGCC#Building_a_Debuggable_Compiler
Hi!
The following patch implements
CWG 2406 - [[fallthrough]] attribute and iteration statements
The genericization of some loops leaves nothing at all or just a label
after a body of a loop, so if the loop is later followed by
case or default label in a switch, the fallthrough statement isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102409
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483
--- Comment #3 from Marek Polacek ---
The error comes from verify_constant, which doesn't explain anything.
verify_constant uses reduced_constant_expression_p which just says yes/no but
doesn't explain anything. reduced_constant_expression_p
On Fri, Aug 25, 2023 at 4:16 PM Michael Welsh Duggan via Gcc <
gcc@gcc.gnu.org> wrote:
> I am attempting to debug an issue in gcc (PR 110827, if curious). In
> order to do this I have built a stage 1 compiler with debugging and
> without optimization as discussed here:
>
>
On 8/13/23 23:32, Tsukasa OI via Gcc-patches wrote:
From: Tsukasa OI
This commit adds support for the 'Zfa' extension containing additional
floating point instructions, version 0.1 (stable and approved).
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
I am attempting to debug an issue in gcc (PR 110827, if curious). In
order to do this I have built a stage 1 compiler with debugging and
without optimization as discussed here:
https://gcc.gnu.org/wiki/DebuggingGCC#Building_a_Debuggable_Compiler
I would like run the compiler from its build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
--- Comment #2 from Vineet Gupta ---
Test case to help drive some of this:
unsigned long long f5(unsigned long long i)
{
return i * 0x0202020202020202ULL;
}
On Fri, 2023-08-25 at 14:48 +0200, Benjamin Priour wrote:
> Hi David,
>
> Thanks for the review.
>
> On Fri, Aug 25, 2023 at 2:12 AM David Malcolm
> wrote:
>
> > > From: benjamin priour
> > >
> > > Hi,
> > >
> > > Below the first batch of a serie of patches to transition
> > > the analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
--- Comment #3 from Martin Jambor ---
Simple C testcase:
-- pr57_0.c --
/* { dg-lto-do run } */
/* { dg-lto-options { { -O2 -flto=auto } } } */
/* { dg-extra-ld-options { -flto-partition=1to1 } } */
extern
th 201 annotations[1] added. Things work as expected. :)
-Kees
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=devel/next-20230825/counted_by
--
Kees Cook
On Fri, 2023-08-25 at 08:50 -0400, Eric Feng wrote:
> Hi Dave,
>
> Please find an updated WIP patch on reference count checking below. Some
> parts aren't properly formatted yet; I apologize for that.
>
> Since the last WIP patch, the major updates include:
> - Updated certain areas of the core
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
In the Fortran front end, most of
gcc/testsuite/ChangeLog
* c-c++-common/gomp/imperfect-attributes.c: New.
* c-c++-common/gomp/imperfect-badloops.c: New.
* c-c++-common/gomp/imperfect-blocks.c: New.
* c-c++-common/gomp/imperfect-extension.c: New.
* c-c++-common/gomp/imperfect-gotos.c: New.
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C front end
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Imperfectly-nested loops are done.
---
libgomp/libgomp.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 5c91163893f..4aad8cc52f4 100644
--- a/libgomp/libgomp.texi
+++
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C++ front end
In order to detect invalid jumps in and out of intervening code in
imperfectly-nested loops, the front ends need to insert some sort of
marker to identify the structured block sequences that they push into
the inner body of the loop. The error checking happens in the
diagnose_omp_blocks pass,
V2 of these patches were previously approved with a few small changes
requested. For the archives, here is the version I've pushed.
Parts 1 and 2 are unchanged since V2. In part 3 (C++) I had to fix a
merge problem by hand. In parts 4 and 5, I hacked up a couple tests
as requested by Jakub.
Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for
hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6")
backend currently returns 0, causing Hoist to bail and elide GCSE.
Note that constants requiring more than 1 insns to setup were working
fine since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58
Bug ID: 58
Summary: diagnostics, colors, and std::same_as
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111013
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
See Also|
On 8/24/23 15:19, Edwin Lu wrote:
Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/
This patch updates the sync instructions to ensure that no insn is left
without a type attribute. Updates a total of 6 insns to have type "atomic"
On 8/24/23 23:16, Vineet Gupta wrote:
Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for
hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6")
backend currently returns 0, causing Hoist to bail and elide GCSE.
Note that constants requiring more than
On 8/24/23 09:45, Jivan Hakobyan via Gcc-patches wrote:
Subject:
RISC-V: Fix stack_save_restore_1/2 test cases
From:
Jivan Hakobyan via Gcc-patches
Date:
8/24/23, 09:45
To:
GCC Patches , Jeff Law
This patch fixes failing stack_save_restore_1/2 test cases.
After 6619b3d4c15c commit size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d9a0d692ffc6951c5670f54c3f4f17ec64a58600
commit r14-3486-gd9a0d692ffc6951c5670f54c3f4f17ec64a58600
Author: Andrew Pinski
Date:
In PR 106677, I noticed that on the trunk we were producing:
```
_25 = SR.116_117 == 0;
_27 = (unsigned char) _25;
_32 = _27 | SR.116_117;
```
>From `SR.115_117 != 0 ? SR.115_117 : 1`
Rather than:
```
_119 = MAX_EXPR <1, SR.115_117>;
```
Or (rather)
```
_119 = SR.115_117 | 1;
```
Due to
On Fri, Aug 25, 2023 at 11:11 AM Andrew Pinski wrote:
>
> On Thu, Aug 24, 2023 at 11:39 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> > wrote:
> > >
> > > In PR 106677, I noticed that on the trunk we were producing:
> > > ```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472
Askar Safin changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
This syncs the libgomp.texi implementation status to the webpage,
i.e. adding a few new items + marking some as 'supported'.
It also fixes a couple of bugs and adds links providing more details
for two items (a PR link as in libgomp.texi and a section in the manual).
Comments? Suggestions? If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #9 from Thomas Koenig ---
(In reply to Richard Earnshaw from comment #8)
> (In reply to Thomas Koenig from comment #7)
> > Would it make sense to document this somewhere? Or did I just miss it? :-)
>
> Possibly, but I've no idea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #3 from David Binderman ---
Reduced C code seems to be:
struct median_estimator {
long median;
long step
} median_diff_ts[];
median_estimator_update_data, median_estimator_update_diff,
median_estimator_update_median,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #2 from David Binderman ---
The bug first seems to appear sometime between g:93f803d53b5ccaab
and g:68f7cb6cf9e8b9f2, some 39 commits.
On Thu, Aug 24, 2023 at 11:39 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > In PR 106677, I noticed that on the trunk we were producing:
> > ```
> > _25 = SR.116_117 == 0;
> > _27 = (unsigned char) _25;
> > _32 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96109
--- Comment #14 from David Binderman ---
Sorry wrong bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96109
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
On Fri, 25 Aug 2023, Marek Polacek via Gcc-patches wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
LGTM
>
> -- >8 --
>
> This CWG clarifies that designated initializer support direct-initialization.
> Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? This
reduces calls to is_rvalue_constant_expression from
cp_parser_constant_expression by 10% for stdc++.h.
-- >8 --
As a follow-up to Marek's r14-3088-ga263152643bbec, this patch makes
us avoid passing an effectively dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
On Fri, Aug 25, 2023 at 12:33:31PM -0400, Patrick Palka via Gcc-patches wrote:
> Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
Very nice. LGTM.
> -- >8 --
>
> This replaces manual memory management via conversion_obstack_alloc(0)
> and obstack_free with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
--- Comment #1 from Martin Jambor ---
interestingly, the issue goes away with -flto-partition=one
It is triggered by propagating 0 as the last parameter of point.constprop.isra
which however looks correct, all four calls to the function (in
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This CWG clarifies that designated initializer support direct-initialization.
Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the
initialization is by designated-initializer-clause, its form determines
whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:6df8dcec7196e42ca2eed69e1ae455bae8d0fe93
commit r14-3485-g6df8dcec7196e42ca2eed69e1ae455bae8d0fe93
Author: Andrew Pinski
Date:
Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
This replaces manual memory management via conversion_obstack_alloc(0)
and obstack_free with the recently added conversion_obstack_sentinel,
and also uses the latter in build_user_type_conversion and
On Fri, 25 Aug 2023, FX Coudert via Gcc-patches wrote:
> Hi,
>
> Thanks Joseph for the review.
>
> > The driver changes are OK.
> >
> > I think the new configure options and the new -nodefaultrpaths compiler
> > option need documenting
>
> Doc patch was added, and okay’ed by Iain.
I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35095
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
Bug 33056 depends on bug 35095, which changed state.
Bug 35095 Summary: DATA with implied-do: Improve bounds checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35095
What|Removed |Added
This moves the pattern `(X & ~Y) | (~X & Y)` to use bitwise_inverted_equal_p
so we can simplify earlier the case where X and Y are defined by comparisons.
We were able to optimize to (!X)^(!Y) in the end due to the pattern added in
r14-3110-g7fb65f102851248bafa0815 and the older pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35095
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:4024ddbe50c2d1cb54c75304c72817d3fc63cdb6
commit r14-3484-g4024ddbe50c2d1cb54c75304c72817d3fc63cdb6
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|416.gamess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110341
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
I have a slightly modified gcc 3.2.3.
Source is available in gcc-stage* in custom.zip at http://pdos.org
Executables are available in customb.zip but everything that
is really needed is in pdos.zip
gccdos.txt has instructions to run windows.mak which
produces the gccx64.exe that I use, but has
Use the counted_by attribute information in bound sanitizer.
gcc/c-family/ChangeLog:
PR C/108896
* c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute
information.
gcc/testsuite/ChangeLog:
PR C/108896
*
Use the counted_by atribute info in builtin object size to compute the
subobject size for flexible array members.
gcc/ChangeLog:
PR C/108896
* tree-object-size.cc (addr_object_size): Use the counted_by
attribute info.
* tree.cc (component_ref_has_counted_by_p):
This is the 3rd version of the patch, per our discussion based on the
review comments for the 1st and 2nd version, the major changes in this
version are:
***Against 1st version:
1. change the name "element_count" to "counted_by";
2. change the parameter for the attribute from a STRING to an
Provide a new counted_by attribute to flexible array member field.
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
Bug ID: 57
Summary: 416.gamess fails with a run-time abort when compiled
with -O2 -flto after r14-3226-gd073e2d75d9ed4
Product: gcc
Version: 14.0
Status:
1 - 100 of 175 matches
Mail list logo
