PR62250 (r219171) was about some fortran tests that used atomic
operations but failing on systems where -latomic is required.
The fix was to always add -latomic. That caused test-suite
regressions for targets that don't have libatomic, but where the
required operations are built-in (no separate
On Fri, 14 Nov 2014, Radovan Obradovic wrote:
index eb37bfe..ddaf8e0 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1605,6 +1612,11 @@ process_options (void)
/* Save the current optimization options. */
optimization_default_node = build_optimization_node (global_options);
Failed ever since added for non-scheduling targets due to:
/x/gcc/testsuite/gcc.dg/pr42629.c:1:0: warning: instruction scheduling not
supported on this target machine
Committed as obvious.
* gcc.dg/pr42629.c: Only pass scheduling options on scheduling targets.
Index: pr42629.c
Another fix for a non-regression FAIL. See the elaborate comment for
MIPS, updated to cover mmix-knuth-mmixware.
* gcc.dg/debug/debug-1.c: Pass -fno-if-conversion for
mmix-knuth-mmixware for the same reason as for MIPS.
* gcc.dg/debug/debug-2.c: Ditto.
Index:
On Fri, 2 Jan 2015, James Bowman wrote:
Sorry, should have been clearer.
Please can someone review and apply this patch, as I don't have write access
to the tree. Thanks.
JFTR: to apply this patch to config.sub and config.guess is
not the way to do it; not a valid request. Review of
On Wed, 31 Dec 2014, Tim Shen wrote:
On Wed, Dec 31, 2014 at 4:17 PM, David Edelsohn dje@gmail.com wrote:
FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc execution test
on AIX.
Oops, a dumb mistake from fixing a dumb mistake. Thanks David! :)
Bootstrapped and tested.
On Thu, 1 Jan 2015, Tim Shen wrote:
On Thu, Jan 1, 2015 at 5:06 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
But apparently not committed yet (at r219139) for some reason?
Oh, errr... I'm not sure if it needs a review by probably Jonathan?
I thought it was an obvious one-character typo
The lto/pr59626 tests, started regressing for cris-elf on trunk
with a commit in the range 218651:218661. Looks like a bug was
fixed, exposing a bug in the test-case; an assumption that the
mapping of a function C name to assembly name does not prefix
the name with any decoration. (Typically, an
On Fri, 12 Dec 2014, Joseph Myers wrote:
At least one target for this port should be added to
contrib/config-list.mk (and you should verify that the port builds cleanly
with --enable-werror-always, for both 32-bit and 64-bit hosts, when
building using current trunk GCC).
While doing that,
From: Richard Biener rguent...@suse.de
Date: Fri, 24 Oct 2014 09:56:51 +0200
On Fri, 24 Oct 2014, Hans-Peter Nilsson wrote:
Still, I don't understand exactly how your patch
introduces build-subdirectories where there were none before.
Maybe that +all-gcc: maybe-all-build-libcpp was wrong
From: Richard Biener rguent...@suse.de
Date: Thu, 23 Oct 2014 10:47:43 +0200
This adds a libcpp host module without NLS and ICONV support
and properly links genmatch against the build libcpp instead of
the host one.
Bootstrap running on x86_64-unknown-linux-gnu (stage1 all-gcc
finished
From: Hans-Peter Nilsson h...@axis.com
Date: Fri, 24 Oct 2014 06:32:06 +0200
The libcpp configure checks are actually run with gcc which is
bogus by itself, but apparently working. I guess the C vs. C++
declaration etc. differences for libcpp are mostly hidden by
using _GNU_SOURCE (through
On Sat, 20 Sep 2014, Jan-Benedict Glaw wrote:
Please note that nios2 failed in the same way a number of other
targets fail, too:
cr16-elf
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=351532
fr30-elf
On Thu, 2 Oct 2014, David Wohlferd wrote:
You want
=m (*( struct foo { char x[8]; } __attribute__((may_alias)) *)Dest)
Thank you. With your help, that worse-than-useless sample in the docs
is getting closer to something people can actually use.
Thank *you* for your investigation.
From: Thomas Schwinge tho...@codesourcery.com
Date: Tue, 23 Sep 2014 23:21:05 +0200
Hi!
On Thu, 4 Sep 2014 23:40:40 +0200, Hans-Peter Nilsson hans-peter.nilsson@a=
xis.com wrote:
The directory at $target_header_dir is [...]
gcc:
* configure.ac (target_header_dir): Move block
From: Jeff Law l...@redhat.com
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 !USE_PT_GNU_EH_FRAME]:
Sanity-check
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 h...@bitrange.com
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
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 be
On Wed, 17 Sep 2014, Janne Blomqvist wrote:
On Tue, Sep 16, 2014 at 11:17 AM, FX fxcoud...@gmail.com wrote:
2014-09-05 Janne Blomqvist j...@gcc.gnu.org
PR libfortran/62768
* io/io.h (gfc_unit): Store C string for the filename.
* io/close.c (st_close): Use gfc_unit.filename.
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);
^
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 hurry, just replace
fstrcpy (iqp-name, iqp
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 find time to fix it later tonight. If
you're
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
On Wed, Sep 17, 2014 at 11:36 PM, Hans-Peter Nilsson h...@bitrange.com
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 me committing the posted
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
On Thu, Sep 18, 2014 at 12:57 AM, Hans-Peter Nilsson h...@bitrange.com
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 regression for
its fix would
Ping! http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00402.html
From: Hans-Peter Nilsson h...@axis.com
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 setting
Ping! http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00403.html
From: Hans-Peter Nilsson h...@axis.com
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: libgcc_s.so.1) built
(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
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 idea of using a *combined* tree here, has been challenged
On Mon, 8 Sep 2014, Pierre-Marie de Rodat wrote:
# Get newlib and the simulator
cvs -d :pserver:anon...@sourceware.org:/cvs/src co newlib sim
# Get binutils
git clone git://sourceware.org/git/binutils-gdb.git
# Create the combined tree
rm -rf combined
mkdir
From: Joseph S. Myers jos...@codesourcery.com
Date: Fri, 5 Sep 2014 19:21:04 +0200
This patch removes some fp-bit target macros that are no longer
needed:
* __make_dp was not really designed as a target macro, but CRIS
defined it in cris.h anyway for optimization purposes
Minor
The conditions for inhibit_libc to activate (i.e. for library
headers to be absent) are IMO a bit too automatic and the effect
is too subtle and serious in some situations. For example, if
you pre-install target headers in $target_header_dir, gcc will
find them and use them, but still
The directory at $target_header_dir is already inspected in
gcc/configure, for e.g. glibc version and stack protector
support, but not for setting inhibit_libc. This is just
inconsistent and the obvious resolution to me is to inhibit
inhibit_libc when a target *does* have its own set of headers,
This adds an option to allow programs and libraries built
*without* inhibit_libc to stay compatible with system libraries
(really: libgcc_s.so.1) built *with* inhibit_libc, at the cost
of the registration. As mentioned, that's a one-way
compatibility barrier.
While it's nice to avoid the
In a native x86_64-linux toolchain in which
eh-table-registration is done explicitly (i.e. dl_iterate_phdr
and PT_GNU_EH_FRAME is *not* assumed, as that eliminates the
issue), the memory overhead for exception-initialization goes
beyond the 32768 bytes assumed in badalloc1.C and the test fails
for
From: David Malcolm dmalc...@redhat.com
Date: Fri, 29 Aug 2014 13:40:49 +0200
Patch attached, which fixes the above testcase; bootstrap in progress:
gcc/
* resource.h (mark_target_live_regs): Undo erroneous conversion
of second param of r214693, converting it back from
From: David Malcolm dmalc...@redhat.com
Date: Fri, 29 Aug 2014 13:26:59 +0200
On Fri, 2014-08-29 at 06:13 +0200, Hans-Peter Nilsson wrote:
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris
From: David Malcolm dmalc...@redhat.com
Date: Fri, 29 Aug 2014 17:33:54 +0200
On Fri, 2014-08-29 at 16:48 +0200, Hans-Peter Nilsson wrote:
Sorry, but that didn't help. I still get the exact same error.
(Yep, I double-checked that I didn't goof testing...)
Famous last words...
Fully
From: David Malcolm dmalc...@redhat.com
Date: Fri, 29 Aug 2014 20:07:04 +0200
BTW, in another email in the thread you said:
Thanks for the heads-up. BTW, the ChangeLog entries should say
what not why; that goes into a comment in the source.
OK. Where possible I've added comments in
Sorry for the context-less mail but I didn't find a proper
obvious gcc-patches-message to reply to. (Also, I can't log
into bugzilla because to enter a PR as there appears to have
been some SSL changes such that my old firefox and gcc.gnu.org
can no longer agree on a cipher or something.) But,
On Mon, 25 Aug 2014, Ilya Enkovich wrote:
2014-08-23 5:47 GMT+04:00 Hans-Peter Nilsson h...@bitrange.com:
...did you send the right version of the patch?
This one uses the RTX-returning hook only in boolean tests,
unless I misread.
(I did, but not by much.)
NULL returned by hook means we
On Sat, 23 Aug 2014, Sandra Loosemore wrote:
On 08/23/2014 10:26 AM, Mike Stump wrote:
On Aug 22, 2014, at 3:48 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
+/* non default branch cost */
+/* { dg-do run { target { ! m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
v850*-*-* picochip
On Thu, 21 Aug 2014, Mike Stump wrote:
On Aug 21, 2014, at 10:59 AM, Sandra Loosemore san...@codesourcery.com
wrote:
On 08/21/2014 11:36 AM, Mike Stump wrote:
On Aug 21, 2014, at 8:00 AM, Sandra Loosemore
san...@codesourcery.com wrote:
tests that assume some non-default branch costs in
(Dropping gcc@ and people known to subscribe to gcc-patches
from the CC.)
Sorry for the drive-by review, but...
On Fri, 22 Aug 2014, Ilya Enkovich wrote:
Hi,
On Cauldron 2014 we had a couple of talks about relaxation of
ebx usage in 32bit PIC mode. It was decided that the best
approach
On Mon, 18 Aug 2014, Oleg Endo wrote:
On Mon, 2014-08-18 at 16:57 -0400, Hans-Peter Nilsson wrote:
On Mon, 18 Aug 2014, Oleg Endo wrote:
On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
On Fri, 15 Aug 2014, Oleg Endo wrote:
How about the attached .html as a replacement
On Mon, 18 Aug 2014, Oleg Endo wrote:
On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
On Fri, 15 Aug 2014, Oleg Endo wrote:
How about the attached .html as a replacement for the current one?
I removed the requirement of setting up a combined tree, as I believe
it makes
On Fri, 15 Aug 2014, Oleg Endo wrote:
How about the attached .html as a replacement for the current one?
I removed the requirement of setting up a combined tree, as I believe
it makes things much more easy. At least it's been working for me
that way. Is this helpful / OK to commit?
On Tue, 12 Aug 2014, Thomas Preud'homme wrote:
As mentioned in PR60070, there is many cases when a programmer want to ensure
that a program does not use any floating point data type. Other cases to
consider
is when a target has several floating point ABI and user want to ensure
his/her
is
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 gcc110
On Fri, 25 Jul 2014, Jan-Benedict Glaw wrote:
On Thu, 2014-07-24 16:30:13 -0400, Hans-Peter Nilsson h...@bitrange.com
wrote:
On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote:
On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson h...@bitrange.com
wrote:
Jan-Benedict, which host gcc
On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote:
On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson h...@bitrange.com
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 to that instead
On Mon, 21 Jul 2014, David Wohlferd wrote:
I have been looking at asm_fprintf in final.c, and I think there's a design
flaw. But since the change affects ARM and since I have no access to an ARM
system, I need a second opinion.
There's this thing called cross-compilation, which happens for
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
gcc-versions, where working
On Tue, 22 Jul 2014, Mike Stump wrote:
On Jul 22, 2014, at 1:40 PM, Hans-Peter Nilsson h...@bitrange.com 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 that can be expected
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
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 should
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
On Tue, 1 Jul 2014, Jonathan Wakely wrote:
On 1 July 2014 20:58, John David Anglin wrote:
On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
On 1 July 2014 09:40, Matthias Klose wrote:
- HPPA (build log [2]), is missing all the future_base symbols and
exception_ptr13exception symbols,
On Mon, 30 Jun 2014, David Wohlferd wrote:
I don't have permissions to commit this patch, but I do have a release on file
with the FSF.
Problem description:
The text for using Explicit Register Variables is confusing, redundant, and
fails to make certain essential information clear.
[...]
On Mon, 16 Jun 2014, Steven Bosscher wrote:
On Mon, Jun 16, 2014 at 12:36 AM, Hans-Peter Nilsson wrote:
On Sun, 15 Jun 2014, Steven Bosscher wrote:
On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
/tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
merge_in_block
On Sat, 14 Jun 2014, Richard Sandiford wrote:
To make the final representation change easier, this patch introduces
macros for iterating over lists of defs, uses and eq_uses. At the
moment there are three possible keys when accessing df_ref lists:
the insn rtx (DF_INSN_*), the insn uid
On Sun, 15 Jun 2014, Steven Bosscher wrote:
On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
/tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
merge_in_block(int, basic_block_def*)':
/tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c:1442: error: 'uid'
was not declared
On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
On Sun, 15 Jun 2014, Steven Bosscher wrote:
Can you please try:
[...]
Thanks. Looks pretty obvious. I was heading for the door with
just enough time to report the issue, so I didn't actually look
at the code before. I'll commit
On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
On Sun, 15 Jun 2014, Steven Bosscher wrote:
Can you please try:
[...]
Thanks. Looks pretty obvious. I was heading for the door with
just enough time to report the issue, so I didn't
On Wed, 11 Jun 2014, Jan Hubicka wrote:
* varasm.c (set_implicit_section): New function.
(resolve_unique_section): Use it to set implicit section
for aliases, too.
(get_named_text_section): Use symtab_get_node (decl)-implicit_section
(default_function_section):
On Tue, 10 Jun 2014, Maciej W. Rozycki wrote:
Hi,
I've noticed mmix_asm_output_source_line is declared, but nowhere
defined. OK to remove the prototype?
Sure; in fact, obvious.
brgds, H-P
On Mon, 5 May 2014, Dominique Dhumieres wrote:
With the following patch, gfortran can be regtested with -flto
with no failure, but pr54852 and pr60061.
OK for trunk?
Dominique
2014-05-05 Dominique d'Humieres domi...@lps.ens.fr
* gfortran.dg/gfortran.dg/bind_c_array_params_2.f90:
Apparently LTO improved or at least changed between r21 and
r211121, such that memory outside the defined space was wrongly read
as expected for this test-case, corresponding to the wrongly
presumed stacked parameters. For a normal target this would
correspond to a SEGV. You'd need the
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 allocated
On Fri, 23 May 2014, Janne Blomqvist wrote:
On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson h...@bitrange.com 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.
Do I?
The way that configure-clause
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 Boessenkool seg...@kernel.crashing.org
* config
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 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 seg...@kernel.crashing.org
* config/m68k/m68k.md (extendplussidi): Don't allow memory for
operand 1.
Thanks. I tweaked the comment and
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:
*
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
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 from last night on aarch64-none-elf and arm-none
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
you must
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 should
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 library on
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
assignment
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 all
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 that
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
On Tue, 4 Mar 2014, Yury Gribov wrote:
Richard wrote:
volatile __asm__(:::memory)
is a memory barrier and a barrier for other volatile instructions.
AFAIK asm without output arguments is implicitly marked as volatile. So it may
not be needed in barrier() at all.
Yes, exactly. Had it at
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
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:
-
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 rsand...@linux.vnet.ibm.com writes:
Hans-Peter Nilsson h...@bitrange.com writes:
On Tue, 4 Feb 2014, Rainer Orth wrote
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 rsand...@linux.vnet.ibm.com writes:
Hans-Peter Nilsson h...@bitrange.com writes:
On Tue, 4 Feb 2014, Rainer Orth wrote:
AFAICT the gcc.dg/binop-xor1.c test is XPASSing everywhere since about
20131114:
Bah, missing
On Tue, 28 Jan 2014, Andreas Schwab wrote:
Hans-Peter Nilsson h...@bitrange.com 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 anything whether its
On Mon, 27 Jan 2014, Bruce Korb wrote:
On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson h...@bitrange.com 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 nobody replied to this and it isn't committed
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 C++
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
that work by luck on old versions
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.
I added
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.ac
This patch fixes a regression on trunk and the 4.8 branch:
Running /tmp/hpautotest-gcc48/gcc/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc2 Optimizing range tests
[^\r\n]*_[0-9]* -.0, 31. and -.128, 159.[\n\r]* into 1
The comment in the test seen in the
From: Mike Stump mikest...@comcast.net
Date: Sat, 11 Jan 2014 01:55:09 +0100
On Jan 10, 2014, at 11:26 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
This patch fixes a regression on trunk and the 4.8 branch:
Index: gcc/testsuite/gcc.dg/pr46309.c
From: Hans-Peter Nilsson h...@axis.com
Date: Mon, 23 Dec 2013 23:34:02 +0100
Just as previously done on trunk, I'm going to cover up PR59584
(which was fixed and then exposed on the 4.8 branch) by applying
commit r206187 from trunk below. Again, the PR bug is an ICE
caused by the combination
On Sat, 14 Dec 2013, Jakub Jelinek wrote:
2013-12-14 Jakub Jelinek ja...@redhat.com
PR middle-end/58956
PR middle-end/59470
* gimple-walk.h (walk_stmt_load_store_addr_fn): New typedef.
(walk_stmt_load_store_addr_ops, walk_stmt_load_store_ops): Use it
for
The circumstances are a bit odd; the stack-pointer (sp) is never
the target for a direct assignment in ordinary generated code.
Still, this happens for gcc.dg/pr50251.c, calling
__builtin_stack_restore. There's a bug in several define_splits
in the CRIS port, in that the destination of the split
Spotted by David Binderman and cppcheck, thanks. The
interesting cases wouldn't be exposed by a cris-elf build, but I
made a regtest-run nonetheless: the fix has actually been in our
local tree for quite some time together with TLS for CRIS v32 so
I'm not worried about fallout. (Upstreaming
701 - 800 of 1367 matches
Mail list logo
