Ok for inclusion in google/gcc-4_6.
Ollie
On Fri, Jul 22, 2011 at 5:46 PM, Jeffrey Yasskin wrote:
>
> For the google/gcc-4_6 branch _only_. I'll fix the inconsistency in
> debug locations later for trunk and google/main.
>
> In some translation units the debug location of make_heap is the
> loca
> I built an arm kernel with it, the USB stuff works.
I take that back - booted the wrong kernel. Didn't work, but I'll
confirm that I'm building with a patched gcc (too many kernels and
compilers to keep track of ;)
> I'm testing the following.
>
> Richard.
>
> 2011-07-22 Richard Guenther
>
> PR tree-optimization/45819
> * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Properly
> preserve volatile and notrap flags.
>
> * gcc.dg/pr45819.c: New testcase.
I built an
Add constexpr markup to move/forward, and enable more std::pair
constructors.
tested x86/linux
-benjamin2011-07-22 Benjamin Kosnik
Daniel Krugler
* include/bits/move.h (move, forward): Mark constexpr.
* include/bits/stl_pair.h (pair): Mark move ctors constexpr.
* testsuite/20_util
On 7/22/11, Gabriel Charette wrote:
> The recent implementation of comparing expected diff checksum had a problem:
> different configs generate different assembly (and although the diff itself
> was still the same in both case, the actual differences were on different
> lines; thus the checksum of
On 07/22/2011 01:57 PM, Richard Henderson wrote:
> On 07/22/2011 01:33 PM, Paolo Bonzini wrote:
>> On Fri, Jul 22, 2011 at 02:09, Richard Henderson wrote:
>>> I should mention here that I suspect the Cleanest solution is
>>> to make DF_DEFER_INSN_RESCAN imply that we also shouldn't grab
>>> data f
Well, technically it's not "broken" yet. It will be as soon as it starts
touching DF data, since this pass runs before pass_df_initialize_no_opt.
But the only real consumer of BB_PARTITION is pass_reorder_blocks. And
that pass is already gated to only run if optimization is enabled. So
really t
I re-tested my dwarf2 cfi propagation pass today, with the
partitioning vs eh edge splitting fix included. Only this
time I tested languages=all,ada,go instead of just =c,c++.
Lo and behold I find another latent problem, this time via
a Fortran test case.
The dwarf2 cfg pass is set to abort for
The recent implementation of comparing expected diff checksum had a problem:
different configs generate different assembly (and although the diff itself was
still the same in both case, the actual differences were on different lines;
thus the checksum of the diff was different).
Added logic to
On 07/22/2011 04:15 PM, Michael Eager wrote:
> On 07/22/2011 02:20 PM, Richard Henderson wrote:
>> On 07/22/2011 02:16 PM, Michael Eager wrote:
>>> On 07/22/2011 02:08 PM, Richard Henderson wrote:
On 07/22/2011 12:54 PM, Michael Eager wrote:
> The definition of opcodes in the line number t
On 07/22/2011 02:20 PM, Richard Henderson wrote:
On 07/22/2011 02:16 PM, Michael Eager wrote:
On 07/22/2011 02:08 PM, Richard Henderson wrote:
On 07/22/2011 12:54 PM, Michael Eager wrote:
The definition of opcodes in the line number table is different from
opcodes in other tables, including a
The CLAST produced by CLooG-ISL contains an assignment and GCC chokes
on it. The exact CLAST contains an assignment followed by an if:
scat_1 = max(0,ceild(T_4-7,8));
if (scat_1 <= min(1,floord(T_4-1,8))) {
S7(scat_1);
}
This is equivalent to a loop that iterates only once, and so CLooG
genera
For the google/gcc-4_6 branch _only_. I'll fix the inconsistency in
debug locations later for trunk and google/main.
In some translation units the debug location of make_heap is the
location of its name; in other TUs it's the location of the closing
')'. This causes false positives in gold's ODR c
The HP-UX bootstrap has been failing since the switch to C++. The
first problem was the strsignal problem that Tru64 was also having and
the fix for Tru64 fixes things on HP-UX too. But after I applied
that patch, I got a good build with no errors, and I got a good
test run, but when I went to r
Gerald Pfeifer writes:
> That puzzled me at first, but FreeBSD defines RLIM_INFINITY in
> /usr/include/sys/resource.h and as follows:
>
> ((rlim_t)(((uint64_t)1 << 63) - 1))
Oy.
> 2011-07-22 Gerald Pfeifer
>
> PR target/49817
> * stack-limit.c: Include .
This is OK.
Thanks.
Fixed on 4.6 with r176659. How about 4.5?
Cheers,
Janus
2011/7/19 Janus Weil :
> Hi all,
>
> I just committed a small patch for an ICE-on-invalid regression with
> ALLOCATE, which was approved by Tobias in the PR:
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=176447
>
> I will backport
On Thu, 21 Jul 2011, Ian Lance Taylor wrote:
>> 2011-07-21 Jakub Jelinek
>>
>> PR c++/49756
>> * libiberty.h (stack_limit_increase): New prototype.
>>
>> * stack-limit.c: New file.
>> * Makefile.in: Regenerate deps.
>> (CFILES): Add stack-limit.c.
>> (REQUIRED_OFILE
On 07/22/2011 02:51 PM, Tobias Burnus wrote:
Local, nostatic/nonallocable DT variables were rejected if they contained
(allocatable) coarray components. However, those are allowed - I had initially
misread the constraint.
C526 A coarray or an object with a coarray ultimate
component shall be a d
On 07/20/2011 03:30 PM, Tobias Burnus wrote:
This patch partially undoes the change done in PR 46010.
For that patch, first (comment 7)
+ || !dtp->u.p.ionml->touched)
was added - and after not solving the problem, the complete change was (comment
9 and committed version)
+ || !dtp->u.p.ionml-
Local, nostatic/nonallocable DT variables were rejected if they
contained (allocatable) coarray components. However, those are allowed -
I had initially misread the constraint.
C526 A coarray or an object with a coarray ultimate
component shall be a dummy argument or have the
AL
Tobias Burnus wrote:
This patch adds a "token" element as last element in the descriptor
such that is can be easily ignored when passing a descriptor to a
noncoarray descriptor dummy.
Handling coarray descriptors differently from noncoarray descriptors is
not a good idea if one does not disti
On Fri, 2011-07-22 at 20:41 +0200, Rainer Orth wrote:
> I'm an idiot: I've just copied the relevant lines from
> gcc/config/t-linux, forgetting that libgcc-glibc.ver still lives in
> gcc/config.
>
> ibgcc/config/t-linux should be
>
> # Override t-slibgcc-elf-ver to export some libgcc symbols wit
On 07/21/2011 11:48 AM, Adam Butcher wrote:
On Fri, April 1, 2011 11:06 pm, Jason Merrill wrote:
Now that we're in stage 1 again, I'd like to get your decltype changes
integrated. Sorry I didn't respond sooner.
No worries. I'm guilty of not checking mails for months due to other
commitments
On 07/22/2011 02:16 PM, Michael Eager wrote:
> On 07/22/2011 02:08 PM, Richard Henderson wrote:
>> On 07/22/2011 12:54 PM, Michael Eager wrote:
>>> The definition of opcodes in the line number table is different from
>>> opcodes in other tables, including a modified macro table. There
>>> are many
On 07/22/2011 02:08 PM, Richard Henderson wrote:
On 07/22/2011 12:54 PM, Michael Eager wrote:
The definition of opcodes in the line number table is different from
opcodes in other tables, including a modified macro table. There
are many opcodes (essentially every possible value is used) and the
On 07/22/2011 12:54 PM, Michael Eager wrote:
> The definition of opcodes in the line number table is different from
> opcodes in other tables, including a modified macro table. There
> are many opcodes (essentially every possible value is used) and the
> specific meaning of the opcodes may be diff
On 07/22/2011 01:33 PM, Paolo Bonzini wrote:
> On Fri, Jul 22, 2011 at 02:09, Richard Henderson wrote:
>> I should mention here that I suspect the Cleanest solution is
>> to make DF_DEFER_INSN_RESCAN imply that we also shouldn't grab
>> data from the blocks those new insns are in either. In this
On Wed, Jul 20, 2011 at 18:35, Rainer Orth
wrote:
> I've hacked around this by wrapping the AM_ICONV calls in
> AC_LANG_{PUSH, POP}(C++), but I think this exposes a fundamental
> issue: the configure tests must be performed with the compiler used
> for the build. That this works without is p
On Fri, Jul 22, 2011 at 02:09, Richard Henderson wrote:
> I should mention here that I suspect the Cleanest solution is
> to make DF_DEFER_INSN_RESCAN imply that we also shouldn't grab
> data from the blocks those new insns are in either. In this
> way one can create the block, link it up properl
Hi Daniel,
Daniel Carrera:
This is a simple patch that fixes PR 4755.
It's PR 49755 - the 9 is missing in the number ...
2011-07-22 Daniel Carrera
* trans.c (gfc__allocate_allocatable): [PR 4755] Do not fix
and the reallocate a variable that is already allocated.
Instead of "[PR
Apparently the Solaris C library headers play games with #pragma
redefine_extname such that we need the pragma to affect extern "C"
declarations in namespaces such as std, not just declarations at file scope.
To implement this, I added another C-family hook "c_linkage_bindings"
that returns a
On 22 July 2011 22:43, Jason Merrill wrote:
> On 07/21/2011 01:39 PM, Ville Voutilainen wrote:
>> This one seems to work...
> Looks good. ChangeLogs?
> Jason
In the first patch-mail that had the borken test-patch. Repasted:
2011-07-21 Ville Voutilainen
Warn about the use of final/ov
On 07/22/2011 09:48 AM, Jakub Jelinek wrote:
Thanks. Jason, is this ok for you too?
Yes.
Jason
On 07/21/2011 10:10 AM, Richard Henderson wrote:
I've been wondering if the header shouldn't contain the opcode
definitions, similar to .debug_line, and drop your _define_opcode.
It does mean that you couldn't re-define opcodes within any one
sequence, but does that actually seem useful?
The d
On 07/21/2011 01:39 PM, Ville Voutilainen wrote:
This one seems to work...
Looks good. ChangeLogs?
Jason
Rainer Orth writes:
> 2011-07-21 Rainer Orth
>
> gcc:
> * system.h [__cplusplus]: Wrap C function declarations in extern "C".
>
> include:
> * xregex.h (regoff_t): Define.
This is OK.
I'll preapprove a similar patch to libcpp/system.h if you want to take a
look at tha
Hi,
This patch adds x32 LEA insn support. The main issue is
gen_lowpart (Pmode, operands[1]);
doesn't work on symbol. This patch avoids it.
Also we shouldn't generate 32bit store with x32 PIC source.
Any comments?
Thanks.
H.J.
2011-07-22 H.J. Lu
* config/i386/constraints.md (Y
Ooops... error in my ChangeLog: "fix" -> "free"
2011-07-22 Daniel Carrera
* trans.c (gfc__allocate_allocatable): [PR 4755] Do not free
and the reallocate a variable that is already allocated.
On 07/22/2011 08:54 PM, Daniel Carrera wrote:
Hello,
This is a simple patch that
Hello,
This is a simple patch that fixes PR 4755. Currently the ALLOCATE
statement will free and re-allocate an already allocated scalar. The
Fortran standard says that this is an error. The attached patch fixes
the problem.
I am also attaching two tree dumps of the same program, compiled be
> > * doc/md.texi (Standard Names): Document window_save.
> > * cfgexpand.c (expand_debug_parm_decl): New function extracted from
> > expand_debug_expr and expand_debug_source_expr. If the target has
> > a window_save instruction, adjust the ENTRY_VALUE_EXP.
> > (expand_debug_e
On 07/18/2011 08:02 AM, Aldy Hernandez wrote:
+ /* If other threads can't see this value, no need to restrict stores. */
+ if (ALLOW_STORE_DATA_RACES
+ || !DECL_THREAD_VISIBLE_P (innerdecl))
+{
+ *bitstart = *bitend = 0;
+ return;
+}
What if get_inner_reference returns
Steve,
>> and a new libgcc/config/t-linux:
>>
>> # Override t-slibgcc-elf-ver to export some libgcc symbols with
>> # the symbol versions that glibc used.
>> SHLIB_MAPFILES += $(srcdir)/config/libgcc-glibc.ver
> This died with:
>
>
> make[3]: *** No rule to make target
> `/wsp/sje/gcc_git/src/g
On Fri, 2011-07-22 at 17:12 +0200, Rainer Orth wrote:
> I think you'll need the following:
>
> ia64*-*-linux*)
> extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtfastmath.o"
> # FIXME: Move to *-*-linux* once the SHLIB_* move is complete.
> tmake_file="t-slibgcc t
Ian,
> I agree with Joseph that this is wrong. We must never wrap the #include
> of a system header file with extern "C". That will simply break on some
> systems. You should only wrap extern "C" around the various HAVE_DECL
> declarations.
ok, the following patch does this. Bootstrap on alph
On 07/22/2011 10:19 AM, Ulrich Weigand wrote:
> Richard Henderson wrote:
>> On 07/22/2011 07:42 AM, Ulrich Weigand wrote:
>>> Well, it works for me with just adding -lm to the dg-extra-ld-options.
>>> This still folds cabs to sqrt in the LTO step, and then satisfies that
>>> call via the libm routi
On 07/22/11 19:17, Richard Henderson wrote:
> On 07/22/2011 10:00 AM, Eric Botcazou wrote:
>>> It's getting confused about loads/stores being control_flow_insns and
>>> getting scheduled past each other nonetheless. Mind testing the following?
>>
>> s/flag_non_call_exceptions/cfun->can_throw_non_ca
Richard Henderson wrote:
> On 07/22/2011 07:42 AM, Ulrich Weigand wrote:
> > Well, it works for me with just adding -lm to the dg-extra-ld-options.
> > This still folds cabs to sqrt in the LTO step, and then satisfies that
> > call via the libm routine ... If I understood your intent correctly,
>
On 07/22/2011 10:00 AM, Eric Botcazou wrote:
>> It's getting confused about loads/stores being control_flow_insns and
>> getting scheduled past each other nonetheless. Mind testing the following?
>
> s/flag_non_call_exceptions/cfun->can_throw_non_call_exceptions/
>
Why test either, since control
On 07/22/2011 07:42 AM, Ulrich Weigand wrote:
> Well, it works for me with just adding -lm to the dg-extra-ld-options.
> This still folds cabs to sqrt in the LTO step, and then satisfies that
> call via the libm routine ... If I understood your intent correctly,
> this should still test the same t
> It's getting confused about loads/stores being control_flow_insns and
> getting scheduled past each other nonetheless. Mind testing the following?
s/flag_non_call_exceptions/cfun->can_throw_non_call_exceptions/
--
Eric Botcazou
On 07/22/2011 06:20 AM, Jakub Jelinek wrote:
> Ok, based on further discussions here, on Dwarf-discuss and on IRC
> here is a hopefully final version.
Ok by me. The dwarf edits look good too.
r~
On 07/22/2011 06:29 PM, Uros Bizjak wrote:
Hello!
This patch backports the fix to the testcase for newer glibcs to 4.6 branch.
2011-07-22 Uros Bizjak
Backport from mainline
2011-06-07 Paolo Carlini
PR libstdc++/49293
* testsuite/22_locale/time_get/get_weekday
Hello!
This patch backports the fix to the testcase for newer glibcs to 4.6 branch.
2011-07-22 Uros Bizjak
Backport from mainline
2011-06-07 Paolo Carlini
PR libstdc++/49293
* testsuite/22_locale/time_get/get_weekday/char/38081-1.cc: Tweak
for glibc
As described in the PR, some scan-assembler tests in
g++.dg/debug/dwarf2/icf.C are FAILing on mips-sgi-irix6.5 since
.debug_dcall isn't emitted at all. On mainline, the failures are gone
since .debug_dcall support has been removed. Thus there's no point in
trying to fix the bug on the 4.5 and 4.6
C++0x references the C99 standard, so in C++0x mode we should have the
C99 builtins.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit fc181abfe4b268602287b2cd036035ab40685b9b
Author: Jason Merrill
Date: Fri Jul 22 10:43:00 2011 -0400
PR c++/49813
* c-opts.c (set_std_cxx0x): Se
David asked that I keep in the calls to strchr, etc. This is the change I just
checked in to address the boostrap issue:
2011-07-22 Michael Meissner
* config/rs6000/rs6000.c (rs6000_xcoff_strip_dollar): Rewrite to
avoid warnings when GCC is built with a C++ compiler.
Index: g
On 07/22/2011 06:07 AM, H.J. Lu wrote:
> 2011-07-21 H.J. Lu
>
> * config/i386/i386.c (ix86_option_override_internal): Disallow
> MS ABI in x32 mode.
> (ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi
> only for TARGET_LP64.
> (ix86_handle_abi_attribute
On 07/22/2011 07:11 AM, Richard Guenther wrote:
> Does this look sensible as a start? We can always improve things
> incrementally when we discover a case that is worthwhile.
Looks good to me.
r~
On Fri, Jul 22, 2011 at 5:38 PM, H.J. Lu wrote:
>>> Fixing ifunc test function in the testsuite uncovered a nasty screwup
>>> in config.gcc that prohibited usage of GNU indirect functions on
>>> x86_64-*-linux*. Fixed by mirroring i[34567]86-*-linux* setting.
>>>
>>> 2011-07-22 Uros Bizjak
>>>
On 22/07/11 13:17, Richard Guenther wrote:
Ok.
I found a NULL-pointer dereference bug.
Fixed in the attached. I'll commit this version when the rest of my
testing is complete.
Thanks
Andrew
2011-07-22 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (is_widening_mult_rhs_p): Handle constant
On Fri, Jul 22, 2011 at 8:30 AM, Uros Bizjak wrote:
> On Fri, Jul 22, 2011 at 5:27 PM, Uros Bizjak wrote:
>
>> Fixing ifunc test function in the testsuite uncovered a nasty screwup
>> in config.gcc that prohibited usage of GNU indirect functions on
>> x86_64-*-linux*. Fixed by mirroring i[34567]8
On Sun, Jul 17, 2011 at 8:33 PM, Tom de Vries wrote:
> Bootstrapped and reg-tested on x86_64. Ok for trunk (after ARM testing)?
+static int
+same_succ_equal (const void *ve1, const void *ve2)
+{
...
+ if (bitmap_bit_p (e1->bbs, ENTRY_BLOCK)
+ || bitmap_bit_p (e1->bbs, EXIT_BLOCK)
+ |
On 22/07/11 14:28, Bernd Schmidt wrote:
Oh well, let's shelve it and do it later.
Here's an updated patch with the formatting problem you found fixed.
OK?
Andrew
2011-07-22 Andrew Stubbs
gcc/
* expr.c (expand_expr_real_2): Use widening_optab_handler.
* genopinit.c (optabs): Use set_wid
On Fri, Jul 22, 2011 at 5:27 PM, Uros Bizjak wrote:
> Fixing ifunc test function in the testsuite uncovered a nasty screwup
> in config.gcc that prohibited usage of GNU indirect functions on
> x86_64-*-linux*. Fixed by mirroring i[34567]86-*-linux* setting.
>
> 2011-07-22 Uros Bizjak
>
>
Hello!
Fixing ifunc test function in the testsuite uncovered a nasty screwup
in config.gcc that prohibited usage of GNU indirect functions on
x86_64-*-linux*. Fixed by mirroring i[34567]86-*-linux* setting.
2011-07-22 Uros Bizjak
* config.gcc (i[34567]86-*-linux*): Set
default
On Fri, 22 Jul 2011, Rainer Orth wrote:
> * Provide fpbit_wrap_start/fpbit_wrap_end as in soft-fp, which is a
> general solution.
>
> * Use configure tests. My current preference would be to use
> AC_CHECK_SIZEOF([double]) (for rx) and AC_CHECK_SIZEOF([long double])
> (for mips) and substi
Steve,
> On Tue, 2011-07-19 at 12:47 +0200, Rainer Orth wrote:
>
>> unfortunately, I don't even have an idea what this error is supposed to
>> mean. Seems to be an error ultimately due to bfd/elfxx-ia64.c
>> (elfNN_ia64_size_dynamic_sections) failing.
>>
>> To debug this, I'd start by comparing
> "Jakub" == Jakub Jelinek writes:
Jakub> Ok, based on further discussions here, on Dwarf-discuss and on IRC
Jakub> here is a hopefully final version.
I've updated the gdb patch.
Tom
Joseph,
>> -tp-bit.c: $(srcdir)/config/fp-bit.c
>> -echo '#ifdef __MIPSEL__' > tp-bit.c
>> -echo '# define FLOAT_BIT_ORDER_MISMATCH' >> tp-bit.c
>> -echo '#endif' >> tp-bit.c
>> -echo '#if __LDBL_MANT_DIG__ == 113' >> tp-bit.c
>> -echo '#define QUIET_NAN_NEGATED' >> tp-bit.c
>>
Richard Guenther wrote:
> On Fri, 22 Jul 2011, Ulrich Weigand wrote:
> > Now that we have the linker plugin, this fails on spu-elf with:
> >
> > /tmp/cce6KuRb.ltrans0.ltrans.o: In function `foo':
> > cce6KuRb.ltrans0.o:(.text+0x28): undefined reference to `sqrt'
> >
> > because nothing links agai
On Fri, 22 Jul 2011, Ulrich Weigand wrote:
> Richard Guenther wrote:
>
> > + /* { dg-lto-do run } */
> > + /* { dg-lto-options { { -O0 -flto } } } */
> > + /* { dg-extra-ld-options "-O2 -ffast-math -fuse-linker-plugin" } */
> > + /* { dg-require-linker-plugin "" } */
> > +
> > + /* We require a
On Fri, 22 Jul 2011, Richard Guenther wrote:
> On Fri, 22 Jul 2011, Richard Guenther wrote:
>
> > On Fri, 22 Jul 2011, Richard Guenther wrote:
> >
> > > On Thu, 21 Jul 2011, Joseph S. Myers wrote:
> > >
> > > > On Thu, 21 Jul 2011, Richard Guenther wrote:
> > > >
> > > > > Patch also handling
Richard Guenther wrote:
> + /* { dg-lto-do run } */
> + /* { dg-lto-options { { -O0 -flto } } } */
> + /* { dg-extra-ld-options "-O2 -ffast-math -fuse-linker-plugin" } */
> + /* { dg-require-linker-plugin "" } */
> +
> + /* We require a linker plugin because otherwise we'd need to link
> +aga
On Fri, Jul 22, 2011 at 7:00 AM, H.J. Lu wrote:
> On Fri, Jul 22, 2011 at 6:03 AM, H.J. Lu wrote:
>> On Fri, Jul 22, 2011 at 5:30 AM, Jakub Jelinek wrote:
>>> On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote:
@@ -2660,6 +2664,7 @@ esac
case ${target} in
i[34567]86-*-linux
Hi Ira,
gcc.dg/vect/vect-70.c fails sporadically on spu-elf, because the local
variable "tmp1" exceeds local store size (it is over 1MB in size), and
thus the stack wraps around.
Dorit had originally fixed this by reducing the size of the array:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00018.
On Fri, Jul 22, 2011 at 6:03 AM, H.J. Lu wrote:
> On Fri, Jul 22, 2011 at 5:30 AM, Jakub Jelinek wrote:
>> On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote:
>>> @@ -2660,6 +2664,7 @@ esac
>>> case ${target} in
>>> i[34567]86-*-linux* | x86_64-*-linux*)
>>> tmake_file="${tmake_file}
On 07/19/11 14:25, Andreas Schwab wrote:
> I'm now seeing this ICE:
>
> /bin/sh ./libtool --tag=GCJ --mode=compile
> /usr/local/gcc/gcc-20110719/Build/./gcc/gcj
> -B/usr/local/gcc/gcc-20110719/Build/ia64-suse-linux/libjava/
> -B/usr/local/gcc/gcc-20110719/Build/./gcc/ -B/usr/ia64-suse-linux/b
On Fri, Jul 22, 2011 at 01:31:20PM +, Joseph S. Myers wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> I don't see a change to invoke.texi to document the new options, but
Oops, fixed below, tested with make doc.
> otherwise it looks OK in option handling
Hi,
On Fri, 22 Jul 2011, Richard Guenther wrote:
> Regresses vectorization on i?86 because that defines floathi expanders
> but the vectorizer does not recognize a short -> float conversion
> as that requires different sized vectors (the int -> short truncation
> is also a complication for it).
On Fri, 22 Jul 2011, Jakub Jelinek wrote:
>
> On Thu, Jul 21, 2011 at 08:32:09PM +, Joseph S. Myers wrote:
> > > If -no can't make it to cc1, I'll drop it. Is -fdump* checking that way
> > > ok (with the orig_option_with_args_text -> canonical_option[0] change)?
> >
> > Yes, that seems reas
On 07/22/11 15:27, Andrew Stubbs wrote:
> On 22/07/11 13:34, Bernd Schmidt wrote:
>>> @@ -1242,7 +1242,8 @@ expand_binop_directly (enum machine_mode mode,
>>> optab binoptab,
>>> >rtx target, int unsignedp, enum optab_methods methods,
>>> >rtx last)
>>> >{
>>> > - enum
On 22/07/11 13:34, Bernd Schmidt wrote:
@@ -1242,7 +1242,8 @@ expand_binop_directly (enum machine_mode mode, optab
binoptab,
>rtx target, int unsignedp, enum optab_methods methods,
>rtx last)
>{
> - enum insn_code icode = optab_handler (binoptab, mod
On Thu, Jul 21, 2011 at 10:10:39AM -0700, Richard Henderson wrote:
> On 07/21/2011 04:22 AM, Jakub Jelinek wrote:
> > Currently, the patch emits 3 byte section headers at the start of
> > the .debug_gnu_macro chunks referenced from .debug_info (through
> > DW_AT_GNU_macros), containing version numb
PING again...
2011/5/28 Laurynas Biveinis :
> PING
>
> http://codereview.appspot.com/4250047
> http://gcc.gnu.org/ml/gcc/2011-01/msg00363.html
>
> this patch moves Valgrind header detection from "valgrind" checking to "misc"
> and enables
> the latter whenever the former is enabled.
>
> If only "m
On Thu, Jul 21, 2011 at 10:14 PM, H.J. Lu wrote:
> On Thu, Jul 21, 2011 at 5:36 PM, H.J. Lu wrote:
>> On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson wrote:
>>> On 07/21/2011 04:28 PM, H.J. Lu wrote:
On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson wrote:
> On 07/21/2011 03:02 PM,
On Fri, Jul 22, 2011 at 5:30 AM, Jakub Jelinek wrote:
> On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote:
>> @@ -2660,6 +2664,7 @@ esac
>> case ${target} in
>> i[34567]86-*-linux* | x86_64-*-linux*)
>> tmake_file="${tmake_file} i386/t-pmm_malloc i386/t-i386"
>> + use_initfini_ar
Hi!
On Thu, Jul 21, 2011 at 08:32:09PM +, Joseph S. Myers wrote:
> > If -no can't make it to cc1, I'll drop it. Is -fdump* checking that way
> > ok (with the orig_option_with_args_text -> canonical_option[0] change)?
>
> Yes, that seems reasonable.
Ok, here is an updated patch. I've had to
On Fri, 22 Jul 2011, Jakub Jelinek wrote:
> On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote:
> > @@ -2660,6 +2664,7 @@ esac
> > case ${target} in
> > i[34567]86-*-linux* | x86_64-*-linux*)
> > tmake_file="${tmake_file} i386/t-pmm_malloc i386/t-i386"
> > + use_initfini_array=yes
> >
H.J.
> Most of this change isn't related to libgcc, except for crtstuff.c. You
> just need to find a way to define NO_CTORS_DTORS_SECTIONS
> in libgcc when .init_array is used.
sorry, I misread: initfini-array.o goes into extra_objs, not
extra_parts.
Rainer
--
On Fri, 22 Jul 2011, Rainer Orth wrote:
> > I don't think NetWare should be called out specially like this; either
> > list all removed targets explicitly, or say "all targets deprecated in
> > 4.6" (with a link to the deprecation list), "except for" a list of the
> > targets reprieved.
>
> AF
On Fri, Jul 22, 2011 at 10:57 AM, Tobias Grosser wrote:
> On 07/22/2011 10:08 AM, Richard Guenther wrote:
>>
>> On Fri, Jul 22, 2011 at 1:00 AM, Tobias Grosser wrote:
>>>
>>> Hi,
>>>
>>> I propose to switch to the official cloog.org cloog version with isl
>>> backend and
>>> at the same time to r
On 07/09/11 16:43, Andrew Stubbs wrote:
>> So, what I've done in the end is add a new pointer entry "widening" into
>> optab_d, and dynamically build the widening operations table for each
>> optab that needs it. I've then added new accessor functions that take
>> both input and output modes, and a
On Fri, 22 Jul 2011, matthew green wrote:
> > I don't see how it can be safe; if the stack slot is insufficiently
> > aligned, the special handling will be needed. Maybe the alignment being
> > passed to this code is wrong, but if it's correct then you need a way to
> > handle the unaligned mo
On Fri, 22 Jul 2011, Tobias Grosser wrote:
> I propose to switch to the official cloog.org cloog version with isl backend
> and
> at the same time to remove support for both CLooG-PPL legacy as well as
> CLooG-Parma.
Where are the install.texi changes in this patch series?
--
Joseph S. Myers
j
On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote:
> @@ -2660,6 +2664,7 @@ esac
> case ${target} in
> i[34567]86-*-linux* | x86_64-*-linux*)
> tmake_file="${tmake_file} i386/t-pmm_malloc i386/t-i386"
> + use_initfini_array=yes
> ;;
> i[34567]86-*-* | x86_64-*-*)
> tma
On Fri, Jul 22, 2011 at 5:22 AM, Rainer Orth
wrote:
> H.J.,
>
>> Can you review this change?
>
> as you know, I'm currently working to move all libgcc-related stuff over
> to toplevel libgcc. Can you please move all but the crtstuff.c part of
> this patch over to libgcc instead?
>
> I've got a pa
H.J.,
> Can you review this change?
as you know, I'm currently working to move all libgcc-related stuff over
to toplevel libgcc. Can you please move all but the crtstuff.c part of
this patch over to libgcc instead?
I've got a patch almost ready to move crtstuff.c and other crt files,
and would
On Fri, Jul 22, 2011 at 2:07 PM, Andrew Stubbs wrote:
> ENOPATCH
>
> On 22/07/11 12:57, Andrew Stubbs wrote:
>>
>> On 21/07/11 14:22, Richard Guenther wrote:
>>>
>>> On Thu, Jul 21, 2011 at 2:53 PM, Andrew Stubbs
>>> wrote:
This patch is part bug fix, part better optimization.
ENOPATCH
On 22/07/11 12:57, Andrew Stubbs wrote:
On 21/07/11 14:22, Richard Guenther wrote:
On Thu, Jul 21, 2011 at 2:53 PM, Andrew Stubbs
wrote:
This patch is part bug fix, part better optimization.
Firstly, my initial patch series introduced a bug that caused an
internal
compiler error
On Sun, Jun 19, 2011 at 1:01 PM, Uros Bizjak wrote:
> On Sun, Jun 19, 2011 at 8:39 PM, H.J. Lu wrote:
>
I can't approve the configury changes and would like to defer
to target maintainers for the target specific changes. That said,
I'm not familiar enough with the area of the patc
1 - 100 of 119 matches
Mail list logo
