with a default languages make bootstrap and make
check.. I see an additional 8 passes, and no other change in the
testsuite results.
Jim
gcc/
2015-06-19 Jim Wilson
* config/aarch64/aarch64.md (mov:GPF): Don't call force_reg if
op1 is an fp zero.
(movsf_aarch64): Change cond
testcases.
Jim
gcc/
2015-06-29 Jim Wilson
PR target/65932
* config/arm/arm.h (PROMOTE_MODE): Don't set UNSIGNEDP for QImode and
HImode.
gcc/testsuite/
2015-06-29 Jim Wilson
PR target/65932
* gcc.target/arm/wmul-1.c (mac): Change a and b to int pointers. Cast
multiply operand
On 07/01/2015 11:26 AM, Jason Merrill wrote:
> I've been threatening to do this for a couple of months, and now that
> the regressions are under control I think it's time. This patch changes
> the default C++ dialect to C++14.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
This causes a buil
rying it now, I see that my build gets
past the point that it failed, so this does appear to work. I won't
be able to finish a proper test until tomorrow, but for now this patch
seems to work.
Jim
2015-07-01 Jim Wilson
* graphite-blocking.c (HAVE_isl): Include .
* graphite-dependencies.c
On Thu, Jul 2, 2015 at 6:08 AM, Richard Biener
wrote:
> On Thu, Jul 2, 2015 at 3:05 PM, Richard Biener
> wrote:
>> Yeah, I _think_ the fix is to move the isl includes below the system.h
>> include.
I tried this, and got a conflict for pretty much every macro defined
by ctype.h, e.g.
/usr/includ
On 07/01/2015 11:17 PM, Jim Wilson wrote:
> On Wed, Jul 1, 2015 at 10:21 PM, Jason Merrill wrote:
>> This document also says that "A workaround until libraries get updated is to
>> include or before any headers from that library."
>> Can you try modifying
On Tue, Jul 7, 2015 at 8:07 AM, Jeff Law wrote:
> On 06/29/2015 07:15 PM, Jim Wilson wrote:
> So if these "copies" require a conversion, then isn't it fundamentally
> wrong to have a PHI node which copies between them? That would seem to
> implicate the eipa_sra pas
On Thu, Jul 2, 2015 at 2:07 AM, Richard Earnshaw
wrote:
> Not quite, ARM state still has more flexible addressing modes for
> unsigned byte loads than for signed byte loads. It's even worse with
> thumb1 where some signed loads have no single-register addressing mode
> (ie you have to copy zero i
On Sun, May 19, 2019 at 5:22 AM Andreas Schwab wrote:
> ../../../libgo/go/runtime/mbitmap.go: In function
> ‘runtime.setMarked.runtime.markBits’:
> ../../../libgo/go/runtime/mbitmap.go:291:9: internal compiler error:
> Segmentation fault
> 291 | atomic.Or8(m.bytep, m.mask)
> | ^
On Wed, May 22, 2019 at 6:41 PM Ian Lance Taylor wrote:
> Jim, you can go ahead and commit that patch with a ChangeLog entry.
> (The files in go/gcc but not in go/gcc/gofrontend) are under normal
> GCC rules.) Thanks.
OK. Committed. I did an x86_64-linux go build and check to make sure
I didn'
On Wed, May 22, 2019 at 6:36 PM Cherry Zhang wrote:
> Jim, thank you for the fix! The patch looks good to me. Maybe we should also
> apply this to __atomic_add_fetch_4 and __atomic_add_fetch_8?
Sorry about the delay, I caught a virus last week and am behind on everything.
For 64-bit RISC-V thos
On Thu, May 30, 2019 at 11:11 AM Andreas Schwab wrote:
> Here are the test results:
> http://gcc.gnu.org/ml/gcc-testresults/2019-05/msg02903.html
I tried running RISC-V go checks on my system. I see 7 unexpected
failures for gcc check-go, 6 unexpected failures for check-gotools,
and 1 unexpected
This fixes a problem reported for the RISC-V Haiku OS port, where putting
STARTFILE_PREFIX_SPEC in riscv.h breaks their port because they put
libraries in different directories than the UNIX convention. The current
definition is definitely needed for Linux. It should not be needed for rtems
or em
On Wed, Jun 12, 2019 at 5:57 PM wrote:
> This patch adds libgcc configuration option to disable TM clone
> registry. This option helps to reduce code size for embedded targets
> which do not need transactional memory support.
This looks OK to me. It is worth pointing out that ARM already ships
c
On Wed, Jul 31, 2019 at 9:41 AM Maxim Blinov wrote:
> gcc/ChangeLog:
> 2019-07-31 Maxim Blinov
>
> * common/config/riscv/riscv-common.c: Check -march string ends
> with null.
>
> gcc/testsuite/ChangeLog:
> 2019-07-31 Maxim Blinov
>
> * gcc.target/riscv/attribute-10.c:
On Thu, Aug 1, 2019 at 4:58 AM Kito Cheng wrote:
> gcc/testsuite/ChangeLog:
> * g++.dg/lto/pr87906_0.C: Add dg-require-effective-target shared
> check.
> * g++.dg/lto/pr89330_0.C: Ditto.
OK.
Jim
On Thu, Aug 1, 2019 at 4:48 AM Kito Cheng wrote:
> gcc/ChangeLog
> * config/riscv/riscv.c (riscv_promote_function_mode): New.
> (TARGET_PROMOTE_FUNCTION_MODE): Use riscv_promote_function_mode.
> gcc/testsuite/ChangeLog
> * gcc.target/riscv/promote-type-for-libcall.c: New.
On Fri, Aug 2, 2019 at 12:11 AM Kito Cheng wrote:
> gcc/ChangeLog
> * config/riscv/riscv.c (riscv_promote_function_mode): New.
> (TARGET_PROMOTE_FUNCTION_MODE): Use riscv_promote_function_mode.
> gcc/testsuite/ChangeLog
> * gcc.target/riscv/promote-type-for-libcall.c: New.
On Mon, Aug 5, 2019 at 1:20 AM Kito Cheng wrote:
> gcc/ChangeLog
> * gcc/config/riscv/multilib-generator: Handle extensions
> combination correctly.
A ChangeLog entry should generally describe what a patch changes, not
what it does. So this should mention a new variable canonical
This fixes a problem with the GCC implementation of the ABI, where we are
accidentally emitting different code for the same struct when compiled by the
C and C++ compilers. This was found by LLVM developers comparing the LLVM ABI
to the GCC ABI.
This affects any struct with one or more zero-lengt
On Mon, Aug 5, 2019 at 11:56 PM Kito Cheng wrote:
> gcc/ChangeLog
> * gcc/config/riscv/multilib-generator: (canonical_order): Add 'g'.
> (arch_canonicalize): Support rv32g and rv64g and fix error
> handling.
Looks good to me.
Jim
On Mon, Aug 19, 2019 at 5:01 AM Segher Boessenkool
wrote:
>
> On Thu, Aug 15, 2019 at 12:22:46AM +0200, Jose E. Marchesi wrote:
> > --- a/configure
> > +++ b/configure
> > @@ -754,6 +754,7 @@ infodir
> > docdir
> > oldincludedir
> > includedir
> > +runstatedir
> > localstatedir
> > sharedstat
On Mon, Aug 19, 2019 at 12:15 PM Andrew Burgess
wrote:
> I don't see any reason why we couldn't add t1, and a0 to a7 into this
> set, and this is what this patch does.
SIBCALL_REGS already includes t1 and t2. It is t0 aka x5 that is
missing. I think this is wrong. As Andrew mentioned, this wil
On Mon, Aug 19, 2019 at 12:15 PM Andrew Burgess
wrote:
> * config.gcc: Add riscv-sr.o to extra_objs for riscv.
> * config/riscv/riscv-sr.c: New file.
> * config/riscv/riscv.c (riscv_reorg): New function.
> (TARGET_MACHINE_DEPENDENT_REORG): Define.
> * config
On Fri, Aug 23, 2019 at 12:13 AM Kito Cheng wrote:
> gcc/testsuite/ChangeLog:
> gcc.target/riscv/li.c: New test.
Thanks. This looks good.
This is incidentally a test for a new binutils patch that improves the
li macro to emit compressed instructions when possible. We need an
execution
On Thu, Aug 22, 2019 at 10:30 PM Jim Wilson wrote:
>
> On Mon, Aug 19, 2019 at 12:15 PM Andrew Burgess
> wrote:
> > I don't see any reason why we couldn't add t1, and a0 to a7 into this
> > set, and this is what this patch does.
>
> SIBCALL_REGS already incl
On Mon, Aug 19, 2019 at 12:15 PM Andrew Burgess
wrote:
> The solution presented in this patch offers a partial solution to this
> problem. By using the TARGET_MACHINE_DEPENDENT_REORG pass to
> implement a very limited pattern matching we identify functions that
> call _riscv_save_0 and _riscv_res
On Thu, Aug 22, 2019 at 10:59 PM Jim Wilson wrote:
> With a rv64gc/lp64d linux toolchain, I get 43 extra gcc failures. For
> C++ and Fortran I get a lot of link errors, so the results aren't very
> useful. Apparently we never tested this before.
> /scratch/jimw/fsf-testing/X
This was noticed while trying to test -msave-restore support. The
save/restore routines use the alternate return register t0/x5 which is
clobbered by the PLT header, so we can't use them in shared libraries.
This patch disables -msave-restore when -fpic (and -mplt), and emits a
warning if the user
On Sun, Aug 25, 2019 at 9:40 AM Jim Wilson wrote:
> The problem with the linux toolchain support for -msave-restore is
> that we forgot to add a version script to export the symbols. I made
> the obvious change to add a RISC-V specific libgcc version script, and
> now everything in
Shifting by more than the size of a SUBREG_REG doesn't work, so we either
need to disable splits if an input is paradoxical, or else we need to
generate a clean temporary for intermediate results.
This was tested with rv32i/newlib and rv64gc/linux cross builds and checks.
There were no regressions
On Thu, Sep 5, 2019 at 3:03 PM Segher Boessenkool
wrote:
> My big question is why do other targets not have this problem? Or what
> is it they do differently?
RISC-V doesn't have convenient sign/zero extend instructions. We also
have a 12-bit immediate, whereas most other RISCs have a 16-bit
im
On Sat, Aug 31, 2019 at 1:08 AM Andreas Schwab wrote:
> I think the problem is that riscv needs to use t-slibgcc-libgcc so that
> libgcc_s.so is a linker script.
Yes, thanks, that fixes the problem and works well. I've got a patch
using this solution now.
Jim
Thanks to Andreas Schwab for the pointer on how to fix this properly.
This re-enables -msave-restore for shared libraries, and uses the
t-slibgcc-libgcc file to get the save-restore routines included directly
in shared libraries so that we don't need to indirect through the PLT
to reach them, which
On Wed, Sep 18, 2019 at 3:27 AM Kito Cheng wrote:
> On Wed, Sep 18, 2019 at 6:25 PM Richard Biener wrote:
> > Since it is target specific and for non-primary/secondary targets
> > it's the RISC-V maintainers call whether to allow backporting this.
> > Generally wrong-code issues can be backported
Similar to a previous patch, adding a in_splitter arg to every function that
can be called from a define_split, so we can prevent calls to gen_reg_rtx
during combine, which can cause crashes.
Tested with riscv32-elf and riscv64-linux builds and checks with no
regressions.
Commmitted.
Jim
Without this patch, compiling a non-leaf function with -g -O0, we get
addis0,sp,16
.cfi_def_cfa 8, 0
...
lw s0,8(sp)
.cfi_restore 8
addisp,sp,16
.cfi_def_cfa_register 2
which clobbers the frame pointer before resetting the cfa to
On 11/18/18 7:28 AM, James Clarke wrote:
GCC will emit ".option (no)relax" in its outputted assembly, but when
using it as an assembler driver, such as for preprocessed assembly, it's
merely preprocessing and therefore will not generate this directive.
Therefore we should pass -mno-relax on to th
On Thu, Jun 20, 2019 at 12:50 PM Jim Wilson wrote:
> This looks OK to me. It is worth pointing out that ARM already ships
> compilers built this way, but they didn't bother adding a configure
> option. They just override Makefile variables in their build scripts.
> I think thi
Try to run "make install-pdf" on a system with dblatex and pdflatex installed
but not doxygen gives an error.
run_doxygen error: Could not find Doxygen 1.7.0 in path.
Looking at the build log, I see that this is also using xsltproc and xmllint.
Installing doxygen and running again, I get lots o
On Fri, Jul 5, 2019 at 11:19 PM Richard Sandiford
wrote:
> gcc/
> * config/riscv/pic.md (*local_pic_load_s)
> (*local_pic_load_u): Explicitly specify the mode iterator
> referenced by , giving...
> (*local_pic_load_s, *local_pic_load_u):
> ...these.
> * con
On Sat, Jul 6, 2019 at 1:26 AM Katsuhiro Suzuki wrote:
> This patch fixes ambiguous mode of some compare insns of RISC-V.
> Only sge, slt and sle are using but other compare insns use
> . It seems first group mode settings are ambiguous.
Richard Sandiford submitted a patch that fixes every port,
Fixes github.com/riscv/riscv-gcc issue #161. We were accidentally using
BITS_PER_WORD to compute shift counts when we should have been using the
bitsize of the operand modes. This was wrong when we had an SImode shift
and a 64-bit target.
Tested with 32-bit elf and 64-bit linux cross compiler bu
On 7/12/19 1:16 AM, Richard Sandiford wrote:
Ping. I think this is the only one of the series left.
2019-07-05 Richard Sandiford
gcc/
* config/mips/micromips.md (*movep):
Explicitly use for the mode attribute.
OK.
Jim
On Tue, Jul 16, 2019 at 12:42 AM Kito Cheng wrote:
> I'd like to back port this patch to GCC 8 and 9, should I send another
> patch mail or just wait ack from release manager?
I think it is only relevant to the gcc-9 branch. The buggy pattern
was added June 2018, which is a while after the gcc-8
On Mon, Jul 22, 2019 at 1:45 PM Ilia Diachkov
wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01609.html
I'm looking at this now. I've been busy dealing with far too many
problems, but have mostly caught up on my backlog, at least enough
that I can deal with this now. I think the c
On Mon, Jul 22, 2019 at 2:50 PM Jim Wilson wrote:
> On Mon, Jul 22, 2019 at 1:45 PM Ilia Diachkov
> wrote:
> > Ping: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01609.html
It looks good. I modified the ChangeLog entry a little to change
Added to New. I modified the doc entry to
This looks pretty good to me, and looks like it works the same way as
the binutils patches that already went in before the binutils-2.32
release. I just see some minor issues that need fixing.
On Tue, Feb 12, 2019 at 11:17 PM Kito Cheng wrote:
>
> From: Kito Cheng
>
> Kito Cheng
> Monk Chiang
This also looks mostly OK to me with only some minor issues that need
to be fixed.
On Tue, Feb 12, 2019 at 11:17 PM Kito Cheng wrote:
>
> From: Kito Cheng
>
> This patch added a configure time option,
> --with-riscv-attribute=[yes|no|default],
> run time option, -mriscv-attribute to control the
On Tue, Feb 26, 2019 at 7:00 PM Kito Cheng wrote:
> This version 2 of patch series for of RISC-V ELF attribute[1], first version
> can be found in[2-4].
> Most changes between last version is typo fixing and coding sytle fix, and a
> missing re-generated
> configure file.
This looks good. I se
On Wed, Mar 6, 2019 at 6:22 AM Andreas Schwab wrote:
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: New file.
I thought we had fixed this already. I vaguely recall discussing it
with you. But I see that nothing was checked in, and I see that you
posted a patch in November t
On Wed, Mar 13, 2019 at 11:53 AM Andrew Pinski wrote:
> This testcase seems generic, that is it has no ABI dependent values
> attached to it.
> Can it be moved to a more generic location instead? Maybe there are
> other targets which get this incorrect also.
I'm not aware of any other target tha
On Wed, Mar 13, 2019 at 11:39 AM Andrew Burgess
wrote:
> gcc/ChangeLog:
>
> PR target/89627
> * config/riscv/riscv.c (riscv_pass_fpr_single): Add offset
> parameter, and make use of it.
> (riscv_get_arg_info): Pass offset to riscv_pass_fpr_single.
>
> gcc/testsuite/
On Mon, Mar 18, 2019 at 3:13 AM Kito Cheng wrote:
> gcc/testsuite:
> Kito Cheng
> ChangeLog
> * gcc.target/riscv/arch-1.c: Update testcase.
OK. I committed with the ChangeLog entry reword to more accurately
describe the change.
Jim
This fixes the bug reported in PR 89411 where we accidentally generated a
%lo with an offset that overflowed at link time if the symbol was allocated
to an address just below the 2KB limit for %lo. This solves the problem
by checking for BLKmode references, pulling out the SYMBOL_REF_DECL, and
the
This adds a pipeline description for the SiFive 7 Series parts, and all
of the supporting patches to make this work. There is quite a bit of
infrastructure to add, as this is the first non-rocket-chip core that
we are adding to the RISC-V backend. This also adds options for the existing
sifive 3
This was accidentally broken by the patch adding ELF attribute support.
The __riscv_compressed predefined macro is not being defined when the
target supports the C extension. The fix adds testcases to verify that
all of the predefined macros are correct for various option combinations.
Tested wit
On 4/8/19 1:09 AM, Andreas Schwab wrote:
FAIL: gcc.target/riscv/arch-1.c (test for errors, line )
FAIL: gcc.target/riscv/arch-1.c (test for excess errors)
Excess errors:
cc1: error: '-march=rv32I': first ISA subset must be 'e', 'i' or 'g'
The testcase has to be fixed, but there is a locale iss
On Mon, Apr 8, 2019 at 1:10 PM Jim Wilson wrote:
> The testcase has to be fixed, but there is a locale issue that has me
> confused at the moment, because this testcase is actually working on one
> of my machines and failing on another one.
Confusion sorted. Turns out one of the tr
On Mon, Apr 8, 2019 at 1:40 AM Martin Liška wrote:
> * gcc.target/riscv/arch-1.c: Fix expected scanned pattern.
Thanks. I verified it is OK with cross testing.
Jim
On Tue, Apr 9, 2019 at 10:36 AM Iain Buclaw wrote:
> Any objection if I upstream the non-asm bits?
Doesn't all of it, except maybe the configure.tgt patch need to go
upstream first? And do you need some paperwork or button click from
David for D language patches for the copyright assignment?
Is
This improves optimization of code storing constants to memory. Given this
testcase:
void sub1 (int *a, long long *b) { *a = 1; *b = 1; }
an unpatched rv64 compiler emits two li instructions, one for an SImode pseudo
and one for a DImode pseudo. With the patch, we get a single DImode li insn.
On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote:
> From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and
> swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit
> cas using 32 bit one).
This is a known problem on our to do list, and there is already a
bu
On Tue, Apr 30, 2019 at 12:06 PM Jakub Jelinek wrote:
> I think you can e.g. have a look at what alpha does in
> alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit
> compare and swap either.
Thanks. I had noticed that the rs6000 port had what I needed, but
looking the alpha on
The SiFive 7 series cores have macro fusion support to convert a branch over
a single instruction into a conditionally executed instruction. This adds
a conditional move pattern, enabled only for the SiFive 7 series cores, that
implements the initial optimization support for this feature. This gi
On Tue, Apr 30, 2019 at 4:47 PM Jim Wilson wrote:
> The SiFive 7 series cores have macro fusion support to convert a branch over
> a single instruction into a conditionally executed instruction. This adds
> a conditional move pattern, enabled only for the SiFive 7 series cores, that
>
On Wed, May 1, 2019 at 6:14 PM Maciej Rozycki wrote:
> within inline assembly, to access IEEE exception flags. The use of
> these instructions is not allowed when building for a soft-float ABI.
Technically it is an architecture issue not an ABI issue. If you
compile for -march=rv32imac -mabi=il
On Fri, May 3, 2019 at 3:11 PM Maciej W. Rozycki wrote:
> Hmm, I've been thinking a little bit about this hybrid mode and I have
> one question: how do we pass the IEEE rounding mode setting between `fcsr'
> and softfp where we have `-march=rv32imafc -mabi=ilp32' and
> `-march=rv32imac -mabi=ilp3
Intel has announced end-of-life for IA-64 in Fall 2020, so if
someone else doesn't step up to maintain the port we might want to
think about deprecating it.
I committed the following change to remove myself as IA-64 maintainer.
Jim
2019-05-07 Jim Wilson
* MAINTAINERS: Remove
On 08/05/2016 12:18 AM, Andrew Pinski wrote:
This patch disables the forming of the load/store pairs for SImode if
we are tuning for ThunderX. I used the tuning flags route so it can
be overridden if needed later on or if someone else wants to use the
same method for their core.
+ if (mode ==
On Mon, May 30, 2016 at 12:45 AM, Richard Biener wrote:
> Joseph - do you know sth about why there's not a full set of divmod
> libfuncs in libgcc?
Because udivmoddi4 isn't a libfunc, it is a helper function for the
div and mov libfuncs. Since we can compute the signed div and mod
results from u
On Thu, Jun 9, 2016 at 1:43 AM, Kyrill Tkachov
wrote:
> On 03/06/16 21:32, Evandro Menezes wrote:
>> Shouldn't this read "The Qualcomm QDF24xx processors are now supported via
>> the"?
>>
> I used Jim's suggestion at
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01423.html.
> I don't have a stro
On Tue, May 31, 2016 at 2:56 AM, James Greenhalgh
wrote:
> As you're proposing to have this on by default, I'd like to give a chance
> to hear whether there is consensus as to this being the right choice for
> the thunderx, xgene1, exynos-m1 and qdf24xx subtargets.
I tested this on qdf24xx using
This adds a tuning structure for qdf24xx. This was tested with an
aarch64-linux bootstrap and a make check, with no regressions. I also
tested it with an x86_64-linux C make check to verify that I didn't
break the testsuite for non aarch64 targets.
I had to change one testcase because it assumes
On Mon, Jun 13, 2016 at 1:53 AM, James Greenhalgh
wrote:
> On Fri, Jun 10, 2016 at 03:48:38PM -0700, Jim Wilson wrote:
>> This adds a tuning structure for qdf24xx. This was tested with an
> Have you seen my recent patch for Cortex-A57 that changes the costs there
> to be relative
On Mon, Jun 13, 2016 at 3:01 AM, Kyrill Tkachov
wrote:
> Hi Jim,
>
> On 10/06/16 23:48, Jim Wilson wrote:
>>
>> This adds a tuning structure for qdf24xx. This was tested with an
>> aarch64-linux bootstrap and a make check, with no regressions. I also
>> test
On Fri, 2017-09-22 at 14:11 -0700, Andrew Pinski wrote:
> On Fri, Sep 22, 2017 at 11:39 AM, Jim Wilson
> wrote:
> >
> > On Fri, Sep 22, 2017 at 10:58 AM, Andrew Pinski
> > wrote:
> > >
> > > Two overall comments:
> > > * What about splittin
We have no targets that emit SDB debug info by default. We dropped all
of the SVR3 Unix and embedded COFF targets a while ago. The only
targets that are still able to emit SDB debug info are cygwin, mingw,
and msdosdjgpp.
I tried a cygwin build with sources modified to emit SDB by default, to
se
This just removes the header file and references to symbols defined in
that file.
Jim
gcc/
* debug.h: Delete sdb_debug_hooks.
* final.c: Delete sdbout.h include.
(final_scan_insn): Delete SDB_DEBUG check.
(rest_of_clean_state): Likewise.
* output.h:
This changes some sdbout.c file references to past tense, since they
are still useful to explain why the code was written this way.
Jim
gcc/
* xcoffout.c: Refer to former sdbout.c file.
(xcoffout_begin_prologue): Use past tense for sdbout.c reference.
---
gcc/xcoffout.c |
TYPE_SYMTAB_POINTER was only used by sdbout.c, so can now be removed.
Jim
gcc/
* tree-core.h (tree_type_common): Delete pointer field of
tree_type_symtab.
* tree.c (copy_node): Clear TYPE_SYMTAB_DIE instead of
TYPE_SYMTAB_POINTER.
* tree.h (TYPE_SYMT
This patch deletes the sdbout.c and sdbout.h files.
Jim
gcc/
* Makefile.in (OBJS): Delete sdbout.o.
(GTFILES): Delete $(srcdir)/sdbout.c.
* sdbout.c: Delete.
* sdbout.h: Delete.
---
gcc/Makefile.in |3 +-
gcc/sdbout.c| 1661 -
This removes the now obsolete SDB/coff info from the docs. I also
removed adb and sdb references, as sdb is obsolete, and most people
probably know adb as the android debug bridge, not the assembly
debugger. There are also some obsolete MIPS/Alpha ECOFF docs removed.
Jim
gcc/
* d
This removes the -gcoff option, and various sdb related references in
non-target files. I also poison SDB_DEBUGGING_INFO and SDB_DEBUG. I
didn't see any point in poisoning the other SDB_* macros, as no one has
used any of them in a very long time.
I noticed one odd thing from removing -gcoff, us
As a side effect, this reduces cygwin C testsuite passes by a bit over
700, because we are no longer torture testing the -gcoff. This is not
a regression.
An interesting thing to notice here is that we are torture testing
dwarf-2, but are not torture testing any of the later dwarf
versions. We d
This file is only used by cygwin, mingw and msdosdjgpp targets, which
explicitly set PREFERRED_DEBUGGING_TYPE after including this file, so
this change has no effect, except to eliminate an obsolete sdb
reference here.
Jim
gcc/
* config/dbxcoff.h (PREFERRED_DEBUGGING_TYPE): Set to
A trivial vxworks related patch.
Jim
gcc/
* config/vx-common.h (SDB_DEBUGGING_INFO): Delete undef.
---
gcc/config/vx-common.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/config/vx-common.h b/gcc/config/vx-common.h
index 5cc965c..d8f04ec 100644
--- a/gcc/config/vx-common
I changed some sdb references to past tense where they seemed to still
have some use. Otherwise, sdb references were removed.
Another interesting point here is that the x86 PE-COFF support is using
the gsym.h file to manually emit some sdb symbol info for the linker in
i386_pe_declare_function_ty
This is modifying comments that include text copied from the docs,
to match the changes made to the docs in a previous patch. These are
all trivial changes.
Jim
gcc/
* config/cris/cris.h: Delete SDB reference in comment.
* config/ia64/ia64.h: Likewise.
* config/mmi
Another trivial patch to drop a reference to the sdb debugger.
Jim
gcc/
* config/m68k/m68kelf.h (DBX_REGISTER_NUMBER): Delete SDB reference.
---
gcc/config/m68k/m68kelf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/m68k/m68kelf.h b/gcc/config/m68
Hand tested to verify that I didn't accidentally break passing -g to
the assembler.
Jim
gcc/
* config/mips/mips.h (SUBTARGET_ASM_DEBUGGING_SPEC): Delete gcoff*
support.
---
gcc/config/mips/mips.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/gcc/co
On 10/25/2017 02:28 PM, Jim Wilson wrote:
This just removes the header file and references to symbols defined in
that file.
Sorry, that should be removing sdbout.h header file includes. The
actual file removal occurs later in the patch series.
Jim
way I think it does..
OK?
Jim
2017-10-25 Jim Wilson
gcc/
* doc/invoke.texi (-fdebug-prefix-map): Expand documentation.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 254023)
+++ gcc/doc/invoke
On Thu, 2017-10-26 at 12:35 -0600, Sandra Loosemore wrote:
> On 10/26/2017 11:47 AM, Gerald Pfeifer wrote:
> > Thanks you for fleshing this out, Jim!
> >
> > This looks fine to me (modula Sandra's note). Just a question:
> > would
> > we refer to GDB instead of gdb here? It feels a little in bet
;d rather not do that. Or
leave -gcoff in as a supported option and ignore it in opts.c, which I
would also rather not do. I just want it gone. I can live with the
ignored option.
OK?
Jim
2017-10-26 Jim Wilson
gcc/
* common.opt (gcoff): Re-add as ignored option.
diff --git
te the gcoff entry 4 times for the 4
options, without the JoinedOrMissing, which is unnecessary if we
explicitly list them all. This seems to be the only easy way to get
the exact result we need, and doesn't look too bad, so this is what I
checked in.
Jim
2017-10-29 Jim Wilson
gcc/
I checked in my patch series today. I did some quick builds before
check in to look for mistakes, and am now doing full builds after check
in to reverify that I did it right.
Jim
Cygwin builds were accidentally broken by the patch for PR
sanitize/82517. This added uses of MAX_SUPPORTED_STACK_ALIGNMENT,
which for cygwin expands to a call to ix86_cfun_abi(), and hence we
need an include of tm_p.h which is currently missing.
Tested with a cygwin default languages bootstrap.
ONE:
^~~~
If I add a call to gcc_unreachable after the longjmp call, then it
builds on both linux and AIX. Anyone have a better idea on how to fix
this? If I don't get any responses in a few days, I will check it in
under the obvious rule, since it fixes a build failure.
Jim
2017-
tion
> enum memmodel);
> ^
Looks like alpha, sparc, and tilegx have the same problem. Fixed by
including memmodel.h before tm_p.h. Tested with quick x86_64-linux C
only bootstrap, and checked in under the obvious rule.
Jim
2017-10-30 Jim Wilson
gcc/
* gimplify.
301 - 400 of 467 matches
Mail list logo
