On 03.08.2025 17:18, Jeff Law wrote:
[...]
Mine tests:
--target_board=h8300-sim\{-mh/-mint32,-ms/-mint32,-msx/-mint32\}
In simpler terms it'll test -mh, -ms -msx, each with -mint32.
Not sure what yours is testing, but additional coverage is useful.
I also run tests on simulator, usually with
b;
a.a=0;
b.a=1;
return f((B*)&a, (B*)&b);
}
is undefined behaviour, even if (in the current implementation of operator==)
it nevers read out of bounds.
From: Jakub Jelinek
Sent: 07 August 2025 18:32:11
To: Thomas de Bock
Cc: Richard Biener; gcc@g
On Thu, Aug 07, 2025 at 03:25:45PM +, Thomas de Bock wrote:
> "I see what you mean, I think there is probably no way to apply the
> optimization to all functions then indeed, since there is no way to
> know if the early break on inequality of a field was arbitrary
> or because it indicates the
both objects against each other until one subobject is not equal to
the other."
But I don't see anything regarding when the memory should be loaded.
Either way, I think the effect this issue has on run-time does
demand a way to, at the very least, have a way of applying
this (possibly th
On Thu, Aug 7, 2025 at 7:18 AM Florian Weimer via Gcc wrote:
>
> * Thomas de Bock via Gcc:
>
> > Sorry for my wording, that is not the only thing memcmp gives us, but it
> > does not give us information regarding which fields mismatched. So we cannot
> > deal with (after !='s are converted to =='s
On Thu, Aug 07, 2025 at 09:37:24AM +, Thomas de Bock wrote:
> Why does that it not matter that the destination of all the chain blocks'
> FALSE edge is the same, if we have:
> :
> _1 = this_13(D)->a;
> _2 = _14(D)->a;
> if (_1 == _2)
> goto ; [INV]
> else
> goto ; [INV]
> :
> _3 = this_13
* Thomas de Bock via Gcc:
> Sorry for my wording, that is not the only thing memcmp gives us, but it
> does not give us information regarding which fields mismatched. So we cannot
> deal with (after !='s are converted to =='s) blocks where not all blocks in
> a chain have the same node as their (e
tfields, for ==/!= all that matters is that
> all bits are compared and the block starts and ends at a byte boundary.
> For <=> it needs the right ordering and for non-unsigned char accesses
> little endian.
Oh interesting I haven't encountered them being swapped yet so I didn't
really conside
On Wed, Aug 06, 2025 at 01:32:07PM +, Thomas de Bock wrote:
> Apologies if I was unclear or misunderstand, I believe that's exactly what I
> am
> doing right now. I change the !='s' to =='s' and switch their true with their
> false
> edge, from there we can simply find the equality edge by fi
d & e & f & g & h cases, but
> expansion of the && on some targets is e.g. one expression per bb or two
> expressions per bb.
> I'd really suggest you look through what that code does because this
> pattern recognition is similar (but not the same).
> Also note that even in the PHI case
On Wed, Aug 06, 2025 at 12:29:09PM +, Thomas de Bock wrote:
> I've looked at the pattern LLVM recognizes and there is indeed a lot of
> different
> ways we could recognize the chains and generalize the optimization.
> The way I do the pattern recognition now is by changing the conditions to ==
ruct?
For -O2:
bool __attribute__((noinline))
f(std::array* x, std::array* y) {
return *x == *y;
}
int main() {
std::array* a;
std::array* b;
a = (std::array*)malloc(sizeof(std::array));
b = (std::array*)malloc(sizeof(std::array));
return f(a, b);
}
Also generates a memcmp call which r
On Wed, Aug 6, 2025 at 9:40 AM Jakub Jelinek wrote:
>
> On Wed, Aug 06, 2025 at 08:48:55AM +0200, Richard Biener via Gcc wrote:
> > For loops the canonical place to perform such optimization is the loop
> > distribution pass which already recognizes
> > memcpy but also strlen (strcmp is more like
On Wed, Aug 06, 2025 at 08:48:55AM +0200, Richard Biener via Gcc wrote:
> For loops the canonical place to perform such optimization is the loop
> distribution pass which already recognizes
> memcpy but also strlen (strcmp is more like strlen).
>
> For straight-line code there's also a bugreport a
On Tue, Aug 5, 2025 at 7:20 PM Thomas de Bock via Gcc wrote:
>
> I have been working on a GCC optimization pass that merges comparisons of
> consecutive memory regions with memcmp calls, which get vectorized later with
> O2 (regarding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953).
>
> Thi
I have been working on a GCC optimization pass that merges comparisons of
consecutive memory regions with memcmp calls, which get vectorized later with
O2 (regarding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953).
This is already implemented in LLVM
(https://github.com/llvm/llvm-project/b
On 7/18/25 10:18 AM, Jan Dubiec wrote:
On 14.07.2025 20:02, Jeff Law wrote:
[...]
MD is a completely new topic to me so I am looking for some hints how
to debug the issue. Is it possible that this particular MD is not
fully complete?
Debugging failure to match is painful. I sometimes remove
On 7/18/25 10:18 AM, Jan Dubiec wrote:
Good. Note that I've got a tester I can throw things into. I'll do a
regression test of mh, ms, msx with -mint32. I can add your patch to
that tester to see what happens.
I would be nice. The new version is in the attachment. I run tests on
the simu
On 14.07.2025 20:02, Jeff Law wrote:
[...]
MD is a completely new topic to me so I am looking for some hints how
to debug the issue. Is it possible that this particular MD is not
fully complete?
Debugging failure to match is painful. I sometimes remove all the #line
markers in the generated ins
On 7/14/25 10:57 AM, Jan Dubiec via Gcc wrote:
Recently I have started playing with machine descriptions in the context
of PR109324 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109324). I
have nodified MDs (see the attached patch) and got following ICE when I
tried to build gcc:
/d/Works/
Recently I have started playing with machine descriptions in the context
of PR109324 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109324). I
have nodified MDs (see the attached patch) and got following ICE when I
tried to build gcc:
/d/Works/xcomp/gcc-build-stage1/./gcc/xgcc
-B/d/Works/xcomp
2025 15:27:19
To: gcc@gcc.gnu.org
Subject: Compiler optimization help
Hello, I'm looking to contribute to the project, hoping to implement the
compiler optimization specified in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164. Would appreciate any
help/tips regarding what files I should
Hello, I'm looking to contribute to the project, hoping to implement the
compiler optimization specified in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164. Would appreciate any
help/tips regarding what files I should look at to start working towards
implementing something like
On Mon, 13 Jan 2025 at 12:17, Ben Boeckel via Gcc wrote:
>
> On Mon, Jan 13, 2025 at 01:27:17 +, Hao Liu via Gcc wrote:
> > I'm new to GCC community, and try to contribute some patches.
> > I am having trouble setting git send-email with Outlook on Linux. Does
> > anyone have any successful ex
On 13/01/2025 01:27, Hao Liu via Gcc wrote:
Hi,
I'm new to GCC community, and try to contribute some patches.
I am having trouble setting git send-email with Outlook on Linux. Does anyone
have any successful experiences to share?
I assume from your email address that you're referring to the
On Mon, Jan 13, 2025 at 01:27:17 +, Hao Liu via Gcc wrote:
> I'm new to GCC community, and try to contribute some patches.
> I am having trouble setting git send-email with Outlook on Linux. Does
> anyone have any successful experiences to share?
I don't believe Outlook is well-suited for send
Hi,
I'm new to GCC community, and try to contribute some patches.
I am having trouble setting git send-email with Outlook on Linux. Does anyone
have any successful experiences to share?
Best regards
Dear GCC Gurus,
We are compiling a GCC using "pre-existing" GCC and
we want to have control over the order of the system directories that are
searched
particularly we want /usr/include to be searched before others. We are not
in a position to keep adding -I/usr/include to our build scripts.
Hi all,
I currently have the following RTL patch to TLS handling code on hand, but
am having major trouble understanding it:
+#if TARGET_WIN32_TLS
+ rtx scratch = gen_rtx_SCRATCH (Pmode);
+
+ rtx basereg = gen_reg_rtx (Pmode);
+ rtx thread = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, const0_rtx),
UN
Am 10.08.24 um 10:17 schrieb Thomas Schwinge:
Hi!
I'm not sure I understand what actually the issue is, but:
On 2024-08-09T20:00:42+0200, Thomas Koenig wrote:
I have managed to bring the fortran-unsigned branch into a state where
First, I see that the upstream devel/fortran_unsigned branch
lready have all relevant commits in your local branch
(check, as others have advised, with 'gitk' or plain 'git log', for
example), just '--force' push the local branch to upstream
devel/fortran_unsigned branch?
Grüße
Thomas
> I have no idea what happened, or
Am 09.08.24 um 21:57 schrieb Dimitar Dimitrov:
You are redoing the rebase again. So it is expected to get the same
warnings.
I need to get the changes from master into my branch, or else
things will not compile due to changes in master. But it seems
that this is no longer possible, thanks to
On Fri, Aug 09, 2024 at 09:40:08PM +0200, Thomas Koenig wrote:
> Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov:
>
> > I assume you reset your local branch? The branch on the server does not
> > seem to be affected. I suggest to rebase the remote branch using
> > another local branch. Example:
>
Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov:
I assume you reset your local branch? The branch on the server does not
seem to be affected. I suggest to rebase the remote branch using
another local branch. Example:
# Just in case, see which is your old local branch.
$ git branch
#
On Fri, Aug 09, 2024 at 08:43:38PM +0200, Thomas Koenig wrote:
> Hi Dimitar,
>
> > On Fri, Aug 09, 2024 at 08:00:42PM +0200, Thomas Koenig via Gcc wrote:
> > > Hi,
> > >
> > > I have managed to bring the fortran-unsigned branch into a state where
> > > it can no longer be rebased. When I do a
> >
Hi Dimitar,
On Fri, Aug 09, 2024 at 08:00:42PM +0200, Thomas Koenig via Gcc wrote:
Hi,
I have managed to bring the fortran-unsigned branch into a state where
it can no longer be rebased. When I do a
$ git rebase master
It's unknown what is the state of your local master branch. So I would
ad
a conflict.
If your local branch is tracking origin/devel/fortran_unsigned, then you
are attempting to merge pre-rebase history with post-rebase history.
In such case conflicts are expected. Don't pull the remote devel
branch.
To visualise the histories of your local and the remote branch:
$ g
(use "git pull" to merge the remote branch into yours)
nothing to commit, working tree clean
and when I do "git pull" I get a lot of conflicts, basically having
to redo each commit by hand, as a conflict.
I have no idea what happened, or why, and despite the help of some
nice peo
On Fri, Jul 12, 2024 at 4:42 AM Andrew Pinski wrote:
>
> On Thu, Jul 11, 2024 at 2:14 AM Richard Biener
> wrote:
> >
> > On Thu, Jul 11, 2024 at 10:58 AM Richard Sandiford
> > wrote:
> > >
> > > Andrew Pinski writes:
> > > > I need some
On Thu, Jul 11, 2024 at 2:14 AM Richard Biener
wrote:
>
> On Thu, Jul 11, 2024 at 10:58 AM Richard Sandiford
> wrote:
> >
> > Andrew Pinski writes:
> > > I need some help with the vector cost model for aarch64.
> > > I am adding V2HI and V4QI mode support
On Thu, Jul 11, 2024 at 10:58 AM Richard Sandiford
wrote:
>
> Andrew Pinski writes:
> > I need some help with the vector cost model for aarch64.
> > I am adding V2HI and V4QI mode support by emulating it using the
> > native V4HI/V8QI instructions (similarly to
Andrew Pinski writes:
> I need some help with the vector cost model for aarch64.
> I am adding V2HI and V4QI mode support by emulating it using the
> native V4HI/V8QI instructions (similarly to mmx as SSE is done). The
> problem is I am running into a cost model issue with
> gcc
I need some help with the vector cost model for aarch64.
I am adding V2HI and V4QI mode support by emulating it using the
native V4HI/V8QI instructions (similarly to mmx as SSE is done). The
problem is I am running into a cost model issue with
gcc.target/aarch64/pr98772.c (wminus is similar to
lk about :- preprocessor
> Compiler
> Aasembler etc
>
> I hope you can help me🥺
>
Sir,
I am a student of class 11th . I want to know original C compiler is open
or closed source.
Like I talk about :- preprocessor
Compiler
Aasembler etc
I hope you can help me🥺
On 28 May 2024, at 14:35, Zack Weinberg wrote:
> These are probably all either vendor or OS names from the late 1980s or
> early 1990s. Can anyone help me fill out the following list of things
> that ought to appear in testsuite/config-sub.data, if I knew what to
> put in place of
nd I don't know what the correct canonical system name should be.
gcc@ mailing list cc:ed because I know some of you have long memories.
These are probably all either vendor or OS names from the late 1980s or
early 1990s. Can anyone help me fill out the following list of things
that ought to appe
Hi! I'm trying to modify the GCC source code to get something done. But
there's a difficulty in understanding how to use some functions and data
structures. Please help me with some hints.
Here is the problem: in the file GCC-source/gcc/c/c-decl.c, before
'c_decl_attribute
added to a special function
> declaration. Could you please help me understand what's happening there?
I think you need to elaborate on what kind of attributes and what exactly a
special function declaration is for us to give a reasonable answer. Maybe
giving an example helps understanding
Hi!
We're trying to improve the optimization process in GCC by adding manual
optimization attributes to some needed functions. I couldn't yet find the
code routine where the attributes can be added to a special function
declaration. Could you please help me understand what's
On 06/03/2024 15:04, Andrew Carlotti via Gcc wrote:
> On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote:
>> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
>>>
>>> Hi Christophe,
>>>
>>> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
I've not
On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote:
> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> >
> > Hi Christophe,
> >
> > On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> > > I've noticed that sourceware's buildbot has a small script
> >
On 05/03/2024 14:26, Richard Earnshaw (lists) wrote:
> On 04/03/2024 20:04, Jonathan Wakely wrote:
>> On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
>> wrote:
>>>
>>>
>>>
>>> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
Tools like git (and svn before it) don't try to maintain time-sta
On 04/03/2024 20:04, Jonathan Wakely wrote:
> On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
> wrote:
>>
>>
>>
>> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
>>> Tools like git (and svn before it) don't try to maintain time-stamps on
>>> patches, the tool just modifies the file and the time
On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
wrote:
>
>
>
> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
> > Tools like git (and svn before it) don't try to maintain time-stamps on
> > patches, the tool just modifies the file and the timestamp comes from the
> > time of the modification.
On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
Tools like git (and svn before it) don't try to maintain time-stamps on
patches, the tool just modifies the file and the timestamp comes from the time
of the modification. That's fine if there is nothing regenerated within the
repository (it
On 04/03/2024 16:42, Christophe Lyon wrote:
> On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw
> wrote:
>>
>>
>>
>> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
>> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
>> >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely
>> >> wrote:
>> >>>
>
On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw wrote:
>
>
>
> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
> >>>
> >>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc
> >
On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
> On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
>> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
>>>
>>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc
>>> wrote:
Hi!
On Mon, 4 Mar 2024 at 10:36, Thomas
On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
>>
>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote:
>>>
>>> Hi!
>>>
>>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
Hi!
On 2024-03-04T00:30:05+,
On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
>
> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote:
> >
> > Hi!
> >
> > On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
> > >
> > > Hi!
> > >
> > > On 2024-03-04T00:30:05+, Sam James wrote:
> > > > Mark Wielaard writes:
>
On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote:
>
> Hi!
>
> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
> >
> > Hi!
> >
> > On 2024-03-04T00:30:05+, Sam James wrote:
> > > Mark Wielaard writes:
> > >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> > >
Hi!
On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
>
> Hi!
>
> On 2024-03-04T00:30:05+, Sam James wrote:
> > Mark Wielaard writes:
> >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> >>> [...], I read
> >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
> >
Hi!
On 2024-03-04T00:30:05+, Sam James wrote:
> Mark Wielaard writes:
>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>>> [...], I read
>>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>>> which basically says "run autoreconf in every dir where there is a
>>> c
Mark Wielaard writes:
> Hi Christophe,
Hi Mark, Christophe, et. al,
>
> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>> > > > And it was indeed done this way because that way the files are
>> > > > regenerated in a reproducible way. Which wasn't the case when using
>> > > >
Hi Christophe,
On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> > > > And it was indeed done this way because that way the files are
> > > > regenerated in a reproducible way. Which wasn't the case when using
> > > > --enable-maintainer-mode (and autoreconfig also doesn't work).
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> > > That python script works across gcc/binutils/gdb:
> > > https://sourceware.org/cgit/builder/tree/builder/
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> > > That python script works across gcc/binutils/gdb:
> > > https://sourceware.org/cgit/builder/tree/builder/
Hi Christophe,
On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> > That python script works across gcc/binutils/gdb:
> > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py
> >
> > It is installed into a containe
On Thu, 29 Feb 2024 at 20:49, Thiago Jung Bauermann
wrote:
>
>
> Hello,
>
> Christophe Lyon writes:
>
> > I hoped improving this would be as simple as adding
> > --enable-maintainer-mode when configuring, after making sure
> > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's
>
Hello,
Christophe Lyon writes:
> I hoped improving this would be as simple as adding
> --enable-maintainer-mode when configuring, after making sure
> autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's
> libtool and gettext seems OK).
>
> However, doing so triggered several pr
On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> > I've noticed that sourceware's buildbot has a small script
> > "autoregen.py" which does not use the project's build system, but
> > rather calls a
On Thu, 29 Feb 2024 at 11:41, Richard Earnshaw (lists)
wrote:
>
> On 29/02/2024 10:22, Christophe Lyon via Gcc wrote:
> > Hi!
> >
> > Sorry for cross-posting, but I'm not sure the rules/guidelines are the
> > same in gcc vs binutils/gdb.
> >
> > TL;DR: are there some guidelines about how to use/en
Hi Christophe,
On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> I've noticed that sourceware's buildbot has a small script
> "autoregen.py" which does not use the project's build system, but
> rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way.
> Should we
On 29/02/2024 10:22, Christophe Lyon via Gcc wrote:
> Hi!
>
> Sorry for cross-posting, but I'm not sure the rules/guidelines are the
> same in gcc vs binutils/gdb.
>
> TL;DR: are there some guidelines about how to use/enable maintainer-mode?
>
> In the context of the Linaro CI, I've been looking
Hi!
Sorry for cross-posting, but I'm not sure the rules/guidelines are the
same in gcc vs binutils/gdb.
TL;DR: are there some guidelines about how to use/enable maintainer-mode?
In the context of the Linaro CI, I've been looking at enabling
maintainer-mode at configure time in our configurations
Hi,
If you are bidding any construction project and need estimation administration,
we are able to assist you with all estimation work.
We are an estimation providing company. We give cost estimation and amounts of
take-off administration. At this moment we are giving 40% discount on our
servi
On 10/31/23 08:26, Enrico via Gcc wrote:
I am working on GCC for a target architecture where clz(0) is defined and
is 32 (TriCore).
The code under test is the following:
#include
int f(unsigned int a) {
unsigned int res = 32 - __builtin_clz(a);
if(res > 0) printf("test");
retu
I am working on GCC for a target architecture where clz(0) is defined and
is 32 (TriCore).
The code under test is the following:
#include
int f(unsigned int a) {
unsigned int res = 32 - __builtin_clz(a);
if(res > 0) printf("test");
return res;
}
>From GCC version greater and equal to
On Fri, Oct 27, 2023 at 2:12 PM David Malcolm wrote:
>
> On Fri, 2023-10-27 at 12:48 -0700, Andrew Pinski wrote:
> > Hi David and others,
> > I am in the process of improving phi-opt and moving what was
> > handled
> > in value_replacement to match-and-simplify and ran into a few
> > failures
>
On Fri, 2023-10-27 at 12:48 -0700, Andrew Pinski wrote:
> Hi David and others,
> I am in the process of improving phi-opt and moving what was
> handled
> in value_replacement to match-and-simplify and ran into a few
> failures
> in the analyzer testsuite.
> For an example c-c++-common/analyzer/in
Hi David and others,
I am in the process of improving phi-opt and moving what was handled
in value_replacement to match-and-simplify and ran into a few failures
in the analyzer testsuite.
For an example c-c++-common/analyzer/inlining-3-multiline.c (and
c-c++-common/analyzer/inlining-3.c) now fail
his approach is that many
> relocation entries will have the same name, so we will need a hash table
> with the key as symbol name and value as symbol index in symtab. It would
> be really helpful if you could point out the relevant docs or help me
> figure out how to use the hash table in
relocation entries will have the same name, so we will need a hash table
with the key as symbol name and value as symbol index in symtab. It would
be really helpful if you could point out the relevant docs or help me
figure out how to use the hash table in GCC.
Another approach is, as we have only 4-5
On 8/10/23 07:33, senthilkumar.selva...@microchip.com wrote:
Hi Vlad,
I can confirm your commit
(https://gcc.gnu.org/git?p=gcc.git;a=commit;h=2971ff7b1d564ac04b537d907c70e6093af70832)
fixes the above problem, thank you. However, I see execution failures if a
pseudo assigned to FP ha
On Tue, 2023-07-18 at 11:04 -0400, Vladimir Makarov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 7/17/23 03:17, senthilkumar.selva...@microchip.com wrote:
> > On Fri, 2023-07-14 at 09:29 -0400, Vladimir Makarov wrote:
> > > If you se
> On Jul 27, 2023, at 7:50 AM, Maciej W. Rozycki wrote:
>
> On Fri, 14 Jul 2023, Vladimir Makarov via Gcc wrote:
>
>>> On the avr, the stack pointer (SP)
>>> is not used to access stack slots
>> It is very uncommon target then.
>
> Same with the VAX target. SP is used for outgoing functi
On Fri, 14 Jul 2023, Vladimir Makarov via Gcc wrote:
> > On the avr, the stack pointer (SP)
> >is not used to access stack slots
> It is very uncommon target then.
Same with the VAX target. SP is used for outgoing function arguments,
function calls, alloca only. AP is used for incoming
On 7/17/23 03:17, senthilkumar.selva...@microchip.com wrote:
On Fri, 2023-07-14 at 09:29 -0400, Vladimir Makarov wrote:
If you send me the preprocessed test, I could start to work on it to fix
the problems. I think it is hard to fix them right for a person having
a little experience with LRA.
On Fri, 2023-07-14 at 09:29 -0400, Vladimir Makarov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 7/13/23 05:27, SenthilKumar.Selvaraj--- via Gcc wrote:
> > Hi,
> >
> >I've been spending some (spare) time checking what it would t
On 7/13/23 05:27, SenthilKumar.Selvaraj--- via Gcc wrote:
Hi,
I've been spending some (spare) time checking what it would take to
make LRA work for the avr target.
Right after I removed the TARGET_LRA_P hook disabling LRA, building
libgcc failed with a weird ICE.
On the avr,
Hi,
I've been spending some (spare) time checking what it would take to
make LRA work for the avr target.
Right after I removed the TARGET_LRA_P hook disabling LRA, building
libgcc failed with a weird ICE. On the avr, the stack pointer (SP)
is not used to access stack slots - TARGET_CAN
Hi,
As mentioned earlier in previous thread, I am working on a project to
bypass the assembler. I have already finished addition of .symtab section.
While I am currently working to emit the debugging symbols directly from
compiler, one thing which I missed was directly outputting the various info
l
6:22: error inline function ‘static bool
> > is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used
> > but never defined [enabled by default]
> >
> > I have tested the .symtab and dummy symbols addition on the
> > non-bootstrapped build, and they ar
ymbols addition on the
> non-bootstrapped build, and they are working fine. I also ran the lto test
> suite, and it passed as expected. I am looking into the error produced
> during bootstrapped build currently. I would appreciate any help/guidance
> regarding this.
This is because you mis
produced
during bootstrapped build currently. I would appreciate any help/guidance
regarding this.
--
Regards
Rishi
hi,
I am using ldscripts / elf_x86_64.xce for linking one c++ program, and need to
mlock the rodata during software startup phase(make sure there is no min
pagefault during accessing the many large static const array), how can we get
the address of that rodata(seem we could get the __executabl
Hi everybody,
I hope this is not inappropriate question for this list, since internet
provides "some" means to get it done:
https://stackoverflow.com/questions/8259447/give-structure-offset-attribute-to-assembler,
https://forum.microchip.com/s/topic/a5C3l00M24UEAS/t238022?
Please don't cross-post to several mailing lists, this belongs on the
gcc-help mailing list only.
On Wed, 1 Mar 2023, 06:33 Kondreddy, Vinay Kumar, <
vinaykumar.kondre...@staples.com> wrote:
> Hi Team,
>
>
>
> We are using GCC 4.8.3 for one of our legacy applicatio
Hi Team,
We are using GCC 4.8.3 for one of our legacy applications i.e: Automatch. after
database upgrade from 11/2 to 19.0.0, while recompiling one of our proc program
we are getting below error. Could you please help us to resolve below issue.
Please find full error trace in above attachment
1 - 100 of 1288 matches
Mail list logo
