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
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
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
(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
> From: "Joseph S. Myers"
> 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 correction here: it wa
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 overhead
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",
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 inhibit_libc
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
> 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 the n
> From: David Malcolm
> 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
> From: David Malcolm
> 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
> From: David Malcolm
> 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 rtx_insn * to
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, si
On Mon, 25 Aug 2014, Ilya Enkovich wrote:
> 2014-08-23 5:47 GMT+04:00 Hans-Peter Nilsson :
> > ...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
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 wrote:
> > >
> > > > +/* non default branch cost */
> > > > +/* { dg-do run { target { ! "m68k*-*-* mmix*-*-
(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 Thu, 21 Aug 2014, Mike Stump wrote:
> On Aug 21, 2014, at 10:59 AM, Sandra Loosemore
> wrote:
> > On 08/21/2014 11:36 AM, Mike Stump wrote:
> >> On Aug 21, 2014, at 8:00 AM, Sandra Loosemore
> >> wrote:
> >>> tests that assume some non-default branch costs in the back end
> >>
> >> Thanks.
>
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:
> >
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
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
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 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 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 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 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 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 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
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 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/aut
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
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 actual
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
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 (D
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_secti
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
>
> * 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 me
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 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 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 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 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
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
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
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 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 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 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 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 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, 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 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:
- LOGICAL_OP_NON_SH
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
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 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 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 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 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, 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 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 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.
> >
>
> From: Mike Stump
> Date: Sat, 11 Jan 2014 01:55:09 +0100
> On Jan 10, 2014, at 11:26 AM, Hans-Peter Nilsson
> wrote:
> > This patch "fixes" a regression on trunk and the 4.8 branch:
>
> >
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
> From: Hans-Peter Nilsson
> 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 com
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 that?
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
On Sat, 14 Dec 2013, Jakub Jelinek wrote:
> 2013-12-14 Jakub Jelinek
>
> 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 callback param
Here's a patch that splits up 20_util/hash/chi2_quality.cc *and*
increases some of the iteration numbers for simulator targets to
something that passes for all working targets mentioned below.
I am a bit worried about the stability of these tests and the
implementation, seeing this amount of target
> From: Hans-Peter Nilsson
> Date: Sun, 15 Dec 2013 15:20:48 +0100
> +// { dg-options "-std=gnu++0x -DSAMPLES=3" { target { { arm*-* } &&
> simulator } } }
> +// { dg-options "-std=gnu++0x -DSAMPLES=1" { target simulator } }
JFTR, I managed
> From: Jonathan Wakely
> Date: Sun, 15 Dec 2013 11:38:43 +0100
> On Dec 15, 2013 6:57 AM, "Hans-Peter Nilsson"
> wrote:
> >
> > From the revision range 205803:205810 (excluding:including) an
> > on, my autotester for cris-elf reports a regression:
>
>From the revision range 205803:205810 (excluding:including) an
on, my autotester for cris-elf reports a regression:
Running
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
WARNING: program timed out.
FAIL: 20_util/hash/chi2_quality.cc execution test
This appears
On Fri, 22 Nov 2013, Andrew MacLeod wrote:
> The target hook patch is checked into mainline, revision 205273.
Thanks!
The target patch is there too now; tested with the previous
version of the hook-patch. I'm confident my autotester will
yell at me if I goofed.
gcc:
* config/cris/cris.c
On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote:
> with this/these patches
> at least I'll be able to tell people that _Atomic for C11 works.
Oh right, gcc still doesn't remove target-introduced "manual"
alignment checks (when expanding atomic intrinsics), but at
least g
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> I can bootstrap and check this on x86 to make sure it doesnt affect anything,
> and you can fool with it and see if you can get your desired results with your
> port.
Success!
For the record, tested together with the attached patch for the
CRIS ports,
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> > Or is that part also required for
> > anything-other-than-ordinary-C-type alignment for the target;
> > say, natural 4-byte alignment of 4-byte-types for targets where
> > alignment is otherwise "packed"; where only 1-byte alignment of
> > the basic ty
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> If we add the hook for atomic_align_for_mode, and change the initalizers in
> tree.c, any target which doesnt need/use the hook should be unaffected. So
> everything remains as it is today.
>
> So Putting the hook in shouldn't be an issue. Then you can
On Tue, 5 Nov 2013, Joseph S. Myers wrote:
Thanks for doing this! However, without examples I have trouble
reading out the bits I need as a target maintainer, and I can't
read out the answers from the patch, so pardon a few questions.
> This patch, relative to trunk and based on work done on the
On Tue, 5 Nov 2013, Mike Stump wrote:
> On Nov 5, 2013, at 1:45 PM, Oleg Endo wrote:
> > You're right, it's redundant. It should be just
> > /* { dg-do compile } */
> >
> > shouldn't it?
>
> Yup, that's my take.
Or nothing at all, as compile seems to be the default here.
(grep for dg-do-what-de
> From: Ian Lance Taylor
> Date: Tue, 19 Nov 2013 02:11:29 +0100
> 2013-11-18 Ian Lance Taylor
>
> * configure.ac: Check for support of __atomic extensions.
> * internal.h: Declare or #define atomic functions for use in
> backtrace code.
> * atomic.c: New file.
Build-
> From: Jakub Jelinek
> Date: Thu, 31 Oct 2013 00:16:41 +0100
> On Fri, Oct 25, 2013 at 05:19:06PM +0200, Martin Jambor wrote:
> > 2013-10-23 Martin Jambor
> >
> > PR rtl-optimization/10474
> > * ira.c (find_moveable_pseudos): Do not calculate dominance info
> > nor df analysis.
>
On Wed, 30 Oct 2013, Zhenqiang Chen wrote:
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Hans-Peter Nilsson
> > One thing I don't see other people mentioning, is that this patch has ju
On Tue, 22 Oct 2013, Zhenqiang Chen wrote:
> ChangeLog:
> 2013-10-22 Zhenqiang Chen
>
> * config/arm/arm.c (arm_fixed_condition_code_regs, arm_ccmode_to_code,
> arm_select_dominance_ccmp_mode): New functions.
> (arm_select_dominance_cc_mode_1): New function extracted from
>
PRED_NORETURN seems a better match; not that I see anything in
the current source that actually treats them differently other
than generating them, but my grep-fu may be weak and certainly
my crystall-ball-fu is.
After testing (no regressions compared to r204080 before the
breakage), committed.
On Sat, 26 Oct 2013, Andrew Pinski wrote:
> I think you could use PRED_NORETURN which should be a reasonable replacement.
I've totally missed that one, thanks.
brgds, H-P
On Sat, 26 Oct 2013, Hans-Peter Nilsson wrote:
> Yeah, cris-elf is broken too. I use PRED_MUDFLAP in
> cris_emit_trap_for_misalignment, which should explain its use.
> Is there a replacement?
Actually looking at predict.def, I see PRED_COLD_LABEL, which
wasn't there when I worked
On Sat, 26 Oct 2013, Jeff Law wrote:
> It appears that mudflap creeped into one additional file (targhooks) between
> the time I bootstrapped the final change and committed the change. This also
> elimiantes PRED_MUDFLAP which I missed the first time around.
>
> Given this is currently breaking
On Fri, 25 Oct 2013, Mike Stump wrote:
> On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson wrote:
> > On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
> >> I too would like to include this change on those branches, as
> >> recent generic newlib changes has caused these t
On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
> On Mon, 21 Oct 2013, Mike Stump wrote:
>
> > On Oct 21, 2013, at 3:28 AM, Vidya Praveen wrote:
> > > Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This
> > > can
> > > be a issu
On Mon, 21 Oct 2013, Mike Stump wrote:
> On Oct 21, 2013, at 3:28 AM, Vidya Praveen wrote:
> > Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This
> > can
> > be a issue especially since they define uint32_t.
>
> > OK for 4.7, 4.8?
>
> For release branches, you'd need to
For cris-elf (no SIMD), the following tests regressed just as
for the similar tests mentioned in PR58556. These apparently
don't fail for the targets mentioned there for some reason, but
I see in the mail thread with the quoted subject there was no
conscious adjustment to the test-suite. Thus I b
There's a page-full or two of numbers reported here with the
background, but maintainers of software-floating-point ports
used with a microcontroller may find that of use, if they're on
a cycle or size budget and consider fp-bit vs. soft-fp.
For an on-chip controller subsystem with a CRIS CPU, the
> From: Bernd Edlinger
> Date: Wed, 4 Sep 2013 10:15:22 +0200
> Even driver code rarely uses bit-fields for register access,
> because that is inherently non-portabe. Reason: the bit
> positions are completely different on little- and big-endian
> targets. Most drivers I have seen use some macros
On Tue, 3 Sep 2013, Richard Biener wrote:
> I think the warning can be completely implemented inside struct-layout.c
> for example in finish_bitfield_representative (if you pass that the first
> field
> in the group, too). Of course that is at the expense of warning for
> struct declarations rath
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
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
701 - 800 of 1173 matches
Mail list logo
