Rainer Orth writes:
> 2011-07-20 Rainer Orth
> Ralf Wildenhues
>
> gcc:
> PR bootstrap/49794
> * configure.ac: Test AM_ICONV with CXX.
> * configure: Regenerate.
> * config/sol2-c.c (solaris_format_types): Use EXPORTED_CONST.
>
> gcc/ada:
>
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 number (2 byte, 4 ATM) and
> 1 byte section offset, but the DW_GNU_MACRO_transp
On Thu, Jul 21, 2011 at 2:47 PM, wrote:
> * tree-ssa-loop-ivopts.c (rtl.h): Include.
Please don't do this. The goal should be that GIMPLE is independent of
RTL, and almost no tree-* files include rtl.h for this reason.
Including rtl.h in tree-ssa-loop-ivopts.c is a very big step in the
wr
On 07/21/2011 11:34 AM, Ville Voutilainen wrote:
Urgh, botched. Will send a new patch after I finish the test run. Note to self:
it's not
a good idea to run check-c++ target with make -j3. One might think tests pass
when
they don't.. :)
Heh. I run check-c++ with -j N, but tee the make output
> 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)->ptr;
>
> in the .optimized tree dump which correctly stat
On 07/21/2011 06:46 PM, Daniel Carrera wrote:
Ok. Updated patch and updated ChangeLog attached. Compiles fine and
I'm about to start running the test suite again.
Doesn't compile here:
gcc/fortran/trans.c: In function 'tree_node*
gfc_allocate_using_lib(stmtblock_t*, tree, tree, tree, tree)':
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 certainly know what value to put there.
>>>
>>
>> x32 doesn't support 64bit relocation, like R_X86_64_64.
>> In many cau
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 certainly know what value to put there.
>>>
>>> x32 doesn't
On 07/21/2011 09:28 AM, H.J. Lu wrote:
> On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson wrote:
>> On 07/21/2011 09:20 AM, H.J. Lu wrote:
>>> ".quad symbol" isn't really valid for 32bit.
>>
>> Why not? We certainly know what value to put there.
>>
>
> x32 doesn't support 64bit relocation, li
On Thu, Jul 21, 2011 at 9:42 AM, Richard Henderson wrote:
> On 07/21/2011 09:28 AM, H.J. Lu wrote:
>> On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson wrote:
>>> On 07/21/2011 09:20 AM, H.J. Lu wrote:
".quad symbol" isn't really valid for 32bit.
>>>
>>> Why not? We certainly know what va
On 21/07/11 18:13, Steven Bosscher wrote:
On Thu, Jul 21, 2011 at 2:47 PM, wrote:
* tree-ssa-loop-ivopts.c (rtl.h): Include.
Please don't do this. The goal should be that GIMPLE is independent of
RTL, and almost no tree-* files include rtl.h for this reason.
Including rtl.h in tree-ss
On Thu, Jul 21, 2011 at 6:42 PM, Richard Henderson wrote:
> On 07/21/2011 09:28 AM, H.J. Lu wrote:
>> On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson wrote:
>>> On 07/21/2011 09:20 AM, H.J. Lu wrote:
".quad symbol" isn't really valid for 32bit.
>>>
>>> Why not? We certainly know what va
At Thu, 21 Jul 2011 18:34:35 +0300,
Ville Voutilainen wrote:
> On 21 July 2011 18:23, Ville Voutilainen wrote:
> > +struct F : E {}; { dg-error "cannot derive from ‘final’ base" }
> Urgh, botched. Will send a new patch after I finish the test run. Note
This one seems to work...
diff --git a/gcc/
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 07/21/2011 10:39 AM, Uros Bizjak wrote:
> IMO, it is OK to disable 64bit relocations, and that compiler is at
> fault here. Consider that something gets written to the d field (see
> example of PR49798). Reading a pointer from *m fileld in DImode, we
> will get non-zero bits in high 32bits of a
This patch fixes part of PR tree-optimization/49749. The operand scans
in tree-ssa-reassoc.c:get_rank() can be prematurely halted by two
erroneous conditions, which this patch removes. Patch pre-approved by
IRC communication with Richard Guenther, 7/21/11.
The wider issue of biasing reassociatio
http://codereview.appspot.com/4798045/diff/1/ipa.c
File ipa.c (right):
http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
ipa.c:1034: {
Has varpool node linking happened at this point? If not, the new code
here is not excersised.
http://codereview.appspot.com/4798045/diff/1/ipa.c#ne
On Thu, Jul 21, 2011 at 11:02 AM, Richard Henderson wrote:
> On 07/21/2011 10:39 AM, Uros Bizjak wrote:
>> IMO, it is OK to disable 64bit relocations, and that compiler is at
>> fault here. Consider that something gets written to the d field (see
>> example of PR49798). Reading a pointer from *m f
Jakub Jelinek writes:
> On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
>> Basile Starynkevitch writes:
>>
>> > I have a similar issue in the MELT branch, and I am passing to
>> > -frandom-seed the md5sum
>> > of relevant source files. With such a trick, the seed is reproduci
On Thu, Jul 21, 2011 at 10:30 AM, 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 ce
Jakub Jelinek writes:
> 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_OFILES): Add ./stack-limit.$(
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
SCattering Transformed" psct_* interface.
- Do not compute twice type, lb, and ub.
- Record the loop level that defi
2011-07-05 Sebastian Pop
* graphite-clast-to-gimple.c (compute_bounds_for_level): Call
psct_dynamic_dim.
(translate_clast_for_loop): Pass loop level to dependency_in_loop_p.
(gcc_type_for_iv_of_clast_loop): Update use of level.
(gloog): Start counting nes
2011-07-05 Sebastian Pop
* graphite-clast-to-gimple.c (graphite_create_new_loop): Do not
recompute type, lb, and ub. Get them from...
(graphite_create_new_loop_guard): ...here. Pass in parameter
pointers to type, lb, and ub.
(translate_clast_for_loop):
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (clast_get_body_of_loop): Add fixme
comment.
---
gcc/ChangeLog |5 +
gcc/graphite-clast-to-gimple.c | 19 ++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/gcc/Cha
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (struct clast_name_index): Add level.
(new_clast_name_index): Add level parameter.
(clast_name_to_level): New.
(save_clast_name_index): Add level parameter.
(newivs_to_depth_to_newiv): Removed.
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (type_for_interval): Generate signed
types whenever possible.
---
gcc/ChangeLog |5 +
gcc/graphite-clast-to-gimple.c | 13 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --gi
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (max_signed_precision_type): Removed.
(max_precision_type): Inline max_signed_precision_type.
(type_for_clast_red): Use max_precision_type.
(type_for_clast_bin): Same.
(type_for_clast_for): Same.
---
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (struct ivs_params): New.
(clast_name_to_gcc): Use ivs_params to pass around parameters.
(clast_to_gcc_expression): Same.
(clast_to_gcc_expression_red): Same.
(gcc_type_for_clast_term): Same.
(
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (gcc_type_for_interval): Renamed
type_for_interval.
(gcc_type_for_value): Renamed type_for_value.
(gcc_type_for_clast_term): Renamed type_for_clast_term.
(gcc_type_for_clast_expr): Renamed type_for_cla
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (struct clast_name_index): Add lb
and ub fields.
(new_clast_name_index): Add lb and ub parameters.
(free_clast_name_index): New.
(clast_name_to_lb_ub): New.
(save_clast_name_index): Add lb and
2011-07-21 Sebastian Pop
PR middle-end/47654
PR middle-end/49649
* graphite-clast-to-gimple.c (type_for_clast_term): Pass v1 and v2
in parameter. Initialize v1 and v2 based on the values returned
by clast_name_to_lb_ub.
(type_for_clast_red): Pass
On Thu, Jul 21, 2011 at 11:09 AM, wrote:
>
> http://codereview.appspot.com/4798045/diff/1/ipa.c
> File ipa.c (right):
>
> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
> ipa.c:1034: {
> Has varpool node linking happened at this point? If not, the new code
> here is not excersised
On 07/21/2011 07:22 PM, Tobias Burnus wrote:
On 07/21/2011 06:46 PM, Daniel Carrera wrote:
Ok. Updated patch and updated ChangeLog attached. Compiles fine and
I'm about to start running the test suite again.
Doesn't compile here:
gcc/fortran/trans.c: In function 'tree_node*
gfc_allocate_using
On Thu, Jul 21, 2011 at 11:32 AM, Rong Xu wrote:
> On Thu, Jul 21, 2011 at 11:09 AM, wrote:
>>
>> http://codereview.appspot.com/4798045/diff/1/ipa.c
>> File ipa.c (right):
>>
>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
>> ipa.c:1034: {
>> Has varpool node linking happened a
this is a good point. ipa_discover_readonly_nonaddressable_vars() is
called in two passes. whole-program (whole program visibility
analysis) and static-var. The one in whole-program is ok here as it is
bundled together with the analysis. the invocation in static-var can
go wrong.
should we add a
On Tue, 12 Jul 2011, matthew green wrote:
> i'm having a problem with GCC 4.5.3 on netbsd-m68k target. i've tracked
> it down to this change from several years ago:
>
> > 2007-02-06 Joseph Myers
> >
> > * expr.c (emit_push_insn): If STRICT_ALIGNMENT, copy to an
> > unaligned stack sl
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
language-independent code and carry out languag
On Thu, Jul 21, 2011 at 12:27 PM, Rong Xu wrote:
> this is a good point. ipa_discover_readonly_nonaddressable_vars() is
> called in two passes. whole-program (whole program visibility
> analysis) and static-var. The one in whole-program is ok here as it is
> bundled together with the analysis. th
wait a second. this still won't work if we disable the whole-program
pass (like my original change, the visibility analysis change won't
kick in). we also need to change varpool_node_link() to merge the
local attribute.
-Rong
On Thu, Jul 21, 2011 at 12:35 PM, Xinliang David Li wrote:
> On Thu, J
On Thu, 21 Jul 2011 11:13:00 -0700
Ian Lance Taylor wrote:
> Jakub Jelinek writes:
>
> > On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
> >> Basile Starynkevitch writes:
> >>
> >> > I have a similar issue in the MELT branch, and I am passing to
> >> > -frandom-seed the md5
On Tue, 12 Jul 2011, Rainer Orth wrote:
> One odd thing out is that the lm32 snippet misses
>
> softfp_exclude_libgcc2 := y
>
> compared to the new t-softfp-sfdf. I'm currently handling this since I
> cannot tell if this is intentional or just an accident.
The general rule is that softfp_exclu
On Thu, 14 Jul 2011, Ilya Enkovich wrote:
> * doc/tm.texi.in (reassociation_width): New hook documentation.
Unless the documentation for a new hook is based on pre-existing GFDL-only
text, it should go in target.def not tm.texi.in, with the only thing added
to tm.texi.in being a single @h
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/gcc-4.7/changes.htm
On Thu, 21 Jul 2011, Rainer Orth wrote:
> diff --git a/gcc/system.h b/gcc/system.h
> --- a/gcc/system.h
> +++ b/gcc/system.h
> @@ -24,6 +24,10 @@ along with GCC; see the file COPYING3.
> #ifndef GCC_SYSTEM_H
> #define GCC_SYSTEM_H
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
I don'
On Thu, Jul 21, 2011 at 10:30 AM, 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 ce
On Wed, 13 Jul 2011, Jakub Jelinek wrote:
> Ideally we'd just include explicitly passed options from command line that
> haven't been overridden by other command line options, and would sort them,
> so that there are higher chances of DW_AT_producer strings being merged
> (e.g. -O2 -ffast-math vs.
On Tue, 12 Jul 2011, Ian Lance Taylor wrote:
> This patch to the C frontend disables warnings about -Wstrict-overflow
> when handling expressions which will not be evaluated. This fixes PR
> 49705.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK for mainline?
OK.
--
Joseph S.
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 the target does efficiently, or what
functions are present
On Thu, Jul 21, 2011 at 10:00 PM, H.J. Lu wrote:
>> /* Represents viewing something of one type as being of a second type.
>> This corresponds to an "Unchecked Conversion" in Ada and roughly to
>> the idiom *(type2 *)&X in C. The only operand is the value to be
>> viewed as being of anothe
On Thu, Jul 21, 2011 at 08:06:49PM +, Joseph S. Myers wrote:
> On Wed, 13 Jul 2011, Jakub Jelinek wrote:
>
> > Ideally we'd just include explicitly passed options from command line that
> > haven't been overridden by other command line options, and would sort them,
> > so that there are higher
On Thu, Jul 21, 2011 at 1:17 PM, Uros Bizjak wrote:
> On Thu, Jul 21, 2011 at 10:00 PM, H.J. Lu wrote:
>
>>> /* Represents viewing something of one type as being of a second type.
>>> This corresponds to an "Unchecked Conversion" in Ada and roughly to
>>> the idiom *(type2 *)&X in C. The onl
On Thu, 21 Jul 2011, Jakub Jelinek wrote:
> So
>
> gcc_checking_assert (save_decoded_options[j].canonical_option[0][0] ==
> '-');
> switch (save_decoded_options[j].canonical_option[0][1])
>
> instead? The reason for checking the option text instead of code
Yes.
> was just becaus
Attached patch applied:
2011-07-21 François Dumont
* include/debug/safe_unordered_sequence.h,
safe_unordered_sequence.tcc: Rename respectively in...
* include/debug/safe_unordered_container.h,
safe_unordered_container.tcc: ...those. _Safe_unordered_sequence
Please review the new patch attached to this email.
thanks,
-Rong
On Thu, Jul 21, 2011 at 12:44 PM, Rong Xu wrote:
> wait a second. this still won't work if we disable the whole-program
> pass (like my original change, the visibility analysis change won't
> kick in). we also need to change varp
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
SCattering Transformed" psct_* interface.
- Do not compute twice typ
On Thu, Jul 21, 2011 at 10:22 PM, H.J. Lu wrote:
>> Expand generates:
>>
>> (insn 8 6 9 (set (reg:SI 68)
>> (symbol_ref:SI ("") [flags 0x40] > >)) p
>> r49798.c:12 -1
>> (nil))
>>
>> (insn 9 8 10 (set (reg:DI 67)
>> (zero_extend:DI (reg:SI 68))) pr49798.c:12 -1
>> (
> On 07/12/2011 02:22 PM, harsha.jaga...@amd.com wrote:
> > We would like to propose changing AVX generic mode tuning to generate
> 128-bit
> > AVX instead of 256-bit AVX.
>
> You indicate a 3% reduction on bulldozer with avx256.
> How does avx128 compare to -mno-avx -msse4.2?
We see these % diff
Daniel Carrera wrote:
On 07/21/2011 07:22 PM, Tobias Burnus wrote:
Doesn't compile here:
gcc/fortran/trans.c:656:8: error: unused variable 'status_type'
[-Werror=unused-variable]
Hmm... I really wish that my Makefile was as picky as yours. But last
time I tried to change my configure flag every
Ok.
David
On Thu, Jul 21, 2011 at 1:45 PM, Rong Xu wrote:
> Please review the new patch attached to this email.
>
> thanks,
>
> -Rong
>
> On Thu, Jul 21, 2011 at 12:44 PM, Rong Xu wrote:
>> wait a second. this still won't work if we disable the whole-program
>> pass (like my original change, th
> >> We would like to propose changing AVX generic mode tuning to
> generate 128-bit
> >> AVX instead of 256-bit AVX.
> >
> > You indicate a 3% reduction on bulldozer with avx256.
> > How does avx128 compare to -mno-avx -msse4.2?
> > Will the next AMD generation have a useable avx256?
> >
> > I'm n
I committed the following patch as obvious.
2011-07-21 Steven G. Kargl
* gfortran.texi: Remove a duplicate word.
Index: gfortran.texi
===
--- gfortran.texi (revision 176586)
+++ gfortran.texi (working copy)
@@
Ignoring all of the other problems that partitioning might have, it
does Just So Happen to work for the single most popular target. So
let's see about keeping the pass limping along for a while longer.
The problem I'm attempting to solve here is the gross hack in
convert_to_eh_region_ranges, whic
On Thu, Jul 21, 2011 at 2:00 PM, Uros Bizjak wrote:
> On Thu, Jul 21, 2011 at 10:22 PM, H.J. Lu wrote:
>
>>> Expand generates:
>>>
>>> (insn 8 6 9 (set (reg:SI 68)
>>> (symbol_ref:SI ("") [flags 0x40] >> >)) p
>>> r49798.c:12 -1
>>> (nil))
>>>
>>> (insn 9 8 10 (set (reg:DI 67)
Basile Starynkevitch writes:
> Using the md5sum of the file is probably not bad neither. I would understand
> that you
> find it being perhaps too complex for your need, but it is much more random
> than just the
> file name (because the md5sum changes with the file content).
Granted, but I am
On 07/21/2011 01:16 PM, 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
Some targets (m32c, tpf, mips) have more than one pointer size. It is
not correct to assume that a pointer is POINTER_SIZE.
Index: gcc/cp/cvt.c
===
--- gcc/cp/cvt.c(revision 176554)
+++ gcc/cp/cvt.c(working copy)
@@
Hello!
Revision 164725 [1] broke detection of ifunc support in the testsuite
[2] due to extra "#endif" without if in the test function. Attached
patch fixes this up.
2011-07-21 Uros Bizjak
* lib/target-supports.exp (check_ifunc_available): Fix test function.
The patch is tested on x8
On Wed, Jul 13, 2011 at 8:37 AM, Richard Henderson wrote:
> On 07/13/2011 08:35 AM, H.J. Lu wrote:
>> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson wrote:
>>> On 07/13/2011 07:02 AM, H.J. Lu wrote:
Hi Richard,
Is my patch OK?
>>>
>>> No, I don't think it is.
>>>
>>
>> What is
On 07/21/2011 03:02 PM, H.J. Lu wrote:
> * config/i386/i386.c (function_value_64): Always return pointers
> in Pmode.
> (ix86_promote_function_mode): New.
> (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
Much better, thanks.
r~
On Thu, Jul 21, 2011 at 11:17 PM, Richard Henderson wrote:
> Suggestions for something better than the df_finish_pass hack
> that I added at the end of partition_hot_cold_basic_blocks are
> very welcome.
Is it not enough to just call df_bb_refs_record and df_analyze
manually after you have creat
On 07/21/2011 03:05 PM, Steven Bosscher wrote:
> On Thu, Jul 21, 2011 at 11:17 PM, Richard Henderson wrote:
>
>> Suggestions for something better than the df_finish_pass hack
>> that I added at the end of partition_hot_cold_basic_blocks are
>> very welcome.
>
> Is it not enough to just call df_b
Seeing little opposition, I plod further... now with documentation
and a test case. OK yet?
Index: doc/extend.texi
===
--- doc/extend.texi (revision 176586)
+++ doc/extend.texi (working copy)
@@ -5089,12 +5089,74 @@ Note t
On Thu, Jul 21, 2011 at 11:56 PM, Uros Bizjak wrote:
> Revision 164725 [1] broke detection of ifunc support in the testsuite
> [2] due to extra "#endif" without if in the test function. Attached
> patch fixes this up.
Actually, we can use existing testsuite infrastructure to simplify the
functio
This patch adds support for GNU/kFreeBSD systems running on MIPS.
--
Robert Millan
2011-07-22 Robert Millan
Support for GNU/kFreeBSD systems running on MIPS.
* config.gcc: Detect mips*-*-kfreebsd*-gnu.
* config.host: Likewise.
* config/mips/kfreebsd-gnu.h: New file.
* config/mips/kfreeb
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 officially maintained version
of cloog. Furthermore, it provides features that
2011-07-21 Tobias Grosser
* configure: Regenerated.
* configure.ac: Require cloog isl 0.16.3
---
ChangeLog|5 +
configure|6 +++---
configure.ac |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a08a780..3d
2011-07-21 Tobias Grosser
* configure: Regenerated.
* config/cloog.m4: Remove support for CLooG-ppl and CLooG-parma,
both cloog.org and legacy versions. The only supported version will
be CLooG with the isl backend.
---
ChangeLog |7 ++
config/cloog.m4
2011-07-21 Tobias Grosser
* configure: Regenerated.
* config/cloog.m4: Do not define CLOOG_ORG
and in gcc/
2011-07-21 Tobias Grosser
* Makefile.in (graphite-clast-to-gimple.o, graphite-cloog-util.o):
Remove graphite-cloog-util.h.
* graphite-clast-to
On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson wrote:
> On 07/21/2011 03:02 PM, H.J. Lu wrote:
>> * config/i386/i386.c (function_value_64): Always return pointers
>> in Pmode.
>> (ix86_promote_function_mode): New.
>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>
> Much be
On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
> static void
> create_params_index (htab_t index_table, CloogProgram *prog) {
> - CloogNames* names = cloog_program_names (prog);
> - int nb_parameters = cloog_names_nb_parameters (names);
> - char **parameters = cloog_names_parameters (na
On 07/22/2011 01:46 AM, Sebastian Pop wrote:
On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
static void
create_params_index (htab_t index_table, CloogProgram *prog) {
- CloogNames* names = cloog_program_names (prog);
- int nb_parameters = cloog_names_nb_parameters (names);
- char *
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, H.J. Lu wrote:
>>> * config/i386/i386.c (function_value_64): Always return pointers
>>> in Pmode.
>>> (ix86_promote_function_mode): New.
>>> (TARGET
Hi Tobias,
On Thu, Jul 21, 2011 at 18:00, 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.
>
Many thanks for implementing this cleanup.
> W
On 07/21/2011 03:11 PM, Richard Henderson wrote:
> On 07/21/2011 03:05 PM, Steven Bosscher wrote:
>> On Thu, Jul 21, 2011 at 11:17 PM, Richard Henderson wrote:
>>
>>> Suggestions for something better than the df_finish_pass hack
>>> that I added at the end of partition_hot_cold_basic_blocks are
>>
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, H.J. Lu wrote:
* config/i386/i386.c (function_value_64): Always return pointers
in Pmod
On Thu, Jul 21, 2011 at 11:02 AM, Richard Henderson wrote:
> On 07/21/2011 10:39 AM, Uros Bizjak wrote:
>> IMO, it is OK to disable 64bit relocations, and that compiler is at
>> fault here. Consider that something gets written to the d field (see
>> example of PR49798). Reading a pointer from *m f
Hi,
This patch fixes 3 compiling warnings. One of them was actually a wrong
assert (operator precedence mistake).
Diogo Sousa
2011-07-22 Diogo Sousa
* natObject.cc: Fixed an expression inside an assert (it
always yield true). This was also a compiler warning.
* libcaf
> On Tue, 12 Jul 2011, matthew green wrote:
>
> > i'm having a problem with GCC 4.5.3 on netbsd-m68k target. i've tracked
> > it down to this change from several years ago:
> >
> > > 2007-02-06 Joseph Myers
> > >
> > > * expr.c (emit_push_insn): If STRICT_ALIGNMENT, copy to an
> > > una
On Jul 21, 2011, at 3:29 PM, Uros Bizjak wrote:
> Actually, we can use existing testsuite infrastructure to simplify the
> function substantially.
>
> 2011-07-21 Uros Bizjak
>
>* lib/target-supports.exp (check_ifunc_available): Rewrite.
>
> The patch is tested on x86_64-pc-linux-gnu,
Some shortened pathnames from doc cleanup branch.
tested x86/linux
-benjamin2011-07-21 Benjamin Kosnik
* testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc: Move...
* testsuite/ext/pb_ds/regression/tree_set_rand.cc: ... here.
* testsuite/ext/pb_ds/regression/tree_no_data_
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, H.J. Lu wrote:
> * config/i386/i386.c (functi
On Thu, Jul 21, 2011 at 3:00 AM, Uros Bizjak wrote:
> On Tue, Jul 19, 2011 at 6:47 AM, H.J. Lu wrote:
>
> So, since copy_to_reg & co. expects x in Pmode or VOIDmode constant
> (due to force_reg that won't do mode conversion), we have to implement
> them with a mode conversion...
>
>> This patch a
David Edelsohn writes:
> On Wed, Jul 20, 2011 at 4:25 PM, Ian Lance Taylor wrote:
>
>> Presumably the fix will be to use -frandom-seed. Does this patch fix
>> the problem? (The only real change is to fragment.am, the other changes
>> are all generated by automake).
>
> This patch gets the buil
Rainer Orth writes:
> diff --git a/gcc/system.h b/gcc/system.h
> --- a/gcc/system.h
> +++ b/gcc/system.h
> @@ -24,6 +24,10 @@ along with GCC; see the file COPYING3.
> #ifndef GCC_SYSTEM_H
> #define GCC_SYSTEM_H
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> /* We must include stda
One of my recent patches broke the toplevel configury. I moved a test
of $configdirs to a point before nonexistent directories have been
removed from configdirs. The test was for whether gcc is being
configured. The test is fine in the gcc repository, but not in the src
repository.
This patch f
101 - 196 of 196 matches
Mail list logo
