Re: [PATCH] RTEMS: Add Nios 2 support
On 2014/7/18 上午 05:19, Joel Sherrill wrote: Unless someone objects, I am going to commit this to the 4.9 branch and head. --joel Sorry about the delay, I'll review it today. Thanks, Chung-Lin On 7/7/2014 1:42 AM, Sebastian Huber wrote: Ping. On 2014-06-26 13:43, Sebastian Huber wrote: This patch should be applied to GCC 4.9 and mainline. I do not have write access, so in case this gets approved, please commit it for me. gcc/ChangeLog 2014-06-26 Sebastian Huber sebastian.hu...@embedded-brains.de * config.gcc (nios2-*-*): Add RTEMS support. * config/nios2/rtems.h: New file. * config/nios2/t-rtems: Likewise.
Re: [PATCH] RTEMS: Add Nios 2 support
For the default multilib settings, it looks like you just intended to use -mcustom-fpu-cfg=60-2. I suggest you modify t-rtems to do that instead of enumerating the individual FPU insn options. Other than that, the patch looks okay. Chung-Lin On 2014/6/26 07:43 PM, Sebastian Huber wrote: diff --git a/gcc/config/nios2/t-rtems b/gcc/config/nios2/t-rtems new file mode 100644 index 000..f95fa3c --- /dev/null +++ b/gcc/config/nios2/t-rtems @@ -0,0 +1,133 @@ +# Custom RTEMS multilibs + +MULTILIB_OPTIONS = mhw-mul mhw-mulx mhw-div mcustom-fadds=253 mcustom-fdivs=255 mcustom-fmuls=252 mcustom-fsubs=254 + +# Enumeration of multilibs + +# MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fsubs=254 +# MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div +MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254
[PATCH, libatomic, alpha]: Add -mfp-trap-mode=sui to compile flags
Hello!
-mfp-trap-mode=sui is needed in addition to -mieee to compile fenv.c
for older alphas to generate inexact exceptions.
2013-07-18 Uros Bizjak ubiz...@gmail.com
* configure.tgt (alpha*): Add -mfp-trap-mode=sui to XCFLAGS.
Tested on alpha-linux-gnu, committed to mainline SVN.
Uros.
Index: configure.tgt
===
--- configure.tgt (revision 212748)
+++ configure.tgt (working copy)
@@ -27,7 +27,11 @@
# work out any special compilation flags as necessary.
case ${target_cpu} in
- alpha*) ARCH=alpha ;;
+ alpha*)
+ # fenv.c needs this option to generate inexact exceptions.
+ XCFLAGS=${XCFLAGS} -mfp-trap-mode=sui
+ ARCH=alpha
+ ;;
rs6000 | powerpc*) ARCH=powerpc ;;
sh*) ARCH=sh ;;
RE: [committed] Fix MIPS p5600 scheduler
Hi Richard, Thanks for fixing this. I'm afraid I managed to get confused between failures we had seen sporadically in our development work and thought they were known regressions on trunk waiting to be fixed when actually we were introducing them. Apologies for the breakage. Regards, Matthew -Original Message- From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Sent: 17 July 2014 21:18 To: gcc-patches@gcc.gnu.org Cc: Jaydeep Patil; Matthew Fortune Subject: [committed] Fix MIPS p5600 scheduler The p5600 scheduler wasn't restricting itself to -mtune=p5600 and so was being used for other CPUs too. This showed up as a failure in various tests, including gcc.target/mips/octeon-pipe-1.c. (Thinking about it, it was probably also why umips-lwp-*.c started failing, although the patch I just committed is still OK after this fix.) Guys: please make sure you do a before-and-after comparison of test results, even if it obviously shouldn't be necessary. This amount of fallout in gcc.target/mips would have been a red flag that something was wrong. Tested on mips64-linux-gnu and applied. Thanks, Richard gcc/ * config/mips/p5600.md: Add missing cpu tests. Index: gcc/config/mips/p5600.md === --- gcc/config/mips/p5600.md 2014-07-17 20:53:50.423095856 +0100 +++ gcc/config/mips/p5600.md 2014-07-17 20:53:50.764100479 +0100 @@ -47,52 +47,62 @@ (define_reservation p5600_alq_alu p56 ;; fadd, fsub (define_insn_reservation p5600_fpu_fadd 4 - (eq_attr type fadd,fabs,fneg) + (and (eq_attr cpu p5600) + (eq_attr type fadd,fabs,fneg)) p5600_fpu_long, p5600_fpu_apu) ;; fabs, fneg, fcmp (define_insn_reservation p5600_fpu_fabs 2 - (eq_attr type fabs,fneg,fcmp,fmove) + (and (eq_attr cpu p5600) + (eq_attr type fabs,fneg,fcmp,fmove)) p5600_fpu_short, p5600_fpu_apu) ;; fload (define_insn_reservation p5600_fpu_fload 8 - (eq_attr type fpload,fpidxload) + (and (eq_attr cpu p5600) + (eq_attr type fpload,fpidxload)) p5600_fpu_long, p5600_fpu_apu) ;; fstore (define_insn_reservation p5600_fpu_fstore 1 - (eq_attr type fpstore,fpidxstore) + (and (eq_attr cpu p5600) + (eq_attr type fpstore,fpidxstore)) p5600_fpu_short, p5600_fpu_apu) ;; fmadd (define_insn_reservation p5600_fpu_fmadd 9 - (eq_attr type fmadd) + (and (eq_attr cpu p5600) + (eq_attr type fmadd)) p5600_fpu_long, p5600_fpu_apu) ;; fmul (define_insn_reservation p5600_fpu_fmul 5 - (eq_attr type fmul) + (and (eq_attr cpu p5600) + (eq_attr type fmul)) p5600_fpu_long, p5600_fpu_apu) ;; fdiv, fsqrt (define_insn_reservation p5600_fpu_div 17 - (eq_attr type fdiv,frdiv,fsqrt,frsqrt) + (and (eq_attr cpu p5600) + (eq_attr type fdiv,frdiv,fsqrt,frsqrt)) p5600_fpu_long, p5600_fpu_apu*17) ;; fcvt (define_insn_reservation p5600_fpu_fcvt 4 - (eq_attr type fcvt) + (and (eq_attr cpu p5600) + (eq_attr type fcvt)) p5600_fpu_long, p5600_fpu_apu) ;; mtc (define_insn_reservation p5600_fpu_fmtc 7 - (eq_attr type mtc) + (and (eq_attr cpu p5600) + (eq_attr type mtc)) p5600_fpu_short, p5600_fpu_store) ;; mfc (define_insn_reservation p5600_fpu_fmfc 4 - (eq_attr type mfc) + (and (eq_attr cpu p5600) + (eq_attr type mfc)) p5600_fpu_short, p5600_fpu_store) ;; madd/msub feeding into the add source @@ -105,100 +115,120 @@ (define_bypass 5 p5600_fpu_fmadd p560 ;; and (define_insn_reservation p5600_int_and 1 - (eq_attr move_type logical) + (and (eq_attr cpu p5600) + (eq_attr move_type logical)) p5600_alq_alu) ;; lui (define_insn_reservation p5600_int_lui 1 - (eq_attr move_type const) + (and (eq_attr cpu p5600) + (eq_attr move_type const)) p5600_alq_alu) ;; Load lb, lbu, lh, lhu, lq, lw, lw_i2f, lwxs (define_insn_reservation p5600_int_load 4 - (eq_attr move_type load) + (and (eq_attr cpu p5600) + (eq_attr move_type load)) p5600_agq_ldsta) ;; store (define_insn_reservation p5600_int_store 3 - (eq_attr move_type store) + (and (eq_attr cpu p5600) + (eq_attr move_type store)) p5600_agq_ldsta) ;; andi, sll, srl, seb, seh (define_insn_reservation p5600_int_arith_1 1 - (eq_attr move_type andi,sll0,signext) + (and (eq_attr cpu p5600) + (eq_attr move_type andi,sll0,signext)) p5600_agq_al2 | p5600_alq_alu) ;; addi, addiu, ori, xori, add, addu (define_insn_reservation p5600_int_arith_2 1 - (eq_attr alu_type add,or,xor) + (and (eq_attr cpu p5600) + (eq_attr alu_type add,or,xor)) p5600_agq_al2 | p5600_alq_alu) ;; nor, sub (define_insn_reservation p5600_int_arith_3 1 - (eq_attr alu_type nor,sub) + (and (eq_attr cpu p5600) + (eq_attr alu_type nor,sub)) p5600_alq_alu) ;; srl, sra, rotr, slt, sllv, srlv (define_insn_reservation p5600_int_arith_4 1 -
Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)
On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: Hi! As a leftover of r210931, an unused variable resulted in: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o mmix.o -MT mmix.o -MMD -MP -MF ./.deps/mmix.TPo ../../../gcc/gcc/config/mmix/mmix.c ../../../gcc/gcc/config/mmix/mmix.c: In function ?int64_t mmix_intval(const_rtx)?: ../../../gcc/gcc/config/mmix/mmix.c:2694:12: error: unused variable ?retval? [-Werror=unused-variable] uint64_t retval; ^ cc1plus: all warnings being treated as errors Weird that I haven't seen this with a host g++ = 4.7 (4.7.2-2); I've certainly built post-r210931 (post-2014-05-26) for example r212486, but obviously so, thanks. I see the warning in my logs but -Werror wasn't isn't used and I didn't pay attention. Did something change more recently re: building with -Werror? brgds, H-P
PR 61628: Invalid sharing of DECL_INCOMING_RTL
My patch to reduce the amount of rtx garbage created:
2014-05-17 Richard Sandiford rdsandif...@googlemail.com
* emit-rtl.h (replace_equiv_address, replace_equiv_address_nv): Add an
inplace argument. Store the new address in the original MEM when true.
* emit-rtl.c (change_address_1): Likewise.
(adjust_address_1, adjust_automodify_address_1, offset_address):
Update accordingly.
* rtl.h (plus_constant): Add an inplace argument.
* explow.c (plus_constant): Likewise. Try to reuse the original PLUS
when true. Avoid generating (plus X (const_int 0)).
* function.c (instantiate_virtual_regs_in_rtx): Adjust the PLUS
in-place. Pass true to plus_constant.
(instantiate_virtual_regs_in_insn): Pass true to replace_equiv_address.
exposed a case where a DECL_INCOMING_RTL MEM rtx was being reused in insn
patterns without being copied. This meant that instantiating virtual
registers changed the DECL_INCOMING_RTL too.
The patch fixes this by adding the missing copy_rtxes. However,
validize_mem has a bit of an awkward interface as far as sharing goes.
If the MEM is already valid, validize_mem returns the original rtx,
but if the MEM is not valid it creates a new one. This means that if
you copy first you create garbage rtl if the MEM was invalid, whereas if
you don't copy first you get invalid sharing if the MEM was valid.
Obviously we need to err on the side of copying first, to avoid the
invalid sharing. The patch therefore changes the interface so that
validize_mem can modify the MEM in-place.
I went through all calls to validize_mem to try to find cases where
this might cause a problem. The patch fixes up the ones I could see.
Most callers already copy first, so as well fixing the bug, this seems
to reduce the amount of garbage created.
Tested on x86_64-linux-gnu, sparc-sun-solaris2.1? and
powerpc64-unknown-linux-gnu. OK to install?
Thanks,
Richard
gcc/
PR middle-end/61268
* function.c (assign_parm_setup_reg): Prevent invalid sharing of
DECL_INCOMING_RTL and entry_parm.
(get_arg_pointer_save_area): Likewise arg_pointer_save_area.
* calls.c (load_register_parameters): Likewise argument values.
(emit_library_call_value_1, store_one_arg): Likewise argument
save areas.
* config/i386/i386.c (assign_386_stack_local): Likewise the local
stack slot.
* explow.c (validize_mem): Modify the argument in-place.
Index: gcc/function.c
===
--- gcc/function.c 2014-07-11 11:55:10.495121493 +0100
+++ gcc/function.c 2014-07-18 08:57:07.047215306 +0100
@@ -2662,13 +2662,14 @@ assign_parm_adjust_entry_rtl (struct ass
/* Handle calls that pass values in multiple non-contiguous
locations. The Irix 6 ABI has examples of this. */
if (GET_CODE (entry_parm) == PARALLEL)
- emit_group_store (validize_mem (stack_parm), entry_parm,
+ emit_group_store (validize_mem (copy_rtx (stack_parm)), entry_parm,
data-passed_type,
int_size_in_bytes (data-passed_type));
else
{
gcc_assert (data-partial % UNITS_PER_WORD == 0);
- move_block_from_reg (REGNO (entry_parm), validize_mem (stack_parm),
+ move_block_from_reg (REGNO (entry_parm),
+ validize_mem (copy_rtx (stack_parm)),
data-partial / UNITS_PER_WORD);
}
@@ -2837,7 +2838,7 @@ assign_parm_setup_block (struct assign_p
else
gcc_assert (!size || !(PARM_BOUNDARY % BITS_PER_WORD));
- mem = validize_mem (stack_parm);
+ mem = validize_mem (copy_rtx (stack_parm));
/* Handle values in multiple non-contiguous locations. */
if (GET_CODE (entry_parm) == PARALLEL)
@@ -2972,7 +2973,7 @@ assign_parm_setup_reg (struct assign_par
assign_parm_find_data_types and expand_expr_real_1. */
equiv_stack_parm = data-stack_parm;
- validated_mem = validize_mem (data-entry_parm);
+ validated_mem = validize_mem (copy_rtx (data-entry_parm));
need_conversion = (data-nominal_mode != data-passed_mode
|| promoted_nominal_mode != data-promoted_mode);
@@ -3228,7 +3229,7 @@ assign_parm_setup_stack (struct assign_p
/* Conversion is required. */
rtx tempreg = gen_reg_rtx (GET_MODE (data-entry_parm));
- emit_move_insn (tempreg, validize_mem (data-entry_parm));
+ emit_move_insn (tempreg, validize_mem (copy_rtx (data-entry_parm)));
push_to_sequence2 (all-first_conversion_insn,
all-last_conversion_insn);
to_conversion = true;
@@ -3265,8 +3266,8 @@ assign_parm_setup_stack (struct assign_p
set_mem_attributes (data-stack_parm, parm, 1);
}
- dest = validize_mem (data-stack_parm);
- src = validize_mem (data-entry_parm);
+ dest = validize_mem
[Ada] Implement No_Standard_Allocators_After_Elaboration
This implements the final definition of the Ada 2012 restriction
No_Standard_Allocators_After_Elaboration. There are two static
cases. First appearence in task body, this one we already had
before (compiled with -gnatj55 -gnatld7)
1. procedure Pmain2 is
2.type P is access all Integer;
3.PV : P;
4.task X;
5.task body X is
6.begin
7. PV := new Integer;
|
violation of restriction
No_Standard_Allocators_After_Elaboration
at gnat.adc:1
8.end;
9. begin
10.null;
11. end;
Second, also a static case, appearence in a parameterless
library level procedure (same switches)
1. procedure Pmain is
2.type R is access all Integer;
3.RV : R;
4. begin
5.RV := new Integer;
|
violation of restriction
No_Standard_Allocators_After_Elaboration
at gnat.adc:1
6. end;
Finally the dynamic case tested at run-time:
1. with Allocate_After_Elab;
2. procedure Allocate_After_Elab_Test is
3. begin
4.Allocate_After_Elab (42);
5. end Allocate_After_Elab_Test;
1. with Ada.Text_IO;
2. procedure Allocate_After_Elab (X : Integer) is
3.type Int_Ptr_Type is access Integer;
4.My_Int_Ptr : Int_Ptr_Type;
5. begin
6.My_Int_Ptr := new Integer'(X);
7.Ada.Text_IO.Put_Line (Have used allocator);
8. end Allocate_After_Elab;
If we run Allocate_After_Elab_Test, we get:
raised PROGRAM_ERROR : standard allocator after elaboration is complete is not
allowed
(No_Standard_Allocators_After_Elaboration restriction active)
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-18 Robert Dewar de...@adacore.com
* gcc-interface/Make-lang.in: Add entry for s-elaall.o
* bcheck.adb (Check_Consistent_Restrictions):
Remove obsolete code checking for violation of
No_Standard_Allocators_After_Elaboration (main program)
* bindgen.adb (Gen_Adainit): Handle
No_Standard_Allocators_After_Elaboration
(Gen_Output_File_Ada): ditto.
* exp_ch4.adb (Expand_N_Allocator): Handle
No_Standard_Allocators_After_Elaboration.
* Makefile.rtl: Add entry for s-elaall
* rtsfind.ads: Add entry for Check_Standard_Allocator.
* s-elaall.ads, s-elaall.adb: New files.
* sem_ch4.adb (Analyze_Allocator): Handle
No_Standard_Allocators_After_Elaboration.
Index: bindgen.adb
===
--- bindgen.adb (revision 212735)
+++ bindgen.adb (working copy)
@@ -739,8 +739,8 @@
if Dispatching_Domains_Used then
WBI ( procedure Freeze_Dispatching_Domains;);
WBI ( pragma Import);
-WBI ((Ada, Freeze_Dispatching_Domains,
- __gnat_freeze_dispatching_domains););
+WBI ((Ada, Freeze_Dispatching_Domains,
+ __gnat_freeze_dispatching_domains););
end if;
WBI ( begin);
@@ -749,6 +749,18 @@
WBI ( end if;);
WBI ( Is_Elaborated := True;);
+ -- Call System.Elaboration_Allocators.Mark_Start_Of_Elaboration if
+ -- restriction No_Standard_Allocators_After_Elaboration is active.
+
+ if Cumulative_Restrictions.Set
+ (No_Standard_Allocators_After_Elaboration)
+ then
+WBI ( System.Elaboration_Allocators.
+ Mark_Start_Of_Elaboration;);
+ end if;
+
+ -- Generate assignments to initialize globals
+
Set_String ( Main_Priority := );
Set_Int(Main_Priority);
Set_Char (';');
@@ -996,6 +1008,15 @@
Gen_Elab_Calls;
+ -- Call System.Elaboration_Allocators.Mark_Start_Of_Elaboration if
+ -- restriction No_Standard_Allocators_After_Elaboration is active.
+
+ if Cumulative_Restrictions.Set
+(No_Standard_Allocators_After_Elaboration)
+ then
+ WBI ( System.Elaboration_Allocators.Mark_End_Of_Elaboration;);
+ end if;
+
-- From this point, no new dispatching domain can be created.
if Dispatching_Domains_Used then
@@ -2482,10 +2503,23 @@
WBI (with System.Restrictions;);
end if;
+ -- Generate with of Ada.Exceptions if needs library finalization
+
if Needs_Library_Finalization then
WBI (with Ada.Exceptions;);
end if;
+ -- Generate with of System.Elaboration_Allocators if the restriction
+ -- No_Standard_Allocators_After_Elaboration was present.
+
+ if Cumulative_Restrictions.Set
+ (No_Standard_Allocators_After_Elaboration)
+ then
+ WBI (with System.Elaboration_Allocators;);
+ end if;
+
+ -- Generate start of package body
+
WBI ();
WBI (package body Ada_Main is);
Re: [PATCH, rs6000] Fix PR61542 - V4SF vector extract for little endian
Bill Schmidt wschm...@linux.vnet.ibm.com writes: Bernd, thanks. At this point I think I will avoid opening this can of worms and not worry about backporting the test case. Sorry for the late answer (catching up on a big backlog), but the testcase was originally added for an optimisation rather than a bug fix. It sounds like it tripped an ICE, so it should be safe to backport as a compile-only test with no dg-additional-options and no dg-finals. Thanks, Richard Thanks, Bill On Wed, 2014-06-18 at 19:18 +0200, Bernd Edlinger wrote: Hi, On Wed, 18 Jun 2014 09:56:15, David Edelsohn wrote: On Tue, Jun 17, 2014 at 6:44 PM, BIll Schmidt wschm...@linux.vnet.ibm.com wrote: Hi, As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542, a new test case (gcc.dg/vect/vect-nop-move.c) was added in 4.9. This exposes a bug on PowerPC little endian for extracting an element from a V4SF value that goes back to 4.8. The following patch fixes the problem. Tested on powerpc64le-unknown-linux-gnu with no regressions. Ok to commit to trunk? I would also like to commit to 4.8 and 4.9 as soon as possible to be picked up by the distros. This is okay everywhere. I would also like to backport gcc.dg/vect/vect-nop-move.c to 4.8 to provide regression coverage. You should ask Bernd and the RMs. Was the bug fix that prompted the new testcase backported to all targets? Thanks, David actually I only added the check_vect to that test case, but that exposed a bug on Solaris-9. See https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=207668. That was in the -fdump-rtl-combine-details handling, where fprintf got a NULL value passed for %s, which ICEs on Solaris9. So if you backport that test case, be sure to check that one too. Originally the test case seems to check something for the aarch64-target. See https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=205712. Obviously the patch in rtlanal.c (set_noop_p) was never backported to the 4.8 branch. Maybe Tejas who originally wrote that test case, can explain, if it makes sense to backport this fix too. Thanks Bernd.
Re: [PATCH] RTEMS: Add Nios 2 support
On 14/7/18 2:30 PM, Chung-Lin Tang wrote: For the default multilib settings, it looks like you just intended to use -mcustom-fpu-cfg=60-2. I suggest you modify t-rtems to do that instead of enumerating the individual FPU insn options. Other than that, the patch looks okay. Chung-Lin BTW, I assume you have done the appropriate testing for a nios2-rtems toolchain? Thanks, Chung-Lin On 2014/6/26 07:43 PM, Sebastian Huber wrote: diff --git a/gcc/config/nios2/t-rtems b/gcc/config/nios2/t-rtems new file mode 100644 index 000..f95fa3c --- /dev/null +++ b/gcc/config/nios2/t-rtems @@ -0,0 +1,133 @@ +# Custom RTEMS multilibs + +MULTILIB_OPTIONS = mhw-mul mhw-mulx mhw-div mcustom-fadds=253 mcustom-fdivs=255 mcustom-fmuls=252 mcustom-fsubs=254 + +# Enumeration of multilibs + +# MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fsubs=254 +# MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mhw-div +MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 +MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 +MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254
[Ada] Enforce style check for all binary operators
Add two missing style checks for token spacing for binary operators when switches -gnatyt, -gnatyy or -gnatyg is used. Preserve previous behavior with debug switch -gnatd.Q Test: $ gcc -c pkg.ads -gnatyt -gnatl -gnatd7 Compiling: pkg.ads 1. package Pkg is 2.One : constant := 1; 3.type Entier is range 0 .. 16-One; | (style) space required 4.AB : constant String := AB; | (style) space required 5. end Pkg; 5 lines: No errors, 2 warnings Invoking gcc -c pkg.ads -gnatyt -gnatd.Q should not report any warning. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-18 Vincent Celier cel...@adacore.com * par-ch4.adb (Simple_Expression): Add missing style check for binary adding operators. (Term): Add missing style check for multiplying operators. Index: debug.adb === --- debug.adb (revision 212725) +++ debug.adb (working copy) @@ -134,7 +134,7 @@ -- d.N Add node to all entities -- d.O Dump internal SCO tables -- d.P Previous (non-optimized) handling of length comparisons - -- d.Q + -- d.Q Previous (incomplete) style check for binary operators -- d.R Restrictions in ali files in positional form -- d.S Force Optimize_Alignment (Space) -- d.T Force Optimize_Alignment (Time) Index: par-ch4.adb === --- par-ch4.adb (revision 212656) +++ par-ch4.adb (working copy) @@ -2152,6 +2152,11 @@ exit when Token not in Token_Class_Binary_Addop; Tokptr := Token_Ptr; Node2 := New_Op_Node (P_Binary_Adding_Operator, Tokptr); + + if Style_Check and then not Debug_Flag_Dot_QQ then + Style.Check_Binary_Operator; + end if; + Scan; -- past operator Set_Left_Opnd (Node2, Node1); Node1 := P_Term; @@ -2406,6 +2411,11 @@ exit when Token not in Token_Class_Mulop; Tokptr := Token_Ptr; Node2 := New_Op_Node (P_Multiplying_Operator, Tokptr); + + if Style_Check and then not Debug_Flag_Dot_QQ then +Style.Check_Binary_Operator; + end if; + Scan; -- past operator Set_Left_Opnd (Node2, Node1); Set_Right_Opnd (Node2, P_Factor);
Re: [wwwdocs] PATCH for Re: New French mirror
On Mon, 14 Jul 2014, Tim Semeijn wrote: We have decided to switch domains so the mirror details have changed. The old domain will be up for a while but it would be best for the details to be edited. -- http://mirror.bbln.org/gcc ftp://mirror.bbln.org/gcc rsync://mirror.bbln.org/gcc Contact mailaddress: n...@bbln.org Okay, thanks for letting me know. Here is what I just applied. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.223 diff -u -r1.223 mirrors.html --- mirrors.html17 Jul 2014 23:00:18 - 1.223 +++ mirrors.html18 Jul 2014 09:22:18 - @@ -25,10 +25,10 @@ liFrance (no snapshots): a href=ftp://ftp.lip6.fr/pub/gcc/;ftp.lip6.fr/a, thanks to ftpmaint at lip6.fr/li liFrance, Brittany: a href=ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/;ftp.irisa.fr/a, thanks to ftpmaint at irisa.fr/li liFrance, Roubaix: - a href=http://mirror.bbln.nl/gcc/;http://mirror.bbln.nl/gcc/a | - a href=ftp://mirror.bbln.nl/gcc;ftp://mirror.bbln.nl/gcc/a | - a href=rsync://mirror.bbln.nl/gccrsync://mirror.bbln.nl/gcc/a, - thanks to Tim Semeijn (n...@bbln.nl) and BBLN./li + a href=http://mirror.bbln.org/gcc/;http://mirror.bbln.org/gcc//a | + a href=ftp://mirror.bbln.org/gcc;ftp://mirror.bbln.org/gcc/a | + a href=rsync://mirror.bbln.org/gccrsync://mirror.bbln.org/gcc/a, + thanks to Tim Semeijn (n...@bbln.org) and BBLN./li liFrance, Versailles: a href=ftp://ftp.uvsq.fr/pub/gcc/;ftp.uvsq.fr/a, thanks to ftpmaint at uvsq.fr/li liGermany, Berlin: a href=ftp://ftp.fu-berlin.de/unix/languages/gcc/;ftp.fu-berlin.de/a, thanks to ftp at fu-berlin.de/li liGermany: a href=ftp://ftp.gwdg.de/pub/misc/gcc/;ftp.gwdg.de/a, thanks to emoenke at gwdg.de/li
[Ada] Container Indexing over a derived container type
the container type is a derived type, the value of the inherited aspect is the Reference (or Constant_Reference) operation declared for the parent type. However, Reference is also a primitive operation of the new type, and the inherited operation has a different signature. It is necessary to retrieve the right operation from the list of primitive operations of the derived type. Compiling and executing the following must yield: 2 10 111 1 --- with Ada.Characters.Handling; use Ada.Characters.Handling; with Ada.Containers.Doubly_Linked_Lists; with Ada.Containers.Indefinite_Hashed_Maps; with Ada.Strings.Hash; use Ada.Containers; with Text_IO; use Text_IO; procedure Derived_Container is function Same_Strings (S, T : String) return Boolean is begin return To_Lower (S) = To_Lower (T); end Same_Strings; type Place is record Page : Positive; Line : Positive; Col : Positive; end record; package Places is new Doubly_Linked_Lists (Place); package Indexes is new Indefinite_Hashed_Maps (Key_Type= String, Element_Type= Places.List, Hash= Ada.Strings.Hash, Equivalent_Keys = Same_Strings, = = Places.=); type Text_Map is new Indexes.Map with null record; -- with Variable_Indexing = Reference; -- Without aspect, indexing gives -- container cannot be indexed with Cursor My_Index : Text_Map; My_Place : constant Place := (1, 2, 3); use type Indexes.Cursor; procedure Add_Entry (The_Index : in out Text_Map; Word : String; P : Place) is M_Cursor : Indexes.Cursor; New_List : Places.List := Places.Empty_List; begin M_Cursor := The_Index.Find (Word); if M_Cursor /= Indexes.No_Element then The_Index (M_Cursor).Append (P); else New_List.Append (P); The_Index.Include (Word, New_List); end if; end Add_Entry; begin Add_Entry (The_Index = My_Index, Word = bill, P = My_Place); Add_Entry (The_Index = My_Index, Word = John, P = (10, 10, 10)); Add_Entry (The_Index = My_Index, Word = John, P = (111, 333, 999)); Put_Line (Integer'Image (Integer (My_Index.Length))); for Datum of My_Index loop for Location of Datum loop Put_Line (Integer'Image (Location.Page)); end loop; end loop; end Derived_Container; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-18 Ed Schonberg schonb...@adacore.com * sem_ch4.adb (Try_Container_Indexing): If the container type is a derived type, the value of the inherited aspect is the Reference operation declared for the parent type. However, Reference is also a primitive operation of the new type, and the inherited operation has a different signature. We retrieve the right one from the list of primitive operations of the derived type. Index: sem_ch4.adb === --- sem_ch4.adb (revision 212779) +++ sem_ch4.adb (working copy) @@ -7020,6 +7020,16 @@ else return False; end if; + + -- If the container type is a derived type, the value of the inherited + -- aspect is the Reference operation declared for the parent type. + -- However, Reference is also a primitive operation of the type, and + -- the inherited operation has a different signature. We retrieve the + -- right one from the list of primitive operations of the derived type. + + elsif Is_Derived_Type (Etype (Prefix)) then + Func := Find_Prim_Op (Etype (Prefix), Chars (Func_Name)); + Func_Name := New_Occurrence_Of (Func, Loc); end if; Assoc := New_List (Relocate_Node (Prefix));
[Ada] Make sure all rep clauses are removed from tree for -gnatI
Previously all rep clauses were ignored in -gnatI mode, but in two
cases (enumeration rep clauses and record rep clauses), they were
not removed from the tree, causing trouble with ASIS tools. These
two cases are now consistent, and ASIS tools will see none of the
ignored rep clauses (e.g. gnatpp will not list ignored rep clauses).
The following test generates no output if compiled with
gcc -c ignorei.ads -gnatI -gnatG log
grep 35 log
1. package IgnoreI is
2.type R is record
3. X : Integer;
4.end record;
5.for R use record
6. X at 0 range 0 .. 35;
7.end record;
8.type E is (a,b,c);
9.for E use (0,1,35);
10. end IgnoreI;
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-18 Robert Dewar de...@adacore.com
* freeze.adb (Check_Address_Clause): Use Kill_Rep_Clause (no
functional change).
* gnat_ugn.texi: Document that -gnatI removes rep clauses from
ASIS trees.
* sem_ch13.adb (Kill_Rep_Clause): New procedure
(Analyze_Attribute_Definition_Clause): Use
Kill_Rep_Clause. This is just a cleanup, no functional effect.
(Analyze_Enumeration_Representation_Clause):
Use Kill_Rep_Clause. This means that enum rep
clauses are now properly removed from -gnatct trees.
(Analyze_Record_Representation_Clause): Same change.
* sem_ch13.ads (Kill_Rep_Clause): New procedure.
Index: gnat_ugn.texi
===
--- gnat_ugn.texi (revision 212782)
+++ gnat_ugn.texi (working copy)
@@ -4091,6 +4091,12 @@
Note that this option should be used only for compiling -- the
code is likely to malfunction at run time.
+Note that when @code{-gnatct} is used to generate trees for input
+into @code{ASIS} tools, these representation clauses are removed
+from the tree. This means that the tool will not see them. For
+example, if you use @command{gnatpp} with @code{-gnatI}, the pretty printed
+output will not include the ignored representation clauses.
+
@item -gnatjnn
@cindex @option{-gnatjnn} (@command{gcc})
Reformat error messages to fit on nn character lines
Index: freeze.adb
===
--- freeze.adb (revision 212737)
+++ freeze.adb (working copy)
@@ -604,8 +604,10 @@
end if;
end;
-Rewrite (Addr, Make_Null_Statement (Sloc (E)));
+-- And now remove the address clause
+Kill_Rep_Clause (Addr);
+
elsif not Error_Posted (Expr)
and then not Needs_Finalization (Typ)
then
Index: sem_ch13.adb
===
--- sem_ch13.adb(revision 212782)
+++ sem_ch13.adb(working copy)
@@ -3647,19 +3647,12 @@
Attribute_Machine_Radix |
Attribute_Object_Size|
Attribute_Size |
+ Attribute_Small |
Attribute_Stream_Size|
Attribute_Value_Size =
- Rewrite (N, Make_Null_Statement (Sloc (N)));
+ Kill_Rep_Clause (N);
return;
--- Perhaps 'Small should not be ignored by Ignore_Rep_Clauses ???
-
-when Attribute_Small =
- if Ignore_Rep_Clauses then
- Rewrite (N, Make_Null_Statement (Sloc (N)));
- return;
- end if;
-
-- The following should not be ignored, because in the first place
-- they are reasonably portable, and should not cause problems in
-- compiling code from another target, and also they do affect
@@ -3676,6 +3669,13 @@
Attribute_Write =
null;
+-- We do not do anything here with address clauses, they will be
+-- removed by Freeze later on, but for now, it works better to
+-- keep then in the tree.
+
+when Attribute_Address =
+ null;
+
-- Other cases are errors (attribute cannot be set with
-- definition clause), which will be caught below.
@@ -3830,7 +3830,7 @@
-- Even when ignoring rep clauses we need to indicate that the
-- entity has an address clause and thus it is legal to declare
--- it imported.
+-- it imported. Freeze will get rid of the address clause later.
if Ignore_Rep_Clauses then
if Ekind_In (U_Ent, E_Variable, E_Constant) then
@@ -5365,6 +5365,7 @@
begin
if Ignore_Rep_Clauses then
+ Kill_Rep_Clause (N);
return;
end if;
@@ -5740,6 +5741,7 @@
begin
if Ignore_Rep_Clauses then
+ Kill_Rep_Clause (N);
return;
end if;
@@ -10286,6 +10288,16 @@
end if;
[Ada] Failure to detect illegal parens in static predicate
The rules for static predicates do not allow the type name to be parenthesized. This was not checked, but is now fixed, the following test now gives the error indicated (compiled with -gnatld7 -gnatj55) (it used to compile without errors). 1. package BadParenSP is 2.subtype r is integer with 3. static_predicate = (r) 2; | expression does not have required form for static predicate 4. end; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-18 Robert Dewar de...@adacore.com * sem_ch13.adb (Is_Type_Ref): Check that type name is not parenthesized. Index: sem_ch13.adb === --- sem_ch13.adb(revision 212797) +++ sem_ch13.adb(working copy) @@ -6247,7 +6247,8 @@ pragma Inline (Is_Type_Ref); -- Returns if True if N is a reference to the type for the predicate in -- the expression (i.e. if it is an identifier whose Chars field matches - -- the Nam given in the call). + -- the Nam given in the call). N must not be parenthesized, if the type + -- name appears in parens, this routine will return False. function Lo_Val (N : Node_Id) return Uint; -- Given static expression or static range from a Static_Predicate list, @@ -6770,7 +6771,9 @@ function Is_Type_Ref (N : Node_Id) return Boolean is begin - return Nkind (N) = N_Identifier and then Chars (N) = Nam; + return Nkind (N) = N_Identifier + and then Chars (N) = Nam + and then Paren_Count (N) = 0; end Is_Type_Ref;
[Ada] Alternate output modes for GNAT.Memory_Dump
Output lines from GNAT.Memory_Dump.Dump can now be prefixed with an offset relative to the start of the dump, or have no prefix at all, instead of showing an absolute address. Test: $ gnatmake -q dump_test $ ./dump_test 00: 4C 6F 72 65 6D 20 69 70 73 75 6D 20 64 6F 6C 6F Lorem ipsum dolo 10: 72 20 73 69 74 20 61 6D 65 74 2C 20 63 6F 6E 73 r sit amet, cons 20: 65 63 74 65 74 75 65 72 20 61 64 69 70 69 73 63 ectetuer adipisc 30: 69 6E 67 20 73 65 64 20 64 69 61 6D 20 6E 6F 6E ing sed diam non 40: 75 6D um with Ada.Text_IO; use Ada.Text_IO; with GNAT.Memory_Dump; use GNAT.Memory_Dump; procedure Dump_Test is S : constant String := Lorem ipsum dolor sit amet, consectetuer adipiscing sed diam nonum; begin Dump (S'Address, S'Length, Offset); end; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-18 Thomas Quinot qui...@adacore.com * g-memdum.adb, g-memdum.ads (Dump): New parameter Prefix, defaulted to Absolute_Address. Index: g-memdum.adb === --- g-memdum.adb(revision 212640) +++ g-memdum.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 2003-2010, AdaCore -- +-- Copyright (C) 2003-2014, AdaCore -- -- -- -- 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- -- @@ -30,6 +30,7 @@ -- with System; use System; +with System.Img_BIU; use System.Img_BIU; with System.Storage_Elements; use System.Storage_Elements; with GNAT.IO; use GNAT.IO; @@ -43,10 +44,18 @@ -- Dump -- -- - procedure Dump (Addr : System.Address; Count : Natural) is + procedure Dump + (Addr : Address; + Count : Natural; + Prefix : Prefix_Type := Absolute_Address) + is Ctr : Natural := Count; -- Count of bytes left to output + Offset_Buf : String (1 .. Standard'Address_Size / 4 + 4); + Offset_Last : Natural; + -- Buffer for prefix in Offset mode + Adr : Address := Addr; -- Current address @@ -56,14 +65,12 @@ C : Character; -- Character at current storage address - AIL : constant := Address_Image_Length - 4 + 2; - -- Number of chars in initial address + colon + space + AIL : Natural; + -- Number of chars in prefix (including colon and space) - Line_Len : constant Natural := AIL + 3 * 16 + 2 + 16; + Line_Len : Natural; -- Line length for entire line - Line_Buf : String (1 .. Line_Len); - Hex : constant array (0 .. 15) of Character := 0123456789ABCDEF; type Char_Ptr is access all Character; @@ -71,53 +78,89 @@ function To_Char_Ptr is new Ada.Unchecked_Conversion (Address, Char_Ptr); begin - while Ctr /= 0 loop + case Prefix is + when Absolute_Address = +AIL := Address_Image_Length - 4 + 2; + when Offset = +Offset_Last := Offset_Buf'First - 1; +Set_Image_Based_Integer (Ctr, 16, 0, Offset_Buf, Offset_Last); +AIL := Offset_Last - 4 + 2; + when None = +AIL := 0; + end case; + Line_Len := AIL + 3 * 16 + 2 + 16; - -- Start of line processing + declare + Line_Buf : String (1 .. Line_Len); + begin + while Ctr /= 0 loop - if N = 0 then -declare - S : constant String := Image (Adr); -begin - Line_Buf (1 .. AIL) := S (4 .. S'Length - 1) : ; +-- Start of line processing + +if N = 0 then + case Prefix is + when Absolute_Address = + declare +S : constant String := Image (Adr); + begin +Line_Buf (1 .. AIL) := S (4 .. S'Length - 1) : ; + end; + + when Offset = + declare +Last : Natural := 0; +Len : Natural; + begin +Set_Image_Based_Integer + (Count - Ctr, 16, 0, Offset_Buf, Last); +Len := Last - 4; + +Line_Buf (1 .. AIL - Len - 2) := (others = '0'); +Line_Buf (AIL - Len - 1 .. AIL - 2) := +
[Ada] Allows Wide_String output on Windows console
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-07-18 Pascal Obry o...@adacore.com
* s-crtl.ads, i-cstrea.ads (fputwc): New routine.
* a-witeio.adb (Put): On platforms where there is translation
done by the OS output the raw text.
(New_Line): Use Put above to properly handle the LM wide characters.
Index: sysdep.c
===
--- sysdep.c(revision 212717)
+++ sysdep.c(working copy)
@@ -104,11 +104,12 @@
file positioning function, unless the input operation encounters
end-of-file.
- The other target dependent declarations here are for the two functions
- __gnat_set_binary_mode and __gnat_set_text_mode:
+ The other target dependent declarations here are for the three functions
+ __gnat_set_binary_mode, __gnat_set_text_mode and __gnat_set_wide_text_mode:
void __gnat_set_binary_mode (int handle);
void __gnat_set_text_mode (int handle);
+ void __gnat_set_wide_text_mode (int handle);
These functions have no effect in Unix (or similar systems where there is
no distinction between binary and text files), but in DOS (and similar
@@ -150,6 +151,12 @@
WIN_SETMODE (handle, O_TEXT);
}
+void
+__gnat_set_wide_text_mode (int handle)
+{
+ WIN_SETMODE (handle, _O_U16TEXT);
+}
+
#ifdef __CYGWIN__
char *
@@ -245,6 +252,12 @@
__gnat_set_text_mode (int handle ATTRIBUTE_UNUSED)
{
}
+
+void
+__gnat_set_wide_text_mode (int handle ATTRIBUTE_UNUSED)
+{
+}
+
char *
__gnat_ttyname (int filedes)
{
Index: s-crtl.ads
===
--- s-crtl.ads (revision 212640)
+++ s-crtl.ads (working copy)
@@ -6,7 +6,7 @@
-- --
-- S p e c --
-- --
--- Copyright (C) 2003-2013, Free Software Foundation, Inc. --
+-- Copyright (C) 2003-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- --
@@ -122,6 +122,9 @@
function fputc (C : int; stream : FILEs) return int;
pragma Import (C, fputc, fputc);
+ function fputwc (C : int; stream : FILEs) return int;
+ pragma Import (C, fputwc, fputwc);
+
function fputs (Strng : chars; Stream : FILEs) return int;
pragma Import (C, fputs, fputs);
Index: i-cstrea.ads
===
--- i-cstrea.ads(revision 212640)
+++ i-cstrea.ads(working copy)
@@ -6,7 +6,7 @@
-- --
-- S p e c --
-- --
--- Copyright (C) 1995-2013, Free Software Foundation, Inc. --
+-- Copyright (C) 1995-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- --
@@ -119,6 +119,9 @@
function fputc (C : int; stream : FILEs) return int
renames System.CRTL.fputc;
+ function fputwc (C : int; stream : FILEs) return int
+ renames System.CRTL.fputwc;
+
function fputs (Strng : chars; Stream : FILEs) return int
renames System.CRTL.fputs;
@@ -223,8 +226,9 @@
-- versa. These functions have no effect if text_translation_required is
-- false (i.e. in normal unix mode). Use fileno to get a stream handle.
- procedure set_binary_mode (handle : int);
- procedure set_text_mode (handle : int);
+ procedure set_binary_mode(handle : int);
+ procedure set_text_mode (handle : int);
+ procedure set_wide_text_mode (handle : int);
-- Full Path Name support --
@@ -256,6 +260,7 @@
pragma Import (C, set_binary_mode, __gnat_set_binary_mode);
pragma Import (C, set_text_mode, __gnat_set_text_mode);
+ pragma Import (C, set_wide_text_mode, __gnat_set_wide_text_mode);
pragma Import (C, max_path_len, __gnat_max_path_len);
pragma Import (C, full_name, __gnat_full_name);
Index: a-witeio.adb
===
--- a-witeio.adb(revision 212640)
+++ a-witeio.adb(working copy)
@@ -6,7 +6,7 @@
-- --
-- B o d y --
--
[Ada] Primitive operations of incomplete types
In Ada 2012, the formals of a subprogram can be incomplete types, and the subprogram is a primitive operation of the type. If the type is subsequently derived, it inherits the operation, and it can be explicitly overridden. Executing main.adb must yield: 1 2 --- with Prim_Test; use Prim_Test; procedure Main is One : T := (Val = 1); Two : T := (Val = 2); begin Q (One); Q (Two); end; --: package Prim_Test is type T; procedure P (V : T); procedure Q (It : T); type T is record Val : Integer; end record; type T2 is new T; overriding procedure P (V : T2); end Prim_Test; --- with Text_IO; use Text_IO; package body Prim_Test is procedure P (V : T) is begin null; end P; procedure Q (It : T) is begin Put_Line (Integer'Image (It.Val)); end; overriding procedure P (V : T2) is begin null; end P; end Prim_Test; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-18 Ed Schonberg schonb...@adacore.com * sinfo.ads, sinfo.adb (Incomplete_View): New semantic attribute of full type declaration, denotes previous declaration for incomplete view of the type. * sem_ch3.adb (Analyze_Full_Type_Declaration): Set Incomplete_View of declaration if one is present. (Replace_Type): When constructing the signature of an inherited operation, handle properly the case where the operation has a formal whose type is an incomplete view. * sem_util.adb (Collect_Primitive_Operations): Handle properly the case of an operation declared after an incomplete declaration for a type T and before the full declaration of T. Index: sem_ch3.adb === --- sem_ch3.adb (revision 212797) +++ sem_ch3.adb (working copy) @@ -2464,6 +2464,8 @@ Prev := Find_Type_Name (N); -- The full view, if present, now points to the current type + -- If there is an incomplete partial view, set a link to it, to + -- simplify the retrieval of primitive operations of the type. -- Ada 2005 (AI-50217): If the type was previously decorated when -- imported through a LIMITED WITH clause, it appears as incomplete @@ -2472,6 +2474,7 @@ if Ekind (Prev) = E_Incomplete_Type and then Present (Full_View (Prev)) then T := Full_View (Prev); + Set_Incomplete_View (N, Parent (Prev)); else T := Prev; end if; @@ -13537,6 +13540,7 @@ -- procedure Replace_Type (Id, New_Id : Entity_Id) is + Id_Type : constant Entity_Id := Etype (Id); Acc_Type : Entity_Id; Par : constant Node_Id := Parent (Derived_Type); @@ -13547,9 +13551,9 @@ -- be out of the proper scope for Gigi, so we insert a reference to -- it after the derivation. - if Ekind (Etype (Id)) = E_Anonymous_Access_Type then + if Ekind (Id_Type) = E_Anonymous_Access_Type then declare - Desig_Typ : Entity_Id := Designated_Type (Etype (Id)); + Desig_Typ : Entity_Id := Designated_Type (Id_Type); begin if Ekind (Desig_Typ) = E_Record_Type_With_Private @@ -13567,7 +13571,7 @@ or else (Is_Interface (Desig_Typ) and then not Is_Class_Wide_Type (Desig_Typ)) then - Acc_Type := New_Copy (Etype (Id)); + Acc_Type := New_Copy (Id_Type); Set_Etype (Acc_Type, Acc_Type); Set_Scope (Acc_Type, New_Subp); @@ -13599,16 +13603,23 @@ Build_Itype_Reference (Acc_Type, Parent (Derived_Type)); else - Set_Etype (New_Id, Etype (Id)); + Set_Etype (New_Id, Id_Type); end if; end; - elsif Base_Type (Etype (Id)) = Base_Type (Parent_Type) + -- In Ada2012, a formal may have an incomplete type but the type + -- derivation that inherits the primitive follows the full view. + + elsif Base_Type (Id_Type) = Base_Type (Parent_Type) or else - (Ekind (Etype (Id)) = E_Record_Type_With_Private - and then Present (Full_View (Etype (Id))) + (Ekind (Id_Type) = E_Record_Type_With_Private + and then Present (Full_View (Id_Type)) and then - Base_Type (Full_View (Etype (Id))) = Base_Type (Parent_Type)) + Base_Type (Full_View (Id_Type)) = Base_Type (Parent_Type)) + or else + (Ada_Version = Ada_2012 +and then Ekind (Id_Type) = E_Incomplete_Type +and then Full_View (Id_Type) = Parent_Type) then -- Constraint checks on formals are generated during expansion, -- based on the signature of the original
PR 60414: Patch proposal
Hi all, this is my first try to submit a patch, so please be kind and correct me when I do something wrong. I was contracted to fix some issues listed in the bugtracker for fortran. Please find attached my first attempt for bug PR60414 (I'll attach it to the bug in the tracker in a second). The bug terminates the compiler, because in the translation phase an unexpected construction is seen as actual argument. I tracked down the location where the decision to construct the parse tree seen is made and deduced, that the parameter matching is not respecting the array_ref done in the code not compiling. I have fixed this by checking if the -ref member of the actual argument is set. The analysis continues and the test case created for it compile fine now. Patch content: - Changelog entry in gcc/fortran/Changelog - Changelog entry in gcc/testsuite/Changelog - Patch in interface.c: two line comment, one line actual code - Testcase in gcc/testsuite/fortran.dg/unlimited_polymorphism_18.f90 Regards, Andre -- Andre Vehreschild diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog index c33936b..cb01a13 100644 --- a/gcc/fortran/ChangeLog +++ b/gcc/fortran/ChangeLog @@ -1,3 +1,11 @@ +2014-07-19 Andre Vehreschild ve...@gmx.de + + PR fortran/60414 + * interface.c (compare_parameter): Fix compile bug: During resolution + of generic an array reference in the actual argument was not + respected. Fixed by checking, if the ref member is non-null. Testcase + unlimited_polymorphism_18.f90 add. + 2014-06-15 Tobias Burnus bur...@net-b.de * symbol.c (check_conflict): Add codimension conflict with diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c index b210d18..8658003 100644 --- a/gcc/fortran/interface.c +++ b/gcc/fortran/interface.c @@ -2156,7 +2156,10 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual, if (symbol_rank (formal) == actual-rank || symbol_rank (formal) == -1) return 1; + /* Only check ranks compatibility, if actual is not an array reference, + i.e., actual(i) indicated by actual-ref being set. */ if (actual-ts.type == BT_CLASS CLASS_DATA (actual)-as + !actual-ref CLASS_DATA (actual)-as-rank == symbol_rank (formal)) return 1; diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog index f6e9f23..84e16da 100644 --- a/gcc/testsuite/ChangeLog +++ b/gcc/testsuite/ChangeLog @@ -1,3 +1,8 @@ +2014-07-19 Andre Vehreschild ve...@gmx.de + + * gfortran.dg/unlimited_polymorphism_18.f90: Check according to + PR 60414 + 2014-07-17 Richard Sandiford rdsandif...@googlemail.com * gcc.target/mips/umips-lwp-1.c (foo): Use a shift/add sequence
Re: Strenghten assumption about dynamic type changes (placement new)
On 07/08/2014 02:50 PM, Jan Hubicka wrote: I am looking into tracking dynamic types now. Obviously I need to set very exact rules about when these may change. Let me first say that this area is somewhat in flux in the standard; if we have a model of what we want the rules to be for GCC, there's a good chance of getting them into the standard. There are several unresolved DRs in this area already (1027, 1116, 1776). I think b variants are invalid Yes, by 3.8/7; we can't use 'a' to call foo after we've changed the object there to a C. currently we also assume t1 to be invalid, but t2 to be valid. I think the compiler ought to be able to treat both as undefined, because 'a' is either defined (t1) or allocated (t2) as a B, and B does not contain an array of char, so changing the dynamic type of that memory before the end of its storage duration ought to be undefined. But the standard doesn't currently say that, though it's along the lines of my proposed drafting for 1116 (which needs reworking). And I suppose that my notion of 'allocated type' can really only apply when using the library allocation functions in 18.6.1.1 and 18.6.1.2, not the inline placement new. Thanks! I guess we will have chance to chat about this on the Cauldron? As you probably know, for middle-end analysis it would be good if types was as sticky as possible. The sucess of type based devirtualization is largely based on the fact that it is hard to track a value of memory location by alias analysis (as calls to external functions are generally believed to change it) but it is easier to track type of a memory location, because the ways it can change are limited to construcition/destruction and placement news. I really only care about types containing virtual table pointers to not change, so non-PODs are out of game. Current propagation is built around assumption that once polymorphic type is constructed on a given location it won't change to completely different type, only possibly repatively construct destruct. This is based on our arlier conversation where the outcome was that chaning non-POD variable by placement new to different type is not defined. Anything weakter will probably need some cooperation from the frontend - I suppose best tie we have is the fact that you can't use 'a' to call foo after changing object. If placement news was marked for some time by a builtin, we could effectively thread the re-allocated objects as a new memory locations.. So perhaps we can go with my dynamic type patch enforcing the strong interpretation (no changes beyond construction/destruction once polymorphic type lands on a given location) and document it (do we have convenient place in the user documentation). If it turns out to be impractical, we can always carefuly relax it? Where I find current wording of DR1116? Honza Jason
[Ada] Reorganize handling of predicates
This reorganizes the handling of predicates, in preparation for proper implementation of real predicates. Several minor errors are corrected and we properly reject improper static real predicates. Static string predicates are now always rejected, in line with latest ARG thinking. The following shows how far we have got. Quite a few minor errors are fixed in recognizing predicate-static expressions. Still to be done is actual compile-time testing of real static predicates, and also noting that constants for which a predicate fails should not be considered as static. 1. package TestSP is 2.subtype F1 is Float with -- OK 3. Static_Predicate = F1 0.0 and 4.7 F1; 4.subtype F2 is Float with -- ERROR 5. Static_Predicate = (F2 + 1.0) 0.0 and 4.7 F2; | expression is not predicate-static (RM 4.3.2(16-22)) 6.subtype F3 is Float with -- OK 7. Dynamic_Predicate = (F3 + 1.0) 0.0 and 4.7 F3; 8.subtype F4 is Float with -- OK 9. Predicate = (F4 + 1.0) 0.0 and 4.7 F4; 10. 11.subtype S1 is String with -- OK 12. Static_Predicate = S1 ABC and then DEF = S1; 13.subtype S2 is String with -- ERROR 14. Static_Predicate = S2'First = 1 and then S2(1) = 'A'; | static predicate not allowed for non-scalar type S2 15.subtype S3 is String with -- OK 16. Dynamic_Predicate = S3'First = 1 and then S3(1) = 'A'; 17.subtype S4 is String with -- OK 18. Predicate = S4'First = 1 and then S4(1) = 'A'; 19. 20.subtype I1 is Integer with -- OK 21. Static_Predicate = I1 0 and 4 I1; 22.subtype I2 is Integer with -- ERROR 23. Static_Predicate = (I2 + 1) 0 and 4 I2; | expression is not predicate-static (RM 4.3.2(16-22)) 24.subtype I3 is Integer with -- OK 25. Dynamic_Predicate = (I3 + 1) 0 and 4 I3; 26.subtype I4 is Integer with -- OK 27. Predicate = (I4 + 1) 0 and 4 I4; 28.subtype I5 is Integer with -- ERROR (not caught before) 29. Static_Predicate = Boolean'(I5 0); | expression is not predicate-static (RM 4.3.2(16-22)) 30. 31.XF1 : constant F1 := 10.0; | warning: real predicate not applied 32.XF2 : constant F1 := 3.0; | warning: real predicate not applied 33.XF3 : constant := XF1; -- ERROR (not caught yet) 34. 35.XI1 : constant I1 := 10; | warning: static expression fails predicate check on I1 36.XI2 : constant I1 := 3; 37.XI3 : constant := XI1; -- ERROR (not caught yet) 38. end; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-18 Robert Dewar de...@adacore.com * einfo.adb (Has_Static_Predicate): New function. (Set_Has_Static_Predicate): New procedure. * einfo.ads (Has_Static_Predicate): New flag. * sem_ch13.adb (Is_Predicate_Static): New function (Build_Predicate_Functions): Use Is_Predicate_Static to reorganize (Add_Call): Minor change in Sloc of generated expression (Add_Predicates): Remove setting of Static_Pred, no longer used. * sem_ch4.adb (Has_Static_Predicate): Removed this function, replace by use of the entity flag Has_Static_Predicate_Aspect. * sem_eval.adb (Eval_Static_Predicate_Check): Check real case and issue warning that predicate is not checked for now. * sem_eval.ads (Eval_Static_Predicate_Check): Fix comments in spec. * sem_util.adb (Check_Expression_Against_Static_Predicate): Carry out check for any case where there is a static predicate, and output appropriate message. * sinfo.ads: Minor comment corrections. Index: sinfo.ads === --- sinfo.ads (revision 212802) +++ sinfo.ads (working copy) @@ -4022,13 +4022,13 @@ -- to deal with, and diagnose a simple expression other than a name for -- the right operand. This simplifies error recovery in the parser. - -- The Alternatives field below is present only if there is more - -- than one Membership_Choice present (which is legitimate only in - -- Ada 2012 mode) in which case Right_Opnd is Empty, and Alternatives - -- contains the list of choices. In the tree passed to the back end, - -- Alternatives is always No_List, and Right_Opnd is set (i.e. the - -- expansion circuitry expands out the complex set membership case - -- using simple membership operations). + -- The Alternatives field below is present only if there is more than + -- one Membership_Choice present (which is legitimate only in
[Ada] Constants are non-static if they fail a predicate check
If a constant is defined with a static expression, and the expression statically fails a static predicate, then the constant is not considered as being static, as shown by this updated example (see last few lines) 1. package TestSP is 2.subtype F1 is Float with -- OK 3. Static_Predicate = F1 0.0 and 4.7 F1; 4.subtype F2 is Float with -- ERROR 5. Static_Predicate = (F2 + 1.0) 0.0 and 4.7 F2; | expression is not predicate-static (RM 4.3.2(16-22)) 6.subtype F3 is Float with -- OK 7. Dynamic_Predicate = (F3 + 1.0) 0.0 and 4.7 F3; 8.subtype F4 is Float with -- OK 9. Predicate = (F4 + 1.0) 0.0 and 4.7 F4; 10. 11.subtype S1 is String with -- OK 12. Static_Predicate = S1 ABC and then DEF = S1; 13.subtype S2 is String with -- ERROR 14. Static_Predicate = S2'First = 1 and then S2(1) = 'A'; | static predicate not allowed for non-scalar type S2 15.subtype S3 is String with -- OK 16. Dynamic_Predicate = S3'First = 1 and then S3(1) = 'A'; 17.subtype S4 is String with -- OK 18. Predicate = S4'First = 1 and then S4(1) = 'A'; 19. 20.subtype I1 is Integer with -- OK 21. Static_Predicate = I1 0 and 4 I1; 22.subtype I2 is Integer with -- ERROR 23. Static_Predicate = (I2 + 1) 0 and 4 I2; | expression is not predicate-static (RM 4.3.2(16-22)) 24.subtype I3 is Integer with -- OK 25. Dynamic_Predicate = (I3 + 1) 0 and 4 I3; 26.subtype I4 is Integer with -- OK 27. Predicate = (I4 + 1) 0 and 4 I4; 28.subtype I5 is Integer with -- ERROR (not caught before) 29. Static_Predicate = Boolean'(I5 0); | expression is not predicate-static (RM 4.3.2(16-22)) 30. 31.XF1 : constant F1 := 10.0; -- WARN (not yet) | warning: real predicate not applied 32.XF2 : constant F1 := 3.0; -- OK | warning: real predicate not applied 33.XF3 : constant := XF1; -- ERROR (not caught yet) 34.XF4 : constant := XF2; -- OK 35. 36.XI1 : constant I1 := 10; -- WARN | warning: static expression fails predicate check on I1 warning: expression is no longer considered static 37.XI2 : constant I1 := 3; -- OK 38.XI3 : constant := XI1; -- ERROR | non-static expression used in number declaration XI1 is not a static constant (RM 4.9(5)) 39.XI4 : constant := XI2; -- OK 40. end; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-07-18 Robert Dewar de...@adacore.com * sem_util.adb (Check_Expression_Against_Static_Predicate): Mark expression as non-static if it fails static predicate check, and issue additional warning. Index: sem_util.adb === --- sem_util.adb(revision 212804) +++ sem_util.adb(working copy) @@ -1718,6 +1718,17 @@ else Error_Msg_NE (??static expression fails predicate check on , Expr, Typ); + +-- We now reset the static expression indication on the expression +-- since it is no longer static if it fails a predicate test. We +-- do not do this if the predicate was officially dynamic, since +-- dynamic predicates don't affect legality in this manner. + +if not Has_Dynamic_Predicate_Aspect (Typ) then + Error_Msg_N + (\??expression is no longer considered static, Expr); + Set_Is_Static_Expression (Expr, False); +end if; end if; end if; end Check_Expression_Against_Static_Predicate;
Re: [GSoC] generation of Gimple code from isl_ast_node_user
Can you explain why all functions would need to be rewritten? I proposed
this function as an easier way to NULL initialize the vector and did not
expect any rewrite to be necessary.
If there is no such thing, please just add a comment that your loop NULL
initializes the vector. We can later improve this.
Sorry, I, probably, mixed something up. This function was used in the
attached patch without rewriting of other functions.
--
Cheers, Roman Gareev.
2014-07-12 Roman Gareev gareevro...@gmail.com
gcc/
* graphite-isl-ast-to-gimple.c:
Add inclusion of gimple-ssa.h, tree-into-ssa.h.
(ivs_params_clear):
(build_iv_mapping): New function.
(translate_isl_ast_node_user): Likewise.
(translate_isl_ast): Add calling of translate_isl_ast_node_user.
gcc/testsuite/gcc.dg/graphite/
* isl-ast-gen-single-loop-1.c: New testcase.
* isl-ast-gen-single-loop-2.c: New testcase.
* isl-ast-gen-single-loop-3.c: New testcase.
Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 212807)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -51,6 +51,8 @@
#include sese.h
#include tree-ssa-loop-manip.h
#include tree-scalar-evolution.h
+#include gimple-ssa.h
+#include tree-into-ssa.h
#include map
#ifdef HAVE_cloog
@@ -541,6 +543,70 @@
return last_e;
}
+/* Inserts in iv_map a tuple (OLD_LOOP-num, NEW_NAME) for the induction
+ variables of the loops around GBB in SESE.
+
+ FIXME: Instead of using a vectree that maps each loop id to a possible
+ chrec, we could consider using a mapint, tree that maps loop ids to the
+ corresponding tree expressions. */
+
+static void
+build_iv_mapping (vectree iv_map, gimple_bb_p gbb,
+ __isl_keep isl_ast_expr *user_expr, ivs_params ip,
+ sese region)
+{
+ gcc_assert (isl_ast_expr_get_type (user_expr) == isl_ast_expr_op
+ isl_ast_expr_get_op_type (user_expr) == isl_ast_op_call);
+ int i;
+ isl_ast_expr *arg_expr;
+ for (i = 1; i isl_ast_expr_get_op_n_arg (user_expr); i++)
+{
+ arg_expr = isl_ast_expr_get_op_arg (user_expr, i);
+ tree type = *graphite_expression_size_type;
+ tree t = gcc_expression_from_isl_expression (type, arg_expr, ip);
+ loop_p old_loop = gbb_loop_at_index (gbb, region, i - 1);
+ iv_map[old_loop-num] = t;
+}
+
+}
+
+/* Translates an isl_ast_node_user to Gimple. */
+
+static edge
+translate_isl_ast_node_user (__isl_keep isl_ast_node *node,
+edge next_e, ivs_params ip)
+{
+ gcc_assert (isl_ast_node_get_type (node) == isl_ast_node_user);
+ isl_ast_expr *user_expr = isl_ast_node_user_get_expr (node);
+ isl_ast_expr *name_expr = isl_ast_expr_get_op_arg (user_expr, 0);
+ gcc_assert (isl_ast_expr_get_type (name_expr) == isl_ast_expr_id);
+ isl_id *name_id = isl_ast_expr_get_id (name_expr);
+ poly_bb_p pbb = (poly_bb_p) isl_id_get_user (name_id);
+ gcc_assert (pbb);
+ gimple_bb_p gbb = PBB_BLACK_BOX (pbb);
+ vectree iv_map;
+ isl_ast_expr_free (name_expr);
+ isl_id_free (name_id);
+
+ gcc_assert (GBB_BB (gbb) != ENTRY_BLOCK_PTR_FOR_FN (cfun)
+ The entry block should not even appear within a scop);
+
+ loop_p loop = gbb_loop (gbb);
+ iv_map.create (loop-num + 1);
+ iv_map.safe_grow_cleared (loop-num + 1);
+
+ build_iv_mapping (iv_map, gbb, user_expr, ip, SCOP_REGION (pbb-scop));
+ isl_ast_expr_free (user_expr);
+ next_e = copy_bb_and_scalar_dependences (GBB_BB (gbb),
+ SCOP_REGION (pbb-scop), next_e,
+ iv_map,
+ graphite_regenerate_error);
+ iv_map.release ();
+ mark_virtual_operands_for_renaming (cfun);
+ update_ssa (TODO_update_ssa);
+ return next_e;
+}
+
/* Translates an ISL AST node NODE to GCC representation in the
context of a SESE. */
@@ -561,7 +627,7 @@
return next_e;
case isl_ast_node_user:
- return next_e;
+ return translate_isl_ast_node_user (node, next_e, ip);
case isl_ast_node_block:
return next_e;
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-1.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-1.c (working copy)
@@ -0,0 +1,28 @@
+/* { dg-do run } */
+/* { dg-options -O2 -fgraphite-identity -fgraphite-code-generator=isl } */
+
+int n = 25;
+
+int
+foo ()
+{
+ int i, res;
+
+ for (i = n, res = 0; i 50; i++)
+ res += i;
+
+ return res;
+}
+
+extern void abort ();
+
+int
+main (void)
+{
+ int res = foo ();
+
+ if (res != 1225)
+abort ();
+
+ return 0;
+}
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-single-loop-2.c
Re: [GSoC] generation of Gimple code from isl_ast_node_user
One last question: On 18/07/2014 12:28, Roman Gareev wrote: + iv_map.create (loop-num + 1); + iv_map.safe_grow_cleared (loop-num + 1); One of these two seems redundant. Cheers, Tobias
Re: [GSoC] generation of Gimple loops with empty bodies
I suggest you use the largest available integer mode via mode = mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0); type = build_nonstandard_integer_type (GET_MODE_PRECISION (mode), [01]); Thank you for the suggestion! Roman, can you give this a shot? Maybe, we could use the following code: static int max_mode_int_precision = GET_MODE_PRECISION (mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0)); static int graphite_expression_type_precision = 128 = max_mode_int_precision ? 128 : max_mode_int_precision; This allows us to change the size during debugging and avoid using unacceptable mode size. Tobias, what do you think about this? -- Cheers, Roman Gareev 2014-07-08 Roman Gareev gareevro...@gmail.com gcc/ * graphite-isl-ast-to-gimple.c: Add using of build_nonstandard_integer_type instead of int128_integer_type_node. Index: gcc/graphite-isl-ast-to-gimple.c === --- gcc/graphite-isl-ast-to-gimple.c(revision 212804) +++ gcc/graphite-isl-ast-to-gimple.c(working copy) @@ -62,10 +62,13 @@ static bool graphite_regenerate_error; -/* We always use signed 128, until isl is able to give information about -types */ +/* We always use signed 128, until it is not accpeted or isl is able to give + information about types. */ -static tree *graphite_expression_size_type = int128_integer_type_node; +static int max_mode_int_precision = + GET_MODE_PRECISION (mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0)); +static int graphite_expression_type_precision = 128 = max_mode_int_precision ? + 128 : max_mode_int_precision; /* Converts a GMP constant VAL to a tree and returns it. */ @@ -494,7 +497,8 @@ tree cond_expr; edge exit_edge; - *type = *graphite_expression_size_type; + *type = +build_nonstandard_integer_type (graphite_expression_type_precision, 0); isl_ast_expr *for_init = isl_ast_node_for_get_init (node_for); *lb = gcc_expression_from_isl_expression (*type, for_init, ip); isl_ast_expr *upper_bound = get_upper_bound (node_for);
[PATCH, nds32] Committed: Have function name start in column one to follow GNU coding standards.
Hi,
According to the GNU coding standards, the function name should start
in column one. Fixed it as obvious, committed as Rev.212809.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 212808)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2014-07-18 Chung-Ju Wu jasonw...@gmail.com
+
+ * config/nds32/nds32.c (nds32_can_eliminate): Follow the
+ GNU coding standards.
+ (nds32_register_move_cost): Likewise.
+ (nds32_memory_move_cost): Likewise.
+ (nds32_address_cost): Likewise.
+
2014-07-18 Jan-Benedict Glaw jbg...@lug-owl.de
* config/mmix/mmix.c (mmix_intval): Drop unused automatic variable.
Index: gcc/config/nds32/nds32.c
===
--- gcc/config/nds32/nds32.c(revision 212808)
+++ gcc/config/nds32/nds32.c(working copy)
@@ -18,8 +18,8 @@
along with GCC; see the file COPYING3. If not see
http://www.gnu.org/licenses/. */
+/* */
-
#include config.h
#include system.h
#include coretypes.h
@@ -1195,7 +1195,8 @@
/* -- Eliminating Frame Pointer and Arg Pointer. */
-static bool nds32_can_eliminate (const int from_reg, const int to_reg)
+static bool
+nds32_can_eliminate (const int from_reg, const int to_reg)
{
if (from_reg == ARG_POINTER_REGNUM to_reg == STACK_POINTER_REGNUM)
return true;
@@ -1795,9 +1796,10 @@
^L
/* Describing Relative Costs of Operations. */
-static int nds32_register_move_cost (enum machine_mode mode ATTRIBUTE_UNUSED,
- reg_class_t from,
- reg_class_t to)
+static int
+nds32_register_move_cost (enum machine_mode mode ATTRIBUTE_UNUSED,
+ reg_class_t from,
+ reg_class_t to)
{
if (from == HIGH_REGS || to == HIGH_REGS)
return 6;
@@ -1805,9 +1807,10 @@
return 2;
}
-static int nds32_memory_move_cost (enum machine_mode mode ATTRIBUTE_UNUSED,
- reg_class_t rclass ATTRIBUTE_UNUSED,
- bool in ATTRIBUTE_UNUSED)
+static int
+nds32_memory_move_cost (enum machine_mode mode ATTRIBUTE_UNUSED,
+reg_class_t rclass ATTRIBUTE_UNUSED,
+bool in ATTRIBUTE_UNUSED)
{
return 8;
}
@@ -1827,10 +1830,11 @@
return nds32_rtx_costs_impl (x, code, outer_code, opno, total, speed);
}
-static int nds32_address_cost (rtx address,
- enum machine_mode mode,
- addr_space_t as,
- bool speed)
+static int
+nds32_address_cost (rtx address,
+enum machine_mode mode,
+addr_space_t as,
+bool speed)
{
return nds32_address_cost_impl (address, mode, as, speed);
}
Best regards,
jasonwucj
Re: [GSoC] generation of Gimple loops with empty bodies
On 18/07/2014 12:34, Roman Gareev wrote: I suggest you use the largest available integer mode via mode = mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0); type = build_nonstandard_integer_type (GET_MODE_PRECISION (mode), [01]); Thank you for the suggestion! Roman, can you give this a shot? Maybe, we could use the following code: static int max_mode_int_precision = GET_MODE_PRECISION (mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0)); static int graphite_expression_type_precision = 128 = max_mode_int_precision ? 128 : max_mode_int_precision; This allows us to change the size during debugging and avoid using unacceptable mode size. Tobias, what do you think about this? One comment is unclear. Otherwise it is good. If my proposed comment is OK, please update, commit and close the bug report. Tobias -- Cheers, Roman Gareev ChangeLog_entry.txt 2014-07-08 Roman Gareevgareevro...@gmail.com gcc/ * graphite-isl-ast-to-gimple.c: Add using of build_nonstandard_integer_type instead of int128_integer_type_node. patch.txt Index: gcc/graphite-isl-ast-to-gimple.c === --- gcc/graphite-isl-ast-to-gimple.c(revision 212804) +++ gcc/graphite-isl-ast-to-gimple.c(working copy) @@ -62,10 +62,13 @@ static bool graphite_regenerate_error; -/* We always use signed 128, until isl is able to give information about -types */ +/* We always use signed 128, until it is not accpeted or isl is able to give + information about types. */ This is not understandable. What about; /* We always try to use signed 128 bit types, but fall back to smaller types in case a platform does not provide types of this sizes. In the future we should use isl to derive the optimal type for each subexpression. */ -static tree *graphite_expression_size_type = int128_integer_type_node; +static int max_mode_int_precision = + GET_MODE_PRECISION (mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0)); +static int graphite_expression_type_precision = 128 = max_mode_int_precision ? + 128 : max_mode_int_precision; /* Converts a GMP constant VAL to a tree and returns it. */ @@ -494,7 +497,8 @@ tree cond_expr; edge exit_edge; - *type = *graphite_expression_size_type; + *type = +build_nonstandard_integer_type (graphite_expression_type_precision, 0); isl_ast_expr *for_init = isl_ast_node_for_get_init (node_for); *lb = gcc_expression_from_isl_expression (*type, for_init, ip); isl_ast_expr *upper_bound = get_upper_bound (node_for);
Re: [committed] Use __kernel_cmpxchg for __sync_lock_release
John David Anglin writes:
Because the atomic sync functions in config/pa/linux-atomic.c are not
lock free, we need to use
__kernel_cmpxchg for the __sync_lock_release. This was found in
glibc's pthread_spin_unlock
implementation.
Tested on hppa-unknown-linux-gnu. Committed to trunk.
It seems to me that ARM's linux-atomic.c has the same problem.
CC:ing some ARM folks for clarification.
/Mikael
Dave
--
John David Anglindave.ang...@bell.net
--
2014-07-17 John David Anglin dang...@gcc.gnu.org
* config/pa/linux-atomic.c (__sync_lock_release_4): New.
(SYNC_LOCK_RELEASE): Update to use __kernel_cmpxchg for release.
Don't use SYNC_LOCK_RELEASE for int type.
Index: config/pa/linux-atomic.c
===
--- config/pa/linux-atomic.c (revision 210671)
+++ config/pa/linux-atomic.c (working copy)
@@ -293,13 +293,34 @@
SUBWORD_TEST_AND_SET (unsigned short, 2)
SUBWORD_TEST_AND_SET (unsigned char, 1)
+void HIDDEN
+__sync_lock_release_4 (int *ptr)
+{
+ int failure, oldval;
+
+ do {
+oldval = *ptr;
+failure = __kernel_cmpxchg (oldval, 0, ptr);
+ } while (failure != 0);
+}
+
#define SYNC_LOCK_RELEASE(TYPE, WIDTH)
\
void HIDDEN
\
__sync_lock_release_##WIDTH (TYPE *ptr) \
{ \
-*ptr = 0;
\
+int failure;\
+unsigned int oldval, newval, shift, mask;
\
+int *wordptr = (int *) ((unsigned long) ptr ~3);
\
+\
+shift = (((unsigned long) ptr 3) 3) ^ INVERT_MASK_##WIDTH; \
+mask = MASK_##WIDTH shift; \
+\
+do {\
+ oldval = *wordptr;\
+ newval = oldval ~mask;
\
+ failure = __kernel_cmpxchg (oldval, newval, wordptr); \
+} while (failure != 0); \
}
-SYNC_LOCK_RELEASE (int, 4)
SYNC_LOCK_RELEASE (short, 2)
SYNC_LOCK_RELEASE (char, 1)
--
[PATCH] Add support for KernelAddressSanitizer
Hi all,
This tiny patch adds support for KernelASan. KASan brings Asan error
detection capabilities to Linux kernel
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).
KASan works similar to normal userspace ASan but disables some options
which are not yet supported by kernel (notably inline instrumentation,
stack/global protection and UAR). We would prefer to hide all necessary
tweaks under a user-friendly flag (-fsanitize=kernel-address) instead of
forcing them directly in kernel's CFLAGS.
Kernel patches are currently under review in LKML
(https://lkml.org/lkml/2014/7/9/990).
Bootstrapped and regtested on x64.
Ok to commit?
-Y
gcc/
2014-07-18 Yury Gribov y.gri...@samsung.com
* doc/invoke.texi (-fsanitize=kernel-address): Describe new option.
* flag-types.h (SANITIZE_KERNEL_ADDRESS): New enum.
* opts.c (common_handle_option): Handle new option.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a83f6c6..70f9c2b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5376,6 +5376,11 @@ more details. The run-time behavior can be influenced using the
@url{https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags} for
a list of supported options.
+@item -fsanitize=kernel-address
+@opindex fsanitize=kernel-address
+Enable AddressSanitizer for Linux kernel.
+See @uref{http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel} for more details.
+
@item -fsanitize=thread
@opindex fsanitize=thread
Enable ThreadSanitizer, a fast data race detector.
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 2849455..04038f6 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -231,6 +231,7 @@ enum sanitize_code {
SANITIZE_FLOAT_DIVIDE = 1 12,
SANITIZE_FLOAT_CAST = 1 13,
SANITIZE_BOUNDS = 1 14,
+ SANITIZE_KERNEL_ADDRESS = 1 15,
SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
| SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
| SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
diff --git a/gcc/opts.c b/gcc/opts.c
index 419a074..42fef36 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1475,6 +1475,7 @@ common_handle_option (struct gcc_options *opts,
{ float-cast-overflow, SANITIZE_FLOAT_CAST,
sizeof float-cast-overflow - 1 },
{ bounds, SANITIZE_BOUNDS, sizeof bounds - 1 },
+ { kernel-address, SANITIZE_KERNEL_ADDRESS, sizeof kernel-address - 1 },
{ NULL, 0, 0 }
};
const char *comma;
@@ -1520,6 +1521,25 @@ common_handle_option (struct gcc_options *opts,
the null pointer checks. */
if (flag_sanitize SANITIZE_NULL)
opts-x_flag_delete_null_pointer_checks = 0;
+
+ /* Kernel ASan implies normal ASan but does not yet support
+ all features. */
+ if (flag_sanitize SANITIZE_KERNEL_ADDRESS)
+ {
+ flag_sanitize |= SANITIZE_ADDRESS;
+ maybe_set_param_value (PARAM_ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD, 0,
+ opts-x_param_values,
+ opts_set-x_param_values);
+ maybe_set_param_value (PARAM_ASAN_GLOBALS, 0,
+ opts-x_param_values,
+ opts_set-x_param_values);
+ maybe_set_param_value (PARAM_ASAN_STACK, 0,
+ opts-x_param_values,
+ opts_set-x_param_values);
+ maybe_set_param_value (PARAM_ASAN_USE_AFTER_RETURN, 0,
+ opts-x_param_values,
+ opts_set-x_param_values);
+ }
break;
}
Re: [PATCH] Add support for KernelAddressSanitizer
On Fri, Jul 18, 2014 at 3:40 PM, Yury Gribov y.gri...@samsung.com wrote: Hi all, This tiny patch adds support for KernelASan. KASan brings Asan error detection capabilities to Linux kernel (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel). KASan works similar to normal userspace ASan but disables some options which are not yet supported by kernel (notably inline instrumentation, stack/global protection and UAR). We would prefer to hide all necessary tweaks under a user-friendly flag (-fsanitize=kernel-address) instead of forcing them directly in kernel's CFLAGS. Kernel patches are currently under review in LKML (https://lkml.org/lkml/2014/7/9/990). Bootstrapped and regtested on x64. Ok to commit? Thanks for doing this, Yury. The patch looks good to me FWIW, but please wait for Jakub or somebody else with stronger gcc-fu.
Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)
On Fri, 2014-07-18 03:10:09 -0400, Hans-Peter Nilsson h...@bitrange.com wrote: On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: As a leftover of r210931, an unused variable resulted in: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o mmix.o -MT mmix.o -MMD -MP -MF ./.deps/mmix.TPo ../../../gcc/gcc/config/mmix/mmix.c ../../../gcc/gcc/config/mmix/mmix.c: In function ?int64_t mmix_intval(const_rtx)?: ../../../gcc/gcc/config/mmix/mmix.c:2694:12: error: unused variable ?retval? [-Werror=unused-variable] uint64_t retval; ^ cc1plus: all warnings being treated as errors Weird that I haven't seen this with a host g++ = 4.7 (4.7.2-2); I've certainly built post-r210931 (post-2014-05-26) for example r212486, but obviously so, thanks. I see the warning in my logs but -Werror wasn't isn't used and I didn't pay attention. Did something change more recently re: building with -Werror? This was a build using GCC's ./contrib/config-list.mk to do the build. It passes --enable-werror-always to top-level `configure', this is where the -Werror comes from. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: 17:45 @Eimann Hrm, das E90 hat keinen Lebenszeit Call-Time Counter mehr the second : 17:46 @jbglaw Eimann: Wofür braucht man das? 17:46 @jbglaw Eimann: Für mich ist an 'nem Handy wichtig, daß ich mein Gegeüber hören kann. Und daß mein Gegenüber mich versteht... 17:47 @KrisK jbglaw: was du meinst ist wodka. 17:47 @KrisK jbglaw: es klingelt und man hört stimmen signature.asc Description: Digital signature
Re: [PATCH] Add support for KernelAddressSanitizer
On Fri, Jul 18, 2014 at 03:40:15PM +0400, Yury Gribov wrote: This tiny patch adds support for KernelASan. KASan brings Asan error detection capabilities to Linux kernel (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel). KASan works similar to normal userspace ASan but disables some options which are not yet supported by kernel (notably inline instrumentation, stack/global protection and UAR). We would prefer to hide all necessary tweaks under a user-friendly flag (-fsanitize=kernel-address) instead of forcing them directly in kernel's CFLAGS. Kernel patches are currently under review in LKML (https://lkml.org/lkml/2014/7/9/990). I thought KAsan used different entry points (__kasan_* etc.), has that changed? Also, oring in SANITIZER_ADDRESS means you add -lasan to link flags, I'd guess that for -fsanitize=kernel-address you don't want to add any libraries at link time? Do you error out on -fsanitize=thread -fsanitize=kernel-address ? Perhaps -fsanitize=kernel-address -fsanitize=address should be invalid too? Jakub
Re: [PATCH] Add support for KernelAddressSanitizer
On Fri, Jul 18, 2014 at 4:26 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jul 18, 2014 at 03:40:15PM +0400, Yury Gribov wrote: This tiny patch adds support for KernelASan. KASan brings Asan error detection capabilities to Linux kernel (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel). KASan works similar to normal userspace ASan but disables some options which are not yet supported by kernel (notably inline instrumentation, stack/global protection and UAR). We would prefer to hide all necessary tweaks under a user-friendly flag (-fsanitize=kernel-address) instead of forcing them directly in kernel's CFLAGS. Kernel patches are currently under review in LKML (https://lkml.org/lkml/2014/7/9/990). I thought KAsan used different entry points (__kasan_* etc.), has that changed? Yes, we've switched to __asan_. Also, oring in SANITIZER_ADDRESS means you add -lasan to link flags, I'd guess that for -fsanitize=kernel-address you don't want to add any libraries at link time? I suspect that we don't pass -fsanitize=kernel-address during linking in kernel today. But I agree that it's better to disable any processing during linking for now. Later we may want to do something special during linking if -fsanitize=kernel-address is supplied. Do you error out on -fsanitize=thread -fsanitize=kernel-address ? Perhaps -fsanitize=kernel-address -fsanitize=address should be invalid too? Yes, all these combinations are invalid.
Re: [PATCH] Add support for KernelAddressSanitizer
Also, oring in SANITIZER_ADDRESS means you add -lasan to link flags, I'd guess that for -fsanitize=kernel-address you don't want to add any libraries at link time? I suspect that we don't pass -fsanitize=kernel-address during linking in kernel today. But I agree that it's better to disable any processing during linking for now. Later we may want to do something special during linking if -fsanitize=kernel-address is supplied. AFAIK kernel is linked directly with ld so this may not be a big issue. Do you error out on -fsanitize=thread -fsanitize=kernel-address ? Perhaps -fsanitize=kernel-address -fsanitize=address should be invalid too? Yes, all these combinations are invalid. Ok, I'll add these. -Y
Re: [GSoC] generation of Gimple code from isl_ast_node_user
One of these two seems redundant.
I get the following error without “iv_map.create (loop-num + 1);”:
/home/roman/sec_trunk/gcc/gcc/vec.h:1184:39: error: ‘iv_map’ may be
used uninitialized in this function [-Werror=maybe-uninitialized] {
return m_vec ? m_vec-length () : 0; }
Can you explain why all functions would need to be rewritten? I proposed this
function as an easier way to NULL initialize the vector and did not expect any
rewrite to be necessary.
When I'm trying to pass iv_map to vec_safe_grow_cleared I get the
following error:
/home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:596:47:
note: mismatched types ‘vecT, A, vl_embed*’ and ‘vectree_node*’
vec_safe_grow_cleared (iv_map, loop-num + 1);
In case of passing of iv_map*, I get the following error:
/home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:596:47:
error: no matching function for call to
‘vec_safe_grow_cleared(vectree_node**, int)’
vec_safe_grow_cleared (iv_map, loop-num + 1);
/home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:596:47:
note: candidate is:
In file included from /home/roman/sec_trunk/gcc/gcc/tree-core.h:27:0,
from /home/roman/sec_trunk/gcc/gcc/tree.h:23,
from
/home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:39:
/home/roman/sec_trunk/gcc/gcc/vec.h:627:1: note: templateclass T,
class A void vec_safe_grow_cleared(vecT, A, vl_embed*, unsigned
int)
vec_safe_grow_cleared (vecT, A, vl_embed *v, unsigned len CXX_MEM_STAT_INFO)
/home/roman/sec_trunk/gcc/gcc/vec.h:627:1: note: template argument
deduction/substitution failed:
/home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:596:47:
note: mismatched types ‘vl_embed’ and ‘vl_ptr’
vec_safe_grow_cleared (iv_map, loop-num + 1);
/home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:596:47:
note: ‘vectree_node*’ is not derived from ‘vecT, A, vl_embed’
If we use vecT, A, vl_embed as a type for iv_map, we'll have to
rewrite declarations of the following functions, which are working
with vectree_node*:copy_bb_and_scalar_dependences,
graphite_copy_stmts_from_block, rename_uses, chrec_apply_map. We'll
also have to rewrite declarations of iv_map in
graphite-clast-to-gimple.c in this case.
Please correct me, if I am wrong.
--
Cheers, Roman Gareev.
[PATCH] Move Asan instrumentation to sanopt pass
Hi all,
Attached patch delays generation of Asan memory checking code
until sanopt pass. This is a first step towards global static analysis
of Asan instrumentation which would allow to
* remove redundant instrumentations
* aggregate adjacent Asan checks
* move invariant checks from loops
The patch also changes the logic behind
asan-instrumentation-with-call-threshold
parameter to more closely match LLVM.
The patch splits build_check_stmt routine to two parts. The first one
(called from asan0/asan passes) inserts calls to internal functions
ASAN_LOAD and ASAN_STORE. The second expands those to inline checks
(in asan_expand_check_ifn).
Here are some obvious disadvantages:
* passing additional info via hidden parameter of
ASAN_{LOAD,STORE} is ugly but I'm not sure how to do this better
* delayed expansion runs after all optimization passes
so inlined Asan checks will not get a chance to be
CSE-ed, etc.; this may probably be solved by moving sanopt earlier
in the pipeline. BTW I haven't experienced notable slowdowns in my
experiments.
* passing program pointers to ASAN_{LOAD,STORE} may damage alias analysis
because all pointers will now escape; I probably could
provide fnspec with (EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE) or
even EAF_UNUSED for these functions but this does not seem
to be supported in current middle-end.
The patch was bootstrapped, regtested and asan-bootstrapped on x64.
Is this ok for trunk?
-Yury
commit ec53fb00ab4a762c3c4cefa886f6cd9ee549de8d
Author: Yury Gribov y.gri...@samsung.com
Date: Thu Jul 17 09:45:26 2014 +0400
Move inlining of Asan memory checks to sanopt pass.
Change asan-instrumentation-with-call-threshold to more closely match LLVM.
gcc/
2014-07-17 Yury Gribov y.gri...@samsung.com
* asan.c (asan_check_flags): New enum.
(build_check_stmt_with_calls): Removed function.
(build_check_stmt): Split inlining logic to
asan_expand_check_ifn.
(instrument_derefs): Rename parameter.
(instrument_mem_region_access): Rename parameter.
(instrument_strlen_call): Likewise.
(asan_expand_check_ifn): New function.
(asan_instrument): Remove old code.
(pass_sanopt::execute): Change handling of
asan-instrumentation-with-call-threshold.
* doc/invoke.texi (asan-instrumentation-with-call-threshold):
Update description.
* gimple_iterator.h (gsi_start_bb): Fix uninitialized
warnings.
* internal-fn.c (expand_ASAN_LOAD): New function.
(expand_ASAN_STORE): Likewise.
* internal-fn.def (ASAN_LOAD): New internal function.
(ASAN_STORE): Likewise.
* params.def (PARAM_ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD):
Update description.
(PARAM_ASAN_USE_AFTER_RETURN): Likewise.
gcc/testsuite/
2014-07-17 Yury Gribov y.gri...@samsung.com
* c-c++-common/asan/inc.c: Update test.
* c-c++-common/asan/instrument-with-calls-2.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-1.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-2.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-3.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-4.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-5.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-6.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-7.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-8.c: Likewise.
* c-c++-common/asan/no-redundant-instrumentation-9.c: Likewise.
diff --git a/gcc/asan.c b/gcc/asan.c
index 0d78634..7fe079d 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -243,18 +243,15 @@ static GTY(()) tree shadow_ptr_types[2];
/* Decl for __asan_option_detect_stack_use_after_return. */
static GTY(()) tree asan_detect_stack_use_after_return;
-/* Number of instrumentations in current function so far. */
-
-static int asan_num_accesses;
-
-/* Check whether we should replace inline instrumentation with calls. */
-
-static inline bool
-use_calls_p ()
+/* Various flags for Asan builtins. */
+enum asan_check_flags
{
- return ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD INT_MAX
- asan_num_accesses = ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD;
-}
+ ASAN_CHECK_NON_ZERO_LEN = 1 0,
+ ASAN_CHECK_SCALAR_ACCESS = 1 1,
+ ASAN_CHECK_START_INSTRUMENTED = 1 2,
+ ASAN_CHECK_END_INSTRUMENTED = 1 3,
+ ASAN_CHECK_LAST
+};
/* Hashtable support for memory references used by gimple
statements. */
@@ -1553,55 +1550,6 @@ maybe_create_ssa_name (location_t loc, tree base, gimple_stmt_iterator *iter,
return gimple_assign_lhs (g);
}
-/* Instrument the memory access instruction using callbacks.
- Parameters are similar to BUILD_CHECK_STMT. */
-
-static void
-build_check_stmt_with_calls (location_t loc, tree base, tree len,
- HOST_WIDE_INT size_in_bytes, gimple_stmt_iterator *iter,
- bool before_p, bool is_store, bool is_scalar_access)
-{
-
Re: [PATCH] Add support for KernelAddressSanitizer
On Fri, Jul 18, 2014 at 05:19:39PM +0400, Dmitry Vyukov wrote:
On Fri, Jul 18, 2014 at 4:26 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jul 18, 2014 at 03:40:15PM +0400, Yury Gribov wrote:
This tiny patch adds support for KernelASan. KASan brings Asan error
detection capabilities to Linux kernel
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).
KASan works similar to normal userspace ASan but disables some options
which
are not yet supported by kernel (notably inline instrumentation,
stack/global protection and UAR). We would prefer to hide all necessary
tweaks under a user-friendly flag (-fsanitize=kernel-address) instead of
forcing them directly in kernel's CFLAGS.
Kernel patches are currently under review in LKML
(https://lkml.org/lkml/2014/7/9/990).
I thought KAsan used different entry points (__kasan_* etc.), has that
changed?
Yes, we've switched to __asan_.
Ok.
Also, oring in SANITIZER_ADDRESS means you add -lasan to link flags, I'd
guess that for -fsanitize=kernel-address you don't want to add any libraries
at link time?
I suspect that we don't pass -fsanitize=kernel-address during linking
in kernel today. But I agree that it's better to disable any
processing during linking for now. Later we may want to do something
special during linking if -fsanitize=kernel-address is supplied.
Do you error out on -fsanitize=thread -fsanitize=kernel-address ?
Perhaps -fsanitize=kernel-address -fsanitize=address should be invalid too?
Yes, all these combinations are invalid.
But you don't error out on that.
If we want to diagnose the last, IMHO we can't have just SANITIZE_ADDRESS
and SANITIZE_KERNEL_ADDRESS flags, but instead should have
SANITIZE_ADDRESS (used when we don't care about kernel vs. user asan
differences), SANITIZE_USER_ADDRESS and SANITIZE_KERNEL_ADDRESS bits.
address would set SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS,
kernel-address SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS.
Then in sanitize_spec_function supposedly for address check
SANITIZE_USER_ADDRESS bit, for kernel-address added there
SANITIZE_KERNEL_ADDRESS, add all the incompatibility diagnostics for the new
invalid combinations. Plus, toplev.c has e.g.:
/* Address Sanitizer needs porting to each target architecture. */
if ((flag_sanitize SANITIZE_ADDRESS)
(targetm.asan_shadow_offset == NULL
|| !FRAME_GROWS_DOWNWARD))
{
warning (0, -fsanitize=address not supported for this target);
flag_sanitize = ~SANITIZE_ADDRESS;
}
Now, is the same really the case for SANITIZE_KERNEL_ADDRESS?
I guess we still inline the shadow memory accesses to poison/unpoison
stack in function prologue/epilogue, right? In that case without
asan_shadow_offset we can't do anything. If it was a function call instead
it would be portable to all architectures.
Jakub
[patch] fix AVX512F tests
Hello, I've fixed AVX512F tests. These tests failed on Android because they were using values.h, which seem to be obsolete and is not present in Android sysroot. Here is the quote from values.h /* This interface is obsolete. New programs should use limits.h and/or float.h instead of values.h. */ So now tests run with Android compiler. Please have a look. Is it ok for trunk? 2014-07-18 Petr Murzin petr.mur...@intel.com * gcc.target/i386/avx512f-vfixupimmpd-2.c: Add float.h instead of values.h, change MAXDOUBLE for DBL_MAX. * gcc.target/i386/avx512f-vfixupimmsd-2.c: Ditto. * gcc.target/i386/avx512f-vfixupimmps-2.c: Add float.h instead of values.h, change MAXFLOAT for FLT_MAX. * gcc.target/i386/avx512f-vfixupimmss-2.c: Ditto. * gcc.target/i386/avx512f-vpermi2d-2.c: Exclude values.h. * gcc.target/i386/avx512f-vpermi2pd-2.c: Ditto. * gcc.target/i386/avx512f-vpermi2ps-2.c: Ditto. * gcc.target/i386/avx512f-vpermi2q-2.c: Ditto. * gcc.target/i386/avx512f-vpermt2d-2.c: Ditto. * gcc.target/i386/avx512f-vpermt2pd-2.c: Ditto. * gcc.target/i386/avx512f-vpermt2ps-2.c: Ditto. * gcc.target/i386/avx512f-vpermt2q-2.c: Ditto. patch Description: Binary data
Re: [PATCH] Add support for KernelAddressSanitizer
Then in sanitize_spec_function supposedly for address check SANITIZE_USER_ADDRESS bit, for kernel-address added there SANITIZE_KERNEL_ADDRESS, add all the incompatibility diagnostics for the new invalid combinations. Ok. Plus, toplev.c has e.g.: ... Now, is the same really the case for SANITIZE_KERNEL_ADDRESS? This is a good point, KASan does not use asan_shadow_offset so this check is redundant. I guess we still inline the shadow memory accesses to poison/unpoison stack in function prologue/epilogue, right? In that case without asan_shadow_offset we can't do anything. If it was a function call instead it would be portable to all architectures. Stack is not supported by current KASan. My local version indeed does replace asan_shadow_offset with function call. -Y
Re: [patch] fix AVX512F tests
On Fri, Jul 18, 2014 at 4:05 PM, Petr Murzin petrmurz...@gmail.com wrote: I've fixed AVX512F tests. These tests failed on Android because they were using values.h, which seem to be obsolete and is not present in Android sysroot. Here is the quote from values.h /* This interface is obsolete. New programs should use limits.h and/or float.h instead of values.h. */ So now tests run with Android compiler. Please have a look. Is it ok for trunk? 2014-07-18 Petr Murzin petr.mur...@intel.com * gcc.target/i386/avx512f-vfixupimmpd-2.c: Add float.h instead of Include float.h ... values.h, change MAXDOUBLE for DBL_MAX. * gcc.target/i386/avx512f-vfixupimmsd-2.c: Ditto. * gcc.target/i386/avx512f-vfixupimmps-2.c: Add float.h instead of Include float.h ... values.h, change MAXFLOAT for FLT_MAX. * gcc.target/i386/avx512f-vfixupimmss-2.c: Ditto. * gcc.target/i386/avx512f-vpermi2d-2.c: Exclude values.h. Do not include ... * gcc.target/i386/avx512f-vpermi2pd-2.c: Ditto. * gcc.target/i386/avx512f-vpermi2ps-2.c: Ditto. * gcc.target/i386/avx512f-vpermi2q-2.c: Ditto. * gcc.target/i386/avx512f-vpermt2d-2.c: Ditto. * gcc.target/i386/avx512f-vpermt2pd-2.c: Ditto. * gcc.target/i386/avx512f-vpermt2ps-2.c: Ditto. * gcc.target/i386/avx512f-vpermt2q-2.c: Ditto. OK with these changes. Thanks, Uros.
Re: [committed] Use __kernel_cmpxchg for __sync_lock_release
On 7/18/2014 7:28 AM, Mikael Pettersson wrote: John David Anglin writes: Because the atomic sync functions in config/pa/linux-atomic.c are not lock free, we need to use __kernel_cmpxchg for the __sync_lock_release. This was found in glibc's pthread_spin_unlock implementation. Tested on hppa-unknown-linux-gnu. Committed to trunk. It seems to me that ARM's linux-atomic.c has the same problem. CC:ing some ARM folks for clarification. It might. However, the issue is very subtle and may be parisc specific. Carlos O'Donnel and I had a long discussion about it and couldn't come to a clear understanding as to how the race occurs. However, without changing the release used in glibc for the pthread_spin_unlock operation, the spin lock tests in the kyotocabinet testsuite would consistently fail. Dave -- John David Anglindave.ang...@bell.net
Re: [PATCH] Move Asan instrumentation to sanopt pass
On Fri, Jul 18, 2014 at 05:36:30PM +0400, Yury Gribov wrote:
The patch was bootstrapped, regtested and asan-bootstrapped on x64.
Thanks for working on this.
For formatting, can you please just replace 8 spaces with tabs
in the ^+ lines in the patch?
sed '/^+/s//\t/g' or so.
Can you avoid using // comments in code that uses /* */ comments?
If all the ifns have a bitmask argument, one question is if we really
want ASAN_LOAD vs. ASAN_STORE, instead of a single ASAN_CHECK that
would actually have ASAN_CHECK_IS_STORE as one of the flags.
pass_sanopt::execute (function *fun)
{
basic_block bb;
+ gimple_stmt_iterator gsi;
+ int asan_num_accesses = 0;
IMHO you should guard this with if (flag_sanitize SANITIZE_ADDRESS),
to avoid the cost for -fsanitize=undefined, thread etc.
+ FOR_EACH_BB_FN (bb, fun)
+for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (gsi))
+ {
+ gimple stmt = gsi_stmt (gsi);
+ if (is_gimple_call (stmt) gimple_call_internal_p (stmt))
+ {
+ enum internal_fn ifn = gimple_call_internal_fn (stmt);
+ switch (ifn)
+ {
+ case IFN_ASAN_LOAD:
+ case IFN_ASAN_STORE:
+ {
+ ++asan_num_accesses;
+ break;
+ }
+ default:
+ break;
+ }
+ }
+}
+
+ bool use_calls = ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD INT_MAX
+ asan_num_accesses = ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD;
+
--- a/gcc/gimple-iterator.h
+++ b/gcc/gimple-iterator.h
@@ -116,6 +116,7 @@ gsi_start_bb (basic_block bb)
gimple_seq *seq;
seq = bb_seq_addr (bb);
+ gcc_assert (seq);
i.ptr = gimple_seq_first (*seq);
i.seq = seq;
i.bb = bb;
Uh. Can you please explain this? That sounds weird.
Jakub
Re: [PATCH, rs6000, 4.9] Fix many powerpc*-linux ASAN test suite failures
This is okay with me if it is okay with the Release Managers.
Thanks, David
On Thu, Jul 17, 2014 at 10:56 AM, Peter Bergner berg...@vnet.ibm.com wrote:
With a recent mainline libsanitizer merge from upstream, we're now seeing a
lot of mainline ASAN test suite failures with the following error:
==26426==ASan runtime does not come first in initial library list; you should
either link runtime to your application or manually preload it with
LD_PRELOAD.
FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
This is caused by mainline libasan detecting that libasan is not linked
first and erroring out. With the 4.8 and 4.9, we may just silently run
into problems. The root cause is that powerpc*-linux does not define
LIBASAN_EARLY_SPEC which is defined in gnu-user.h. It looks like all
*-linux architectures include gnu-user.h except for powerpc*-linux.
As discussed, for the 4.8 and 4.9 backports of the original patch, we
will just copy those defines to the rs6000 header files and not try and
include gnu-user.h itself.
This is slightly different than the 4.8 patch, since the
STATIC_LIB[AT]SAN_LIBS
macro was deleted in 4.9.
This passed bootstrap and regtesting on powerpc64-linux with no regressions.
Ok for 4.9?
Peter
* config/rs6000/sysv4.h:
Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h (revision 212695)
+++ gcc/config/rs6000/sysv4.h (working copy)
@@ -949,3 +949,19 @@ ncrtn.o%s
#define TARGET_USES_SYSV4_OPT 1
#undef DBX_REGISTER_NUMBER
+
+/* Link -lasan early on the command line. For -static-libasan, don't link
+ it for -shared link, the executable should be compiled with
-static-libasan
+ in that case, and for executable link link with --{,no-}whole-archive
around
+ it to force everything into the executable. And similarly for -ltsan. */
+#if defined(HAVE_LD_STATIC_DYNAMIC)
+#undef LIBASAN_EARLY_SPEC
+#define LIBASAN_EARLY_SPEC %{!shared:libasan_preinit%O%s} \
+ %{static-libasan:%{!shared: \
+ LD_STATIC_OPTION --whole-archive -lasan --no-whole-archive \
+ LD_DYNAMIC_OPTION }}%{!static-libasan:-lasan}
+#undef LIBTSAN_EARLY_SPEC
+#define LIBTSAN_EARLY_SPEC %{static-libtsan:%{!shared: \
+ LD_STATIC_OPTION --whole-archive -ltsan --no-whole-archive \
+ LD_DYNAMIC_OPTION }}%{!static-libtsan:-ltsan}
+#endif
[PATCH, DOC] -O3 enables -ftree-loop-distribute-patterns
Hi,
when reading the gcc/opts.c sources, I noticed that the docs don't
mention -ftree-loop-distribute-patterns along the other switches enabled
with -O3.
This documentation was missing since this option's introduction in SVN
r162822 and should be backported to the 4.6, 4.7, 4.8 and 4.9 branches
(if still alive).
2014-07-18 Horst Schirmeier ho...@schirmeier.com
* doc/invoke.texi: -O3 enables -ftree-loop-distribute-patterns.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b5e8d98..b0a8eb8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7030,6 +7030,7 @@ Optimize yet more. @option{-O3} turns on all
optimizations specified
by @option{-O2} and also turns on the @option{-finline-functions},
@option{-funswitch-loops}, @option{-fpredictive-commoning},
@option{-fgcse-after-reload}, @option{-ftree-loop-vectorize},
+@option{-ftree-loop-distribute-patterns},
@option{-ftree-slp-vectorize}, @option{-fvect-cost-model},
@option{-ftree-partial-pre} and @option{-fipa-cp-clone} options.
--
PGP-Key 0xD40E0E7A
Re: [PATCH, rs6000, 4.8] Fix many powerpc*-linux ASAN test suite failures
This patch is okay with me if it is okay with the Release Managers.
Thanks, David
On Thu, Jul 17, 2014 at 10:54 AM, Peter Bergner berg...@vnet.ibm.com wrote:
With a recent mainline libsanitizer merge from upstream, we're now seeing a
lot of mainline ASAN test suite failures with the following error:
==26426==ASan runtime does not come first in initial library list; you should
either link runtime to your application or manually preload it with
LD_PRELOAD.
FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
This is caused by mainline libasan detecting that libasan is not linked
first and erroring out. With the 4.8 and 4.9, we may just silently run
into problems. The root cause is that powerpc*-linux does not define
LIBASAN_EARLY_SPEC which is defined in gnu-user.h. It looks like all
*-linux architectures include gnu-user.h except for powerpc*-linux.
As discussed, for the 4.8 and 4.9 backports of the original patch, we
will just copy those defines to the rs6000 header files and not try and
include gnu-user.h itself.
This passed bootstrap and regtesting on powerpc64-linux with no regressions.
Ok for 4.8?
Peter
* config/rs6000/sysv4.h:
Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h (revision 212695)
+++ gcc/config/rs6000/sysv4.h (working copy)
@@ -949,3 +949,27 @@ ncrtn.o%s
#define TARGET_USES_SYSV4_OPT 1
#undef DBX_REGISTER_NUMBER
+
+/* Link -lasan early on the command line. For -static-libasan, don't link
+ it for -shared link, the executable should be compiled with
-static-libasan
+ in that case, and for executable link link with --{,no-}whole-archive
around
+ it to force everything into the executable. And similarly for -ltsan. */
+#if defined(HAVE_LD_STATIC_DYNAMIC)
+#undef LIBASAN_EARLY_SPEC
+#define LIBASAN_EARLY_SPEC %{!shared:libasan_preinit%O%s} \
+ %{static-libasan:%{!shared: \
+ LD_STATIC_OPTION --whole-archive -lasan --no-whole-archive \
+ LD_DYNAMIC_OPTION }}%{!static-libasan:-lasan}
+#undef LIBTSAN_EARLY_SPEC
+#define LIBTSAN_EARLY_SPEC %{static-libtsan:%{!shared: \
+ LD_STATIC_OPTION --whole-archive -ltsan --no-whole-archive \
+ LD_DYNAMIC_OPTION }}%{!static-libtsan:-ltsan}
+#endif
+
+/* Additional libraries needed by -static-libasan. */
+#undef STATIC_LIBASAN_LIBS
+#define STATIC_LIBASAN_LIBS -ldl -lpthread
+
+/* Additional libraries needed by -static-libtsan. */
+#undef STATIC_LIBTSAN_LIBS
+#define STATIC_LIBTSAN_LIBS -ldl -lpthread
Re: [PATCH, rs6000, 4.8] Fix many powerpc*-linux ASAN test suite failures
On Fri, Jul 18, 2014 at 11:40:31AM -0400, David Edelsohn wrote: This patch is okay with me if it is okay with the Release Managers. Ok. Jakub
Re: [PATCH, rs6000, 4.9] Fix many powerpc*-linux ASAN test suite failures
On Fri, Jul 18, 2014 at 11:38:22AM -0400, David Edelsohn wrote: This is okay with me if it is okay with the Release Managers. Ok. Jakub
[patch] libstdc++/61835 fix invalid character escape in docstring
Committed to trunk. commit dacf2aec1b84828e92a06431d725a6e80413b21d Author: redi redi@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Jul 18 15:56:00 2014 + PR libstdc++/61835 * python/libstdcxx/v6/printers.py (TemplateTypePrinter): Use raw string. (SingleObjContainerPrinter): Check if type printers are in use. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212822 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py index af41f1f..625396b 100644 --- a/libstdc++-v3/python/libstdcxx/v6/printers.py +++ b/libstdc++-v3/python/libstdcxx/v6/printers.py @@ -845,6 +845,9 @@ class SingleObjContainerPrinter(object): def _recognize(self, type): Return TYPE as a string after applying type printers +global _use_type_printing +if not _use_type_printing: +return str(type) return gdb.types.apply_type_recognizers(gdb.types.get_type_recognizers(), type) or str(type) @@ -1043,7 +1046,7 @@ class Printer(object): libstdcxx_printer = None class TemplateTypePrinter(object): -A type printer for class templates. +rA type printer for class templates. Recognizes type names that match a regular expression. Replaces them with a formatted string which can use replacement field
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
This patch is okay with me if okay with the Release Managers.
Thanks, David
On Wed, Jul 16, 2014 at 8:41 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Hello,
this is the variant intended for the 4.8/4.9 branches of the patch:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html
As discussed, it does *not* actually change ABI, but only warn when
encountering a situation where the ABI will change in a future GCC.
(Avoiding the specific term GCC 4.10 here since I'm not certain
whether the next GCC release will in fact be called that ...)
Tested on powerpc64-linux and powerpc64le-linux; also verified using
the ABI compat suite (against an unpatched GCC) that this patch does
not change the ABI.
OK for 4.8/4.9 once the mainline patch is in?
Bye,
Ulrich
gcc/ChangeLog:
* config/rs6000/rs6000-protos.h (rs6000_special_adjust_field_align_p):
Add prototype.
* config/rs6000/rs6000.c (rs6000_special_adjust_field_align_p): New
function. Issue -Wpsabi warning if future GCC releases will use
different field alignment rules for this type.
* config/rs6000/sysv4.h (ADJUST_FIELD_ALIGN): Call it.
* config/rs6000/linux64.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/freebsd64.h (ADJUST_FIELD_ALIGN): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/ppc64-abi-warn-3.c: New test.
* gcc.c-torture/execute/20050316-1.x: Add -Wno-psabi.
* gcc.c-torture/execute/20050604-1.x: Add -Wno-psabi.
* gcc.c-torture/execute/20050316-3.x: New file. Add -Wno-psabi.
* gcc.c-torture/execute/pr23135.x: Likewise.
Index: gcc-4_9-branch/gcc/config/rs6000/rs6000-protos.h
===
--- gcc-4_9-branch.orig/gcc/config/rs6000/rs6000-protos.h
+++ gcc-4_9-branch/gcc/config/rs6000/rs6000-protos.h
@@ -155,6 +155,7 @@ extern void rs6000_split_logical (rtx []
#ifdef TREE_CODE
extern unsigned int rs6000_data_alignment (tree, unsigned int, enum
data_align);
+extern bool rs6000_special_adjust_field_align_p (tree, unsigned int);
extern unsigned int rs6000_special_round_type_align (tree, unsigned int,
unsigned int);
extern unsigned int darwin_rs6000_special_round_type_align (tree, unsigned
int,
Index: gcc-4_9-branch/gcc/config/rs6000/rs6000.c
===
--- gcc-4_9-branch.orig/gcc/config/rs6000/rs6000.c
+++ gcc-4_9-branch/gcc/config/rs6000/rs6000.c
@@ -5871,6 +5871,34 @@ rs6000_data_alignment (tree type, unsign
return align;
}
+/* Previous GCC releases forced all vector types to have 16-byte alignment.
*/
+
+bool
+rs6000_special_adjust_field_align_p (tree field, unsigned int computed)
+{
+ if (TARGET_ALTIVEC TREE_CODE (TREE_TYPE (field)) == VECTOR_TYPE)
+{
+ if (computed != 128)
+ {
+ static bool warned;
+ if (!warned warn_psabi)
+ {
+ warned = true;
+ inform (input_location,
+ the layout of aggregates containing vectors with
+ %d-byte alignment will change in a future GCC
release,
+ computed / BITS_PER_UNIT);
+ }
+ }
+ /* GCC 4.8/4.9 Note: To avoid any ABI change on a release branch, we
+keep the special treatment of vector types, but warn if there will
+be differences in future GCC releases. */
+ return true;
+}
+
+ return false;
+}
+
/* AIX increases natural record alignment to doubleword if the first
field is an FP double while the FP fields remain word aligned. */
Index: gcc-4_9-branch/gcc/config/rs6000/sysv4.h
===
--- gcc-4_9-branch.orig/gcc/config/rs6000/sysv4.h
+++ gcc-4_9-branch/gcc/config/rs6000/sysv4.h
@@ -292,7 +292,7 @@ do {
\
/* An expression for the alignment of a structure field FIELD if the
alignment computed in the usual way is COMPUTED. */
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED)
\
- ((TARGET_ALTIVEC TREE_CODE (TREE_TYPE (FIELD)) == VECTOR_TYPE)
\
+ (rs6000_special_adjust_field_align_p ((FIELD), (COMPUTED))
\
? 128 : COMPUTED)
#undef BIGGEST_FIELD_ALIGNMENT
Index: gcc-4_9-branch/gcc/config/rs6000/linux64.h
===
--- gcc-4_9-branch.orig/gcc/config/rs6000/linux64.h
+++ gcc-4_9-branch/gcc/config/rs6000/linux64.h
@@ -246,7 +246,7 @@ extern int dot_symbols;
/* PowerPC64 Linux word-aligns FP doubles when -malign-power is given. */
#undef ADJUST_FIELD_ALIGN
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \
- ((TARGET_ALTIVEC TREE_CODE (TREE_TYPE (FIELD)) == VECTOR_TYPE)\
+
[PATCH, i386]: Fix PR 61794, unrecognizable insn from avx512 extract instruction
Hello!
2014-07-18 Uros Bizjak ubiz...@gmail.com
PR target/61794
* config/i386/sse.md (avx512f_vextractshuffletype32x4_1_maskm):
Fix instruction constraint.
(mask_codeforavx512f_vextractshuffletype32x4_1mask_name): Ditto.
testsuite/ChangeLog:
2014-07-18 Uros Bizjak ubiz...@gmail.com
PR target/61794
* gcc.target/i386/pr61794.c: New test.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} and
committed to mainline and 4.9 branch.
Uros.
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 212817)
+++ config/i386/sse.md (working copy)
@@ -5892,9 +5892,10 @@
(match_operand 5 const_0_to_15_operand)]))
(match_operand:ssequartermode 6 memory_operand 0)
(match_operand:QI 7 register_operand Yk)))]
- TARGET_AVX512F (INTVAL (operands[2]) = INTVAL (operands[3]) - 1)
- (INTVAL (operands[3]) = INTVAL (operands[4]) - 1)
- (INTVAL (operands[4]) = INTVAL (operands[5]) - 1)
+ TARGET_AVX512F
+(INTVAL (operands[2]) == (INTVAL (operands[3]) - 1)
+INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
+INTVAL (operands[4]) == (INTVAL (operands[5]) - 1))
{
operands[2] = GEN_INT ((INTVAL (operands[2])) 2);
return vextractshuffletype32x4\t{%2, %1, %0%{%7%}|%0%{%7%}, %1, %2};
@@ -5914,9 +5915,10 @@
(match_operand 3 const_0_to_15_operand)
(match_operand 4 const_0_to_15_operand)
(match_operand 5 const_0_to_15_operand)])))]
- TARGET_AVX512F (INTVAL (operands[2]) = INTVAL (operands[3]) - 1)
- (INTVAL (operands[3]) = INTVAL (operands[4]) - 1)
- (INTVAL (operands[4]) = INTVAL (operands[5]) - 1)
+ TARGET_AVX512F
+(INTVAL (operands[2]) == (INTVAL (operands[3]) - 1)
+INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
+INTVAL (operands[4]) == (INTVAL (operands[5]) - 1))
{
operands[2] = GEN_INT ((INTVAL (operands[2])) 2);
return vextractshuffletype32x4\t{%2, %1,
%0mask_operand6|%0mask_operand6, %1, %2};
Index: testsuite/gcc.target/i386/pr61794.c
===
--- testsuite/gcc.target/i386/pr61794.c (revision 0)
+++ testsuite/gcc.target/i386/pr61794.c (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -mavx512f } */
+
+#include x86intrin.h
+
+__m512i zmm;
+__m128i xmm;
+
+void test (void)
+{
+ xmm = _mm512_extracti32x4_epi32 (zmm, 0);
+}
Re: [PATCH, rs6000, 4.8/4.9] Fix aggregate alignment ABI issue
On Wed, Jul 16, 2014 at 8:39 PM, Ulrich Weigand uweig...@de.ibm.com wrote: Hello, this is the variant intended for the 4.8/4.9 branches of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00995.html As discussed, it does *not* actually change ABI, but only warn when encountering a situation where the ABI will change in a future GCC. (Avoiding the specific term GCC 4.10 here since I'm not certain whether the next GCC release will in fact be called that ...) Tested on powerpc64-linux and powerpc64le-linux; also verified using the ABI compat suite (against an unpatched GCC) that this patch does not change the ABI. OK for 4.8/4.9 once the mainline patch is in? Bye, Ulrich gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_function_arg_boundary): Issue -Wpsabi note when encountering a type where future GCC releases will apply different alignment requirements. gcc/testsuite/ChangeLog: * gcc.target/powerpc/ppc64-abi-warn-2.c: New test. This patch is okay if it is okay with the Release Managers. Thanks, David
Re: [PATCH, rs6000, 4.8/4.9] Fix ELFv2 homogeneous float aggregate ABI bug
On Wed, Jul 16, 2014 at 8:37 PM, Ulrich Weigand uweig...@de.ibm.com wrote: Hello, this is the variant intended for the 4.8/4.9 branches of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00994.html As discussed, it does *not* actually change ABI, but only warn when encountering a situation where the ABI will change in a future GCC. (Avoiding the specific term GCC 4.10 here since I'm not certain whether the next GCC release will in fact be called that ...) Tested on powerpc64-linux and powerpc64le-linux; also verified using the ABI compat suite (against an unpatched GCC) that this patch does not change the ABI. OK for 4.8/4.9 once the mainline patch is in? Bye, Ulrich gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_function_arg): If a float argument does not fit fully into floating-point registers, and there is still space in the register parameter area, issue -Wpsabi note that the ABI will change in a future GCC release. gcc/testsuite/ChangeLog: * gcc.target/powerpc/ppc64-abi-warn-1.c: New test. This patch is okay if okay with the Release Managers. Thanks, David
Re: [PATCH, rs6000, v2] Fix aggregate alignment ABI issue
On Mon, Jul 14, 2014 at 2:54 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Hello,
this patch updates the prior version:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00634.html
to add a -Wpsabi note as discussed.
Note that the warning triggers whenever type is encountered whose alignment
*requirement* changes due to this patch. In some cases, this does not
actually
change the ABI of a given function call since the argument happened to be
already aligned for the higher requirement as well.
Except for a few cases in the ABI compat suite (as expected), this note
triggers in three test cases:
In the ELFv1 ABI only:
gcc.c-torture/compile/20040709-1.c:7:1: note: the ABI of passing aggregates
with 16-byte alignment has changed in GCC 4.10
union foo {
long double ld;
} bar;
Note that this union counts as homogeneous aggregate according to
the ELFv2 ABI, so it is treated the same before and after this patch
(i.e. aligned to 8 bytes).
In the ELFv1 ABI, however, this union does *not* count as a single-element
float struct (because its mode is TImode, not TFmode, since common code
does the latter only for single-element structs, not unions). Therefore,
this union used to be 8-byte aligned but is now 16-byte aligned.
In both the ELFv1 and ELFv2 ABIs:
gcc.dg/pr32293.c:46:1: note: the ABI of passing aggregates with 16-byte
alignment has changed in GCC 4.10
typedef
__attribute__ ((aligned(16)))
struct {
UINT64 w[2];
} UINT128;
g++.dg/abi/param2.C:9:1: note: the ABI of passing aggregates with 16-byte
alignment has changed in GCC 4.10
struct S { union {} a; } __attribute__((aligned));
In both cases, we have a struct of size 16 bytes (in the second case due to
alignment padding) and alignment requirement 16 bytes, which is recognized
as TImode and not BLKmode by common code, and thus used to be 8-byte aligned
but is now 16-byte aligned.
The tests still PASS since the dg-test infrastructure prunes all informational
messages from the GCC output.
Based on the discussion after the previous patch submission, the patch
leaves the Darwin ABI unchanged.
Tested on powerpc64-linux and powerpc64le-linux.
OK for mainline?
Bye,
Ulrich
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_function_arg_boundary): In the AIX
and ELFv2 ABI, do not use the mode == BLKmode check to test for
aggregate types. Instead, *all* aggregate types, except for single-
element or homogeneous float/vector aggregates, are quadword-aligned
if required by their type alignment. Issue -Wpsabi note when a type
is now treated differently than before.
gcc/testsuite/ChangLog:
* gcc.target/powerpc/ppc64-abi-warn-2.c: New test.
This patch is okay.
Thanks, David
Re: [PATCH, rs6000, 4.8/4.9] Fix aggregate alignment ABI issue
On Fri, Jul 18, 2014 at 12:11:56PM -0400, David Edelsohn wrote: gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_function_arg_boundary): Issue -Wpsabi note when encountering a type where future GCC releases will apply different alignment requirements. gcc/testsuite/ChangeLog: * gcc.target/powerpc/ppc64-abi-warn-2.c: New test. This patch is okay if it is okay with the Release Managers. Ok. Jakub
Re: [PATCH, rs6000, 4.8/4.9] Fix ELFv2 homogeneous float aggregate ABI bug
On Fri, Jul 18, 2014 at 12:13:09PM -0400, David Edelsohn wrote: gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_function_arg): If a float argument does not fit fully into floating-point registers, and there is still space in the register parameter area, issue -Wpsabi note that the ABI will change in a future GCC release. gcc/testsuite/ChangeLog: * gcc.target/powerpc/ppc64-abi-warn-1.c: New test. This patch is okay if okay with the Release Managers. Ok. Jakub
Re: [PATCH, rs6000, v2] Fix ELFv2 homogeneous float aggregate ABI bug
On Mon, Jul 14, 2014 at 2:52 PM, Ulrich Weigand uweig...@de.ibm.com wrote: Hello, this patch updates the prior version: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00632.html to add a -Wpsabi note as discussed. (We may need to change the GCC 4.10 string if the next release turns out to get a different name ...) In a testsuite run, this note triggers only in those two ABI compat suite test cases mentioned in the previous patch email (only on ELFv2, of course). Tested on powerpc64le-linux. OK for mainline? Bye, Ulrich gcc/testsuite/ChangLog: * config/rs6000/rs6000.c (rs6000_function_arg): If a float argument does not fit fully into floating-point registers, and there is still space in the register parameter area, use GPRs to pass those parts of the argument. Issue -Wpsabi note if any parameter is now treated differently than before. (rs6000_arg_partial_bytes): Update. gcc/testsuite/ChangLog: * gcc.target/powerpc/ppc64-abi-warn-2.c: New test. This patch is okay. Thanks, David
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
On Fri, Jul 18, 2014 at 12:01:21PM -0400, David Edelsohn wrote: This patch is okay with me if okay with the Release Managers. Ok. Jakub
Re: [patch 0/2] gcc re-arch status
On 07/17/2014 07:10 AM, Richard Biener wrote: Just to mention - the regimplification removal and a gimple-building facility is provided on the match-and-simplify branch worked on by me and Prathamesh (a GSoC student this year). I'll present about this during the Cauldron with the title Unifying GENERIC and GIMPLE folding with a pattern description. It falls under the folding umbrella as the important feature passes get from using fold + re-gimplification is expression simplification. perfect. Another related topic (well, not so much maybe as you are focused on removing references to trees from GIMPLE) is (language dependent) debug information for types and decls, esp. in the context of LTO (but also in the context of information we need to retain during the GIMPLE/RTL phases). Recently on IRC we concluded that the simplest approach to start tackling this is to emit (aka run the dwarf2out machinery) debug info for decls and types early (at least before LTO streaming). To reference DIEs created there we annotate decls which we can later complete (function and variable definitions) with hidden symbols we need to remember for those entities (and stream them via LTO). At LTO LTRANS time we build a DWARF translation unit importing referenced units with decls/types from compile-time and complete functions and variables, refering to the compile-time decl/type dwarf via those symbols. And we of course link this early debug info at link time. A similar scheme could be used even without LTO (emit the early debug info into the asm early and later emit another blob ofA debug info refering to it). Volunteers to prototype that welcome ;) (hah) It would basically allow us to build a completely separate representation for types (the real types, not 'tree') and decls on GIMPLE (yeah, really no trees!), and Frontends like GFortran could emit this GIMPLE directly, skipping GENERIC, if it knows to emit debug info itself. This is worth discussing... Now that I have a mechanism which we can use to remove all trees from GIMPLE, I'd like to discuss what trees are actually useful to remove... if any. The only trees that I think may make sense to replace at this point are potentially types and decls. All the LTO work you guys have been doing means you are the defacto experts on decls and types in the backend... Would it buy us anything to have a custom type and/or decl kind that exists from gimpification time on in the backend rather than the current tree? I believe LTO creates its own symbol table and type mapping/system but I don't know much beyond that. Would it make sense if we could replicate those throughout the backend and have those become the types and/or decls? or some subset of the LTO stuff? We could potentially haul a bunch of that stuff out of LTO and make it an integral part of the backend.. and maybe we could integrate that debug info work you are talking about into it. I dont plan to present very much on sunday in the BOF.I'd like to discuss what useful direction we can actually go. Andrew
Re: [PATCH] Move Asan instrumentation to sanopt pass
For formatting, can you please just replace 8 spaces with tabs in the ^+ lines in the patch? Sorry, I thought I cleared all these out but looks like I indeed missed some whites. I should probably take some time and finally setup my editor to do this. Can you avoid using // comments in code that uses /* */ comments? Thanks, this TODO should have been included in the patch to begin with. If all the ifns have a bitmask argument, one question is if we really want ASAN_LOAD vs. ASAN_STORE, instead of a single ASAN_CHECK that would actually have ASAN_CHECK_IS_STORE as one of the flags. True. + gcc_assert (seq); Uh. Can you please explain this? That sounds weird. Sure, this caused maybe-uninitialized warnings with iterator during bootstrap. It turned out that *bb_seq_addr (bb) in gsi_start (bb) returned something like bb.flags GIMPLE ? bb.il.gimple.seq : NULL and when GCC saw *NULL it rushed to generated uninitialized read. This assert silences compiler. -Y
Re: [RFC, rs6000, v2] Fix alignment of non-Altivec vector struct fields
On Tue, Jul 15, 2014 at 11:23 AM, Ulrich Weigand uweig...@de.ibm.com wrote: Richard Biener wrote: On Mon, Jul 14, 2014 at 8:55 PM, Ulrich Weigand uweig...@de.ibm.com wrote: Hello, this is an attempt to update the prior patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00635.html to add a -Wpsabi note as discussed. However, this is causing a bit of difficulties. First of all, the warning triggers in a larger number of tests -- which was probably to be expected since a number of tests in the suite explicitly work on GCC vectors defined using various vector_size values, and any size except 16 will result in the warning. Note that the warning gets issued at the site of definition of the structure type -- it does not have to be used in a function call. More problematic is that this new warning causes four tests to fail (it's actually 38 new FAILS since each of the tests fails in multiple optimization levels): FAIL: gcc.c-torture/execute/20050316-1.c compilation gcc.c-torture/execute/20050316-1.c:53:9: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 4.10 FAIL: gcc.c-torture/execute/20050316-3.c compilation gcc.c-torture/execute/20050316-3.c:26:9: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 4.10 FAIL: gcc.c-torture/execute/20050604-1.c compilation gcc.c-torture/execute/20050604-1.c:12:1: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 4.10 FAIL: gcc.c-torture/execute/pr23135.c compilation gcc.c-torture/execute/pr23135.c:20:1: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 4.10 Unfortunately, while most of the tests in the suite use the dg-test framework which ignores note messages, the gcc.c-torture/execute tests still use the old torture test framework, which does *not*. (Also, in the old framework you cannot even add dg-... commands to ignore those messages for a certain test, or add a -Wno-psabi option.) Therefore, I'm not proposing to commit this patch as-is, but would like to ask for feedback on how to best proceed with this. One option might be to move the affected tests to the dg-test framework. Or else we might decide we don't actually need a warning for this change, since it only affects GCC synthetic vectors, where we might not have made strict ABI guarantees anyway ... Thoughts? cat gcc/testsuite/gcc.c-torture/execute/pr38151.x set additional_flags -Wno-psabi return 0 Ah, I had forgotten about the .x files. Thanks! Here's a version with the -Wno-psabi added to the .x files. This now passes regression testing. OK for mainline? Bye, Ulrich gcc/ChangeLog: * config/rs6000/rs6000-protos.h (rs6000_special_adjust_field_align_p): Add prototype. * config/rs6000/rs6000.c (rs6000_special_adjust_field_align_p): New function. * config/rs6000/sysv4.h (ADJUST_FIELD_ALIGN): Call it. * config/rs6000/linux64.h (ADJUST_FIELD_ALIGN): Likewise. * config/rs6000/freebsd64.h (ADJUST_FIELD_ALIGN): Likewise. gcc/testsuite/ChangeLog: * gcc.target/powerpc/ppc64-abi-warn-3.c: New test. * gcc.c-torture/execute/20050316-1.x: Add -Wno-psabi. * gcc.c-torture/execute/20050604-1.x: Add -Wno-psabi. * gcc.c-torture/execute/20050316-3.x: New file. Add -Wno-psabi. * gcc.c-torture/execute/pr23135.x: Likewise. This patch is okay. Thanks, David
Re: [PATCH] Move Asan instrumentation to sanopt pass
On Fri, Jul 18, 2014 at 9:23 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jul 18, 2014 at 08:42:35PM +0400, Yuri Gribov wrote: Uh. Can you please explain this? That sounds weird. Sure, this caused maybe-uninitialized warnings with iterator during bootstrap. It turned out that *bb_seq_addr (bb) in gsi_start (bb) returned something like bb.flags GIMPLE ? bb.il.gimple.seq : NULL and when GCC saw *NULL it rushed to generated uninitialized read. This assert silences compiler. Why it doesn't trip elsewhere? Do you get the maybe-uninit warning on asan.c or somewhere else without that? Just in pass_sanopt::execute in asan.c. -Y
Aw: Re: [MIPS r5900] libgcc floating point fixes
Hello Richard, Jürgen Urban juergenur...@gmx.de writes: The problem happens with the r5900 hard float configurations, e.g.: configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single --with-arch=r5900 I created the attached patch which fixes this problem for r5900 and another problem explained later. The fixed code generates the following code which should be correct (mipsr5900el-ps2-elf): 00105440 __extendsfdf2: 105440: 27bdffc8addiu sp,sp,-56 105444: 27a40028addiu a0,sp,40 105448: 27a50018addiu a1,sp,24 10544c: afbf0034sw ra,52(sp) 105450: 0c0417b5jal 105ed4 __unpack_f 105454: e7ac0028swc1$f12,40(sp) 105458: 8fa20024lw v0,36(sp) 10545c: 8fa40018lw a0,24(sp) 105460: 8fa5001clw a1,28(sp) 105464: 8fa60020lw a2,32(sp) 105468: 00021882srl v1,v0,0x2 10546c: 00021780sll v0,v0,0x1e 105470: afa20010sw v0,16(sp) 105474: 0c041789jal 105e24 __make_dp 105478: afa30014sw v1,20(sp) 10547c: 8fbf0034lw ra,52(sp) 105480: 03e8jr ra 105484: 27bd0038addiu sp,sp,56 The default targets mipsr5900el and mips64r5900el are not affected by the problem, because soft float is the default. It also seems that the same problem occurs with the following configuration: configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single I expected that this combination should work and a problem should already be detected. Can somebody confirm that the problem also occurs with default mipsel? Although that configuration is in theory supported by GCC (said like that because I don't know the state of the glibc support for single-float), I don't think anyone uses it for any target other than r5900. But you're right that this is a --with-fpu=single thing rather than an r5900 thing, so I don't think the patch is correct. It should be keyed off whether the target is single-float or double-float, which you can test by checking whether the preprocessor macro __mips_single_float is defined. Checking these macros seem to be too late, because it needs to be known at configure time and not at build time. The libgcc doesn't seem to be very flexible. It doesn't seem to provide different libraries for single and double float. The Linux kernel on the PS2 has support to switch between single and double float. For single float the hardware FPU is used and for double the FPU emulator gets activated. Currently it only checks whether the architecture is mips r5900 or not. For non r5900 the FPU emulator is activated. It seems that we also need to add something to the ELF file to specify the 32 bit or 64 bit for float. It would be good when it is not at a so complicated position as the soft vs hard float flag, because it needs to be read by the kernel when starting a ELF file. This way it would also be possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same as r5900, but the FPU is 64 bit and compliant to IEEE 754. Note that this won't really be correct for r5900 anyway because of its non-IEEE FPU. E.g. the soft-float routines will treat 0x7f80 as infinity and 0x7fff as a NaN, whereas for r5900 they should be treated as normal numbers. The code looked like it uses the configured floating point configuration for hard float, but you are right the conversion is not working in these cases. I think there is no problem with the second part of the patch which disables t-mips16 for r5900. So could you commit the last part of the patch? Best regards Jürgen
Re: FDO and source changes
Any other concern of the patch? I don't really like the name of the
parameter myself. Do you have better suggestions?
thanks,
David
On Thu, Jul 17, 2014 at 10:17 AM, Xinliang David Li davi...@google.com wrote:
I see why you do not like first_global_object_name because changing it
would cause
all functions from that unit to drop the profiles. Perhaps we can combine
function name
and compilation unit (gcov file) name?
that is a good idea -- it will also solve the LTO problem you mentioned
above.
Will update the patch.
It already does this (similarly):
chksum = coverage_checksum_string
(chksum, aux_base_name);
The static function defined in the same header will have different
'aux_base_name' depending on the including module.
David
David
Honza
chksum = coverage_checksum_string
(chksum, first_global_object_name);
chksum = coverage_checksum_string
@@ -645,7 +650,12 @@ coverage_begin_function (unsigned lineno
/* Announce function */
offset = gcov_write_tag (GCOV_TAG_FUNCTION);
- gcov_write_unsigned (current_function_funcdef_no + 1);
+ if (PARAM_VALUE (PARAM_PROFILE_FUNC_INTERNAL_ID))
+gcov_write_unsigned (current_function_funcdef_no + 1);
+ else
+gcov_write_unsigned (coverage_compute_profile_id (
+ cgraph_get_node (current_function_decl)));
+
gcov_write_unsigned (lineno_checksum);
gcov_write_unsigned (cfg_checksum);
gcov_write_string (IDENTIFIER_POINTER
@@ -682,8 +692,13 @@ coverage_end_function (unsigned lineno_c
if (!DECL_EXTERNAL (current_function_decl))
{
item = ggc_alloccoverage_data ();
-
- item-ident = current_function_funcdef_no + 1;
+
+ if (PARAM_VALUE (PARAM_PROFILE_FUNC_INTERNAL_ID))
+ item-ident = current_function_funcdef_no + 1;
+ else
+item-ident = coverage_compute_profile_id (
+ cgraph_get_node (cfun-decl));
+
item-lineno_checksum = lineno_checksum;
item-cfg_checksum = cfg_checksum;
Re: [committed] Fix MIPS p5600 scheduler
On Jul 17, 2014, at 11:47 PM, Matthew Fortune matthew.fort...@imgtec.com wrote: Thanks for fixing this. I'm afraid I managed to get confused between failures we had seen sporadically in our development work and thought they were known regressions on trunk waiting to be fixed when actually we were introducing them. I recommend contrib/compare_tests for checking for regressions. It tells you just what you need to know, and if they first line is unimportant, you’re done reading. If the first three lines are interesting, then you have at least 1 regression left. By reducing the line count of what you have to look at, it making it exceedingly hard to ignore it and exceedingly hard to accidentally put in a regression.
RE: [committed] Fix MIPS p5600 scheduler
On Jul 17, 2014, at 11:47 PM, Matthew Fortune matthew.fort...@imgtec.com wrote: Thanks for fixing this. I'm afraid I managed to get confused between failures we had seen sporadically in our development work and thought they were known regressions on trunk waiting to be fixed when actually we were introducing them. I recommend contrib/compare_tests for checking for regressions. It tells you just what you need to know, and if they first line is unimportant, you're done reading. If the first three lines are interesting, then you have at least 1 regression left. By reducing the line count of what you have to look at, it making it exceedingly hard to ignore it and exceedingly hard to accidentally put in a regression. Thanks Mike. The advice is appreciated. Matthew
RE: Re: [MIPS r5900] libgcc floating point fixes
Jürgen Urban juergenur...@gmx.de writes:
Hello Richard,
Jürgen Urban juergenur...@gmx.de writes:
The problem happens with the r5900 hard float configurations, e.g.:
configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
--with-arch=r5900
I created the attached patch which fixes this problem for r5900 and
another problem explained later.
The fixed code generates the following code which should be correct
(mipsr5900el-ps2-elf):
00105440 __extendsfdf2:
105440: 27bdffc8addiu sp,sp,-56
105444: 27a40028addiu a0,sp,40
105448: 27a50018addiu a1,sp,24
10544c: afbf0034sw ra,52(sp)
105450: 0c0417b5jal 105ed4 __unpack_f
105454: e7ac0028swc1$f12,40(sp)
105458: 8fa20024lw v0,36(sp)
10545c: 8fa40018lw a0,24(sp)
105460: 8fa5001clw a1,28(sp)
105464: 8fa60020lw a2,32(sp)
105468: 00021882srl v1,v0,0x2
10546c: 00021780sll v0,v0,0x1e
105470: afa20010sw v0,16(sp)
105474: 0c041789jal 105e24 __make_dp
105478: afa30014sw v1,20(sp)
10547c: 8fbf0034lw ra,52(sp)
105480: 03e8jr ra
105484: 27bd0038addiu sp,sp,56
The default targets mipsr5900el and mips64r5900el are not affected by
the problem, because soft float is the default.
It also seems that the same problem occurs with the following
configuration:
configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
I expected that this combination should work and a problem should
already be detected. Can somebody confirm that the problem also occurs
with default mipsel?
Although that configuration is in theory supported by GCC (said like that
because I don't know the state of the glibc support for single-float),
I don't think anyone uses it for any target other than r5900. But you're
right that this is a --with-fpu=single thing rather than an r5900 thing,
so I don't think the patch is correct. It should be keyed off whether
the target is single-float or double-float, which you can test by
checking whether the preprocessor macro __mips_single_float is defined.
Checking these macros seem to be too late, because it needs to be known at
configure time and not at build time. The libgcc doesn't seem to be very
I believe the suggestion is to add some code to configure.ac to detect a
single-float configuration like the hard-float is detected and update your
patch accordingly with no need to reference r5900 at all:
case ${host} in
mips*-*-*)
AC_CACHE_CHECK([whether the target is hard-float],
[libgcc_cv_mips_hard_float],
[AC_COMPILE_IFELSE(
[#ifndef __mips_hard_float
#error FOO
#endif],
[libgcc_cv_mips_hard_float=yes],
[libgcc_cv_mips_hard_float=no])])
esac
flexible. It doesn't seem to provide different libraries for single and
Single and double float would need to be supported as multilibs, it is generally
assumed that all libraries in the same folder follow a compatible ABI. Single
and double float ABIs are inherently incompatible.
double float. The Linux kernel on the PS2 has support to switch between
single and double float. For single float the hardware FPU is used and for
Just to confirm... The kernel has special handling for an ELF using r5900 arch
and then checks to see if it is single or double float? Is this something you
have recently developed outside of the mainline kernel or does it already exist.
I'm not aware of such logic in the MIPS kernel yet.
double the FPU emulator gets activated. Currently it only checks whether the
architecture is mips r5900 or not. For non r5900 the FPU emulator is
activated. It seems that we also need to add something to the ELF file to
specify the 32 bit or 64 bit for float. It would be good when it is not at a
so complicated position as the soft vs hard float flag, because it needs to
be read by the kernel when starting a ELF file. This way it would also be
I have a series of patches that will add this kind of support to the MIPS
ABI in the coming weeks for similar reasons but relating to O32 and double-float
ABI extensions. You will be able to directly hang off the changes once I commit
(testing is taking some time). There should be no need for extra changes to
gcc or binutils to get the information you need. Kernel changes to respond
to new ABI information are also in progress and will be easily extendable.
possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same as
r5900, but the FPU is 64 bit and compliant to IEEE 754.
Note that this won't really be correct for r5900 anyway because of its
non-IEEE FPU. E.g. the soft-float routines
[patch,gomp-4_0-branch] acc nested function support
Hi Thomas,
This patch enables acc constructs to be used inside nested functions. I
doubt nested functions will be used much in c, but some of the openacc
fortran tutorials I've seen online make use of internal subroutines in
fortran. Those internal subroutines are implemented as nested functions.
Does this look OK to commit to gomp-4_0-branch?
Thanks,
Cesar
2014-07-17 Cesar Philippidis ce...@codesourcery.com
gcc/
* gcc/gimple.h (gimple_statement_oacc_kernels,
gimple_statment_oacc_parallel): Derive from
gimple_statement_omp_taskreg instestead of
gimple_statement_omp_parallel_layout.
(is_a_helper gimple_statement_omp_taskreg *::test): Permit gimple
codes GIMPLE_OACC_PARALLEL and GIMPLE_OACC_KERNELS.
(is_a_helper const gimple_statement_omp_taskreg *::test): Likewise.
*tree-nested.c (walk_gimple_omp_for): Handle openacc kernels and
parallel constructs.
(convert_nonlocal_reference_stmt): Likewise.
(convert_local_reference_stmt): Likewise.
(convert_tramp_reference_stmt): Likewise.
(convert_gimple_call): Likewise.
gcc/testsuite/
* c-c++-common/goacc/nested-function-1.c: New test.
* gfortran.dg/goacc/cray-2.f95: New test.
* gfortran.dg/goacc/loop-4.f95: New test.
* gfortran.dg/goacc/loop-5.f95: New test.
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 68d1745..d45010f 100644
--- a/gcc/gimple.h
+++ b/gcc/gimple.h
@@ -576,22 +576,6 @@ struct GTY((tag(GSS_OMP_PARALLEL_LAYOUT)))
tree data_arg;
};
-/* GIMPLE_OACC_KERNELS */
-struct GTY((tag(GSS_OMP_PARALLEL_LAYOUT)))
- gimple_statement_oacc_kernels : public gimple_statement_omp_parallel_layout
-{
-/* No extra fields; adds invariant:
- stmt-code == GIMPLE_OACC_KERNELS. */
-};
-
-/* GIMPLE_OACC_PARALLEL */
-struct GTY((tag(GSS_OMP_PARALLEL_LAYOUT)))
- gimple_statement_oacc_parallel : public gimple_statement_omp_parallel_layout
-{
-/* No extra fields; adds invariant:
- stmt-code == GIMPLE_OACC_PARALLEL. */
-};
-
/* GIMPLE_OMP_PARALLEL or GIMPLE_TASK */
struct GTY((tag(GSS_OMP_PARALLEL_LAYOUT)))
gimple_statement_omp_taskreg : public gimple_statement_omp_parallel_layout
@@ -617,6 +601,22 @@ struct GTY((tag(GSS_OMP_PARALLEL_LAYOUT)))
stmt-code == GIMPLE_OMP_TARGET. */
};
+/* GIMPLE_OACC_KERNELS */
+struct GTY((tag(GSS_OMP_PARALLEL_LAYOUT)))
+ gimple_statement_oacc_kernels : public gimple_statement_omp_taskreg
+{
+/* No extra fields; adds invariant:
+ stmt-code == GIMPLE_OACC_KERNELS. */
+};
+
+/* GIMPLE_OACC_PARALLEL */
+struct GTY((tag(GSS_OMP_PARALLEL_LAYOUT)))
+ gimple_statement_oacc_parallel : public gimple_statement_omp_taskreg
+{
+/* No extra fields; adds invariant:
+ stmt-code == GIMPLE_OACC_PARALLEL. */
+};
+
/* GIMPLE_OMP_TASK */
struct GTY((tag(GSS_OMP_TASK)))
@@ -927,7 +927,8 @@ template
inline bool
is_a_helper gimple_statement_omp_taskreg *::test (gimple gs)
{
- return gs-code == GIMPLE_OMP_PARALLEL || gs-code == GIMPLE_OMP_TASK;
+ return gs-code == GIMPLE_OMP_PARALLEL || gs-code == GIMPLE_OMP_TASK
+|| gs-code == GIMPLE_OACC_PARALLEL || gs-code == GIMPLE_OACC_KERNELS;
}
template
@@ -1135,7 +1136,8 @@ template
inline bool
is_a_helper const gimple_statement_omp_taskreg *::test (const_gimple gs)
{
- return gs-code == GIMPLE_OMP_PARALLEL || gs-code == GIMPLE_OMP_TASK;
+ return gs-code == GIMPLE_OMP_PARALLEL || gs-code == GIMPLE_OMP_TASK
+|| gs-code == GIMPLE_OACC_PARALLEL || gs-code == GIMPLE_OACC_KERNELS;
}
template
diff --git a/gcc/testsuite/c-c++-common/goacc/nested-function-1.c b/gcc/testsuite/c-c++-common/goacc/nested-function-1.c
new file mode 100644
index 000..51a0e9f
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc/nested-function-1.c
@@ -0,0 +1,47 @@
+/* { dg-do compile } */
+
+extern void abort (void);
+
+int
+main (void)
+{
+ int j = 0, k = 6, l = 7, m = 8;
+ void simple (void)
+ {
+int i;
+#pragma acc parallel
+{
+#pragma acc loop
+ for (i = 0; i m; i+= k)
+ j = (m + i - j) * l;
+}
+ }
+ void collapse (void)
+ {
+int x, y, z;
+#pragma acc parallel
+{
+#pragma acc loop collapse (3)
+ for (x = 0; x k; x++)
+ for (y = -5; y l; y++)
+ for (z = 0; z m; z++)
+ j += x + y + z;
+}
+ }
+ void reduction (void)
+ {
+int x, y, z;
+#pragma acc parallel
+{
+#pragma acc loop collapse (3) reduction (+:j)
+ for (x = 0; x k; x++)
+ for (y = -5; y l; y++)
+ for (z = 0; z m; z++)
+ j += x + y + z;
+}
+ }
+ simple();
+ collapse();
+ reduction();
+ return 0;
+}
diff --git a/gcc/testsuite/gfortran.dg/goacc/cray-2.f95 b/gcc/testsuite/gfortran.dg/goacc/cray-2.f95
new file mode 100644
index 000..70f7cf6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/cray-2.f95
@@ -0,0 +1,55 @@
+! { dg-do compile }
+! { dg-additional-options -fcray-pointer }
+
+program test
+ call oacc1
+contains
+ subroutine oacc1
+implicit none
+integer :: i
+real :: pointee
+pointer (ptr, pointee)
+!$acc declare device_resident (pointee)
+!$acc
a new libgcov interface: __gcov_dump_all
Hi, the following patch implements a new dumper interface to allow
dumping of profile data for all instrumented shared libraries.
For good reasons, existing libgcov implements the dumping on a
per-shared library basis (i.e., gcov_exit is hidden, gcov_list is file
static). This allows each shared library's profile data to be dumped
independently with separate summary data. The downside is that there
is no interface that can be invoked to dump profile data for all
shared modules.
The attached patch does that. Ok for trunk after testing?
thanks,
David
Index: libgcc/ChangeLog
===
--- libgcc/ChangeLog(revision 212682)
+++ libgcc/ChangeLog(working copy)
@@ -1,3 +1,9 @@
+2014-07-18 Xinliang David Li davi...@google.com
+
+ * libgcov-driver.c: Force __gcov_dump to be exported
+ * libgcov-interface.c (register_dumper): New function.
+ (__gcov_dump_all): Ditto.
+
2014-07-14 Richard Biener rguent...@suse.de
* libgcov.h (struct gcov_fn_info): Make ctrs size 1.
Index: libgcc/libgcov-driver.c
===
--- libgcc/libgcov-driver.c (revision 212682)
+++ libgcc/libgcov-driver.c (working copy)
@@ -55,6 +55,13 @@ extern void set_gcov_dump_complete (void
extern void reset_gcov_dump_complete (void) ATTRIBUTE_HIDDEN;
extern int get_gcov_dump_complete (void) ATTRIBUTE_HIDDEN;
extern void set_gcov_list (struct gcov_info *) ATTRIBUTE_HIDDEN;
+
+#ifndef IN_GCOV_TOOL
+
+/* Creates strong reference to force _gcov_dump.o to be linked
+ in shared library for exported interfaces. */
+void (*__gcov_dummy_ref)(void) = __gcov_dump;
+#endif
struct gcov_fn_buffer
{
Index: libgcc/libgcov-interface.c
===
--- libgcc/libgcov-interface.c (revision 212682)
+++ libgcc/libgcov-interface.c (working copy)
@@ -115,6 +115,43 @@ __gcov_dump (void)
set_gcov_dump_complete ();
}
+typedef void (*gcov_dumper_type) (void);
+struct dumper_entry
+{
+ gcov_dumper_type dumper;
+ struct dumper_entry *next_dumper;
+};
+
+static struct dumper_entry this_dumper = {__gcov_dump, 0};
+
+/* global dumper list with default visibilty. */
+struct dumper_entry *__gcov_dumper_list;
+
+
+__attribute__((constructor))
+static void
+register_dumper (void)
+{
+ this_dumper.next_dumper = __gcov_dumper_list;
+ __gcov_dumper_list = this_dumper;
+}
+
+/* Public interface to dump profile data for all shared libraries
+ via registered dumpers from the libraries. This interface
+ has default visibility (unlike gcov_dump which has hidden
+ visbility. */
+
+void
+__gcov_dump_all (void)
+{
+ struct dumper_entry *dumper = __gcov_dumper_list;
+ while (dumper)
+ {
+ dumper-dumper ();
+ dumper = dumper-next_dumper;
+ }
+}
+
#endif /* L_gcov_dump */
Index: libgcc/libgcov.h
===
--- libgcc/libgcov.h(revision 212682)
+++ libgcc/libgcov.h(working copy)
@@ -218,8 +218,14 @@ extern void __gcov_flush (void) ATTRIBUT
/* Function to reset all counters to 0. */
extern void __gcov_reset (void);
-/* Function to enable early write of profile information so far. */
-extern void __gcov_dump (void);
+/* Function to enable early write of profile information so far.
+ __GCOV_DUMP is also used by __GCOV_DUMP_ALL. The latter
+ depends on __GCOV_DUMP to have hidden or protected visibility
+ so that each library has its own copy of the registered dumper. */
+extern void __gcov_dump (void) ATTRIBUTE_HIDDEN;
+
+/* Call __gcov_dump registered from each shared library. */
+void __gcov_dump_all (void);
/* The merge function that just sums the counters. */
extern void __gcov_merge_add (gcov_type *, unsigned) ATTRIBUTE_HIDDEN;
Go patch committed: Check for mismatch between results and uses
The Go frontend had a bug in that it would not give an error for
a, b := F()
when F returned more than two results. This patch fixes the bug. I've
proposed a test case for the master testsuite in
http://codereview.appspot.com/111360045 . Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r d56f774d848e go/expressions.cc
--- a/go/expressions.cc Fri Jul 11 16:53:55 2014 -0700
+++ b/go/expressions.cc Fri Jul 18 14:15:40 2014 -0700
@@ -9065,6 +9065,15 @@
return (*this-results_)[i];
}
+// Set the number of results expected from a call expression.
+
+void
+Call_expression::set_expected_result_count(size_t count)
+{
+ go_assert(this-expected_result_count_ == 0);
+ this-expected_result_count_ = count;
+}
+
// Return whether this is a call to the predeclared function recover.
bool
@@ -9252,6 +9261,15 @@
return;
}
+ if (this-expected_result_count_ != 0
+ this-expected_result_count_ != this-result_count())
+{
+ if (this-issue_error())
+ this-report_error(_(function result count mismatch));
+ this-set_is_error();
+ return;
+}
+
bool is_method = fntype-is_method();
if (is_method)
{
@@ -9302,6 +9320,20 @@
if (!is_method || this-args_-size() 1)
this-report_error(_(too many arguments));
}
+ else if (this-args_-size() == 1
+ this-args_-front()-call_expression() != NULL
+ this-args_-front()-call_expression()-result_count() 1)
+{
+ // This is F(G()) when G returns more than one result. If the
+ // results can be matched to parameters, it would have been
+ // lowered in do_lower. If we get here we know there is a
+ // mismatch.
+ if (this-args_-front()-call_expression()-result_count()
+ parameters-size())
+ this-report_error(_(not enough arguments));
+ else
+ this-report_error(_(too many arguments));
+}
else
{
int i = 0;
diff -r d56f774d848e go/expressions.h
--- a/go/expressions.h Fri Jul 11 16:53:55 2014 -0700
+++ b/go/expressions.h Fri Jul 18 14:15:40 2014 -0700
@@ -1606,9 +1606,9 @@
Location location)
: Expression(EXPRESSION_CALL, location),
fn_(fn), args_(args), type_(NULL), results_(NULL), call_(NULL),
- call_temp_(NULL), is_varargs_(is_varargs), are_hidden_fields_ok_(false),
- varargs_are_lowered_(false), types_are_determined_(false),
- is_deferred_(false), issued_error_(false)
+ call_temp_(NULL), expected_result_count_(0), is_varargs_(is_varargs),
+ are_hidden_fields_ok_(false), varargs_are_lowered_(false),
+ types_are_determined_(false), is_deferred_(false), issued_error_(false)
{ }
// The function to call.
@@ -1639,6 +1639,12 @@
Temporary_statement*
result(size_t i) const;
+ // Set the number of results expected from this call. This is used
+ // when the call appears in a context that expects multiple results,
+ // such as a, b = f().
+ void
+ set_expected_result_count(size_t);
+
// Return whether this is a call to the predeclared function
// recover.
bool
@@ -1767,6 +1773,9 @@
Bexpression* call_;
// A temporary variable to store this call if the function returns a tuple.
Temporary_statement* call_temp_;
+ // If not 0, the number of results expected from this call, when
+ // used in a context that expects multiple values.
+ size_t expected_result_count_;
// True if the last argument is a varargs argument (f(a...)).
bool is_varargs_;
// True if this statement may pass hidden fields in the arguments.
diff -r d56f774d848e go/parse.cc
--- a/go/parse.cc Fri Jul 11 16:53:55 2014 -0700
+++ b/go/parse.cc Fri Jul 18 14:15:40 2014 -0700
@@ -1694,6 +1694,8 @@
// the right number of values, but it might. Declare the variables,
// and then assign the results of the call to them.
+ call-set_expected_result_count(vars-size());
+
Named_object* first_var = NULL;
unsigned int index = 0;
bool any_new = false;
@@ -4101,6 +4103,7 @@
{
if (op != OPERATOR_EQ)
error_at(location, multiple results only permitted with %=%);
+ call-set_expected_result_count(lhs-size());
delete vals;
vals = new Expression_list;
for (unsigned int i = 0; i lhs-size(); ++i)
diff -r d56f774d848e go/statements.cc
--- a/go/statements.cc Fri Jul 11 16:53:55 2014 -0700
+++ b/go/statements.cc Fri Jul 18 14:15:40 2014 -0700
@@ -2664,6 +2664,7 @@
vals-front()-call_expression() != NULL)
{
Call_expression* call = vals-front()-call_expression();
+ call-set_expected_result_count(results_count);
delete vals;
vals = new Expression_list;
for (size_t i = 0; i results_count; ++i)
Re: PR 60414: Patch proposal
Hi Andre, and welcome aboard! The explanation you give is nice, your patch submission looks clean. Two things: 1. Do you have a copyright assignment on file with the FSF? See https://gcc.gnu.org/contribute.html 2. Normally, all GCC patch submissions should be accompanied by a statement saying how you tested the patch. The standard thing to do is to check that the patched sources still bootstrap and that there is no regression in the testsuite. This can be stated as “Patch bootstrapped and regtested on insert here your testing platform triplet, like x86_64-apple-darwin13”. In that particular case, it might also be nice to indicate that not only the testcase doesn’t crash the compiler any more, but to confirm that it now generates the correct code (i.e. that we don’t turn an ice-on-valid bug into a wrong-code bug!). Cheers, FX
Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)
On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: This was a build using GCC's ./contrib/config-list.mk to do the build. It passes --enable-werror-always to top-level `configure', this is where the -Werror comes from. Aha. Looks like it's of more use than theoretical pain; sounds like this should (effectively) be the default for *non-releases* when cross-compiling, with the possibility to override per-target. Agreement? Anyone against? 1/2 :) It should be per-target because there *may* be port-specific constructs warned about by buggy previous-but-not-ancient gcc-versions, where working around the warnings would cause unwanted obfuscation. (IIRC gdb does something like this.) Is that the reason it's not the default, that there are such constructs in the non-port-specific parts? But then that would have already been noticed through use of the config-list.mk, no? brgds, H-P
