https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112485
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gccadmin/2023q4/020594.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112485
--- Comment #1 from Andrew Pinski ---
Changelog generation is broken due to a commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112485
Bug ID: 112485
Summary: datestamp on -v recently broken ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Hi Dimitar,
On 2023/11/11 0:00, Dimitar Dimitrov wrote:
On Fri, Nov 10, 2023 at 04:53:57PM +0800, Lehua Ding wrote:
The divide by zero error above is interesting. I'm not sure why
ira_reg_class_max_nregs[] yields 0 for the pseudo register 168 in
the following rtx:
(debug_insn 168 167 169 19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105326
--- Comment #6 from Andrew Pinski ---
(In reply to Sam James from comment #5)
> (In reply to Keiya Nobuta from comment #4)
> > Thank you for the information.
> > Can it be suppressed by option?
>
> You can use the noipa function attribute and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92444
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105326
Sam James changed:
What|Removed |Added
Last reconfirmed||2023-11-12
Ever confirmed|0
Thanks Richard S and Jeff for comments.
> Did you want to use known_le so that you'd pick up the case when the two
> modes are the same size? Or was known_lt the test you really wanted
> (and if so, why).
Take known_lt in v2 due to consideration that leave the equal go to original
code path.
Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
access.
-- >8 --
Currently the first depset for an EK_BINDING is not seeded. This breaks
the attached testcase as then the namespace is not considered referenced
yet during streaming, but we've already finished importing.
The following has undefined behaviour (signed overflow) [1]:
weekday max{sys_days{days{numeric_limits::max()}}};
The issue is in this line when __n is very large and __n + 4 overflows:
return weekday(__n >= -4 ? (__n + 4) % 7 : (__n + 5) % 7 + 6);
In addition to fixing this bug, the new
Hi, Richard.
>> Maybe dead lanes are better tracked at the gimple level though, not sure.
>> (But AArch64 might need to lower lane operations more than it does now if
>> we want gimple to handle it.)
We were trying to address such issue at GIMPLE leve at the beginning.
Tracking subreg-lanes of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476
Xi Ruoyao changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
GCC internal says:
'subreg's of 'subreg's are not supported. Using
'simplify_gen_subreg' is the recommended way to avoid this problem.
Unfortunately loongarch_expand_vec_cond_mask_expr might create nested
subreg under certain circumstances, causing an ICE.
Use simplify_gen_subreg as
bad-mapper-1.C has been failing since the posix_spawn codepath was added
to libiberty, adjust the check to accept the changed error message.
Patch has been verified on x86_64 Linux.
gcc/testsuite:
* g++.dg/modules/bad-mapper-1.C: Also accept posix_spawn.
Signed-off-by: Brendan Shanks
The current implementation returns
(_M_y & (__is_multiple_of_100 ? 15 : 3)) == 0;
where __is_multiple_of_100 is calculated using an obfuscated algorithm which
saves one ror instruction when compared to _M_y % 100 == 0 [1].
In leap years calculation, it's correct to replace the divisibility
Snapshot gcc-13-2023 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-2023/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
exactl...@ispras.ru writes:
> From: Daniil Frolov
>
> PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
> violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
> OpenJade.
>
> The discussion in the PR was centered around extending MSan, but
Hi,
I like the idea of emitting Valgrind annotations. Instrumenting the
compiler /a little/ could make a very useful tool even more useful.
I have a minor remark, though (as someone not qualified to talk about
the middle-end bits of code), in the case that the annotation built-in
remains a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112484
Bug ID: 112484
Summary: [14 Regression]
26_numerics/random/{poisson_distribution,negative_bino
mial_distribution}/operators/values.cc fails on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #39 from John David Anglin ---
In the f-m-o pass, the following three insns that set call clobbered
registers r20-r22 are pulled from loop:
(insn 186 183 190 29 (set (reg/f:SI 22 %r22 [478])
(plus:SI (reg/f:SI 19 %r19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483
Bug ID: 112483
Summary: [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on
loongarch64-linux-gnu at -O1 or above
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
On 8/14/23 05:22, Jin Ma wrote:
CLOBBER and USE does not represent real instructions, but in the
process of pipeline optimization, they will wait for transmission
in ready list like other insns, without considering resource
conflicts and cycles. This results in a multi-issue CPU architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #37 from John David Anglin ---
(In reply to Sam James from comment #35)
> If you still need dumps off me, please let me know which. I've attached
> those w/ f-o-m on for the fold-mem-offsets pass. If you need others, just
> say.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #36 from John David Anglin ---
Created attachment 56562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56562=edit
fold_mem_offsets, prop_hardreg, rtl_dce and bbro dumps
Comment #33 is wrong. The issue is not reload. It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #35 from Sam James ---
If you still need dumps off me, please let me know which. I've attached those
w/ f-o-m on for the fold-mem-offsets pass. If you need others, just say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #34 from John David Anglin ---
Same wrong code is generated with x86-64 cross to hppa-linux-gnu. This it seems
this bug is not due to gcc being miscompiled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7610e5cc82bd6316cfe0bfee6d9f12d8c2cfa9c3
commit r14-5366-g7610e5cc82bd6316cfe0bfee6d9f12d8c2cfa9c3
Author: Jakub Jelinek
Date:
Hi Paul,
this is OK.
Thanks for the patch!
Harald
Am 11.11.23 um 11:15 schrieb Paul Richard Thomas:
Hi All,
Evidently -w causes gfc_option.allow_std to be set to default, which allows
anything and everything to happen, including these f2003/8 finalizations.
The fix is trivial.
Regtests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
On 6/11/23 21:38, Jin Ma wrote:
Why do you need a different cost based on what's in the ready list?
Isn't the only property we're looking for whether or not the USE/CLOBBER
opens a live range?
Jeff
For this, I found that if I only look for the USE/CLOBBER that opens a live
range,
when
On 11/11/23 05:11, Eric Botcazou wrote:
Hi,
IPA-CP can currently handle addresses of scalar constants (CONST_DECL) so this
extends that to addresses of constants in the pool (DECL_IN_CONSTANT_POOL).
Again this is helpful for so-called fat pointers in Ada, i.e. objects that are
semantically
@Pilar, this is the patch. Let me know if you need any help or have
questions. Thank you !
On Mon 3. Jul 2023 at 09:02, Gonzalo Brito Gadeschi <
gonzalo.gades...@gmail.com> wrote:
> libstdc++: Recognize C++ random access iterators as random access in PSTL
> [PR110432]
>
> The check for random
> On 11 Nov 2023, at 07:47, Simon Wright wrote:
>
> On 6 Nov 2023, at 08:36, Arnaud Charlet wrote:
>>
So without changing fundamentally the model, you can't decide dynamically
for the whole
system. Making the choice based on the current directory is pretty random,
Florian Weimer writes:
> * Eric Gallager:
>
>>> diff --git a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>>> b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>>> index bf32775d401..911fb562790 100644
>>> --- a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>>> +++
On 11/10/23 15:06, Florian Weimer wrote:
gcc/testsuite/
* gcc.c-torture/compile/20080613-1.c (hop_sendmsg): Call
__builtin_memcpy instead of memcpy.
* gcc.c-torture/compile/complex-6.c (bar): Declare.
* gcc.c-torture/compile/pr23445.c (__brelse): Declare.
On 11/10/23 15:06, Florian Weimer wrote:
These tests use obsolete language constructs, but they are not
clearly targeting C89, either. So use -fpermissive to keep
future errors as warnings.
The reasons why obsolete constructs are used used vary from
test to test. Some tests deliberately
On 11/10/23 17:22, Patrick O'Neill wrote:
On 11/10/23 03:00, Prathamesh Kulkarni wrote:
On Thu, 5 Oct 2023 at 00:00, Brendan Shanks wrote:
Hi,
This patch implements pex_unix_exec_child using posix_spawn when
available.
This should especially benefit recent macOS (where vfork just calls
On 11/10/23 18:02, Keith Packard wrote:
I'm largely trusting your reputation on the fpgnulib changes. I won't
claim to know that code at all. The assembly bits were simple enough
that I could make out what you were doing relatively easily.
Thanks for that review -- m68k assembly isn't
On 6 Nov 2023, at 08:36, Arnaud Charlet wrote:
>
>>> So without changing fundamentally the model, you can't decide dynamically
>>> for the whole
>>> system. Making the choice based on the current directory is pretty random,
>>> since the current
>>> directory isn't well defined at program's
On 11/11/23 08:33, Richard Sandiford wrote:
Joern's code is a bit of a mess, but Jivan and I are slowly untangling
it from a correctness standpoint. It'll also need the usual cleanups.
Ah, nice! How configurable are the bit ranges? We might be able to use
something similar to track
* Eric Gallager:
>> diff --git a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> index bf32775d401..911fb562790 100644
>> --- a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> +++ b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>>
Jeff Law writes:
> On 11/11/23 08:54, Richard Sandiford wrote:
>> Jeff Law writes:
>>> On 11/5/23 11:50, Richard Sandiford wrote:
The mode-switching pass assumed that all of an entity's modes
were mutually exclusive. However, the upcoming SME changes
have an entity with some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #5 from Mikael Pettersson ---
Created attachment 56561
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56561=edit
proposed fix, only compile-tested for now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112478
--- Comment #3 from Michael T. Kloos ---
Created attachment 56560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56560=edit
Sample program to reproduce the bug
I have created and attached a small simple program which shows the bug.
If
Thanks for the patch.
Manos Anagnostakis writes:
> This is an RTL pass that detects store forwarding from stores to larger loads
> (load pairs).
>
> This optimization is SPEC2017-driven and was found to be beneficial for some
> benchmarks,
> through testing on ampere1/ampere1a machines.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476
Xi Ruoyao changed:
What|Removed |Added
Component|rtl-optimization|target
Status|NEW
When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
that the operation "& 1" wasn't necessary but we did not patch it at that
time. This patch removes the unnecessary operation.
libstdc++-v3/ChangeLog:
* include/std/chrono: Remove &1 from
On 11/11/23 08:54, Richard Sandiford wrote:
Jeff Law writes:
On 11/5/23 11:50, Richard Sandiford wrote:
The mode-switching pass assumed that all of an entity's modes
were mutually exclusive. However, the upcoming SME changes
have an entity with some overlapping modes, so that there is
On 11/11/23 08:51, Richard Sandiford wrote:
Jeff Law writes:
On 11/7/23 17:35, Richard Sandiford wrote:
I could have sworn that there was something that checked that passes
left edge aux fields clear, but it looks like I misremembered. So I
probably need to stick a clear_aux_for_edges ()
Jeff Law writes:
> On 11/5/23 11:50, Richard Sandiford wrote:
>> The mode-switching pass assumed that all of an entity's modes
>> were mutually exclusive. However, the upcoming SME changes
>> have an entity with some overlapping modes, so that there is
>> sometimes a "superunion" mode that
When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
that the operation "& 1" wasn't necessary but we did not patch it at that
time. This patch removes the unnecessary operation.
libstdc++-v3/ChangeLog:
* include/std/chrono: Remove &1 from year_month_day_last::day().
Jeff Law writes:
> On 11/7/23 17:35, Richard Sandiford wrote:
>
>> I could have sworn that there was something that checked that passes
>> left edge aux fields clear, but it looks like I misremembered. So I
>> probably need to stick a clear_aux_for_edges () call above the first
>> main loop (for
Jeff Law writes:
> On 11/8/23 02:40, Richard Sandiford wrote:
>> Lehua Ding writes:
>>> Hi,
>>>
>>> These patchs try to support subreg coalesce feature in
>>> register allocation passes (ira and lra).
>>
>> Thanks a lot for the series. This is definitely something we've
>> needed for a while.
Jeff Law writes:
> On 11/8/23 23:08, pan2...@intel.com wrote:
>> From: Pan Li
>>
>> Update in v2:
>> * Move vector type support to get_stored_val.
>>
>> Original log:
>>
>> This patch would like to allow the vector mode in the
>> get_stored_val in the DSE. It is valid for the read
>> rtx if
Hi!
On 2023-11-08T13:01:47-0300, Alexandre Oliva wrote:
> These gimplefe tests never got the desired optimization on ia32, but
> they only started visibly failing when the representation of MEMs in
> dumps changed from printing 'symbol: a' to ''.
ACK -- but why not likewise "fix" the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111671
--- Comment #3 from Shaohua Li ---
Yes, I cannot reproduce it anymore. Any idea about which commit fixed it?
> Am 11.11.2023 um 09:27 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase ICEs, because the temp_stmts were removed in
> wrong order, from the ones appearing earlier in the IL to the later ones,
> so insert_debug_temps_for_defs can reintroduce dead SSA_NAMEs back into the
> IL.
>
On Fri, Nov 10, 2023 at 5:06 PM Florian Weimer wrote:
>
> These tests use obsolete language constructs, but they are not
> clearly targeting C89, either. So use -fpermissive to keep
> future errors as warnings.
>
> The reasons why obsolete constructs are used used vary from
> test to test. Some
Hi,
IPA-CP can currently handle addresses of scalar constants (CONST_DECL) so this
extends that to addresses of constants in the pool (DECL_IN_CONSTANT_POOL).
Again this is helpful for so-called fat pointers in Ada, i.e. objects that are
semantically pointers but represented by structures made
* Jeff Law:
> OK. Spot checked. It looked like -fpermissive was added for some as
> well, which is fine by me. Perhaps "Compile with -std=gnu89 and
> possibly -fpermissive as needed" or something similar in the
> ChangeLog.
There was one test that had -std=gnu89 -fpermissive. But
Just a quick addition here as I was starting to work on things I
realized where some misunderstandings were coming from. (Please also
see my previous e-mail, it is all still relevant, I just wanted to
clarify this.)
(From the other thread)
> > @@ -9949,7 +9951,8 @@ build_over_call (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476
Xi Ruoyao changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
--- Comment
fld and fst have same address mode as ld.w and st.w, so the same
optimization as r14-4851 should be applied for them too.
gcc/ChangeLog:
* config/loongarch/loongarch.md (LD_AT_LEAST_32_BIT): New mode
iterator.
(ST_ANY): New mode iterator.
(define_peephole2): Use
> [combined reply to all three threads]
>
> On 11/9/23 23:24, waffl3x wrote:
>
> > > > I'm unfortunately going down a rabbit hole again.
> > > >
> > > > --function.h:608
> > > > `/* If pointers to member functions use the least significant bit to
> > > > indicate whether a function is virtual,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2023-11-11
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459
--- Comment #3 from Paul Thomas ---
Hi Sebastien,
I have posted the patch to the gfortran list. Hopefully, the bug will be fixed
this weekend.
Thanks for the report.
Paul
Hi All,
Evidently -w causes gfc_option.allow_std to be set to default, which allows
anything and everything to happen, including these f2003/8 finalizations.
The fix is trivial.
Regtests fine - OK for mainline and -13 branch?
Paul
Fortran: Prevent unwanted finalization with -w option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
Bug 95507 depends on bug 112428, which changed state.
Bug 112428 Summary: Wnonnull outputs wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:c58b426d64ac2513dc0ed19165740604e891e9df
commit r14-5353-gc58b426d64ac2513dc0ed19165740604e891e9df
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428
--- Comment #1 from CVS Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:c58b426d64ac2513dc0ed19165740604e891e9df
commit r14-5353-gc58b426d64ac2513dc0ed19165740604e891e9df
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
Alexander Monakov changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110043
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
Hi!
The following testcase ICEs when dumping details.
When m_ssa_ranges vector is created, it is safe_grow_cleared (num_ssa_names),
but when when some new SSA_NAME is added, we strangely grow it to
num_ssa_names + 1 instead and later on the 3 argument dump method
iterates from 1 to
Hi!
The following testcase ICEs, because the temp_stmts were removed in
wrong order, from the ones appearing earlier in the IL to the later ones,
so insert_debug_temps_for_defs can reintroduce dead SSA_NAMEs back into the
IL.
The following patch fixes that by removing them in the order they were
Hi!
While filing a clang request to return 18 on _BitInts for
__builtin_classify_type instead of -1 they return currently, I've
noticed that we return -1 for vector types. I'm not convinced it is a good
idea to change behavior of __builtin_classify_type (vector_expression)
after 22 years it
On Fri, Nov 10, 2023 at 10:44:12AM +0100, Jakub Jelinek wrote:
> Because the builtins are just something matching in behavior to existing
> builtins which can be used for those macros, not exact implementation of
> those.
BTW, the new builtins also allow implementation of generic signed_type_for
82 matches
Mail list logo
