On Sat, 2016-02-13 at 07:50 +, James Greenhalgh wrote:
> > So do you prefer e.g. following? Bootstrapped/regtested on x86_64
> > -linux and
> > i686-linux.
> >
> > 2016-02-12 Jakub Jelinek
> >
> > PR rtl-optimization/69764
> > PR rtl-optimization/69771
> > * optabs.c (expand_
On Fri, Feb 12, 2016 at 05:34:21PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 12, 2016 at 03:20:07PM +0100, Bernd Schmidt wrote:
> > >>- mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
> > >>+ mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode1;
> > >>if (xmode1 != VOID
On 02/13/2016 03:36 AM, John David Anglin wrote:
As far as the avcrc.c reduced testcase, it didn't trigger the original bug on
hppa-unknown-linux-gnu.
Odd, I see the same transformation in the dumps. Do you think you could
investigate a bit so we get a useful testcase to add?
Bernd
On Thu, Feb 11, 2016 at 10:41:02PM +, Joseph Myers wrote:
> For proposed features, I find documentation and testcases of much more
> value than the rest of the implementation.
I can see the logic of that. This is the part that I find a little
tricky, so please bear with me here.
> Critical
On 2016-02-12, at 11:28 AM, Bernd Schmidt wrote:
> I'm attaching a full patch. John David Anglin is currently running tests on
> PA which may take a while. He's confirmed it fixes his testcase, and the
> earlier 67781 testcase seems to be cured as well (only looked at generated
> assembly, don'
This test needs alias support.
Tested on hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2016-02-12 John David Anglin
* gcc.dg/pr67964.c: Add dg-require-alias.
Index: gcc.dg/pr67964.c
Hi,
The attached patch fixes PR 67636 in a simple way by adding yet another
bit extraction pattern as mentioned in PR 64345#c3.
Tested on sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,
-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed to trunk as r233397.
C
On 02/12/2016 05:51 AM, Bernd Schmidt wrote:
On 02/12/2016 08:05 AM, David Wohlferd wrote:
Actually, it was my intent that this apply to v6. It's not like there
is a significant change here. We're documenting long-time behavior, and
adding a (disabled) warning.
The doc patch (minus mentionin
On 10/02/16 13:31, Claudiu Zissulescu wrote:
Please find attached the amended patch for FPU instructions.
Ok to apply?
+(define_insn "*cmpdf_fpu"
I'm wondering - could you compare with +zero using a literal (adding an
alternative)?
(No need to hold up the main patch, but you can consider it
This patch to libgo ports https://golang.org/cl/18150 from the master
library to the gccgo runtime. This installs signal handlers
synchronously when building a Go archive, rather than potentially
racing against the main program. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed
On Fri, Jan 29, 2016 at 11:46 AM, Andres Tiraboschi
wrote:
> 2016-01-28 17:54 GMT-03:00 Joseph Myers :
>> Any patch adding a new option needs to add documentation for it to
>> invoke.texi (both substantive documentation, and inclusion in the summary
>> lists of options).
>>
>> --
>> Joseph S. Myer
This patch uses g++ instead of gcc to compile a c++ source file. The GNU
buildbot is currently failing with a c++ related link error that I have
not been able to reproduce; I'm hoping using g++ will fix the issue.
2016-02-12 Walter Lee
* config/tilepro/t-tilepro: Replace CC_FOR_BUIL
On Feb 12, 2016, at 1:01 PM, Jonathan Wakely wrote:
> OK, thanks.
t double checked the log file:
-D__STDCPP_WANT_MATH_SPEC_FUNCS__ -DMAX_ITERATIONS=5
which I neglected to do the first time. With that check looking good as well,
I checked it in, thanks.
This patch removes ti from softfp_int_modes for 32-bit config, to fix a
compile-time assert failure.
2016-02-12 Walter Lee
* config.host (tilegx*-*-linux*): remove ti from
softfp_int_modes for 32-bit configs.
Index: libgcc/config.host
==
Hi Bernd. Thanks for looking into that. Your patch looks good and I
have checked it in myself.
Walter
On 1/1/2016 4:31 PM, Bernd Edlinger wrote:
Hi Walter,
while playing with the tilegx cross compiler I noticed another defect.
Currently building a tilegx cross compiler fails in libgcc mul
On 12/02/16 12:39 -0800, Mike Stump wrote:
On Feb 12, 2016, at 10:07 AM, Jonathan Wakely wrote:
On 12/02/16 09:52 -0800, Mike Stump wrote:
On Feb 11, 2016, at 3:57 AM, Jonathan Wakely wrote:
On 10/02/16 22:36 -0800, Mike Stump wrote:
I’m seeing:
/home/mrs/work1/gcc/libstdc++-v3/testsuite
On Feb 12, 2016, at 10:07 AM, Jonathan Wakely wrote:
> On 12/02/16 09:52 -0800, Mike Stump wrote:
>> On Feb 11, 2016, at 3:57 AM, Jonathan Wakely wrote:
>>> On 10/02/16 22:36 -0800, Mike Stump wrote:
I’m seeing:
/home/mrs/work1/gcc/libstdc++-v3/testsuite/special_functions/18_rie
On 02/12/2016 01:49 PM, Bernd Schmidt wrote:
This is a PR where LRA creates a read from an uninitialized stack
slot. That stack slot is supposed to hold the value of the PIC register.
What seems to happen is that we have two passes making different choices:
Choosing alt 0 in insn 143:
On 02/12/2016 12:06 PM, David Malcolm wrote:
On Fri, 2016-02-12 at 11:25 -0700, Jeff Law wrote:
On 02/09/2016 01:54 PM, David Malcolm wrote:
gcc/ChangeLog:
PR other/69554
* diagnostic-show-locus.c (struct line_span): New struct.
(layout::get_first_line): Delete.
On Fri, 2016-02-12 at 11:25 -0700, Jeff Law wrote:
> On 02/09/2016 01:54 PM, David Malcolm wrote:
>
> > gcc/ChangeLog:
> > PR other/69554
> > * diagnostic-show-locus.c (struct line_span): New struct.
> > (layout::get_first_line): Delete.
> > (layout::get_last_line): Delete.
> >
This is a PR where LRA creates a read from an uninitialized stack slot.
That stack slot is supposed to hold the value of the PIC register.
What seems to happen is that we have two passes making different choices:
Choosing alt 0 in insn 143: (0) =x (1) 0 (2) r {sse2_pinsrw}
[...]
On 02/09/2016 01:54 PM, David Malcolm wrote:
gcc/ChangeLog:
PR other/69554
* diagnostic-show-locus.c (struct line_span): New struct.
(layout::get_first_line): Delete.
(layout::get_last_line): Delete.
(layout::get_num_line_spans): New member function.
On 02/12/2016 11:12 AM, David Malcolm wrote:
The problem is that struct spec_list's "name" field is declared const:
const char *name;/* name of the spec. */
and likewise for the "name" field within struct spec_list_1:
const char *const name;
Some are statically allocated,
On Fri, 2016-02-12 at 00:51 -0700, Jeff Law wrote:
> On 02/11/2016 10:12 PM, David Malcolm wrote:
> > In r227188 I introduced driver::finalize () which resets
> > all state within gcc.c, allowing the driver code to embedded
> > inside libgccjit and run repeatedly in-process.
> >
> > Running this o
On 12/02/16 09:52 -0800, Mike Stump wrote:
On Feb 11, 2016, at 3:57 AM, Jonathan Wakely wrote:
On 10/02/16 22:36 -0800, Mike Stump wrote:
I’m seeing:
/home/mrs/work1/gcc/libstdc++-v3/testsuite/special_functions/18_riemann_zeta/check_value.cc:
In function 'void test(const testcase_riemann_zet
On 02/07/2016 10:55 PM, Alan Modra wrote:
This test was added by git commit 7c5f55675 (svn 231569)
Here's the log message from that commit:
avoid alignment of static variables affecting stack's
Function (or more narrow) scope static variables (as well as others not
placed on the
On Fri, Feb 12, 2016 at 5:31 PM, Kumar, Venkataramanan
wrote:
> Hi Maintainers,
>
> Below patch does some minor changes to pipe reservations in znver1.md.
> GCC bootstrap completed.
>
> GCC regression testing underway. Ok for trunk if the testing passes?
>
>
> ChangeLog
> -
> 2016-02-1
On 02/12/2016 09:28 AM, Bernd Schmidt wrote:
PR69714 is an issue where the bswap pass makes an incorrect
transformation on big-endian targets. The source has a 32-bit bswap, but
PA doesn't have a pattern for that. Still, we recognize that there is a
16-bit bswap involved, and generate code for th
On 02/12/2016 02:04 AM, Richard Biener wrote:
So what am I missing here? Is there any kind of aliasing issues I need to
be aware of? Any other dragons lurking?
I think what you are missing is that you'll "optimize"
_Complex double x, y;
void foo (void)
{
x = y;
}
then but dependent on
So do you prefer e.g. following? Bootstrapped/regtested on x86_64-linux and
i686-linux.
- mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
+ mode1 = (GET_MODE (xop1) != VOIDmode || canonicalize_op1)
+ ? GET_MODE (xop1) : mode;
Placement of parentheses is wrong for format
On Fri, Feb 12, 2016 at 03:20:07PM +0100, Bernd Schmidt wrote:
> >>- mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
> >>+ mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode1;
> >>if (xmode1 != VOIDmode && xmode1 != mode1)
> >> {
>
> Here, things aren't so clear,
Committed on gcc-5-branch as rev. 233379.
2016-02-12 0:04 GMT+01:00 Alessandro Fanfarillo :
> Dear all,
>
> in attachment the EVENT patch for gcc-5-branch directly back-ported
> from the trunk.
>
> Built and regtested on x86_64-pc-linux-gnu. I plan to commit this
> patch this evening (Feb 12th, CE
Hi Maintainers,
Below patch does some minor changes to pipe reservations in znver1.md.
GCC bootstrap completed.
GCC regression testing underway. Ok for trunk if the testing passes?
ChangeLog
-
2016-02-12 Venkataramanan Kumar
* config/i386/znver1.md
(znver1_pop,
PR69714 is an issue where the bswap pass makes an incorrect
transformation on big-endian targets. The source has a 32-bit bswap, but
PA doesn't have a pattern for that. Still, we recognize that there is a
16-bit bswap involved, and generate code for that - loading the halfword
at offset 2 from
On 02/12/2016 03:08 PM, Marek Polacek wrote:
We've got a report that GCC is crashing when building a package on i686;
there was an ICE in assemble_integer. Turned out this ICE was already fixed
by r233216, so I reduced it and would like to add it to the testsuite.
Tested on x86_64-linux and i68
On 12/02/16 14:56, Charles Baylis wrote:
> When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc
> function are not generated as long calls.
>
> This is encountered when building an allyesconfig Linux kernel because
> the Linux build system generates very large sections by partial
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Esperanto team of translators. The file is available at:
http://translationproject.org/latest/cpplib/eo.po
(This file, 'cpplib-6.1-b201601
On 12/02/16 15:02, Jiong Wang wrote:
On 12/02/16 14:56, Charles Baylis wrote:
This is encountered when building an allyesconfig Linux kernel because
the Linux build system generates very large sections by partial
linking a large number of object files. This causes link failures
I have trie
On 12/02/16 14:56, Charles Baylis wrote:
This is encountered when building an allyesconfig Linux kernel because
the Linux build system generates very large sections by partial
linking a large number of object files. This causes link failures
I have tried latest BFD linker? I suspect the follo
When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc
function are not generated as long calls.
This is encountered when building an allyesconfig Linux kernel because
the Linux build system generates very large sections by partial
linking a large number of object files. This cause
On Thu, Feb 11, 2016 at 10:18 PM, Markus Trippelsdorf
wrote:
> On 2016.02.08 at 09:49 -0700, Jeff Law wrote:
>> On 01/18/2016 08:52 PM, Kugan wrote:
>> >
>> >2016-01-19 Kugan Vivekanandarajah
>> >
>> > PR middle-end/66726
>> > * tree-ssa-reassoc.c (optimize_range_tests): Handle tcc_comp
On Thu, Feb 11, 2016 at 02:17:43PM -0700, Martin Sebor wrote:
> >>Actually, there is one other thing that might be wort mentioning
> >>about flexible array members.
> >>
> >>The type and mangling of flexible array members has changed. While
> >>in GCC 5 and prior the type of a flexible array membe
On 02/12/2016 02:47 PM, Richard Biener wrote:
Another possibility, only do the convert_modes from VOIDmode for
shift_optab_p's xop1, and keep doing what we've done before otherwise.
That looks like a very targeted and safe fix indeed.
You two can obviously go ahead and sort this out, I'll jus
On 12/02/16 13:33, Bernd Schmidt wrote:
On 02/12/2016 02:18 PM, Jiong Wang wrote:
PR rtl-optimization/69752
* ira.c (update_equiv_regs): When looking for more than a single
SET,
also take other side effects into account.
Will it be better that we don't remove the insn if it has
We've got a report that GCC is crashing when building a package on i686;
there was an ICE in assemble_integer. Turned out this ICE was already fixed
by r233216, so I reduced it and would like to add it to the testsuite.
Tested on x86_64-linux and i686-linux, ok for trunk?
2016-02-12 Marek Polac
(Replying to multiple messages at once ...)
Michael Meissner wrote:
> At the present time, we do not allow DImode to go into Altivec
> registers. Mostly it was due to reload complications in the power8 time frame,
> where we didn't have d-form addressing for the Altivec registers and
> interferen
On Fri, Feb 12, 2016 at 02:45:40PM +0100, Richard Biener wrote:
> > The case I'm worried about is if xop1 is a constant in narrower
> > mode (let's say QImode), e.g. -15, unsignedp is 1, and xmode1 is
> > wider. Then previously we'd zero extend it, thus get
> > 0xf1, but with your patch we'll end
On Fri, 12 Feb 2016, Jakub Jelinek wrote:
> On Fri, Feb 12, 2016 at 01:50:08PM +0100, Richard Biener wrote:
> > > - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
> > > - if (xmode1 != VOIDmode && xmode1 != mode1)
> > > + mode1 = GET_MODE (xop1);
> > > + if (xmode1 != mode1)
> >
On Fri, Feb 12, 2016 at 02:28:39PM +0100, Bernd Schmidt wrote:
> On 02/12/2016 02:26 PM, Marek Polacek wrote:
> >On Fri, Feb 12, 2016 at 02:17:19PM +0100, Andreas Schwab wrote:
> >>FAIL: gcc.dg/pr69522.c (test for excess errors)
> >>Excess errors:
> >>/daten/a
On Fri, 12 Feb 2016, Jakub Jelinek wrote:
> On Fri, Feb 12, 2016 at 01:48:36PM +0100, Richard Biener wrote:
> > But my patch should deal with all this.
> >
> > - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
> > - if (xmode1 != VOIDmode && xmode1 != mode1)
> > + mode1 = GET_MOD
On 02/12/2016 02:18 PM, Jiong Wang wrote:
PR rtl-optimization/69752
* ira.c (update_equiv_regs): When looking for more than a single
SET,
also take other side effects into account.
Will it be better that we don't remove the insn if it has side-effect
instead of don't record the equ
On Fri, Feb 12, 2016 at 01:50:08PM +0100, Richard Biener wrote:
> > - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
> > - if (xmode1 != VOIDmode && xmode1 != mode1)
> > + mode1 = GET_MODE (xop1);
> > + if (xmode1 != mode1)
> > {
> >xop1 = convert_modes (xmode1, mode
On 02/12/2016 02:26 PM, Marek Polacek wrote:
On Fri, Feb 12, 2016 at 02:17:19PM +0100, Andreas Schwab wrote:
FAIL: gcc.dg/pr69522.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:2:8: error:
struct has no members [-Wpedantic]
/daten/aranym
On Fri, Feb 12, 2016 at 02:17:19PM +0100, Andreas Schwab wrote:
> FAIL: gcc.dg/pr69522.c (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:2:8: error:
> struct has no members [-Wpedantic]
> /daten/aranym/gcc/gcc-20160212/gcc/t
On 12/02/16 07:43, Jeff Law wrote:
On 02/11/2016 06:28 PM, Bernd Schmidt wrote:
This seems fairly straightforward:
(insn 213 455 216 6 (set (reg:SI 266)
(mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748
{*thumb1_movsi_insn}
(expr_list:REG_EQUAL (const_int -1044200508 [
FAIL: gcc.dg/pr69522.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:2:8: error:
struct has no members [-Wpedantic]
/daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:9:8: error: ISO C
forbids empty initializer braces [-Wpedantic
Hi,
This patch fixes instrumentation thunk recognition condition in lto_output.
This avoids missing required thunks in ltrans modules. Bootstrapped and
regtested on x86_64-pc-linux-gnu. Committed to trunk.
Thanks,
Ilya
--
gcc/
2016-02-12 Ilya Enkovich
PR target/69729
* l
Hi,
This patch fixes a warning in test used for effective MPX target check. Fix
allows to use test with g++. Bootsrapped and tested on x86_64-pc-linux-gnu.
Applied to trunk.
Thanks,
Ilya
--
gcc/testsuite/
2016-02-11 Ilya Enkovich
* lib/mpx-dg.exp: Fix warning in check_effective_
On Fri, Feb 12, 2016 at 01:48:36PM +0100, Richard Biener wrote:
> But my patch should deal with all this.
>
> - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode;
> - if (xmode1 != VOIDmode && xmode1 != mode1)
> + mode1 = GET_MODE (xop1);
> + if (xmode1 != mode1)
> {
>x
On 02/12/2016 08:05 AM, David Wohlferd wrote:
Actually, it was my intent that this apply to v6. It's not like there
is a significant change here. We're documenting long-time behavior, and
adding a (disabled) warning.
The doc patch (minus mentioning the warning) could go in now, but for
gcc-6
On Fri, 12 Feb 2016, Richard Biener wrote:
> On Fri, 12 Feb 2016, Jakub Jelinek wrote:
>
> > On Fri, Feb 12, 2016 at 01:15:11PM +0100, Bernd Schmidt wrote:
> > > >Ah, indeed looks like a dup. Let's go with your version which had
> > > >feedback from Bernd already. Might want to add my testcase
On Fri, 12 Feb 2016, Jakub Jelinek wrote:
> On Fri, Feb 12, 2016 at 01:15:11PM +0100, Bernd Schmidt wrote:
> > >Ah, indeed looks like a dup. Let's go with your version which had
> > >feedback from Bernd already. Might want to add my testcase (w/o the
> > >runtime outcome test).
> >
> > Actually
On Fri, Feb 12, 2016 at 01:15:11PM +0100, Bernd Schmidt wrote:
> >Ah, indeed looks like a dup. Let's go with your version which had
> >feedback from Bernd already. Might want to add my testcase (w/o the
> >runtime outcome test).
>
> Actually, Richard I was just looking at Jakub's second patch an
On 02/12/2016 11:46 AM, Richard Biener wrote:
On Fri, 12 Feb 2016, Jakub Jelinek wrote:
On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote:
I am testing the following patch which fixes PR69771 where the code
doesn't match the comment before it. We get to expand a QImode << QImo
On 02/12/2016 04:27 AM, Alan Modra wrote:
I don't understand this comment. If we're pushing a reload of the
inner reg, then the SECONDARY_MEMORY_NEEDED code in push_reload will
fire. Why then should there be any need to do anything special in
find_reloads_address_1 regarding secondary memory?
On 12/02/16 07:43, Jeff Law wrote:
On 02/11/2016 06:28 PM, Bernd Schmidt wrote:
This seems fairly straightforward:
(insn 213 455 216 6 (set (reg:SI 266)
(mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748
{*thumb1_movsi_insn}
(expr_list:REG_EQUAL (const_int -1044200508 [0x
On Thu, 11 Feb 2016, Jakub Jelinek wrote:
> On Thu, Feb 11, 2016 at 10:22:24AM +0100, Richard Biener wrote:
> > The other option is to simply not split the function in this case.
>
> Here is a better fix (but it needs the other patch I've sent, so that
> what is return_bb stays the same).
>
> Th
On Thu, 11 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> While the cgraph versioning code is able to deal with clobber stmts that
> refer to SSA_NAMEs set by basic blocks not split into the versioned
> function, and similarly with debug stmts (clobbers refererring to those
> are removed and debug stmt
On 26/01/16 13:49, Jakub Jelinek wrote:
On Tue, Jan 26, 2016 at 01:38:39PM +0100, Tom de Vries wrote:
Ping^3. ( https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01089.html )
First of all, I wonder if it wouldn't be far easier to handle these during
gimplification rather than during omp expansion
FRE/PREs redundant store removal code doesn't honor the middle-end
memory model which says that all stores change the dynamic type of
the affected memory region. So it removed the second 'int' store in
MEM[(int *)p_3] = 1;
MEM[(double *)p_3] = 0.0;
MEM[(int *)p_3] = 1;
which is not valid
On Fri, 12 Feb 2016, Jakub Jelinek wrote:
> On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote:
> >
> > I am testing the following patch which fixes PR69771 where the code
> > doesn't match the comment before it. We get to expand a QImode << QImode
> > shift but the shift amount was
On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild wrote:
> Hi all,
>
> it wasn't my intention to start such a big discussion for such a small
> thing. Please stop this academic battle and get back to the issue at
> hand:
>
> Thomas is examining a symbol, that
>
> - has come through the scanner,
> While working on the -Waddress fix I've posted earlier today, I've noticed
> that the C and C++ FE disagree on the spelling - C uses US english spelling,
> while C++ uses UK english spelling.
> This patch switches to US english spelling of these 2 words, in
> diagnostics, documentation and commen
On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote:
>
> I am testing the following patch which fixes PR69771 where the code
> doesn't match the comment before it. We get to expand a QImode << QImode
> shift but the shift amount was of type int and thus it was expanded
> as SImode cons
I am testing the following patch which fixes PR69771 where the code
doesn't match the comment before it. We get to expand a QImode << QImode
shift but the shift amount was of type int and thus it was expanded
as SImode constant. Then
/* In case the insn wants input operands in modes different
Hi all,
it wasn't my intention to start such a big discussion for such a small
thing. Please stop this academic battle and get back to the issue at
hand:
Thomas is examining a symbol, that
- has come through the scanner, i.e., it adheres to the rules of
gfortran, especially it is known to be s
On 02/10/2016 02:27 PM, David Edelsohn wrote:
> On Wed, Feb 10, 2016 at 1:52 AM, Michael Haubenwallner
> wrote:
>>
>> On 02/08/2016 02:59 PM, David Edelsohn wrote:
>>> Runtime linking is disabled by default on AIX, and I disabled it for
>>> libstdc++.
>>
>> For large applications mainly develope
On Fri, Feb 12, 2016 at 02:08:53AM +0100, Bernd Schmidt wrote:
> Isn't the problem just that shifts are unusual as binops, in that the two
> operands can have different modes? We have the appropriate mode for the
> shift count in xmode1, so I think we should just always rebuild a CONST_INT
> in tha
On Fri, Feb 12, 2016 at 12:53 AM, Jeff Law wrote:
>
> So I've never thought much about our Complex support and I don't have a lot
> of confidence in the coverage for our testsuite for these changes. So I'd
> really appreciate someone with more experience thinking about this issue for
> a bit.
>
>
> This causes LTO/PGO bootstrap on ppc64le to ICE all over the place:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69781
And a comparison failure with -enable-checking=yes,rtl on x86-64/Linux:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
B
On 02/11/2016 08:43 AM, David Malcolm wrote:
On Thu, 2016-02-11 at 10:16 +0100, Richard Biener wrote:
On Wed, Feb 10, 2016 at 5:25 PM, Bernd Schmidt
wrote:
On 02/09/2016 09:44 PM, David Malcolm wrote:
This is a bug in a new feature, so it isn't a regression as such,
but
it's fairly visible,
On 02/11/2016 08:27 PM, Alan Modra wrote:
On Thu, Feb 11, 2016 at 03:29:05PM +0100, Bernd Schmidt wrote:
On 02/11/2016 10:45 AM, Alan Modra wrote:
Due to uses elsewhere in vsx instructions, reload chooses to put
psuedo 185 in fr31, which can't be used as a base register in the
following:
Wha
Hi Janne,
[std::string]
As we're supposed to be C++ nowadays, why aren't we
using that?
My reason is simple: I know C and Fortran. I hardly know C++,
and I don't want to learn it for the sake of some largely
irrelevant micro-optimizations.
We should restrict C++ usage to those cases where th
83 matches
Mail list logo
