https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111030
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #42 from Mikael Morin ---
(In reply to anlauf from comment #41)
> (In reply to Mikael Morin from comment #40)
> > Harald, I have just closed the followup PR110419.
> > I think this PR can be closed as well, or is there something left
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111035
Bug ID: 111035
Summary: Getting warning array subscript 0 is outside array
bounds
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111036
Bug ID: 111036
Summary: Code generation error in handling __builtin_constant_p
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111035
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
--- Comment #7 from Jens Seifert ---
What happened ? Still waiting for improvement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655
--- Comment #6 from Jonathan Wakely ---
Does it silently ignore the x and open in non-exclusive mode, or does it give
an error?
Giving an error is fine, it just means noreplace can't be used on those
systems.
Silently ignoring the x and openin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108305
--- Comment #7 from Jonathan Wakely ---
I think we need to make __cpp_lib_ios_noreplace depend on some new macro that
is undefined by default, and defined manually in os_defines.h when we know it
works.
The won't work for musl though, as it use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111017
Tobias Burnus changed:
What|Removed |Added
Known to work||11.4.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111017
--- Comment #2 from Tobias Burnus ---
Bisecting points at:
r12-5295-g47de0b56ee455ec82ec7d61a20988f11b67aa4e9
openmp: Regimplify operands of GIMPLE_COND in a few more places [PR103208]
Date: Tue Nov 16 10:19:22 2021 +0100
which fixed an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111017
--- Comment #3 from Tobias Burnus ---
Looking at the dump, the only relevant change seems to be
.count.5 = 0;
which is now in a different basic block.
In the working case, it comes in a basic block executed shortly after the bb
containing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111017
--- Comment #4 from Tobias Burnus ---
I tried the following - without understanding the code.
But I looked at what the failing commit changes (GSI_SAME_STMT instead of
GSI_CONTINUE_LINKING for the 'factor' case). The latter is used again (only
Hi there,
We are excited to offer you a comprehensive email list of school districts that
includes key contact information such as phone numbers, email addresses,
mailing addresses, company revenue, size, and web addresses. Our databases also
cover related industries such as:
* K-12 schools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111024
--- Comment #1 from Tobias Burnus ---
Created attachment 55742
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55742&action=edit
libgomp/allocator.c's gomp_init_libnuma - call numa_available()
Given that (lib)memkind uses jemalloc - on Bio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037
Bug ID: 111037
Summary: RISC-V: Invalid vsetvli fusion
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111015
--- Comment #4 from Mikael Pettersson ---
Reverting the pass_store_merging::process_store hunk makes this test case work
again:
diff --git a/gcc/gimple-ssa-store-merging.cc b/gcc/gimple-ssa-store-merging.cc
index 0d19b98ed73..c4bf8eec64e 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101602
--- Comment #4 from Marshall Ward ---
Thank you Michael, that is very informative, particularly with respect to
LOCAL_INIT vs FIRSTPRIVATE. If we could just get support for LOCAL, then we
may be to start using do-concurrent in our production co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
--- Comment #5 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:b3cfa47d385c004bfbf1772c41e255e8eb60377e
commit r13-7729-gb3cfa47d385c004bfbf1772c41e255e8eb60377e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110254
--- Comment #3 from CVS Commits ---
The master branch has been updated by Surya Kumari Jangala
:
https://gcc.gnu.org/g:02ecc9a26324d142c5cd19d24526b9c23aabc1c3
commit r14-3251-g02ecc9a26324d142c5cd19d24526b9c23aabc1c3
Author: Surya Kumari Jang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111038
Bug ID: 111038
Summary: The function summary in gcov
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #3 from waffl3x ---
I have some elements working so far, I opted to implement parsing for `this` in
cp_parser_parameter_declaration instead of in cp_parser_decl_specifier_seq
because I didn't want to add another member to cp_decl_spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #4 from Gašper Ažman ---
As one of the authors, I can assure you you never need to implement this for
c++23.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #5 from Gašper Ažman ---
And of course by "this" I meant support for a default argument on the explicit
object parameter.
We might add it back in the future if we find a usecase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942
--- Comment #1 from Andrew Macleod ---
Created attachment 55743
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55743&action=edit
patch to revert the change
Although the bisection stopped at this change, it does not appear to be the
underl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110426
--- Comment #4 from Alex Henrie ---
I tried out your changes and the warnings look great now. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039
Bug ID: 111039
Summary: Unable to coalesce ssa_names
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-08-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111040
Bug ID: 111040
Summary: __builtin_object_size: inconsistent result for
subobject with member arrays.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111041
Bug ID: 111041
Summary: Malformed requires syntax should produce better
diagnostics
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111041
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #43 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:9ade70bb86c8744f4416a48bb69cf4705f00905a
commit r14-3254-g9ade70bb86c8744f4416a48bb69cf4705f00905a
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039
--- Comment #2 from Andrew Pinski ---
# flags_1(ab) = PHI
_setjmp (flags_1(ab));
_14 = flags_6(D)(ab) & 9437184;
The use of _6 is the issue here.
The problem shows up in ifcombine pass:
optimizing double bit test to flags_6(D)(ab) & T =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942
--- Comment #3 from Andrew Macleod ---
The original revision listed, I narrowed down to a single instance where the
new code did something that makes a difference
we determine that in stmt
stmt _8 = (int) i_10;
which originally had a range of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039
--- Comment #3 from Andrew Pinski ---
I suspect the issue is recognize_single_bit_test does not check
SSA_NAME_OCCURS_IN_ABNORMAL_PHI at all ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111040
--- Comment #1 from qinzhao at gcc dot gnu.org ---
an initial study inside gdb shows the following:
1. the guilty pass is "ccp1", when folding the call to
__builtin_dynamic_object_size(p->array, 1)
2. In this pass, the IR for p->array is represe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #5 from Sergei Trofimovich ---
For what it's worth bisect pointed at r12-4871-g502ffb1f389011
$ git bisect good
502ffb1f389011b28ee51815242c7397790802d5 is the first bad commit
commit 502ffb1f389011b28ee51815242c7397790802d5
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111042
Bug ID: 111042
Summary: [OpenMP] 'allocate' clause and combined directive -
impove diagnostic, ICE because of missing diagnostic
Product: gcc
Version: 14.0
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #6 from Sam James ---
Can you bisect further back with -param=vrp2-mode=ranger, to force ranger
before it was the default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111043
Bug ID: 111043
Summary: ICE in adjust_loop_info_after_peeling, at
tree-ssa-loop-ivcanon.cc:1068
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #7 from Sergei Trofimovich ---
commit bd400db6d3ec167142ace352db00f84d382e33a8 (HEAD)
Date: Fri Oct 15 12:06:27 2021 -0400
Add --param=vrp1-mode and --param=vrp2-mode.
(the first commit that adds the option) generates SIGSEGVs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111043
Andrew Pinski changed:
What|Removed |Added
Summary|ICE in |[14 regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #8 from Andrew Macleod ---
Do I need some special target or something? on trunk just
"-fno-strict-overflow -O3" doesnt fail for me on x86_64-pc-linux-gnu...
./cc1 -fno-strict-overflow -O3 009.c -quiet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #9 from Sergei Trofimovich ---
Created attachment 55744
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55744&action=edit
bug.S
At the hazard of stating the obvious: it's a wrong-code when you execute it
(not a gcc ICE).
Shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #6 from waffl3x ---
I've noticed the standard does call `this` a specifier, I will perhaps rework
the code to just do parsing in cp_decl_specifier_seq.
(In reply to Gašper Ažman from comment #5)
> And of course by "this" I meant sup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037
--- Comment #1 from JuzheZhong ---
confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027
--- Comment #2 from Andrew Pinski ---
This might fix the issue:
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index a00dad965c5..267f6258ee3 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3686,6 +3686,7 @@ install: install-common $(INST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111036
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111036
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986
--- Comment #18 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:a32de58c9e6394e4e6aef0ac95b52d1c774ac8bc
commit r14-3257-ga32de58c9e6394e4e6aef0ac95b52d1c774ac8bc
Author: Andrew Pinski
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002
--- Comment #3 from Thorsten Otto ---
Created attachment 55745
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55745&action=edit
Possible workaround
I currently use the attached patch to work around this. However it is a bit
hackish as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110429
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
HaoChen Gui changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111038
--- Comment #1 from Gejoe ---
The document referred was this:
https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html
Kindly respond to my query.
Eagerly awaited. :)
Thank you very much team for the support !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #18 from Julian Waters ---
That's great news! With regards to this patch, I'm fairly certain you have to
proactively send it to gcc-patches mailing list for it to be merged; No gcc
committer has the time to look for this issue and com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037
--- Comment #2 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:29547511f7bae06f9f424f8c8583014878240016
commit r14-3265-g29547511f7bae06f9f424f8c8583014878240016
Author: Juzhe-Zhong
Date: Thu Aug 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111028
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023
--- Comment #2 from Richard Biener ---
Huh, that escaped me. I'll have to go back and compare where it derails
compared to aarch64 with neon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021
--- Comment #6 from Martin Uecker ---
Note that I do not propose to add variably modified types to C++. This would
indeed be a major extension. I simply propose to ignore the size expressions
in C headers as a usability improvement. My patch
64 matches
Mail list logo
