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 remove support for both CLooG-PPL legacy as well as
> CLooG-Parma.
>
> We want to switch to cloog-isl as it is the only officia
On 21/07/11 20:29, Joseph S. Myers wrote:
On Tue, 12 Jul 2011, Richard Guenther wrote:
(**) We really ought to forbid any arithmetic on types that have non-mode
precision and only allow conversions to/from such types.
Arithmetic on such types is a perfectly reasonable notion to have in
langua
On Thu, Jul 21, 2011 at 7:30 PM, Uros Bizjak wrote:
> On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu wrote:
>> On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak wrote:
>>> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu wrote:
>>>
>> ".quad symbol" isn't really valid for 32bit.
>
> Why not? We cer
2011/7/21 Richard Guenther :
> On Thu, Jul 21, 2011 at 3:09 PM, Kai Tietz wrote:
>> Hello,
>>
>> this patch changes TRUTH-expression patterns into BIT-expression ones
>> and adjusts code-flow
>> for this.
>>
>> ChangeLog gcc
>>
>> 2011-07-21 Kai Tietz
>>
>> * tree-vrp.c (extract_range_fr
On Thu, Jul 21, 2011 at 7:21 PM, DJ Delorie wrote:
>
>> The patch is not correct, it papers over a problem elsewhere (maybe
>> in forwprop).
>>
>> I can't btw reproduce the issue on either the 4.5 or the 4.6 branch or trunk
>> with the testcase from the PR. I always get
>>
>> v_2 ={v} st_1(D)->
Dear all,
this patch continues a bit the project of argument passing with
-fcoarray=lib. As a reminder: The coarray communication library uniquely
identifies coarrays based on the token - and it needs to know the offset
between the data you want and the base address of the coarray.
This patc
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 remove support for both CLooG-PPL legacy as well as
CLooG-Parma.
We want to switch to
Tobias,
>> Your patch is ok for GCC, please commit.
>> You can post a patch for CLooG on cloog-developm...@googlegroups.com
>> Don't forget to update the documentation of CLooG as well.
>
> I am about to post a patch to CLooG. I will take care of pushing it
> upstream.
Great, thanks.
Rai
On Thu, 21 Jul 2011, Joseph S. Myers wrote:
> On Thu, 21 Jul 2011, Richard Guenther wrote:
>
> > Patch also handling wider modes and not starting with SImode but
> > the mode of int:
>
> Use of target int for anything not about C ABIs is certainly wrong. This
> might be about what operations t
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 wider modes and not starting with SImode but
> > > the mode of int:
> >
> > Use of target int for anything not about C ABIs
On Thu, 21 Jul 2011, Tobias Grosser wrote:
> On 07/21/2011 08:31 PM, Sebastian Pop wrote:
> > Hi,
> >
> > This patch-set addresses the comments from Tobias on fixing PR47654.
> >
> > The first patches are cleanups:
> >
> > - Start counting nesting level from 0 and use the standard "Polyhedral
>
On Fri, Jul 22, 2011 at 10:16 AM, Richard Guenther
wrote:
> On Thu, Jul 21, 2011 at 7:21 PM, DJ Delorie wrote:
>>
>>> The patch is not correct, it papers over a problem elsewhere (maybe
>>> in forwprop).
>>>
>>> I can't btw reproduce the issue on either the 4.5 or the 4.6 branch or trunk
>>> with
Hi,
PR 49796 is basically a bug in the verifier. If IPA-CP creates a
clone of a node (__base_ctor) which also has an alias (__comp_ctor),
normally the verifier is able to trace both to the original node and
be happy but if the node ends up in a different partition, the alias
information is lost a
On Fri, Jul 22, 2011 at 10:14 AM, Kai Tietz wrote:
> 2011/7/21 Richard Guenther :
>> On Thu, Jul 21, 2011 at 3:09 PM, Kai Tietz wrote:
>>> Hello,
>>>
>>> this patch changes TRUTH-expression patterns into BIT-expression ones
>>> and adjusts code-flow
>>> for this.
>>>
>>> ChangeLog gcc
>>>
>>> 201
On 07/22/2011 07:45 AM, Ian Lance Taylor wrote:
OK for mainline?
Sure.
Paolo.
Joseph,
> On Fri, 15 Jul 2011, Rainer Orth wrote:
>
>> Index: htdocs/gcc-4.7/changes.html
>> ===
>> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
>> retrieving revision 1.22
>> diff -u -p -r1.22 changes.html
>> --- htdocs/g
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 wider modes and not starting with SImode but
> > > > the mode of
zhr...@ispras.ru writes:
> This patch fixes the compiler segfault found while regtesting trunk with SMS
> on
> IA64 platform. Segfault happens on test gcc.dg/pr45259.c with -fmodulo-sched
> enabled. The following jump instruction is given as argument for
> doloop_condition_get function:
> (jump_
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 when the input to a multiply was a constant. This was
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
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 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.
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 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
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, 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, 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 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, 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 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
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, 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
> >
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, 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
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,
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: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
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 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 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
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, 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
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 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}
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 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
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, 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
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
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
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
>>
> "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
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
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
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, 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
>
>
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 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 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 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 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 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 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
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
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
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
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
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
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~
> 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 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
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
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/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
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
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 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
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 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
> > * 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
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
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
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
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
On 07/21/2011 01:39 PM, Ville Voutilainen wrote:
This one seems to work...
Looks good. ChangeLogs?
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/22/2011 09:48 AM, Jakub Jelinek wrote:
Thanks. Jason, is this ok for you too?
Yes.
Jason
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
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
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
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
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 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 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 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 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/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 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
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
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
1 - 100 of 119 matches
Mail list logo
