Changes since v8:
* Documentation changes as requested by Sandra
* 3 functional test cases added
Torsten
gcc/c-family/ChangeLog
2017-06-13 Torsten Duwe
* c-attribs.c (c_common_attribute_table): Add entry for
"patchable_function_entry".
gcc/lto/ChangeLog
2017-06-
-Wduplicated-branches can crash on a weird ObjC testcase that we haven't
managed to reduce, so no testcase attached. On that testcase, we end up
calling do_warn_duplicated_branches with null COND_EXPR_THEN, and the code
wasn't prepared to handle that. The fix is trivial. Eric G. verified that
th
James Greenhalgh writes:
>> +
>> + /* First determine number of instructions to do the move
>> +as an integer constant. */
>> +if (!aarch64_float_const_representable_p (x)
>> +&& !aarch64_can_const_movi_rtx_p (x, mode)
>> +&& aarch64_float_const_rtx_p (x))
>> +
On Tue, Jun 13, 2017 at 07:01:11PM +0200, Marek Polacek wrote:
> -Wduplicated-branches can crash on a weird ObjC testcase that we haven't
> managed to reduce, so no testcase attached. On that testcase, we end up
> calling do_warn_duplicated_branches with null COND_EXPR_THEN, and the code
> wasn't
On 09/06/17 13:53, Richard Earnshaw wrote:
>
> In order to support more complex specifications for cpus and architectures
> we need to move away from using enumerations to represent the set of
> permitted options. This basic change just moves the option parsing
> infrastructure over to that, but
On 09/06/17 13:53, Richard Earnshaw wrote:
>
> This is the main patch to provide the infrastructure for adding
> feature extensions to CPU and architecture specifications. It does not,
> however, add all the extensions that we intend to support (just a small
> number to permit some basic testing)
On 06/13/2017 02:05 AM, Richard Biener wrote:
> On Tue, Jun 13, 2017 at 2:09 AM, Iain Buclaw wrote:
>> On 13 June 2017 at 01:22, Mike Stump wrote:
>>> On Jun 12, 2017, at 11:34 AM, Richard Sandiford
>>> wrote:
I'm not sure who this is a question to really, but how much value is
t
On 09/06/17 13:53, Richard Earnshaw wrote:
>
> The driver really needs to handle some canonicalization of the new
> -mcpu and -march options in order to make multilib selection
> tractable. This will require moving much of the logic to parse the
> new options into the common code file. However,
On 09/06/17 13:53, Richard Earnshaw wrote:
>
> This patch has no functional change. The code used for parsing -mcpu,
> -mtune and -march options is simply moved from arm.c arm-common.c.
> The list of FPU options is also moved. Subsequent patches will make
> use of this within the driver.
>
> So
On 09/06/17 13:53, Richard Earnshaw wrote:
>
> This patch uses the driver and some spec rewrite rules to generate a
> canonicalized form of the -march= option. We want to do this for
> several reasons, all relating to making multi-lib selection sane.
>
> 1) It can remove redundant extension opti
-marm and -mthumb are opposites: one cancels out the other. This patch
marks them as such so that the driver will eliminate all but the last
option on the command line. This aids multilib selection which
otherwise can get confused if both are present.
* config/arm/arm.opt (marm): Mark as
This test was overriding the options that had been detected as being
necessary to enable Neon. The result was that the combination of the
test's options and those auto-detected were not compatible with neon
leading to a test failure. The correct fix here is to stick with the
options that dg-add-o
As I read it, the front end has functions with names such as error, but no
useful i18n will actually occur because the functions in d-diagnostic.cc
format the messages with xvasprintf before passing to the common
diagnostic code.
But will exgettext nevertheless extract messages from the dfronte
Presumably all of these GCC-specific files should have the GCC Runtime
Library Exception notice.
--
Joseph S. Myers
jos...@codesourcery.com
There appear to be various GPLv2 notices with old FSF addresses in here.
Where those are on source files (as opposed to generated files), they
should be updated to the usual GPLv3+ notice for GCC (and I'd expect FSF
copyright notices throughout the contributed GCC-specific files, not
"Copyrigh
On 13/06/2017 16:54, Nick Clifton wrote:
Hi Jozef,
Ok for trunk and gcc-7-branch?
Approved - please apply (to both).
Cheers
Nick
Sorry, didn't mention in that last post that I don't have write access,
could someone please apply this for me.
Thanks,
Jozef
On 12/06/2017 13:57, Jonathan Wakely wrote:
Ok to commit ?
OK, thanks.
Done yesterday.
I guess that considering the compiler bug and rare occasions for this
bug to show up we don't backport.
François
Hi Thomas,
On 13 June 2017 at 11:08, Thomas Preudhomme
wrote:
> Hi,
>
> Conditions checked for ARM targets in vector-related effective targets
> are inconsistent:
>
> * sometimes arm*-*-* is checked
> * sometimes Neon is checked
> * sometimes arm_neon_ok and sometimes arm_neon is used for neon ch
Hi,
Add support for early expansion of vector shifts. Including
vec_sl (shift left), vec_sr (shift right),
vec_sra (shift right algebraic), vec_rl (rotate left).
Part of this includes adding the vector shift right instructions to
the list of those instructions having an unsigned second argument.
On 12/05/2017 13:03, Jonathan Wakely wrote:
A much simpler (but equivalent) change would be:
--- a/libstdc++-v3/src/c++98/tree.cc
+++ b/libstdc++-v3/src/c++98/tree.cc
@@ -153,6 +153,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/* Static keyword was missing on _Rb_tree_rotate_left.
Export the sym
This patch to gotools/configure.ac fixes the build to build the tools
when host_alias = target_alias, or, in other words, when the system
for which we are building code is the same as the system where that
code will run. The earlier test of cross_compiling effectively tested
whether build_alias an
On 01/06/2017 15:34, Jonathan Wakely wrote:
I would expect the constructor to look like this:
_Bvector_impl()
_GLIBCXX_NOEXCEPT_IF( noexcept(_Bit_alloc_type()) )
: _Bit_alloc_type()
{ }
What happens when you do that?
_Bvector_impl(const _Bit_alloc_type& _
On 13 June 2017 at 19:29, Joseph Myers wrote:
> As I read it, the front end has functions with names such as error, but no
> useful i18n will actually occur because the functions in d-diagnostic.cc
> format the messages with xvasprintf before passing to the common
> diagnostic code.
>
That could
On 13 June 2017 at 19:38, Joseph Myers wrote:
> Presumably all of these GCC-specific files should have the GCC Runtime
> Library Exception notice.
>
OK, noted. I will update them.
On 13 June 2017 at 19:41, Joseph Myers wrote:
> There appear to be various GPLv2 notices with old FSF addresses in here.
> Where those are on source files (as opposed to generated files), they
> should be updated to the usual GPLv3+ notice for GCC (and I'd expect FSF
> copyright notices throughout
New "ERROR: (DejaGnu)" on mips64el target.
my DejaGnu version is 1.5.1.
1)
make check-gcc RUNTESTFLAGS="tree-ssa.exp=builtin-sprintf-2.c"
...
ERROR: (DejaGnu) proc "^:\\" does not exist.
The error code is TCL LOOKUP COMMAND ^:\\
The info on the error is:
invalid command name "^:\"
while execu
Hi Paul,
> New "ERROR: (DejaGnu)" on mips64el target.
>
> my DejaGnu version is 1.5.1.
>
> 1)
> make check-gcc RUNTESTFLAGS="tree-ssa.exp=builtin-sprintf-2.c"
> ...
> ERROR: (DejaGnu) proc "^:\\" does not exist.
> The error code is TCL LOOKUP COMMAND ^:\\
> The info on the error is:
> invalid comm
Hi!
When doing the last cp_genericize_r change, I've noticed most of the
function is a spaghetti if like:
if (TREE_CODE (stmt) == X1)
do_something;
else if (TREE_CODE (stmt) == X2)
do_something_else;
else if (TREE_CODE (stmt) == X3)
do_yet_another_stuff;
else ...
sometimes with
On Wed, Jun 14, 2017 at 07:52:10AM +0200, Rainer Orth wrote:
> both revised scan-tree-dump patterns got the quoting wrong, leading to
> attempts to run unknown procs ^\\: instead of matching [^:] ;-(
>
> This totally broke make check-gcc: the affected partial test runs
> aborted at that point, lea
101 - 129 of 129 matches
Mail list logo
