On Tue, 13 Nov 2012, Richard Henderson wrote:
> As discussed elsewhere. Tested on x86_64-linux.
> +2012-11-13 Richard Henderson
> +
> + * configure.ac: Move libsanitizer logic to subdirectory.
> + * configure: Regenerate.
> +
Thanks and sorry for copypasting the wrong pattern in the f
On Wed, 14 Nov 2012, Jakub Jelinek wrote:
> > Which brings us to the question of what to do with the patch for 4.8.
> > It's true that you made the deadline for stage1 closure. But there will
> > be no users of this feature, so it begs the question of why we should
> > apply it now. Have you a co
On Sun, 18 Nov 2012, H.J. Lu wrote:
> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini wrote:
> > Il 18/11/2012 00:54, H.J. Lu ha scritto:
> >> +@if gcc-bootstrap
> >> +ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),)
> >> +LIBASAN_LIBS=-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
> >> +endi
On Sat, 17 Nov 2012, Diego Novillo wrote:
> I have now committed all 25 parts of this patch as rev 193595. Please
> CC me on any problems that you think may be related to this rewrite.
That seems to have trigged some bug in gcc-4.4-era. See
PR55381. There are a lot of suspicious warnings from v
On Sun, 18 Nov 2012, Diego Novillo wrote:
> My cris-elf builds worked fine, but config-list.mk only builds stage
> 1, it does not build libgfortran. Can you give me instructions on how
> to build your target on my x86 workstation?
Better see the PR for cc1 command-line and preprocessed C-file.
b
On Sun, 18 Nov 2012, Andreas Tobler wrote:
> Is there a minimum gcc to bootstrap current trunk?
> I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
> succeeds.
A gcc-4.1.2 has worked for me in the past, before this recent
vec.h change. I think that's the minimum version reportedly
w
On Sun, 18 Nov 2012, Andreas Tobler wrote:
> On 18.11.12 20:11, Hans-Peter Nilsson wrote:
> > On Sun, 18 Nov 2012, Andreas Tobler wrote:
> >> Is there a minimum gcc to bootstrap current trunk?
> >> I currently fail to bootstrap trunk with a 4.2.1 gcc, but a 4.6
> &g
On Sun, 18 Nov 2012, Paolo Bonzini wrote:
> Il 18/11/2012 16:59, Hans-Peter Nilsson ha scritto:
> > Nice, but I agree with the other poster that this'd IMHO be
> > better as --enable-checking=asan (or actually,
> > --enable-checking=all,asan).
>
> Yeah, that's
On Mon, 12 Nov 2012, Eric Botcazou wrote:
> > This is a target-specific blockage insn, but with the general form
> > found in all targets defining it. The default blockage is an empty
> > asm-volatile, which is what cse_insn recognized. The blockage insn is
> > there to "prevent scheduling" of th
On Tue, 20 Nov 2012, Jakub Jelinek wrote:
> 2012-11-20 Jakub Jelinek
>
> * Makefile.in (tree-if-conv.o): Depend on $(TARGET_H), $(EXPR_H)
> and $(OPTABS_H).
> * config/i386/sse.md (maskload, maskstore): New expanders.
(etc., new patterns, but nothing for md.texi)
Missing docum
On Sun, 18 Nov 2012, Jan Hubicka wrote:
> > > > this patch reduces max-peeled-insns and max-completely-peeled-insns
> > > > from 400
> > > > to 100. The reason why I am doing this is that I want to reduce code
> > > > bloat
> > > > caused by my cunroll work that enabled a lot more unrolling then
On Thu, 22 Nov 2012, Kirill Yukhin wrote:
> Hi folks,
>
> This patch adds an utility for dumping MD-files after iterators and
> define_substs expanding. The new utility is named genmddump and is
> built along with other gen* programs.
>
> I also added new target to Makefile to invoke this utility.
Without this, I got weird ERRORs and those Tcl backtraces you come
to hate, instead of the expected FAILs. Committed as obvious after
running a failing guality test and obvserving the intended change.
(Well ok, *adding an explanatory comment* is apparently not obvious,
but I'll take that liberty..
On Fri, 23 Nov 2012, Georg-Johann Lay wrote:
> Here are some more fixes for 16-bit int and similar.
> * gcc.c-torture/execute/20120919-1.x: New file (int32plus).
No, you should be able to use dg-directives in the main file these days.
(The .x files are obsolete since a few years, IIRC.)
br
On Fri, 23 Nov 2012, H.J. Lu wrote:
> On Fri, Nov 23, 2012 at 9:38 AM, Jakub Jelinek wrote:
> > On Fri, Nov 23, 2012 at 09:23:37AM -0800, H.J. Lu wrote:
> >> This patch allocates extra 16 bytes for -fsanitize=address so that
> >> asan won't report read beyond memory buffer. It is used by
> >> boot
On Sat, 24 Nov 2012, Steven Bosscher wrote:
> Hello,
>
> The DELAY_SLOTS_FOR_EPILOGUE target macro, and the related
> ELIGIBLE_FOR_EPILOGUE_DELAY macro, are unused. The attached patch
> removes them.
>
> OK for trunk?
Obviously; Jeff Law preapproved their removal long ago.
(I forgot about it.) Bu
On Sun, 25 Nov 2012, Steven Bosscher wrote:
> stop_search_p will reach the default case on DEBUG_INSN, and the
> default case is "gcc_unreachable()". I suppose this means nobody is
> using DWARF3+ on a dbr_sched target, it can't possibly ever have
> worked. Eric?
There must be something else (som
Thanks for the reviews!
On Mon, 19 Nov 2012, Eric Botcazou wrote:
> Thanks for the analysis. I don't think that the redundancy of the clobber
> list matters here: the clobbers are added to all asm statements, volatile or
> not, so they aren't intended to make the volatile statements more precise
On Mon, 26 Nov 2012, Georg-Johann Lay wrote:
> Hans-Peter Nilsson wrote:
> > On Fri, 23 Nov 2012, Georg-Johann Lay wrote:
> >> Here are some more fixes for 16-bit int and similar.
> >
> >>* gcc.c-torture/execute/20120919-1.x: New file (int32plus).
> &g
I don't see this posted on gcc-patches@, but...
On Mon, 26 Nov 2012, ste...@gcc.gnu.org wrote:
> testsuite/
> * testsuite/gcc.dg/20050811-1.c: Change -dv option to -graph option
> to -fdump-rtl-all.
> * testsuite/gcc.dg/pr37858.c: Remove -dv option.
...looks like you missed:
Ex
I quoted the whole discussion, see a single line below.
On Mon, 19 Nov 2012, Eric Botcazou wrote:
> > Unfortunately, it causes regressions; read on for a very brief
> > analysis.
> >
> > For x86_64-linux (base multilib):
> >
> > Running
> > /home/hp/gcctop/tmp/pr55030-2n/gcc/gcc/testsuite/gcc.dg/g
On Tue, 27 Nov 2012, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 06:44:23AM -0500, Hans-Peter Nilsson wrote:
JFTR: No I didn't, Eric wrote the below. But, it made sense to me. :)
> > > We apparently have a small conflict between the meaning of volatile asms
> > >
On Tue, 27 Nov 2012, Jakub Jelinek wrote:
> 2012-11-26 Jakub Jelinek
>
> PR debug/36728
> PR debug/55467
> * cselib.c (cselib_process_insn): If cselib_preserve_constants,
> don't reset table and exit early on volatile insns and setjmp.
> Reset table afterwards on se
(No cans of worms opened here, I believe...)
For MMIX with the default, Knuth's ABI (returning values in register
$0, through the register stack), function return values are prepared
in a register-swapped fashion due to the way the register stack works,
which has to be expressed as:
(parallel [
On Sat, 1 Dec 2012, Eric Botcazou wrote:
> > Of course this matters only to >64bit (i.e. >registersize) values like
> > TImode, alias __int128. The problem here is that group-loading a
> > constant for a function return-value doesn't work; it's passed to
> > simplify_gen_subreg which horks on the
> From: Marc Glisse
> Date: Tue, 14 May 2013 13:47:23 +0200
> Here is what I tested during the night, I'll just rename the function.
> I took the chance to remove an unnecessary alternative in TRUTH_XOR_EXPR.
>
> Passes bootstrap+testsuite on x86_64-linux-gnu.
>
> 2013-05-14 Marc Glisse
>
>
> From: Jan Hubicka
> Date: Wed, 5 Jun 2013 16:18:52 +0200
> * class.c (emit_register_classes_in_jcr_section): Use DECL_PRESERVE_P
> instead of mark_decl_referenced.
>
> * decl2.c (maybe_make_one_only): Use forced_by_abi instad of
> mark_decl_referenced.
>
On Fri, 7 Jun 2013, Richard Henderson wrote:
> I've had a brief look over the instances of D_A within the tree atm. Most of
> them carry the cut-n-paste comment "for the same reasons". These I believe
> never intended an ABI change, and were really only interested in optimization.
>
> But these I
(Thanks to people CC'ed and others forgotten; I hope I
incorporated at least some of everyone's suggestions.)
First, as noted, the instructions are outdated due to repos merging,
splitting, moving and switching, with fallout such as it now seemed
odd as-is with one minor component randomly being n
On Wed, 10 Sep 2014, Oleg Endo wrote:
> On Wed, 2014-09-10 at 15:46 -0400, Hans-Peter Nilsson wrote:
> > (Thanks to people CC'ed and others forgotten; I hope I
> > incorporated at least some of everyone's suggestions.)
> >
> > [...]
> > Also, the ide
Ping! <http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00402.html>
> From: Hans-Peter Nilsson
> Date: Thu, 4 Sep 2014 23:40:40 +0200
> The directory at $target_header_dir is already inspected in
> gcc/configure, for e.g. glibc version and stack protector
> support, but not for
Ping! <http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00403.html>
> From: Hans-Peter Nilsson
> Date: Thu, 4 Sep 2014 23:42:28 +0200
> This adds an option to allow programs and libraries built
> *without* inhibit_libc to stay compatible with system libraries
> (really: libgc
On Wed, 17 Sep 2014, Janne Blomqvist wrote:
> On Tue, Sep 16, 2014 at 11:17 AM, FX wrote:
> >>> 2014-09-05 Janne Blomqvist
> >>>
> >>>PR libfortran/62768
> >>>* io/io.h (gfc_unit): Store C string for the filename.
> >>>* io/close.c (st_close): Use gfc_unit.filename.
> >>>* io/in
On Wed, 17 Sep 2014, Janne Blomqvist wrote:
> > /tmp/hpautotest-gcc1/gcc/libgfortran/io/inquire.c:97:41: error: 'gfc_unit'
> > has no member named 'file'
> > fstrcpy (iqp->name, iqp->name_len, u->file, u->file_len);
> > ^
> > /tmp/hpautotest-gcc1/gcc/l
On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
> On Wed, 17 Sep 2014, Janne Blomqvist wrote:
> > Oops, I forgot to update some parts in an #ifdef branch that isn't
> > taken on my target. I'll try to find time to fix it later tonight. If
> > you're in a hurr
On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
> On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
> > On Wed, 17 Sep 2014, Janne Blomqvist wrote:
> > > Oops, I forgot to update some parts in an #ifdef branch that isn't
> > > taken on my target. I'll try to
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
> On Wed, Sep 17, 2014 at 11:36 PM, Hans-Peter Nilsson
> wrote:
> > On the other hand, the tree *is* broken for some ports; I'd
> > prefer regressions to that. So, unless you're onto this, how do
> > you feel about
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
> On Thu, Sep 18, 2014 at 12:57 AM, Hans-Peter Nilsson
> wrote:
> > 'k so we'll track the regressions in a PR.
>
> Do you prefer to tack on to 62768 or a new PR?
Hijacking 62768 for the purposes of reporting a regress
On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
> On Thu, 18 Sep 2014, Janne Blomqvist wrote:
> > On Thu, Sep 18, 2014 at 12:57 AM, Hans-Peter Nilsson
> > wrote:
> > > 'k so we'll track the regressions in a PR.
> >
> > Do you prefer to tack on to
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
> > If you look back at the patch I posted, there's a
> > typo. :-} Duly warned about, but I'd rather expect the build to
> > fail.
>
> Yes, strange that it didn't fail. There's no prototype for cf_fstrcpy,
> and since we use std=gnu11 prototypes should
> From: Jeff Law
> Date: Fri, 19 Sep 2014 08:29:16 +0200
> On 09/12/14 11:51, Hans-Peter Nilsson wrote:
> > Ping! <http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00403.html>
> >> libgcc:
> >>* crtstuff.c [EH_FRAME_SECTION_NAME &&a
-lcio instead, assuming the corresponding newlib
patch[2] to move msp430's nosys implementation to libcio.a is also used.
gcc/ChangeLog
2014-09-22 Peter A. Bigot
* config/msp430/msp430.h: Remove automatic -lnosys when -msim absent.
[1] http://www.mail-archive.com/mspgcc-
> From: Thomas Schwinge
> Date: Tue, 23 Sep 2014 23:21:05 +0200
> Hi!
>
> On Thu, 4 Sep 2014 23:40:40 +0200, Hans-Peter Nilsson xis.com> wrote:
> > The directory at $target_header_dir is [...]
>
> > gcc:
> > * configure.ac (target_header_dir): Mov
On Wed, 19 Jun 2013, DJ Delorie wrote:
>
> Third revision, mostly the same as the last, haven't heard any additional
> feedback in the last few weeks. Ok to commit yet?
> [libgcc]
>
> * config.host (msp*-*-elf): New.
> * config/msp430/: New port.
A random spotting; copyright header r
On Wed, 26 Jun 2013, Iyer, Balaji V wrote:
> Hello Everyone,
> This patch will fix a FAIL in one of the test cases for array
> notations. The reason for fail is that the array sizes were huge and thus it
> was causing a stack overflow. This patch should fix the issue. I am
> committing thi
Eric Botcazou asked that I re-apply this previously reverted patch, so
here goes. Bootstrapped+regression-test x86_64-unknown-linux-gnu at
r200585 with and without -m32. The 32-bit i686-* aka. -m32 previously
exposed PR55030. Though that PR was originally about the regression
causing the revert,
On Mon, 1 Jul 2013, Andrew Pinski wrote:
> On Sun, Jun 30, 2013 at 8:32 PM, DJ Delorie wrote:
> >
> > Given how much trouble I went through to make it the default, I'd
> > rather not revert all that work... especially since the flag is
> > *required* for proper operation of the hardware on many
On Sat, 13 Jul 2013, Bernd Edlinger wrote:
> Hi Sandra,
>
> On Fri, 5 Jul 2013, Hans-Peter Nilsson wrote
> > Or - maybe more acceptable - an optional warning, say
> > -Wportable-volatility, to warn about code for which separate
> > incompatbile definitions on differ
On Wed, 17 Jul 2013, Zoran Jovanovic wrote:
> Hello,
> This patch adds new optimization pass that combines several adjacent bit
> field accesses that copy values from one memory location to another into
> single bit field access.
>
> Example:
>
> Original code:
> D.1351;
> D.1350;
> D.13
On Sat, 20 Jul 2013, Göran Uddeborg wrote:
> While translating GCC (to Swedish), I've occasionally come across
> obviously truncated strings. Often, it has been caused by multiple
> lines used for the description in .opt files. I've tried to file
> reports about them.
>
> One such report I made
On Tue, 23 Jul 2013, Bernd Edlinger wrote:
> H-P: I hope you can approve my little patch for trunk now,
> although it turned out to be less trivial than I'd have expected.
Sorry, I'm not an approver. (People who are not approvers are
welcome to review any gcc patch where they might say something
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
> This patch adds an atomic type qualifier to GCC. It can be accessed via
> __attribute__((atomic)) or in C11 mode via the _Atomic keyword.
> HP, you might want to give this a try and see if you can get the alignment
> correct for the cris port finally
> - ftp://ftp.axis.se/pub/users/hp/pgccfd/";>Porting GCC for
> + http://ftp.axis.se/pub/users/hp/pgccfd/";>Porting GCC for
>Dunces by Hans-Peter Nilsson < href="mailto:hans-peter.nils...@axis.com";>hans-peter.nils...@axis.com>.
>
>http://cobolforgcc.sourceforge.net/cobol_toc.html";>Using,
>
brgds, H-P
For cris-elf at r198164:
...
libtool: compile: /tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc/xgcc
-shared-libgcc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc -nostdinc++
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/src
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/s
Its BRANCH_COST being the default, MMIX is one of them, here
doing away with a few regressions. Committed.
gcc/testsuite:
* lib/target-supports.exp
(check_effective_target_logical_op_short_circuit): Add mmix-*-*
to the list.
Index: gcc/testsuite/lib/target-supports.exp
==
That test now looks a bit silly with the dozen+1 exceptions. But, I
guess with just this one(?) test there's little sense in adding an
effective target to describe that division by 0 doesn't signal. Other
than keeping it in just one place, of course. But, committed.
gcc/testsuite:
* gcc
On Thu, 24 Apr 2014, Jeff Law wrote:
> On 04/16/14 18:20, seg...@kernel.crashing.org wrote:
> > PR target/60822
> > 2014-04-16 Segher Boessenkool
> >
> > * config/m68k/m68k.md (extendplussidi): Don't allow memory for
> > operand 1.
> Thanks. I tweaked the comment and added the testcase
On Tue, 13 May 2014, Joseph S. Myers wrote:
> On Mon, 12 May 2014, Hans-Peter Nilsson wrote:
> > On Thu, 24 Apr 2014, Jeff Law wrote:
> > > On 04/16/14 18:20, seg...@kernel.crashing.org wrote:
> > > > PR target/60822
> > > > 2014-04-16 Segher Boessenko
On Mon, 5 May 2014, Jan Hubicka wrote:
> Hi,
> this patch fixes unfortunate thinko in get_class_context that invalidates
> transitions from non-POD type to a polymorphic type that may happen by virtue
> of placement new and apparently breaks openJDK and Qt. I really tried to keep
> placement new in
On Mon, 19 May 2014, Janne Blomqvist wrote:
> Hello,
>
> some systems such as GNU Hurd, don't define PATH_MAX at all, and on
> some other systems many syscalls apparently work for paths longer than
> PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
> characters, but rather use heap allo
On Fri, 23 May 2014, Janne Blomqvist wrote:
> On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson wrote:
> > This patch broke build for newlib targets; you need AC_DEFINE
> > clauses for those in the "if-then"-leg where you patched the
> > "else"-leg.
&g
On Sun, 26 Jan 2014, Mikael Morin wrote:
> Le 18/01/2014 21:17, Mikael Morin a écrit :
> > Well, I guess that due to the touchy nature of the bug, there are cases
> > that work by luck on old versions and fail (by unluck) on newer ones.
> > Thus, I will backport in a few days to 4.8 and 4.7.
> >
>
On Sun, 8 Dec 2013, Bruce Korb wrote:
> On 12/08/13 13:06, Gerald Pfeifer wrote:
> > Lovely. Thank you very much!
(Looks like nobody replied to this and it isn't committed.)
> $ svn diff
> Index: configure.ac
> ===
> --- configure.a
On Mon, 27 Jan 2014, Mikael Morin wrote:
> Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
> > On Sun, 26 Jan 2014, Mikael Morin wrote:
> >> Le 18/01/2014 21:17, Mikael Morin a écrit :
> >>> Well, I guess that due to the touchy nature of the bug, there are cases
On Mon, 27 Jan 2014, Bruce Korb wrote:
> On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson wrote:
> > On Sun, 8 Dec 2013, Bruce Korb wrote:
> >> On 12/08/13 13:06, Gerald Pfeifer wrote:
> >> > Lovely. Thank you very much!
> >
> > (Looks like nob
On Mon, 27 Jan 2014, Richard Biener wrote:
> >Huh, so we have C for cross-builds and C++ for bootstraps.
>
> No, we use a C host compiler in both cases. Only stages 2 and 3 build with a
> C++ compiler.
Tomatos potatoes! As fortran isn't built until then, it'll be
built as C for cross-builds and
On Tue, 28 Jan 2014, Andreas Schwab wrote:
> Hans-Peter Nilsson writes:
>
> > See is_release in that same configure.ac, that might be the only
> > additional condition that's needed.
>
> is_release only distinguishes a release from a snapshot, but does not
> say a
On Tue, 4 Feb 2014, Rainer Orth wrote:
> AFAICT the gcc.dg/binop-xor1.c test is XPASSing everywhere since about
> 20131114:
Bah, missing analysis. "Everywhere" does not include cris-elf,
powerpc64-unknown-linux-gnu, m68k-unknown-linux-gnu,
s390x-ibm-linux-gnu, powerpc-ibm-aix7.1.0.0.
>
> XPASS:
On Thu, 13 Feb 2014, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Hans-Peter Nilsson writes:
> >> On Tue, 4 Feb 2014, Rainer Orth wrote:
> >>> AFAICT the gcc.dg/binop-xor1.c test is XPASSing everywhere since about
> >>> 20131114:
> >>
On Fri, 14 Feb 2014, Jakub Jelinek wrote:
> On Fri, Feb 14, 2014 at 10:37:03AM -0700, Jeff Law wrote:
> > On 02/13/14 03:54, Richard Sandiford wrote:
> > >Richard Sandiford writes:
> > >>Hans-Peter Nilsson writes:
> > >>>On Tue, 4 Feb 2014, Rainer Ort
There was a new effective-target predicate (thanks, Richard S),
but the droplet that broke the camel's back or something, wasn't
added to its target-list. Committed after brief testing
(checking that tests fail before, checking that tests pass after
patch).
Other observations:
- LOGICAL_OP_NON_SH
On Tue, 25 Feb 2014, bin.cheng wrote:
> Hi,
> This patch is to fix regression reported in PR60280 by removing forward loop
> headers/latches in cfg cleanup if possible. Several tests are broken by
> this change since cfg cleanup is shared by all optimizers. Some tests has
> already been fixed by
Oops. I've left cris-linux and crisv32-linux alone and rot set
in...quite some time ago. The prerequisite config.gcc I kind of
knew about, but it fell in and out of mind; it was finally noted
in the referenced PR, but just as a side-comment. Regarding the
removed comment, there seems to be nothi
On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote:
> Hi!
>
> As a leftover of r210931, an unused variable resulted in:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wmissing-fo
On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote:
> This was a build using GCC's ./contrib/config-list.mk to do the build.
> It passes --enable-werror-always to top-level `configure', this is
> where the -Werror comes from.
Aha. Looks like it's of more use than theoretical pain; sounds
like this shou
On Tue, 22 Jul 2014, Richard Biener wrote:
> On Fri, 18 Jul 2014, Hans-Peter Nilsson wrote:
>
> > On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote:
> > It should be per-target because there *may* be port-specific
> > constructs warned about by buggy previous-but-not-ancient
On Tue, 22 Jul 2014, Mike Stump wrote:
> On Jul 22, 2014, at 1:40 PM, Hans-Peter Nilsson wrote:
> >
> > *Developers* (or rather, people cross-building non-released gcc
> > source in their usual setup) don't use the fairly old or even
> > broken host gcc versions th
On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote:
> On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson
> wrote:
> > Jan-Benedict, which host gcc version do you use when getting
> > most targets to build with config-list.mk? Maybe we can just
> > set the initial version
On Fri, 25 Jul 2014, Jan-Benedict Glaw wrote:
> On Thu, 2014-07-24 16:30:13 -0400, Hans-Peter Nilsson
> wrote:
> > On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote:
> > > On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson
> > > wrote:
> > > > Jan-Benedi
On Fri, 25 Jul 2014, Hans-Peter Nilsson wrote:
> Anyway, on to the point of this message: by the quoted list it
> seems you have a local host called pluto using 4.9.1 as the host
> gcc for some build; does config-list.mk work for that?
Never mind, I found a 4.9.1 installation on gcc11
On Mon, 3 Mar 2014, Richard Sandiford wrote:
> AIUI:
Reading back the references don't yield any dissenting
flash-backs, FWIW.
So, a (use fp) then a (clobber fp)? That was probably just too
weird for me to think of, much like a hypercorrect ending of the
previous clause. :)
Thanks for dealing w
On Fri, 4 Apr 2014, dw wrote:
> Problem description:
> The existing documentation does an inadequate job of describing gcc's
> implementation of the "asm" keyword. This has led to a great deal of
> confusion as people struggle to understand how it works. This entire section
> requires a rewrite th
On Mon, 31 Mar 2014, Dominique d'Humières wrote:
> Updated gfortran.dg/fmt_en.f90 to skip some tests not
> supported on i?86-*-solaris2.9* and hppa*-*-hpux* (these tests
> assume rounding to nearest and to even on tie, AFAICT
> i?86-*-solaris2.9* rounds real(16) to zero and hppa*-*-hpux*
> rounds
On Sat, 12 Apr 2014, Dominique Dhumieres wrote:
> > This test, after the update on 4.8 in r209070 when the test-case was
> > modified substantially (not really covered by the ChangeLog entry) to be
> > identical to that on trunk, apparently takes a different route in the
> > fortran run-time libra
On Tue, 8 Apr 2014, dw wrote:
> > The general bits seems like a big improvement, but what worries
> > me is the deleted text. For example, the aspects of "Explicit
> > Reg Vars" when *directly feeding an asm* and how to write them
> > to avoid the named registers being call-clobbered between
> > a
On Sun, 13 Apr 2014, dw wrote:
> So, how about this:
>
> 1) I put the (rephrased) text and examples at the end of "Local Reg Vars" page
> (starts with "Sometimes"):
> http://www.LimeGreenSocks.com/gcc/Local-Reg-Vars.html
> 2) In the constraint paragraph for both Input and Output, I added this: "If
On Fri, 11 Apr 2014, Jakub Jelinek wrote:
> On Thu, Apr 10, 2014 at 02:18:26PM +0100, Ramana Radhakrishnan wrote:
> > I see failures from last night on aarch64-none-elf and arm-none-eabi
> > (both bare-metal) configurations even after moving up to dejagnu
> > 1.5.1. If this can't be fixed easily s
On Mon, 14 Apr 2014, Jakub Jelinek wrote:
> On Sun, Apr 13, 2014 at 09:24:28PM -0400, Hans-Peter Nilsson wrote:
> > On Fri, 11 Apr 2014, Jakub Jelinek wrote:
> >
> > > On Thu, Apr 10, 2014 at 02:18:26PM +0100, Ramana Radhakrishnan wrote:
> > > > I see failures
On Tue, 15 Jan 2013, Janis Johnson wrote:
> Most of the tests in gcc.c-torture/execute/builtins that use LTO torture
> options "-O2 -flto -fuse-linker-plugin -fno-fat-lto-objects" fail to
> link on EABI and ELF targets with multiple definitions for either memset
> or strlen. I filed PR testsuite/5
Ever since it was changed to a "run" test (from the default
"compile", i.e. just producing assembly code), the test
gfortran.dg/inquire_10.f90 has failed for newlib targets while
linking, because (besides cygwin and some linux support), newlib
doesn't have getcwd:
/tmp/ccNhxU2l.o: In function `MAI
> From: Janne Blomqvist
> Date: Sun, 20 Jan 2013 20:14:11 +0100
> On Sun, Jan 20, 2013 at 2:29 AM, Hans-Peter Nilsson
> wrote:
> > Ever since it was changed to a "run" test (from the default
> > "compile", i.e. just producing assembly code), the te
> From: Kenneth Zadeck
> Date: Mon, 28 Jan 2013 02:02:41 +0100
> this looks good to me. does your patch also address the vec_concat
> issue that marc raised?
You mean the issue being "same thing there"? I can confirm that
(I've stumbled upon) the same issue being there (i.e. similarly
applies
On Mon, 28 Jan 2013, nick clifton wrote:
> > Also, could you close its duplicates, bugs 36798 and 36966?
>
> Sorry no. I do not actually own these PRs, so I cannot close them. :-(
Sorry if I misinterpret, but it seems a reminder is in order:
magic powers are attached to whome...@gcc.gnu.org accou
> From: Hans-Peter Nilsson
> Date: Mon, 28 Jan 2013 23:14:21 +0100
> * doc/rtl.texi (vec_concat, vec_duplicate): Mention that
> scalars are valid operands.
Finally committed as obvious after brief check of generated dvi
and info.
brgds, H-P
> Date: Tue, 27 Sep 2011 19:23:22 +0200
> From: Jan Hubicka
> this patch updates testsuite to cover both fat and slim LTO when linker plugin
> is used and also both linker plugin and collect2 paths. I didn't wanted to
> slow down testing too much so I just distributes the flags across existing
> Date: Fri, 21 Oct 2011 00:19:32 +0200
> From: Jan Hubicka
> Yes, if we scan assembler, we likely want -fno-fat-lto-objects.
> > then IIUC you need to patch *all* torture tests that use
> > scan-assembler and scan-assembler-not. Alternatively, patch
> > somewhere else, like not passing it if ce
> Date: Fri, 21 Oct 2011 17:44:15 +0200
> From: Jan Hubicka
> I also noticed that tests scanning output of late optimization passes are
> now getting UNRESOLVED state with slim LTO. We don't really lose coverage
> here because we test fat LTO with the other compilation, but probably easiest
> is
> Date: Fri, 21 Oct 2011 20:34:05 +0200
> From: Jan Hubicka
> I guess we could make ipa-dump/rtl-dump/tree-dump scanning to disable fat lto
> and introduce variants intended to scan late tree dumps and ipa execution
> dumps...
Ok, sounds like a plan. Are there any such
scan-tests-with-late-thi
> Date: Mon, 24 Oct 2011 00:03:45 +0400
> From: Anatoly Sokolov
For future reference, please add the diff "-p" option for
readability. With subversion, you need to add the equivalence
of "diff-cmd = /home/hp/.scripts/svn-diff"
under [helpers] in your ~/.subversion/config and have a svn-diff
equi
Ping.
Subject changed from '[RFA:] fix breakage with "Update testsuite
to run with slim LTO"' except it doesn't fix *all* breakage
introduced by that patch, only the one I observed and intended
to fix.
> Date: Fri, 21 Oct 2011 04:29:20 +0200
> From: Hans-Peter Nilss
1401 - 1500 of 2382 matches
Mail list logo
