On 01/07/2019 18:03, James Greenhalgh wrote:
>> gcc/testsuite/ChangeLog:
>>
>> 2019-06-12 Joel Hutton
>>
>> * gcc.target/aarch64/fmul_scvtf_1.c: New test.
> This testcase will fail on ILP32 targets where unsigned long will still
> live in a '
dbsupport/create-version.sh
exists, use that to determine the version number.
Tested on x86_64-linux, by running the src-release script with "gdb"
as the argument, and verifying that the name of the tarball is now
correct.
OK to push?
Thanks!
--
Joel
---
src-release.sh | 4 +++
t, and verifying that the name of the tarball is now
> >correct.
>
> Ok.
Thanks Richard. Pushed to the master branch in binutils-gdb. I looked at
the GCC repository, and couldn't find it there, so synchronization to do
between the two, after all!
--
Joel
);
}
The following warning is emitted:
warning: ignoring return value of 'cmse_check_address_range' declared
with attribute 'warn_unused_result' [-Wunused-result]
6 | cmse_check_address_range((int*)data, 0, 0);
| ^~
gcc/ChangeLo
>> +++ b/gcc/config/newlib-stdint.h
>> @@ -22,10 +22,9 @@ a copy of the GCC Runtime Library Exception along
>with this program;
>> see the files COPYING3 and COPYING.RUNTIME respectively. If not,
>see
>> <http://www.gnu.org/licenses/>. */
>>
>> -/* newlib uses 32-bit long in certain cases for all non-SPU
>> - targets. */
>> +/* newlib used to use a 32-bit long, no longer */
>> #ifndef STDINT_LONG32
>> -#define STDINT_LONG32 (LONG_TYPE_SIZE == 32)
>> +#define STDINT_LONG32 0
>> #endif
>>
>> #define SIG_ATOMIC_TYPE "int"
>> --
>> 2.7.4
>>
--joel
> Thanks. Is the environ thing also fixed?
>
> Joel/Pedro, how should I go about making sure these changes are in the
> GDB copy of libiberty?
Normally, I'd expect someone pushing to GCC's libibert to also
update our repo accordingly. However, it's easy to forget so,
he work (revision log, etc).
--
Joel
x27;s very kind of you to help us with that :). Thank you!
--
Joel
; @@ -1768,8 +1780,11 @@ AC_ARG_WITH(boot-ldflags,
> # In stages 2 and 3, default to linking libstdc++ and libgcc
> # statically. But if the user explicitly specified the libraries to
> # use, trust that they are doing what they want.
> - if test "$poststage1_libs" = ""; then
> + if test "$poststage1_libs" = "" -a "$have_static_libs" = yes; then
> poststage1_ldflags="-static-libstdc++ -static-libgcc"
> + else
> + # If static library linking is disabled.
> + poststage1_ldflags=""
> fi])
> AC_SUBST(poststage1_ldflags)
>
--
Joel
issues. This patch (or some
minor variant) needs to be applied to every branch from
4.9 to master.
Comments?
2015-04-18 Joel Sherrill
* config.host (moxie-*-rtems*): Merge this stanza with
other moxie targets so the same extra_parts are built.
Also have
What is currently submitted for LLVM review was submitted before we determined
this naming scheme. I will mark the current submittal as abandoned, as the
scheduling model needs to be split out and revised.
Joel Jones
Sent from my AArch64 powered iPhone
> On Nov 2, 2016, at 3:55 AM, Ja
eted as targets.
Wouldn't a list be able to be compiled from major branch release announcements?
There should be a deprecated and removed note in two release branch
descriptions. Even if we screwed up and forgot to list it on both, if it likely
to be in one of them.
--joel
of
configury for us with respect to lib depenencies, which I see
in gcc's root configure.ac that gmp/mpfr/mpc options is done
via specific code.
What I'm getting at is that, to achieve your prefered option
(which I agree is more elegant), it would take a significant
effort.
--
Joel
.
Ok to apply?
Thanks,
--
Joel
---
.gitignore |1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index dc1bf3f..8e2e1e9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@
*.la
*.lo
*.o
+*.pyc
*.tmp
.deps
--
1.7.10.4
I would like to hear from an ARM maintainer before I commit this.
--joel
On 5/8/2013 5:06 AM, Sebastian Huber wrote:
This patch should be applied to all open GCC branches.
This patch removes the mthumb/march=armv7 since it is virtually equal to
the mthumb/march=armv7-m multilib. Add variants
t-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-m/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv7-m/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-m
+MULTILIB_EXCEPTIONS += mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mfpu=neon
+MULTILIB_EXCEPTIONS += mfloat-abi=hard
--
Joel Sherrill,
Hi
sparc64*-*-rtems* ends up with __svr4__ defined. The attached
patch corrects that.
OK to apply?
013-05-10 Joel Sherrill
* config.gcc (sparc64*-*-rtems*): Use sp64-rtemself.h.
RTEMS target should not have -D__svr4__ in CPP_SUBTARGET_SPEC.
* config/sparc/sp64
Thanks Eric. This is better. spaec64-elf should not define it either.
Eric Botcazou wrote:
> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.
Let's remove the FIXME instead. Applied to mainline.
2013-05-14 Eric Botcazou
* config/sparc/sp64-elf
I forgot to ask. Did you put this on the open branches as well? 4.7 and 4.8.
Please and thank you
Eric Botcazou wrote:
> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.
Let's remove the FIXME instead. Applied to mainline.
2013-05-14 Eric Botcazou
Thanks for the ping.
I updated the date on the ChangeLog and committed this.
--joel
On 9/17/2014 8:26 AM, Sebastian Huber wrote:
Ping^2.
On 02/05/14 10:46, Sebastian Huber wrote:
Ping.
On 2014-04-18 12:11, Sebastian Huber wrote:
From: Sebastian Huber
The command line to build a GCC
Is there anyone else from GCC who needs to approve this?
As RTEMS maintainer for GCC, I am ok with it.
--joel
On 9/17/2014 8:37 AM, Sebastian Huber wrote:
> contrib/ChangeLog
> 2014-09-17 Sebastian Huber
>
> * config-list.mk (LIST): Add arm-rtems.
> Add nios2-rtems
Other than that, it looks like all the RTEMS
targets except that the or1k (which is not in the FSF tree
yet) are included. I didn't review against the list of *-elf
targets though.
What is the rationale for inclusion on the list? Should
v850-elf and v850-rtems also be added?
And is t
I committed this to 4.9 and head.
Sebastian.. please double check that it is OK please.
I had some issues with applying it to the head and
manually did it.
--joel
On 9/17/2014 8:37 AM, Sebastian Huber wrote:
> contrib/ChangeLog
> 2014-09-17 Sebastian Huber
>
> * config-l
On 9/18/2014 6:51 AM, Jan-Benedict Glaw wrote:
> On Wed, 2014-09-17 10:52:34 -0500, Joel Sherrill
> wrote:
>> On 9/17/2014 10:41 AM, Sebastian Huber wrote:
>>> On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
>>>> On Wed, 2014-09-17 15:37:32 +0200, Sebastian
OK to commit?
2014-09-18 Joel Sherrill
* config-list.mk (LIST): Add v850-rtems.
Index: contrib/config-list.mk
===
--- contrib/config-list.mk (revision 215357)
+++ contrib/config-list.mk (working copy)
@@ -68,7
Thanks. Committed to 4.9 and head.
--joel
On 9/18/2014 1:28 PM, Jeff Law wrote:
> On 09/18/14 09:31, Joel Sherrill wrote:
>> OK to commit?
>>
>> 2014-09-18 Joel Sherrill
>>
>> * config-list.mk (LIST): Add v850-rtems.
> Yes.
>
> jeff
>
--
On 9/18/2014 6:51 AM, Jan-Benedict Glaw wrote:
> On Wed, 2014-09-17 10:52:34 -0500, Joel Sherrill
> wrote:
>> On 9/17/2014 10:41 AM, Sebastian Huber wrote:
>>> On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
>>>> On Wed, 2014-09-17 15:37:32 +0200, Sebastian
This is now committed.
Please double check me, Sebastian.
--joel
On 7/31/2013 2:02 AM, Sebastian Huber wrote:
Ping.
On 2013-07-08 15:29, Sebastian Huber wrote:
The __cxa_atexit support is a reqirement for destructor registration of
thread-local objects.
For *-*-elf it is already enabled by
Hi
This has been around for a while as PR52466 which has
a patch. I have attached the patch. Is it OK to apply to
the open branches?
2013-08-07 Joel Sherrill
* configure.ac (lm32*-*-*): Use SJLJ exceptions.
--
Joel Sherrill, Ph.D. Director of Research & Develop
the ChangeLog entry on the branches, putting 2013-02-22 for a
patch installed on 2013-03-06 doesn't make much sense. There is an example
just below on the 4.7 branch. TIA.
Done.
Sorry. I used Sebastian's entries without even thinking they were at
least a week old.
--
Joel Sher
Committed to 4.8 branch and head as obvious and cosmetic.
--joel
RTEMS
On 3/22/2013 3:42 PM, Sebastian Huber wrote:
gcc/testsuite/ChangeLog
2013-03-22 Sebastian Huber
* gcc.c-torture/execute/builtins/builtins.exp: Sort targets
alphabetically.
---
gcc/testsuite/gcc.c
I committed this patch which reduces test failures.
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01373.html
2013-01-29 Sebastian Huber
* config/rtems.opt: Add -pthread option.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp
Hi
Would it be possible for a PowerPC maintainer to look
into committing the fix to this PR to the impacted
branches which are open?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00970.html
Thanks.
--
Joel Sherrill, Ph.D. Director
The RTEMS Community would like to squeeze pr56771 in. It only got a fix in the
past few days. It is a one line arm-rtems specific path to libcpp configure.
Can I commit that?
--joel
RTEMS
Richard Biener wrote:
Status
==
The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
On 4/3/2013 8:36 AM, Richard Biener wrote:
On Wed, 3 Apr 2013, Joel Sherrill wrote:
The RTEMS Community would like to squeeze pr56771 in. It only got a fix in the
past few days. It is a one line arm-rtems specific path to libcpp configure.
Can I commit that?
Sure, if it got RTEMS maintainer
This patch has been applied to 4.7, 4.8 and 4.9.
PR 56771 closed.
--joel
On 4/2/2013 10:08 AM, Sebastian Huber wrote:
This patch is for GCC 4.8 and 4.9.
v2: Fix ChangeLog.
libcpp/ChangeLog
2013-04-02 Sebastian Huber
PR target/56771
* configure.ac: Require 64-bit int for
On 02/19/2013 10:42 PM, Joel Brobecker wrote:
> > >This is useful when a DIE does not have a descriptive type attribute.
> > >In that case, the debugger needs to determine whether the unit
> > >was compiled with a compiler that normally provides that information,
> >
This patch is now committed.
--joel
On 1/7/2014 10:58 AM, Sebastian Huber wrote:
> v2: Do not override an existing tmake_file in (arm*-*-uclinux*eabi*).
>
> The ARM changes are already approved:
>
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00254.html
>
> The rest is RT
Hi Jason,
On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote:
> On 02/19/2013 10:42 PM, Joel Brobecker wrote:
> >This is useful when a DIE does not have a descriptive type attribute.
> >In that case, the debugger needs to determine whether the unit
> >was compiled
[resending with the patch - sorry about that]
Hi Jason,
On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote:
> On 02/19/2013 10:42 PM, Joel Brobecker wrote:
> >This is useful when a DIE does not have a descriptive type attribute.
> >In that case, the debugger needs to de
arted working on producing
standard DWARF in place of our encodings, and small progress has been
made. But this is even more of a huge task than we thought, and in
the meantime, this little flag will help non-AdaCore users...
Thank you!
On Fri, Jan 31, 2014 at 09:09:05AM +0400, Joel Brobecker wrote:
>
ote for binutils.
> How about includes/ too? The choices there are
> a) apply to just binutils owned files,
> b) apply to binutils+gdb files,
> c) apply to the lot, and update gcc/include/ too.
>
> I see Joel already updated include/gdb, but the script makes a further
> sma
t mean that the sources needed to be made public that year for
us to be able to claim copyright that year? It did not seem so to me.
But you could ask the FSF (copyright DASH clerk AT fsf DOT org).
--
Joel
Unless someone objects, I am going to commit this to the
4.9 branch and head.
--joel
On 7/7/2014 1:42 AM, Sebastian Huber wrote:
> Ping.
>
> On 2014-06-26 13:43, Sebastian Huber wrote:
>> This patch should be applied to GCC 4.9 and mainline. I do not have
>> write access,
Hi
It took a while to find this but v850-rtems lost the include
paths for the rtems specific .h files in newlib due to
the line that resets tmake_file rather than appends to it.
Is this OK to apply to all impacted branches and the head?
2014-03-20 Joel Sherrill
* config.host (v850
On 3/20/2014 10:57 AM, Rainer Orth wrote:
> Hi Joel,
>
>> It took a while to find this but v850-rtems lost the include
>> paths for the rtems specific .h files in newlib due to
>> the line that resets tmake_file rather than appends to it.
>>
>> Is this OK to ap
k;
> > +}
> > +}
> > +
> > + if (needs_quotes)
> > +{
> > + *p++ = '"';
> > +}
> >for (j = 0; argv[i][j]; j++)
> > {
> > if (argv[i][j] == '"')
> > @@ -382,9 +409,12 @@ argv_to_cmdline (char *const *argv)
> > }
> > *p++ = argv[i][j];
> > }
> > - for (k = j - 1; k >= 0 && argv[i][k] == '\\'; k--)
> > - *p++ = '\\';
> > - *p++ = '"';
> > + if (needs_quotes)
> > +{
> > + for (k = j - 1; k >= 0 && argv[i][k] == '\\'; k--)
> > +*p++ = '\\';
> > + *p++ = '"';
> > +}
> >*p++ = ' ';
> > }
> >p[-1] = '\0';
> > --
> > 1.9.2
>
> Patch itself makes sense. Let see if there are additional comments.
>
> Regards,
> Kai
--
Joel
only, but I think this is the type of extension (compilation
> artifact) which can be shared amoung all projects.
>
> ChangeLog:
>
> * .gitignore: Ignore *.pyc file.
>
> Ok to apply?
> Thanks,
> --
> Joel
>
> ---
> .gitignore |1 +
>
? (obvious?)
Thanks,
--
Joel
---
gcc/cp/parser.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3dc2ec6..61d93f8 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17932,9 +17932,10 @@ cp_parser_initializer_list (cp_parser
> > Tested against x86_64-linux, no regression.
> > OK to commit? (obvious?)
>
> Hmm? We compile with a C++ compiler where this is perfectly valid ...
I was compiling with GCC 4.7 where it gave me a warning... I don't know
much about C++ anymore, so I didn't know. Oh well!
--
Joel
yes.
Eric Botcazou asked that we have the same code for both 4.7 and HEAD.
Would it be OK to apply it to both? It's not really strictly
necessary for the HEAD, but I don't see it as being harmful either.
Thank you!
--
Joel
ssion. I also tested against
the GDB testsuite, before and after, and no regression. This
is expected, since GDB currently does not look for this attribute
(but I would like it to).
OK to apply for HEAD and 4.7?
Thanks,
--
Joel
---
gcc/dwarf2out.c |4
1 files changed, 4 insertions(
> > Eric Botcazou asked that we have the same code for both 4.7 and HEAD.
> > Would it be OK to apply it to both? It's not really strictly
> > necessary for the HEAD, but I don't see it as being harmful either.
>
> Sure.
Thank you! Now checked in.
--
Joel
Ping?
Thank you!
On Tue, Jan 08, 2013 at 07:24:14AM -0500, Joel Brobecker wrote:
> Hello,
>
> I just noticed that part of the proposal we made for...
> http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type
>
> ... got missed in the patch that got checked in:
> http://gcc.g
Hello,
I was hoping someone would kindly review this patch? It is an
important part for debugging Ada code, helping with performance.
Thank you!
On Tue, Jan 08, 2013 at 07:24:14AM -0500, Joel Brobecker wrote:
> Hello,
>
> I just noticed that part of the proposal we made for.
such as objdump,
for instance. But I think those can be submitted separately.
It might not apply to HEAD just yet, because I'm going at it
step by step. For those who use git, I applied it on top of:
commit 889f73fdb5bec852e083f47703f31592ef3ee77b
Author: Alan Modra
Date: T
patches for powerpc-aix...
http://www.sourceware.org/ml/binutils/2013-02/msg00233.html
So, not quite there yet, but getting a lot closer.
--
Joel
looked at this part in details, but our recollection is that
it's a matter of configuring GCC with --with-gnu-as and --with-gnu-ld,
together with a small patch to make DWARF the default. AFAIK, the rest
should be working as expected.
--
Joel
.
As RTEMS GCC target maintainer, I can approve these changes but I would
like concurrence with the branch release managers.
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a
bled for
"smul".
/tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for
"smul".
/tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for
"umul".
I can prepare a PR if you think it is different.
Ra
On 11/02/2011 05:30 PM, David Miller wrote:
From: Joel Sherrill
Date: Wed, 2 Nov 2011 16:29:16 -0500
Is this similar to what I just got for sparc-rtems when compiling
libgcc2 with -mcpu=v8?
/tmp/cczMc4jN.s: Assembler messages:
/tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" n
This patch adds the microblaze-*-rtems* target to gcc.
OK to apply?
2012-05-07 Joel Sherrill
* config.gcc (microblaze-*-rtems*): New target.
* config/microblaze/rtems.h: New file
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp
Sorry.. missed the attachment
This patch adds the microblaze-*-rtems* target to gcc.
OK to apply?
2012-05-07 Joel Sherrill
* config.gcc (microblaze-*-rtems*): New target.
* config/microblaze/rtems.h: New file.
--
Joel Sherrill, Ph.D. Director of Research& Develop
ches from
a.out -> coff -> elf in a similar manner in the past.
I hope it is OK to merge this.
Thanks.
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35
Hi
When moving stuff into libgcc, a line for m32r-rtems
got lost. This is PR53314.
Is this OK for the head and 4.7?
2012-05-16 Joel Sherrill
* config.host (m32r-*-rtems*): Include crtinit.o and crtfinit.o
as extra_parts.
diff --git a/libgcc/config.host b/libgcc/config.host
index
It will naturally disappear when gcc does the clean up. It won't be around
long.
Sebastian Huber wrote:
>On 06/13/2012 02:51 PM, Richard Earnshaw wrote:
>> (arm*-*-rtems*): Remove.
>
>For RTEMS the intention was to rename arm*-*-rtemseabi* into arm*-*-rtems* and
>provide an arm*-*-rtemse
x27;t they also be the same?
And if they should be the same, wouldn't it make
sense to combine the stanzas?
Just wanting advice from someone who knows more. :)
--joel
Hi, please have a look at the attached patch. Test suite results for
GCC 4.7 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg
Hello everyone,
I wasn't sure if I needed approval for this patch or not, but better
be safe than sorry. I'll apply to both GCC and then src when I receive
confirmation that it's OK to apply.
I would like to update the config.sub script to the latest version
from the official config repo. The bi
> ChangeLog:
>
> * config.sub: Update to 2012-04-18 version from official repo.
Thanks to everyone who answered. This patch is no in, both GCC & src.
--
Joel
file
libgcc/config/rs6000/t-ppccomm.rej
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Thanks.
Works for me. I posted test results for powerpc-rtems4.11
at http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02314.html
From the rtems perspective, you can commit it.
--joel
On 11/21/2011 12:08 PM, Rainer Orth wrote:
Joel Sherrill writes:
Does this patch apply OK for others
results than what I posted back in
April for a 4.6.1 prerelease:
http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00209.html
2011-12-01 Joel Sherrill
* gcc/ada/s-tpopsp-rtems.adb: Use ATCB_Key rather than
RTEMS_Ada_Self variable for consistency with other ports.
* gcc/ada
On 12/02/2011 01:48 AM, Arnaud Charlet wrote:
The attached patch is necessary to let the gcc head
compile Ada for *-*-rtems*. Other than terminals.c,
the files impacted are RTEMS specific. OK to commit?
OK
Thanks. Committed.
--
Joel Sherrill, Ph.D. Director of Research
Hi,
I have been testing with this for almost a month. It is
my attempt to follow the changes I think Joseph made
to other rs6000 targets. If this change looks right,
I would like to commit it.
Test results have been posted for it.
Thanks.
2011-12-02 Joel Sherrill
* config/rs6000
On 12/02/2011 10:38 AM, Joseph S. Myers wrote:
On Fri, 2 Dec 2011, Joel Sherrill wrote:
2011-12-02 Joel Sherrill
* config/rs6000/rtems.h: Switch to using global_options_set
in SUBSUBTARGET_OVERRIDE_OPTIONS.
Is it deliberate that you are removing the first part of each &qu
On 12/02/2011 11:57 AM, Joseph S. Myers wrote:
On Fri, 2 Dec 2011, Joel Sherrill wrote:
On 12/02/2011 10:38 AM, Joseph S. Myers wrote:
On Fri, 2 Dec 2011, Joel Sherrill wrote:
2011-12-02 Joel Sherrill
* config/rs6000/rtems.h: Switch to using global_options_set
in
Hi,
This addresses all of the Go compilation issues on the
head except one.
Ian.. Is this OK to commit? Or do you have suggestions
on how to make it more general?
Thanks.
2011-12-02 Joel Sherrill
* runtime/go-signal.c: Add conditional on SIGPROF.
* runtime
On 12/02/2011 06:37 PM, Joseph S. Myers wrote:
On Fri, 2 Dec 2011, Joel Sherrill wrote:
OK. I obviously read too much into the other uses.
I did not intend to change semantics just account for
the change making this not compile.
How does the the new version look?
This version is OK
reaks RTEMS, do a visual double check please on the RTEMS specific parts and
commit it. Either that or wait for a test report from me.
--joel
Rainer Orth wrote:
>Paolo Bonzini writes:
>
>> On 05/30/2011 04:29 PM, Rainer Orth wrote:
>>>>> * Non-Solaris SPARC change
* filename_cmp.c (filename_cmp, filename_ncmp): Add handling of
HAVE_CASE_INSENSITIVE_FILE_SYSTEM.
Tested on x86_64-darwin as well as on x86_64-linux. I haven't tested
on a Windows system yet, but I will get our gdb-testsuite's daily
results before tomorrow.
Does this look O
ty
is not an OS property, and we could try devising some ways to test it
in various ways. But I think that the current solution is good enough
for practical purposes. A better solution is, in my opinion, more
effort than it is worth.
--
Joel
> Looks OK to me.
Thanks, DJ. I've just checked the patch in on the GCC side.
I will push it on the src/GDB CVS momentarily.
--
Joel
interwork is an enhancement.
I don't claim that the switch to the EABI tool chain will be without problems,
but we have to use it to figure this out. The multilib selection may need
further changes. I am concerned about the enabled exceptions in some libgcc
functions.
--
Joel Sherrill,
> We can go with a private vect_gimple_build function until we sort out the API
> issue to unblock Tamar (I'll reply to Richards reply with further thoughts on
> this)
>
Done.
> > Similarly are you ok with the use of gimple_extract_op? I would lean
> towards using it as it is cleaner, but I don'
Signed-off-by: Joel Holdsworth
---
gcc/config/avr/avr-devices.cc | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/avr/avr-devices.cc b/gcc/config/avr/avr-devices.cc
index aa284217f50..ff6a5441b77 100644
--- a/gcc/config/avr/avr-devices.cc
+++ b/gcc/config/avr/avr-devices.cc
From: Richard Sandiford
Sent: 21 January 2021 13:40
To: Richard Biener
Cc: Joel Hutton via Gcc-patches ; Joel Hutton
Subject: Re: [AArch64] Remove backend support for widen-sub
Richard Biener writes:
> On Thu, 21 Jan 2021, Richard Sandiford wrote:
>
>> Joe
ed with a V8QI, or how to
represent V16QI where we don't care about the top/bottom 8. I made some attempt
in optabs.c, which is in the patch commented out, but I'm not sure if I'm going
about this the right way.
Joel
diff --git a/gcc/config/aarch64/aarch64-simd.md b/
>>> In practice this will only affect targets that choose to use mixed
>>> vector sizes, and I think it's reasonable to optimise only for the
>>> case in which such targets support widening conversions. So what
>>> do you think about the idea of emitting separate conversions and
>>> a normal subtr
>> So emit a v4qi->v8qi gimple conversion
>> then a regular widen_lo/hi using the existing backend patterns/optabs?
>
>I was thinking of using a v8qi->v8hi convert on each operand followed
>by a normal v8hi subtraction. That's what we'd generate if the target
>didn't define the widening patterns.
ater.
That's fair enough, fake/don't care elements is a bit of a hack. I'll try
something out with the conversions and regular subtract.
thanks for the help,
Joel
Hi Richards,
This patch adds support for the V8QI->V8HI case from widening vect patterns as
discussed to target PR98772.
Bootstrapped and regression tested on aarch64.
[aarch64][vect] Support V8QI->V8HI WIDEN_ patterns
In the case where 8 out of every 16 elements are widened using a
widening
&code2, &multi_step_cvt,
>> +&interm_types))
>>{
>> /* Binary widening operation can only be supported directly by the
>> architecture. */
>> @@ -4981,10 +5065,20
Hi Richard,
I've revised the patch, sorry about sloppy formatting in the previous one.
Full bootstrap/regression tests are still running, but the changes are pretty
trivial.
Ok for trunk assuming tests finish clean?
>Joel Hutton writes:
>> @@ -277,6 +277,81 @@ optab_for_t
Ping. Is there still interest in refactoring vect-patterns to internal_fn's?
> -Original Message-
> From: Joel Hutton
> Sent: 07 June 2021 14:30
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Biener ; Richard Sandiford
>
> Subject: [vect-patterns][RFC] Refactor
-09-29 Joel Hutton
PR target/96837
* tree-vect-slp.c (vect_analyze_slp): Do not call
vect_attempt_slp_rearrange_stmts for vector constructors.
gcc/testsuite/ChangeLog:
2020-09-29 Joel Hutton
PR target/96837
* gcc.dg/vect/bb-slp-49.c: New test.From
avr-libc here: https://github.com/avrdudes/avr-libc/pull/881
In addition, this patch-set includes a patch to remove non-printable
characters from avr-devices.cc.
Joel Holdsworth (2):
avr: Added AVR-DA and DB MCU series
avr: Removed errant control characters
gcc/config/avr/avr-devices.cc
leaking into cc1.
Signed-off-by: Joel Holdsworth
---
gcc/config/avr/avr-mcus.def | 22 ++
gcc/config/avr/gen-avr-mmcu-specs.cc | 2 +-
gcc/config/avr/gen-avr-mmcu-texi.cc | 2 +-
gcc/doc/avr-mmcu.texi| 6 +++---
4 files changed, 27 insertions(+), 5
Signed-off-by: Joel Holdsworth
---
gcc/config/avr/avr-devices.cc | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/avr/avr-devices.cc b/gcc/config/avr/avr-devices.cc
index aa284217f50..ff6a5441b77 100644
--- a/gcc/config/avr/avr-devices.cc
+++ b/gcc/config/avr/avr-devices.cc
Hi all,
These patches refactor the widening patterns in vect-patterns to use
internal_fn instead of tree_codes.
Sorry about the delay, some changes to master made it a bit messier.
Bootstrapped and regression tested on aarch64.
Joel
> > diff --git a/gcc/tree-vect-patterns.c b/gcc/tre
Ping patch.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592668.html
Thanks
Joel Holdsworth
101 - 200 of 237 matches
Mail list logo
