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
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
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
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
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
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 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,
> 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
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 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
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 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
>>
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 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
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 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 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
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
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.
* 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
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
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
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
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 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
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: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 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
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
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)
@@
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
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 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)
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
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)
@@
> >> 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
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
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
> 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
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/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
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
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
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
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, 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 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, 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 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 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 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 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 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, 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 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, 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
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, 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
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 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
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 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
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: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
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
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
* 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 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 (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 (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 (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 (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-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-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
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
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.$(
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:
> 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 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
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
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
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
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
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 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
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 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 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 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 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 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)':
> 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 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
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 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
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 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 causes, generate
>
> .long symbol
> .long 0
>
> for ".quad symbol"
On 07/21/2011 06:09 PM, Sebastian Pop wrote:
Hi,
On Thu, Jul 21, 2011 at 07:37, Rainer Orth
wrote:
As described in the PR, the use of LANGUAGE_C in CLooG breaks C++
bootstrap on IRIX 6.5. Both MIPS and Alpha C compilers predefine
LANGUAGE_C themselves, which clashes with the CLooG macro in
.
Ok. Updated patch and updated ChangeLog attached. Compiles fine and I'm
about to start running the test suite again.
Cheers,
Daniel.
On 07/21/2011 06:37 PM, Tobias Burnus wrote:
On 07/21/2011 06:01 PM, Daniel Carrera wrote:
I was using Mercurial wrong. I've been experimenting with using
Mer
On 07/21/2011 06:01 PM, Daniel Carrera wrote:
I was using Mercurial wrong. I've been experimenting with using
Mercurial to work with GCC and was doing the diff wrong. The attached
file should be correct (fingers crossed).
Looks better :-)
The patch is OK after regtesting and fixing the follow
1 - 100 of 196 matches
Mail list logo
