[C PATCH] Implement -Wc90-c99-compat (PR c/51849)
One of the prerequisites to moving the default from gnu89 to gnu11
is that we need both -Wc90-c99-compat and -Wc99-c11-compat options.
This patch implements the former. Its purpose is similar to
-Wtraditional - that people who build code in C99/C11 mode can easily
check whether the code uses something outside C90. Since
__extension__ disables this warning, features that are properly
conditioned are fine and not warned about.
As I said privately, it turned out to be convenient to reuse
pedwarn_c90 - the patch now mostly removes code. Earlier I defined
a special function, but that rendered pedwarn_c90 unused. Another
benefit I see is that if we ever add pedwarn_c90, we have
-Wc90-c99-compat handled for free. And obviously, defining yet
another warn/pedwarn function would be confusing.
A few issues: currently we don't warn (in -std=c90 -pedantic mode)
about the usage of __func__ and _Pragma (possible others - va_copy?).
I'm hoping this is not that important though. For restrict/inline,
in GNU90 mode we just don't compile the code at all (unless we use
__restrict and similar), and -Wc90-c99-compat does not warn about those.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2014-07-31 Marek Polacek
PR c/51849
gcc/
* gcc/doc/invoke.texi: Document -Wc90-c99-compat.
gcc/c-family/
* c-opts.c (sanitize_cpp_opts): Pass warn_c90_c99_compat to libcpp.
* c.opt (Wc90-c99-compat): Add option.
gcc/c/
* c-decl.c (build_array_declarator): Remove check for !flag_isoc99.
Call pedwarn_c90 instead of pedwarn.
(check_bitfield_type_and_width): Likewise.
(declspecs_add_qual): Likewise.
(declspecs_add_type): Likewise.
(warn_variable_length_array): Unify function for -pedantic and -Wvla.
Adjust to only call pedwarn_c90.
(grokdeclarator): Remove pedantic && !flag_isoc99 check. Call
pedwarn_c90 instead of pedwarn.
* c-errors.c (pedwarn_c90): Handle -Wc90-c99-compat.
* c-parser.c (disable_extension_diagnostics): Handle
warn_c90_c99_compat.
(restore_extension_diagnostics): Likewise.
(c_parser_enum_specifier): Remove check for !flag_isoc99. Call
pedwarn_c90 instead of pedwarn.
(c_parser_initelt): Likewise.
(c_parser_postfix_expression): Likewise.
(c_parser_postfix_expression_after_paren_type): Likewise.
(c_parser_compound_statement_nostart): Remove check for !flag_isoc99.
* c-tree.h: Fix formatting.
* c-typeck.c (build_array_ref): Remove check for !flag_isoc99. Call
pedwarn_c90 instead of pedwarn.
gcc/testsuite/
* gcc.dg/Wc90-c99-compat-1.c: New test.
* gcc.dg/Wc90-c99-compat-2.c: New test.
* gcc.dg/Wc90-c99-compat-3.c: New test.
* gcc.dg/Wc90-c99-compat-4.c: New test.
* gcc.dg/Wc90-c99-compat-5.c: New test.
* gcc.dg/Wc90-c99-compat-6.c: New test.
* gcc.dg/wvla-1.c: Adjust dg-warning.
* gcc.dg/wvla-2.c: Adjust dg-warning.
* gcc.dg/wvla-4.c: Adjust dg-warning.
* gcc.dg/wvla-6.c: Adjust dg-warning.
libcpp/
* lex.c (_cpp_lex_direct): Warn when -Wc90-c99-compat is in effect.
* charset.c (_cpp_valid_ucn): Likewise.
* include/cpplib.h (cpp_options): Add cpp_warn_c90_c99_compat.
* macro.c (replace_args): Warn when -Wc90-c99-compat is in effect.
(parse_params): Likewise.
diff --git gcc/gcc/c-family/c-opts.c gcc/gcc/c-family/c-opts.c
index 3f8e6e6..43a8b9d 100644
--- gcc/gcc/c-family/c-opts.c
+++ gcc/gcc/c-family/c-opts.c
@@ -1295,6 +1295,7 @@ sanitize_cpp_opts (void)
cpp_opts->unsigned_char = !flag_signed_char;
cpp_opts->stdc_0_in_system_headers = STDC_0_IN_SYSTEM_HEADERS;
cpp_opts->warn_date_time = cpp_warn_date_time;
+ cpp_opts->cpp_warn_c90_c99_compat = warn_c90_c99_compat;
/* Wlong-long is disabled by default. It is enabled by:
[-Wpedantic | -Wtraditional] -std=[gnu|c]++98 ; or
diff --git gcc/gcc/c-family/c.opt gcc/gcc/c-family/c.opt
index f427da1..b62bac1 100644
--- gcc/gcc/c-family/c.opt
+++ gcc/gcc/c-family/c.opt
@@ -291,6 +291,10 @@ Wbuiltin-macro-redefined
C ObjC C++ ObjC++ Warning
Warn when a built-in preprocessor macro is undefined or redefined
+Wc90-c99-compat
+C ObjC Var(warn_c90_c99_compat) Warning
+Warn about features not present in ISO C90, but present in ISO C99
+
Wc++-compat
C ObjC Var(warn_cxx_compat) Warning
Warn about C constructs that are not in the common subset of C and C++
diff --git gcc/gcc/c/c-decl.c gcc/gcc/c/c-decl.c
index 2a4b439..b1c5862 100644
--- gcc/gcc/c/c-decl.c
+++ gcc/gcc/c/c-decl.c
@@ -3968,16 +3968,13 @@ build_array_declarator (location_t loc,
}
declarator->u.array.static_p = static_p;
declarator->u.array.vla_unspec_p = vla_unspec_p;
- if (!flag_isoc99)
-{
- if (static_p || quals != NULL)
- pedwarn (loc, OPT_Wpedantic,
+ if (static_p || quals != NULL)
+pedwarn_c90 (loc, OPT_Wpedantic,
"I
[PATCH][LTO] Move and rename data streamer stuff
This renames lto_output_data_stream to streamer_write_data_stream
and moves it, together with lto_append_block, to data-streamer-out.[ch]
where it belongs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-07-31 Richard Biener
* data-streamer.h (streamer_write_data_stream): Declare here,
renamed from ...
* lto-streamer.h (lto_output_data_stream): ... this. Remove.
* lto-cgraph.c (lto_output_node): Adjust.
(lto_output_varpool_node): Likewise.
* data-streamer-out.c (streamer_string_index): Likewise.
(streamer_write_data_stream, lto_append_block): Move from ...
* lto-section-out.c (lto_output_data_stream,
lto_append_block): ... here.
Index: gcc/data-streamer.h
===
*** gcc/data-streamer.h (revision 213253)
--- gcc/data-streamer.h (working copy)
*** void streamer_write_uhwi_stream (struct
*** 70,75
--- 70,77
unsigned HOST_WIDE_INT);
void streamer_write_hwi_stream (struct lto_output_stream *, HOST_WIDE_INT);
void streamer_write_gcov_count_stream (struct lto_output_stream *, gcov_type);
+ void streamer_write_data_stream (struct lto_output_stream *, const void *,
+size_t);
/* In data-streamer-in.c */
const char *string_for_index (struct data_in *, unsigned int, unsigned int *);
Index: gcc/lto-streamer.h
===
*** gcc/lto-streamer.h (revision 213253)
--- gcc/lto-streamer.h (working copy)
*** extern void lto_begin_section (const cha
*** 779,786
extern void lto_end_section (void);
extern void lto_write_data (const void *, unsigned int);
extern void lto_write_stream (struct lto_output_stream *);
- extern void lto_output_data_stream (struct lto_output_stream *, const void *,
- size_t);
extern bool lto_output_decl_index (struct lto_output_stream *,
struct lto_tree_ref_encoder *,
tree, unsigned int *);
--- 779,784
Index: gcc/lto-cgraph.c
===
*** gcc/lto-cgraph.c(revision 213253)
--- gcc/lto-cgraph.c(working copy)
*** lto_output_node (struct lto_simple_outpu
*** 488,494
comdat = IDENTIFIER_POINTER (group);
else
comdat = "";
! lto_output_data_stream (ob->main_stream, comdat, strlen (comdat) + 1);
if (group)
{
--- 488,494
comdat = IDENTIFIER_POINTER (group);
else
comdat = "";
! streamer_write_data_stream (ob->main_stream, comdat, strlen (comdat) + 1);
if (group)
{
*** lto_output_node (struct lto_simple_outpu
*** 546,552
bp_pack_enum (&bp, ld_plugin_symbol_resolution,
LDPR_NUM_KNOWN, node->resolution);
streamer_write_bitpack (&bp);
! lto_output_data_stream (ob->main_stream, section, strlen (section) + 1);
if (node->thunk.thunk_p && !boundary_p)
{
--- 546,552
bp_pack_enum (&bp, ld_plugin_symbol_resolution,
LDPR_NUM_KNOWN, node->resolution);
streamer_write_bitpack (&bp);
! streamer_write_data_stream (ob->main_stream, section, strlen (section) + 1);
if (node->thunk.thunk_p && !boundary_p)
{
*** lto_output_varpool_node (struct lto_simp
*** 622,628
comdat = IDENTIFIER_POINTER (group);
else
comdat = "";
! lto_output_data_stream (ob->main_stream, comdat, strlen (comdat) + 1);
if (group)
{
--- 622,628
comdat = IDENTIFIER_POINTER (group);
else
comdat = "";
! streamer_write_data_stream (ob->main_stream, comdat, strlen (comdat) + 1);
if (group)
{
*** lto_output_varpool_node (struct lto_simp
*** 640,646
section = node->get_section ();
if (!section)
section = "";
! lto_output_data_stream (ob->main_stream, section, strlen (section) + 1);
streamer_write_enum (ob->main_stream, ld_plugin_symbol_resolution,
LDPR_NUM_KNOWN, node->resolution);
--- 640,646
section = node->get_section ();
if (!section)
section = "";
! streamer_write_data_stream (ob->main_stream, section, strlen (section) + 1);
streamer_write_enum (ob->main_stream, ld_plugin_symbol_resolution,
LDPR_NUM_KNOWN, node->resolution);
Index: gcc/data-streamer-out.c
===
*** gcc/data-streamer-out.c (revision 213253)
--- gcc/data-streamer-out.c (working copy)
*** along with GCC; see the file COPYING3.
*** 32,37
--- 32,80
#include "gimple.h"
#include "data-streamer.h"
+
+ /* Adds a new block to output stream OBS. */
+
+ void
+ lto_append_block (struct lto_output_stream *obs)
+ {
+ struct lto_char
Re: [PATCH 5/5] add libcc1
On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law wrote: > On 06/19/14 14:52, Tom Tromey wrote: >> >> Tom> I've edited this one down by removing the auto-generated stuff , and >> Tom> then compressed it. >> >> Here's a new version of patch #5. >> I've removed the generated code; let's see if it gets through without >> compression. >> >> I think this addresses all the reviews: >> >> * It uses gcc-plugin.m4 to disable the plugin >> * It does some configure checks for needed functionality, and disables >>the plugin if they are not found >> * libcc1 and the plugin now do a protocol version handshake at >>startup >> * The diagnostic overriding code is now in the plugin, not in gcc proper >> * gdb now tells libcc1 about the target triplet, and libcc1 uses >>this to invoke the proper GCC. This is done by (ewww) searching $PATH. >> >> Tom >> >> 2014-06-19 Phil Muldoon >> Tom Tromey >> >> * Makefile.def: Add libcc1 to host_modules. >> * configure.ac (host_tools): Add libcc1. >> * Makefile.in, configure: Rebuild. >> >> 2014-06-19 Phil Muldoon >> Jan Kratochvil >> Tom Tromey >> >> * aclocal.m4: New file. >> * callbacks.cc: New file. >> * callbacks.hh: New file. >> * cc1plugin-config.h.in: New file. >> * configure: New file. >> * configure.ac: New file. >> * connection.cc: New file. >> * connection.hh: New file. >> * findcomp.cc: New file. >> * findcomp.hh: New file. >> * libcc1.cc: New file. >> * libcc1plugin.sym: New file. >> * libcc1.sym: New file. >> * Makefile.am: New file. >> * Makefile.in: New file. >> * marshall.cc: New file. >> * marshall.hh: New file. >> * names.cc: New file. >> * names.hh: New file. >> * plugin.cc: New file. >> * rpc.hh: New file. >> * status.hh: New file. > > So my biggest concern here is long term maintenance -- who's going to own > care and feeding of these bits over time. > > My inclination is to go ahead and approve, but explicitly note that if the > bits do start to rot that we'll be fairly aggressive at disabling/removing > them. > > Now that my position is out there for everyone to see, give the other > maintainers a few days (say until Monday) to chime in with any objections. > > Obviously if there are no objections and you check in the change, please be > on the lookout for any fallout. I'm particularly concerned about AIX, > Solaris and other non-linux platforms. > > Does this deserve a mention in the news file? Can you briefly elaborate on how this relates to the JIT work from David Malcom? Also during the GCC Summit we talked about JIT and plugins and I mentioned that the JIT API is actually a kind of "stable plugin API" for IL creation. We've also elaborated on why the JIT cannot be a "plugin" at the moment - which is at least partly because we cannot have "frontend plugins". This is because compilation is currently driven by the frontend which "owns" main() even though it immediately calls into the middle-end and only gets control back via langhooks. So a quite obvious cleanup of the program flow of GCC would be to drive things from a middle-end main() - which would allow a plugin to take over the frontend parts (and which would allow making all frontends shared objects, aka "plugins" to a common middle-end "driver"). Just throwing in my mental notes from the Summit here. I really wonder how libcc1 falls in into this picture and if it would stand in the way of re-organizing main program flow and/or making frontends shared objects. [ideally both frontends and targets would be shared objects, but of course even frontends have target dependencies pulled in via target macros at the moment...] Richard. > Jeff >
Re: [GSoC] type of an isl_ast_expr_id
On 31/07/2014 08:19, Roman Gareev wrote: Could you please advise me how is it better to answer the following questions of Sven: In what way is it "not optimal"? That is, what are your optimality criteria? (I could answer them, but I don't want to miss anything) Don't worry. Just give it a shot. ;-) (I even don't understand the question in this case. Not having conditions in the loops reduces control overhead, while in this case it does not seem to come with code size growth either.) Tobias
Re: [PATCH] Fix PR56426
On 25-02-13 20:53, Marek Polacek wrote:
2013-02-25 Marek Polacek
PR tree-optimization/56426
* tree-ssa-loop.c (tree_ssa_loop_init): Always call
scev_initialize.
* gcc.dg/pr56436.c: New test.
--- gcc/tree-ssa-loop.c.mp 2013-02-25 13:06:47.212132327 +0100
+++ gcc/tree-ssa-loop.c 2013-02-25 20:09:30.668978936 +0100
@@ -70,10 +70,13 @@ tree_ssa_loop_init (void)
| LOOPS_HAVE_RECORDED_EXITS);
rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
+ /* We might discover new loops, e.g. when turning irreducible
+ regions into reducible. */
+ scev_initialize ();
+
if (number_of_loops () <= 1)
return 0;
- scev_initialize ();
return 0;
}
Marek,
moving scev_initialize up leaves the if-clause as dead code. This patches
removes that dead code. Bootstrapped and reg-tested with tree-ssa.exp.
Committed as trivial.
Thanks,
- Tom
2014-07-30 Tom de Vries
* tree-ssa-loop.c (pass_tree_loop_init::execute): Remove dead code.
diff --git a/gcc/tree-ssa-loop.c b/gcc/tree-ssa-loop.c
index 7c52748..d0c9980 100644
--- a/gcc/tree-ssa-loop.c
+++ b/gcc/tree-ssa-loop.c
@@ -168,7 +168,7 @@ public:
}; // class pass_tree_loop_init
unsigned int
-pass_tree_loop_init::execute (function *fun)
+pass_tree_loop_init::execute (function *fun ATTRIBUTE_UNUSED)
{
loop_optimizer_init (LOOPS_NORMAL
| LOOPS_HAVE_RECORDED_EXITS);
@@ -178,9 +178,6 @@ pass_tree_loop_init::execute (function *fun)
regions into reducible. */
scev_initialize ();
- if (number_of_loops (fun) <= 1)
-return 0;
-
return 0;
}
Re: [GSoC][match-and-simplify] split match.pd
On Wed, Jul 30, 2014 at 7:54 PM, Prathamesh Kulkarni wrote: > I have split match.pd in this patch. > Not sure if I have written the ChangeLog correctly though... > > * match-bitwise.pd: New file. > * match-plusminus.pd: Likewise. > * match-constant-folding.pd: Likewise. > * match-builtin.pd: Likewise. > * match-rotate.pd): New file. > Adjust to use wi::eq_p and wi::add. > > * (match.pd): Move plus-minus patterns to ... > (match-pluminus.pd): ... here. > Move bitwise paterns to ... > (match-bitwise.pd): ... here. > Move constant folding patterns to ... > (match-constant-folding.pd): ... here. > Move patterns on built-in functions to ... > (match-builtin.pd): ... here. > Move rotate patterns to ... > (match-rotate.pd): ... here. > Include match-plusminus.pd. > Include match-bitwise.pd. > Include match-constant-folding.pd. > Include match-builtin.pd. > Include match-rotate.pd. Thanks - I simplified the ChangeLog to * match-bitwise.pd: New file, split out from match.pd. * match-plusminus.pd: Likewise. * match-constant-folding.pd: Likewise. * match-builtin.pd: Likewise. * match-rotate.pd: Likewise. * match.pd: Move contend to individual files based on pattern origin and include them. Committed. Richard. > Thanks, > Prathamesh
Re: [GSoC][match-and-simplify] split match.pd
On Thu, 31 Jul 2014, Richard Biener wrote: * match-bitwise.pd: New file, split out from match.pd. * match-plusminus.pd: Likewise. * match-constant-folding.pd: Likewise. * match-builtin.pd: Likewise. * match-rotate.pd: Likewise. * match.pd: Move contend to individual files based on pattern origin and include them. If we are going to have many files, how about creating a subdirectory so match-rotate.pd would become match/rotate.pd? Makefile could even pick all the *.pd files in that directory so we don't have to include them manually. -- Marc Glisse
RE: [PATCH] PR61868
Thanks, Jeff. Checked in. Bingfeng > -Original Message- > From: Jeff Law [mailto:l...@redhat.com] > Sent: 31 July 2014 04:43 > To: Bingfeng Mei; Richard Biener > Cc: Andi Kleen; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] PR61868 > > On 07/30/14 09:20, Bingfeng Mei wrote: > > Yes, that fix is better. Here are updated patches. LTO-bootstrapped > and tested. OK? > > > > Bingfeng > > > > Index: ChangeLog > > === > > --- ChangeLog (revision 213152) > > +++ ChangeLog (working copy) > > @@ -1,3 +1,10 @@ > > +2014-07-29 Bingfeng Mei > > + > > + PR lto/61868 > > + * toplev.c (init_random_seed): Move piece of code never called > to > > + set_random_seed. > > + (set_random_seed): see above. > > + > > 2014-07-28 Jan Hubicka > OK for the trunk. > > Thanks, > Jeff
Re: [GSoC][match-and-simplify] split match.pd
On Thu, Jul 31, 2014 at 10:51 AM, Marc Glisse wrote: > On Thu, 31 Jul 2014, Richard Biener wrote: > >>* match-bitwise.pd: New file, split out from match.pd. >>* match-plusminus.pd: Likewise. >>* match-constant-folding.pd: Likewise. >>* match-builtin.pd: Likewise. >>* match-rotate.pd: Likewise. >>* match.pd: Move contend to individual files based on >>pattern origin and include them. > > > If we are going to have many files, how about creating a subdirectory so > match-rotate.pd would become match/rotate.pd? Makefile could even pick all > the *.pd files in that directory so we don't have to include them manually. We can decide this at branch-merge time. For now it's just making easier to match existing code and patterns. That is, I don't know if the many-files will persist. Richard. > -- > Marc Glisse
[Ada] Excluded checked on unchecked unions
Checks that would read the value of a discriminant are suppressed on types
that are unchecked unions. If such a record has components whose types have
invariants, applying those checks would require determining the variant in
which they reside, and this cannot be done on an unchecked union. THis patch
recognizes such cases and warns that there are no invariant checks on the
components of the record.
Compiling unc_rec.ads must yield:
cannot generate code for file unc_rec.ads (package spec)
unc_rec.ads:12:24: warning:
invariants cannot be checked on components of unchecked_union type "Rec"
---
package Unc_Rec is
type Comp is private
with Invariant => Comp_OK (Comp);
type Rec (<>) is private;
function Comp_OK (It : Comp) return Boolean;
private
type Comp is new Float;
type Rec (Flag : Boolean) is record
case Flag is
when True => Val : Integer;
when False => Weight : Comp;
end case;
end record;
pragma Unchecked_Union (Rec);
end;
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Ed Schonberg
* exp_ch3.adb (Build_Invariant_Checks): If the enclosing record
is an unchecked_union, warn that invariants will not be checked
on components that have them.
Index: exp_ch3.adb
===
--- exp_ch3.adb (revision 213322)
+++ exp_ch3.adb (working copy)
@@ -3763,8 +3763,16 @@
if Has_Invariants (Etype (Id))
and then In_Open_Scopes (Scope (R_Type))
then
- Append_To (Stmts, Build_Component_Invariant_Call (Id));
+ if Has_Unchecked_Union (R_Type) then
+ Error_Msg_NE
+ ("invariants cannot be checked on components of "
+ & "unchecked_union type&?", Decl, R_Type);
+ return Empty_List;
+ else
+ Append_To (Stmts, Build_Component_Invariant_Call (Id));
+ end if;
+
elsif Is_Access_Type (Etype (Id))
and then not Is_Access_Constant (Etype (Id))
and then Has_Invariants (Designated_Type (Etype (Id)))
[Ada] Correct failure to detect Invariant'Class for untagged type
This fixes a problem with B test ND11001. There were actually three
problems reported
a) Bad use of Default_Component_Value, but this had already been
previously fixed.
b) Bad use of Invariant'Class, fixed as part of this patch
c) Failure to detect bad aspect on null body. This was actually
an issue of not detecting this after a previous error (i.e. a
B test splitting issue), but as part of this patch, this error
is now properly caught even if there are previous errors, which
avoids the need to split the test.
The following shows the three reported cases properly caught
and diagnosed (compiled with -gnatq -gnatld7 -gnatj55):
1. procedure BadAsp is
2.package P1 is
3. type Arr is private with
|
>>> aspect Default_Component_Value can only
apply to an array of scalar components
4. Default_Component_Value => 1;
5.private
6. type Arr is array (1 .. 10) of Integer;
7.end;
8.
9.package P2 is
10. type Rec is private with
11. Type_Invariant'Class => True;
|
>>> Type_Invariant'Class cannot be specified
for "Rec", can only be specified for a
tagged type
12.private
13. type Rec is null record;
14.end;
15.
16.package p3 is
17. type Priv is tagged null record;
18. procedure Prim1 (A : in out Priv);
19.end;
20.
21.package body P3 is
22. procedure Prim1 (A : in out Priv) is null
23. with Post'Class => True;
|
>>> aspect specification must appear in
subprogram declaration
24.end;
25.
26. begin
27.null;
28. end;
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Robert Dewar
* freeze.adb (Freeze_Entity): Check for error of
Type_Invariant'Class applied to a untagged type.
* sem_ch6.adb (Analyze_Null_Procedure): Unconditionally rewrite
as null body, so that we perform error checks even if expansion
is off.
Index: freeze.adb
===
--- freeze.adb (revision 213289)
+++ freeze.adb (working copy)
@@ -4537,6 +4537,24 @@
return No_List;
end if;
+ -- Check for error of Type_Invariant'Class applied to a untagged type
+ -- (check delayed to freeze time when full type is available).
+
+ declare
+Prag : constant Node_Id := Get_Pragma (E, Pragma_Invariant);
+ begin
+if Present (Prag)
+ and then Class_Present (Prag)
+ and then not Is_Tagged_Type (E)
+then
+ Error_Msg_NE
+ ("Type_Invariant''Class cannot be specified for &",
+ Prag, E);
+ Error_Msg_N
+ ("\can only be specified for a tagged type", Prag);
+end if;
+ end;
+
-- Deal with special cases of freezing for subtype
if E /= Base_Type (E) then
Index: sem_ch6.adb
===
--- sem_ch6.adb (revision 213300)
+++ sem_ch6.adb (working copy)
@@ -1391,19 +1391,14 @@
end if;
else
- -- The null procedure is a completion
+ -- The null procedure is a completion. We unconditionally rewrite
+ -- this as a null body (even if expansion is not active), because
+ -- there are various error checks that are applied on this body
+ -- when it is analyzed (e.g. correct aspect placement).
Is_Completion := True;
-
- if Expander_Active then
-Rewrite (N, Null_Body);
-Analyze (N);
-
- else
-Designator := Analyze_Subprogram_Specification (Spec);
-Set_Has_Completion (Designator);
-Set_Has_Completion (Prev);
- end if;
+ Rewrite (N, Null_Body);
+ Analyze (N);
end if;
end Analyze_Null_Procedure;
Re: Patch for constexpr variable templates
Here's an updated patch with cp_parser_id_expression instantiating the
variable templates if this is indeed what we want to do.
The previous implementation did seem to make the distinction between
static template class member variables and variable templates a bit more
obvious. See the first change to check_explicit_specialization.
Related to that, grokvardecl might be using build_lang_decl more often
than it did previously. I might be able to narrow that down a little,
but I'm not sure.
- Braden Obrzut
2014-07-31 Braden Obrzut
* decl.c (grokvardecl): Handle specializations of variable templates.
(grokdeclarator): Handle variable template id expressions and NULL_TREE
return from grokvardecl.
* decl2.c (check_member_template): Allow declaration of template member
variables.
* parser.c (make_id_declarator): Accept VAR_DECL for variable
templates.
(cp_parser_template_id): Handle variable templates and return a
VAR_DECL.
(cp_parser_lookup_name): May now be passed a VAR_DECL which is already
resolved.
* pt.c (determine_specialization): Accept variable templates.
(check_template_variable): Fixed wanted template header count and
change non static data member error to variable template warning.
(check_explicit_specialization): Handle variable templates.
(lookup_template_variable): New.
(tsubst_decl): Handle variable template specializations.
(do_decl_instantiation): Handle template variables.
(instantiate_decl): Handle template variables.
* semantics.c (finish_template_variable): New.
2014-07-31 Braden Obrzut
* g++.dg/cpp1y/var-templ1.C: New.
* g++.dg/cpp1y/var-templ2.C: New.
* g++.dg/cpp1y/var-templ3.C: New.
* g++.dg/cpp1y/var-templ4.C: New.
* g++.dg/cpp1y/var-templ5.C: New.
* g++.dg/cpp1y/pr59638.C: Marked xfail for template variables as
function pointers taking auto are considered templates at the moment.
* g++.dg/parse/error50.C: Malformed statements look like variable
templ.
* g++.dg/template/crash71.C: Looks like variable templ.
* g++.old-deja/g++.oliva/template10.C: Looks like variable templ.
* g++.old-deja/g++.pt/var1.C: Non-constexpr variable templ.
2013-03-29 Gabriel Dos Reis
* cp-tree.h (variable_template_p): Do not check scope.
* pt.c (check_template_variable): Fix thinko from previous change.
(push_template_decl_real): Fix formatting.
2013-03-29 Gabriel Dos Reis
* cp-tree.h (variable_template_p): New.
* pt.c (check_template_variable): Accept variable temploids at
non-class scope.
(push_template_decl_real): The current instantiation of a template
can be a VAR_DECL.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 4a5cb98..c6c 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5027,6 +5027,17 @@ class_of_this_parm (const_tree fntype)
return TREE_TYPE (type_of_this_parm (fntype));
}
+/* True if T designates a variable template declaration. */
+inline bool
+variable_template_p (tree t)
+{
+ if (TREE_CODE (t) != TEMPLATE_DECL)
+return false;
+ if (tree r = DECL_TEMPLATE_RESULT (t))
+return VAR_P (r);
+ return false;
+}
+
/* A parameter list indicating for a function with no parameters,
e.g "int f(void)". */
extern cp_parameter_declarator *no_parameters;
@@ -5554,6 +5565,7 @@ extern bool redeclare_class_template (tree, tree);
extern tree lookup_template_class (tree, tree, tree, tree,
int, tsubst_flags_t);
extern tree lookup_template_function (tree, tree);
+extern tree lookup_template_variable (tree, tree);
extern int uses_template_parms (tree);
extern int uses_template_parms_level (tree, int);
extern bool in_template_function (void);
@@ -5816,6 +5828,7 @@ extern tree perform_koenig_lookup (tree, vec *,
tsubst_flags_t);
extern tree finish_call_expr (tree, vec **, bool,
bool, tsubst_flags_t);
+extern tree finish_template_variable (tree);
extern tree finish_increment_expr (tree, enum tree_code);
extern tree finish_this_expr (void);
extern tree finish_pseudo_destructor_expr (tree, tree, tree, location_t);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index dae85c2..c9c36d8 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -80,8 +80,8 @@ static int ambi_op_p (enum tree_code);
static int unary_op_p (enum tree_code);
static void push_local_name (tree);
static tree grok_reference_init (tree, tree, tree, int);
-static tree grokvardecl (tree, tree, const cp_decl_specifier_seq *,
- int, int, tree);
+static tree grokvardecl (tree, tree, tree, const cp_decl_specifier_seq *,
+ int, int, int, tree);
static int check_static_variable_definition (tree, tree);
static void record_unknown_type (tree, const char *);
static tree builtin_function_1 (tree, tree, bool);
@@ -7943,9 +7943,11 @@ set_linkage_for_static_data_member (tree decl)
static tree
grokvardecl (tree type,
tree name,
+ tree orig_declarator,
const cp_dec
[Ada] Overflow checking is now on by default
All previous versions of GNAT have set overflow checking off by default (with -gnato switches to enable overflow checking). This update sets the default to checking on, and implements a new switch -gnato0 to turn overflow checking on. The old switch -gnato, which used to enable overflow checking can still be used but simply sets the default, so normally has no effect. The following program: 1. procedure OvTest is 2.A : Integer; 3.function Ident (X : Integer) return Integer is 4.begin 5. return X; 6.end; 7. begin 8.A := Ident (Integer'Last) + 1; 9. end; raises an exception: raised CONSTRAINT_ERROR : ovtest.adb:8 overflow check failed if compiled with no options or with -gnato, and runs silently if compiled with -gnato0. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-31 Robert Dewar * gnat1drv.adb (Adjust_Global_Switches): Default for overflow checking is enabled except in GNAT_Mode. * switch-c.adb (Scan_Front_End_Switches): Implement -gnato0 (suppress overflow checks). Index: switch-c.adb === --- switch-c.adb(revision 213263) +++ switch-c.adb(working copy) @@ -953,38 +953,57 @@ when 'o' => Ptr := Ptr + 1; - Suppress_Options.Suppress (Overflow_Check) := False; - -- Case of no digits after the -gnato + -- Case of -gnato0 (overflow checking turned off) - if Ptr > Max or else Switch_Chars (Ptr) not in '1' .. '3' then + if Ptr <= Max and then Switch_Chars (Ptr) = '0' then + Ptr := Ptr + 1; + Suppress_Options.Suppress (Overflow_Check) := True; + + -- We set strict mode in case overflow checking is turned + -- on locally (also records that we had a -gnato switch). + Suppress_Options.Overflow_Mode_General:= Strict; Suppress_Options.Overflow_Mode_Assertions := Strict; - -- At least one digit after the -gnato + -- All cases other than -gnato0 (overflow checking turned on) else - -- Handle first digit after -gnato + Suppress_Options.Suppress (Overflow_Check) := False; - Suppress_Options.Overflow_Mode_General := -Get_Overflow_Mode (Switch_Chars (Ptr)); - Ptr := Ptr + 1; + -- Case of no digits after the -gnato - -- Only one digit after -gnato, set assertions mode to - -- be the same as general mode. - if Ptr > Max or else Switch_Chars (Ptr) not in '1' .. '3' then - Suppress_Options.Overflow_Mode_Assertions := - Suppress_Options.Overflow_Mode_General; + Suppress_Options.Overflow_Mode_General:= Strict; + Suppress_Options.Overflow_Mode_Assertions := Strict; - -- Process second digit after -gnato + -- At least one digit after the -gnato else - Suppress_Options.Overflow_Mode_Assertions := + -- Handle first digit after -gnato + + Suppress_Options.Overflow_Mode_General := Get_Overflow_Mode (Switch_Chars (Ptr)); Ptr := Ptr + 1; + + -- Only one digit after -gnato, set assertions mode to be + -- the same as general mode. + + if Ptr > Max + or else Switch_Chars (Ptr) not in '1' .. '3' + then +Suppress_Options.Overflow_Mode_Assertions := + Suppress_Options.Overflow_Mode_General; + + -- Process second digit after -gnato + + else +Suppress_Options.Overflow_Mode_Assertions := + Get_Overflow_Mode (Switch_Chars (Ptr)); +Ptr := Ptr + 1; + end if; end if; end if; @@ -1026,6 +1045,13 @@ Validity_Checks_On := False; Opt.Suppress_Checks := True; + + -- Set overflow mode checking to strict in case it gets + -- turned on locally (also signals that overflow checking + -- has been specifically turned off). + + Suppress_Options.Overflow_Mode_General:= Strict; + Suppress_Options.Overflow_Mode_Assertions := Strict; end if; -- -gnatP (periodic poll) Index: gnat1drv.adb === --- gnat1drv.adb
[Ada] Do not fail program when runtime dir cannot be found
When a runtime specified as a relative or full path in package Builder
of the main project, instead of failing the program immediately, the
Project Manager raises an exception.
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Vincent Celier
* prj-pars.adb, prj-conf.ads, prj-conf.adb (Locate_Runtime): Move spec
to package body, as it is not called from outside. Remove argument
Project_Tree, no longer used. When runtime cannot be found,
call Raise_Invalid_Config instead of failing the program.
Index: prj-conf.adb
===
--- prj-conf.adb(revision 213263)
+++ prj-conf.adb(working copy)
@@ -64,6 +64,14 @@
-- Stores the runtime names for the various languages. This is in general
-- set from a --RTS command line option.
+ procedure Locate_Runtime
+ (Language : Name_Id;
+ Env : Prj.Tree.Environment);
+ -- If RTS_Name is a base name (a name without path separator), then
+ -- do nothing. Otherwise, convert it to an absolute path (possibly by
+ -- searching it in the project path) and call Set_Runtime_For with the
+ -- absolute path. Raise Invalid_Config if the path does not exist.
+
---
-- Local_Subprograms --
---
@@ -721,7 +729,7 @@
Set_Runtime_For
(Name_Ada,
Name_Buffer (7 .. Name_Len));
- Locate_Runtime (Name_Ada, Project_Tree, Env);
+ Locate_Runtime (Name_Ada, Env);
end if;
elsif Name_Len > 7
@@ -748,7 +756,7 @@
if not Runtime_Name_Set_For (Lang) then
Set_Runtime_For (Lang, RTS);
-Locate_Runtime (Lang, Project_Tree, Env);
+Locate_Runtime (Lang, Env);
end if;
end;
end if;
@@ -1518,7 +1526,6 @@
procedure Locate_Runtime
(Language : Name_Id;
- Project_Tree : Prj.Project_Tree_Ref;
Env : Prj.Tree.Environment)
is
function Is_Base_Name (Path : String) return Boolean;
@@ -1555,7 +1562,7 @@
Find_Rts_In_Path (Env.Project_Path, RTS_Name);
if Full_Path = null then
-Fail_Program (Project_Tree, "cannot find RTS " & RTS_Name);
+Raise_Invalid_Config ("cannot find RTS " & RTS_Name);
end if;
Set_Runtime_For (Language, Normalize_Pathname (Full_Path.all));
Index: prj-conf.ads
===
--- prj-conf.ads(revision 213263)
+++ prj-conf.ads(working copy)
@@ -216,13 +216,4 @@
function Runtime_Name_Set_For (Language : Name_Id) return Boolean;
-- Returns True only if Set_Runtime_For has been called for the Language
- procedure Locate_Runtime
- (Language : Name_Id;
- Project_Tree : Prj.Project_Tree_Ref;
- Env : Prj.Tree.Environment);
- -- If RTS_Name is a base name (a name without path separator), then
- -- do nothing. Otherwise, convert it to an absolute path (possibly by
- -- searching it in the project path) and call Set_Runtime_For with the
- -- absolute path. Fail the program if the path does not exist.
-
end Prj.Conf;
Index: prj-pars.adb
===
--- prj-pars.adb(revision 213263)
+++ prj-pars.adb(working copy)
@@ -6,7 +6,7 @@
-- --
-- B o d y --
-- --
--- Copyright (C) 2001-2013, Free Software Foundation, Inc. --
+-- Copyright (C) 2001-2014, Free Software Foundation, Inc. --
-- --
-- GNAT is free software; you can redistribute it and/or modify it under --
-- terms of the GNU General Public License as published by the Free Soft- --
@@ -103,8 +103,8 @@
Success := The_Project /= No_Project;
exception
-when Invalid_Config =>
- Success := False;
+when E : Invalid_Config =>
+ Osint.Fail (Exception_Message (E));
end;
Prj.Err.Finalize;
[Ada] Crash on complex conditional involving a packed array indexing
This patch updates the freezing of expressions to account for a case when the
freezing expression is part of the Actions list of a N_Expression_With_Actions
node. In this case, any freeze nodes must remain in the Actions list.
-- Source --
-- use_before_decl.adb
with Ada.Text_IO; use Ada.Text_IO;
procedure Use_Before_Decl is
type String_Ptr is access all String;
type String_Ptr_Array is array (Positive range <>) of String_Ptr;
pragma Pack (String_Ptr_Array);
type String_Ptr_Array_Ptr is access all String_Ptr_Array;
procedure Print (Data : String_Ptr_Array_Ptr) is
begin
if Data = null then
Put_Line ("Empty");
else
for Index in Data.all'Range loop
if Data.all (Index) /= null
and then Data.all (Index).all'Length > 0
then
Put_Line (Data.all (Index).all);
end if;
end loop;
end if;
end Print;
Data : String_Ptr_Array_Ptr;
begin
Data := new String_Ptr_Array (1 .. 3);
for Index in Data.all'Range loop
Data.all (Index) := new String'("Value" & Index'Img);
end loop;
Print (Data);
end Use_Before_Decl;
-- Compilation and output --
$ gnatmake -q use_before_decl.adb
$ ./use_before_decl
Value 1
Value 2
Value 3
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Hristian Kirtchev
* freeze.adb (Freeze_Expression): Update the loop in charge
of finding a proper insertion place for freeze nodes to handle
N_Expression_With_Actions nodes.
Index: freeze.adb
===
--- freeze.adb (revision 213332)
+++ freeze.adb (revision 21)
@@ -6143,14 +6143,27 @@
exit when Is_List_Member (P);
--- Note: The N_Loop_Statement is a special case. A type that
--- appears in the source can never be frozen in a loop (this
--- occurs only because of a loop expanded by the expander), so we
--- keep on going. Otherwise we terminate the search. Same is true
--- of any entity which comes from source. (if they have predefined
--- type, that type does not appear to come from source, but the
--- entity should not be frozen here).
+-- Freeze nodes produced by an expression coming from the Actions
+-- list of a N_Expression_With_Actions node must remain within the
+-- Actions list. Inserting the freeze nodes further up the tree
+-- may lead to use before declaration issues in the case of array
+-- types.
+when N_Expression_With_Actions =>
+ if Is_List_Member (P)
+ and then List_Containing (P) = Actions (Parent_P)
+ then
+ exit;
+ end if;
+
+-- Note: N_Loop_Statement is a special case. A type that appears
+-- in the source can never be frozen in a loop (this occurs only
+-- because of a loop expanded by the expander), so we keep on
+-- going. Otherwise we terminate the search. Same is true of any
+-- entity which comes from source. (if they have predefined type,
+-- that type does not appear to come from source, but the entity
+-- should not be frozen here).
+
when N_Loop_Statement =>
exit when not Comes_From_Source (Etype (N))
and then (No (Nam) or else not Comes_From_Source (Nam));
[Ada] More precise setting of Do_Overflow_Check flag for division
The Do_Overflow_Check flag was being set on division operators in
many cases where it was not needed. Now the flag will be set only
if there is a possibility of the (largest neg number) / (-1) case
and this only if code is not being generated (-gnatc mode), since
if code is generated, the check is explicitly generated. The test
program:
1. procedure JunkDCheck
2. (Y : Positive;
3.X, Z : in out Integer) is
4. begin
5.Z := X / Z;
6.X := 10 / Y;
7. end;
if compiled with -gnatc -gnatG generates:
procedure junkdcheck
(y : positive; x : in out integer;
z : in out integer) is
begin
z := x {/} z;
x := 10 / y;
end junkdcheck;
(previously the second assignment had {/}
and if compiled with -gnatc -gnatG:
procedure junkdcheck
(y : positive; x : in out integer;
z : in out integer) is
begin
[constraint_error when
z = 0
"divide by zero"]
[constraint_error when
x = -16#8000_# and then z = -1
"overflow check failed"]
z := x / z;
x := 10 / y;
return;
end junkdcheck;
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Robert Dewar
* checks.adb (Enable_Overflow_Check): More precise setting of
Do_Overflow_Check flag for division.
Index: checks.adb
===
--- checks.adb (revision 213325)
+++ checks.adb (working copy)
@@ -1795,6 +1795,8 @@
if Do_Overflow_Check (N)
and then not Overflow_Checks_Suppressed (Etype (N))
then
+Set_Do_Overflow_Check (N, False);
+
-- Test for extremely annoying case of xxx'First divided by -1
-- for division of signed integer types (only overflow case).
@@ -1855,6 +1857,8 @@
-- it is a Division_Check and not an Overflow_Check.
if Do_Division_Check (N) then
+Set_Do_Division_Check (N, False);
+
if (not ROK) or else (Rlo <= 0 and then 0 <= Rhi) then
Insert_Action (N,
Make_Raise_Constraint_Error (Loc,
@@ -5110,6 +5114,8 @@
Lo : Uint;
Hi : Uint;
+ Do_Ovflow_Check : Boolean;
+
begin
if Debug_Flag_CC then
w ("Enable_Overflow_Check for node ", Int (N));
@@ -5187,15 +5193,52 @@
-- c) The alternative is a lot of special casing in this routine
-- which would partially duplicate Determine_Range processing.
- if OK
- and then Lo > Expr_Value (Type_Low_Bound (Typ))
- and then Hi < Expr_Value (Type_High_Bound (Typ))
- then
-if Debug_Flag_CC then
- w ("No overflow check required");
+ if OK then
+Do_Ovflow_Check := True;
+
+-- Note that the following checks are quite deliberately > and <
+-- rather than >= and <= as explained above.
+
+if Lo > Expr_Value (Type_Low_Bound (Typ))
+ and then
+Hi < Expr_Value (Type_High_Bound (Typ))
+then
+ Do_Ovflow_Check := False;
+
+-- Despite the comments above, it is worth dealing specially with
+-- division specially. The only case where integer division can
+-- overflow is (largest negative number) / (-1). So we will do
+-- an extra range analysis to see if this is possible.
+
+elsif Nkind (N) = N_Op_Divide then
+ Determine_Range
+ (Left_Opnd (N), OK, Lo, Hi, Assume_Valid => True);
+
+ if OK and then Lo > Expr_Value (Type_Low_Bound (Typ)) then
+ Do_Ovflow_Check := False;
+
+ else
+ Determine_Range
+(Right_Opnd (N), OK, Lo, Hi, Assume_Valid => True);
+
+ if OK and then (Lo > Uint_Minus_1
+or else
+ Hi < Uint_Minus_1)
+ then
+ Do_Ovflow_Check := False;
+ end if;
+ end if;
end if;
-return;
+-- If no overflow check required, we are done
+
+if not Do_Ovflow_Check then
+ if Debug_Flag_CC then
+ w ("No overflow check required");
+ end if;
+
+ return;
+end if;
end if;
end if;
[Ada] Interplay between limited with clauses, abstract states and refinement
This patch corrects the mechanism which handles limited with clauses to semi- declare abstract states (the states are fully declared when Abstract_States is analyzed). The end result is that multiple limited with clauses now reference one unique entity which denotes the state. -- Source -- -- aip.ads package AIP with SPARK_Mode is pragma Pure; end AIP; -- aip-ip.ads limited with AIP.UDP; limited with AIP.TCP; package AIP.IP with SPARK_Mode, Abstract_State => (FIB, State), Initializes=> (FIB, State) is procedure IP_Input (Netif : Integer; Buf : Integer) with Global => (Input => (FIB, UDP.State), In_Out => (TCP.State, State)); pragma Export (C, IP_Input, "AIP_ip_input"); end AIP.IP; -- aip-ip.adb with AIP.UDP; with AIP.TCP; package body AIP.IP with SPARK_Mode, Refined_State => (State => IP_Serial, FIB => Default_Router) is Default_Router : Integer := 0; IP_Serial : Integer := 0; procedure IP_Input (Netif : Integer; Buf : Integer) with Refined_Global => (Input => (Default_Router, UDP.State), In_Out => (IP_Serial, TCP.State)) is begin null; end IP_Input; end AIP.IP; -- aip-tcp.ads limited with AIP.IP; package AIP.TCP with SPARK_Mode, Abstract_State => State is procedure TCP_Input (Buf : Integer; Netif : Integer) with Global => (Input => IP.FIB, In_Out => (IP.State, State)); end AIP.TCP; -- aip-udp.ads with AIP.IP; package AIP.UDP with SPARK_Mode, Abstract_State => State is procedure UDP_Input (Buf : Integer; Netif : Integer) with Global => (Input => State); end AIP.UDP; - -- Compilation -- - $ gcc -c aip-ip.adb Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-31 Hristian Kirtchev * sem_ch10.adb (Process_State): Remove local variable Name. Add local variable Decl. Partially declare an abstract state by generating an entity and storing it in the state declaration. * sem_prag.adb (Create_Abstract_State): Fully declare a semi-declared abstract state. Index: sem_ch10.adb === --- sem_ch10.adb(revision 213264) +++ sem_ch10.adb(working copy) @@ -5695,10 +5695,10 @@ procedure Process_State (State : Node_Id) is Loc : constant Source_Ptr := Sloc (State); + Decl : Node_Id; + Dummy : Entity_Id; Elmt : Node_Id; Id: Entity_Id; - Name : Name_Id; - Dummy : Entity_Id; begin -- Multiple abstract states appear as an aggregate @@ -5721,12 +5721,12 @@ -- extension aggregate. elsif Nkind (State) = N_Extension_Aggregate then - Name := Chars (Ancestor_Part (State)); + Decl := Ancestor_Part (State); -- Simple state declaration elsif Nkind (State) = N_Identifier then - Name := Chars (State); + Decl := State; -- Possibly an illegal state declaration @@ -5734,15 +5734,27 @@ return; end if; - -- Construct a dummy state for the purposes of establishing a - -- non-limited => limited view relation. Note that the dummy - -- state is not added to list Abstract_States to avoid multiple - -- definitions. + -- Abstract states are elaborated when the related pragma is + -- elaborated. Since the withed package is not analyzed yet, + -- the entities of the abstract states are not available. To + -- overcome this complication, create the entities now and + -- store them in their respective declarations. The entities + -- are later used by routine Create_Abstract_State to declare + -- and enter the states into visibility. - Id := Make_Defining_Identifier (Loc, New_External_Name (Name)); - Set_Parent (Id, State); - Decorate_State (Id, Scop); + if No (Entity (Decl)) then + Id := Make_Defining_Identifier (Loc, Chars (Decl)); + Set_Entity (Decl, Id); + Set_Parent (Id, State); + Decorate_State (Id, Scop); + + -- Otherwise the package was previously withed + + else + Id := Entity (Decl); + end if; + Build_Shadow_Entity (Id, Scop, Dummy); end Process_State; Index: sem_prag.adb === --- sem_prag.adb(revision 213271) +++ sem_prag.adb(working copy) @@ -10519,11 +10519
[Ada] Handle =>+ notation for Depends pragma/aspect
The Depends pragma/aspect uses + in a non-standard manner, which requires new handling for the -gnatyt token check, as shown by this test, compiled with -gnatl -gnatyt 1. package DependsStyle is 2.procedure P1 3. (A : in out Integer; B : Integer) 4. with Depends => (A => +B); 5. 6.procedure P2 7. (A : in out Integer; B : Integer) 8. with Depends => (A =>+ B); | >>> (style) space required 9. 10.procedure P3 11. (A : in out Integer; B : Integer) 12. with Depends => (A =>+B); | >>> (style) space required 13. 14.procedure P4 15. (A : in out Integer; B : Integer); 16.pragma Depends ((A => +B)); 17. 18.procedure P5 19. (A : in out Integer; B : Integer); 20.pragma Depends (A =>+ B); | >>> (style) space required 21. 22.procedure P6 23. (A : in out Integer; B : Integer); 24.pragma Depends (A =>+B); | >>> (style) space required 25. end; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-31 Robert Dewar * par-ch13.adb (Get_Aspect_Specifications): Set Inside_Depends. * par-ch2.adb (P_Pragma): Set Inside_Depends. * par-ch4.adb (P_Simple_Expression): Pass Inside_Depends to Check_Unary_Plus_Or_Minus. * scans.ads (Inside_Depends): New flag. * scng.adb (Scan): Pass Inside_Depends to Check_Arrow. * style.ads: Add Inside_Depends parameter to Check_Arrow Add Inside_Depends parameter to Check_Unary_Plus_Or_Minus. * styleg.adb (Check_Arrow): Handle Inside_Depends case. (Check_Unary_Plus_Or_Minus): Handle Inside_Depends case. * styleg.ads: Add Inside_Depends parameter to Check_Arrow Add. Inside_Depends parameter to Check_Unary_Plus_Or_Minus. Index: style.ads === --- style.ads (revision 213263) +++ style.ads (working copy) @@ -6,7 +6,7 @@ -- -- -- S p e c -- -- -- --- Copyright (C) 1992-2012, Free Software Foundation, Inc. -- +-- Copyright (C) 1992-2014, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -79,7 +79,7 @@ renames Style_Inst.Check_Apostrophe; -- Called after scanning an apostrophe to check spacing - procedure Check_Arrow + procedure Check_Arrow (Inside_Depends : Boolean := False) renames Style_Inst.Check_Arrow; -- Called after scanning out an arrow to check spacing @@ -180,7 +180,7 @@ -- procedure is called only if THEN appears at the start of a line with -- Token_Ptr pointing to the THEN keyword. - procedure Check_Unary_Plus_Or_Minus + procedure Check_Unary_Plus_Or_Minus (Inside_Depends : Boolean := False) renames Style_Inst.Check_Unary_Plus_Or_Minus; -- Called after scanning a unary plus or minus to check spacing Index: par-ch13.adb === --- par-ch13.adb(revision 213263) +++ par-ch13.adb(working copy) @@ -170,6 +170,8 @@ Scan; -- past WITH Aspects := Empty_List; + -- Loop to scan aspects + loop OK := True; @@ -445,6 +447,12 @@ end if; end if; + -- Note if inside Depends aspect + + if A_Id = Aspect_Depends then + Inside_Depends := True; + end if; + -- Parse the aspect definition depening on the expected -- argument kind. @@ -460,6 +468,10 @@ Aspect_Argument (A_Id) = Optional_Expression); Set_Expression (Aspect, P_Expression); end if; + + -- Unconditionally reset flag for Inside_Depends + + Inside_Depends := False; end if; -- Add the aspect to the resulting list only when it was properly Index: scng.adb === --- scng.adb(revision 213263) +++ scng.adb(working copy) @@ -1571,7 +1571,7 @@ Token := Tok_Arrow; if Style_Check then - Style.Check_Arrow; + Style.Check_Arrow (Inside_Depends); end if; return; Index: par-ch2.adb ==
Re: [PATCH, Pointer Bounds Checker 27/x] Strlen
2014-06-11 12:22 GMT+04:00 Jakub Jelinek : > On Wed, Jun 11, 2014 at 12:14:14PM +0400, Ilya Enkovich wrote: >> This patch adds instrumented code support for strlen optimization. >> >> Bootstrapped and tested on linux-x86_64. >> >> Does it look OK? > > Ugh, this looks terribly ugly. So you are changing the meaning of arguments > of every single builtin that has pointer arguments, so all spots that > work with those builtins have to take into account > gimple_call_with_bounds_p and do something different? > That is very error prone and maintainance nightmare. > > Jakub Hi Jakub, I've tried an approach with internal functions usage as you suggested on Cauldron. Shortly about used scheme: - only a selected set of builtin functions is instrumented - during instrumentation builtin call is replaced with internal function call I tried to implement it and faced few issues: 1. On expand pass we need to expand all those internal function and since they should be expanded as regular instrumented calls, I need to create a CALL_EXPR tree for that. I have nothing to use as fndecl for this call except the same instrumented builtin fndecl I use right now. Therefore the problem of instrumented call with the same builtin function code would still exist during expand pass. 2. Some builtins actually may have body. If I instrument such call and replace it with internal call then I loose a possibility to inline it. If I do not replace it with internal call then I have to make an instrumented call and again I have to create and use instrumented builtin fndecl having the same situation I have now but this time only until call is inlined. 3. Usage of internal functions means we cannot support whole program instrumentation (or we have to declare internal function for each builtin) which may appear a very useful scheme with reduced memory and performance penalties. Now I want to try another scheme. I want to change enum built_in_function so that each builtin code has a paired code to be used for instrumented version. I'm not going to actually declare additional builtins for users, I just want to obtain special function codes to be used for instrumented builtins and thus to not make current code handling builtins to work with instrumented calls. Ilya
[PATCH][LTO] Remove set-but-unused fields
Bootstrapped on x86_64-unknown-linux-gnu, applied.
Richard.
2014-07-31 Richard Biener
* lto-streamer.h (struct output_block): Remove global.
(struct data_in): Remove labels, num_named_labels and
num_unnamed_labels.
* lto-streamer-in.c (lto_data_in_delete): Do not free labels.
* lto-streamer-out.c (produce_asm_for_decls): Do not set global.
Index: gcc/lto-streamer.h
===
--- gcc/lto-streamer.h (revision 213317)
+++ gcc/lto-streamer.h (working copy)
@@ -696,9 +696,6 @@ struct output_block
int current_line;
int current_col;
- /* True if writing globals and types. */
- bool global;
-
/* Cache of nodes written in this section. */
struct streamer_tree_cache_d *writer_cache;
@@ -714,22 +711,12 @@ struct data_in
/* The global decls and types. */
struct lto_file_decl_data *file_data;
- /* All of the labels. */
- tree *labels;
-
/* The string table. */
const char *strings;
/* The length of the string table. */
unsigned int strings_len;
- /* Number of named labels. Used to find the index of unnamed labels
- since they share space with the named labels. */
- unsigned int num_named_labels;
-
- /* Number of unnamed labels. */
- unsigned int num_unnamed_labels;
-
/* Maps each reference number to the resolution done by the linker. */
vec globals_resolution;
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c (revision 213317)
+++ gcc/lto-streamer-in.c (working copy)
@@ -1427,6 +1427,5 @@ lto_data_in_delete (struct data_in *data
{
data_in->globals_resolution.release ();
streamer_tree_cache_delete (data_in->reader_cache);
- free (data_in->labels);
free (data_in);
}
Index: gcc/lto-streamer-out.c
===
--- gcc/lto-streamer-out.c (revision 213317)
+++ gcc/lto-streamer-out.c (working copy)
@@ -2632,7 +2632,6 @@ produce_asm_for_decls (void)
int32_t num_decl_states;
ob = create_output_block (LTO_section_decls);
- ob->global = true;
memset (&header, 0, sizeof (struct lto_decl_header));
[Ada] Crash on illegal discrete range
With this patch the compiler rejects properly a discrete range in a loop
specification that uses 'length by mistake.
Compiler lab4.adb must yield:
lab4.adb:13:23: expect attribute "range"
---
package body lab4 is
procedure createArray (myArr : in out dynArray; maxIndex : Integer) is
tempArr : dynArray (1..maxIndex);
cntArr : integer :=0;
begin
for i in tempArr'length loop
tempArr(cntArr):= cntArr;
cntArr := cntArr+1;
end loop;
end createArray;
end lab4;
---
package lab4 is
Type Node;
Type Tree is access Node;
Type Node is record
Val : Integer;
Left, Right : Tree;
end record;
type dynArray is array (positive range <>) of Integer; -- typeset for array
procedure createArray (myArr : in out dynArray; maxIndex : Integer);
end lab4;
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Ed Schonberg
* sem_ch3.adb (Make_Index): Reject properly the use of 'Length
in a discrete range, when 'range was probably intended.
Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 213338)
+++ sem_ch3.adb (working copy)
@@ -17285,10 +17285,16 @@
elsif Nkind (N) = N_Attribute_Reference then
- -- The parser guarantees that the attribute is a RANGE attribute
+ -- Catch beginner's error (use of attribute other than 'Range)
+ if Attribute_Name (N) /= Name_Range then
+Error_Msg_N ("expect attribute ''Range", N);
+Set_Etype (N, Any_Type);
+return;
+ end if;
+
-- If the node denotes the range of a type mark, that is also the
- -- resulting type, and we do no need to create an Itype for it.
+ -- resulting type, and we do not need to create an Itype for it.
if Is_Entity_Name (Prefix (N))
and then Comes_From_Source (N)
[Ada] Warnings on non-static components of protected types
This patch improves the warnings on component of protected types when compiled
under restriction No_Heap_allocations. The patch distinguishes betwen:
a) components whose size depends on discriminants, in which case an object of
the type will not violate restriction if the discriminants have static values.
b) Components whose size depends on some other non-static expression, e.g. a
function call, in which case any object of the type will violate restriction.
Compiling toto.adb must yield:
toto.ads:5:07: warning: creation of protected object of type "Bounded_Queue"
with non-static discriminants will violate restriction
No_Implicit_Heap_Allocations
---
pragma restrictions (No_Implicit_Heap_Allocations);
package toto is
protected type Bounded_Queue (c : integer) is
private
Queue_Elements : String (1 .. C);
end Bounded_Queue;
end;
---
package body toto is
protected body Bounded_Queue is
-- begin
-- null;
end Bounded_Queue;
A : Bounded_queue (3);
begin
null;
end;
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Ed Schonberg
* exp_ch9.adb (Expand_N_Protected_Type_Declaration): New
predicate Discriminated_Size, to distinguish between private
components that depend on discriminants from those whose size
depends on some other non-static expression.
Index: exp_ch9.adb
===
--- exp_ch9.adb (revision 213325)
+++ exp_ch9.adb (working copy)
@@ -8877,6 +8877,12 @@
-- to the internal body, for possible inlining later on. The source
-- operation is invisible to the back-end and is never actually called.
+ function Discriminated_Size (Comp : Entity_Id) return Boolean;
+ -- If a component size is not static then a warning will be emitted
+ -- in Ravenscar or other restricted contexts. When a component is non-
+ -- static because of a discriminant constraint we can specialize the
+ -- warning by mentioning discriminants explicitly.
+
procedure Expand_Entry_Declaration (Comp : Entity_Id);
-- Create the subprograms for the barrier and for the body, and append
-- then to Entry_Bodies_Array.
@@ -8904,10 +8910,66 @@
end if;
end Check_Inlining;
- -
- -- Check_Static_Component_Size --
- -
+
+ -- Discriminated_Size --
+
+ function Discriminated_Size (Comp : Entity_Id) return Boolean
+ is
+ Typ : constant Entity_Id := Etype (Comp);
+ Index : Node_Id;
+
+ function Non_Static_Bound (Bound : Node_Id) return Boolean;
+ -- Check whether the bound of an index is non-static and does
+ -- denote a discriminant, in which case any protected object of
+ -- the type will have a non-static size.
+
+ --
+ -- Non_Static_Bound --
+ --
+
+ function Non_Static_Bound (Bound : Node_Id) return Boolean is
+ begin
+if Is_Static_Expression (Bound) then
+ return False;
+
+elsif Is_Entity_Name (Bound)
+ and then Present (Discriminal_Link (Entity (Bound)))
+then
+ return False;
+
+else
+ return True;
+end if;
+ end Non_Static_Bound;
+
+ begin
+ if not Is_Array_Type (Typ) then
+return False;
+ end if;
+
+ if Ekind (Typ) = E_Array_Subtype then
+Index := First_Index (Typ);
+while Present (Index) loop
+ if Non_Static_Bound (Low_Bound (Index))
+ or else Non_Static_Bound (High_Bound (Index))
+ then
+ return False;
+ end if;
+
+ Next_Index (Index);
+end loop;
+
+return True;
+ end if;
+
+ return False;
+ end Discriminated_Size;
+
+ ---
+ -- Static_Component_Size --
+ ---
+
function Static_Component_Size (Comp : Entity_Id) return Boolean is
Typ : constant Entity_Id := Etype (Comp);
C : Entity_Id;
@@ -9100,11 +9162,26 @@
Check_Restriction (No_Implicit_Heap_Allocations, Priv);
elsif Restriction_Active (No_Implicit_Heap_Allocations) then
- Error_Msg_N ("component has non-static size??", Priv);
- Error_Msg_NE
- ("\creation of protected object of type& will violate"
-& " restriction No_Implicit_Heap_Allocations??",
-Priv, Prot_Typ);
+ if not Discriminated_Size (Defining_Identifier (Priv))
+ then
+
+-- Any object of
Re: [PATCH 5/5] add libcc1
On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote: > On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law wrote: > > On 06/19/14 14:52, Tom Tromey wrote: > >> > >> Tom> I've edited this one down by removing the auto-generated stuff , and > >> Tom> then compressed it. > >> > >> Here's a new version of patch #5. > >> I've removed the generated code; let's see if it gets through without > >> compression. > >> > >> I think this addresses all the reviews: > >> > >> * It uses gcc-plugin.m4 to disable the plugin > >> * It does some configure checks for needed functionality, and disables > >>the plugin if they are not found > >> * libcc1 and the plugin now do a protocol version handshake at > >>startup > >> * The diagnostic overriding code is now in the plugin, not in gcc proper > >> * gdb now tells libcc1 about the target triplet, and libcc1 uses > >>this to invoke the proper GCC. This is done by (ewww) searching $PATH. > >> > >> Tom > >> > >> 2014-06-19 Phil Muldoon > >> Tom Tromey > >> > >> * Makefile.def: Add libcc1 to host_modules. > >> * configure.ac (host_tools): Add libcc1. > >> * Makefile.in, configure: Rebuild. > >> > >> 2014-06-19 Phil Muldoon > >> Jan Kratochvil > >> Tom Tromey > >> > >> * aclocal.m4: New file. > >> * callbacks.cc: New file. > >> * callbacks.hh: New file. > >> * cc1plugin-config.h.in: New file. > >> * configure: New file. > >> * configure.ac: New file. > >> * connection.cc: New file. > >> * connection.hh: New file. > >> * findcomp.cc: New file. > >> * findcomp.hh: New file. > >> * libcc1.cc: New file. > >> * libcc1plugin.sym: New file. > >> * libcc1.sym: New file. > >> * Makefile.am: New file. > >> * Makefile.in: New file. > >> * marshall.cc: New file. > >> * marshall.hh: New file. > >> * names.cc: New file. > >> * names.hh: New file. > >> * plugin.cc: New file. > >> * rpc.hh: New file. > >> * status.hh: New file. > > > > So my biggest concern here is long term maintenance -- who's going to own > > care and feeding of these bits over time. > > > > My inclination is to go ahead and approve, but explicitly note that if the > > bits do start to rot that we'll be fairly aggressive at disabling/removing > > them. > > > > Now that my position is out there for everyone to see, give the other > > maintainers a few days (say until Monday) to chime in with any objections. > > > > Obviously if there are no objections and you check in the change, please be > > on the lookout for any fallout. I'm particularly concerned about AIX, > > Solaris and other non-linux platforms. > > > > Does this deserve a mention in the news file? > > Can you briefly elaborate on how this relates to the JIT work from > David Malcom? I don't think the JIT work helps much here because this library wants to feed gcc source not IL, so it needs a front end not just the back. > Also during the GCC Summit we talked about JIT and plugins and > I mentioned that the JIT API is actually a kind of "stable plugin API" > for IL creation. good point. > We've also elaborated on why the JIT cannot be a "plugin" at the > moment - which is at least partly because we cannot have > "frontend plugins". This is because compilation is currently > driven by the frontend which "owns" main() even though it immediately > calls into the middle-end and only gets control back via langhooks. > So a quite obvious cleanup of the program flow of GCC would be > to drive things from a middle-end main() - which would allow > a plugin to take over the frontend parts (and which would allow > making all frontends shared objects, aka "plugins" to a common > middle-end "driver"). sounds nice > Just throwing in my mental notes from the Summit here. I really > wonder how libcc1 falls in into this picture and if it would stand > in the way of re-organizing main program flow and/or making > frontends shared objects. so the interesting bit of libcc1 is just a plugin, which means it won't add any extra work past making plugins work. On the other hand if you could load a library that included the driver and front ends then you'd basically have a much simpler libcc1, so I think that work would make libcc1 a bit nicer. Trev > > [ideally both frontends and targets would be shared objects, but of > course even frontends have target dependencies pulled in via > target macros at the moment...] > > Richard. > > > Jeff > >
Re: [PATCH] [ARM] [RFC] Fix longstanding push_minipool_fix ICE (PR49423, lp1296601)
On 5 July 2014 16:12, Charles Baylis wrote: > On 3 July 2014 15:26, Richard Earnshaw wrote: > >> So OK, but if you're considering back-ports, I suggest you let it bake a >> while on trunk first. > > Committed as r212303. It was a few weeks ago now, so is it OK to backport this to 4.8 and 4.9 branches?
Re: [PATCH] [ARM] [RFC] Fix longstanding push_minipool_fix ICE (PR49423, lp1296601)
On 31/07/14 11:53, Christophe Lyon wrote: On 5 July 2014 16:12, Charles Baylis wrote: On 3 July 2014 15:26, Richard Earnshaw wrote: So OK, but if you're considering back-ports, I suggest you let it bake a while on trunk first. Committed as r212303. It was a few weeks ago now, so is it OK to backport this to 4.8 and 4.9 branches? Given that we've had this bake sufficiently on trunk and have seen no regressions reported it should be fine to go back to these branches. Further we've had the 4.9.1 and 4.8.3 releases recently so I'd say Yes, unless the RM's object in the next 24 hours. regards Ramana
Re: [PATCH 5/5] add libcc1
On Thu, Jul 31, 2014 at 12:44 PM, Trevor Saunders wrote: > On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote: >> On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law wrote: >> > On 06/19/14 14:52, Tom Tromey wrote: >> >> >> >> Tom> I've edited this one down by removing the auto-generated stuff , and >> >> Tom> then compressed it. >> >> >> >> Here's a new version of patch #5. >> >> I've removed the generated code; let's see if it gets through without >> >> compression. >> >> >> >> I think this addresses all the reviews: >> >> >> >> * It uses gcc-plugin.m4 to disable the plugin >> >> * It does some configure checks for needed functionality, and disables >> >>the plugin if they are not found >> >> * libcc1 and the plugin now do a protocol version handshake at >> >>startup >> >> * The diagnostic overriding code is now in the plugin, not in gcc proper >> >> * gdb now tells libcc1 about the target triplet, and libcc1 uses >> >>this to invoke the proper GCC. This is done by (ewww) searching $PATH. >> >> >> >> Tom >> >> >> >> 2014-06-19 Phil Muldoon >> >> Tom Tromey >> >> >> >> * Makefile.def: Add libcc1 to host_modules. >> >> * configure.ac (host_tools): Add libcc1. >> >> * Makefile.in, configure: Rebuild. >> >> >> >> 2014-06-19 Phil Muldoon >> >> Jan Kratochvil >> >> Tom Tromey >> >> >> >> * aclocal.m4: New file. >> >> * callbacks.cc: New file. >> >> * callbacks.hh: New file. >> >> * cc1plugin-config.h.in: New file. >> >> * configure: New file. >> >> * configure.ac: New file. >> >> * connection.cc: New file. >> >> * connection.hh: New file. >> >> * findcomp.cc: New file. >> >> * findcomp.hh: New file. >> >> * libcc1.cc: New file. >> >> * libcc1plugin.sym: New file. >> >> * libcc1.sym: New file. >> >> * Makefile.am: New file. >> >> * Makefile.in: New file. >> >> * marshall.cc: New file. >> >> * marshall.hh: New file. >> >> * names.cc: New file. >> >> * names.hh: New file. >> >> * plugin.cc: New file. >> >> * rpc.hh: New file. >> >> * status.hh: New file. >> > >> > So my biggest concern here is long term maintenance -- who's going to own >> > care and feeding of these bits over time. >> > >> > My inclination is to go ahead and approve, but explicitly note that if the >> > bits do start to rot that we'll be fairly aggressive at disabling/removing >> > them. >> > >> > Now that my position is out there for everyone to see, give the other >> > maintainers a few days (say until Monday) to chime in with any objections. >> > >> > Obviously if there are no objections and you check in the change, please be >> > on the lookout for any fallout. I'm particularly concerned about AIX, >> > Solaris and other non-linux platforms. >> > >> > Does this deserve a mention in the news file? >> >> Can you briefly elaborate on how this relates to the JIT work from >> David Malcom? > > I don't think the JIT work helps much here because this library wants to > feed gcc source not IL, so it needs a front end not just the back. Ah, ok ... >> Also during the GCC Summit we talked about JIT and plugins and >> I mentioned that the JIT API is actually a kind of "stable plugin API" >> for IL creation. > > good point. > >> We've also elaborated on why the JIT cannot be a "plugin" at the >> moment - which is at least partly because we cannot have >> "frontend plugins". This is because compilation is currently >> driven by the frontend which "owns" main() even though it immediately >> calls into the middle-end and only gets control back via langhooks. >> So a quite obvious cleanup of the program flow of GCC would be >> to drive things from a middle-end main() - which would allow >> a plugin to take over the frontend parts (and which would allow >> making all frontends shared objects, aka "plugins" to a common >> middle-end "driver"). > > sounds nice Actually after looking again I was wrong. main.c and toplev.c are the "driver". So if we can make all frontends shared objects with their only interface being their lang_hooks that would be nice (of course the middle-end still needs to make gazillions of symbols available to that "plugin"). Of course it won't really help libcc1 as libcc1 isn't a frontend itself. >> Just throwing in my mental notes from the Summit here. I really >> wonder how libcc1 falls in into this picture and if it would stand >> in the way of re-organizing main program flow and/or making >> frontends shared objects. > > so the interesting bit of libcc1 is just a plugin, which means it won't > add any extra work past making plugins work. On the other hand if you > could load a library that included the driver and front ends then you'd > basically have a much simpler libcc1, so I think that work would make > libcc1 a bit nicer. > > Trev > >> >> [ideally both fronten
[PATCH, i386] Handle extended family cpuid info for AMD
Hi,
The below patch handles the AMD's cpuid family information.
With the information from cpuid, BTVER2 cpu for -march=native flag is handled.
Bootstrap passes.
Is it OK for trunk and branches?
Regards
Ganesh
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6223bd6..3f8bb2c 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-07-31 Ganesh Gopalasubramanian
+
+ * tree-sra.c (host_detect_local_cpu): Handle AMD's extended family
+ information. Handle BTVER2 cpu with cpuid family value.
+
2014-07-30 Martin Jambor
* tree-sra.c (sra_ipa_modify_assign): Change type of the first
diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index 1c6385f..21ae1f3 100644
--- a/gcc/config/i386/driver-i386.c
+++ b/gcc/config/i386/driver-i386.c
@@ -432,7 +432,8 @@ const char *host_detect_local_cpu (int argc, const char
**argv)
model = (eax >> 4) & 0x0f;
family = (eax >> 8) & 0x0f;
- if (vendor == signature_INTEL_ebx)
+ if ((vendor == signature_INTEL_ebx) ||
+ (vendor == signature_AMD_ebx))
{
unsigned int extended_model, extended_family;
@@ -576,7 +577,7 @@ const char *host_detect_local_cpu (int argc, const char
**argv)
if (name == signature_NSC_ebx)
processor = PROCESSOR_GEODE;
- else if (has_movbe)
+ else if (has_movbe && family == 22)
processor = PROCESSOR_BTVER2;
else if (has_avx2)
processor = PROCESSOR_BDVER4;
Re: [PATCH, i386] Handle extended family cpuid info for AMD
On Thu, Jul 31, 2014 at 1:28 PM, Gopalasubramanian, Ganesh wrote: > The below patch handles the AMD's cpuid family information. > With the information from cpuid, BTVER2 cpu for -march=native flag is handled. But, looking to processor_alias_table in config/i386/i386.c, only PROCESSOR_BTVER2 defines PTA_MOVBE. According to this, the logic is already correct, so the patch is not needed. Uros.
RE: [PATCH, i386] Handle extended family cpuid info for AMD
> But, looking to processor_alias_table in config/i386/i386.c, only > PROCESSOR_BTVER2 defines PTA_MOVBE. According to this, the logic is already > correct, so the patch is not needed. We are evaluating bdver4 cpu. Bdver4 also supports MOVBE. I will submit patch for bdver4 PTA after our evaluation. Ganesh.
Re: [PATCH, i386] Handle extended family cpuid info for AMD
On Thu, Jul 31, 2014 at 1:46 PM, Gopalasubramanian, Ganesh wrote: >> But, looking to processor_alias_table in config/i386/i386.c, only >> PROCESSOR_BTVER2 defines PTA_MOVBE. According to this, the logic is already >> correct, so the patch is not needed. > > We are evaluating bdver4 cpu. Bdver4 also supports MOVBE. I will submit patch > for bdver4 PTA after our evaluation. Then just use: --cut here-- Index: driver-i386.c === --- driver-i386.c (revision 213342) +++ driver-i386.c (working copy) @@ -576,10 +576,10 @@ const char *host_detect_local_cpu (int argc, const if (name == signature_NSC_ebx) processor = PROCESSOR_GEODE; + else if (has_avx2) +processor = PROCESSOR_BDVER4; else if (has_movbe) processor = PROCESSOR_BTVER2; - else if (has_avx2) -processor = PROCESSOR_BDVER4; else if (has_xsaveopt) processor = PROCESSOR_BDVER3; else if (has_bmi) --cut here-- Uros.
RE: [PATCH, i386] Handle extended family cpuid info for AMD
> Then just use: > + else if (has_avx2) > +processor = PROCESSOR_BDVER4; > else if (has_movbe) >processor = PROCESSOR_BTVER2; >- else if (has_avx2) >-processor = PROCESSOR_BDVER4; > else if (has_xsaveopt) In that case, with earlier GCC versions where we don’t have bdver4 added, the fall back would be BTVER2, whereas a BD variant is more desirable. Ganesh
[PATCH] Fix PR61950
The following fixes PR61950 by properly initializing the _size field
of the static constructor for the vtable init member. Previously
gfortran would use a 64bit integer to initialize the 32bit size field
(not sure why larger aggregates are not considered).
This breaks more sophisticated constant-folding and previously
inhibited constant folding (which would have worked in this case
been there no mismatch between initializer and field).
Bootstrap and regtest ongoing on powerpc64-linux-gnu, ok? I'm not
considering a backport as it is only a missed optimization there.
Thanks,
Richard.
2014-07-31 Richard Biener
* trans-expr.c (gfc_conv_structure): Initialize _size with
a value of proper type.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 213342)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -6260,7 +6260,9 @@ gfc_conv_structure (gfc_se * se, gfc_exp
else if (cm->ts.u.derived && strcmp (cm->name, "_size") == 0)
{
val = TYPE_SIZE_UNIT (gfc_get_derived_type (cm->ts.u.derived));
- CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, val);
+ CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl,
+ fold_convert (TREE_TYPE (cm->backend_decl),
+ val));
}
else
{
[PING][PATCHv3] Fix vector tests on ARM platforms with disabled unaligned accesses
On 07/24/2014 07:40 PM, Marat Zakirov wrote:
On 07/24/2014 04:27 PM, Marat Zakirov wrote:
On 07/23/2014 06:23 PM, Marat Zakirov wrote:
Hi there!
I made a patch which fixes regressions on ARM platforms with
disabled unaligned accesses. The problem is that
'arm_vect_no_misalign' predicate do not check 'unaligned_access'
global variable to determine whether unaligned access to vector are
allowed. This leads to spurious vect.exp test fails when GCC is
configured --with-specs=%{!munaligned-access:-mno-unaligned-access}.
Attached patch fixes ARM predicate and several tests to correctly
handle the issue.
The following targets were reg. tested for multiple targets (ARM,
Thumb-1, Thumb-2, x86, x86_64) with and without
-mno-unaligned-access. Analysis showed patch affects only vect.exp
tests so only vect.exp was tested.
For x86, x86_64, ARM without -mno-unaligned-access, Thumb-2 without
-mno-unaligned-access and Thumb-1 no regressions occured. For
ARM/Thumb2 with -mno-unaligned-access patch fixed most of failures
but triggered some problems (see attached log) for current vect.exp
tests:
1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61887
2) Some XPASS'es due to unexpected loop versioning (e.g.
gcc.dg/vect/pr33804.c).
3) After predicate fix some passing tests which require unaligned
vector support become NA (this was expected).
Here is new version of patch and regression log. On the current trunk
results are slightly different due to patches for Richard Biener (no
UNRESOLVED fails) but some PASS->XPASS regressions still remain (see
attachment):
PASS->XPASS: gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c
scan-tree-dump-times vect "vectorized 1 loops" 1
PASS->XPASS: gcc.dg/vect/pr33804.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
etc.
These XPASS'es are due to code versioning: current GCC creates 2
versions of loop: aligned and misaligned. It's look like they are
slightly out of date at lest for ARM.
On 07/24/2014 06:50 PM, Ramana Radhakrishnan wrote:
This is redundant.
- || (defined(__ARMEL__) \
+ || (defined(__ARM_FEATURE_UNALIGNED) \
+ && defined(__ARMEL__) \
&& (!defined(__thumb__) || defined(__thumb2__)))
As is this line.
I think you can restrict the check to defined(__ARM_FEATURE_UNALIGNED)
&& defined(__ARMEL__)
__ARM_FEATURE_UNALIGNED should tell you whether unaligned access is
allowed or not, therefore you should no longer require any specific
"architectural" checks.
#error FOO
#endif
I'm not sure about the original intent of the tests right now.
Ramana
Thank you Ramana!
--Marat
gcc/testsuite/ChangeLog:
2014-07-23 Marat Zakirov
* gcc.dg/vect/vect-109.c: Skip predicate added.
* gcc.dg/vect/vect-93.c: Test check fixed.
* gcc.dg/vect/bb-slp-10.c: Likewise.
* lib/target-supports.exp (check_effective_target_arm_vect_no_misalign):
Check unaligned feature.
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-10.c b/gcc/testsuite/gcc.dg/vect/bb-slp-10.c
index a1850ed..0090a4b 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-10.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-10.c
@@ -49,7 +49,7 @@ int main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-times "unsupported alignment in basic block." 1 "slp2" { xfail vect_element_align } } } */
+/* { dg-final { scan-tree-dump "unsupported alignment in basic block." 1 "slp2" { xfail vect_element_align } } } */
/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp2" { target vect_element_align } } } */
/* { dg-final { cleanup-tree-dump "slp2" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/vect-109.c b/gcc/testsuite/gcc.dg/vect/vect-109.c
index 854c970..c671175 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-109.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-109.c
@@ -1,3 +1,4 @@
+/* { dg-skip-if "" { vect_no_align } } */
/* { dg-require-effective-target vect_int } */
#include
diff --git a/gcc/testsuite/gcc.dg/vect/vect-93.c b/gcc/testsuite/gcc.dg/vect/vect-93.c
index 65403eb..1065a6e 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-93.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-93.c
@@ -79,7 +79,7 @@ int main (void)
/* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { target vect_no_align } } } */
/* in main: */
-/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { target vect_no_align } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target vect_no_align } } } */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 1 "vect" { xfail { vect_no_align } } } } */
/* { dg-final { cleanup-tree-dump "vect" } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index db65ebe..35076d2 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2293,8 +2293,8 @@ proc check_effective_target_arm_little_endian { } {
proc check_effective_target_arm_vect
[PATCH][match-and-simplify] Fix match.pd dependencies
Committed. Richard. 2014-07-31 Richard Biener * Makefile.in (s-match): Fix dependencies. Index: Makefile.in === --- Makefile.in (revision 213121) +++ Makefile.in (working copy) @@ -2236,7 +2236,7 @@ s-tm-texi: build/genhooks$(build_exeext) gimple-match.c: s-match gimple-match-head.c ; @true generic-match.c: s-match generic-match-head.c ; @true -s-match: build/genmatch$(build_exeext) $(srcdir)/match.pd +s-match: build/genmatch$(build_exeext) $(srcdir)/match*.pd $(RUN_GEN) build/genmatch$(build_exeext) -gimple $(srcdir)/match.pd \ > tmp-gimple-match.c $(RUN_GEN) build/genmatch$(build_exeext) -generic $(srcdir)/match.pd \
[Ada] Avoid random warnings treated as errors
There may be cases when warnings in the Project Manager are treated as errors, even when the switch -we is not used. There is no test, as the occurences of such errors are random (unitialized component of a record). Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-31 Vincent Celier * errutil.adb (Error_Msg): Make sure that all components of the error message object are initialized. Index: errutil.adb === --- errutil.adb (revision 213326) +++ errutil.adb (working copy) @@ -201,24 +201,27 @@ -- Otherwise build error message object for new message - Errors.Increment_Last; - Cur_Msg := Errors.Last; - Errors.Table (Cur_Msg).Text := new String'(Msg_Buffer (1 .. Msglen)); - Errors.Table (Cur_Msg).Next := No_Error_Msg; - Errors.Table (Cur_Msg).Sptr := Sptr; - Errors.Table (Cur_Msg).Optr := Optr; - Errors.Table (Cur_Msg).Sfile:= Get_Source_File_Index (Sptr); - Errors.Table (Cur_Msg).Line := Get_Physical_Line_Number (Sptr); - Errors.Table (Cur_Msg).Col := Get_Column_Number (Sptr); - Errors.Table (Cur_Msg).Style:= Is_Style_Msg; - Errors.Table (Cur_Msg).Warn := Is_Warning_Msg; - Errors.Table (Cur_Msg).Info := Is_Info_Msg; - Errors.Table (Cur_Msg).Warn_Chr := Warning_Msg_Char; - Errors.Table (Cur_Msg).Serious := Is_Serious_Error; - Errors.Table (Cur_Msg).Uncond := Is_Unconditional_Msg; - Errors.Table (Cur_Msg).Msg_Cont := Continuation; - Errors.Table (Cur_Msg).Deleted := False; + Errors.Append +(New_Val => + (Text => new String'(Msg_Buffer (1 .. Msglen)), +Next => No_Error_Msg, +Prev => No_Error_Msg, +Sfile=> Get_Source_File_Index (Sptr), +Sptr => Sptr, +Optr => Optr, +Line => Get_Physical_Line_Number (Sptr), +Col => Get_Column_Number (Sptr), +Warn => Is_Warning_Msg, +Info => Is_Info_Msg, +Warn_Err => Warning_Mode = Treat_As_Error, +Warn_Chr => Warning_Msg_Char, +Style=> Is_Style_Msg, +Serious => Is_Serious_Error, +Uncond => Is_Unconditional_Msg, +Msg_Cont => Continuation, +Deleted => False)); + Cur_Msg := Errors.Last; Prev_Msg := No_Error_Msg; Next_Msg := First_Error_Msg;
[Ada] Legality checks on indexing aspects
This patch implements the legality rules given in RM 4.1.6 on user-defined indexing, most importantly the rule that the aspects cannot be specified for a derived type if the parent type has such defined or inherited aspects. Several reports include this illegal usage, which appears to be an intuitive (if illegal) way of creating new container types. In order to simplify the transition between this illegal usage and the proper one, the previous behavior can be recovered by using the internal debugging option -gnatd.X. This patch also handles properly element iterators over class-wide containers. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-31 Ed Schonberg * sem_ch4.adb (Try_Container_Indexing): If the container type is class-wide, use specific type to locate iteration primitives. * sem_ch13.adb (Check_Indexing_Functions): Add legality checks for rules in RM 4.1.6 (Illegal_Indexing): New diagnostic procedure. Minor error message reformating. * exp_ch5.adb (Expand_Iterator_Loop): Handle properly Iterator aspect for a derived type. Index: exp_ch5.adb === --- exp_ch5.adb (revision 213327) +++ exp_ch5.adb (working copy) @@ -28,6 +28,7 @@ with Checks; use Checks; with Debug;use Debug; with Einfo;use Einfo; +with Elists; use Elists; with Errout; use Errout; with Exp_Aggr; use Exp_Aggr; with Exp_Ch6; use Exp_Ch6; @@ -58,6 +59,7 @@ with Stringt; use Stringt; with Targparm; use Targparm; with Tbuild; use Tbuild; +with Uintp;use Uintp; with Validsw; use Validsw; package body Exp_Ch5 is @@ -3292,17 +3294,90 @@ -- type of the iterator must be obtained from the aspect. if Of_Present (I_Spec) then -declare - Default_Iter : constant Entity_Id := -Entity - (Find_Value_Of_Aspect -(Etype (Container), - Aspect_Default_Iterator)); - +Handle_Of : declare + Default_Iter : Entity_Id; Container_Arg : Node_Id; Ent : Entity_Id; + function Get_Default_Iterator + (T : Entity_Id) return Entity_Id; + -- If the container is a derived type, the aspect holds the + -- parent operation. The required one is a primitive of the + -- derived type and is either inherited or overridden. + + -- + -- Get_Default_Iterator -- + -- + + function Get_Default_Iterator + (T : Entity_Id) return Entity_Id + is + Iter : constant Entity_Id := +Entity (Find_Value_Of_Aspect (T, Aspect_Default_Iterator)); + Prim : Elmt_Id; + Op : Entity_Id; + + begin + Container_Arg := New_Copy_Tree (Container); + + -- A previous version of GNAT allowed indexing aspects to + -- be redefined on derived container types, while the + -- default iterator was inherited from the aprent type. + -- This non-standard extension is preserved temporarily for + -- use by the modelling project under debug flag d.X. + + if Debug_Flag_Dot_XX then + if Base_Type (Etype (Container)) /= +Base_Type (Etype (First_Formal (Iter))) + then +Container_Arg := + Make_Type_Conversion (Loc, +Subtype_Mark => + New_Occurrence_Of +(Etype (First_Formal (Iter)), Loc), +Expression => Container_Arg); + end if; + + return Iter; + + elsif Is_Derived_Type (T) then + + -- The default iterator must be a primitive operation + -- of the type, at the same dispatch slot position. + + Prim := First_Elmt (Primitive_Operations (T)); + while Present (Prim) loop +Op := Node (Prim); + +if Chars (Op) = Chars (Iter) + and then DT_Position (Op) = DT_Position (Iter) +then + return Op; +end if; + +Next_Elmt (Prim); + end loop; + + -- default iterator must exist. + + pragma Assert (False); + + else -- not a derived type + return Iter; + end
Re: [PATCH, i386] Handle extended family cpuid info for AMD
On Thu, Jul 31, 2014 at 1:54 PM, Gopalasubramanian, Ganesh
wrote:
>> Then just use:
>
>> + else if (has_avx2)
>> +processor = PROCESSOR_BDVER4;
>> else if (has_movbe)
>>processor = PROCESSOR_BTVER2;
>>- else if (has_avx2)
>>-processor = PROCESSOR_BDVER4;
>> else if (has_xsaveopt)
>
> In that case, with earlier GCC versions where we don’t have bdver4 added, the
> fall back would be BTVER2,
> whereas a BD variant is more desirable.
I would like to have a check for a family at the beginning, something like:
if (name == signature_NSC_ebx)
processor = PROCESSOR_GEODE;
else if (family == 22)
{
if (has_movbe)
processor = PROCESSOR_BTVER2;
else
processor = PROCESSOR_BTVER1;
}
else if (has_avx2)
processor = PROCESSOR_BDVER4;
else if (has_xsaveopt)
Please also fix ChangeLog entry.
Uros.
[Ada] Avoid unwanted overflow checks on unconstraint float operations
For operations on unconstrained floating-point values, we do not want
overflow checks (since we expect to generate and handle IEEE INF and
NaN values). This corrects a problem where such checks were being set
if integer overflow was enabled. The following test when executed:
1. with Ada.Float_Text_IO;
2. with Ada.Long_Long_Float_Text_IO;
3. with Ada.Text_IO;
4. procedure IEEE_Conversions is
5.package FIO renames Ada.Float_Text_IO;
6.package LIO renames Ada.Long_Long_Float_Text_IO;
7.use Ada.Text_IO;
8.One : Long_Float := 1.0;
9.Zero : Long_Float := 0.0;
10.Infinity : Long_Float := One / Zero;
11.NaN : Long_Float := Zero / Zero;
12. begin
13.Put ("Float infinity: ");
14.FIO.Put (Float (Infinity));
15.New_Line;
16.Put ("Long_Long_Float infinity: ");
17.LIO.Put (Long_Long_Float (Infinity));
18.New_Line;
19.Put ("Float NaN: ");
20.FIO.Put (Float (NaN));
21.New_Line;
22.Put ("Long_Long_Float NaN: ");
23.LIO.Put (Long_Long_Float (NaN));
24.New_Line;
25. end;
should generate the output:
Float infinity: +Inf
Long_Long_Float infinity: +Inf
Float NaN: NaN*
Long_Long_Float NaN: NaN*
Before this change, a constraint error was raised
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Robert Dewar
* checks.ads, checks.adb (Activate_Overflow_Check): Do not set flag for
unconstrained fpt ops.
Index: checks.adb
===
--- checks.adb (revision 213335)
+++ checks.adb (working copy)
@@ -389,10 +389,31 @@
procedure Activate_Overflow_Check (N : Node_Id) is
begin
- if not Nkind_In (N, N_Op_Rem, N_Op_Mod, N_Op_Plus) then
- Set_Do_Overflow_Check (N, True);
- Possible_Local_Raise (N, Standard_Constraint_Error);
+ -- Nothing to do for unconstrained floating-point types (the test for
+ -- Etype (N) being present seems necessary in some cases, should be
+ -- tracked down, but for now just ignore the check in this case ???)
+
+ if Present (Etype (N))
+and then Is_Floating_Point_Type (Etype (N))
+and then not Is_Constrained (Etype (N))
+
+-- But do the check after all if float overflow checking enforced
+
+and then not Check_Float_Overflow
+ then
+ return;
end if;
+
+ -- Nothing to do for Rem/Mod/Plus (overflow not possible)
+
+ if Nkind_In (N, N_Op_Rem, N_Op_Mod, N_Op_Plus) then
+ return;
+ end if;
+
+ -- Otherwise set the flag
+
+ Set_Do_Overflow_Check (N, True);
+ Possible_Local_Raise (N, Standard_Constraint_Error);
end Activate_Overflow_Check;
--
Index: checks.ads
===
--- checks.ads (revision 213292)
+++ checks.ads (working copy)
@@ -146,7 +146,9 @@
-- Always call this routine rather than calling Set_Do_Overflow_Check to
-- set an explicit value of True, to ensure handling the local raise case.
-- Note that this call has no effect for MOD, REM, and unary "+" for which
- -- overflow is never possible in any case.
+ -- overflow is never possible in any case. In addition, we do not set the
+ -- flag for unconstrained floating-point type operations, since we want to
+ -- allow for the generation of IEEE infinities in such cases.
procedure Activate_Range_Check (N : Node_Id);
pragma Inline (Activate_Range_Check);
[Ada] SPARK property "effectively volatile" and its effects
This patch implements SPARK property "effectively volatile" which states:
In SPARK 2014, the terms volatile type and volatile object are defined as
per Ada RM C.6(8/3). An effectively volatile type is a volatile type or an
array type to which the Volatile_Components aspect has been applied. An
effectively volatile object is a volatile object or an object of an array
type to which Volatile_Components has been applied.
-- Source --
-- volatile_comps.ads
package Volatile_Comps with SPARK_Mode is
type I is range 1 .. 10;
type VC_Array is array (I) of Integer with Volatile_Components;
type NVC_Array is array (I) of Integer;
Obj_1 : VC_Array with Async_Readers;
Obj_2 : VC_Array with Async_Readers, Effective_Reads;
Obj_3 : NVC_Array with Volatile, Async_Readers;
Obj_4 : NVC_Array with Volatile, Async_Readers, Effective_Reads;
end Volatile_Comps;
-- Compilation and output --
$ gcc -c volatile_comps.ads
volatile_comps.ads:8:04: illegal combination of external properties (SPARK RM
7.1.2(6))
volatile_comps.ads:10:04: illegal combination of external properties (SPARK RM
7.1.2(6))
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-31 Hristian Kirtchev
* freeze.adb (Freeze_Record_Type): Replace all calls to
Is_SPARK_Volatile with Is_Effectively_Volatile and update
related comments.
* sem_ch3.adb (Analyze_Object_Contract, Process_Discriminants):
Replace all calls to Is_SPARK_Volatile with
Is_Effectively_Volatile and update related comments.
* sem_ch5.adb (Analyze_Iterator_Specification,
Analyze_Loop_Parameter_Specification): Replace all calls to
Is_SPARK_Volatile with Is_Effectively_Volatile and update
related comments.
* sem_ch6.adb (Process_Formals): Replace all calls to
Is_SPARK_Volatile with Is_Effectively_Volatile and update
related comments.
* sem_ch12.adb (Instantiate_Object): Replace the call to
Is_SPARK_Volatile_Object with Is_Effectively_Volatile_Object
and update related comment.
* sem_prag.adb (Analyze_External_Property_In_Decl_Part,
Analyze_Global_Item): Replace all calls to Is_SPARK_Volatile
with Is_Effectively_Volatile and update related comments.
* sem_res.adb (Resolve_Actuals, Resolve_Entity_Name): Replace
all calls to Is_SPARK_Volatile with Is_Effectively_Volatile and
update related comments.
* sem_util.adb (Has_Enabled_Property,
Variable_Has_Enabled_Property): Replace all calls
to Is_SPARK_Volatile with Is_Effectively_Volatile and
update related comments.
(Is_Effectively_Volatile): New routine.
(Is_Effectively_Volatile_Object): New routine.
(Is_SPARK_Volatile): Removed.
(Is_SPARK_Volatile_Object): Removed.
* sem_util.ads (Is_Effectively_Volatile): New routine.
(Is_Effectively_Volatile_Object): New routine.
(Is_SPARK_Volatile): Removed.
(Is_SPARK_Volatile_Object): Removed.
Index: freeze.adb
===
--- freeze.adb (revision 213350)
+++ freeze.adb (working copy)
@@ -3472,27 +3472,29 @@
-- they are not standard Ada legality rules.
if SPARK_Mode = On then
-if Is_SPARK_Volatile (Rec) then
+if Is_Effectively_Volatile (Rec) then
- -- A discriminated type cannot be volatile (SPARK RM C.6(4))
+ -- A discriminated type cannot be effectively volatile
+ -- (SPARK RM C.6(4)).
if Has_Discriminants (Rec) then
Error_Msg_N ("discriminated type & cannot be volatile", Rec);
- -- A tagged type cannot be volatile (SPARK RM C.6(5))
+ -- A tagged type cannot be effectively volatile
+ -- (SPARK RM C.6(5)).
elsif Is_Tagged_Type (Rec) then
Error_Msg_N ("tagged type & cannot be volatile", Rec);
end if;
--- A non-volatile record type cannot contain volatile components
--- (SPARK RM C.6(2))
+-- A non-effectively volatile record type cannot contain
+-- effectively volatile components (SPARK RM C.6(2)).
else
Comp := First_Component (Rec);
while Present (Comp) loop
if Comes_From_Source (Comp)
-and then Is_SPARK_Volatile (Etype (Comp))
+and then Is_Effectively_Volatile (Etype (Comp))
then
Error_Msg_Name_1 := Chars (Rec);
Error_Msg_N
Index: sem_ch12.adb
===
--- sem_ch12.adb(revision 213263)
+++ sem_ch12.adb(working copy)
@@ -9905,13 +9905
Re: Patch for constexpr variable templates
On 07/30/2014 05:33 PM, Braden Obrzut wrote: On 07/30/2014 04:44 PM, Jason Merrill wrote: Why not do this in cp_parser_id_expression? I did mention this in the original mail, is this definitely the way it should be done? In the original mail you mentioned doing it in cp_parser_template_id; I agree that we probably don't want to do it there because of the complications you are seeing. I was thinking about doing it when we normally resolve an id-expression that refers to a variable, once we know we're looking at an expression and not a declarator-id. But I think my suggestion of cp_parser_id_expression was wrong, and it would be better in finish_id_expression. Jason
[Ada] Add support for files > 2Gb on 32bit platforms.
This patch set adds support for file larger than 2Gb on 32bit platforms. The main visible change is that Stream_Element_Offset is now a 64bit type on all platforms. The other changes are internal only. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-31 Pascal Obry * a-stream.ads (Stream_Element_Offset): Now a signed 64bit type. * i-cstrea.ads, s-crtl.ads (fseek64): Offset is always a 64bit value. (ftell64): Always returns a 64bit value. * cstreams.c (int64): New definition. (_FILE_OFFSET_BITS): Set to 64 to enable 64bit offset support. (__gnat_ftell64): Always returns a 64bit value. The implemenation now uses ftello() on UNIX. (__gnat_fseek64): Offset is always a 64bit value. The implementation now uses fseeko() on UNIX. * a-ststio.adb, s-direio.adb (Set_Position): Simplify code, always use fseek64 to set the offset. (Size): Simplify code, always use fseek64/ftell64. * s-direio.ads (Count): Now an int64. * g-socket.ads (Vector_Element): Adjust definition for Length to be a size_t. This matches the C definition and avoid using a 64bit integer on 32bit platforms now that Count is always 64bit. * g-socthi-mingw.adb (Ada.Streams): Removed as not used anymore. (C_Recvmsg): Change some conversion to account for change in Vector_Element. (C_Sendmsg): Likewise. Index: a-stream.ads === --- a-stream.ads(revision 213263) +++ a-stream.ads(working copy) @@ -6,7 +6,7 @@ -- -- -- S p e c -- -- -- --- Copyright (C) 1992-2013, Free Software Foundation, Inc. -- +-- Copyright (C) 1992-2014, Free Software Foundation, Inc. -- -- -- -- This specification is derived from the Ada Reference Manual for use with -- -- GNAT. The copyright notice above, and the license provisions that follow -- @@ -41,9 +41,7 @@ type Stream_Element is mod 2 ** Standard'Storage_Unit; - type Stream_Element_Offset is range - -(2 ** (Standard'Address_Size - 1)) .. - +(2 ** (Standard'Address_Size - 1)) - 1; + type Stream_Element_Offset is range -(2 ** 63) .. +(2 ** 63) - 1; subtype Stream_Element_Count is Stream_Element_Offset range 0 .. Stream_Element_Offset'Last; Index: s-crtl.ads === --- s-crtl.ads (revision 213263) +++ s-crtl.ads (working copy) @@ -62,6 +62,8 @@ type ssize_t is range -(2 ** (Standard'Address_Size - 1)) .. +(2 ** (Standard'Address_Size - 1)) - 1; + type int64 is range -(2 ** 63) .. (2 ** 63) - 1; + type Filename_Encoding is (UTF8, ASCII_8bits, Unspecified); for Filename_Encoding use (UTF8 => 0, ASCII_8bits => 1, Unspecified => 2); pragma Convention (C, Filename_Encoding); @@ -147,14 +149,14 @@ function fseek64 (stream : FILEs; - offset : ssize_t; + offset : int64; origin : int) return int; pragma Import (C, fseek64, "__gnat_fseek64"); function ftell (stream : FILEs) return long; pragma Import (C, ftell, "ftell"); - function ftell64 (stream : FILEs) return ssize_t; + function ftell64 (stream : FILEs) return int64; pragma Import (C, ftell64, "__gnat_ftell64"); function getenv (S : String) return System.Address; Index: i-cstrea.ads === --- i-cstrea.ads(revision 213263) +++ i-cstrea.ads(working copy) @@ -43,6 +43,7 @@ subtype long is System.CRTL.long; subtype size_t is System.CRTL.size_t; subtype ssize_t is System.CRTL.ssize_t; + subtype int64 is System.CRTL.int64; subtype voids is System.Address; NULL_Stream : constant FILEs; @@ -159,14 +160,14 @@ function fseek64 (stream : FILEs; - offset : ssize_t; + offset : int64; origin : int) return int renames System.CRTL.fseek64; function ftell (stream : FILEs) return long renames System.CRTL.ftell; - function ftell64 (stream : FILEs) return ssize_t + function ftell64 (stream : FILEs) return int64 renames System.CRTL.ftell64; function fwrite Index: a-ststio.adb === --- a-ststio.adb(revision 213263) +++ a-ststio.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- ---
[Ada] Remove -gnatdm flag
As a first step in removing specific support for the no-longer supported VMS port of GNAT, this patch removes the -gnatdm flag which allowed testing of VMS-specific tests on non-VMS platforms. The test suite has been adjusted appropriately, no additional test is required. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-31 Robert Dewar * cstand.adb (Create_Standard): Remove handling of -gnatdm flag. * debug.adb: Remove documentation of -gnatdm flag. * gnat1drv.adb (Adjust_Global_Switches): Remove handling of -gnatdm flag. Index: debug.adb === --- debug.adb (revision 213361) +++ debug.adb (working copy) @@ -49,7 +49,7 @@ -- dj Suppress "junk null check" for access parameter values -- dk Generate GNATBUG message on abort, even if previous errors -- dl Generate unit load trace messages - -- dm Allow VMS features even if not OpenVMS version + -- dm -- dn Generate messages for node/list allocation -- do Print source from tree (original code only) -- dp Generate messages for parser scope stack push/pops @@ -281,14 +281,6 @@ -- generated each time a request is made to the library manager to -- load a new unit. - -- dm Some features are permitted only in OpenVMS ports of GNAT (e.g. - -- the specification of passing by descriptor). Normally any use - -- of these features will be flagged as an error, but this debug - -- flag allows acceptance of these features in non OpenVMS ports. - -- Of course they may not have any useful effect, and in particular - -- attempting to generate code with this flag set may blow up. - -- The flag also forces the use of 64-bits for Long_Integer. - -- dn Generate messages for node/list allocation. Each time a node or -- list header is allocated, a line of output is generated. Certain -- other basic tree operations also cause a line of output to be Index: gnat1drv.adb === --- gnat1drv.adb(revision 213361) +++ gnat1drv.adb(working copy) @@ -38,7 +38,6 @@ with Fname.UF; use Fname.UF; with Frontend; with Gnatvsn; use Gnatvsn; -with Hostparm; with Inline; with Lib; use Lib; with Lib.Writ; use Lib.Writ; @@ -477,17 +476,11 @@ Ttypes.Bytes_Big_Endian := not Ttypes.Bytes_Big_Endian; end if; - -- Deal with forcing OpenVMS switches True if debug flag M is set, but - -- record the setting of Targparm.Open_VMS_On_Target in True_VMS_Target - -- before doing this, so we know if we are in real OpenVMS or not. + -- Temporarily set True_VMS_Target to OpenVMS_On_Target. This is just + -- temporary, we no longer deal with the debug flag -gnatdm here. Opt.True_VMS_Target := Targparm.OpenVMS_On_Target; - if Debug_Flag_M then - Targparm.OpenVMS_On_Target := True; - Hostparm.OpenVMS := True; - end if; - -- Activate front end layout if debug flag -gnatdF is set if Debug_Flag_FF then Index: cstand.adb === --- cstand.adb (revision 213286) +++ cstand.adb (working copy) @@ -740,18 +740,9 @@ Build_Signed_Integer_Type (Standard_Integer, Standard_Integer_Size); - declare - LIS : Nat; - begin - if Debug_Flag_M then -LIS := 64; - else -LIS := Standard_Long_Integer_Size; - end if; + Build_Signed_Integer_Type +(Standard_Long_Integer, Standard_Long_Integer_Size); - Build_Signed_Integer_Type (Standard_Long_Integer, LIS); - end; - Build_Signed_Integer_Type (Standard_Long_Long_Integer, Standard_Long_Long_Integer_Size); Set_Is_Implementation_Defined (Standard_Long_Long_Integer);
Re: [AArch64_be] Fix vec_select hi/lo mask confusions.
On 30 July 2014 11:10, James Greenhalgh wrote: > 2014-07-30 James Greenhalgh > > * config/aarch64/aarch64.c (aarch64_simd_vect_par_cnst_half): Vary > the generated mask based on BYTES_BIG_ENDIAN. > (aarch64_simd_check_vect_par_cnst_half): New. > * config/aarch64/aarch64-protos.h > (aarch64_simd_check_vect_par_cnst_half): New. > * config/aarch64/predicates.md (vect_par_cnst_hi_half): Refactor > the check out to aarch64_simd_check_vect_par_cnst_half. > (vect_par_cnst_lo_half): Likewise. > * config/aarch64/aarch64-simd.md > (aarch64_simd_move_hi_quad_): Always use vec_par_cnst_lo_half. > (move_hi_quad_): Always generate a low mask. OK with me /Marcus
Re: [PATCH][PING] Add support for KernelAddressSanitizer
On 07/31/2014 08:49 AM, Jeff Law wrote: This is fine. Thanks, Commited in r213367.
Re: [AArch64_be] Don't fold reduction intrinsics.
On 30 July 2014 11:19, James Greenhalgh wrote: > 2014-07-28 James Greenhalgh > > * config/aarch64/aarch64-builtins.c > (aarch64_gimple_fold_builtin): Don't fold reduction operations for > BYTES_BIG_ENDIAN. OK /Marcus
[Ada] Remove VMS specific files
This is part of the Ada front-end clean ups related to the removal of VMS support. More changes to come. Note: I've removed the boring deletions from the diff. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-31 Arnaud Charlet * s-auxdec-vms-ia64.adb, s-parame-vms-alpha.ads, s-asthan-vms-alpha.adb, s-tpopde-vms.adb, s-mastop-vms.adb, s-tpopde-vms.ads, s-taprop-vms.adb, mlib-tgt-vms_common.adb, mlib-tgt-vms_common.ads, s-inmaop-vms.adb, g-enblsp-vms-alpha.adb, s-ransee-vms.adb, s-osprim-vms.adb, s-osprim-vms.ads, g-socthi-vms.adb, g-socthi-vms.ads, system-vms_64.ads, s-osinte-vms.adb, s-osinte-vms.ads, g-eacodu-vms.adb, s-vaflop-vms-alpha.adb, s-parame-vms-ia64.ads, a-dirval-vms.adb, a-caldel-vms.adb, mlib-tgt-specific-vms-alpha.adb, s-tasdeb-vms.adb, symbols-vms.adb, a-intnam-vms.ads, g-expect-vms.adb, symbols-processing-vms-alpha.adb, mlib-tgt-specific-vms-ia64.adb, s-traent-vms.adb, s-traent-vms.ads, i-cstrea-vms.adb, a-numaux-vms.ads, symbols-processing-vms-ia64.adb, s-interr-vms.adb, s-memory-vms_64.adb, s-memory-vms_64.ads, g-enblsp-vms-ia64.adb, s-taspri-vms.ads, s-auxdec-vms_64.ads, s-intman-vms.adb, s-intman-vms.ads, s-tpopsp-vms.adb, s-asthan-vms-ia64.adb, a-calend-vms.adb, a-calend-vms.ads, system-vms-ia64.ads, s-auxdec-vms-alpha.adb: Removed. * namet.h (Is_Non_Ada_Error): Remove. Index: namet.h === --- namet.h (revision 213263) +++ namet.h (working copy) @@ -6,7 +6,7 @@ * * * C Header File * * * - *Copyright (C) 1992-2012, Free Software Foundation, Inc. * + *Copyright (C) 1992-2014, Free Software Foundation, Inc. * * * * GNAT is free software; you can redistribute it and/or modify it under * * terms of the GNU General Public License as published by the Free Soft- * @@ -109,9 +109,6 @@ #define Body_Filename exp_dbug__body_filename extern char *Spec_Filename, *Body_Filename; -#define Is_Non_Ada_Error exp_ch11__is_non_ada_error -extern Boolean Is_Non_Ada_Error (Entity_Id); - /* Here are some functions in sinput.adb we call from trans.c. */ typedef Nat Source_File_Index;
[PATCH] Fix PR61964
This fixes PR61964, we have to rely on structural equality when
determining equivalency of non-register LHS.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-07-31 Richard Biener
PR tree-optimization/61964
* tree-ssa-tail-merge.c (gimple_equal_p): Handle non-SSA LHS solely
by structural equality.
* gcc.dg/torture/pr61964.c: New testcase.
Index: gcc/tree-ssa-tail-merge.c
===
--- gcc/tree-ssa-tail-merge.c (revision 213317)
+++ gcc/tree-ssa-tail-merge.c (working copy)
@@ -1161,17 +1168,9 @@ gimple_equal_p (same_succ same_succ, gim
lhs2 = gimple_get_lhs (s2);
if (TREE_CODE (lhs1) != SSA_NAME
&& TREE_CODE (lhs2) != SSA_NAME)
- {
- /* If the vdef is the same, it's the same statement. */
- if (vn_valueize (gimple_vdef (s1))
- == vn_valueize (gimple_vdef (s2)))
- return true;
-
- /* Test for structural equality. */
- return (operand_equal_p (lhs1, lhs2, 0)
- && gimple_operand_equal_value_p (gimple_assign_rhs1 (s1),
- gimple_assign_rhs1 (s2)));
- }
+ return (operand_equal_p (lhs1, lhs2, 0)
+ && gimple_operand_equal_value_p (gimple_assign_rhs1 (s1),
+gimple_assign_rhs1 (s2)));
else if (TREE_CODE (lhs1) == SSA_NAME
&& TREE_CODE (lhs2) == SSA_NAME)
return vn_valueize (lhs1) == vn_valueize (lhs2);
Index: gcc/testsuite/gcc.dg/torture/pr61964.c
===
--- gcc/testsuite/gcc.dg/torture/pr61964.c (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr61964.c (working copy)
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+
+extern void abort (void);
+
+struct node { struct node *next, *prev; } node;
+struct head { struct node *first; } heads[5];
+int k = 2;
+struct head *head = &heads[2];
+
+static int __attribute__((noinline))
+foo()
+{
+ node.prev = (void *)head;
+ head->first = &node;
+
+ struct node *n = head->first;
+ struct head *h = &heads[k];
+
+ if (n->prev == (void *)h)
+h->first = n->next;
+ else
+n->prev->next = n->next;
+
+ n->next = h->first;
+ return n->next == &node;
+}
+
+int main()
+{
+ if (foo ())
+abort ();
+ return 0;
+}
Re: [PATCH, ARM] Fix PR61948 (ICE with DImode shift by 1 bit)
On 30 July 2014 11:48, Richard Earnshaw wrote:
>> gcc/ChangeLog:
>> 2014-07-29 Charles Baylis
>>
>> PR target/61948
>> * config/arm/neon.md (ashldi3_neon): Don't emit arm_ashldi3_1bit unless
>> constraints are satisfied.
>> (di3_neon): Likewise.
>>
>
> This is OK, but...
>>
>> gcc/testsuite/ChangeLog:
>> 2014-07-29 Charles Baylis
>>
>> PR target/61948
>> * gcc.target/arm/pr61948.c: New test case.
>
> I think this should be using something like:
>
> /* { dg-do compile } */
> /* { dg-require-effective-target arm_neon_ok } */
> /* { dg-require-effective-target arm_thumb2_ok } */
> /* { dg-options "-O2 -mthumb" } */
> /* { dg-add-options arm_neon } */
>
> rather than explicitly adding -mfpu=neon.
I made that change, and committed to trunk as r213376.
Re: [Patch, avr] Add device name to cpp_builtins
2014-07-30 11:19 GMT+04:00 Senthil Kumar Selvaraj : > On Mon, Jul 28, 2014 at 08:09:28PM +0200, Georg-Johann Lay wrote: >> Senthil Kumar Selvaraj schrieb: >> >The below patch adds a new preprocessor define for the device name >> >(__AVR_DEVICE_NAME__) that was passed to the compiler. >> > >> >While the device name macro (say __AVR_ATmega128__) can be used to check >> >for a specific device, there is no way right now for code to get the >> >device name it is being compiled against (without checking >> >for every possible device). >> >> Shouldn't this also be added to the documentation? >> There's a section "AVR Built-in Macros" in the manual. > > Thanks for reminding me, Johann. Here's the patch - if ok, could someone > commit please? > > Regards > Senthil > > 2014-07-30 Senthil Kumar Selvaraj > > * doc/invoke.texi (AVR Options): Add documentation about > __AVR_DEVICE_NAME__ built-in macro. > Committed. Denis.
Re: [PATCH 5/5] add libcc1
On Thu, 31 Jul 2014, Richard Biener wrote: > Actually after looking again I was wrong. main.c and toplev.c > are the "driver". So if we can make all frontends shared objects > with their only interface being their lang_hooks that would be nice > (of course the middle-end still needs to make gazillions of symbols > available to that "plugin"). As far as I know, the main non-lang-hook interface provided by front ends is the "convert" function (and there aren't that many places outside the front ends that still use it). So it shouldn't be hard to get to the state where each front end is only used by its langhooks. (That's a long way from any sort of independent buildability, though; everything still embeds global information about such things as command-line options for all available front ends, and tree codes likewise.) I don't personally like the relics of other such magic-named functions in the form of langhooks-def.h defaulting to a langhook having a particular name that a front end can provide #define LANG_HOOKS_GLOBAL_BINDINGS_P global_bindings_p #define LANG_HOOKS_PUSHDECL pushdecl #define LANG_HOOKS_GETDECLS getdecls and think it would be better for each front end to have unique names for these, with no such default. I think there are a few more cases where C and C++ provide different implementations of a function with the same name for use by c-family code (and ObjC / ObjC++ issues as well, of course). -- Joseph S. Myers jos...@codesourcery.com
Re: [Ada] Remove VMS specific files
On Thu, 31 Jul 2014, Arnaud Charlet wrote: > This is part of the Ada front-end clean ups related to the removal of VMS > support. More changes to come. Will those include obsoletion of the VMS ports (and with them, associated code such as vmsdbgout.c) for GCC as a whole? I don't know if anyone else cares about VMS support. -- Joseph S. Myers jos...@codesourcery.com
Re: [Ada] Remove VMS specific files
On 07/31/2014 08:08 AM, Joseph S. Myers wrote: On Thu, 31 Jul 2014, Arnaud Charlet wrote: This is part of the Ada front-end clean ups related to the removal of VMS support. More changes to come. Will those include obsoletion of the VMS ports (and with them, associated code such as vmsdbgout.c) for GCC as a whole? I don't know if anyone else cares about VMS support. There's a user's group that works with VMS engineering that wants to keep using the "C" compiler, so let's keep the config files and non-Ada specific "C" files. Tristan and I will stay on as maintainers of the cross port for now.
Re: [Ada] Remove VMS specific files
There's a user's group that works with VMS engineering that wants to keep using the "C" compiler, so let's keep the config files and non-Ada specific "C" files. Tristan and I will stay on as maintainers of the cross port for now. Why should we continue to maintain these?
[AArch64] arm_neon.h - add vpaddd_f64, vpaddd_s64, vpaddd_u64 intrinsics
Hi,
This patch adds intrinsics for scalar pairwise addition operations.
The patch only touches arm_neon.h, so tested using aarch64.exp, simd.exp and
an internal testsuite on aarch64-none-elf and aarch64_be-none-elf with no
issues.
OK?
Cheers,
James
---
gcc/
2014-07-31 James Greenhalgh
* config/aarch64/arm_neon.h (vpadd_<8,16,32,64>): Move to
correct alphabetical position.
(vpaddd_f64): Rewrite using builtins.
(vpaddd_s64): Move to correct alphabetical position.
(vpaddd_u64): New.
gcc/testsuite/
2014-07-31 James Greenhalgh
* gcc.target/aarch64/scalar_intrinsics.c (test_vpaddd_f64): New.
(test_vpaddd_s64): Likewise.
(test_vpaddd_s64): Likewise.
* gcc.target/aarch64/simd/vpaddd_f64: New.
* gcc.target/aarch64/simd/vpaddd_s64: New.
* gcc.target/aarch64/simd/vpaddd_u64: New.
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 66968e8..7e6aba7 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -9233,56 +9233,6 @@ vpadd_f32 (float32x2_t a, float32x2_t b)
return result;
}
-__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
-vpadd_s8 (int8x8_t __a, int8x8_t __b)
-{
- return __builtin_aarch64_addpv8qi (__a, __b);
-}
-
-__extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
-vpadd_s16 (int16x4_t __a, int16x4_t __b)
-{
- return __builtin_aarch64_addpv4hi (__a, __b);
-}
-
-__extension__ static __inline int32x2_t __attribute__ ((__always_inline__))
-vpadd_s32 (int32x2_t __a, int32x2_t __b)
-{
- return __builtin_aarch64_addpv2si (__a, __b);
-}
-
-__extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
-vpadd_u8 (uint8x8_t __a, uint8x8_t __b)
-{
- return (uint8x8_t) __builtin_aarch64_addpv8qi ((int8x8_t) __a,
- (int8x8_t) __b);
-}
-
-__extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
-vpadd_u16 (uint16x4_t __a, uint16x4_t __b)
-{
- return (uint16x4_t) __builtin_aarch64_addpv4hi ((int16x4_t) __a,
- (int16x4_t) __b);
-}
-
-__extension__ static __inline uint32x2_t __attribute__ ((__always_inline__))
-vpadd_u32 (uint32x2_t __a, uint32x2_t __b)
-{
- return (uint32x2_t) __builtin_aarch64_addpv2si ((int32x2_t) __a,
- (int32x2_t) __b);
-}
-
-__extension__ static __inline float64_t __attribute__ ((__always_inline__))
-vpaddd_f64 (float64x2_t a)
-{
- float64_t result;
- __asm__ ("faddp %d0,%1.2d"
- : "=w"(result)
- : "w"(a)
- : /* No clobbers */);
- return result;
-}
-
__extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
vpaddl_s8 (int8x8_t a)
{
@@ -12563,12 +12513,6 @@ vaddlv_u32 (uint32x2_t a)
return result;
}
-__extension__ static __inline int64_t __attribute__ ((__always_inline__))
-vpaddd_s64 (int64x2_t __a)
-{
- return __builtin_aarch64_addpdi (__a);
-}
-
__extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
vqdmulh_laneq_s16 (int16x4_t __a, int16x8_t __b, const int __c)
{
@@ -19230,6 +19174,65 @@ vnegq_s64 (int64x2_t __a)
return -__a;
}
+/* vpadd */
+
+__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
+vpadd_s8 (int8x8_t __a, int8x8_t __b)
+{
+ return __builtin_aarch64_addpv8qi (__a, __b);
+}
+
+__extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
+vpadd_s16 (int16x4_t __a, int16x4_t __b)
+{
+ return __builtin_aarch64_addpv4hi (__a, __b);
+}
+
+__extension__ static __inline int32x2_t __attribute__ ((__always_inline__))
+vpadd_s32 (int32x2_t __a, int32x2_t __b)
+{
+ return __builtin_aarch64_addpv2si (__a, __b);
+}
+
+__extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
+vpadd_u8 (uint8x8_t __a, uint8x8_t __b)
+{
+ return (uint8x8_t) __builtin_aarch64_addpv8qi ((int8x8_t) __a,
+ (int8x8_t) __b);
+}
+
+__extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
+vpadd_u16 (uint16x4_t __a, uint16x4_t __b)
+{
+ return (uint16x4_t) __builtin_aarch64_addpv4hi ((int16x4_t) __a,
+ (int16x4_t) __b);
+}
+
+__extension__ static __inline uint32x2_t __attribute__ ((__always_inline__))
+vpadd_u32 (uint32x2_t __a, uint32x2_t __b)
+{
+ return (uint32x2_t) __builtin_aarch64_addpv2si ((int32x2_t) __a,
+ (int32x2_t) __b);
+}
+
+__extension__ static __inline float64_t __attribute__ ((__always_inline__))
+vpaddd_f64 (float64x2_t __a)
+{
+ return vgetq_lane_f64 (__builtin_aarch64_reduc_splus_v2df (__a), 0);
+}
+
+__extension__ static __inline int64_t __attribute__ ((__always_inline__))
+vpaddd_s64 (int64x2_t __a)
+{
+ return __builtin_aarch64_addpdi (__a);
+}
+
+__extension__ static __inline uint64_t __attribute__ ((__always_inline__))
+vpaddd_u64 (uint64x2_t __a)
+{
+ return __builtin_aarch64_addpdi ((int64x2_t) __a);
+}
+
/* vqabs */
__extension__ static __inline int64x2_t __attribute__ ((__always_inline__))
diff --git a/gcc/testsuite/gcc.target/aar
Re: [PATCH, rs6000] Use new __builtin_pack_longdouble within libgcc's ibm-ldouble.c
On Wed, 2014-07-30 at 22:13 -0400, David Edelsohn wrote: > On Tue, Jul 29, 2014 at 10:56 AM, Peter Bergner wrote: > > libgcc/ > > * config/rs6000/ibm-ldouble.c (typedef union longDblUnion): Delete. > > (pack_ldouble): New function. > > (__gcc_qadd): Use it. > > (__gcc_qmul): Likewise. > > (__gcc_qdiv): Likewise. > > (__gcc_qneg): Likewise. > > (__gcc_stoq): Likewise. > > (__gcc_dtoq): Likewise. > > Okay. Committed as revision 213380. Thanks. Peter
Re: [PATCH, rs6000] Use new __builtin_pack_longdouble within libgcc's ibm-ldouble.c
On Tue, 2014-07-29 at 10:11 -0700, Mike Stump wrote: > On Jul 29, 2014, at 7:56 AM, Peter Bergner wrote: > > Currently, the IBM long double routines in libgcc use a union to construct > > a long double from two double values. This causes horrific code generation > > that copies the two double from the FP registers over to GPRs and back > > again, giving us two loads and two stores, which leads to two load-hit-store > > hazzards. > > Gosh, it’s too bad we don’t have any sort of technology to optimize moving > data around. Well the problem is we're trying to move it around, when we'd really like the data to stay in the FP registers the entire time. The problem is that unions and structs that are the same size as a TImode/TFmode/TDmode are always converted to TImode and that is what ends up causing the whole fp -> int -> fp shuffle which leads to crappy code. On power8 where we have int <-> fp reg copy instructions, it's better than the copy thru the stack frame, but even that is unnecessary. Peter
[SH][committed] Fix PR 61844
Hello,
Attached patch fixes sh64 build issues and was committed as r213381 to
trunk. Tested by building an sh64-elf newlib cross compiler for C and
C++. Non-sh64 sh-elf should not be affected by the patch, since
ALLOW_INDEXED_ADDRESS is always 'true' on sh-elf. Thus, tested only
with 'make all' for sh-elf only. Backports to 4.9 and 4.8 will follow.
Cheers,
Oleg
gcc/ChangeLog:
PR target/61844
* config/sh/sh.c (sh_legitimate_address_p,
sh_legitimize_reload_address): Handle reg+reg address modes when
ALLOW_INDEXED_ADDRESS is false.
* config/sh/predicates.md (general_movsrc_operand,
general_movdst_operand): Likewise.
Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md (revision 212271)
+++ gcc/config/sh/predicates.md (working copy)
@@ -489,6 +489,10 @@
rtx mem_rtx = MEM_P (op) ? op : SUBREG_REG (op);
rtx x = XEXP (mem_rtx, 0);
+ if (! ALLOW_INDEXED_ADDRESS
+ && GET_CODE (x) == PLUS && REG_P (XEXP (x, 0)) && REG_P (XEXP (x, 1)))
+ return false;
+
if ((mode == QImode || mode == HImode)
&& GET_CODE (x) == PLUS
&& REG_P (XEXP (x, 0))
@@ -567,6 +571,10 @@
rtx mem_rtx = MEM_P (op) ? op : SUBREG_REG (op);
rtx x = XEXP (mem_rtx, 0);
+ if (! ALLOW_INDEXED_ADDRESS
+ && GET_CODE (x) == PLUS && REG_P (XEXP (x, 0)) && REG_P (XEXP (x, 1)))
+ return false;
+
if ((mode == QImode || mode == HImode)
&& GET_CODE (x) == PLUS
&& REG_P (XEXP (x, 0))
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 212271)
+++ gcc/config/sh/sh.c (working copy)
@@ -10287,6 +10287,10 @@
static bool
sh_legitimate_address_p (enum machine_mode mode, rtx x, bool strict)
{
+ if (! ALLOW_INDEXED_ADDRESS
+ && GET_CODE (x) == PLUS && REG_P (XEXP (x, 0)) && REG_P (XEXP (x, 1)))
+return false;
+
if (REG_P (x) && REGNO (x) == GBR_REG)
return true;
@@ -10516,6 +10520,28 @@
enum reload_type type = (enum reload_type) itype;
const int mode_sz = GET_MODE_SIZE (mode);
+ if (! ALLOW_INDEXED_ADDRESS
+ && GET_CODE (*p) == PLUS
+ && REG_P (XEXP (*p, 0)) && REG_P (XEXP (*p, 1)))
+{
+ *p = copy_rtx (*p);
+ push_reload (*p, NULL_RTX, p, NULL,
+ BASE_REG_CLASS, Pmode, VOIDmode, 0, 0, opnum, type);
+ return true;
+}
+
+ if (! ALLOW_INDEXED_ADDRESS
+ && GET_CODE (*p) == PLUS
+ && GET_CODE (XEXP (*p, 0)) == PLUS)
+{
+ rtx sum = gen_rtx_PLUS (Pmode, XEXP (XEXP (*p, 0), 0),
+ XEXP (XEXP (*p, 0), 1));
+ *p = gen_rtx_PLUS (Pmode, sum, XEXP (*p, 1));
+ push_reload (sum, NULL_RTX, &XEXP (*p, 0), NULL,
+ BASE_REG_CLASS, Pmode, VOIDmode, 0, 0, opnum, type);
+ return true;
+}
+
if (TARGET_SHMEDIA)
return false;
Re: [AArch64] arm_neon.h - add vpaddd_f64, vpaddd_s64, vpaddd_u64 intrinsics
On 31 July 2014 17:12, James Greenhalgh wrote: > --- > gcc/ > > 2014-07-31 James Greenhalgh > > * config/aarch64/arm_neon.h (vpadd_<8,16,32,64>): Move to > correct alphabetical position. > (vpaddd_f64): Rewrite using builtins. > (vpaddd_s64): Move to correct alphabetical position. > (vpaddd_u64): New. > > gcc/testsuite/ > > 2014-07-31 James Greenhalgh > > * gcc.target/aarch64/scalar_intrinsics.c (test_vpaddd_f64): New. > (test_vpaddd_s64): Likewise. > (test_vpaddd_s64): Likewise. > * gcc.target/aarch64/simd/vpaddd_f64: New. > * gcc.target/aarch64/simd/vpaddd_s64: New. > * gcc.target/aarch64/simd/vpaddd_u64: New. OK /Marcus
[C++ Patch] DR 217 follow up (and more)
Hi,
today I noticed that when we implemented the resolution we failed to
handle static member functions. The below tested x86_64-linux.
While working on this I noticed that we don't use the
DECL_NONSTATIC_MEMBER_FUNCTION_P macro much, should we apply something
like the attached?
Finally, if you are wondering instead how I noticed the former ;) I have
been working on c++/15339, which seems relatively easy to resolve. Ie,
rejecting in duplicate_decls
template void fun(int);
template void fun(int = 0);
however, handling correctly the member case:
class A
{
template void fun(int);
};
template void A::fun(int = 0) { }
is more tricky because we don't want to start rejecting:
class A
{
void fun(int);
};
void A::fun(int = 0) { }
which is well formed. The problem is that when grokfndecl calls
duplicate_decls in such member cases it looks through TEMPLATE_DECLs, eg:
if (TREE_CODE (old_decl) == TEMPLATE_DECL)
/* Because grokfndecl is always supposed to return a
FUNCTION_DECL, we pull out the DECL_TEMPLATE_RESULT
here. We depend on our callers to figure out that its
really a template that's being returned. */
old_decl = DECL_TEMPLATE_RESULT (old_decl);
and then telling apart the two cases above is tough, both are
FUNCTION_DECLs :(
Ideas about the best way to handle that? Anything less delicate than
trying *not* to use DECL_TEMPLATE_RESULT that early and passing the
TEMPLATE_DECLs as they are to duplicate_decls and then using it only
right before returning from grokfndecl?
Thanks!
Paolo.
///
/cp
2014-07-31 Paolo Carlini
DR 217 again
* decl.c (duplicate_decls): Handle static member functions too.
/testsuite
2014-07-31 Paolo Carlini
DR 217 again
* g++.dg/tc1/dr217-2.C: New.
Index: cp/decl.c
===
--- cp/decl.c (revision 213379)
+++ cp/decl.c (working copy)
@@ -1710,10 +1710,10 @@ duplicate_decls (tree newdecl, tree olddecl, bool
tree t2 = TYPE_ARG_TYPES (TREE_TYPE (newdecl));
int i = 1;
- if (TREE_CODE (TREE_TYPE (newdecl)) == METHOD_TYPE)
+ if (DECL_NONSTATIC_MEMBER_FUNCTION_P (newdecl))
t1 = TREE_CHAIN (t1), t2 = TREE_CHAIN (t2);
- if (TREE_CODE (TREE_TYPE (newdecl)) == METHOD_TYPE
+ if (DECL_FUNCTION_MEMBER_P (newdecl)
&& CLASSTYPE_TEMPLATE_INFO (CP_DECL_CONTEXT (newdecl)))
{
/* C++11 8.3.6/6.
Index: testsuite/g++.dg/tc1/dr217-2.C
===
--- testsuite/g++.dg/tc1/dr217-2.C (revision 0)
+++ testsuite/g++.dg/tc1/dr217-2.C (working copy)
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// DR217: Default arguments for non-template member functions of class
+// templates
+
+template
+struct S
+{
+ static void foo (int);
+};
+
+template
+void S::foo (int = 0) // { dg-error "" "default arguments for parameters
of member functions of class templates can be specified in the initial
declaration only" }
+{ }
Index: call.c
===
--- call.c (revision 213379)
+++ call.c (working copy)
@@ -7038,7 +7038,7 @@ build_over_call (struct z_candidate *cand, int fla
}
}
/* Bypass access control for 'this' parameter. */
- else if (TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE)
+ else if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn))
{
tree parmtype = TREE_VALUE (parm);
tree arg = build_this (first_arg != NULL_TREE
@@ -8026,7 +8026,7 @@ build_new_method_call_1 (tree instance, tree fns,
fn);
}
- if (TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE
+ if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
&& !DECL_CONSTRUCTOR_P (fn)
&& is_dummy_object (instance))
{
@@ -8071,7 +8071,7 @@ build_new_method_call_1 (tree instance, tree fns,
/* In an expression of the form `a->f()' where `f' turns
out to be a static member function, `a' is
none-the-less evaluated. */
- if (TREE_CODE (TREE_TYPE (fn)) != METHOD_TYPE
+ if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
&& !is_dummy_object (instance)
&& TREE_SIDE_EFFECTS (instance))
call = build2 (COMPOUND_EXPR, TREE_TYPE (call),
Index: class.c
===
--- class.c (revision 213379)
+++ class.c (working copy)
@@ -7306,7 +7306,7 @@ resolve_address_of_overloaded_function (tree targe
pointer-to-member types, not the internal POINTER_TYPE to
METHOD_TYPE representation. */
gcc_assert (!TYPE_PTR_P (target_type)
- || TREE_CODE (TREE_TYPE (target_type)) != METHOD_TYPE);
+ || !DECL_NONSTATIC_MEMBER_FUNCTION_P (target_type));
Re: [PATCH] Fix mklog to support running from arbitrary folder
On Mon, Jul 21, 2014 at 4:32 AM, Yury Gribov wrote: > Hi all, > > Current mklog works only if run from GCC top-level folder. The patch allows > running from arbitrary directory. > > I've used Linux directory separators which is probably ok because script > already expects Linux environment (dirname, basename, etc.). > > Ok to commit? OK. Thanks. Diego.
RE: [RFC: Patch, PR 60102] [4.9/4.10 Regression] powerpc fp-bit ices@dwf_regno
Ulrich,
Thanks for your comments, I have updated the patch accordingly.
> > /* The SPE has an additional 32 synthetic registers, with DWARF debug
> > info numbering for these registers starting at 1200. While
> > eh_frame @@ -951,13 +952,14 @@ enum data_align { align_abi, align_opt,
> > We must map them here to avoid huge unwinder tables mostly consisting
> > of unused space. */
> > #define DWARF_REG_TO_UNWIND_COLUMN(r) \
> > - ((r) > 1200 ? ((r) - 1200 + (DWARF_FRAME_REGISTERS - 32)) : (r))
> > + ((r) >= FIRST_SPE_HIGH_REGNO ? ((r) - FIRST_SPE_HIGH_REGNO +
> > + (DWARF_FRAME_REGISTERS - 32)) : (r))
>
> As discussed above, this shouldn't change.
Updated to handle first SPE high register too.
#define DWARF_REG_TO_UNWIND_COLUMN(r) \
- ((r) > 1200 ? ((r) - 1200 + (DWARF_FRAME_REGISTERS - 32)) : (r))
+ ((r) >= 1200 ? ((r) - 1200 + (DWARF_FRAME_REGISTERS - 32)) : (r)
Tested this patch on trunk [213030] & GCC v4.9.1 with ppc64 and didn't find any
new regressions.
Back ported this patch on GCC v4.8.3 e500v2 and tested with no new regressions
PR target/60102
[libgcc]
2014-07-31 Rohit
* config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update
based on change in SPE high register numbers and 3 HTM registers.
[gcc]
2014-07-31 Rohit
* config/rs6000/rs6000.c
(rs6000_reg_names) : Add SPE high register names.
(alt_reg_names) : Likewise
(rs6000_dwarf_register_span) : For SPE high registers, replace
dwarf register numbers with GCC hard register numbers.
(rs6000_init_dwarf_reg_sizes_extra) : Likewise.
(rs6000_dbx_register_number): For SPE high registers, return dwarf
register number for the corresponding GCC hard register number.
* config/rs6000/rs6000.h
(FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard
register numbers for SPE high registers.
(DWARF_FRAME_REGISTERS) : Likewise.
(DWARF_REG_TO_UNWIND_COLUMN) : Likewise.
(DWARF_FRAME_REGNUM) : Likewise.
(FIXED_REGISTERS) : Likewise.
(CALL_USED_REGISTERS) : Likewise.
(CALL_REALLY_USED_REGISTERS) : Likewise.
(REG_ALLOC_ORDER) : Likewise.
(enum reg_class) : Likewise.
(REG_CLASS_NAMES) : Likewise.
(REG_CLASS_CONTENTS) : Likewise.
(SPE_HIGH_REGNO_P) : New macro to identify SPE high registers.
* gcc.target/powerpc/pr60102.c: New testcase.
Please let me know if you have any further comments on the updated patch.
Regards,
Rohit
pr60102.patch
Description: pr60102.patch
Re: [Patch] Not very subtle fix for pr61510
On Mon, Jun 23, 2014 at 06:43:20PM +0100, Jan Hubicka wrote:
> > On Mon, 23 Jun 2014, James Greenhalgh wrote:
> >
> > >
> > > Hi,
> > >
> > > pr61510 is a case where cgraphunit.c::analyze_functions can end up
> > > dereferencing a NULL pointer. This is, to me, the obvious way to avoid
> > > dereferencing NULL.
> > >
> > > However, I'm not very confident that this isn't just masking some
> > > horrible and subtle bug, so I'd like some review feedback on the patch.
> > >
> > > Tested on aarch64-none-elf, where I was seeing the issue.
> > >
> > > OK?
> >
> > Obvious in some sense to me, too, but I wonder why we don't have a cgraph
> > node
> > for it and what happens if it is created later (and then doesn't
> > have the flag set)?
>
> In that case we won't get the used_as_abstract_origin flag. that will make us
> to throw away the debug info if we remove it. I guess we simply want
> graph_get_create_node here. I can prepare patch tonight (after teaching)
I've spun a patch with what I think you were suggesting here.
Tested on aarch64-none-elf with no regressions to confirm it fixes the
bug and bootstrapped on x86 and aarch64 with no issues.
OK?
Thanks,
James
---
2014-07-31 James Greenhalgh
PR regression/61510
* cgraphunit.c (analyze_functions): Use get_create rather than get
for decls which are clones of abstract functions.
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 3080b9a..02c9fa1 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1047,7 +1047,7 @@ analyze_functions (void)
if (DECL_ABSTRACT_ORIGIN (decl))
{
struct cgraph_node *origin_node
- = cgraph_node::get (DECL_ABSTRACT_ORIGIN (decl));
+ = cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (decl));
origin_node->used_as_abstract_origin = true;
}
}
[PATCH][committed] Remove superfluous declaration in testcase
Hi,
This patch removes a superfluous declaration in a test-case.
Committed to trunk.
Thanks,
- Tom
2014-07-31 Tom de Vries
* gcc.dg/pr51879-7.c: Remove superfluous declaration of bar.
diff --git a/gcc/testsuite/gcc.dg/pr51879-7.c b/gcc/testsuite/gcc.dg/pr51879-7.c
index 6c1d320..8a699a1 100644
--- a/gcc/testsuite/gcc.dg/pr51879-7.c
+++ b/gcc/testsuite/gcc.dg/pr51879-7.c
@@ -1,8 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-pre" } */
-int bar (int);
-
int z;
void
Re: [PATCH 5/5] add libcc1
Richard> Can you briefly elaborate on how this relates to the JIT work from Richard> David Malcom? I think Trevor answered this bit well but I had a bit more to add... Richard> Just throwing in my mental notes from the Summit here. I really Richard> wonder how libcc1 falls in into this picture and if it would stand Richard> in the way of re-organizing main program flow and/or making Richard> frontends shared objects. FWIW the plugin is really quite small. It uses just a few things from the C front end. Earlier patches in the series also add a couple of ad hoc hooks to the C front end so that the plugin can insert itself. However it really isn't much -- primarily I think due to the simplicity of C; I expect hooking into g++ will be trickier. I don't think this plugin will be much of a barrier to anything in gcc. It hooks in to gcc in the same way as any other plugin (aside from those ad hoc hooks). You can look through plugin.cc in the patch to see what parts of gcc's internals uses. One way of looking at it is -- if gcc changes break this plugin, they'll probably break every plugin. So it's a good thing :) Richard> [ideally both frontends and targets would be shared objects, but of Richard> course even frontends have target dependencies pulled in via Richard> target macros at the moment...] We actually started development with this approach. Our first working version of this project was based on David Malcolm's JIT branch. We turned cc1 into a .so and had gdb dlopen it. Then we did the compilation parts in-process. We ended up going with the plugin approach because it has better fault tolerance. With the cc1.so approach, if we could provoke a crash -- not uncommon given that we were calling gcc internals in a new and exciting way -- then the whole debug session came down. Using a plugin avoids this. If gcc crashes, gdb can report an error and continue on. This is much friendlier for users, making it worth the extra effort of dealing with multiple processes, RPC, etc. Also, our fears about the performance of this approach were unfounded, I imagine because we're generally dealing with very small inputs. Tom
Re: [PATCH 5/5] add libcc1
On Thu, Jul 31, 2014 at 01:12:54PM -0600, Tom Tromey wrote: > Richard> [ideally both frontends and targets would be shared objects, but of > Richard> course even frontends have target dependencies pulled in via > Richard> target macros at the moment...] > > We actually started development with this approach. Our first working > version of this project was based on David Malcolm's JIT branch. We > turned cc1 into a .so and had gdb dlopen it. Then we did the > compilation parts in-process. > > We ended up going with the plugin approach because it has better fault > tolerance. With the cc1.so approach, if we could provoke a crash -- not > uncommon given that we were calling gcc internals in a new and exciting > way -- then the whole debug session came down. > > Using a plugin avoids this. If gcc crashes, gdb can report an error and > continue on. This is much friendlier for users, making it worth the > extra effort of dealing with multiple processes, RPC, etc. Also, our > fears about the performance of this approach were unfounded, I imagine > because we're generally dealing with very small inputs. Given that what GDB wants is not a JIT, but reuse the C (and later on C++) FEs, I think the plugin approach is just fine for this. Jakub
[PATCH][testsuite] Don't run cproj-fails-with-broken-glibc.c for broken glibc
Rainer,
The test-case cproj-fails-with-broken-glibc.c does not work with broken glibcs,
as the header comment mentions:
...
Check the runtime behavior of the C library's cproj() function and
whether it follows the standard. Versions of GLIBC through 2.11.1
had an incorrect implementation which will conflict with GCC's
builtin cproj(). GLIBC 2.12+ should be okay.
...
This patch skips the test for known broken glibcs. OK for trunk?
Thanks,
- Tom
2014-07-31 Tom de Vries
* lib/target-supports.exp (check_effective_target_glibc)
(check_effective_target_glibc_2_12_or_later)
(check_effective_target_not_glibc_2_11_or_earlier): New proc.
* gcc.dg/cproj-fails-with-broken-glibc.c: Require effective target
not_glibc_2_11_or_earlier.
diff --git a/gcc/testsuite/gcc.dg/cproj-fails-with-broken-glibc.c b/gcc/testsuite/gcc.dg/cproj-fails-with-broken-glibc.c
index fe143b9..1df29f9 100644
--- a/gcc/testsuite/gcc.dg/cproj-fails-with-broken-glibc.c
+++ b/gcc/testsuite/gcc.dg/cproj-fails-with-broken-glibc.c
@@ -11,6 +11,7 @@
/* { dg-options "-fno-builtin-cproj" } */
/* { dg-add-options c99_runtime } */
/* { dg-require-effective-target c99_runtime } */
+/* { dg-require-effective-target not_glibc_2_11_or_earlier } */
extern void abort(void);
extern void exit(int);
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index fa5137e..cbe2930 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5038,6 +5038,44 @@ proc check_effective_target_newlib {} {
}]
}
+# Return true if this is a glibc target.
+
+proc check_effective_target_glibc {} {
+return [check_no_compiler_messages glibc object {
+ #include
+ #if !(defined (__GLIBC__) && defined (__GLIBC_MINOR__))
+ #error FOO
+ #endif
+}]
+}
+
+# Return true if this is a glibc 2.12 or later target.
+
+proc check_effective_target_glibc_2_12_or_later {} {
+return [check_no_compiler_messages glibc_2_12_or_later object {
+ #include
+ #if !(defined (__GLIBC__) && defined (__GLIBC_MINOR__) \
+ && __GLIBC_PREREQ(2,12))
+ #error FOO
+ #endif
+}]
+}
+
+# Return true if this is a not a glibc 2.11 or earlier target.
+
+proc check_effective_target_not_glibc_2_11_or_earlier {} {
+
+if { ![check_effective_target_glibc] } {
+ return 1
+}
+
+if { [check_effective_target_glibc_2_12_or_later] } {
+ return 1
+}
+
+return 0
+}
+
# Return true if this is NOT a Bionic target.
proc check_effective_target_non_bionic {} {
--
1.9.1
RE: [PATCH 1/3, Cilk+] Fix for PR61455
Ping
> -Original Message-
> From: Zamyatin, Igor
> Sent: Saturday, July 12, 2014 1:52 PM
> To: GCC Patches (gcc-patches@gcc.gnu.org)
> Subject: [PATCH 1/3, Cilk+] Fix for PR61455
>
> Hi!
>
> This simple change fixes the issue with printing of error message (happened
> in unprintable_error routine of the PR's test) Regtested with the next patch
> of this chain.
>
> Ok for trunk/4.9?
>
> Thanks,
> Igor
>
> gcc/cp/Changelog:
>
> 2014-07-08 Igor Zamyatin
>
> * cp-array-notation.c (expand_an_in_modify_expr): Fix the misprint
> in error output.
>
>
> diff --git a/gcc/cp/cp-array-notation.c b/gcc/cp/cp-array-notation.c index
> b45449b..6b910fc 100644
> --- a/gcc/cp/cp-array-notation.c
> +++ b/gcc/cp/cp-array-notation.c
> @@ -607,7 +607,7 @@ expand_an_in_modify_expr (location_t location, tree
> lhs,
>
> if (lhs_rank == 0 && rhs_rank != 0)
> {
> - error_at (location, "%qD cannot be scalar when %qD is not", lhs, rhs);
> + error_at (location, "%qE cannot be scalar when %qE is not", lhs,
> +rhs);
> return error_mark_node;
> }
> if (lhs_rank != 0 && rhs_rank != 0 && lhs_rank != rhs_rank)
Re: [PATCH 5/5] add libcc1
On Thu, Jul 31, 2014 at 01:12:54PM -0600, Tom Tromey wrote: > Richard> Can you briefly elaborate on how this relates to the JIT work from > Richard> David Malcom? > > I think Trevor answered this bit well but I had a bit more to add... > > Richard> Just throwing in my mental notes from the Summit here. I really > Richard> wonder how libcc1 falls in into this picture and if it would stand > Richard> in the way of re-organizing main program flow and/or making > Richard> frontends shared objects. > > FWIW the plugin is really quite small. It uses just a few things from > the C front end. Earlier patches in the series also add a couple of ad > hoc hooks to the C front end so that the plugin can insert itself. > However it really isn't much -- primarily I think due to the simplicity > of C; I expect hooking into g++ will be trickier. > > I don't think this plugin will be much of a barrier to anything in gcc. > It hooks in to gcc in the same way as any other plugin (aside from those > ad hoc hooks). You can look through plugin.cc in the patch to see what > parts of gcc's internals uses. the plugin part seems fine, but I do find my self wondering if there's a better way of doing the hooks into C, if they can be more genrally useful. I'm not complaining about them at all it just seems like its worth thinking about what they tell us we should make better in the future. > One way of looking at it is -- if gcc changes break this plugin, they'll > probably break every plugin. So it's a good thing :) > > Richard> [ideally both frontends and targets would be shared objects, but of > Richard> course even frontends have target dependencies pulled in via > Richard> target macros at the moment...] > > We actually started development with this approach. Our first working > version of this project was based on David Malcolm's JIT branch. We > turned cc1 into a .so and had gdb dlopen it. Then we did the > compilation parts in-process. > > We ended up going with the plugin approach because it has better fault > tolerance. With the cc1.so approach, if we could provoke a crash -- not > uncommon given that we were calling gcc internals in a new and exciting > way -- then the whole debug session came down. out of process seems very reasonable, but I do hope we'll fix the crashes since there's any number of other uses for cc1 as a library. Trev > Using a plugin avoids this. If gcc crashes, gdb can report an error and > continue on. This is much friendlier for users, making it worth the > extra effort of dealing with multiple processes, RPC, etc. Also, our > fears about the performance of this approach were unfounded, I imagine > because we're generally dealing with very small inputs. > > Tom
Re: [PATCH 5/5] add libcc1
> "Trevor" == Trevor Saunders writes: Trevor> the plugin part seems fine, but I do find my self wondering if there's a Trevor> better way of doing the hooks into C, if they can be more genrally Trevor> useful. There's just one now, the binding oracle. (There used to be two but we reimplemented the second one by overriding a langhook from the plugin.) The binding oracle could perhaps be redone as an ordinary plugin event. It didn't seem that worthwhile to me, but if someone else has a use, it seems doable. Trevor> out of process seems very reasonable, but I do hope we'll fix the Trevor> crashes since there's any number of other uses for cc1 as a library. The ones I recall were all things like the plugin making a tree incorrectly. This could still be an issue but it is one unlikely to be hit in ordinary uses of the compiler. I agree any such things are bugs though. Tom
[PATCH, Cilk+] Fix for PR61962
Hi!
This patch fixes endless compilation for the case of array notation for an
array which is a structure member
Ok for trunk/4.9 once testing finished?
Thanks,
Igor
Changelog:
gcc/c-family:
2014-07-31 Igor Zamyatin
PR other/61962
* array-notation-common.c (find_rank): Added handling for other
types of references.
gcc/testsuite:
2014-07-31 Igor Zamyatin
PR other/61962
* c-c++-common/cilk-plus/AN/pr61962.c: New test.
diff --git a/gcc/c-family/array-notation-common.c
b/gcc/c-family/array-notation-common.c
index c010039..5db14c6 100644
--- a/gcc/c-family/array-notation-common.c
+++ b/gcc/c-family/array-notation-common.c
@@ -221,7 +221,9 @@ find_rank (location_t loc, tree orig_expr, tree expr, bool
ignore_builtin_fn,
current_rank++;
ii_tree = ARRAY_NOTATION_ARRAY (ii_tree);
}
- else if (TREE_CODE (ii_tree) == ARRAY_REF)
+ else if (TREE_CODE (ii_tree) == ARRAY_REF
+ || TREE_CODE (ii_tree) == INDIRECT_REF
+ || TREE_CODE (ii_tree) == COMPONENT_REF)
ii_tree = TREE_OPERAND (ii_tree, 0);
else if (TREE_CODE (ii_tree) == PARM_DECL
|| TREE_CODE (ii_tree) == VAR_DECL)
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61962.c
b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61962.
new file mode 100644
index 000..08d4fe2
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61962.c
@@ -0,0 +1,14 @@
+/* PR other/61962 */
+/* { dg-do compile } */
+/* { dg-options "-fcilkplus" } */
+
+struct FloatStruct
+{
+float *f;
+};
+
+/* Either SRC or DST must be a struct, otherwise the bug does not occur. */
+void f (struct FloatStruct* dst, float *src, unsigned int length)
+{
+dst->f[0:length] = src[0:length];
+}
[PATCH, Cilk+] Fix for PR61963
Hi!
This patch fixes the ICE on invalid code by adding missed check for
error_mark_node.
Regtested on x86_64. Ok for trunk/4.9?
Thanks,
Igor
Changelog:
gcc/cp:
2014-07-31 Igor Zamyatin
PR other/61963
* parser.c (cp_parser_array_notation): Added check for array_type.
gcc/testsuite:
2014-07-31 Igor Zamyatin
PR other/61963
* c-c++-common/cilk-plus/AN/pr61963.c: New test.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 32c7a3f..be071a8 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6376,7 +6376,7 @@ cp_parser_array_notation (location_t loc, cp_parser
*parser, tree *init_index,
parser->colon_corrects_to_scope_p = saved_colon_corrects;
if (*init_index == error_mark_node || length_index == error_mark_node
- || stride == error_mark_node)
+ || stride == error_mark_node || array_type == error_mark_node)
{
if (cp_lexer_peek_token (parser->lexer)->type == CPP_CLOSE_SQUARE)
cp_lexer_consume_token (parser->lexer);
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61963.c
b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61963.
new file mode 100644
index 000..dfa713c
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61963.c
@@ -0,0 +1,9 @@
+/* PR other/61963 */
+/* { dg-do compile } */
+/* { dg-options "-fcilkplus" } */
+
+void f (int * int *a) /* { dg-error "expected" } */
+{
+a[0:64] = 0; /* { dg-error "was not declared" "" { target c++ } 7 } */
+a[0:64] = 0;
+}
[PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option
Hi
This patchset will add a new configure options --enable-default-pie.
With the new option enable will make it pass -fPIE and -pie from the gcc and
g++ frontend. Have only add the support for two targets but should work on
more targes. In configure.ac we add the new option. We can't compile the
compiler or the crt stuff with -fPIE it will brake the PCH and the crtbegin and
crtend files. The disabling is done in the Makefiles. The needed spec is added
to DRIVER_SELF_SPECS. We disable all the profiling test for the linking will
fail. Tested on x86_64 linux (Gentoo).
More and more Linux/gnu distributions compile binary with PIE with this you
could allmost compile all binary with PIE as we do on Gentoo Hardened.
This patches have bin posted before on the list.
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01515.html
/Magnus Granberg
Changlog
2014-07-31 Magnus Granberg
/gcc
* config/gnu-user.h: Define PIE_DRIVER_SELF_SPECS for PIE
as default and GNU_DRIVER_SELF_SPECS.
* config/i386/gnu-user-common.h: Define DRIVER_SELF_SPECS
* configure.ac: Add new option that enable PIE as default.
* configure, config.in: Rebuild.
* Makefile.in: Disable PIE when building the compiler.
* doc/install.texi: Add the new configure option default PIE.
* doc/invoke.texi: Add note for the new configure option default PIE.
* testsuite/gcc/default-pie.c: New test for new configure option
--enale-default-pie
* testsuite/gcc.dg/other/anon5.C: Add skip test as it fail to link
on effective_target default_pie.
* testsuite/lib/target-supports.exp (check_profiling_available):
We can't use profiling on effective target default_pie.
(check_effective_target_pie): Add check_effective_target_default_pie.
/libgcc
* Makefile.in: Disable PIE when building the crtbegin/end files.
--- a/gcc/config/gnu-user.h 2013-08-20 10:31:40.0 +0200
+++ b/gcc/config/gnu-user.h 2013-10-23 22:01:42.337238981 +0200
@@ -126,3 +126,17 @@ see the files COPYING3 and COPYING.RUNTI
LD_STATIC_OPTION " --whole-archive -ltsan --no-whole-archive " \
LD_DYNAMIC_OPTION "}}%{!static-libtsan:-ltsan}"
#endif
+
+/* We use this to make the compiler use -fPIE as default and link
+ with -pie. */
+#ifdef ENABLE_DEFAULT_PIE
+#define PIE_DRIVER_SELF_SPECS \
+"%{pie|fpic|fPIC|fpie|fPIE|fno-pic|fno-PIC|fno-pie|fno-PIE| \
+ shared|static|nostdlib|nodefaultlibs|nostartfiles:;:-fPIE -pie}"
+#else
+#define PIE_DRIVER_SELF_SPECS ""
+#endif
+
+#ifndef GNU_DRIVER_SELF_SPECS
+#define GNU_DRIVER_SELF_SPECS PIE_DRIVER_SELF_SPECS
+#endif
--- a/gcc/config/i386/gnu-user-common.h 2013-01-10 21:38:27.0 +0100
+++ b/gcc/config/i386/gnu-user-common.h 2013-10-23 17:37:45.432767049 +0200
@@ -70,3 +70,8 @@ along with GCC; see the file COPYING3.
/* Static stack checking is supported by means of probes. */
#define STACK_CHECK_STATIC_BUILTIN 1
+
+/* Use GNU_DRIVER_SELF_SPECS. */
+#ifndef DRIVER_SELF_SPECS
+#define DRIVER_SELF_SPECS GNU_DRIVER_SELF_SPECS
+#endif
--- a/gcc/configure.ac 2014-04-28 16:01:40.0 +0200
+++ b/gcc/configure.ac 2014-05-08 02:42:30.900883247 +0200
@@ -5671,6 +5671,36 @@ if test x"${LINKER_HASH_STYLE}" != x; th
[The linker hash style])
fi
+# Check whether --enable-default-pie was given and target have the support.
+AC_ARG_ENABLE(default-pie,
+[AS_HELP_STRING([--enable-default-pie],
+ [enable Position Independent Executable as default])],
+enable_default_pie=$enableval,
+enable_default_pie=no)
+if test x$enable_default_pie = xyes; then
+ AC_MSG_CHECKING(if $target supports default PIE)
+ enable_default_pie=no
+ case $target in
+i?86*-*-linux* | x86_64*-*-linux*)
+ saved_LDFLAGS="$LDFLAGS"
+ saved_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS -fPIE"
+ LDFLAGS="$LDFLAGS -fPIE -pie"
+ AC_TRY_LINK(,,[enable_default_pie=yes],)
+ LDFLAGS="$saved_LDFLAGS"
+ CFLAGS="$saved_CFLAGS"
+ ;;
+*)
+ ;;
+esac
+ AC_MSG_RESULT($enable_default_pie)
+fi
+if test x$enable_default_pie == xyes ; then
+ AC_DEFINE(ENABLE_DEFAULT_PIE, 1,
+ [Define if your target supports default PIE and it is enabled.])
+fi
+AC_SUBST([enable_default_pie])
+
# Configure the subdirectories
# AC_CONFIG_SUBDIRS($subdirs)
--- a/gcc/Makefile.in 2013-10-02 21:52:27.0 +0200
+++ b/gcc/Makefile.in 2013-10-24 17:46:22.055357122 +0200
@@ -968,14 +968,23 @@ CONTEXT_H = context.h
# cross compiler which does not use the native headers and libraries.
INTERNAL_CFLAGS = -DIN_GCC $(PICFLAG) @CROSS@
+# We don't want to compile the compiler with -fPIE, it make PCH fail.
+enable_default_pie = @enable_default_pie@
+ifeq ($(enable_default_pie),yes)
+NOPIE_CFLAGS = -fno-PIE
+else
+NOPIE_CFLAGS=
+endif
+
# This is the variable actually used when we compile. If you change this,
# you probably want to update BUILD_CFLAGS in configure.ac
-ALL_CFLAG
[PATCH, libfortran] Backport xmallocarray to 4.8/4.9 (CVE-2014-5044)
Hi, a while ago I committed a patch to trunk adding a function xmallocarray to libgfortran, which is a malloc wrapper like xmalloc but has two arguments and does an overflow check before multiplying them together. https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=211721 Originally I had no intentions of backporting this functionality to release branches, but subsequently Florian Weimer thought it was important enough to warrant a CVE number (CVE-2014-5044), so after some private discussions with Tobias and Jerry we agreed to backport. http://seclists.org/oss-sec/2014/q3/230 https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg01136.html https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg01135.html -- Janne Blomqvist
Re: [PATCH 5/5] add libcc1
On Jul 30, 2014, at 9:47 PM, Jeff Law wrote: > So my biggest concern here is long term maintenance -- who's going to own > care and feeding of these bits over time. > > My inclination is to go ahead and approve, but explicitly note that if the > bits do start to rot that we'll be fairly aggressive at disabling/removing > them. So the normal way to do this would be to make the plugin front-end non-default and then never gate any release decisions upon the state of the that front-end. If it works, ship it, if it doesn’t ship it. If people want it to build, the contribute patches, if they don’t care, oh well… That said, changes that ripple across front-ends generally need to be built with all (really all) built and are generally rejected if they break the build. Given my experience with lessor front-ends (Objective-C and Objective-C++), I think we do a good job and the maintenance is fairly low. Others can disabuse me of this opinion if they want. My expectation is that this frontend will be easy to maintain and will be a non-issue. Everyone and then someone won’t test with it, they will break it, someone will notice, someone will contribute the 2 line patch that also makes it work, and life goes on. This is my experience with Objective-C++ (a non-default language).
Re: [SH][committed] Fix PR 61844
On Thu, 2014-07-31 at 18:34 +0200, Oleg Endo wrote: > Hello, > > Attached patch fixes sh64 build issues and was committed as r213381 to > trunk. Tested by building an sh64-elf newlib cross compiler for C and > C++. Non-sh64 sh-elf should not be affected by the patch, since > ALLOW_INDEXED_ADDRESS is always 'true' on sh-elf. Thus, tested only > with 'make all' for sh-elf only. Backports to 4.9 and 4.8 will follow. 4.9 backport was committed as r213384. 4.8 backport seems not necessary, as it builds OK (gcc + newlib) without the patch. Cheers, Oleg
[RFC, PATCH 3/n] IPA C++ refactoring
Hello,
in the following patch, I would like to introduce a new template class
(indexed_set) that can replace many cgraph_node_set and varpool_node_set
related functions.
Bootstrapped on x86_64-pc-linux-gnu, no regression observed.
Thank you,
Martin
2014-07-31 Martin Liska
* cgraph.h (cgraph_node_set, varpool_node_set): Removed structs and all
related functions that manipulated these data structures.
(cgraph_new_nodes): vec replaces cgraph_node_set.
* cgraphunit.c (cgraph_new_nodes): Likewise.
(cgraph_process_new_functions): Usage of newly added indexed_set class.
(cgraph_node::add_new_function): Likewise.
* indexed-set.h: New data structure.
* ipa-inline-transform.c (can_remove_node_now_p_1): Usage of newly
added indexed_set class.
* ipa-utils.c: Implementations of legacy data structures removed.
* tree-emutls.c (tls_vars): indexed_set replaces varpool_node_set.
(emutls_index): New functions are used.
(ipa_lower_emutls): Likewise.
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index d8651e2..3de76ed 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3. If not see
#include "basic-block.h"
#include "function.h"
#include "ipa-ref.h"
+#include "indexed-set.h"
/* Symbol table consists of functions and variables.
TODO: add labels and CONST_DECLs. */
@@ -1200,41 +1201,6 @@ public:
unsigned calls_comdat_local : 1;
};
-/* A cgraph node set is a collection of cgraph nodes. A cgraph node
- can appear in multiple sets. */
-struct cgraph_node_set_def
-{
- struct pointer_map_t *map;
- vec nodes;
-};
-
-typedef cgraph_node_set_def *cgraph_node_set;
-typedef struct varpool_node_set_def *varpool_node_set;
-
-class varpool_node;
-
-/* A varpool node set is a collection of varpool nodes. A varpool node
- can appear in multiple sets. */
-struct varpool_node_set_def
-{
- struct pointer_map_t * map;
- vec nodes;
-};
-
-/* Iterator structure for cgraph node sets. */
-struct cgraph_node_set_iterator
-{
- cgraph_node_set set;
- unsigned index;
-};
-
-/* Iterator structure for varpool node sets. */
-struct varpool_node_set_iterator
-{
- varpool_node_set set;
- unsigned index;
-};
-
/* Structure containing additional information about an indirect call. */
struct GTY(()) cgraph_indirect_call_info
@@ -1509,7 +1475,7 @@ enum cgraph_state
};
extern enum cgraph_state cgraph_state;
extern bool cgraph_function_flags_ready;
-extern cgraph_node_set cgraph_new_nodes;
+extern vec cgraph_new_nodes;
extern GTY(()) struct asm_node *asm_nodes;
extern GTY(()) int symtab_order;
@@ -1615,24 +1581,7 @@ void record_references_in_initializer (tree, bool);
/* In ipa.c */
bool symtab_remove_unreachable_nodes (bool, FILE *);
-cgraph_node_set cgraph_node_set_new (void);
-cgraph_node_set_iterator cgraph_node_set_find (cgraph_node_set,
- cgraph_node *);
-void cgraph_node_set_add (cgraph_node_set, cgraph_node *);
-void cgraph_node_set_remove (cgraph_node_set, cgraph_node *);
-void dump_cgraph_node_set (FILE *, cgraph_node_set);
-void debug_cgraph_node_set (cgraph_node_set);
-void free_cgraph_node_set (cgraph_node_set);
void cgraph_build_static_cdtor (char which, tree body, int priority);
-
-varpool_node_set varpool_node_set_new (void);
-varpool_node_set_iterator varpool_node_set_find (varpool_node_set,
- varpool_node *);
-void varpool_node_set_add (varpool_node_set, varpool_node *);
-void varpool_node_set_remove (varpool_node_set, varpool_node *);
-void dump_varpool_node_set (FILE *, varpool_node_set);
-void debug_varpool_node_set (varpool_node_set);
-void free_varpool_node_set (varpool_node_set);
void ipa_discover_readonly_nonaddressable_vars (void);
/* In predict.c */
@@ -1948,93 +1897,6 @@ cgraph_next_function_with_gimple_body (cgraph_node *node)
/* Create a new static variable of type TYPE. */
tree add_new_static_var (tree type);
-/* Return true if iterator CSI points to nothing. */
-static inline bool
-csi_end_p (cgraph_node_set_iterator csi)
-{
- return csi.index >= csi.set->nodes.length ();
-}
-
-/* Advance iterator CSI. */
-static inline void
-csi_next (cgraph_node_set_iterator *csi)
-{
- csi->index++;
-}
-
-/* Return the node pointed to by CSI. */
-static inline cgraph_node *
-csi_node (cgraph_node_set_iterator csi)
-{
- return csi.set->nodes[csi.index];
-}
-
-/* Return an iterator to the first node in SET. */
-static inline cgraph_node_set_iterator
-csi_start (cgraph_node_set set)
-{
- cgraph_node_set_iterator csi;
-
- csi.set = set;
- csi.index = 0;
- return csi;
-}
-
-/* Return true if SET contains NODE. */
-static inline bool
-cgraph_node_in_set_p (cgraph_node *node, cgraph_node_set set)
-{
- cgraph_node_set_iterator csi;
- csi = cgraph_node_set_find (set, node);
- return !csi_end_p (csi);
-}
-
-/* Return number of nodes in SET. */
-static inline size_t
-cgraph_node_set_size (cgraph_node_set set)
-
Re: [RFC, PATCH 3/n] IPA C++ refactoring
> Hello, >in the following patch, I would like to introduce a new template class > (indexed_set) that can replace many cgraph_node_set and varpool_node_set > related functions. > > Bootstrapped on x86_64-pc-linux-gnu, no regression observed. > > Thank you, > Martin > 2014-07-31 Martin Liska > > * cgraph.h (cgraph_node_set, varpool_node_set): Removed structs and all > related functions that manipulated these data structures. > (cgraph_new_nodes): vec replaces cgraph_node_set. > * cgraphunit.c (cgraph_new_nodes): Likewise. > (cgraph_process_new_functions): Usage of newly added indexed_set class. > (cgraph_node::add_new_function): Likewise. > * indexed-set.h: New data structure. > * ipa-inline-transform.c (can_remove_node_now_p_1): Usage of newly > added indexed_set class. > * ipa-utils.c: Implementations of legacy data structures removed. > * tree-emutls.c (tls_vars): indexed_set replaces varpool_node_set. > (emutls_index): New functions are used. > (ipa_lower_emutls): Likewise. As a cgraph maintainer I am very happy to see cgraph_node_set and varpool_node_set to go. I would however preffer someone to approve the indexed-set.h implementation. Honza
Re: [Patch] Not very subtle fix for pr61510
> > On Mon, Jun 23, 2014 at 06:43:20PM +0100, Jan Hubicka wrote: > > > On Mon, 23 Jun 2014, James Greenhalgh wrote: > > > > > > > > > > > Hi, > > > > > > > > pr61510 is a case where cgraphunit.c::analyze_functions can end up > > > > dereferencing a NULL pointer. This is, to me, the obvious way to avoid > > > > dereferencing NULL. > > > > > > > > However, I'm not very confident that this isn't just masking some > > > > horrible and subtle bug, so I'd like some review feedback on the patch. > > > > > > > > Tested on aarch64-none-elf, where I was seeing the issue. > > > > > > > > OK? > > > > > > Obvious in some sense to me, too, but I wonder why we don't have a cgraph > > > node > > > for it and what happens if it is created later (and then doesn't > > > have the flag set)? > > > > In that case we won't get the used_as_abstract_origin flag. that will make > > us > > to throw away the debug info if we remove it. I guess we simply want > > graph_get_create_node here. I can prepare patch tonight (after teaching) > > I've spun a patch with what I think you were suggesting here. > > Tested on aarch64-none-elf with no regressions to confirm it fixes the > bug and bootstrapped on x86 and aarch64 with no issues. > > OK? > > Thanks, > James > > --- > 2014-07-31 James Greenhalgh > > PR regression/61510 > * cgraphunit.c (analyze_functions): Use get_create rather than get > for decls which are clones of abstract functions. OK, thanks Honza
[wwwdocs][committed] Update SH section in readings
Hello, The references to SuperH Inc are outdated. The link now leads to a funny place. I've replaced it with something more relevant. Cheers, Oleg Index: htdocs/readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.234 diff -u -r1.234 readings.html --- htdocs/readings.html 27 Jun 2014 20:41:05 - 1.234 +++ htdocs/readings.html 31 Jul 2014 22:08:07 - @@ -261,10 +261,10 @@ sh - Manufacturer: Renesas, or various licensed by SuperH Inc - CPUs include: SH1, SH2, SH2-DSP, SH3, SH3-DSP, SH4, SH5 series. + Manufacturer: Renesas, various licensees. + CPUs include: SH1, SH2, SH2-DSP, SH3, SH3-DSP, SH4, SH4A, SH5 series. http://www.renesas.com/products/mpumcu/superh/superh_landing.jsp";>Renesas SuperH Processors - http://www.superh.com/";>SuperH Home Page + http://shared-ptr.com/sh_insns.html";>SuperH Instruction Set Summary GDB includes a simulator.
Re: [PATCH, Cilk+] Fix for PR61962
On 07/31/14 13:51, Zamyatin, Igor wrote: Hi! This patch fixes endless compilation for the case of array notation for an array which is a structure member Ok for trunk/4.9 once testing finished? Thanks, Igor Changelog: gcc/c-family: 2014-07-31 Igor Zamyatin PR other/61962 * array-notation-common.c (find_rank): Added handling for other types of references. gcc/testsuite: 2014-07-31 Igor Zamyatin PR other/61962 * c-c++-common/cilk-plus/AN/pr61962.c: New test. OK. Please install. Thanks, Jeff
Re: [PATCH, Cilk+] Fix for PR61963
On 07/31/14 13:51, Zamyatin, Igor wrote: Hi! This patch fixes the ICE on invalid code by adding missed check for error_mark_node. Regtested on x86_64. Ok for trunk/4.9? Thanks, Igor Changelog: gcc/cp: 2014-07-31 Igor Zamyatin PR other/61963 * parser.c (cp_parser_array_notation): Added check for array_type. gcc/testsuite: 2014-07-31 Igor Zamyatin PR other/61963 * c-c++-common/cilk-plus/AN/pr61963.c: New test. This is fine too. Thanks, Jeff
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 07/24/14 09:31, Chen Gang wrote:
strlen() will get string length excluding '\0', but strcpy() will append
'\0' in the end, so need XNEWVEC additional byte, or cause memory over
flow.
Signed-off-by: Chen Gang
---
gcc/gcc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6cd08ea..8ea46ec 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -4895,7 +4895,7 @@ do_spec_1 (const char *spec, int inswitch, const char
*soft_matched_part)
{
saved_suffix
= XNEWVEC (char, suffix_length
-+ strlen (TARGET_OBJECT_SUFFIX));
++ strlen (TARGET_OBJECT_SUFFIX) + 1);
strncpy (saved_suffix, suffix, suffix_length);
strcpy (saved_suffix + suffix_length,
TARGET_OBJECT_SUFFIX);
Thanks. I've installed this on the trunk after bootstrapping and
regression testing on x86_64-unknown-linux-gnu
In the future, please do a bootstrap & regression test when submitting
patches and indicate which platform you did the testing on.
In essence the process looks like
make
make check
make clean
make
make check
It seems tedious for simple patches, but the requirements for
bootstrapping and regression testing keep the tip of the trunk from
getting broken too often (which is very costly for everyone when it occurs).
You also need to provide a ChangeLog entry. The details of what belongs
in a ChangeLog are on the web site. Here's an example for your patch:
2014-07-31 Chen Gang
* gcc.c (do_spec_1): Allocate enough space for saved_suffix.
Thanks,
Jeff
Re: [PATCH][testsuite] Don't run cproj-fails-with-broken-glibc.c for broken glibc
On 07/31/14 13:20, Tom de Vries wrote: Rainer, The test-case cproj-fails-with-broken-glibc.c does not work with broken glibcs, as the header comment mentions: ... Check the runtime behavior of the C library's cproj() function and whether it follows the standard. Versions of GLIBC through 2.11.1 had an incorrect implementation which will conflict with GCC's builtin cproj(). GLIBC 2.12+ should be okay. ... This patch skips the test for known broken glibcs. OK for trunk? Yes, this is fine. jeff
Re: [PATCH 1/3, Cilk+] Fix for PR61455
On 07/31/14 13:21, Zamyatin, Igor wrote: Ping -Original Message- From: Zamyatin, Igor Sent: Saturday, July 12, 2014 1:52 PM To: GCC Patches (gcc-patches@gcc.gnu.org) Subject: [PATCH 1/3, Cilk+] Fix for PR61455 Hi! This simple change fixes the issue with printing of error message (happened in unprintable_error routine of the PR's test) Regtested with the next patch of this chain. Ok for trunk/4.9? Thanks, Igor gcc/cp/Changelog: 2014-07-08 Igor Zamyatin * cp-array-notation.c (expand_an_in_modify_expr): Fix the misprint in error output. This is fine. Sorry it slipped through the cracks. jeff
Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny
On Wed, Jul 30, 2014 at 10:35 PM, Mike Stump wrote: > On Jul 22, 2014, at 12:14 PM, Mike Stump wrote: >> On Jul 22, 2014, at 4:01 AM, Kyrill Tkachov wrote: >>> These tests use very large arrays as part of their loop interchange testing >>> so they don't fit into the 1MiB binary size limit imposed by -mcmodel=tiny. >>> This causes errors at link-time. >> >>> Ok to commit? >> >> So the test suite should be used to figure this out as marking the >> individual test cases is a never ending and ever changing. I can a big test >> case on my system, and found: >> >> ld: address 0xc401ad0 of a.out section `.data' is not within region `SRAM' >> ld: a.out section `.ctors' will not fit in region `SRAM' >> ld: address 0xc401ad0 of a.out section `.data' is not within region `SRAM' >> ld: region `SRAM' overflowed by 155196160 bytes >> >> for large test cases. After looking at the current gld sources, it seems >> that they merely changed the spelling of the error message and we’ve not >> kept up. Please try the patch below and tell me if it works for you. If it >> doesn’t, what messages do you see and what tool are they from? Vendor, >> program and version would be nice to know. >> >> If it works, feel free to check it in. If you want to replicate the 4 lines >> and add a case for the vendor’s tool, that’d be a better way to handle it. >> The below should handle a variety of GNU ld situations (but not all of them). > > So, were you able to test the patch I sent? So Kyrill's away and that's probably why he hasn't tested your patch yet. The particular errors are in the "tiny" memory model in AArch64 and the typical messages are about relocations truncated to fit. Now, in the tiny memory model on AArch64 it's valid to filter out the error messages that state that "relocation was truncated to fit" which is essentially that the program is too big. However if we have a situation where a port tries to ameliorate some of these errors with linker veneering and the compiler testsuite peels off such error messages and just marks them as UNSUPPORTED instead of getting a failure, is that the right behaviour in the testsuite ? I may be missing something here but it does sound like we may want 2 slightly different behaviours possible here. Ramana
Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny
On Jul 31, 2014, at 3:55 PM, Ramana Radhakrishnan
wrote:
> However if we have a situation where a port tries to ameliorate some
> of these errors with linker veneering and the compiler testsuite peels
> off such error messages and just marks them as UNSUPPORTED instead of
> getting a failure, is that the right behaviour in the test suite ?
A link editor test suite to ensure you implemented complex things in the linker
is a fine place for such a tescase. The gcc test suite isn’t a place for such
a test case if you want to test other than it works ok when it fits and to have
it marked as unsupported if it doesn’t. The gcc test suite generally speaking
doesn’t have enough of a low level system view to manage the totality of the
complexities. In reality, some folks have a meg of ram, and 64k of code and
they want to run the test suite. There are test cases that won’t work, and it
is rather impossible to split the hairs and say exactly when a test case will
and won’t work. Let’s say your 1 byte inside the limits on ram for a test case
T. Then, someone improved the compiler by adding an optimization that expands
the code size by 4 bytes and makes it 30% faster. That goes in. We don’t want
that test case to fail, just because it no longer fits. Wether is fits or not,
is not something we get to know in the test suite; because we don’t get to
know, we can’t pass or fail because of it. The best we can do is know when it
passes and say PASS:, and notice when it doesn’t fit and say UNSUPPORTED:.
> I may be missing something here but it does sound like we may want 2
> slightly different behaviours possible here.
Nope. Consider:
#define N 100*1024*1024
char a[N];
main() {
}
and 100 different systems that this test case will run this test one, some
already invented and some yet to be invented. Let me focus on one of them. It
is a demand paged virtual memory system. It has 32 megs of ram on the machine,
let say, that is the only size the machine has ever had. Do we mark this as
passing or failing? Hint I’ve engineered this so that you cannot win. The
problem is, if you say fail, I say it is demand paged, and it works. If you
say it works, I say it fails, because the demand paged memory system
preallocated all the backing store from swap and there wasn’t enough swap space
to support it. You can attempt to say, ah, but the test suite is turning
complete and we can write some tcl code to check out much swap space there is
and set it up correctly, then I retort that the environment impinges the data
space on this machine, then you retort, but we can then check the environment,
and then I retort, but another user on the machine can use swap, then you
retort, but we can kill off all their processes, then I retort, no, we can’t,
then you still wind up loosing. Now, maybe I’ve overlooked something trivial,
maybe I don’t understand the entirety of the world your envisioning… If you
want to describe it, feel free.
In short, the gcc test suite is not the proper place to test veneers for ld.
We can test some of that support, just there are limits to it.
Re: [RFC, PATCH 3/n] IPA C++ refactoring
> +++ b/gcc/cgraph.h
> @@ -27,6 +27,7 @@ along with GCC; see the file COPYING3. If not see
> #include "basic-block.h"
> #include "function.h"
> #include "ipa-ref.h"
> +#include "indexed-set.h"
you don't actually use that here so why are you including it?
> +++ b/gcc/cgraphunit.c
> @@ -211,11 +211,12 @@ along with GCC; see the file COPYING3. If not see
> #include "tree-nested.h"
> #include "gimplify.h"
> #include "dbgcnt.h"
> +#include "indexed-set.h"
afaict you don't use it here either.
> @@ -529,9 +529,9 @@ cgraph_node::add_new_function (tree fndecl, bool lowered)
> }
> if (lowered)
> node->lowered = true;
> - if (!cgraph_new_nodes)
> - cgraph_new_nodes = cgraph_node_set_new ();
> - cgraph_node_set_add (cgraph_new_nodes, node);
> + if (!cgraph_new_nodes.exists ())
> + cgraph_new_nodes.create (4);
I don't think you need this, if the vector doesn't exist it will point
at null, and safe_push knows how to handle that.
> +++ b/gcc/indexed-set.h
> +template
> +class indexed_set
per below I don't think you actually need this class after all.
> +{
> +public:
> + class iterator
> + {
> + public:
> +iterator (const vec *v, unsigned index) : m_index (index), m_vector
> (v) {};
> +
> +inline T operator * ()
> +{
> + gcc_assert (m_index < m_vector->length ());
> +
> + return (*m_vector)[m_index];
> +}
> +
> +inline iterator &operator ++ ()
> +{
> + m_index++;
> + return *this;
> +}
> +
> +bool operator != (const iterator &other) const
> +{
> + return m_vector != other.m_vector || m_index != other.m_index;
> +}
> +
> +inline int
> +get_index (void) const
> +{
> + return m_index;
> +}
> +
> + private:
> +unsigned m_index;
> +const vec *m_vector;
> + };
> +
> + /* Iterator to the start of data structure. */
> +
> + iterator begin () const
> + {
> +gcc_assert (!is_empty ());
it seems to me it would be better to just return the iterator for end ()
if there's no elements.
> +
> +iterator iter (&m_vector, 0);
> +return iter;
> + }
> +
> + /* Iterator to the end of data structure. */
> +
> + iterator end () const
> + {
> +return iterator (&m_vector, m_vector.length ());
> + }
> +
> + /* Add item V to data structure. */
> +
> + inline void
afaik defining within the class implies inline.
> + add (T v)
You are passing by value here, which you probably don't want to do if T
is big.
> + {
> +m_map.put (v, m_vector.length ());
> +m_vector.safe_push (v);
I think this blows up if v was already in the map, so assert it isn't?
> + }
> +
> + /* Return iterator for an item V. */
> +
> + inline iterator
> + find (T v)
> + {
> +int *item = m_map.get (v);
> +gcc_unreachable ();
> +
> +return item ? iterator (&m_vector, *item) : end ();
returning an iterator here seems silly, the only information you get is
the index and if the element exists in the map, so just return an int?
> + }
> +
> + /* Return if the data structure is empty. */
> +
> + inline bool
> + is_empty (void) const
> + {
> +return m_vector.is_empty ();
> + }
> +
> + /* Return number of items stored in data structure. */
> +
> + inline unsigned
> + length (void)
> + {
> +return m_vector.length ();
> + }
> +
> +
> +private:
> + hash_map m_map;
> + auto_vec m_vector;
I know you don't use this with anything but pointers now, but this will
do "weird" things if T is some sort of object.
> +};
> +
> +#endif
> diff --git a/gcc/tree-emutls.c b/gcc/tree-emutls.c
> index 89197c7..9c06aec 100644
> --- a/gcc/tree-emutls.c
> +++ b/gcc/tree-emutls.c
> @@ -42,6 +42,7 @@ along with GCC; see the file COPYING3. If not see
> #include "target.h"
> #include "targhooks.h"
> #include "tree-iterator.h"
> +#include "indexed-set.h"
>
>
> /* Whenever a target does not support thread-local storage (TLS) natively,
> @@ -70,7 +71,7 @@ along with GCC; see the file COPYING3. If not see
> /* These two vectors, once fully populated, are kept in lock-step so that
> the index of a TLS variable equals the index of its control variable in
> the other vector. */
> -static varpool_node_set tls_vars;
> +static indexed_set tls_vars;
Note that will create a static initializer that calls malloc, and tls
emulation probably isn't needed on many targets, so I'd guess your
better off using a hash_map * with new and delete as annoying as that is.
> static vec control_vars;
so, looking at this thing more closely it looks like this is just a
weirdo implementation of a hash map from varpool_node * to (varpool_node
*, tree) so I think you could just do
struct tls_var_data
{
varpool_node *control_var;
tree access;
};
hash_map
Thanks!
Trev
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
Thank you very much for your work. Especially give a complete sample for
the whole working flow, which I shall follow.
For me, if no related documents for it, I recommend to put a complete
sample (e.g. this one) to a related document which can be referenced by
other newbies.
By the way, with your aid, my original plan "a patch per month" is
succeed, or it must be fail for 2014-07, thanks.
On 08/01/2014 06:36 AM, Jeff Law wrote:
> On 07/24/14 09:31, Chen Gang wrote:
>> strlen() will get string length excluding '\0', but strcpy() will append
>> '\0' in the end, so need XNEWVEC additional byte, or cause memory over
>> flow.
>>
>> Signed-off-by: Chen Gang
>> ---
>> gcc/gcc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/gcc.c b/gcc/gcc.c
>> index 6cd08ea..8ea46ec 100644
>> --- a/gcc/gcc.c
>> +++ b/gcc/gcc.c
>> @@ -4895,7 +4895,7 @@ do_spec_1 (const char *spec, int inswitch, const
>> char *soft_matched_part)
>> {
>> saved_suffix
>> = XNEWVEC (char, suffix_length
>> - + strlen (TARGET_OBJECT_SUFFIX));
>> + + strlen (TARGET_OBJECT_SUFFIX) + 1);
>> strncpy (saved_suffix, suffix, suffix_length);
>> strcpy (saved_suffix + suffix_length,
>> TARGET_OBJECT_SUFFIX);
> Thanks. I've installed this on the trunk after bootstrapping and
> regression testing on x86_64-unknown-linux-gnu
>
Thank you for your work.
> In the future, please do a bootstrap & regression test when submitting
> patches and indicate which platform you did the testing on.
>
> In essence the process looks like
>
> make
> make check
>
>
> make clean
> make
> make check
>
>
Thanks, I shall follow, next.
>
> It seems tedious for simple patches, but the requirements for
> bootstrapping and regression testing keep the tip of the trunk from
> getting broken too often (which is very costly for everyone when it
> occurs).
>
That sounds reasonable to me.
> You also need to provide a ChangeLog entry. The details of what belongs
> in a ChangeLog are on the web site. Here's an example for your patch:
>
> 2014-07-31 Chen Gang
>
> * gcc.c (do_spec_1): Allocate enough space for saved_suffix.
>
Thanks, I shall follow, next.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Jul 31, 2014, at 6:37 PM, Chen Gang wrote: > Thank you very much for your work. Especially give a complete sample for > the whole working flow, which I shall follow. > > For me, if no related documents for it, I recommend to put a complete > sample (e.g. this one) to a related document which can be referenced by > other newbies. https://gcc.gnu.org/contribute.html
Re: [PATCH 5/5] add libcc1
On Thu, Jul 31, 2014 at 01:51:45PM -0600, Tom Tromey wrote: > > "Trevor" == Trevor Saunders writes: > > Trevor> the plugin part seems fine, but I do find my self wondering if > there's a > Trevor> better way of doing the hooks into C, if they can be more genrally > Trevor> useful. > > There's just one now, the binding oracle. ah, that seems reasonable enough. > (There used to be two but we reimplemented the second one by overriding > a langhook from the plugin.) hm, I think langhooks should eventually become an interface with virtual functions to help seperate front ends, and that may be interesting with plugins that over ride lang hooks from the front end, but we need to cross that bridge anyway I guess. > The binding oracle could perhaps be redone as an ordinary plugin event. > It didn't seem that worthwhile to me, but if someone else has a use, it > seems doable. > > Trevor> out of process seems very reasonable, but I do hope we'll fix the > Trevor> crashes since there's any number of other uses for cc1 as a library. > > The ones I recall were all things like the plugin making a tree > incorrectly. This could still be an issue but it is one unlikely to be > hit in ordinary uses of the compiler. I agree any such things are bugs > though. Then that seems fine. So as far as I'm concerned please lets go forward with this and clean up later as needed. Trev > > Tom
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/01/2014 10:14 AM, Mike Stump wrote: > On Jul 31, 2014, at 6:37 PM, Chen Gang wrote: >> Thank you very much for your work. Especially give a complete sample for >> the whole working flow, which I shall follow. >> >> For me, if no related documents for it, I recommend to put a complete >> sample (e.g. this one) to a related document which can be referenced by >> other newbies. > > https://gcc.gnu.org/contribute.html > Thank you for your information, I shall read it in details, next. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] PowerPC: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV
Thanks for implementing the FENV support. The patch generally looks good to me. My one concern is a detail in the implementation of "update". I do not have enough experience with GENERIC to verify the details and it seems like it is missing building an outer COMPOUND_EXPR containing update_mffs and the CALL_EXPR for update mtfsf. I would like someone to double check. Thanks, David
Re: [PATCH] Keep patch file permissions in mklog
Cc Diego. --- From: Tom de Vries Sent: Saturday, May 31, 2014 11:47AM To: Geoff Keating Cc: GCC Patches Subject: [PATCH] Keep patch file permissions in mklog On 05/31/2014 11:47 AM, Tom de Vries wrote: Geoff, Currently, mklog resets the permissions on a patch file: ... $ touch tmp.patch $ ls -la tmp.patch -rw-rw-r-- 1 vries vries 0 mei 31 09:17 tmp.patch $ ./contrib/mklog tmp.patch $ ls -la tmp.patch -rw--- 1 vries vries 59 mei 31 09:17 tmp.patch $ ... This patch fixes that: ... $ rm tmp.patch $ touch tmp.patch $ ls -la tmp.patch -rw-rw-r-- 1 vries vries 0 mei 31 09:41 tmp.patch $ ./contrib/mklog tmp.patch $ ls -la tmp.patch -rw-rw-r-- 1 vries vries 59 mei 31 09:41 tmp.patch ... OK for trunk? Thanks, - Tom
Re: [PATCH] Fix mklog to support running from arbitrary folder
On 07/31/2014 09:57 PM, Diego Novillo wrote: Current mklog works only if run from GCC top-level folder. The patch allows running from arbitrary directory. I've used Linux directory separators which is probably ok because script already expects Linux environment (dirname, basename, etc.). Ok to commit? OK. Thanks. Done, r213401. -Y
Re: [PATCH 2/2] Enable elimination of zext/sext
> + lhs_type = lang_hooks.types.type_for_mode (lhs_mode, lhs_uns);
> ...
> + && ((!lhs_uns && !wi::neg_p (min, TYPE_SIGN (lhs_type)))
> ...
> + type_min = wide_int::from (TYPE_MIN_VALUE (lhs_type), prec,
> +TYPE_SIGN (TREE_TYPE (ssa)));
> + type_max = wide_int::from (TYPE_MAX_VALUE (lhs_type), prec,
> +TYPE_SIGN (TREE_TYPE (ssa)));
>
> you shouldn't try getting at lhs_type. Btw, do you want to constrain
> lhs_mode to MODE_INTs somewhere?
Is this in addition to !INTEGRAL_TYPE_P (TREE_TYPE (ssa)))? Do you mean
that I should check lhs_mode as well?
> For TYPE_SIGN use lhs_uns instead, for the min/max value you
> should use wi::min_value () and wi::max_value () instead.
>
> You are still using TYPE_SIGN (TREE_TYPE (ssa)) here and later,
> but we computed rhs_uns "properly" using PROMOTE_MODE.
> I think the code with re-setting lhs_uns if rhs_uns != lhs_uns
> and later using TYPE_SIGN again is pretty hard to follow.
>
> Btw, it seems you need to conditionalize the call to PROMOTE_MODE
> on its availability.
>
> Isn't it simply about choosing a proper range we need to restrict
> ssa to? That is, dependent on rhs_uns computed by PROMOTE_MODE,
> simply:
>
> + mode = TYPE_MODE (TREE_TYPE (ssa));
> + rhs_uns = TYPE_UNSIGNED (TREE_TYPE (ssa));
> #ifdef PROMOTE_MODE
> + PROMOTE_MODE (mode, rhs_uns, TREE_TYPE (ssa));
> #endif
>
> if (rhs_uns)
>return wi::ge_p (min, 0); // if min >= 0 then range contains positive
> values
> else
>return wi::le_p (max, wi::max_value (TYPE_PRECISION (TREE_TYPE
> (ssa)), SIGNED); // if max <= signed-max-of-type then range doesn't
> need sign-extension
I think we will have to check that ssa has necessary sign/zero extension
when assigned to lhs_type. If PROMOTE_MODE tells us that ssa's type will
be interpreted differently, the value range of ssa also will have
corresponding range. In this cases, shouldn’t we have to check for
upper and lower limit for both min and max?
How about this?
bool
promoted_for_type_p (tree ssa, enum machine_mode lhs_mode, bool lhs_uns)
{
wide_int min, max;
tree lhs_type, rhs_type;
bool rhs_uns;
enum machine_mode rhs_mode;
tree min_tree, max_tree;
if (ssa == NULL_TREE
|| TREE_CODE (ssa) != SSA_NAME
|| !INTEGRAL_TYPE_P (TREE_TYPE (ssa)))
return false;
/* Return FALSE if value_range is not recorded for SSA. */
if (get_range_info (ssa, &min, &max) != VR_RANGE)
return false;
rhs_uns = TYPE_UNSIGNED (TREE_TYPE (ssa));
if (rhs_uns != lhs_uns)
{
/* Signedness of LHS and RHS differs and values also cannot be
represented in LHS range. */
unsigned int prec = min.get_precision ();
if ((lhs_uns && wi::neg_p (min, rhs_uns ? UNSIGNED : SIGNED))
|| (!lhs_uns && !wi::le_p (max,
wi::max_value (prec, SIGNED),
rhs_uns ? UNSIGNED : SIGNED)))
return false;
}
/* In some architectures, modes are promoted and sign changed with
target defined PROMOTE_MODE macro. If PROMOTE_MODE tells you to
promote _not_ according to ssa's sign then honour that. */
rhs_mode = TYPE_MODE (TREE_TYPE (ssa));
#ifdef PROMOTE_MODE
PROMOTE_MODE (rhs_mode, rhs_uns, TREE_TYPE (ssa));
#endif
rhs_type = lang_hooks.types.type_for_mode (rhs_mode, rhs_uns);
lhs_type = lang_hooks.types.type_for_mode (lhs_mode, lhs_uns);
min_tree = wide_int_to_tree (rhs_type, min);
max_tree = wide_int_to_tree (rhs_type, max);
/* Check if values lies in-between the type range. */
if (int_fits_type_p (min_tree, lhs_type)
&& int_fits_type_p (max_tree, lhs_type))
return true;
else
return false;
}
Thanks,
Kugan
Re: [PATCH] libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c: Be sure 'errbuf' always be zero terminated.
Sorry for no testsuite, I shall send patch v2 for it after finish related testsuite within this week end (2014-08-03). And the patch v2 also need cc to java-patc...@gcc.gnu.org Thanks. On 07/31/2014 12:59 PM, Chen Gang wrote: > > > On 07/31/2014 12:10 PM, Jeff Law wrote: >> On 07/30/14 09:01, Chen Gang wrote: >>> Hello All: >>> >>> I shall stop making this kind of patch, next. The reason is that I worry >>> about what I have done have negative effect to others. And next, I shall >>> try to send another kinds of patches for gcc when I have time. >>> >>> Many persons or companies use open source who never give thanks or >>> contribution back to open source. But open source (especially, >>> fundamental software) still provide common contributions to outside. >>> >>> What I have done is only for contribution back to open source, so I can >>> understand none-reply from open source (at least, it is not the excuse >>> to let myself stop). But what I worry about is whether bother others. >> I don't think you've have any kind of negative impact. GCC developers >> tend to be a bit more conservative and try not to change code just for >> the sake of changing code. Thus we tend to want to have a clearer >> understanding of why a particular change needs to be made. >> >> It's also the case that we tend to look more closely at patches from >> relatively new developers simply because we don't have a long history of >> interactions that have built trust over time. >> >> So, just to be clear, I don't think you're bothering anyone and I would >> recommend you continue to analyze code and send patches. >> > > OK, thank you for your encouragement. And I shall continue to send this > kind of patches. > >> And sorry for telling you everything goes to gcc-patches. I often >> forget there's a separate java patch list -- and more generally for the >> runtime libraries, we're often a downstream code consumer. Thus a >> proposed change in some of the runtime libraries may need to be sent to >> other projects (Classpath is a good example). >> > > OK, and I shall notice about it next time (send related patches to > correct mailing list). > > For me, it will be good idea to have a related document for these > mailing list intruduction (maybe it has, and I shall try to find it). > > > Thanks. > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/fortran/resolve.c: Let 'err_len' have real effect in gfc_explicit_interface_required()
Excuse me, this patch has no testsuite, either no change log.
If pass checking (get reply confirmation for this mail), I shall send
patch v2 with testsuite and change log for it, and still only cc to
gcc-patches@gcc.gnu.org.
Thanks.
On 07/28/2014 04:03 PM, Chen Gang wrote:
> External function gfc_explicit_interface_required() assumes the input
> parameter 'errmsg' will be a zero terminated string after return, and
> the input parameter 'err_len' is full length of 'errmsg'.
>
> If 'err_len' would have real effect -- truncate 'errmsg' by strncpy()
> which will zero pad but not be sure of zero terminated, 'errmsg' would
> not be zero terminated string.
>
> At present, it is not a bug -- all 'err_len' are large enough for it,
> But it is an extern function, according to its interface, it assumes
> 'errmsg' may be truncated in the future, so still need fix it.
>
>
> Signed-off-by: Chen Gang
> ---
> gcc/fortran/resolve.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
> index 15d8dab..a109168 100644
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -2212,6 +2212,10 @@ gfc_explicit_interface_required (gfc_symbol *sym, char
> *errmsg, int err_len)
> {
>gfc_formal_arglist *arg = gfc_sym_get_dummy_args (sym);
>
> + if (--err_len < 0)
> +return false;
> + errmsg[err_len] = '\0';
> +
>for ( ; arg; arg = arg->next)
> {
>if (!arg->sym)
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
RE: [PATCH, i386] Handle extended family cpuid info for AMD
Uros!
> I would like to have a check for a family at the beginning, something like:
> if (name == signature_NSC_ebx)
>processor = PROCESSOR_GEODE;
> else if (family == 22)
>{
> if (has_movbe)
I get your idea of having the family checked first and then differentiating
with cpuid info later.
But, this case is getting interesting because, BTVER1 and BTVER2 are two
variants but don't really have same family numbers.
BTVER1 is family 14h and BTVER2 is family 16h. I don't see near term plans for
any additional cpus to either 14h or 16h.
Given that fact, this particular check is applicable only for BTVER2.
In that case, having
else if (family == 22)
if (has_movbe)
processor = PROCESSOR_BTVER2;
looks odd.
Regards
Ganesh
Re: [AArch64] Implement movmem for the benefit of inline memcpy
On Fri, Jun 6, 2014 at 1:50 AM, James Greenhalgh
wrote:
>
> Hi,
>
> The move_by_pieces infrastructure performs a copy by repeatedly trying
> the largest safe copy it can make. So for a 15-byte copy we might see:
>
> offset amount bytes copied
> 08 0-7
> 84 8-11
> 12 2 12-13
> 14 1 14
>
> However, we can implement a 15-byte copy as so:
>
> offset amount bytes copied
> 08 0-7
> 78 7-14
>
> Which can prove more efficient for both space and speed.
>
> In this patch we set MOVE_RATIO low to avoid using move_by_pieces, and
> implement the movmem pattern name to expand small block copy cases. Note, this
> optimization does not apply for -mstrict-align targets, which must continue
> copying byte-by-byte.
>
> Setting MOVE_RATIO low in this way causes a few tests to begin failing,
> both of these are documented in the test-case as expected to fail for
> low MOVE_RATIO targets, which do not allow certain Tree-Level optimizations.
I think you should reevaluate setting MOVE_RATIO this low. It is used
for SRA and IPA-SRA which both are very useful; more useful than
memmove optimizations can do.
In fact this optimization is not even valid for volatile variables.
Here is a testcase for the volatile issue:
struct __attribute__((packed)) t15{
long long t8;
int t4;
short t2;
unsigned char t1;
};
volatile struct t15 t15;
int f(struct t15 *a)
{
t15 = *a;
}
Notice how we are writing to byte 7 twice to t15 in the outputted code.
Thanks,
Andrew Pinski
>
> Bootstrapped on aarch64-unknown-linux-gnu with no issues.
>
> OK for trunk?
>
> Thanks,
> James
>
> ---
> gcc/
>
> 2014-06-06 James Greenhalgh
>
> * config/aarch64/aarch64-protos.h (aarch64_expand_movmem): New.
> * config/aarch64/aarch64.c (aarch64_move_pointer): New.
> (aarch64_progress_pointer): Likewise.
> (aarch64_copy_one_part_and_move_pointers): Likewise.
> (aarch64_expand_movmen): Likewise.
> * config/aarch64/aarch64.h (MOVE_RATIO): Set low.
> * config/aarch64/aarch64.md (movmem): New.
>
> gcc/testsuite/
>
> 2014-06-06 James Greenhalgh
>
> * gcc.dg/tree-ssa/pr42585.c: Skip for AArch64.
> * gcc.dg/tree-ssa/sra-12.c: Likewise.
Re: [PATCH] Keep patch file permissions in mklog
On 01-08-14 06:21, Yury Gribov wrote: Cc Diego. --- From: Tom de Vries Sent: Saturday, May 31, 2014 11:47AM To: Geoff Keating Cc: GCC Patches Subject: [PATCH] Keep patch file permissions in mklog On 05/31/2014 11:47 AM, Tom de Vries wrote: Geoff, Currently, mklog resets the permissions on a patch file: Yuri, Diego, The permissions problem does not occur anymore with the latests versions of mklog, since it doesn't modify the patch file anymore. This patch adds a script contrib/mklog-in-patch, which uses mklog to generate the skeleton log, but generates the log at the start of the patch as mklog did before (which is how I like to use it). OK for trunk? I can also try to add an --inline option to mklog instead. Thanks, - Tom 2014-08-01 Tom de Vries * mklog-in-patch: New script. diff --git a/contrib/mklog-in-patch b/contrib/mklog-in-patch new file mode 100755 index 000..6d041eb --- /dev/null +++ b/contrib/mklog-in-patch @@ -0,0 +1,61 @@ +#!/bin/sh + +# Copyright (C) 2014 Free Software Foundation, Inc. +# +# This file is part of GCC. +# +# GCC is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3, or (at your option) +# any later version. +# +# GCC is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GCC; see the file COPYING. If not, write to +# the Free Software Foundation, 51 Franklin Street, Fifth Floor, +# Boston, MA 02110-1301, USA. + + +# Check for errors +set -e + +scriptdir=$(dirname $0) +prog=$(basename $0) + +diff="$1" + +if [ "$diff" = "" ]; then + usage +echo < "$temp"; then +echo "Could not write log file to $temp" +exit 1 +fi + +# Append patch to $temp, and move $temp to $patch. For the latter, we use cat +# rather than mv to keep $diff permissions the same. +if ! ( cat $diff >>$temp && cat $temp >$diff ); then +echo "Could not add the ChangeLog entry to $diff" +exit 1 +fi + +if ! rm $temp; then +echo "Could not remove $temp" +exit 1 +fi
