On 22/03/2013 08:44, Kai Tietz wrote:
> 2013-03-22 Kai Tietz
>
> * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
> (__deregister_frame_info): Likewise.
Hi Kai,
I read your explanation of the problem relating to x86-64 memory models over
on the Cygwin de
On Mon, Apr 8, 2013 at 5:48 PM, Richard Biener
wrote:
>Can you trigger this message to show up with -Winline before/after the patch?
>Can you please add a testcase then?
Thanks Richard for reviewing, from my point of view about gcc and my invoking
of gcc, -Winline
only works on callees that be d
On 04/08/2013 07:54 PM, Jeff Law wrote:
This incorporates the concrete suggestions from Steven & Richi -- it
doesn't do any refactoring of the VRP code. There's still stuff I'm
looking at that might directly lead to some refactoring. In the mean
time I'm submitting the obvious small improvemen
One major suboptimal area of the sparc back end is cstore generation
on 64-bit.
Due to the way arguments and return values of functions must be
promoted, the ideal mode for cstore's result would be DImode.
But this hasn't been done because of a fundamental limitation
of the cstore patterns. The
This incorporates the concrete suggestions from Steven & Richi -- it
doesn't do any refactoring of the VRP code. There's still stuff I'm
looking at that might directly lead to some refactoring. In the mean
time I'm submitting the obvious small improvements.
Bootstrapped and regression test
Hi, sorry it has taken me so long to get back to this. Hopefully we can
wrap it up quickly now that we're back in stage 1.
On 02/25/2013 02:24 PM, Caroline Tice wrote:
-CXX_FOR_TARGET='$$r/$(HOST_SUBDIR)/gcc/xg++ -B$$r/$(HOST_SUBDIR)/gcc/
-nostdinc++ `if test -f $$r/$(TARGET_SUBDIR)
/libs
On 4/8/2013 7:46 PM, Kenneth Zadeck wrote:
On 04/08/2013 06:45 PM, Robert Dewar wrote:
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in som
On 04/08/2013 06:45 PM, Robert Dewar wrote:
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in some cases, since the
language standard specifi
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in some cases, since the
language standard specifically encourages this approach.
gcc lacks an
Revised copyright info.
-Rong
2013-04-08 Rong Xu
* contrib/profile_merge.py: An offline profile merge tool.
Index: contrib/profile_merge.py
===
--- contrib/profile_merge.py(revision 0)
+++ contrib/profile_merge.py
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
> That may be so in C, in Ada it would be perfectly reasonable to use
> infinite precision for intermediate results in some cases, since the
> language standard specifically encourages this approach.
gcc lacks an infinite precision plus operator?!
The copyright header is wrong. Please use the standard one for GCC.
David
On Mon, Apr 8, 2013 at 2:57 PM, Rong Xu wrote:
> Hi,
>
> This is a offline profile merge program.
>
> Usage: profile_merge.py [options] arg1 arg2 ...
>
> Options:
> -h, --helpshow this help message and exit
>
Hi,
This is a offline profile merge program.
Usage: profile_merge.py [options] arg1 arg2 ...
Options:
-h, --helpshow this help message and exit
-w MULTIPLIERS, --multipliers=MULTIPLIERS
Comma separated list of multipliers to be applied for
On 4/8/2013 5:46 PM, Kenneth Zadeck wrote:
In some sense you have to think in terms of three worlds:
1) what you call "compile-time static expressions" is one world which in
gcc is almost always done by the front ends.
2) the second world is what the optimizers can do. This is not
compile-time
In some sense you have to think in terms of three worlds:
1) what you call "compile-time static expressions" is one world which in
gcc is almost always done by the front ends.
2) the second world is what the optimizers can do. This is not
compile-time static expressions because that is what th
Ping?
On 3/31/13, Lawrence Crowl wrote:
> On 3/28/13, Richard Biener wrote:
>> On Mar 27, 2013 Lawrence Crowl wrote:
>> > On 3/27/13, Richard Biener wrote:
>> > > On Mar 23, 2013 Lawrence Crowl wrote:
>> > > > This patch is a consolodation of the hash_table patches to
>> > > > the cxx-convers
On 4/8/2013 5:12 PM, Lawrence Crowl wrote:
(BTW, you *really* don't need to quote entire messages, I find
it rather redundant for the entire thread to be in every message,
we all have thread following mail readers!)
Correct me if I'm wrong, but the Ada standard doesn't require any
particular ma
On 4/8/13, Robert Dewar wrote:
> On 4/8/2013 10:26 AM, Kenneth Zadeck wrote:
> > On 04/08/2013 10:12 AM, Robert Dewar wrote:
> > > On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
> > > > yes but the relevant question for the not officially
> > > > static integer constants is "in what precision are thos
On 4/8/13, Richard Biener wrote:
> I advocate the infinite precision signed representation as one
> solution to avoid the issues that come up with your implementation
> (as I currently have access to) which has a representation
> with N bits of precision encoded with M <= N bits and no sign
> info
> "Jonathan" == Jonathan Wakely writes:
Jonathan> On 2 April 2013 16:39, Marc Glisse wrote:
>> On Tue, 2 Apr 2013, Jonathan Wakely wrote:
>>> Should we update the prerequisites documentation to say that if
>>> Systemtap is installed it needs to be at least version X?
>>
>>
>> I thought you
On Sun, 7 Apr 2013, Marc Glisse wrote:
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_slli_epi16 (__m128i __A, int __B)
{
- return (__m128i)__builtin_ia32_psllwi128 ((__v8hi)__A, __B);
+ return (__m128i) ((__v8hi)__A << __B);
}
Actually, I
On 4/8/13, Kenneth Zadeck wrote:
> The other problem, which i invite you to use the full power of
> your c++ sorcery on, is the one where defining an operator so
> that wide-int + unsigned hwi is either rejected or properly
> zero extended. If you can do this, I will go along with
> your suggesti
Hi,
this patch makes change_decl_assembler_name to do the right thing with inline
clones. My original plan was to remove inline clones from assembler_name_hash,
but it hits the problem that we currently need to make them unique for purposes
of LTO sreaming.
It is not hard to walk the clone tree a
Hi,
this patch adds a new symbol flag UNIQUE_NAME. Its purpose is to disable
renaming at LTO time when the symbol is already known to be unique in the whole
resulting DSO. This happens for symbols that was previously global and we know
from LTO plugin resolution data that they are not bound by non
Remnants of the RTL inliner... Committed as obvious.
* reg-notes.def (REG_EH_CONTEXT): Remove unused note.
--- trunk/gcc/reg-notes.def 2013/04/08 19:36:43 197610
+++ trunk/gcc/reg-notes.def 2013/04/08 19:59:57 197611
@@ -172,11 +172,6 @@
the rest of the compiler as a C
On Mon, Apr 8, 2013 at 11:30 AM, Richard Biener wrote:
> On Sun, Apr 7, 2013 at 12:04 AM, Steven Bosscher wrote:
>> Hello,
>>
>> The existing documentation for SEQUENCE still states it is used for
>> DEFINE_EXPAND sequences. I think I wasn't even hacking GCC when that
>> practice was abandoned, and
Hi,
currently lto-symtab is trying to resolve all duplicated declarations,
including static variables where such duplicates should not happen.
This conflicts with the plan to solve PR54095 by postponning renaming to
the partitioning. This patch adds lto_symtab_symbol_p that disable merging
on stat
Hello,
On Mon, 8 Apr 2013, Laurent Alfonsi wrote:
I have identified a big performance regression between 4.6 and 4.7. (I have
enclosed a pathological test).
After investigation, it is because of the += statement applied on 2 signed
chars.
- It is now type-promoted to "int" when it is writte
Hello world,
I committed the attached patch as obvious to fix the regression
with array constructors on trunk, after regression-testing.
Will commit to 4.8 next.
Thomas
2013-04-08 Thomas Koenig
PR fortran/56782
* frontend-passes.c (callback_reduction): Dont't do
Hi,
I have just merge upstream gcc-4_8-branch into linaro/gcc-4_8-branch, up to
r197294. (The merge is r197598.)
I have also backported the following trunk revisions into the
linaro/gcc-4_8-branch: 196856, 196858, 196876, 197046, 197051, 197052,
197153, 197207, 197341, 197342, and 197346. (
Hi!
lhs ={v} {CLOBBER};
stmts right now allow only VAR_DECL or MEM_REF lhs, but the forwprop code
below on the attached testcase attempts to propagate an ARRAY_REF (of
MEM_REF) into it. Fixed by not propagating in that case, allowing arbitrary
memory lhs is IMHO unnecessary and such lhs's wouldn'
Hello,
I have identified a big performance regression between 4.6 and 4.7. (I
have enclosed a pathological test).
After investigation, it is because of the += statement applied on 2
signed chars.
- It is now type-promoted to "int" when it is written "result +=
foo()".(since 4.7)
On Mon, Apr 08, 2013 at 07:54:18PM +0200, Manuel López-Ibáñez wrote:
> > can be right now a single call, while you would need several. Also, if you
> > eventually want to colorize something in say error_at, warning_at and
> > similar format strings. For those you really don't have the printer at
On 8 April 2013 16:43, Jakub Jelinek wrote:
> On Mon, Apr 08, 2013 at 04:29:02PM +0200, Manuel López-Ibáñez wrote:
>> In fact, I would be fine with something like:
>>
>> pp_start_color()
>> pp_stop_color()
>> pp_wrap_in_color("")
>>
>> It is a bit more verbose, but also clearer when reading the co
OK.
Jason
Ping.
Thanks, Teresa
On Sun, Mar 31, 2013 at 9:39 AM, Teresa Johnson wrote:
> On Sun, Mar 31, 2013 at 1:36 AM, Andrew Pinski wrote:
>> On Sun, Mar 31, 2013 at 12:10 AM, Teresa Johnson
>> wrote:
>>> This patch allows the unused attribute to be used without warning
>>> on C++ class members, whic
Hi,
this patch fixes an obvious typo in recently applied patch.
ChangeLog
2013-04-08 Kai Tietz
* config/i386/cygwin.h (EXTRA_OS_CPP_BUILTINS): Replaced
TARGET_CYGWIN64 by TARGET_64BIT.
Applied to trunk as obvious fix. as revision 197593.
Regards,
Kai
Index: cygwin.h
==
This is basically the same patch as attached to the PR, except that I
have changed the goto-loop into a do-while loop with a new comment;
this caused the need for a lot of reformatting.
bootstrapped & regtested on i686-pc-linux-gnu.
2013-04-08 Joern Rennecke
* tree-ssa-math-opts.c (mu
On 04/08/13 08:59, Iyer, Balaji V wrote:
Hi Aldy,
Here are the things I found with the patch. All my comments have
"BVI:" in front of them.
BTW, it would be nice if you could use standard mailer quotation when
responding (">", etc).
- return;
BVI: I am OK with removing this retu
On Mon, Apr 08, 2013 at 04:29:02PM +0200, Manuel López-Ibáñez wrote:
> In fact, I would be fine with something like:
>
> pp_start_color()
> pp_stop_color()
> pp_wrap_in_color("")
>
> It is a bit more verbose, but also clearer when reading the code. And
> no need for %[colorname] or %r or -Wformat
... I think that by the time we do the check, if old_decl is a
FUNCTION_DECL we can safely assume that new_decl is also a
FUNCTION_DECL, thus I can simplify the code. I'm finishing testing the
below variant.
Thanks
Paolo.
///
Index: cp/decl.c
==
Dear all,
attached is an updated version of the patch, which address the raised
issues and some minor problems and omissions I found.
OK for the trunk?
Tobias
2013-04-08 Tobias Burnus
* gfortran.texi (KIND Type Parameters,
Internal representation of LOGICAL variables): Add crossrefs.
(
On 4/8/2013 10:26 AM, Kenneth Zadeck wrote:
My confusion is what you mean by "we"? Do you mean "we" the writer of
the program, "we" the person invoking the compiler by the use command
line options or "we", your company's implementation of ada?
Sorry, bad usage, The gcc implementation of Ada
On Mon, Apr 8, 2013 at 2:43 PM, Kenneth Zadeck wrote:
>
> On 04/08/2013 06:46 AM, Richard Biener wrote:
>>
>> On Sun, Apr 7, 2013 at 7:16 PM, Kenneth Zadeck
>> wrote:
>>>
>>> Richard,
>>>
>>> You advocate that I should be using an infinite precision
>>> representation and I advocate a finite prec
On 8 April 2013 15:23, Jakub Jelinek wrote:
> On Fri, Apr 05, 2013 at 11:51:43PM +0200, Manuel López-Ibáñez wrote:
>> In this patch the default is "never", because for some reason "auto"
>> triggers colorization during regression testing. I have not found a
>
> That reason is obvious, dejagnu (exp
On 04/08/2013 10:12 AM, Robert Dewar wrote:
On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
yes but the relevant question for the not officially static integer
constants is "in what precision are those operations to be performed
in?I assume that you choose gcc types for these operations and you
On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
yes but the relevant question for the not officially static integer
constants is "in what precision are those operations to be performed
in?I assume that you choose gcc types for these operations and you
expect the math to be done within that type,
On Mon, Apr 8, 2013 at 3:27 PM, Jeff Law wrote:
> On 04/08/2013 03:45 AM, Richard Biener wrote:
>
>>> @@ -8584,6 +8584,43 @@ simplify_cond_using_ranges (gimple stmt)
>>> }
>>> }
>>>
>>> + /* If we have a comparison of a SSA_NAME boolean against
>>> + a constant (which obviously
On 04/08/2013 09:52 AM, Robert Dewar wrote:
On 4/8/2013 9:23 AM, Kenneth Zadeck wrote:
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
Hello Joseph,
Did you get a chance to look at this patch?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Friday, March 29, 2013 5:58 PM
> To: 'Joseph Myers'; 'Aldy Hernandez'
> Cc: 'gcc-patches'
> Subject: RE: [patch] cilkplus: Array notation for C pa
On 4/8/2013 9:23 AM, Kenneth Zadeck wrote:
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer)
Richard Biener writes:
> On Mon, Apr 8, 2013 at 3:05 PM, Andreas Schwab wrote:
>> Richard Biener writes:
>>
>>> when a "real prototype" was visible
>>
>> How is that different from a prototype?
>
> It's different from the case where a K&R definition was seen and thus
> type information is prese
On 4/8/2013 9:24 AM, Kenneth Zadeck wrote:
So then how does a language like ada work in gcc? My assumption is
that most of what you describe here is done in the front end and by the
time you get to the middle end of the compiler, you have chosen types
for which you are comfortable to have any
On 04/06/2013 09:15 PM, Bin Cheng wrote:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
Behalf Of Bin Cheng
Sent: Tuesday, March 26, 2013 4:33 PM
To: 'Joern Rennecke'
Cc: gcc-patches@gcc.gnu.org; 'Jeff Law'
Subject: RE: [PATCH GCC]Rel
On 04/08/2013 03:45 AM, Richard Biener wrote:
@@ -8584,6 +8584,43 @@ simplify_cond_using_ranges (gimple stmt)
}
}
+ /* If we have a comparison of a SSA_NAME boolean against
+ a constant (which obviously must be [0..1]). See if the
+ SSA_NAME was set by a type conversion
On 04/08/2013 09:03 AM, Robert Dewar wrote:
It may be interesting to look at what we have done in
Ada with regard to overflow in intermediate expressions.
Briefly we allow specification of three modes
all intermediate arithmetic is done in the base type,
with overflow signalled if an intermediat
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer).
What do you mean when you say "constant a
On Fri, Apr 05, 2013 at 11:51:43PM +0200, Manuel López-Ibáñez wrote:
> In this patch the default is "never", because for some reason "auto"
> triggers colorization during regression testing. I have not found a
That reason is obvious, dejagnu (expect?) creates pseudo terminals, so
isatty is true, w
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer).
On 04/08/2013 04:56 AM, Florian Weimer wrote:
On 04/07/2013 07:16 PM, Kenneth Zadeck wrote:
The poster child for operations that do not belong to a ring is
division.
For my example, I am using 4 bit integers because it makes the
examples easy, but similar examples exist for any fixed precision.
On Mon, Apr 8, 2013 at 3:05 PM, Andreas Schwab wrote:
> Richard Biener writes:
>
>> when a "real prototype" was visible
>
> How is that different from a prototype?
It's different from the case where a K&R definition was seen and thus
type information is present via that mechanism. We don't want
Richard Biener writes:
> when a "real prototype" was visible
How is that different from a prototype?
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."
It may be interesting to look at what we have done in
Ada with regard to overflow in intermediate expressions.
Briefly we allow specification of three modes
all intermediate arithmetic is done in the base type,
with overflow signalled if an intermediate value is
outside this range.
all intermedi
Hi all,
When compiling:
unsigned long long
muld (unsigned long long X, unsigned long long Y)
{
unsigned long long mask = 0xull;
return (X & mask) * (Y & mask);
}
we get a suboptimal sequence:
stmfd sp!, {r4, r5}
mvn r4, #0
mov r5, #0
and
On 04/08/2013 06:46 AM, Richard Biener wrote:
On Sun, Apr 7, 2013 at 7:16 PM, Kenneth Zadeck wrote:
Richard,
You advocate that I should be using an infinite precision
representation and I advocate a finite precision representation where
the precision is taken from the context. I would like t
The following avoids the excessive verboseness of get_vectype_*
and leaves better traces of the original stmt in the vectorizer
temporary names by preserving their SSA name version.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-04-08 Richard Biener
* gi
ChangeLog
2013-04-02 Xinyu Qi
PR target/54338
* config/arm/arm.h (REG_CLASS_CONTENTS): Include IWMMXT_GR_REGS in
ALL_REGS.
Thanks,
Xinyu
Thanks now applied to trunk.
For the future please consider creating patches at the top level
directory. Makes it easier for applic
While the Solaris linker doesn't support the --as-needed/--no-as-needed
options (yet), it long has provided the equivalent -z ignore/-z record
options. This patch makes use of them, avoiding unnecessary
dependencies on libgcc_s.so.1.
Bootstrapped without regressions on i386-pc-solaris2.11 (and ch
This patch prevents two Invalid read of size 8 and one
Invalid write of size 8 warnings when cc1 is run under valgrind. What
happens here is that we firstly allocate 0B
ebb_data.path = XNEWVEC (struct branch_path,
PARAM_VALUE (PARAM_MAX_CSE_PATH_LENGTH));
(in fact, X
As Georg-Johann Lay wrote:
> Joerg Wunsch wrote:
> >The attached patch adds the new ATmega*RFR* devices to AVR-GCC.
> >[...]
>
> Supply the auto generated files, too. Cf. t-avr, avr-mcus.def etc.
OK, thanks for the reminder. Here is the updated patch.
--
Joerg Wunsch * Development engineer,
Hi,
seems an easy issue: we aren't allowing an explicit specializations
differing from the template declaration with respect to the constexpr
specifier.
Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2013-04-08 Paolo Carlini
PR c++/56871
* decl.c (validat
On Sun, Apr 7, 2013 at 7:16 PM, Kenneth Zadeck wrote:
> Richard,
>
> You advocate that I should be using an infinite precision
> representation and I advocate a finite precision representation where
> the precision is taken from the context. I would like to make the
> case for my position here, i
On Fri, Apr 5, 2013 at 2:34 PM, Kenneth Zadeck wrote:
> Richard,
>
> There has been something that has bothered me about you proposal for the
> storage manager and i think i can now characterize that problem. Say i want
> to compute the expression
>
> (a + b) / c
>
> converting from tree values,
Le 08/04/2013 10:34, Tobias Burnus a écrit :
> Janne Blomqvist wrote:
>> On Thu, Mar 21, 2013 at 11:31 PM, Janne Blomqvist
>> wrote:
>>> Updated patch which in addition does the above transformations as
>>> well.
>> .. and here is the actual patch (thanks Bernhard!)
> http://gcc.gnu.org/ml/fortran
Ping.
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00163.html
Regards
Senthil
On Wed, Apr 03, 2013 at 07:18:20PM +0530, Senthil Kumar Selvaraj wrote:
> This patch detects and emits an error if the value provided in _Alignas
> is negative. The fix was approved pending full regression testing in a
On Mon, Apr 8, 2013 at 4:47 AM, Zhouyi Zhou wrote:
> When inline failed because of callee is overwritable, gcc will not report it
> in dump file (triggered by -fdump-tree-einline) as other not inlinable cases
> do. This patch correct this.
>
> Regtested/bootstrapped on x86_64-linux.
Can you trigg
On Sat, Apr 6, 2013 at 2:48 PM, Jeff Law wrote:
>
> Given something like this:
>
> :
> _23 = changed_17 ^ 1;
> _12 = (_Bool) _23;
> if (_12 != 0)
> goto ;
> else
> goto ;
>
> Assume _23 and changed_17 have integer types wider than a boolean, but VRP
> has determined they have a ra
On Sun, Apr 7, 2013 at 12:04 AM, Steven Bosscher wrote:
> Hello,
>
> The existing documentation for SEQUENCE still states it is used for
> DEFINE_EXPAND sequences. I think I wasn't even hacking GCC when that
> practice was abandoned, and in the mean time some other uses of
> SEQUENCE have appeared
On Sat, Apr 6, 2013 at 11:50 PM, Andreas Schwab wrote:
> Tobias Burnus writes:
>
>> gcc.dg/Wunprototyped-calls.c:13:3: warning: call to function ‘g’ without a
>> real prototype [-Wunprototyped-calls]
>
> What is a real prototype?
One reason I didn't bother to upstream that patch is language lawy
Hello!
2013-04-08 Uros Bizjak
* config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Update.
Tested on alphaev68-pc-linux-gnu.
OK for mainline SVN?
Uros.
Index: config/abi/post/alpha-linux-gnu/baseline_symbols.txt
===
---
On Sat, Apr 6, 2013 at 1:13 PM, Jeff Law wrote:
>
>
> The tree combiner/forward propagator is missing opportunities to collapse
> sequences like this:
>
> _15 = _12 ^ _14;
> if (_15 != 0)
>
>
> Into:
>
> if (_12 != _14)
>
> The tree combiner/forward propagator builds this tree:
>
> x ^ y
>
I haven't even applied it.
Kai
On Fri, Apr 5, 2013 at 9:30 PM, Jeff Law wrote:
> On 04/05/2013 02:29 AM, Kai Tietz wrote:
>>
>> Hello,
>>
>> while debugging I made the finding that in find_func_aliases rhsop
>> might be used as NULL for gimple_assign_single_p items. It should be
>> using for the gimple_assign_single_p instead
On 04/07/2013 07:16 PM, Kenneth Zadeck wrote:
The poster child for operations that do not belong to a ring is division.
For my example, I am using 4 bit integers because it makes the
examples easy, but similar examples exist for any fixed precision.
Consider 8 * 10 / 4
in an infinite precision
On Fri, Apr 5, 2013 at 4:18 PM, Teresa Johnson wrote:
> On Thu, Mar 28, 2013 at 2:27 AM, Richard Biener
> wrote:
>> On Wed, Mar 27, 2013 at 6:22 PM, Teresa Johnson wrote:
>>> I found that the node weight updates on cloned nodes during ipa-cp were
>>> leading to incorrect/insane weights. Both the
On Thu, 4 Apr 2013, Jakub Jelinek wrote:
> Hi!
>
> The vt3.C testcase (from PR34949) ICEd, because sink_clobbers sunk a
> MEM_REF[SSA_NAME] clobber from a landing pad which that SSA_NAME definition
> dominated to an outer one which wasn't dominated by the definition.
> As the ehcleanup nor ehdisp
On Mon, 8 Apr 2013, Jakub Jelinek wrote:
> Hi!
>
> I was curious whether we don't miscompile the following testcase on 4.8
> branch (-1+0i matches integer_all_onesp), but apparently we don't, because
> TYPE_PRECISION on the COMPLEX_TYPE is 0. Anyway, I'd like to check this
> into trunk/4.8 branc
To require vect_double.
Committed.
Richard.
2013-04-08 Richard Biener
* gfortran.dg/vect/fast-math-pr37021.f90: Adjust.
Index: gcc/testsuite/gfortran.dg/vect/fast-math-pr37021.f90
===
--- gcc/testsuite/gfortran.dg/vect
On Sat, 6 Apr 2013, John David Anglin wrote:
> The patch fixes PR other/55274 and we now generate a non empty map file. As
> noted
> in the PR, this problem causes a hang when bootstrap is done using HP cat.
>
> Tested on hppa64-hp-hpux11.11 and hppa2.0w-hp-hpux11.11. Committed to trunk
> and 4
This adjusts g++.dg/vect/slp-pr56812.cc for targets that cannot
handle HW misaligned vector loads.
Tested on x86_64-unknown-linux-gnu, confirmed by Andreas that it
helps ia64 / powerpc.
Richard.
2013-04-08 Richard Biener
* g++.dg/vect/slp-pr56812.cc: Adjust.
Index: gcc/testsuite/g+
Janne Blomqvist wrote:
On Thu, Mar 21, 2013 at 11:31 PM, Janne Blomqvist
wrote:
Updated patch which in addition does the above transformations as
well.
.. and here is the actual patch (thanks Bernhard!)
http://gcc.gnu.org/ml/fortran/2013-03/msg00108.html
Thanks for the update and sorry for t
Hi!
I was curious whether we don't miscompile the following testcase on 4.8
branch (-1+0i matches integer_all_onesp), but apparently we don't, because
TYPE_PRECISION on the COMPLEX_TYPE is 0. Anyway, I'd like to check this
into trunk/4.8 branch, ok?
2013-04-08 Jakub Jelinek
* gcc.c-t
Hi,
I've committed the attached patch fixing the following testsuite fails
on s390 (-march=z196):
< FAIL: gcc.dg/pr48335-2.c (internal compiler error)
< FAIL: gcc.dg/pr48335-2.c (test for excess errors)
< FAIL: gcc.dg/pr48335-3.c (internal compiler error)
< FAIL: gcc.dg/pr48335-3.c (test for exce
PING (now in plain text mode so that the lists will accept the
message, hopefully. $#%& gmail "improvements".)
On Fri, Mar 22, 2013 at 8:58 AM, Janne Blomqvist
wrote:
>
> On Thu, Mar 21, 2013 at 11:31 PM, Janne Blomqvist
> wrote:
> > Updated patch which in addition does the above transformation
94 matches
Mail list logo
