Hi Diego,
This patch adjusts the .xfail files for Google's ARM & PowerPC64 targets.
The test cpp0x/variadic-value1.C was already marked as an expected ERROR
for X86_64. This also mark gcc.dg/torture/tls/tls-test.c as flaky since
we have issues with the simulator. Tested by building the toolch
As Robert Mason pointed out, the POSIX open call already contains the
mode ("S_IRUSR | S_IWUSR" is the same as 0600).
I somehow must have missed the "," and read it as "|". The extra
argument does not harm as open is variadic; nonetheless, it makes sense
to remove the extra argument.
Committ
Hi,
This is a ping for the patch that add memory model attributes
'data16', 'data20', 'data24' and 'data32' for CR16 target.
For details kindly refer:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00983.html
Can someone please review the patch?
Thanks & Regards,
Ajinkya Dhobale
KPIT Cummins, P
On Wed, May 30, 2012 at 4:40 PM, Sterling Augustine
wrote:
> On Wed, May 30, 2012 at 2:15 PM, Gabriel Dos Reis
> wrote:
>> On Tue, May 29, 2012 at 5:32 PM, Sterling Augustine
>> wrote:
>>
Index: gcc/c-family/c-pretty-print.h
=
Change the check functions from templates to overloads.
Add "set unwindonsignal on" to gdbinit.in to gracefully handle aborts
in functions used from gdb.
Tested on x86-64.
Index: gcc/ChangeLog.cxx-conversion
2012-05-30 Lawrence Crowl
* tree.h (tree_check): Change from template to
On 05/30/2012 02:44 PM, Richard Sandiford wrote:
The previous patch asserted that the first and second sets are now the same,
which means that the second and (temporary) third sets are no longer needed.
This patch removes them and renames the first set to have the same names
as the second used to
On 05/30/2012 02:41 PM, Richard Sandiford wrote:
This patch makes the original move_cost calculation match the value
currently calculated for ira_register_move_cost, asserting that the
"IRA code" now has nothing to do.
It seems like we really ought to be preserving the contains_reg_of_mode
part
On 05/30/2012 02:28 PM, Richard Sandiford wrote:
I needed to move an instance of:
COPY_HARD_REG_SET (temp_hard_regset, reg_class_contents[cl]);
AND_COMPL_HARD_REG_SET (temp_hard_regset, no_unit_alloc_regs);
if (hard_reg_set_empty_p (temp_hard_regset))
continue;
But
On 05/30/2012 02:26 PM, Richard Sandiford wrote:
This patch adjusts init_move_cost to follow local conventions.
The new names are IMO more readable anyway (it's easier to see
that p1 is related to cl1 than i, etc.).
Richard
gcc/
* ira.c (init_move_cost): Adjust local variable names to
On 05/30/2012 02:24 PM, Richard Sandiford wrote:
After the preceding patch, only ira_init_register_move_cost uses
the regclass costs directly. This patch moves them to IRA and makes
init_move_cost static to it.
This is just a stepping stone to make the later patches easier to review.
Richard
On 05/30/2012 02:21 PM, Richard Sandiford wrote:
The only part of IRA that uses move_costs directly is copy_cost.
It looks like this might be an oversight, since all related costs
already use ira_register_move_cost.
move_cost was from code which was part or regclass before.
As mentioned in the
On 05/30/2012 02:15 PM, Richard Sandiford wrote:
For one of the later patches I wanted to test whether a class had any
allocatable registers. It turns out that we have two arrays that hold
the number of allocatable registers in a class:
ira_class_hard_regs_num
ira_available_class_regs
Resend ChangeLog and two patches by attachment. Patches using `diff
-upr' based on quilt internal data .pc/XX and original directory.
ChangeLog
Description: Binary data
gcc.patch
Description: Binary data
libcpp.patch
Description: Binary data
Resend ChangeLog and two patches by attachment.
ChangeLog
Description: Binary data
gcc.patch
Description: Binary data
libcpp.patch
Description: Binary data
On Thu, May 31, 2012 at 09:43:09AM +0930, Alan Modra wrote:
> real bug that the register checks have uncovered. I haven't
> determined whether this is a new bug introduced with my prologue
> changes, or whether it's a long-standing bug. I suspect the latter.
Looks like it is one I introduced. g
On Wed, May 30, 2012 at 03:21:28PM +0200, Dominique Dhumieres wrote:
> I get an ICE of the form
>
> /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/savres.c: In function 'nb_all':
> /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/savres.c:473:3: internal
> compiler error: in rs6000_emit_prologue, a
This patch to the Go frontend avoids a crash when invalid code uses
invalid constant types with && or ||. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
diff -r 59ff38be518a go/expressions.cc
--- a/go/expressions.cc Fri May 25 14:49:53 2
The previous fix for PR target/52999 didn't work...
This change implements the suggestion Jakub.
Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Cana
This is my first patch submission, so please let me know if I did anything
incorrectly.
This patch reorganizes the list of warnings available in GCC. I changed the top
of the page to be an overview of -Wall, then -Wextra, then -Wpedantic. After
that, individual warnings are listed with all of the
Eric, while looking at soft-fp code generated in glibc I noticed that
for v9 on 32-bit we end up doing software multiplies and divides :-/
I also noticed that the two-limb addition and subtraction could be
done using a branchless sequence on 64-bit.
Any objections?
libgcc/
* longlong.h
On 05/25/12 10:55, Richard Henderson wrote:
On 05/25/2012 06:25 AM, Aldy Hernandez wrote:
OK? Would this be acceptable for the 4.7 branch as well?
curr
PR middle-end/53008
* trans-mem.c (ipa_tm_create_version_alias): Output new_node if
accessed indirectly.
(ipa_tm_create_version): Same.
Ok
On 05/30/2012 10:44 AM, Jason Merrill wrote:
The code in build_new_1 already knows how to handle an initializer that
it was unable to stabilize, but the logic was backwards in a critical
place. I'm surprised this typo hasn't been hit before since it was
introduced in 2006...
...and then this pa
On 05/30/2012 10:26 PM, Pedro Alves wrote:
> On 05/30/2012 05:44 PM, Joerg Wunsch wrote:
>
>> As Richard Henderson wrote:
>>
>>> Instead of writing to stdout, open the file to write, and open
>>> it in binary mode. Seems much easier than fighting with conversion
>>> after the fact.
>>
>> (Discla
This is OK for google/gcc-4_6.
http://codereview.appspot.com/6248072/
On Wed, May 30, 2012 at 2:15 PM, Gabriel Dos Reis
wrote:
> On Tue, May 29, 2012 at 5:32 PM, Sterling Augustine
> wrote:
>
>>> Index: gcc/c-family/c-pretty-print.h
>>> ===
>>> --- gcc/c-family/c-pretty-print.h (revision 187603)
On 05/30/2012 05:44 PM, Joerg Wunsch wrote:
> As Richard Henderson wrote:
>
>> Instead of writing to stdout, open the file to write, and open
>> it in binary mode. Seems much easier than fighting with conversion
>> after the fact.
>
> (Disclaimer: I'm not the author.)
>
> There has been an arg
On Tue, May 29, 2012 at 5:32 PM, Sterling Augustine
wrote:
>> Index: gcc/c-family/c-pretty-print.h
>> ===
>> --- gcc/c-family/c-pretty-print.h (revision 187603)
>> +++ gcc/c-family/c-pretty-print.h (working copy)
>> @@ -3
This patch is for the google/gcc-4_6 branch. It fixes an issue that
causes the .debug_addr section to be twice as big as it should be.
Tested on x86_64 and ran validate_failures.py. Also tested by
building an internal application and verifying correct behavior.
2012-05-30 Cary Coutant
Hello Everyone,
This patch is for the Cilk Plus branch mainly affecting template code
in C++. This patch will pass the spawn information for the expanded template
functions. This information was not propagated correctly in the existing
implementation.
Thanks,
Balaji V. Iyer.Index: gcc/
> "Lawrence" == Lawrence Crowl writes:
Lawrence> On 5/24/12, Gabriel Dos Reis wrote:
>> On May 24, 2012 Lawrence Crowl wrote:
>> > Add a type-safe hash table, typed_htab. Uses of this table
>> > replace uses of libiberty's htab_t. The benefits include less
>> > boiler-plate code, full typ
Ian Lance Taylor writes:
> Richard Sandiford writes:
>> gcc/
>> * doc/invoke.texi (sched-pressure-algorithm): Document new --param.
>> * common.opt (fsched-pressure-algorithm=): Remove.
>> * flag-types.h (sched_pressure_algorithm): Move to...
>> * sched-int.h (sched_pressure_a
The previous patch asserted that the first and second sets are now the same,
which means that the second and (temporary) third sets are no longer needed.
This patch removes them and renames the first set to have the same names
as the second used to.
Richard
gcc/
* ira-int.h (target_ira_i
This patch makes the original move_cost calculation match the value
currently calculated for ira_register_move_cost, asserting that the
"IRA code" now has nothing to do.
It seems like we really ought to be preserving the contains_reg_of_mode
part of the original move_cost check, i.e.:
I needed to move an instance of:
COPY_HARD_REG_SET (temp_hard_regset, reg_class_contents[cl]);
AND_COMPL_HARD_REG_SET (temp_hard_regset, no_unit_alloc_regs);
if (hard_reg_set_empty_p (temp_hard_regset))
continue;
But this can more easily be calculated as:
ira_clas
This patch adjusts init_move_cost to follow local conventions.
The new names are IMO more readable anyway (it's easier to see
that p1 is related to cl1 than i, etc.).
Richard
gcc/
* ira.c (init_move_cost): Adjust local variable names to match
file conventions. Use ira_assert ins
After the preceding patch, only ira_init_register_move_cost uses
the regclass costs directly. This patch moves them to IRA and makes
init_move_cost static to it.
This is just a stepping stone to make the later patches easier to review.
Richard
gcc/
* regs.h (move_table, move_cost, may_
The only part of IRA that uses move_costs directly is copy_cost.
It looks like this might be an oversight, since all related costs
already use ira_register_move_cost.
As mentioned in the covering message, the two arrays are usually
the same anyway. The only hitch is that we have:
if (!move
On Wed, May 30, 2012 at 10:45 AM, Steven Bosscher wrote:
> Hello,
>
> I've committed this patch to fix a -Wmissing-prototypes warning in
> ira.c. I don't understand why this didn't cause a bootstrap failure
> (with -Werror) but oh well.
It is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
-
On 05/30/2012 01:52 PM, Cary Coutant wrote:
At the time we emit the pubtypes table, we have a pointer to the DIE
I can add a field to the comdat_type_node structure to keep track of
the skeleton DIE for a given type unit, so that I can easily get the
right DIE offset for cases where there is a s
For one of the later patches I wanted to test whether a class had any
allocatable registers. It turns out that we have two arrays that hold
the number of allocatable registers in a class:
ira_class_hard_regs_num
ira_available_class_regs
We calculate them in quick succession and already a
On 05/29/2012 12:00 PM, Florian Weimer wrote:
This patch flags operator new on variably modified types as an error.
If this is acceptable, this will simplify the implementation of the
C++11 requirement to throw std::bad_array_new_length instead of
allocating a memory region which is too short.
On Fri, May 25, 2012 at 6:53 AM, H.J. Lu wrote:
> On Sun, May 20, 2012 at 7:47 AM, H.J. Lu wrote:
>> Hi,
>>
>> This patch allows -mpreferred-stack-boundary=3 on x86-64 when SSE is
>> disabled. Since this option changes ABI, I also added a warning for
>> -mpreferred-stack-boundary=3. OK for trun
On 5/29/12, Michael Matz wrote:
> On Sun, 27 May 2012, Gabriel Dos Reis wrote:
> > > people actually working on it and used to that style.
> > > We don't want to have a mixture of several different styles in
> > > the compiler. I (and I expect many others) don't want anyone
> > > working around t
At the moment there are three sets of move costs:
move_cost
may_move_in_cost
may_move_out_cost
ira_register_move_cost
ira_may_move_in_cost
ira_may_move_out_cost
ira_max_register_move_cost
ira_max_may_move_in_cost
ira_max_may_move_out_cost
Having the first two
OK.
Jason
> At the time we emit the pubtypes table, we have a pointer to the DIE
> that has been moved to the type unit, and there's no mapping from that
> back to the skeleton DIE. As it stands, we don't even emit a skeleton
> DIE unless one of its descendants is a declaration, so we can't count
> on always
On May 30, 2012, at 9:15 AM, Gabriel Dos Reis wrote:
>> On the other hand, it is such an obscure feature that it is rather unlikely
>> that it has any users. The usual C++ conformance fixes and libstdc++ header
>> reorganizations cause much more pain, and no depreciation is required for
>> them.
>
I'm attaching an updated version of the patch, addressing the comments from
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01615.html
This patch adds arm32 to targets that support vect_char_mult. In addition,
the test is updated to prevent vectorization of the initialization loop. The
expected numbe
Hello,
I've committed this patch to fix a -Wmissing-prototypes warning in
ira.c. I don't understand why this didn't cause a bootstrap failure
(with -Werror) but oh well.
Ciao!
Steven
Index: ChangeLog
===
--- ChangeLog (revision 1
> > BUILD_CFLAGS= @BUILD_CFLAGS@ -DGENERATOR_FILE
> > +BUILD_CXXFLAGS = $(INTERNAL_CFLAGS) $(CXXFLAGS) -DGENERATOR_FILE
Why are these so different?
The rest seem OK
On Tue, May 29, 2012 at 02:00:40PM -0700, Benjamin De Kosnik wrote:
>
> As per libstdc++/52700, this fixes the configure bits for
> libgfortran/libssp/libquadmath. With these fixes, I believe all the
> libs are safe for --enable-symvers=gnu* variants.
>
> Super simple patches...
>
> I intend to
Hi,
we're having issues with get_ref_base_and_extent overflowing the offset and
thus returning bogus big negative values on 32-bit hosts. The attached patch
converts it to double ints like get_inner_reference. It also contains a small
fix for build_user_friendly_ref_for_offset that can stop i
As Richard Henderson wrote:
> Instead of writing to stdout, open the file to write, and open
> it in binary mode. Seems much easier than fighting with conversion
> after the fact.
(Disclaimer: I'm not the author.)
There has been an argument that (some) older implementations might not
be able to
This patch is related to today's check.c patch, but independent (also
order wise).
The patch ensures that for scalar coarrays, the array path is taken in
trans-intrinsic. Thus, "to->data = from->data" gets replaced by "*to =
*from" such that the array bounds (and with -fcoarray=lib the token)
On 05/30/2012 05:17 AM, Georg-Johann Lay wrote:
+# The avr-mmcu.texi we want to compare against / check into svn should
+# have unix-style line endings. To make this work on MinGW, remove \r.
+# \r is not portable to Solaris tr, therefore we have a special case
+# for ASCII. We use \r for other
On Wed, May 30, 2012 at 3:47 AM, Florian Weimer wrote:
> On 05/29/2012 06:41 PM, Gabriel Dos Reis wrote:
>>
>> On Tue, May 29, 2012 at 11:00 AM, Florian Weimer
>> wrote:
>>>
>>> This patch flags operator new on variably modified types as an error.
>>> If this is acceptable, this will simplify the
The code in build_new_1 already knows how to handle an initializer that
it was unable to stabilize, but the logic was backwards in a critical
place. I'm surprised this typo hasn't been hit before since it was
introduced in 2006...
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit
As Georg-Johann Lay wrote:
> The problem was reported by Joerg. Does it work for you?
Yes, it works fine.
> + case `echo X|tr X '\101'` in\
> + A) tr -d '\015' < tmp-avr-mmcu.texi > tmp2-avr-mmcu.texi ;; \
> + *) tr -d '\r' < tmp-avr-mmcu.tex
> Yes indeed, and it would be wise to ensure torture-options.exp is
> loaded too. I'm committing the following as obvious.
Thanks
> Hmm, this will be because darwin is PIC by default. Does adding
> -static to the dg-options line in savres.c fix the darwin fail?
With the following change
--- /
This patch replaces sed with tr when t-avr checks for
consistency between generated doc/avr-mmcu.texi and the compiler.
The method is the same as used in s-tm-texi in gcc/Makefile.in
The problem was reported by Joerg. Does it work for you?
Ok for trunk?
Johann
* config/avr/t-avr: Corre
Ping.
On Tue, May 8, 2012 at 6:46 PM, Diego Novillo wrote:
>
> Found this while testing the C++ conversion for vec.[ch] on the
> cxx-conversion branch. We do not build the build/*.o files with g++,
> so I was getting lots of syntax errors while compiling build/vec.o.
>
> I am not completely sure
On 05/30/2012 11:09 AM, Tobias Burnus wrote:
This patch rejects actual arguments to MOVE_ALLOC which are coindexed
or have a corank.
Updated version (cf. below). Build and regtested on x86-64-linux.
OK for the trunk?
I asked at J3 and John Reid kindly pointed me to the pending
interpretation
On Tue, May 29, 2012 at 09:26:37PM +0200, Dominique Dhumieres wrote:
> gcc-dg-runtest [list $srcdir/$subdir/savres.c] $alti
>
> # All done.
> +torture-finish
> dg-finish
>
> is required to avoid the errors of the kind
>
> ERROR: tcl error sourcing
> /home/gccbuild/gcc_trunk_anonsvn/gcc/gcc
The patch below extents memset recognition to cover a few more
non-byte-size store loops and all byte-size store loops. This exposes
issues with our builtins.exp testsuite which has custom memset
routines like
void *
my_memset (void *d, int c, size_t n)
{
char *dst = (char *) d;
while (n--)
Dear Tobias,
That's OK for trunk.
Thanks
Paul
On 30 May 2012 11:09, Tobias Burnus wrote:
> This patch rejects actual arguments to MOVE_ALLOC which are coindexed or
> have a corank.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
--
The knack of flying is learning ho
This fixes PR53501, fold_plusminus_mult_expr does not expect that
operands have a sign-conversion stripped. So don't call it with
such arguments.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-05-30 Richard Guenther
PR middle-end/53501
* fold-const
Hi,
I've updated the patch to invoke predict_extra_loop_exits in the right
place. Attached is the new patch.
Bootstrapped and passed gcc testsuite.
Thanks,
Dehao
Index: testsuite/g++.dg/predict-loop-exit-1.C
===
--- testsuite/g++.d
Hi
This is the third part of the patches that deals with 64bit xor. It extends
the patterns xordi3, xordi3_insn and xordi3_neon to handle 64bit constant
operands.
Tested on arm qemu without regression.
OK for trunk?
thanks
Carrot
2012-05-30 Wei Guozhi
PR target/53447
* gcc.
Committed as obvious.
Richard.
2012-05-30 Richard Guenther
PR middle-end/53522
* tree-emutls.c (gen_emutls_addr): Do not add globals to
referenced-vars.
Index: gcc/tree-emutls.c
===
--- gcc/tree-emutls.c
This patch rejects actual arguments to MOVE_ALLOC which are coindexed or
have a corank.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-05-30 Tobias Burnus
* check.c (gfc_check_move_alloc): Reject coindexed actual arguments
and those with corank.
2012-05-30 Tobias Bur
It apparently got changed when the conversion to the new create_input_operand
interface was done. This restores the simple control flow of 4.6.x and stops
the compiler when the probe cannot be generated if HAVE_check_stack, instead
of silently dropping it (but no architectures HAVE_check_stack
On 05/29/2012 06:41 PM, Gabriel Dos Reis wrote:
On Tue, May 29, 2012 at 11:00 AM, Florian Weimer wrote:
This patch flags operator new on variably modified types as an error.
If this is acceptable, this will simplify the implementation of the
C++11 requirement to throw std::bad_array_new_length
On Tue, May 29, 2012 at 5:05 PM, Steven Bosscher wrote:
> Hello,
>
> Using the contrib/check_makefile_deps.sh script, I've uncovered a lot
> of missing or redundant dependencies. The attached patch fixes
> everything I've found for files up to et-forest.o. That means there
> may be much more to co
On 05/29/2012 06:45 PM, Paolo Carlini wrote:
Hi,
This patch evaluates _FORTIFY_SOURCE in a way similar to GNU libc.
If set, std::vector::operator[] throws if the index is out of bounds.
This is compliant with the standard because such usage triggers
undefined behavior. _FORTIFY_SOURCE users ex
74 matches
Mail list logo
