This patchset contains the gimple interface.
--8<--8<--8<--8<--8<--8<
diff -ruw /dev/null gcc-git-devel-modula2/gcc/m2/gm2-gcc/m2assert.cc
--- /dev/null 2022-08-24 16:22:16.88870 +0100
+++ gcc-git-devel-modula2/gcc/m2/gm2-gcc/m2assert.cc
This patchset contains the gimple interface.
--8<--8<--8<--8<--8<--8<
diff -ruw /dev/null gcc-git-devel-modula2/gcc/m2/gm2-gcc/init.cc
--- /dev/null 2022-08-24 16:22:16.88870 +0100
+++ gcc-git-devel-modula2/gcc/m2/gm2-gcc/init.cc2
Hi!
On Tue, Nov 01, 2022 at 10:39:04PM -0400, Michael Meissner wrote:
> The basic issue is internally within GCC there are several types for 128-bit
> floating point. The types are:
>
> 1)The long double type (TFmode or possibly DFmode).
Please be very careful to call types types an
On Tue, Dec 06, 2022 at 08:56:09AM -0600, Segher Boessenkool wrote:
> > In the past, _Float128 was a C extended type,
> > but now it is a part of the C/C++ 2x standards.
>
> Only if you select a new enough -std=, it still is an extended type if
> not?
No, as an extension _Float{16,32,64,1
Prathamesh Kulkarni via Gcc-patches writes:
> On Fri, 4 Nov 2022 at 14:00, Prathamesh Kulkarni
> wrote:
>>
>> On Mon, 31 Oct 2022 at 15:27, Richard Sandiford
>> wrote:
>> >
>> > Prathamesh Kulkarni writes:
>> > > On Wed, 26 Oct 2022 at 21:07, Richard Sandiford
>> > > wrote:
>> > >>
>> > >> Sor
Hi Richard,
thanks for reviewing.
Just one clarification before I complete the respin of this patch.
Richard Earnshaw writes:
[...]
> Also, I think (out of an abundance of caution) we really need a
> scheduling barrier placed before calls to gen_aut_nop() pattern is
> emitted, to ensure that
Tamar Christina via Gcc-patches writes:
> Hi All,
>
> The target has various zero and sign extension patterns. These however live
> in
> various locations around the MD file and almost all of them are split
> differently. Due to the various patterns we also ended up missing valid
> extensions.
Hi, this is the 3rd version of the patch.
Per Richard's request, I split the patch into two seperate patches:
1. Update -Warray-bounds with -fstrict-flex-arrays.
2. Add a new warning option -Wstrict-flex-arrays.
I have bootstrapped and regression tested on both X86 and aarch64
without any issu
A. add the following to clarify the relationship between -Warray-bounds
and the LEVEL of -fstrict-flex-array:
By default, the trailing array of a structure will be treated as a
flexible array member by '-Warray-bounds' or '-Warray-bounds=N' if
it is declared as either a
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field of a structure if it's available,
otherwise according to the LEVEL of the option
'-fstrict-fl
Sorry, Please ignore this email.
Qing
> On Dec 6, 2022, at 11:14 AM, Qing Zhao wrote:
>
> '-Wstrict-flex-arrays'
> Warn about inproper usages of flexible array members according to
> the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
> the trailing array field of a s
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field of a structure if it's available,
otherwise according to the LEVEL of the option
'-fstrict-fl
On Tue, 6 Dec 2022, Qing Zhao wrote:
> A. add the following to clarify the relationship between -Warray-bounds
> and the LEVEL of -fstrict-flex-array:
>
> By default, the trailing array of a structure will be treated as a
> flexible array member by '-Warray-bounds' or '-War
On 06/12/2022 15:46, Andrea Corallo wrote:
Hi Richard,
thanks for reviewing.
Just one clarification before I complete the respin of this patch.
Richard Earnshaw writes:
[...]
Also, I think (out of an abundance of caution) we really need a
scheduling barrier placed before calls to gen_au
Richard Earnshaw writes:
> On 06/12/2022 15:46, Andrea Corallo wrote:
>> Hi Richard,
>> thanks for reviewing.
>> Just one clarification before I complete the respin of this patch.
>> Richard Earnshaw writes:
>> [...]
>>
>>> Also, I think (out of an abundance of caution) we really need a
>>> sch
This patch fixes some issues with substitution into a C++20 template
parameter object wrapper:
* The first testcase demonstrates a situation where the same_type_p
assert in relevant case of tsubst_copy doesn't hold, because (partial)
substitution of {int,} into the VIEW_CONVERT_EXPR wrapper yi
On 31/10/2022 15:36, Srinath Parvathaneni via Gcc-patches wrote:
Hi,
This patch adds the support for pacbti multlilib linking by making
"-mbranch-protection=none" as default in the command line for all M-profile
targets and uses "-mbranch-protection=none" for multilib matching. If any
valid v
Hello,
I'm happy to give you a current report on the email participant database for
"DISTRIBUTECH International 2023".
Delegates are:
* Transmission grid owner / operator
* Distribution grid owner / operator
* Energy service provider
* Publicly owned
* Municipal
* IOU / Co
On Tue, 6 Dec 2022, Patrick Palka wrote:
> This patch fixes some issues with substitution into a C++20 template
> parameter object wrapper:
>
> * The first testcase demonstrates a situation where the same_type_p
> assert in relevant case of tsubst_copy doesn't hold, because (partial)
> substi
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4517-g861c917a972dc9.
gcc/ChangeLog:
* Makefile.in (ANALYZER_OBJS): Add analyzer/call-details.o,
analyzer/kf-analyzer.o, and kf-lang-cp.o.
gcc/analyzer/ChangeLog:
* analyzer.h (register_k
Lightly tested with doxygen; with this patch it generates docs for the
analyzer internals (e.g. class hierarchies).
Pushed to trunk as r13-4519-gfa19bfbb0a1995.
contrib/ChangeLog:
* gcc.doxy (INPUT): Add gcc/analyzer subdirectory.
Signed-off-by: David Malcolm
---
contrib/gcc.doxy | 2 +
Successfully built on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4518-g14b0d6c4bd973c.
gcc/ChangeLog:
* doc/analyzer.texi: Drop out-of-date ideas for other checkers.
Signed-off-by: David Malcolm
---
gcc/doc/analyzer.texi | 10 --
1 file changed, 10 deletions(-)
diff --git a/gc
PR analyzer/106325 reports false postives from
-Wanalyzer-null-dereference on code like this:
__attribute__((nonnull))
void foo_a (Foo *p)
{
foo_b (p);
switch (p->type)
{
/* ... */
}
}
where foo_b (p) has a:
g_return_if_fail (p);
that expands to:
if (!p)
{
retu
On 12/5/22 19:35, Jakub Jelinek via Gcc-patches wrote:
Hi!
According to
https://gcc.gnu.org/pipermail/gcc-regression/2022-December/077258.html
Seen in the wild too - compiling one of the two weather forecasting
programs I use:
during GIMPLE pass: dom
/home/toon/scratch/hm_home/my_CY46h1/l
Version 4 contains two missed feedback suggestions (namespace in
m2pp.cc) and use build_nonstandard_integer_type in
gm2-lang.cc:gm2_type_for_size.
This patch set contains the .h, .cc and .flex files found in
gcc/m2. The files are tightly coupled with the gimple interface
(see 04-gimple-interfac
From: Björn Schäpers
It's the right thing to do, since the PC shouldn't go out of the
uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t.
This is a preparation for a following patch.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* dwarf.c: changed variables holding p
From: Björn Schäpers
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the backtrace_initialize are not handled.
But as far as I can see that's the same for elf.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* pecoff.c (coff_add)
From: Björn Schäpers
Any underflow which might happen, will be countered by an overflow in
dwarf.c.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/89 and
https://github.com/ianlancetaylor/libbacktrace/issues/82.
* peco
From: Björn Schäpers
This is actually needed so that libstdc++'s implementation
to be able to work on windows.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* configure.ac: Add a check for windows.h.
* configure, config.h.in: Regenerate.
* fileline.c: Add windo
Hi!
I suppose I just fail to see some detail here, but:
On 2022-11-21T08:25:25+0100, Sebastian Huber
wrote:
> gcc/ChangeLog:
>
> * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
> (cc1_spec): Append SUBTARGET_CC1_SPEC.
> ---
> v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec
The 12/06/2022 11:58, Wilco Dijkstra wrote:
> > i don't think how[*RA_STATE] can ever be set to REG_SAVED_OFFSET,
> > this pseudo reg is not spilled to the stack, it is reset to 0 in
> > each frame and then toggled within a frame.
>
> It's is just a state, we can use any state we want since it is
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Fix digit grouping for integers formatted with "{:#Lx}" which were
including the "0x" prefix in the grouped digits. This resulted in output
like "0,xff,fff" instead of "0xff,fff".
Also change std:::basic_format_parse_context to not throw for an arg-
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/std_mutex.h (mutex): Add nodiscard attribute to
try_lock member function.
* include/bits/unique_lock.h (unique_lock): Likewise for
try_lock, try_lock_until, try_lock_for member f
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The PR shows a bogus warning where jump threading generates code for the
undefined case that the insertion point is a value-initialized iterator
but _M_finish and _M_end_of_storage are unequal (so at least one must be
non-null). Using __builtin_unrea
I've pushed this to trunk. Tested x86_64-linux.
On Mon, 21 Nov 2022 at 20:44, Jonathan Wakely via Libstdc++
wrote:
>
> While finishing the time zone support for C++20, I noticed that the
> chrono::hh_mm_ss type is surprisingly large: 40 bytes. That's because
> we use duration for each of the four
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/107871
* include/std/format (_Iter_sink::_M_overflow): Add cast to
size_t.
(_Iter_sink::_M_make_span): Use
typedef instead of decltype.
* testsuite/std/format/funct
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This test was recently modified to check that the library doesn't use
__unused anywhere, because that's a macro in newlib. But it's also a
macro in old versions of glibc, so the test now fails for those targets.
Disable that check for those targets a
On Wed, 30 Nov 2022 at 18:00, François Dumont wrote:
>
> On 30/11/22 14:07, Jonathan Wakely wrote:
> > On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
> >>
> >>
> >> On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
> >>>
> >>>
> >>> On Wed, 30 Nov 2022 at 06:04, François Dumont via Libs
PR analyzer/107882 reports an ICE, due to trying to get a compound svalue
for this binding:
cluster for: a:
key: {bytes 0-3}
value: {UNKNOWN()}
key: {empty}
value: {UNKNOWN()}
key: {bytes 4-7}
value: {UNKNOWN()}
where there's an binding to the unknown value of z
Thanks Richard for your review and for pointing out the issue with BTI.
The current patch removes the existing BTI instruction,
and then adds the BTI hint when expanding the patchable_area pseudo.
The attached patch passed bootstrap and regression test on arm64-linux.
Ok to commit to gcc trun
I initially ran into this while reviving autoprofiledbootstrap build.
I was able to create a simple reliable test for this bug and captured it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000
I also included the test case in the updated patch below.
Eugene
===
gcc/ChangeLog:
* doc/rtl.texi: Correct a clerical error in the document.
---
gcc/doc/rtl.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index 43c9ee8bffe..44858d12892 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -214
Hi,
In the recent discussion on how to make some built-in type only valid for
some target features efficiently[1], Andrew mentioned this patch which he
made previously (Thanks!). I confirmed it can help rs6000 related issue,
and noticed PR99657 is still opened, so I think we still want this to
be
Hi Haochen,
on 2022/12/6 13:44, HAO CHEN GUI wrote:
> Hi,
> This patch enables "have_cbranchcc4" on rs6000 by defining
> a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc
> to indicate if branch by CC bits is invalid or not. With this
> flag enabled, some branches can be optimized
Hi,
This patch adds a new conversion to convert a certain branch to
conditional ternary set in ifcvt.
The branch commonly has following insns.
cond_jump ? pc : label
setcc
(neg/subreg)
label: set a constant
cond_jump and setcc use the same CC reg and neg/subreg is optional.
The br
Hi Kewen,
Thanks so much for your review comments. I will fix them.
在 2022/12/7 11:06, Kewen.Lin 写道:
> Does this issue which relies on the fix for generic part make bootstrapping
> fail?
> If no, how many failures it can cause? I'm thinking if we can commit this
> firstly,
> then in the commi
on 2022/12/7 13:24, HAO CHEN GUI wrote:
> Hi Kewen,
> Thanks so much for your review comments. I will fix them.
>
> 在 2022/12/7 11:06, Kewen.Lin 写道:
>> Does this issue which relies on the fix for generic part make bootstrapping
>> fail?
>> If no, how many failures it can cause? I'm thinking if
On 06.12.22 22:06, Thomas Schwinge wrote:
Hi!
I suppose I just fail to see some detail here, but:
On 2022-11-21T08:25:25+0100, Sebastian
Huber wrote:
gcc/ChangeLog:
* gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
(cc1_spec): Append SUBTARGET_CC1_SPEC.
---
v2: Append SUBT
For Alderlake there is similar issue like PR 81616, enable
avoid_fma256_chain will also benefit on Intel latest platforms
Alderlake and Sapphire Rapids.
Bootstrapped/regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for master?
gcc/ChangeLog:
* config/i386/x86-tune.def (X86_TUNE_AVOID_256FMA_
On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> Thanks for fixing this!
>
> Could you help to elaborate why we need to disable it during libgcc building?
When you are building libgcc, you are building the __mulkc3, __divkc3
functions. The mapping in the compiler interf
On Wed, Dec 7, 2022 at 7:36 AM Hongyu Wang wrote:
>
> For Alderlake there is similar issue like PR 81616, enable
> avoid_fma256_chain will also benefit on Intel latest platforms
> Alderlake and Sapphire Rapids.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu{-m32,}.
>
> Ok for master?
>
> gcc/Ch
Hi!
On 2022-12-07T07:04:10+0100, Sebastian Huber
wrote:
> On 06.12.22 22:06, Thomas Schwinge wrote:
> I suppose I just fail to see some detail here, but:
>
>> On 2022-11-21T08:25:25+0100, Sebastian
>> Huber wrote:
>>> gcc/ChangeLog:
>>>
>>>* gcc.cc (SUBTARGET_CC1_SPEC): Define if not d
On 07.12.22 08:10, Thomas Schwinge wrote:
Hi!
On 2022-12-07T07:04:10+0100, Sebastian Huber
wrote:
On 06.12.22 22:06, Thomas Schwinge wrote:
I suppose I just fail to see some detail here, but:
On 2022-11-21T08:25:25+0100, Sebastian
Huber wrote:
gcc/ChangeLog:
* gcc.cc (SUBTARG
Hi Mike,
on 2022/12/7 14:44, Michael Meissner wrote:
> On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
>> Hi Mike,
>>
>> Thanks for fixing this!
>>
>> Could you help to elaborate why we need to disable it during libgcc building?
>
> When you are building libgcc, you are building the __
101 - 154 of 154 matches
Mail list logo
