On Tue, 7 Apr 2015, Jonathan Wakely wrote:
> The docs are clear that alignof(s.x) is not related to its position in
> struct SoSo: https://gcc.gnu.org/onlinedocs/gcc/Alignment.html
>
> I'm not going to worry about that behaviour changing.
'kthen thanks, quite clear; I should have checked that myse
On Wed, 8 Apr 2015, Segher Boessenkool wrote:
> 2015-04-08 Segher Boessenkool
>
> * combine.c (is_parallel_of_n_reg_sets): Change first argument
> from an rtx_insn * to an rtx.
> (try_combine): Adjust both callers. Use it once more.
That "once more" is outside of #ifndef HAVE
On Thu, 9 Apr 2015, Segher Boessenkool wrote:
> I tested a cross to cris-linux and built a Linux kernel with the trivial
> patch (attached); doing that for all other cross configs is in progress.
Thanks. Using contrib/config-list.mk comes to mind, but might
be a bit excessive in this particular c
>PR libstdc++/62259
>PR libstdc++/65147
>* include/std/atomic (atomic): Increase alignment for types with
>the same size as one of the integral types.
>* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error line number.
>* testsuite/29_atomics/atomi
(check_cxx_fundamental_alignment_constraints is Dodji's, others
CC:ed were already in the thread)
Looking into those atomic things and running tests for cris-elf,
I get FAIL for
libstdc++-v3/testsuite/29_atomics/atomic/65147.cc, specifically
struct S16 {
char c[16];
};
static_assert( alignof(
> From: Richard Sandiford
> Date: Tue, 30 Jun 2015 22:55:24 +0200
> Bootstrapped & regression-tested on x86_64-linux-gnu and aarch64-linux-gnu.
> Also tested via config-list.mk. Committed as preapproved.
>
> Thanks,
> Richard
>
>
> gcc/
> * defaults.h (HAVE_epilogue, gen_epilogue): De
> From: Richard Sandiford
> Date: Wed, 1 Jul 2015 23:26:59 +0200
> Hans-Peter Nilsson writes:
> >> From: Richard Sandiford
> >> Date: Tue, 30 Jun 2015 22:55:24 +0200
> >
> >> Bootstrapped & regression-tested on x86_64-linux-gnu and aarch64-
> From: Richard Sandiford
> Date: Thu, 2 Jul 2015 20:58:15 +0200
> Hans-Peter Nilsson writes:
> > gcc:
> > * config/cris/cris.md ("epilogue"): Remove condition.
> > ("prologue"): Ditto.
>
> Thanks.
No, thank *you* for the massiv
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
> > On Jan 16, 2015, at 9:57 PM, David Edelsohn wrote:
> >
> > This patch has broken bootstrap on AIX
> >
> > May I mention that this really should have been tested on systems
> > other than x86 Linux.
>
> It also broke all newlib targets too. So you c
(Waking up an old thread with my 2 cents due to being a little
behind on reading...)
On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > That's already what it does though, did you mean the opposite? Or did you
> > > mean to write "combine
On Sat, 17 Jan 2015, Jakub Jelinek wrote:
> On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> > (Waking up an old thread with my 2 cents due to being a little
> > behind on reading...)
> >
> > On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> > >
On Mon, 8 Dec 2014, Segher Boessenkool wrote:
> A lot of old user code clobbers the carry bit without telling the compiler
> about it. This used to just work, because the compiler never used the bit
> outside of a single RTL instruction. But that will change. Let's clobber
> the carry bit in ev
On Mon, 9 Feb 2015, Matthew Wahab wrote:
> On 07/02/15 00:11, Jonathan Wakely wrote:
> > Any idea why HP still sees the tests fail? See comment 8 at
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8
>
> It looks like he's found the problem: that _NEWLIB_ is a recent addition that
> isn't in
Lately,
26_numerics/random/binomial_distribution/operators/values.cc has
started to FAIL on trunk with a timeout for my autotester for
cris-elf, a soft-float simulator target running a cgen-generated
simulator on a six-year-old x86_64-linux-gnu host. The reason
it's started to fail in the last few
> From: Vladimir Makarov
> Date: Tue, 21 May 2019 17:05:50 -0400
> Yes, the patch is ok to commit. Thank you for working on the problem.
>
> It is hard to reproduce the same problem in LRA as LRA mostly follows
> IRA decisions.
>
> I'll probably do the analogous patch for LRA on this week.
T
Ping, on behalf of Martin, CC:ing diagnostics maintainers.
On Fri, 3 May 2019, Martin Li?ka wrote:
> Hi.
>
> The patch prints all values requested in multiple --help options.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
There was a regression for gfortran.dg/fmt_en.f90 for cris-elf
that on inspection was due to it having acquired a truncation
call through the runtime. I updated that and the new tests that
had "Fortran runtime error: required ftruncate or chsize support
not present" messages in gfortran.log, ran p
This test regressed for cris-elf (testing in a simulator) with
the fixing of libstdc++/83237, as the part suggested to be
wrapped in #ifndef was *added* to the existing test and causes a
timeout. Tsk tsk. Please don't pile-on existing tests, instead
add a *separate* test-file.
>From what I under
> From: Janne Blomqvist
> Date: Thu, 23 May 2019 23:43:23 +0300
> On Thu, May 23, 2019 at 5:21 AM Hans-Peter Nilsson
> wrote:
> >
> > There was a regression for gfortran.dg/fmt_en.f90 for cris-elf
> > that on inspection was due to it having acquired a truncation
&g
TL;DR: instead of capping TYPE_PRECISION of bitsizetype at
MAX_FIXED_MODE_SIZE, search for the largest fitting size from
scalar_int_mode modes supported by the target using
targetm.scalar_mode_supported_p.
-
In initialize_sizetypes, MAX_FIXED_MODE_SIZE is used as an upper
limit to the *pre
> From: Richard Biener
> Date: Wed, 29 May 2019 15:04:42 +0200
> On Tue, May 28, 2019 at 5:43 PM Hans-Peter Nilsson
> wrote:
> >
> > TL;DR: instead of capping TYPE_PRECISION of bitsizetype at
> > MAX_FIXED_MODE_SIZE, search for the largest fitting size from
>
> From: Eric Botcazou
> Date: Wed, 05 Jun 2019 22:03:04 +0200
> > This issue exists, not just for targets that can have their
> > MAX_FIXED_MODE_SIZE more-or-less easily tweaked higher, but also
> > for the 'bit-container' targets where it *can't* be set higher.
> >
> > Let's please DTRT and cor
> Date: Thu, 6 Jun 2019 16:04:47 +0200
> From: Hans-Peter Nilsson
> When bitsizetype objects end
> up on the target, they use the actual Pmode and not the larger
> precision mode.
Oops, a half-way-done email slipped away, this part still needs
to be investigated.
I don't r
Thu, 06 Jun 2019 00:59:40 -0700 (PDT)
> References: <201906051938.x55jcssw016...@ignucius.se.axis.com>
> <18571728.MIQ1nkMWVm@polaris>
> From: Richard Biener
> Date: Thu, 6 Jun 2019 09:59:29 +0200
> Cc: Hans-Peter Nilsson ,
> GCC Patches
> Old-Content-Type
On Wed, 12 Dec 2018, Wilco Dijkstra wrote:
> I've not seen such an alternative implementation (-fno-trampolines is
> ignored on all targets I tried), but it wouldn't affect the ABI since you can
> only take the address of a nested function when you're the parent function.
Regarding the trampoline-
On Mon, 17 Dec 2018, Wilco Dijkstra wrote:
> H-P:
> > So, changing from R18 to R11 for aarch64 seems right, as the
> > latter is call-clobbered and the former is call-saved IIUC.
>
> The AArch64 ABI defines x18 as platform specific:
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI005
On Mon, 17 Dec 2018, Hans-Peter Nilsson wrote:
> On Mon, 17 Dec 2018, Wilco Dijkstra wrote:
> > H-P:
> > > So, changing from R18 to R11 for aarch64 seems right, as the
> > > latter is call-clobbered and the former is call-saved IIUC.
> >
> > The AArch
On Tue, 18 Dec 2018, Uecker, Martin wrote:
> Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker:
> > Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek:
> > > On Tue, Dec 18, 2018 at 09:03:41AM -0700, Jeff Law wrote:
> > > > Right. This is the classic example and highlights
On Tue, 18 Dec 2018, Andi Kleen wrote:
> > Yes, take g++.dg/tree-prof/morefunc.C as an example:
> > - int i;
> > - for (i = 0; i < 1000; i++)
> > + int i, j;
> > + for (i = 0; i < 100; i++)
> > +for (j = 0; j < 50; j++)
> > g += tc->foo();
> > if (g<100) g++;
> > }
> > @@ -2
> From: Jakub Jelinek
> Date: Sat, 10 Aug 2019 12:12:46 +0200
> I ran the gcc/ subdirectory ChangeLogs through following script that doesn't
> seem to have false positives ATM
except one...
> # Date not separated from name by two spaces, but just one.
[...]
> # Email not wrapped in <>s.
> grep
> From: Richard Biener
> Date: Tue, 13 Aug 2019 09:50:34 +0200
> 2019-08-13 Richard Biener
>
> PR testsuite/91419
> * lib/target-supports.exp (natural_alignment_32): Amend target
> list based on BIGGEST_ALIGNMENT.
> (natural_alignment_64): Targets not natural_alignment
On Tue, 20 Aug 2019, Jose E. Marchesi wrote:
> > On Thu, Aug 15, 2019 at 12:22:46AM +0200, Jose E. Marchesi wrote:
> > > --- a/configure
> > > +++ b/configure
> Yeah by mistake I used a Debian patched autoconf 2.96. Will regenerate
> using vanilla autoconf for subsequent versions of th
I didn't expect this to be contested and not by a frequent
reviewer, but since you took the time to express yourself, I'll
do the same.
On Wed, 21 Aug 2019, Segher Boessenkool wrote:
> On Tue, Aug 20, 2019 at 04:05:40PM -0400, Hans-Peter Nilsson wrote:
> > On Tue, 20 Aug 201
This patch should have no visible effect. It was approved in the BZ and
is what remains of PR54005. _M_i is declared "alignas(_S_alignment) _Tp
_M_i;" and is_lock_free is supposed to refer to the *type* not the
specific *object*. (Note how the actual address of the object is not
used in the __at
On Tue, 13 Nov 2018, Maciej W. Rozycki wrote:
> On Sun, 11 Nov 2018, Fredrik Noring wrote:
>
> > ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:71:1:
> > note: in expansion of macro ?COMPILER_CHECK?
> >71 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct st
Hej!
On Sun, 25 Nov 2018, Krister Walfridsson wrote:
> On Sun, 25 Nov 2018, Maya Rashish wrote:
>
> > gcc/config.host | 4 ++
> > gcc/config/host-netbsd.c | 85
> > gcc/config/x-netbsd | 4 ++
> > 3 files changed, 93 insertions(+)
> > create mo
> Date: Tue, 27 Nov 2018 23:25:55 +
> From: Jonathan Wakely
> This resolves a longstanding issue where the lock policy for shared_ptr
> reference counting depends on compilation options when the header is
> included, so that different -march options can cause ABI
> changes.
> [...]
Thank you
Regarding this sometimes-add--latomic(-in-testsuite) that is
revisited:
When is it appropriate to make the user add -latomic to link
their program? Perhaps different answers for fortran and C++.
I'm guessing "always when using any atomic construct" for C.
I had a grep-look in gcc/doc before aski
> Date: Tue, 30 Apr 2019 11:37:17 -0600
> From: Jeff Law
> On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote:
> > Here's the follow-up, getting rid of the observed
> > alignment-padding in execute/930126-1.c: the x parameter in f
> > spuriously being runtime-aligne
On Tue, 14 May 2019, Richard Sandiford wrote:
> Several SVE patterns need define_insn_and_splits that generate the
> same insn_code, but with different operands. That's probably a
> niche requirement, but it's cropping up often enough on the ACLE
> branch that I think it would be good to have a sy
I was looking into why I couldn't trivially move cris-elf to
"use init_array". It appeared that it wasn't the hooks into
that machinery that went wrong, but that a compiler bug is
plaguing __libc_init_array. It's been there since at least
4.7-era, hiding under the covers of the __init_array being
> Date: Thu, 10 Jan 2019 00:06:01 +0100
> From: Jakub Jelinek
> 2019-01-09 Jakub Jelinek
>
> PR middle-end/84877
> PR bootstrap/88450
> * function.c (assign_stack_local_1): Revert the 2018-11-21 changes.
> (assign_parm_setup_block): Do the argument slot realignment her
Here's the follow-up, getting rid of the observed
alignment-padding in execute/930126-1.c: the x parameter in f
spuriously being runtime-aligned to BITS_PER_WORD. I separated
this change because this is an older issue, a change introduced
in r94104 where BITS_PER_WORD was chosen perhaps because we
> Date: Mon, 11 Feb 2019 02:05:11 +0100
> From: Hans-Peter Nilsson
> Regtested on cris-elf, where it "introduces" gcc.dg/pr84877.c
Correction: "no regressions" (not introduced by this proposed
patch, I misread).
brgds, H-P
Spotted while in a recent gdb session. JFTR, not mine... Committed.
Index: ChangeLog
===
--- ChangeLog (revision 268759)
+++ ChangeLog (revision 268760)
@@ -1,3 +1,8 @@
+2019-02-11 Hans-Peter Nilsson
+
+ * config/cris
> Date: Mon, 11 Feb 2019 07:38:14 +0100
> From: Richard Biener
> >+ HOST_WIDE_INT min_parm_align
> >+= STRICT_ALIGNMENT ? BITS_PER_WORD : PREFERRED_STACK_BOUNDARY;
>
> Shouldn't it be MIN (...) of BOTH?
That *does* seem logical... Take 2 as follows, in testing as
before.
Ok to commi
> Date: Mon, 11 Feb 2019 10:22:12 +0100
> From: Jakub Jelinek
> Is PREFERRED_STACK_BOUNDARY what we want here? Shouldn't that be
> STACK_BOUNDARY, or PARM_BOUNDARY? Though, PARM_BOUNDARY on cris is 32...
Hm.
I wish there was a better distinction both in the code and in
peoples minds between b
On Fri, 10 Jun 2016, Jakub Jelinek wrote:
> On Fri, Jun 10, 2016 at 03:13:32PM +0300, Maxim Ostapenko wrote:
> > gcc/ChangeLog:
> >
> > 2016-06-10 Maxim Ostapenko
> >
> > PR sanitizer/71480
> > * varasm.c (place_block_symbol): Adjust alignment for asan protected
> > STRING_CSTs even
On Sat, 18 Jun 2016, Bernhard Reutner-Fischer wrote:
> A branch with a name matching scan-assembler pattern triggers
> inappropriate FAIL.
>
> E.g. branch fixups-testsuite and
> - gcc.target/i386/pr65871-?.c (scan-assembler-not "test")
> - gcc.target/i386/pr41442.c (scan-assembler-times "test|cmp"
Committed to trunk. Apparently the -fno-inline is key to
keeping the test-case small.
Thanks go to the reporter, David B. Robins.
gcc:
PR target/71571
* config/cris/cris.c (cris_asm_output_mi_thunk): Add missing "ba"
delay-slot "nop" for PIC with CRIS v32. Also add missin
On Thu, 12 Oct 2017, Tsimbalist, Igor V wrote:
> * unwind.inc (_Unwind_RaiseException_Phase2): Use FRAMES_P_DECL,
> FRAMES_VAR_DECL_1, FRAMES_VAR_INC and FRAMES_P_UPDATE.
> (_Unwind_RaiseException): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
> FRAMES_VAR.
> (_Unwind_ForcedU
On Wed, 18 Oct 2017, FX wrote:
> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on
> macOS 10.13 often fail (failure rate for ?make -j2? to ?make -j8? is about
> 60% from my own builds and results reported by others):
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
On Wed, 10 May 2017, Jakub Jelinek wrote:
> On Wed, May 10, 2017 at 09:57:56PM +0200, Uros Bizjak wrote:
> > BTW: This patch now catches 417 cases (instead of 200+) in linux
> > build, including e.g.:
> >
> > (parallel [
> > (set (reg:CCZ 17 flags)
> > (compare:CCZ (lshiftrt:SI
(To-list pruned, my correction doesn't need attention.)
On Thu, 11 May 2017, Hans-Peter Nilsson wrote:
> On Wed, 10 May 2017, Jakub Jelinek wrote:
>
> > On Wed, May 10, 2017 at 09:57:56PM +0200, Uros Bizjak wrote:
> > > BTW: This patch now catches 417 cases (instead of
On Fri, 12 May 2017, Jeff Law wrote:
> On 05/11/2017 03:29 PM, Hans-Peter Nilsson wrote:
> > The canonical order of insns affecting condition-codes has been
> > discussed in the past too.
> >
> > I was then arguing that the compare should go last, i.e.
>
On Wed, 17 May 2017, Uros Bizjak wrote:
> On Wed, May 17, 2017 at 4:45 AM, Hans-Peter Nilsson wrote:
> >> But yes, we definitely should document the final canonical ordering.
> >
> > Is that about to also happen?
> The proposed doc patch is wiating for review at [1].
For cris-elf on the gcc-5-branch at r244321:
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-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-m
> Date: Sun, 29 Jan 2017 23:06:56 +0100 (CET)
> From: Gerald Pfeifer
> There is one reference left in gcc.gnu.org/readings.html; Hans-Peter,
> do you have a recommendation on how to best handle that? (Remove it,
> or is there a good and stable replacement?)
Sorry, I don't
> From: Segher Boessenkool
> Date: Tue, 21 Feb 2017 14:48:14 +
> 2017-02-21 Segher Boessenkool
>
> * config/cris/cris.md: Use correct operand in a define_peephole2.
Obviously ok, thanks (INTVAL on "const_int_operand"
vs. "nonimmediate_operand").
brgds, H-P
> Date: Sun, 12 Mar 2017 12:34:25 +0100 (CET)
> From: Gerald Pfeifer
> On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> > References to dependencies on really, really old versions of
> > binutils (talking 10+ years here) which I think we can remove.
> > Let me follow-up with some of you with concrete
> Date: Sun, 12 Mar 2017 14:47:42 +0100
> From: Gerald Pfeifer
> (May there be further changes to consider for cris-*?)
Nothing actively pursued and no news on related issues.
brgds, H-P
On Mon, 25 Apr 2016, Bernd Schmidt wrote:
> Now that we're in stage1, I thought I'd bring this up again. For reference,
> the patch was here:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00165.html
>
> So, would you like this for cris and mmix? I could enable it for these, then
> we'd need som
There exists targets that support fortran but error on -fPIC,
for example cris-elf, which broke with the libbacktrace thingy.
(Emitting an error for -fPIC is a conscious choice; a
compilation error is better than e.g. to silently ignoring it.)
This fix causes build to pass the point of error for cr
(Goofed on the CC line, sorry for the dup.)
There exists targets that support fortran but error on -fPIC,
for example cris-elf, which broke with the libbacktrace thingy.
(Emitting an error for -fPIC is a conscious choice; a
compilation error is better than e.g. to silently ignoring it.)
This fix c
> From: FX
> Date: Mon, 24 Aug 2015 18:07:52 +0200
> > PIC_FLAG=
> > if test -n "${with_target_subdir}"; then
> > - PIC_FLAG=-fPIC
> > + AC_TRY_COMPILE([void foo(void){}], [PIC_FLAG=-fPIC])
> > fi
>
> There's something I don't understand about this
> test. Shouldn't AC_TRY_COMPILE take a firs
TL;DR: See last...
> From: Ulrich Weigand
> Date: Tue, 25 Aug 2015 14:59:05 +0200
> However, the compiler actually does accept -fPIC. If the flag is
> present, we attempt to generate relocatable code, but only to the
> extent the compiler can do that without support for run-time
> relocations.
> From: Ulrich Weigand
> Date: Tue, 25 Aug 2015 19:45:06 +0200
> Hans-Peter Nilsson wrote:
> However, neither works for the SPU, because in both cases libtool
> will only do the test whether the target supports the -fPIC option.
> It will not test whether the target supports
> From: Ulrich Weigand
> Date: Wed, 26 Aug 2015 13:45:35 +0200
> Hans-Peter Nilsson wrote:
> > > From: Ulrich Weigand
> > > Date: Tue, 25 Aug 2015 19:45:06 +0200
> >
> > > However, neither works for the SPU, because in both cases libtool
> > >
(Pruned the CC list a bit as lists are included anyway)
On Fri, 28 Aug 2015, James Greenhalgh wrote:
> On Fri, Aug 28, 2015 at 10:40:31AM +0100, James Greenhalgh wrote:
> > On Tue, Aug 25, 2015 at 03:44:05PM +0100, FX wrote:
> > > > 2015-08-25 James Greenhalgh
> > > >
> > > > * configur
On Thu, 3 Sep 2015, James Greenhalgh wrote:
> On Sun, Aug 30, 2015 at 02:46:26PM +0100, Hans-Peter Nilsson wrote:
> > (Pruned the CC list a bit as lists are included anyway)
> >
> > On Fri, 28 Aug 2015, James Greenhalgh wrote:
> > > Give me a shout if you se
> From: Ian Lance Taylor
> Date: Tue, 8 Sep 2015 18:46:21 +0200
> PR other/67457
> * backtrace.c: #include "internal.h".
> (struct backtrace_data): Add can_alloc field.
> (unwind): If can_alloc is false, don't try to get file/line
> information.
> (backtrace_full): Set can_alloc field in bdata.
On Mon, 21 Nov 2016, Jeff Law wrote:
>
> The CRIS port seems to have made a minor goof in a conditional guarding a call
> to copy_to_mode_reg.
>
> copy_to_mode_reg always allocates a new pseudo, so calling it when
> !can_create_pseudo_p is going to result in an ICE.
>
> The attached patch fixes th
On Tue, 1 Dec 2015, Bernd Schmidt wrote:
> On 12/01/2015 04:31 PM, Bernd Schmidt wrote:
> > On 12/01/2015 04:23 PM, Jakub Jelinek wrote:
> > > With the comments in the *.md file I'd worry about them getting out of
> > > date,
> > > or people feeling they have to edit them manually (rather than bein
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,
m OK with the patch approach, but let's wait for
> eventual comments from Linux people.
>
Acked-by: H. Peter Anvin
H.J. already coordinated with us; we are more than happy with this approach.
Thank you!
-hpa
On 12/18/2014 09:43 AM, H.J. Lu wrote:
>
> Peter, please feel free to use my kernel patch or create a different
> one.
>
Great, thanks!
-hpa
On 12/18/2014 10:37 AM, Rasmus Villemoes wrote:
>
> Minor thing: If it's not too late, I'd appreciate a 'Suggested-by' or
> similar mention in the kernel change log.
>
I think we can get that.
-hpa
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 Wed, 31 Dec 2014, Tim Shen wrote:
> On Wed, Dec 31, 2014 at 4:17 PM, David Edelsohn 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.
But appar
On Thu, 1 Jan 2015, Tim Shen wrote:
> On Thu, Jan 1, 2015 at 5:06 PM, Hans-Peter Nilsson 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-characte
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 p
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: gcc.dg/debug
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);
>
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 PR
On Wed, 19 Nov 2014, David Malcolm wrote:
> On Wed, 2014-11-19 at 10:09 -0700, Jeff Law wrote:
> > On 11/19/14 04:47, Richard Biener wrote:
> > > On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm
> > > wrote:
> > >> Valgrind complains about uninitialized data within sparseset_bit_p.
> > >> Provide
(CC list trimmed.)
On Wed, 31 Oct 2012, Kirill Yukhin wrote:
> Hi,
> This patch introduces a new RTL expression called define_subst and
> required by it define_subst_attr.
>
> The new feature allows to make MD-files more compact - it defines a
> rule by which a parser could generate modified versi
> From: Steven Bosscher
> Date: Sun, 28 Oct 2012 19:33:29 +0100
> On Mon, Oct 22, 2012 at 11:09 PM, Jakub Jelinek wrote:
> > On Mon, Oct 22, 2012 at 10:51:43PM +0200, Steven Bosscher wrote:
> > Wouldn't it be way cheaper to just export dfs_find_deadend from cfganal.c
> > and call it in calc_dfs_t
Due to weird circumstances detailed in the PR, this test briefly
passed (it has always failed before), so technically I'm fixing
a regression. :)
The test checks that a certain label is mentioned twice; being
mentioned once infers that there are two identical initializer
vectors in the constant-po
On Sun, 4 Nov 2012, Kirill Yukhin wrote:
> Hi,
>
> >> But... I don't really understand it, so here's some feedback on
> >> the documentation: Regarding the language, a definite article is
>
> Patch with fixed doc is attached. Changelog is the same
>
> Is it OK?
The structure is much improved and q
> From: Eric Botcazou
> Date: Mon, 5 Nov 2012 15:29:11 +0100
> > But, for cris-elf (and reasonably the same for other targets)
> > there might not be such a constant-pool entry in the first
> > place: the vectors are too short to rule out piecewise
> > initialization as optimal for size (counting
On Wed, 7 Nov 2012, Vladimir Makarov wrote:
> On 12-11-07 5:27 PM, H.J. Lu wrote:
> > You should check !ia32 target:
> >
> > /* { dg-do compile { target { ! { ia32 } } } } */
> >
> >
> Thanks, H.J. I've just fixed it.
>
> Index: testsuite/ChangeLog
> ===
The problem exposed in PR55030 (repeatable on x86_64-linux with -m32 at
r192676) is that the fake-frame-pointer "frame" is replaced with the
actual-frame-pointer "bp" in cse1, around the critical insn in
__builtin_setjmp_receiver that restores their defined offset. The
patch in PR55030/r192676 rem
While the fallout(*) from the libsanitizer commit is handled,
it's obvious it should have a noconfigdirs= section in
toplevel/configure.ac like the other target libs. Here's what I
committed after observing that a cris-elf build passed, where it
previously failed building libsanitizer which wrongl
...those of you who don't have the equivalent of the patch
below in your ports, that is. You'll likely only notice through
a slightly reduced debugging experience and
g++.dg/debug/dwarf2/non-virtual-thunk.C failing. Yes, the docs
should mention these functions need to be called IMHO obviously,
bu
> From: Dodji Seketeli
> Date: Tue, 13 Nov 2012 16:04:12 +0100
> I guess when the issue of the missing files is resolved, we can enable
> building libsanitizer on Darwin proper. Here is the patchlet I am
> proposing so far http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00993.html.
That's the dire
> From: Richard Henderson
> Date: Tue, 13 Nov 2012 21:38:40 +0100
> On 11/13/2012 05:24 AM, Jakub Jelinek wrote:
> > Yes. And it shouldn't be just based on target CPU, but also based
> > on target OS, I don't think libsanitizer supports anything but linux (glibc
> > + maybe android) right now, w
> From: Richard Henderson
> Date: Wed, 14 Nov 2012 02:34:32 +0100
> On 11/13/2012 05:20 PM, Hans-Peter Nilsson wrote:
> > Right. And, I think it's worth to repeat ;) that IMHO best to
> > there simply check that -faddress-sanitizer can compile
> > error-free (i.e
> From: Ed Smith-Rowland <3dw...@verizon.net>
> Date: Fri, 9 Nov 2012 05:55:16 +0100
> libcpp
>
> 2012-11-09 Ed Smith-Rowland <3dw...@verizon.net>
>
> PR c++/54413
> * include/cpplib.h (cpp_interpret_float_suffix): Add cpp_reader* arg.
> (cpp_interpret_int_suffix): Add
On Fri, 9 Nov 2012, Andrew Pinski wrote:
> Committed the testcase as obvious after a quick test to make sure it
> works. Note someone might need to mark the testcase as only
> executable on targets which have 32bit ints.
Someone like you? There are plenty of greppable
effective-target attributes
1301 - 1400 of 2382 matches
Mail list logo
