2011/6/14 ���f任 :
> The patch correct statement about CFG. According to the comment on
> the function gimple_expand_cfg in gcc/cfgexpand.c, the tree CFG now
> is preserved and expanded to RTL representation.
>
> 2011-06-14 Wei-Ren Chen
>
> * gcc/doc/cfg.texi: Correct statement about CFG.
>
> Ind
On 14 June 2011 21:35, Janis Johnson wrote:
> These tests apparently require thumb2 support (I don't yet know much
> about ARM). OK for trunk, and later 4.6?
OK - The -march=armv7-a is redundant in these tests. You should be
able to lose them if arm_thumb2_ok returns true.
cheers
Ramana
On Jun 14 18:01, DJ Delorie wrote:
>
> > This is wrong as not all FSs are case insensitive. In fact HFS+ can
> > be case sensitive too. I think you need better check than just
> > saying all Darwin is case insensitive. This is just like using
> > FAT32 on Linux. In fact I think HAVE_DOS_BASED_
On Tue, 14 Jun 2011, Mike Stump wrote:
> On Jun 13, 2011, at 3:57 AM, Richard Guenther wrote:
> > That's not exactly an example - I can't think of how you want or need
> > to use VIEW_CONVERT_EXPRs to implement said divmod instruction or why
> > you would need anything special for the _argument_ o
On Tue, Jun 14, 2011 at 6:04 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> As I've noted in prior messages; I'm looking to improve our path
> isolation to improve code generation and reduce false positives from
> warnings.
>
> The patch that's been in my queue for som
Hi!
All of these _mm{,256}_permute2_p[sd] and _mm_roti_epi{8,16,32,64}
intrinsics ICE if the last argument is constant integer, but not in the
expected range.
I could only find MSFT documentation for these intrinsics, where for
*permute2* it says that the last argument must be 0, 1, 2 or 3,
for *
> Date: Wed, 15 Jun 2011 10:22:36 +0200
> From: Corinna Vinschen
>
> On Jun 14 18:01, DJ Delorie wrote:
> >
> > > This is wrong as not all FSs are case insensitive. In fact HFS+ can
> > > be case sensitive too. I think you need better check than just
> > > saying all Darwin is case insensitive
2011/6/15 Georg-Johann Lay :
> This is a patch that implements some libgcc functions in assembler.
> The functions are used only very seldom but if, they lead to an
> unpleasant waste of resource. For example, some SF functions
> eventually lead to __clz_tab being dragged in (PR29524).
>
> This pat
On Jun 15 11:58, Mark Kettenis wrote:
> > Date: Wed, 15 Jun 2011 10:22:36 +0200
> > From: Corinna Vinschen <...>
Please do not quote my email address in the body of your message.
Thank you.
> > IMHO it's actually a pity that the filename comparison behaves differently
> > on different systems. I
On Wed, 15 Jun 2011, Corinna Vinschen wrote:
> these functions be replaced with multibyte-aware versions? Along the
> same lines, the entire set of safe-ctype functions only work for ASCII
> and EBCDIC...
That's the whole point of safe-ctype: that code that is processing things
such as C source
On Wednesday 15 June 2011 11:44:19, Corinna Vinschen wrote:
> Indeed. Probably the case sensitivity should not be hardcoded in a
> low-level function at all. The application should decide if it wants
> case-sensitive or case-insensitive filename comparison. This way,
> the comparison could be ba
On Jun 15 10:45, Joseph S. Myers wrote:
> On Wed, 15 Jun 2011, Corinna Vinschen wrote:
>
> > these functions be replaced with multibyte-aware versions? Along the
> > same lines, the entire set of safe-ctype functions only work for ASCII
> > and EBCDIC...
>
> That's the whole point of safe-ctype:
On 6/15/2011 5:58 AM, Mark Kettenis wrote:
Over my dead body. On a proper operating system filenames are
case-sensitive. Your suggestion would create spurious matches.
Yes, we all know that Unix systems chose case sensitive, and
are happy to have files differing only by case in the same
dire
Denis Chertykov schrieb:
> 2011/6/15 Georg-Johann Lay :
>> This is a patch that implements some libgcc functions in assembler.
>> The functions are used only very seldom but if, they lead to an
>> unpleasant waste of resource. For example, some SF functions
>> eventually lead to __clz_tab being dra
We handle integer types with bitfield precision but not other
integral types which the middle-end considers equivalent. Noticed
while working on bitfield reference lowering where this causes
some miscompiles with boolean bitfields.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to
Hi,
this patch switch regular function-function aliases to the new representation.
I plan to followup with reorg of weakrefs and variable-variable aliases and then
remove the infrastructure for aliases. It is however better to do these step by
step so possible problems are easier to track.
Bootstr
Jan Hubicka writes:
> this patch switch regular function-function aliases to the new representation.
> I plan to followup with reorg of weakrefs and variable-variable aliases and
> then
> remove the infrastructure for aliases. It is however better to do these step
> by
> step so possible proble
On 10/06/11 00:43, Janis Johnson wrote:
> On 06/08/2011 03:17 AM, Joseph S. Myers wrote:
>> On Tue, 7 Jun 2011, Janis Johnson wrote:
>>
>>> These tests fail when multilib options use -mfpu= and override the
>>> -mfpu=neon-fp16 used for the test:
>>>
>>> g++.dg/ext/arm-fp16/arm-fp16-ops-5.C
>>
On 06/06/11 15:31, Andrew Stubbs wrote:
> On 06/06/11 15:26, Dmitry Plotnikov wrote:
>> On 06/06/2011 05:33 PM, Andrew Stubbs wrote:
>>> On 06/06/11 14:26, Dmitry Plotnikov wrote:
if (const_ok_for_arm (INTVAL (x))
- || const_ok_for_arm (~INTVAL (x)))
+ || const_ok_for_arm (~INTVAL (x
Since __dso_handle is always hidden if HAVE_GAS_HIDDEN is set, it is safe
to mark __dso_handle hidden if assembler supports it. OK for trunk?
Thanks.
H.J.
---
2011-06-15 H.J. Lu
PR c++/49412
* decl.c (get_dso_handle_node): Mark __dso_handle hidden if
assembler suppor
On 22/04/11 16:21, Chung-Lin Tang wrote:
> Hi Richard, this part's for you.
>
> The ARM backend changes needed are very little after the prior patches,
> basically just a case in arm_canonicalize_comparison() to detect
> (zero_extend:SI (subreg:QI (reg:SI ...) 0)), and swap it into (and:SI
> (reg:
Hi Johann,
I understand your reasoning, but I'm not particularly fond of this hack.
Surely there's a way to fix this correctly without relying on this hack...
Eric Weddington
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Wednesday, June 15, 2011 3:26 PM
>
Weddington, Eric schrieb:
> Hi Johann,
>
> I understand your reasoning, but I'm not particularly fond of this hack.
Yes, ACK. It's a hack to get rid of the PR.
> Surely there's a way to fix this correctly without relying on this hack...
Surely, gcc is man-made ;-) Someone will have to dive into
On 05/23/11 16:52, Nathan Sidwell wrote:
This patch fixes an interoperability issue with code generated by ARM's EABI
compiler.
ping?
--
Nathan Sidwell
Hi,
On Sat, 11 Jun 2011, H.J. Lu wrote:
> We are very inconsistent when saving and restoring non-local goto save
> area. See:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48016
>
> for detailed analysis. OK for trunk?
> + /* FIXME: update_nonlocal_goto_save_area may pass SA in the wrong
On Fri, 10 Jun 2011, Pierre Vittet wrote:
> I guess this is better now.
>
> Changelog (gcc/c-family):
>
> 2011-06-10 Pierre Vittet
>
> * c-pragma.h (pragma_handler_1arg, pragma_handler_2arg): New handler.
> (gen_pragma_handler): New union.
> (internal_pragma_handler): New type.
>
On Wed, Jun 15, 2011 at 7:11 AM, Michael Matz wrote:
> Hi,
>
> On Sat, 11 Jun 2011, H.J. Lu wrote:
>
>> We are very inconsistent when saving and restoring non-local goto save
>> area. See:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48016
>>
>> for detailed analysis. OK for trunk?
>> + /*
OK.
Jason
This patch removes treating (bool)x the same as x != 0 in
canonicalize_cond_expr_cond. That isn't true as the cast to
bool can be a truncation. With lowering bit-field refs
this exposes a miscompile of g++.dg/opt/nrv5.C.
When removing that canonicalization fold turns out to be
unhelpful exposin
>
> After it has been determined how to check for PIE support, I'm checking
> this in.
I haven't bisected it and not investigated failures in detail because
I'm about to walk out of the door. This patch might have broken
testing with arm-linux-gnueabi cross with defaults set to v7-a. (
configured
On Tue, Jun 14, 2011 at 5:47 PM, H.J. Lu wrote:
> On Tue, May 10, 2011 at 12:18 PM, Easwaran Raman wrote:
>> On Tue, May 3, 2011 at 9:40 AM, Easwaran Raman wrote:
>>> On Mon, May 2, 2011 at 8:37 PM, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/26/11 16
Hi,
PR 49343 showed that build_ref_for_model in tree-sra.c used a more
primitive technique to determine an offset of a field than
get_ref_base_and_extent, cannot crunch fields with "placeholders" in
their offsets and ICEs on them (while get_ref_base_and_extent
processed them fine before).
Fixed
On 06/15/2011 01:13 AM, Ramana Radhakrishnan wrote:
> On 14 June 2011 21:35, Janis Johnson wrote:
>> These tests apparently require thumb2 support (I don't yet know much
>> about ARM). OK for trunk, and later 4.6?
>
> OK - The -march=armv7-a is redundant in these tests. You should be
> able to l
On Wed, Jun 15, 2011 at 4:54 AM, Jakub Jelinek wrote:
> Hi!
>
> All of these _mm{,256}_permute2_p[sd] and _mm_roti_epi{8,16,32,64}
> intrinsics ICE if the last argument is constant integer, but not in the
> expected range.
>
> I could only find MSFT documentation for these intrinsics, where for
>
On Fri, 10 Jun 2011, Steve Ellcey wrote:
> I will check in this testsuite fix as obvious if there are no objections.
But... :)
> On IA64 and HPPA the test generates global declarations for the function
> as well as calls so the scan-assembler-times fails because it finds the
> declarations as we
On Jun 15, 2011, at 9:06 AM, Ramana Radhakrishnan wrote:
>> After it has been determined how to check for PIE support, I'm checking
>> this in.
>
> I haven't bisected it and not investigated failures in detail because
> I'm about to walk out of the door. This patch might have broken
> testing with
> testsuite/ChangeLog:
>
>* gcc.dg/vect/vect-16.c: Rename to ...
>* gcc.dg/vect/no-fast-math-vect16.c: ... this.
>* gcc.dg/vect/vect-peel-3.c: Adjust misalignment values
>for double-word vectors.
>* gcc.dg/vect/vect-peel-4.c: Likewise.
>* gcc.dg/vect
> Date: Wed, 15 Jun 2011 10:22:36 +0200
> From: Corinna Vinschen
> Cc: Andrew Pinski , brobec...@adacore.com,
> gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
>
> Talking about case-insensitive comparison, the filename_cmp and
> filename_ncmp functions don't work for multibyte codesets, onl
> Date: Wed, 15 Jun 2011 06:59:11 -0400
> From: Robert Dewar
> CC: vinsc...@redhat.com, d...@redhat.com, pins...@gmail.com,
> brobec...@adacore.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
>
> > or some piece of code in the toolchain arbitrarily changed the
> > case of a filename.
On 06/14/2011 02:29 PM, Georg-Johann Lay wrote:
> I tested on some handcrafted examples and on the code attached to
> PR46278. The generated code looked very good and so I started
> regression testing but found at spill fail in
> gcc.c-torture/compile/950612-1.c
I reproduced this today.
The Pro
On Jun 15, 2011, at 2:04 AM, Richard Guenther wrote:
> This VIEW_CONVERT_EXPR looks useless - in fact useless_type_conversion_p
> will tell you that, so you can omit it.
So, I tracked down who created it:
tree
convert_to_vector (tree type, tree expr)
{
switch (TREE_CODE (TREE_TYPE (expr)))
Hi,
After updating the patch, I now see a failure on c++0x forward enums.
Consider the below code:
template
struct S1
{
enum class E1;
enum class E1;
};
Currently, the second declaration of E1 relies on a successfull call
to supplement_binding_1.
With the patch I am working on, it no lo
Hi!
The following testcase is miscompiled e.g. on powerpc (not on x86_64/i686
due to different ivopts choices), because estimate_numbers_of_iterations
was called before assert_exprs are added to the IL and gets info cached
until adjust_range_with_scev, where using the original SSA_NAMEs leads
to p
On Jun 15 20:27, Eli Zaretskii wrote:
> > Date: Wed, 15 Jun 2011 10:22:36 +0200
> > From: Corinna Vinschen <...>
> > Talking about case-insensitive comparison, the filename_cmp and
> > filename_ncmp functions don't work for multibyte codesets, only for
> > singlebyte codesets. Given that UTF-8 is
Richard Henderson schrieb:
On 06/14/2011 02:29 PM, Georg-Johann Lay wrote:
I tested on some handcrafted examples and on the code attached to
PR46278. The generated code looked very good and so I started
regression testing but found at spill fail in
gcc.c-torture/compile/950612-1.c
I reproduc
>I have no problems on -mtune=Bulldozer. But I object -mtune=generic
>change and did suggest a different approach for -mtune=generic.
Something must have been broken for the unaligned load splitting in generic
mode.
While we lose 1.3% on CFP2006 in geomean by splitting unaligned loads for
-mtu
On 06/15/2011 01:40 PM, Georg-Johann Lay wrote:
> But I still wonder what's the very problem. Any architecture has
> limited reg+const addressing and limited number of address
> registers. I definetely saw architectures run out of registers and
> reload manages to access stack beyond reg+maxoff wit
> The patch isn't suitable as is. If -PIE requires -fPIC, then anything that
> adds it or tortures on it, should add both, or torture on both.
The ABS relocs that I mentioned were from testglue.o which isn't built
PIE or PIC and that's the reason for the failures to show up. Maybe
the right solu
> OK for mainline once regtest on arm-linux-gnueabi completes?
ok.
+ else
+{
+ if (mem_read_insn_p (to->insn))
+ return;
+ else
better do
else if (!mem_read_insn_p (to->insn))
+ create_ddg_dep_no_link (g, from, to, ANTI_DEP, MEM_DEP, 0);
+}
Ayal.
Revital Er
Ok for google/main.
David
On Tue, Jun 14, 2011 at 1:50 PM, Sharad Singhai (शरद सिंघई)
wrote:
> Sorry, Rietveld didn't send out the updated patch along with my mail.
> Here it is.
>
> Sharad
>
> 2011-06-14 Sharad Singhai
>
> Google Ref 3
>
> * doc/gcov.texi: Document gcov in
On 06/15/2011 02:58 PM, Richard Henderson wrote:
> Indeed, I can work around this particular crash by either
> hacking Z to be call-saved, or hacking the frame pointer to
> not be required. The former of course changes the abi, and
> the second produces awful code due to too many copies from
> the
On Tue, 7 Jun 2011, Andrew Haley wrote:
>> The vast majority of users does not need the former and the latter is
>> on the verge of becoming practically irrelevant. As one datapoint, the
>> entire FreeBSD Ports Collection has a single(!) port relying on GCJ.
> It's not quite as irrelevant as you t
A generic bug found in one of the less common targets. The MMIX
port usually saves the return-address from the special-register rJ to
a general call-saved register (helped by get_hard_reg_initial_val),
restored to rJ immediately on return from the call. I know, the
"restore immediately on return"
Hello,
> better do
> else if (!mem_read_insn_p (to->insn))
>
> + create_ddg_dep_no_link (g, from, to, ANTI_DEP, MEM_DEP, 0);
> + }
Done. Committed to -r175090.
Thanks,
Revital
Revital Eres wrote on 14/06/2011 09:27:32 AM:
> From: Revital Eres
> To: Ayal Zaks/Haifa/IBM@IBMIL
> Cc: gcc-patches@gcc.gnu.org, Patch Tracking
> Date: 14/06/2011 09:27 AM
> Subject: Re: [PATCH, SMS 1/4] Fix calculation of row_rest_count
>
> Hello,
>
> > Please add the following:
> > o A clari
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So as I've mentioned previously, I've been working on a relatively small
change to the jump threading code which would allow it to duplicate a
join block when doing so allows us to thread through a successor of the
join block. This is expected to b
* mh-darwin: Turn off -pie on darwin11 and later.
2011-06-15 Mike Stump
* mh-darwin: Turn off -pie on darwin11 and later.
Index: mh-darwin
===
--- mh-darwin (revision 174625)
+++ mh-darwin (working copy)
@@ -
Steve Ellcey wrote on 15/06/2011 08:15:27 PM:
>
> > testsuite/ChangeLog:
> >
> >* gcc.dg/vect/vect-16.c: Rename to ...
> >* gcc.dg/vect/no-fast-math-vect16.c: ... this.
> >* gcc.dg/vect/vect-peel-3.c: Adjust misalignment values
> >for double-word vectors.
> >
args (&temp), mode,
type, named) != 0)
Extra tab character before !=.
Actually, it was a missing carriage return.
46500-patch-20110615.gz
Description: GNU Zip compressed data
Hello,
>>> * ddg.c (add_intra_loop_mem_dep): New function.
>
> You could check first thing if (from->cuid == to->cuid), for code clarity.
Attached is the new version of the patch which addresses this.
The patch was re-tested as follows:
On ppc64-redhat-linux regtest as well as bootstrap
On 06/15/2011 05:53 AM, Richard Earnshaw wrote:
> On 10/06/11 00:43, Janis Johnson wrote:
>> On 06/08/2011 03:17 AM, Joseph S. Myers wrote:
>>> On Tue, 7 Jun 2011, Janis Johnson wrote:
>>>
These tests fail when multilib options use -mfpu= and override the
-mfpu=neon-fp16 used for the
PR34734 is an annoying, false C++ warning for code like
const int x __attribute__((progmem)) = 1;
progmem.c:1:30: warning: only initialized variables can be placed into
program memory area [enabled by default]
The problem is that DECL_INITIAL is NULL at the specific point in
space and time (avr_
This patch adds ISO_Fortran_Env's LOCK_TYPE, tons of constraint checks
and a simple implementation for -fcoarray=single.
With the implementation of LOCK_TYPE and (UN)LOCK, gfortran can now
parse all coarrays constructs of Fortran 2008. (However, there are still
known deficits and bugs in the r
On Wed, Jun 15, 2011 at 8:16 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 15 Jun 2011, H.J. Lu wrote:
>
>> >> + /* FIXME: update_nonlocal_goto_save_area may pass SA in the wrong
>> >> mode. */
>> >> + if (GET_MODE (sa) != mode)
>> >> + {
>> >> + gcc_assert (ptr_mode != Pmode
>> >> +
Hi,
Consider the following example.
extern unsigned int foo (int*) __attribute__((pure));
unsigned int
tr (int array[], int n)
{
unsigned int i;
unsigned int sum = 0;
for (i = 0; i < n; i++)
sum += foo (&array[i]);
return sum;
}
For 32-bit pointers, the analysis in infer_loop_bounds_
[Resent as original appears to got lost in the net]
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01141.html
This is a patch that implements some libgcc functions in assembler.
The functions are used only very seldom but if, they lead to an
unpleasant waste of resource. For example, some SF functi
On 06/16/2011 08:39 AM, Tom de Vries wrote:
> I will sent the adapted test cases in a separate email.
Update 2 test cases to be more strict, and more like the original example.
Thanks,
- Tom
2011-06-15 Tom de Vries
PR target/45098
* gcc.target/arm/ivopts-3.c: Update test.
This is a patch that implements some libgcc functions in assembler.
The functions are used only very seldom but if, they lead to an
unpleasant waste of resource. For example, some SF functions
eventually lead to __clz_tab being dragged in (PR29524).
This patch avoids that by straight forward assem
Sorry, clearly the test case was missing a dg-error directive. Here's
the corrected version.
Cheers,
Janus
2011/6/15 Janus Weil :
> Hi all,
>
> here is the fix for an OOP-regression reported today by Andrew Benson
> (http://gcc.gnu.org/ml/fortran/2011-06/msg00119.html).
>
> It is fixed by chec
Hi all,
here is the fix for an OOP-regression reported today by Andrew Benson
(http://gcc.gnu.org/ml/fortran/2011-06/msg00119.html).
It is fixed by checking the 'class_ok' attribute, which determines
whether the CLASS declaration was ok. We also need to set this
attribute for components read from
Hi,
For
unsigned char in[N];
int out[N];
for (i = 0; i < N; i++)
out[i] = in[i] * 300;
in[i] is first promoted to int and then multiplied by 300. This
over-promotion prevents the vectorizer from using the widen-mult
pattern here.
This patch checks if a constant fits an intermediate type (sh
71 matches
Mail list logo
