The problem was spotted while fixing PR53272, a target bug with
crisv32-* involving the error-prone notice_update_cc function.
When wrapping up the test-case to use as a run-test, adding main
and auxiliary functions to the reduced test-case unexpectedly
made the bug go away. This despite all func
On 12-05-07 10:56 , Cary Coutant wrote:
2012-05-07 Sterling Augustine
Cary Coutant
include/
* dwarf2.h (enum dwarf_form): Remove DW_FORM_GNU_ref_index.
(enum dwarf_attribute): Replace DW_AT_GNU_ref_base with
DW_AT_GNU_ranges_base.
gcc/
* gcc/dwarf2ou
On 05/08/2012 04:10 AM, Jason Merrill wrote:
How do we even get to calling cp_truthvalue_conversion?
ocp_convert wants to do that, around line 750... And I have a brand new
proposal ;)
The patchlet below (which passes testing) leads to very consistent error
messages for the testcase in the PR
How do we even get to calling cp_truthvalue_conversion?
Jason
On Mon, May 7, 2012 at 7:10 PM, Sterling Augustine
wrote:
> This is the second in the series of patches to make c decl pretty printing
> more closely match the demangler. A full explanation is here:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00512.html
>
> OK for mainline?
Now I realize som
On 20.08.2011 21:51, Matthias Klose wrote:
> Multiarch [1] is the term being used to refer to the capability of a system to
> install and run applications of multiple different binary targets on the same
> system.
please find attached an updated for the trunk (2012-05-08). The multiarch
triplets a
On 05/07/2012 07:04 PM, Aldy Hernandez wrote:
Andrew suggested the correct fix was to add a new pass that was able
to do some ?? flow sensitive data flow analysis ?? that could discover
these unreachable paths and insert the 0 phis at the start of the
blocks automatically. But that seemed l
This is the second in the series of patches to make c decl pretty printing
more closely match the demangler. A full explanation is here:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00512.html
OK for mainline?
Sterling
2012-05-07 Sterling Augustine
* c-family/c-pretty-print.c (pp_c
> +Honza and Nathan.
>
> David
>
> On Thu, May 3, 2012 at 10:52 AM, Teresa Johnson wrote:
> > This patch adds functionality to libgcov to enable user applications to
> > collect profile data only in regions of interest. This is useful, for
> > example, to collect profile data from a long-running
The lto plugin is installed without x bits set, but gcc-ar.c still checks for
the execute bits. There is no need to have the lto plugin to have the x bits
set, so just check that it is readable.
Ok for the trunk and the 4.7 branch?
Matthias
* (main): Don't check for execute bits for the
Hi. Sorry for the delay. There were various tricky hiccups along the
way to bootstrappability and regression cleanliness...
On 04/26/12 04:51, Richard Guenther wrote:
On Wed, 25 Apr 2012, Aldy Hernandez wrote:
On 04/25/12 06:45, Richard Guenther wrote:
On Tue, Apr 24, 2012 at 7:43 PM, Aldy
This is the first in a series of patches to get split-dwarf debug output
(AKA the Fission project: http://gcc.gnu.org/wiki/DebugFission)
contributed to the mainline.
Under certain circumstances, dwarf2out.c:dwarf_name calls into the front end's
decl pretty-printer to produce names for debug info.
On Mon, May 7, 2012 at 4:58 PM, Sharad Singhai wrote:
> This is the first patch for planned improvements to dump
> infrastructure. Please reference the discussion in
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02088.html.
>
> The following small patch allows selective tree and rtl dumps on
> s
This is the first patch for planned improvements to dump
infrastructure. Please reference the discussion in
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02088.html.
The following small patch allows selective tree and rtl dumps on
stderr instead of named files. Later -fopt-info can be implemented
Hi,
I am preparing to update GLIBC longlong.h from GCC. This patch updates
GCC longlong.h to use a URL instead of an FSF postal address and replace
spaces with tab. OK to install?
Since I'd like to simply copy longlong.h from GCC release branch to GLIBC,
Is this also OK for 4.7 branch?
Thanks
On May 7, 2012, at 21:27 , Olivier Hainque wrote:
> Of course. That was actually my point in offering
> to open a PR, so that Alan (who did the nice recent
> reorg) can take it from there. He will certainly be
> more efficient than me in resolving this :)
PR 53271
On Mon, May 7, 2012 at 10:35 PM, Uros Bizjak wrote:
Now with a patch and ChangeLog:
2012-05-07 Uros Bizjak
PR target/53250
* config/i386/i386.c (ix86_set_reg_reg_cost): New function.
(ix86_rtx_costs): Handle SET.
> Patch was tested on x86_64-pc-linux-gnu {,-m32}.
>
>
Hello!
Attached patch implements reg->reg move cost function for x86, as
required by new lower-subreg.c patch. The patch fixes:
FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"
failure on 32bit x86 targets, and for following testcase:
long long test (long long a, long long b)
OK for Google branches.
On Mon, May 7, 2012 at 12:21 PM, Jing Yu wrote:
> I would like to port this patch to google/gcc-4_6 and also
> google/gcc-4_6_2-mobile.
>
> From reading the patch, it does not change config for non-Android target.
>
> bootstrap,crosstool tests finished successfully on goog
Hello,
this patch combines for vectors a concat and a shuffle. An example on x86
would be:
__m128d f(double d){
__m128d x=_mm_setr_pd(-d,d);
return _mm_shuffle_pd(x,x,1);
}
which was compiled as:
vmovsd .LC0(%rip), %xmm1
vxorpd %xmm0, %xmm1, %xmm1
vunpcklpd
On Sun, May 6, 2012 at 11:41 AM, Richard Sandiford
wrote:
> x32 uses a mixture of MEM address modes for the same address space.
> Some MEMs have SImode addresses, some have DImode. This means that
> the currently common idiom:
>
> targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem))
>
> isn'
On May 7, 2012, at 20:31 , David Edelsohn wrote:
> You can open a PR, but I assume that you mean fixing the problem
> before the patch is committed.
Yes, that was the intent.
> I would like to give Alan a chance to
> comment and look into it.
Of course. That was actually my point in offering
I would like to port this patch to google/gcc-4_6 and also
google/gcc-4_6_2-mobile.
>From reading the patch, it does not change config for non-Android target.
bootstrap,crosstool tests finished successfully on google/gcc-4_6.
Built ARM android toolchain successfully.
OK?
Thanks,
Jing
On Thu, M
On May 7, 2012, at 6:11 AM, Michael Matz wrote:
> I'd like to retain the #if 0 code therein,
Can you structure this code as
#define DEBUG 0
if (DEBUG) ...
?
If so, that would be a preferable way to structure the code.
Nice work.
On May 4, 2012, at 4:01 PM, Georg-Johann Lay wrote:
> Mike Stump schrieb:
>> On May 3, 2012, at 12:50 PM, Georg-Johann Lay wrote:
>>> It's hardly possible to write proper rtx_costs for SET:
>>> 1) What should be the cost of (const_int 1) if you don't see the machine
>>> mode? Is it QI, is it HI, i
This patch from Rémy Oudompheng fixes the Go frontend lexer to not treat
0x123i as 123i. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
diff -r 8671bcd0c298 go/lex.cc
--- a/go/lex.cc Mon May 07 11:35:33 2012 -0700
+++ b/go/lex.cc Mon May
This patch from Rémy Oudompheng fixes the handling of ^'a' or -'^' in
the Go frontend. It used to crash, rather than computing the
appropriate value. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
<#part type="text/x-diff" filename="~/f
This patch from Rémy Oudompheng fixes the handling of ^'a' or -'^' in
the Go frontend. It used to crash, rather than computing the
appropriate value. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
<#part type="text/x-diff" filename="~/f
On 05/07/2012 08:23 PM, Paolo Carlini wrote:
Index: typeck.c
===
--- typeck.c(revision 187249)
+++ typeck.c(working copy)
@@ -4782,7 +4782,11 @@ cp_truthvalue_conversion (tree expr)
return ret;
}
else
-retu
On Mon, May 7, 2012 at 1:24 PM, Olivier Hainque wrote:
>
> On May 7, 2012, at 18:59 , David Edelsohn wrote:
>> Yes, exactly. If we can work through the fallout, this is exactly the
>> type of cleanup I envisioned.
>
> Great :)
>
>> Thanks, David
>
> Do you want a PR for the fallout ? It is not
This patch from Rémy Oudompheng fixes a bug in the Go frontend: it was
permitting the ! unary operator with integer operands, but in the Go
language ! is only permitted with boolean operands. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and
4.7 branch.
Ian
Hi,
On 05/07/2012 08:07 PM, Manuel López-Ibáñez wrote:
On 7 May 2012 19:40, Paolo Carlini wrote:
On 05/07/2012 07:18 PM, Paolo Carlini wrote:
a.cc:5:12: error: could not convert ‘foo()’ from ‘void’ to ‘bool’
if (foo())
Is this the error message we want to see for the former testcase, or w
On Mon, May 7, 2012 at 11:04 AM, Maxim Kuvyrkov wrote:
> On 6/05/2012, at 7:02 PM, Igor Zamyatin wrote:
>
>> Hi!
>>
>> The patch enables stack protector for Android.
>> Android targets don't contain necessary information in features.h so
>> we explicitly enable stack protector for Android.
>>
>> B
On 7 May 2012 19:40, Paolo Carlini wrote:
> On 05/07/2012 07:18 PM, Paolo Carlini wrote:
>
> a.cc:5:12: error: could not convert ‘foo()’ from ‘void’ to ‘bool’
> if (foo())
>
> Is this the error message we want to see for the former testcase, or we want
> something slightly different?
If "foo()"
On 6/05/2012, at 7:02 PM, Igor Zamyatin wrote:
> Hi!
>
> The patch enables stack protector for Android.
> Android targets don't contain necessary information in features.h so
> we explicitly enable stack protector for Android.
>
> Bootstrapped and regtested on x86_64. Ok to commit?
>
> Thanks,
AVR-LibC switched from using either signal /or/ interrupt function
attribute to using both at the same time.
This was never documented or implemented but worked accidentally for
some time, but results in wrong code for 4.7+
This patch adds better documentation of these attributes and makes
'inter
This patch is for the google/gcc-4_6 branch.
Fission improvements and bug fixes. Move the .debug_loc section to the
.dwo file, and eliminates the .debug_ref section, replacing references
to range list entries with offsets relative to the value given by
DW_AT_GNU_ranges_base.
Bootstrapped and tes
On 05/07/2012 07:18 PM, Paolo Carlini wrote:
On 05/07/2012 07:16 PM, Jason Merrill wrote:
I don't think the diagnostic is meaningless; since a() is ill-formed,
b() has type void.
Sure we do understand it ;)
But we ought to give a more helpful message when an expression used
as a truth value
On May 7, 2012, at 18:59 , David Edelsohn wrote:
> Yes, exactly. If we can work through the fallout, this is exactly the
> type of cleanup I envisioned.
Great :)
> Thanks, David
Do you want a PR for the fallout ? It is not related to this patch
at all. I can look into it further and make su
On 05/07/2012 07:16 PM, Jason Merrill wrote:
I don't think the diagnostic is meaningless; since a() is ill-formed,
b() has type void.
Sure we do understand it ;)
But we ought to give a more helpful message when an expression used
as a truth value has an unsuitable type.
Thus something much mo
I don't think the diagnostic is meaningless; since a() is ill-formed,
b() has type void. But we ought to give a more helpful message when an
expression used as a truth value has an unsuitable type.
Jason
On Mon, May 7, 2012 at 12:10 PM, Joseph S. Myers
wrote:
> On Mon, 7 May 2012, Olivier Hainque wrote:
>
>> Joseph and David suggested to address this in a more general fashion,
>> along lines proposed in
>>
>> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01667.html
>>
>> The attached patch is a f
On Wed, May 2, 2012 at 11:04 AM, H.J. Lu wrote:
> On Wed, May 2, 2012 at 10:44 AM, Sriraman Tallam wrote:
>
> 1. Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
> foo for AVX and SSE3, on AVX processors, which foo will be
> selected?
foo for AVX will get called since
On Fri, May 4, 2012 at 10:35 AM, Eric Botcazou wrote:
> 2012-05-04 Eric Botcazou
>
> * configure.ac (PLUGIN_LD): Rename into...
> (PLUGIN_LD_SUFFIX): ...this and strip the target_alias triplet.
> * config.in: Regenerate.
> * configure: Likewise.
> * collect2.
Committed to fix ICE during library build from r187199:
http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00255.html
Johann
Hi,
for this testcase:
int main()
{
auto a = []() { return true; };
auto b = []() { return a(); }; // { dg-error "'a' is not captured" }
int c, d;
while (b() && c < d)
{
}
}
we produce meaningless diagnostics for the while loop (stemming from b()
but the caret is also in the wrong place, a sep
On Mon, 7 May 2012, Olivier Hainque wrote:
> Joseph and David suggested to address this in a more general fashion,
> along lines proposed in
>
> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01667.html
>
> The attached patch is a first shot in this direction. Only lightly tested
> at this point
+Honza and Nathan.
David
On Thu, May 3, 2012 at 10:52 AM, Teresa Johnson wrote:
> This patch adds functionality to libgcov to enable user applications to
> collect profile data only in regions of interest. This is useful, for
> example, to collect profile data from a long-running server only
> d
On 05/07/2012 04:23 AM, Rainer Orth wrote:
2012-05-05 Rainer Orth
* Makefile.am (libatomic.map-sun): Handle objects in
libatomic_la_LIBADD.
* aclocal.m4: Regenerate.
* Makefile.in: Regenerate.
Ok.
r~
On 05/07/2012 04:14 AM, Rainer Orth wrote:
2012-05-04 Rainer Orth
* configure.ac: Add $XPCFLAGS to CFLAGS, not $XCFLAGS.
* configure: Regenerate.
Ok.
r~
On May 7, 2012, at 15:57 , Olivier Hainque wrote:
> My first attempt at building there failed, with
>
> --target=powerpc-eabispe --with-cpu=8548 --enable-languages=c
> --disable-libada
>
> (internal compiler error on unwind-dw2.c) This failure reproduces with
> an unpatched tree as well, so
On 05/07/2012 10:30 AM, Bernd Schmidt wrote:
On 05/03/2012 07:47 PM, Richard Sandiford wrote:
Richard Guenther writes:
On Sat, Apr 28, 2012 at 5:31 PM, Bernd
Schmidt wrote:
This patch allows us to recognize that even if the argument to
memcpy lives
across the call, we can allocate it to a ca
Hi,
On 06/11/2010 10:23 PM, Manuel López-Ibáñez wrote:
On 11 August 2009 02:01, Joseph S. Myers wrote:
On Tue, 11 Aug 2009, Manuel López-Ibáñez wrote:
Modified the patch to make use of the new c-c++-common testsuite.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK for trunk?
I s
On Mon, May 7, 2012 at 10:00 AM, Jakub Jelinek wrote:
>> > Shouldn't that be done only for generic tuning? If somebody uses
>> > -mtune=native, then emitting rep; bsf is overkill, the code is intended
>> > to be run on a CPU without (or with TARGET_BMI with) tzcnt insn support.
>>
>> Yes, this i
On 05/06/2012 04:06 PM, Fabien Chêne wrote:
+ if (late_enum_values)
+ VEC_safe_push (tree, gc, late_enum_values, decl);
I would think you could walk the TYPE_VALUES list directly, rather than
copy it into a temporary VEC.
Jason
On Mon, May 7, 2012 at 7:35 AM, Steven Bosscher wrote:
> Hello,
>
> This patch fixes PR53245.
> Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
>
> Ciao!
> Steven
>
>
> PR middle-end/53245
> * gimplify.c (preprocess_case_label_vec_for_gimple): If low or high
>
On Mon, May 7, 2012 at 4:35 PM, Steven Bosscher wrote:
> Hello,
>
> This patch fixes PR53245.
> Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ok.
Thanks,
Richard.
> Ciao!
> Steven
>
>
> PR middle-end/53245
> * gimplify.c (preprocess_case_label_vec_for_gimple):
Hello,
This patch fixes PR53245.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
PR middle-end/53245
* gimplify.c (preprocess_case_label_vec_for_gimple): If low or high
is folded to a type boundary value, verify that the resulting case
On 05/03/2012 07:47 PM, Richard Sandiford wrote:
Richard Guenther writes:
On Sat, Apr 28, 2012 at 5:31 PM, Bernd Schmidt wrote:
This patch allows us to recognize that even if the argument to memcpy lives
across the call, we can allocate it to a call-used register by reusing the
return value o
Hello,
This is a followup on a discussion we had a while ago, starting with
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01543.html
The original issue was the vxworks port unduly clobbering explicit
SPE related options on powerpc, which it still does. The proposed patch
at the time was to prev
On Mon, May 7, 2012 at 1:34 PM, Richard Guenther
wrote:
> On Mon, May 7, 2012 at 1:28 PM, Steven Bosscher wrote:
>> Hello,
>>
>> When I moved the first bits of the switch lowering code from stmt.c, I
>> didn't anticipate that the GIMPLE passes can sometimes perform
>> transformations that break t
Hi,
neverending story. Maybe this time something gets in :)
This patch changes generation of insn-attrtab.c to:
* order attributes topologically (so that the "inlining" genattrtab does
is as effective as possible, and doesn't hit the size limits too much)
* adjusts the rtx_cost for the attribu
Ian Lance Taylor wrote:
> It looks like you checked in a version of this patch to gcc-4_7-branch.
> However, the version you committed used "false" where it should have
> used "NULL", causing a bootstrap failure in stage 2 when not using building
> in release mode:
>
> ../../gccgo-gcc/gcc/tree-ve
We fail to add referenced vars when inline copies are instantiated
from clones created from IPA-CP. That later leads to ICEs in
remove-unused-locals because var_ann has not been allocated.
Bootstrapped and tested on x86_64-unknown-linux-gnu, LTO bootstrapped.
Applied to trunk and branch.
Richa
OK, thanks.
Jason
On Mon, May 7, 2012 at 2:30 PM, Jakub Jelinek wrote:
> Hi!
>
> If returning an addressable result by value, the C++ FE makes
> it returned by reference, RESULT_DECL in that case is DECL_BY_REFERENCE
> REFERENCE_TYPE. VRP shouldn't in that case assume the is
> VR_UNDEFINED, instead it only knows
Il 07/05/2012 14:09, Rainer Orth ha scritto:
> gcc.target/i386/builtin_target.c currently FAILs on Solaris/x86 (and
> also on on *86*-*-freebsd*, judging from testresults):
>
> FAIL: gcc.target/i386/builtin_target.c (test for excess errors)
> WARNING: gcc.target/i386/builtin_target.c compilation f
Hi!
If returning an addressable result by value, the C++ FE makes
it returned by reference, RESULT_DECL in that case is DECL_BY_REFERENCE
REFERENCE_TYPE. VRP shouldn't in that case assume the is
VR_UNDEFINED, instead it only knows that it is nonnull.
Bootstrapped/regtested on x86_64-linux and i
gcc.target/i386/builtin_target.c currently FAILs on Solaris/x86 (and
also on on *86*-*-freebsd*, judging from testresults):
FAIL: gcc.target/i386/builtin_target.c (test for excess errors)
WARNING: gcc.target/i386/builtin_target.c compilation failed to produce
executable
Excess errors:
Undefined
Steven Bosscher writes:
> Tested by building a cross to m68k-linux. OK for trunk?
Ok with a changelog.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Committed.
Richard.
2012-05-07 Richard Guenther
PR lto/42987
* g++.dg/lto/pr42987_0.C: New testcase.
* g++.dg/lto/pr42987_1.C: Likewise.
Index: gcc/testsuite/g++.dg/lto/pr42987_0.C
===
--- gcc/testsuite/
On 05/07/2012 01:32 PM, Richard Guenther wrote:
> On Sun, May 6, 2012 at 7:24 PM, Janne Blomqvist
> wrote:
>> On Sun, May 6, 2012 at 2:39 PM, Richard Guenther
>> wrote:
>>> On Sun, May 6, 2012 at 10:33 AM, Janne Blomqvist
>>> wrote:
Hi,
in http://gcc.gnu.org/install/prerequisites.
g++.dg/debug/dwarf2/nested-3.C currently FAILs on Solaris/x86 and
Darwin/x86 (scan-assembler), for two reasons:
* First of all, Solaris uses / instead of # as comment character. There
seem to be many others, but I cannot tell which of them are relevant
for this testcase.
* Even with this fix
On Mon, May 7, 2012 at 1:28 PM, Steven Bosscher wrote:
> Hello,
>
> When I moved the first bits of the switch lowering code from stmt.c, I
> didn't anticipate that the GIMPLE passes can sometimes perform
> transformations that break the rules the gimplifier uses while
> lowering SWITCH_EXPRs.
>
>
On Sun, May 6, 2012 at 7:24 PM, Janne Blomqvist
wrote:
> On Sun, May 6, 2012 at 2:39 PM, Richard Guenther
> wrote:
>> On Sun, May 6, 2012 at 10:33 AM, Janne Blomqvist
>> wrote:
>>> Hi,
>>>
>>> in http://gcc.gnu.org/install/prerequisites.html we say that GCC
>>> requires at least MPFR 2.4.2, but
Hello,
When I moved the first bits of the switch lowering code from stmt.c, I
didn't anticipate that the GIMPLE passes can sometimes perform
transformations that break the rules the gimplifier uses while
lowering SWITCH_EXPRs.
The attached patch adds the expected rules to the GIMPLE_SWITCH verifi
After the previous libatomic patch, many testcases fail on Solaris/x86
like this:
FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors)
Excess errors:
Undefined first referenced
symbol in file
__atomic_compare_exchange_1 /
Solaris 10 and 11/x86 bootstrap is currently broken configuring the
64-bit libatomic: configure aborts with
configure:3499: /var/gcc/regression/trunk/11-gcc/build/./gcc/xgcc
-B/var/gcc/regression/trunk/11-gcc/build/./gcc/
-B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/
-
Solaris bootstrap on mainline is currently broken with the native
linker: linking stage1 libgcc_s.so fails like this:
ld: fatal: unwind table: file _divdi3_s.o: section .eh_frame: bad cie version
0: offset 0x20
It turns out that ld cannot handle CIE version 3. The wrong error message
nonwithsta
Richard Sandiford writes:
> Olivier Hainque writes:
>> Hello Richard,
>>
>> Re $subject, at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01515.html
>>
>> You suggested:
Would be nice to use a single function that knows about the extra
contraints here. Maybe something like the attached?
On Mon, 7 May 2012, Eric Botcazou wrote:
> > > Sure, no opposition by me to applying the whole set of patches.
> >
> > Done now.
>
> This has introduced a couple of ACATS failures on x86:
>
> FAIL: c52102a
> FAIL: c52102c
>
> The problem is that a builtin_memmove is wrongly folded into an a
Hi Alessandro,
> my name is Alessandro, I'm a newbie of GCC and helped by Tobias Burnus
> and Paul Thomas I'll try to add support for final subroutines.
since Tobias already reviewed your patch, I just want to say: Welcome
to the team :)
We're certainly looking forward to your contributions! Hav
Hi,
> Nice call! Apart from s/wronly/wrongly/ in the testcase, this is
> certainly OK for trunk and, I would suggest, as far back as you have
> the intestinal fortitude to go. I suspect, without checking, that the
> patch might not do the right thing on 4.5.
agreed. Apart from the fact that the
Hello,
On 05/06/2012 09:37 PM, Alessandro Fanfarillo wrote:
The patch is bootstrapped and tested on x86_64-unknown-linux-gnu - gcc
version 4.8.0 20120506 (experimental)
2012-05-06 Alessandro Fanfarillo
Paul Thomas
Tobias Burnus
PR fortran/52158
*
> > Sure, no opposition by me to applying the whole set of patches.
>
> Done now.
This has introduced a couple of ACATS failures on x86:
FAIL: c52102a
FAIL: c52102c
The problem is that a builtin_memmove is wrongly folded into an assignment
between MEM_EXPRs, although source and destination
Hi Tobias,
Nice call! Apart from s/wronly/wrongly/ in the testcase, this is
certainly OK for trunk and, I would suggest, as far back as you have
the intestinal fortitude to go. I suspect, without checking, that the
patch might not do the right thing on 4.5.
Thanks for the patch for what you carr
On Mon, May 07, 2012 at 09:36:38AM +0200, Uros Bizjak wrote:
> On Mon, May 7, 2012 at 7:43 AM, Jakub Jelinek wrote:
>
> >> Index: i386.md
> >> ===
> >> --- i386.md (revision 187217)
> >> +++ i386.md (working copy)
> >> @@ -12112,
On Mon, May 7, 2012 at 7:43 AM, Jakub Jelinek wrote:
>> Index: i386.md
>> ===
>> --- i386.md (revision 187217)
>> +++ i386.md (working copy)
>> @@ -12112,9 +12112,22 @@
>> (set (match_operand:SWI48 0 "register_operand" "=r")
88 matches
Mail list logo
