Hi!
While omit_one_operand_loc fold_converts the value to the right type,
when type is vector, it is not possible to convert that way
integer_one_node.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-01-03 Jakub Jelinek
Marc Glisse
Hi!
When one (or both) IVs have extend_mode wider than mode, but step doesn't
fit into mode (the IV is
(subreg:MODE (plus:EXTEND_MODE base (mult:EXTEND_MODE i step)) lowpart)
), such as for EXTEND_MODE SImode, MODE QImode and step e.g. 129, 128, 256
or 517, iv_number_of_iterations can create inval
On Thu, 3 Jan 2013, Jakub Jelinek wrote:
> Hi!
>
> While omit_one_operand_loc fold_converts the value to the right type,
> when type is vector, it is not possible to convert that way
> integer_one_node.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
Ok.
On Thu, 3 Jan 2013, Jakub Jelinek wrote:
> Hi!
>
> When one (or both) IVs have extend_mode wider than mode, but step doesn't
> fit into mode (the IV is
> (subreg:MODE (plus:EXTEND_MODE base (mult:EXTEND_MODE i step)) lowpart)
> ), such as for EXTEND_MODE SImode, MODE QImode and step e.g. 129, 128
On Wed, Jan 2, 2013 at 7:31 PM, Jason Merrill wrote:
> My earlier patch to force layout when re-building an array type caused
> problems because we weren't setting TYPE_NEEDS_CONSTRUCTING at the same
> time. So this attacks the problem in a different way: the underlying issue
> here is that we're
Hi,
> When one (or both) IVs have extend_mode wider than mode, but step doesn't
> fit into mode (the IV is
> (subreg:MODE (plus:EXTEND_MODE base (mult:EXTEND_MODE i step)) lowpart)
> ), such as for EXTEND_MODE SImode, MODE QImode and step e.g. 129, 128, 256
> or 517, iv_number_of_iterations can cr
On Thu, Jan 3, 2013 at 2:25 AM, Andrew Pinski wrote:
> On Wed, Jan 2, 2013 at 5:15 PM, Rong Xu wrote:
>> Hi,
>>
>> Here is a new patch. The only difference is to declare
>> __atomic_fetch_add as weak. This is
>> needed for targets without sync/atomic builtin support. The patch
>> contains a call
On Wed, Jan 2, 2013 at 5:36 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Sun, Dec 23, 2012 at 10:43 AM, Richard Sandiford
>> wrote:
>>> Some of the maths builtins can expand to a call followed by a bit
>>> of postprocessing. With 4.8's PARALLEL return optimisations, these
>>> emb
Hello!
> I've committed a patch to upgrade libgo to the current version of the
> master Go library. As usual, this mail message only includes the
> changes to files that are specific to gccgo. Bootstrapped and ran Go
> testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
This caused m
Hi!
As every year, update printed Copyright notices in various locations.
Committed to trunk.
2013-01-03 Jakub Jelinek
* gcc.c (process_command): Update copyright notice dates.
* gcov.c (print_version): Likewise.
* gcov-dump.c (print_version): Likewise.
* gfor
Hi!
I've rotated ChangeLogs where we have ChangeLog-20NN files, patch too large
for the mailing list even after bzip2, so just look at
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194840
for details.
Jakub
Hi,
On 01/02/2013 11:07 AM, Jakub Jelinek wrote:
Hi!
On Sun, Oct 28, 2012 at 12:27:40PM +0100, Paolo Carlini wrote:
--- gcc/cp/parser.c (revision 192887)
+++ gcc/cp/parser.c (working copy)
@@ -12655,9 +12655,8 @@ cp_parser_template_id (cp_parser *parser,
/* Otherwise, emit an e
If an object has a class-wide type and a renaming declaration is created for it,
the original object and the one in the renaming declaration are exchanged so
that source information is consistent. The exchange must preserve the entity
chain, which already contains generated internal types. This ens
This change fixes a defect in the visibility rules whereby a root library
unit that appears indirectly in the closure is erroneously treated as
visible if referred to using an expanded name with prefix Standard.
Root library units must be treated no different than child units for
visibility purpose
The format for the ALI file has evolved and now lists the information for both
the index and the component type for array types. However, gnatfind and
gnatxref do not correctly parse this information and consider the corresponding
line as invalid, resulting in missing references.
With the followin
Ongoing work to implement AI05-0144. No test needed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-01-03 Javier Miranda
* sem_warn.adb (Warn_On_Overlapping_Actuals): Adding documentation
plus restricting the functionality of this routine to cover the
cases des
The alignment check for an address clause must be inserted after the
object has been elaborated in the GIGI sense, but before any initialization
operation occur. This change fixes both the spec and implementation
of Apply_Address_Clause_Check to this effect (previously they disagreed,
and were both
When the GNAT driver is called with a project file and a single main
specified as an absolute path, the specific switches that are declared
for the main source were not taken into account. This patch fixes this.
The specific switches are now taken into account.
Example:
prj.gpr:
project Prj is
Ongoing work to implement AI05-0144.
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-01-03 Javier Miranda
* sem_warn.adb (Warn_On_Overlapping_Actuals): For overlapping
parameters that are record types or array types generate warnings
only compiling under -gnatw.
This change fixes the circuitry that handles record representation
clauses so that a component clause for an inherited component in
a record extension is properly rejected (such a clause is illegal
per 13.5.1(9)).
The following compilation must be rejected with the indicated error:
$ gcc -c illega
Hi,
Attached is a patch that fixes bugs in intrinsic implementation of vmovn_high_*,
vqmovn_high_* and vqmovun_high_* in arm_neon.h. This runtime bug was because of
xtn2 having the incorrect operand number for the source operand.
Tested on aarch64-none-elf. OK for trunk and 4.7?
Thanks,
Tejas
My earlier patch to avoid dead code generation for vectorized
invariant loops breaks re-align load targets as the setup is
still carried out for them.
Fixed as follows, bootstrapped and tested on x86_64-unknown-linux-gnu
and with a ppc cross.
Committed.
Richard.
2013-01-03 Richard Biener
Hello,
this trivial patch fixes a bootstrap issue on LLP64 hosts.
PR 55707
* graphite-dependences.c (hash_poly_ddr_p): Cast from pointer via
intptr_t.
Tested for x86_64-w64-mingw32 and x86_64-unknown-gnu-linux.
If OK for apply, Kai please commit.
Regards,
Rainer
Index
On Thu, Jan 3, 2013 at 1:08 PM, Rainer Emrich
wrote:
> Hello,
>
> this trivial patch fixes a bootstrap issue on LLP64 hosts.
>
> PR 55707
> * graphite-dependences.c (hash_poly_ddr_p): Cast from pointer via
> intptr_t.
>
> Tested for x86_64-w64-mingw32 and x86_64-unknown-gnu
Hello,
I happened to notice a warning while compiling GCC, and it seemed
like an easy fix...
gcc/cp/ChangeLog:
* parser.c (cp_parser_initializer_list): Move declaration
of variable non_const to start of lexical block.
Tested against x86_64-linux, no regression.
OK to commit? (ob
On Thu, Jan 3, 2013 at 1:30 PM, Joel Brobecker wrote:
> Hello,
>
> I happened to notice a warning while compiling GCC, and it seemed
> like an easy fix...
>
> gcc/cp/ChangeLog:
>
> * parser.c (cp_parser_initializer_list): Move declaration
> of variable non_const to start of lexical
This removes two calls to build_fold_indirect_ref which were only
done to later call get_name on the result. Simply build a name
in the first place instead of repeatedly doing so. It also adjusts
dumping of what kind of object we vectorize (going from terribly
wrong to most of the time wrong ...
> > Tested against x86_64-linux, no regression.
> > OK to commit? (obvious?)
>
> Hmm? We compile with a C++ compiler where this is perfectly valid ...
I was compiling with GCC 4.7 where it gave me a warning... I don't know
much about C++ anymore, so I didn't know. Oh well!
--
Joel
Hi DJ,
Since interrupts can happen at any time, it is possible for a ISR to
be called when register bank 0 is not the currently selected bank.
Hence the prologue for an interrupt handler should always select bank
0 before saving any registers. The patch below makes sure that this
happen
> Hmm? We compile with a C++ compiler where this is perfectly valid ...
Not on earlier branches though, e.g. the 4.7 branch. So I would install it
everywhere to avoid gratuitous differences.
--
Eric Botcazou
On Thu, Jan 3, 2013 at 1:37 PM, Joel Brobecker wrote:
>> > Tested against x86_64-linux, no regression.
>> > OK to commit? (obvious?)
>>
>> Hmm? We compile with a C++ compiler where this is perfectly valid ...
>
> I was compiling with GCC 4.7 where it gave me a warning... I don't know
> much about
Hi DJ,
There is a error in the RL78 G13 hardware manual. Section 14, Figure
14-3 lists the values of the MDBL registers as 4H, 5H and the
MDBH registers as 6H, 7H. This is incorrect. The correct
values are shown in Section 3, Table 3-5: MDBL => 6H, 7H,
MDBH =>
Hello,
this trivial patch fixes the bootstrap with ada on mingw targets.
The right casts fix the invalid conversion issues. Patch is against trunk.
ada/
PR 52123
* adaint.c (__gnat_check_OWNER_ACL): Cast from pointer via
SECURITY_DESCRIPTOR *
(__gnat_set_O
This patch provides the initial implementation of aspect Abstract_State. This
construct is intended for formal verification proofs.
The syntax of the aspect is as follows:
abstract_state_list::=
null
| state_name_with_properties
| (state_name_with_properties { , state
This patch avoids an overflow that occurs when tables get bigger than about 12
million elements. No change in functionality (except for enormous tables), so
no test available.
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-01-03 Bob Duff
* table.adb (Reallocate): Calculate new
On 03/01/13 11:35, Tejas Belagod wrote:
Hi,
Attached is a patch that fixes bugs in intrinsic implementation of vmovn_high_*,
vqmovn_high_* and vqmovun_high_* in arm_neon.h. This runtime bug was because of
xtn2 having the incorrect operand number for the source operand.
Tested on aarch64-none-el
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Forgot to mention, tested on x86_64-w64-mingw32 and x86_64-unknown-gnu-linux.
Am 03.01.2013 14:06, schrieb Rainer Emrich:
> Hello,
>
> this trivial patch fixes the bootstrap with ada on mingw targets. The
> right casts fix the invalid conversion issu
The testcase should have included dg-add-options tls. committed as obvious.
Index: tls-reload-1.c
===
--- tls-reload-1.c (revision 194830)
+++ tls-reload-1.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do run } */
/* { dg-requ
> "Marc" == Marc Glisse writes:
Marc> libcpp/
Marc> * line-map.c (get_combined_adhoc_loc): Cast to extern "C" type.
Yucky.
Marc> line_map_realloc reallocator
Marc> - = set->reallocator ? set->reallocator : xrealloc;
Marc> + = set->reallocator ? set->reallocator
Marc> +
On Thu, 3 Jan 2013, Richard Biener wrote:
>
> My earlier patch to avoid dead code generation for vectorized
> invariant loops breaks re-align load targets as the setup is
> still carried out for them.
>
> Fixed as follows, bootstrapped and tested on x86_64-unknown-linux-gnu
> and with a ppc cros
On Thu, 3 Jan 2013, Tom Tromey wrote:
"Marc" == Marc Glisse writes:
Marc> libcpp/
Marc>* line-map.c (get_combined_adhoc_loc): Cast to extern "C" type.
Yucky.
Yes, there is a discussion of what is necessary for a real fix (and an
alternate hack) in the PR:
http://gcc.gnu.org/bugzi
This halves the size of vect dumps for mgrid with -details. The
dataref analysis parts have too much spacing.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-01-03 Richard Biener
* tree-data-ref.c (dump_conflict_function): Use less vertical
spaci
The attached patch fixes two ICE.
Regarding the unlimited_polymorphic_3.f03 change: "null(x)" is invalid
as initialization expression (null-init). Using "ptr2 => x" would be
valid, but it ICEs. (Cf. PR55763, comment 13)
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-0
My patch for c++/48370 changed initialization of an array from a
brace-enclosed initializer list so that even when the initializer is
omitted, we were filling out the CONSTRUCTOR with the appropriate
value-initialization semantics. For a large array, this causes the
internal representation to
Hi Rainer,
applied at rev 194859.
Thanks,
Kai
On Thu, Jan 03, 2013 at 11:48:48AM -0500, Jason Merrill wrote:
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/init/array34.C
> @@ -0,0 +1,13 @@
> +// PR c++/53650
> +// We should loop over array inits if they don't involve temporaries
> +// that need extending.
> +// { dg-final { scan-assembler-times
Hi,
I checked in this patch to fix ChangeLog entry for PR lto/55466.
H.J.
---
diff --git a/gcc/ChangeLog-2012 b/gcc/ChangeLog-2012
index ae21e02..ee4c574 100644
--- a/gcc/ChangeLog-2012
+++ b/gcc/ChangeLog-2012
@@ -790,9 +790,6 @@
PR lto/55466
* lto-symtab.c (lto_symtab_merge_dec
On Wed, Jan 2, 2013 at 3:27 AM, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
>> On Tue, Dec 11, 2012 at 02:00:18PM -0800, H.J. Lu wrote:
>>> 2012-12-11 H.J. Lu
>>>
>>> * libstdc++-raw-cxx.m4 (GCC_LIBSTDCXX_RAW_CXX_FLAGS): Also
>>> AC_SUBST LIBSTDCXX_RAW_CXX_LDFLAGS.
>>
>>> --- a/c
On Sun, Dec 30, 2012 at 8:08 PM, Uros Bizjak wrote:
> On Fri, Dec 28, 2012 at 9:27 PM, Richard Henderson wrote:
>> On 12/27/2012 12:08 AM, Uros Bizjak wrote:
>>> The alternative approach is changing cpuid definition in cpuid.h (as
>>> in attached patch) to preserve %rbx, but we can't detect vario
> "Marc" == Marc Glisse writes:
Marc> Do you prefer an other approach?
No, this is fine, just yucky.
Marc> Like this? (I'll test if approved, but I am not sure what was wrong
Marc> with the indentation and parentheses so it may be wrong again)
>From the node 'Formatting' in the GCS:
Hi,
the patch below fixes PR 55755 which was in the compiler for years.
The problem is that a replacement of a bit-field can have a larger
TYPE_SIZE than the type of the field and so creating a V_C_E from it
to the field type may result in invalid gimple. We do that when we
scalarize only one sid
"H.J. Lu" writes:
> diff --git a/libjava/Makefile.am b/libjava/Makefile.am
> index c6c84e4..dd08a4f 100644
> --- a/libjava/Makefile.am
> +++ b/libjava/Makefile.am
> @@ -594,7 +594,7 @@ lib_gnu_awt_xlib_la_CPPFLAGS = \
> $(AM_CPPFLAGS) \
> $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
> ## The myster
In the original testcase, the constexpr code was getting confused by a
DECL_EXPR for a lifetime-extended temporary bound to the reference
member of the tuple.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit e9f73b2b5a67a425ae52755a6f9bebe16fc2398d
Author: Jason Merrill
Date: Th
On 01/03/2013 11:54 AM, Jakub Jelinek wrote:
I'd say safer would be to scan the gimple dump instead...
That makes sense.
commit 8a13c5cee23447467ed58bb1f213cad9050e3f87
Author: jason
Date: Thu Jan 3 18:34:48 2013 +
PR c++/53650
* g++.dg/init/array34.C: Check gimple dump, no
Richard Biener writes:
> On Wed, Jan 2, 2013 at 5:36 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Sun, Dec 23, 2012 at 10:43 AM, Richard Sandiford
>>> wrote:
Some of the maths builtins can expand to a call followed by a bit
of postprocessing. With 4.8's PARALLEL re
On Thu, Jan 3, 2013 at 10:09 AM, Andreas Schwab wrote:
> "H.J. Lu" writes:
>
>> diff --git a/libjava/Makefile.am b/libjava/Makefile.am
>> index c6c84e4..dd08a4f 100644
>> --- a/libjava/Makefile.am
>> +++ b/libjava/Makefile.am
>> @@ -594,7 +594,7 @@ lib_gnu_awt_xlib_la_CPPFLAGS = \
>> $(AM_C
David Edelsohn writes:
> The testcase should have included dg-add-options tls. committed as obvious.
Thanks. I also removed the main point of the test in a final "tweak".
Also committed as obvious after testing on mips64-linux-gnu.
Richard
gcc/testsuite/
* gcc.dg/torture/tls/tls-reloa
We need to instantiate a deferred noexcept when evaluationg
__has_nothrow_constructor.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 2b440f24a3319736c477523f65af741f97068ab6
Author: Jason Merrill
Date: Thu Jan 3 14:38:54 2013 -0500
PR c++/55842
* semantics.c (trait_
This is a bit I missed in my 55419 patch; if we aren't setting
TREE_CONSTANT on TARGET_EXPRs in the constexpr code, we can't expect it
in the template code.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit db160eb9b07b62f3696e7358c74e6d59c68385d8
Author: Jason Merrill
Date: Thu
Hello,
here is a fix for PR fortran/55827 where we had a function expression
(loaded from a module) whose symtree pointer was NULL. My attempt to
have symtree properly set got me way too far, so this is fixing the
unconditional usages of symtree based on Steve's patch in the PR. As
noted in
On 01/03/2013 05:44 AM, Paolo Carlini wrote:
+ /* C++11 - 2.5 p3, bullet 2. */
Please flesh out this comment some more.
Jason
Hi,
For aarch64, we don't CSE some cmp away. This patch fixes the case
where we are CSE across some basic-blocks like:
int f(int a, int b)
{
if(ab)
return -1;
return 0;
}
--- CUT ---
To fix this, I implemented the target hook
TARGET_FIXED_CONDITION_CODE_REGS as there was already code in
NULL with MOLD should be rejected as (default) initialization
expression. From F2008:
R506 null-init is function-reference
C512 (R506) The function-reference shall be a reference to the intrinsic
function NULL with no arguments.
"null-init" occurs twice, as "R505 initialization" in "R505
ini
The problem here is that if tmp had the correct mode, as it usually
might, we'd incorrectly discard tmp instead of assigning it to op1.
I see little point in the explicit check vs mode, since convert_to_mode
is going to do exactly that first thing. This redundant check is something
that should b
Relax the restrictions on argument types to a unique_ptr
instantiated on an array type. This patch is a backport
of Jonathan Wakely's "std::unique_ptr improvements"
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01271.html to the
google 4.7 branch.
The existing unique_ptr admits no conversions, not
On Thu, Jan 3, 2013 at 3:46 PM, Lawrence Crowl wrote:
> Relax the restrictions on argument types to a unique_ptr
> instantiated on an array type. This patch is a backport
> of Jonathan Wakely's "std::unique_ptr improvements"
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01271.html to the
> googl
The libstdc++ prettyprinter tests require a certain level of support
from GDB, and the check for that GDB support runs a command that
includes a quoted string. This causes an error from the testsuite
infrastructure for embedded processors whose board support passes
commands through additional leve
Found the problem:
The assembler generates a relocation of type LO14, meaning 14 bits
that represent bits 2 - 15 of the effective address (lowest two bits
are forced to zero), which is used for some types of 64 bit loads and
stores.
Unfortunately the OS X dynamic linker doesn't support that
On 1/1/13, Geoffrey Romer wrote:
> AFAICT there's no way to distinguish between safe and unsafe
> conversions of user-defined pointers, because that's a property
> of the pointer implementation, not the type itself. My PR errs on
> the side of trusting the implementation to provide only correct
>
Here is the new patch.
It links libatomic when -fprofile-gen-atomic is specified for FDO
instrumentation build. Here I assume libatomic is always installed.
Andrew: do you think if this is reasonable?
It also disables the functionality if target does not support weak
(ie. TARGET_SUPPORTS_WEAK ==
Hi Rong,
The following patch modifies the behaviour of the linker plugin to
not create a separate segment for cold sections by default. Separate
segments can be created with the plugin option "segment=cold". Is this
alright to commit?
Thanks,
-Sri.
On Mon, Dec 17, 2012 at 11:14 AM, Sriraman Ta
This patch clarifies the error message when using e.g. -Obar option,
except non-negative numbers we accept some other levels too.
Bootstrapped on x86_64-linux. Ok for trunk?
2013-01-04 Marek Polacek
PR middle-end/55859
* opts.c (default_options_optimization): Clarify error mes
Committed the attached change to trunk and 4.7 after testing on hppa-
unknown-linux-gnu.
Working on a revised change for 4.6.
I don't think symbol + constant can occur but I'm not absolutely sure.
On 2-Jan-13, at 8:12 AM, Richard Sandiford wrote:
In any case, reload needs to know up-front tha
Dear Mikael and Steve,
>From a quick read of your correspondence in the PR, you seem to have
covered all the angles between you.
OK for trunk.
As for the branches; yes, but how far back to go? I guess that
4.6 and 4.7 should be patched, if possible, since they are in current
use in distribu
Dear Tobias,
Hah! You are right about null(x). It is an odd constraint, though,
since all that is used is the type/kind information.
OK for trunk
Thanks for the patch.
Paul
On 3 January 2013 17:38, Tobias Burnus wrote:
> The attached patch fixes two ICE.
>
> Regarding the unlimited_polymorp
Dear Tobias,
Yes, following your previous patch that I OK'd this is clearly OK for trunk.
Thanks
Paul
On 4 January 2013 00:23, Tobias Burnus wrote:
> NULL with MOLD should be rejected as (default) initialization expression.
> From F2008:
>
> R506 null-init is function-reference
> C512 (R506) T
Is it better to change the option to something like:
split_segment|nosplit-segment
or split_segment=yes|no
David
On Thu, Jan 3, 2013 at 5:41 PM, Sriraman Tallam wrote:
> Hi Rong,
>
> The following patch modifies the behaviour of the linker plugin to
> not create a separate segment for cold s
77 matches
Mail list logo
