Re: [Patch, Fortran, 4.7 Regression] PR 59941: ICE with polymorphic types
>> the attached patch fixes an OOP-related 4.7-only regression. Pretty >> much straightforward, for details see PR. >> >> Regtested on x86_64-unknown-linux-gnu. Ok for 4.7? >> > Yes, thanks. Thanks, Mikael. Committed as r207417. Cheers, Janus
Re: [PATCH] fix PR58602 (.gcno files not truncated at gcov_close)
Jeff, All, As you suggested, I have extended my testing around this fix to prevent race condition issues. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602#c8 All my tests passed successfully. Is it ok for trunk ? Thanks, Laurent On 10/03/13 17:01, Laurent Alfonsi wrote: Hi All, We have discovered a bug on gcno file generation registred as PR58602. When the .gcno graph file is opened for generating the coverage graph information, the mode used is w+ as this code is shared with updating tools such as libgcov. Thus, when GCC outputs .gcno files, it may leave garbage at the end of the file if the file already exists when opening it. This has been trackeddown from a kernel issue on lcov: http://sourceforge.net/p/ltp/mailman/message/31141937/ This following patch fixes the function gcov_open() such that the .gcno file is opened with truncation when gcc asks for creating a new file (mode<0). Regression test x86-64 are ok with this patch. Is it ok to commit in trunk ? Thanks Laurent
[PATCH Ping] Extend -fstack-protector-strong to cover calls with return slot
On 01/17/2014 11:26 AM, Florian Weimer wrote: On 01/08/2014 03:57 PM, Florian Weimer wrote: What about the attached version? It still does not exactly match your original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if the result is ignored and this case needs instrumentation, as you explained, so I use the function return type in the aggregate_value_p check. Testing is still under way, but looks good so far. I'm bootstrapping with BOOT_CFLAGS="-O2 -g -fstack-protector-strong" with Ada enabled, for additional coverage. Testing passed without new regressions. Is this okay for trunk? Ping? Thanks. -- Florian Weimer / Red Hat Product Security Team
[Documentation] Remove documentation of gimple_asm_clear_volatile
Hi,
Will and I were trying to understand the semantics of volatile asm
statements (we didn't succeed!) when we came across documentation
for:
gimple_asm_clear_volatile
This function looks like it is long gone, so this patch removes the
documentation.
Checked to ensure gimple.texi still builds.
OK?
Thanks,
James
---
2014-01-31 James Greenhalgh
Will Deacon
* doc/gimple.texi (gimple_asm_clear_volatile): Remove.
diff --git a/gcc/doc/gimple.texi b/gcc/doc/gimple.texi
index 714adda..54cbb92 100644
--- a/gcc/doc/gimple.texi
+++ b/gcc/doc/gimple.texi
@@ -994,10 +994,6 @@ Return true if @code{G} is an asm statement marked volatile.
Mark asm statement @code{G} as volatile.
@end deftypefn
-@deftypefn {GIMPLE function} void gimple_asm_clear_volatile (gimple g)
-Remove volatile marker from asm statement @code{G}.
-@end deftypefn
-
@node @code{GIMPLE_ASSIGN}
@subsection @code{GIMPLE_ASSIGN}
@cindex @code{GIMPLE_ASSIGN}
Re: PATCH: PR tree-optimization/60024: global-buffer-overflow in init_regs_for_mode
Hello,
On 01.02.2014 19:16, H.J. Lu wrote:
Hi,
init_regs_for_mode accesses global_regs before checking if regno is OK
for a mode, which leads to buffer overflow. This patch moves
HARD_REGNO_MODE_OK for checking global_regs. There is no functional
change. OK for trunk?
This is fine, you'd need to change tree-optimization/60024 to
rtl-optimization/60024 in the ChangeLog. Thanks for doing this.
Yours,
Andrey
Thanks.
H.J.
---
2014-02-01 H.J. Lu
PR tree-optimization/60024
* sel-sched.c (init_regs_for_mode): Check if mode is OK first.
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index ad4a0aa..7b1a183 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -1116,9 +1116,16 @@ init_regs_for_mode (enum machine_mode mode)
for (cur_reg = 0; cur_reg < FIRST_PSEUDO_REGISTER; cur_reg++)
{
- int nregs = hard_regno_nregs[cur_reg][mode];
+ int nregs;
int i;
+ /* See whether it accepts all modes that occur in
+ original insns. */
+ if (! HARD_REGNO_MODE_OK (cur_reg, mode))
+continue;
+
+ nregs = hard_regno_nregs[cur_reg][mode];
+
for (i = nregs - 1; i >= 0; --i)
if (fixed_regs[cur_reg + i]
|| global_regs[cur_reg + i]
@@ -1140,11 +1147,6 @@ init_regs_for_mode (enum machine_mode mode)
if (i >= 0)
continue;
- /* See whether it accepts all modes that occur in
- original insns. */
- if (! HARD_REGNO_MODE_OK (cur_reg, mode))
-continue;
-
if (HARD_REGNO_CALL_PART_CLOBBERED (cur_reg, mode))
SET_HARD_REG_BIT (sel_hrd.regs_for_call_clobbered[mode],
cur_reg);
Re: changing a collision resolution strategy of the symbol table of identifiers
These are statistically significant differences: increasing by 0.23% for the version 4.8.0, increasing by 0.21% for the version 4.8.1, decreasing by 0.686% for trunk. These are new row numbers: 2013-11-05 Roman Gareev : > 2013/10/31 Florian Weimer : >> On 10/20/2013 02:55 PM, Roman Gareev wrote: >>> >>> During testing of the linux kernel (3.8.8) compilation time, the >>> acquired results were the following: increasing by 0.17% for the >>> version 4.8.0, increasing by 1.12% for the version 4.8.1, decreasing >>> by 0.598% for trunk (this are average values). >> >> >> Can you share the raw numbers? Are the differences statistically >> significant? >> >> -- >> Florian Weimer / Red Hat Product Security Team > > These are the row numbers. I'll share results of checking for > statistical significance as soon as more compilations are made. -- C уважением, Гареев Роман. trunk_original Description: Binary data trunk Description: Binary data 4.8.1_original Description: Binary data 4.8.1_modified Description: Binary data 4.8.0_original Description: Binary data 4.8.0_modified Description: Binary data
Re: [gomp4] Merge trunk r206958 (was: gomp-4_0-branch)
> In r207132, I have now committed a merge of trunk r206958 (2014-01-23).
> Compared to a pristine trunk r206958 build, there is one regression:
>
> FAIL: g++.dg/gomp/declare-simd-1.C -std=c++98 (internal compiler error)
> FAIL: g++.dg/gomp/declare-simd-1.C -std=c++11 (internal compiler error)
>
> [...]/build/gcc/testsuite/g++/../../xg++
> -B[...]/build/gcc/testsuite/g++/../../
> [...]/source/gcc/testsuite/g++.dg/gomp/declare-simd-1.C
> -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
> -I[...]/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
> -I[...]/build/x86_64-unknown-linux-gnu/libstdc++-v3/include
> -I[...]/source/libstdc++-v3/libsupc++
> -I[...]/source/libstdc++-v3/include/backward
> -I[...]/source/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++98
> -fopenmp -S -o declare-simd-1.s
> [...]/source/gcc/testsuite/g++.dg/gomp/declare-simd-1.C:243:1: internal
> compiler error: in estimate_function_body_sizes, at ipa-inline-analysis.c:2403
> 0xa19664 estimate_function_body_sizes
> ../../source/gcc/ipa-inline-analysis.c:2403
> 0xa19ef1 compute_inline_parameters(cgraph_node*, bool)
> ../../source/gcc/ipa-inline-analysis.c:2797
> 0xa1a200 inline_analyze_function
> ../../source/gcc/ipa-inline-analysis.c:3790
> 0x865a10 cgraph_call_function_insertion_hooks(cgraph_node*)
> ../../source/gcc/cgraph.c:405
> 0xacc652 simd_clone_create
> ../../source/gcc/omp-low.c:11600
> 0xacc652 expand_simd_clones
> ../../source/gcc/omp-low.c:12370
> 0xacc652 ipa_omp_simd_clone
> ../../source/gcc/omp-low.c:12410
> 0xacc652 execute
> ../../source/gcc/omp-low.c:12443
>
> In my understanding, the only gomp-4_0-branch-specific change that is a
> candidate to cause this is r205214 (Ilya Tocar, commited by Kirill
> Yukhin) for "LTO" streaming. As I couldn't easily tell what's wrong (all
> changes from r205214 are still present; there were no obvious conflicts),
> could you guys please have a look at that one?
>
Hi,
Sorry for the delay, i was busy with AVX512.
I finally had time to look into this bug.
The problem in r205214 was in adding add_new_function hook in
inline_generate_summary with -O0 -fopenmp and not removing it,
before running expand_simd_clones.
I've changed inline_free_summary to always remove hooks.
Patch bellow. It bootstraps, passes make check, fixes declare-simd-1.C.
Ok for gomp4 branch?
---
gcc/ipa-inline-analysis.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c
index d4abd90..440ae79 100644
--- a/gcc/ipa-inline-analysis.c
+++ b/gcc/ipa-inline-analysis.c
@@ -4143,11 +4143,6 @@ void
inline_free_summary (void)
{
struct cgraph_node *node;
- if (!inline_edge_summary_vec.exists ())
-return;
- FOR_EACH_DEFINED_FUNCTION (node)
-if (!node->alias)
- reset_inline_summary (node);
if (function_insertion_hook_holder)
cgraph_remove_function_insertion_hook (function_insertion_hook_holder);
function_insertion_hook_holder = NULL;
@@ -4162,6 +4157,11 @@ inline_free_summary (void)
node_duplication_hook_holder = NULL;
if (edge_duplication_hook_holder)
cgraph_remove_edge_duplication_hook (edge_duplication_hook_holder);
+ if (!inline_edge_summary_vec.exists ())
+return;
+ FOR_EACH_DEFINED_FUNCTION (node)
+if (!node->alias)
+ reset_inline_summary (node);
edge_duplication_hook_holder = NULL;
vec_free (inline_summary_vec);
inline_edge_summary_vec.release ();
--
1.8.3.1
[ARM] fix a typo in ftest-armv7a-thumb.c
Hi all,
This is a simple patch which fix a type error found in
gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c
Okay for trunk?
Regards,
Renlin Li
gcc/testsuite/ChangeLog:
2014-02-03 Renlin Li
* gcc.target/arm/ftest-armv7a-thumb.c: Change aramv7-a to armv7-a.diff --git a/gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c b/gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c
index ac05ffa..f1f789e 100644
--- a/gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c
+++ b/gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } { "-march=aramv7-a" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } { "-march=armv7-a" } } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" } { "" } } */
/* { dg-options "-mthumb" } */
/* { dg-add-options arm_arch_v7a } */
GCC 4.9.0 Status Report (2014-02-03), Stage 3 ends
Status == After two months of Stage 3 the trunk is now in release-branch mode which means only patches fixing regressions and documentation issues are appropriate. We're getting a lot of bugs fixed and thus the quality data below shows we are on track for a release around the beginning of April. Still some architecture specific bugs lack attention by their maintainers. To remind people of the list of primary and secondary archs considered for GCC 4.9: The primary platforms are: arm-linux-gnueabi i386-unknown-freebsd i686-pc-linux-gnu mipsisa64-elf powerpc64-unknown-linux-gnu sparc-sun-solaris2.10 x86_64-unknown-linux-gnu The secondary platforms are: hppa2.0w-hp-hpux11.11 powerpc-ibm-aix7.1.0.0 i686-apple-darwin i686-pc-cygwin i686-mingw32 s390x-linux-gnu Archtecture maintainers please also look at the testsuite status of your port and try to clean it from existing failures. Quality Data Priority # Change from last report --- --- P1 32- 24 P2 87- 40 P3 21 --- --- Total 140- 64 Previous Report === http://gcc.gnu.org/ml/gcc/2013-12/msg00203.html The next report will be sent by Jakub
Re: [PATCH][AARCH64]Resolves testsuite/gcc.target/aarch64/aapcs64/ret-func-1.c regression
On 02/02/14 19:02, Renlin Li wrote:
Hi all,
This is a simple patch which resolves
testsuite/gcc.target/aarch64/aapcs64/ret-func-1.c regression.
Basically, no special operations are needed for vector type i32in128
or f32in64 in big-endian mode any more due the aarch64 back-end change.
Okay for trunk?
Kind regards,
Renlin Li
Hi all,
I forgot to attach the ChangeLog. Sorry for this additional annoying email.
Kind regards,
Renlin Li
gcc/testsuite/ChangeLog:
2014-02-03 Renlin Li
* gcc.target/aarch64/aapcs64/validate_memory.h: move f32in64 and
i32in128 cases
outside special big-endian processing block.diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/validate_memory.h b/gcc/testsuite/gcc.target/aarch64/aapcs64/validate_memory.h
index ac94625..24431c6 100644
--- a/gcc/testsuite/gcc.target/aarch64/aapcs64/validate_memory.h
+++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/validate_memory.h
@@ -60,8 +60,6 @@ validate_memory (void *mem1, char *mem2, size_t size, enum structure_type type)
case i8in64:
case i16in64:
case i32in64:
-case f32in64:
-case i32in128:
for (i = 0; i < size; i += element_size[type])
{
if (memcmp (cmem1 + i,
@@ -72,6 +70,8 @@ validate_memory (void *mem1, char *mem2, size_t size, enum structure_type type)
return 0;
break;
#endif
+case f32in64:
+case i32in128:
default:
break;
}
New template for 'cpplib' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'cpplib' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/cpplib-4.9-b20140202.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140202/gcc-4.9-20140202.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New template for 'gcc' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/gcc-4.9-b20140202.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140202/gcc-4.9-20140202.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [ARM] fix a typo in ftest-armv7a-thumb.c
On 02/03/14 09:58, Renlin Li wrote: Hi all, This is a simple patch which fix a type error found in gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c Okay for trunk? Ok. Ramana Regards, Renlin Li gcc/testsuite/ChangeLog: 2014-02-03 Renlin Li * gcc.target/arm/ftest-armv7a-thumb.c: Change aramv7-a to armv7-a. -- Ramana Radhakrishnan Principal Engineer ARM Ltd.
Contents of PO file 'cpplib-4.9-b20140202.sv.po'
cpplib-4.9-b20140202.sv.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
New Swedish PO file for 'cpplib' (version 4.9-b20140202)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/cpplib/sv.po (This file, 'cpplib-4.9-b20140202.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [Patch][AArch64] Shift right pattern fix
Hi, I agree to changelog change. Could this patch, please, be submitted as I do not have rights to do so. Kind regards, Alex On 30/01/14 22:36, Marcus Shawcroft wrote: On 30 January 2014 15:28, Alex Velenko wrote: Hi, This patch fixes shift right pattern, as it failed on -O0 after shift right patch. The reason was unnecessary movement of immediate value to a register due to type mismatch. Patch is tested not to cause any additional regressions. Could someone, please, approve and commit this patch, as I do not have the rights to do so? Kind regards, Alex 2014-01-28 Alex Velenko gcc/ * config/aarch64/aarch64-simd.md (aarch64_ashr_simddi): Fixed. Fixed doesn't say what was changed, how about: * config/aarch64/aarch64-simd.md (aarch64_ashr_simddi): Change QI to SI. OK with that change. /Marcus
Re: [Documentation] Remove documentation of gimple_asm_clear_volatile
On Mon, 3 Feb 2014, James Greenhalgh wrote: > Will and I were trying to understand the semantics of volatile asm > statements (we didn't succeed!) when we came across documentation > for: > > gimple_asm_clear_volatile > > This function looks like it is long gone, so this patch removes the > documentation. Yep, cf. % grep gimple_asm_clear_volatile gcc/* gcc/ChangeLog.tuples: (gimple_asm_clear_volatile): Remove. gcc/ChangeLog.tuples: (gimple_asm_clear_volatile): New. > OK? > > 2014-01-31 James Greenhalgh > Will Deacon > > * doc/gimple.texi (gimple_asm_clear_volatile): Remove. Yes, thanks. And you don't need to ask for approval for changes like this. ;-) (And thanks for fixing such things!) Gerald
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
Ian Lance Taylor writes: > On Mon, Jan 20, 2014 at 4:29 AM, Rainer Orth > wrote: >> >> Given that there were no other comments, I'd like to install the patch >> now. Ian, could you please install the ltmain.sh patch in libgo/config, >> or should I do so myself? > > I'll do it. Thanks. Could you please take care of that, provided the RMs approve? The patch was ok two weeks ago and is completely Solaris-specific, so I'd like to get it into the 4.9.0 release. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[committed][ARM] Regenerate arm-tables.opt for armv7ve patch
Hi all, I've regenerated arm-tables.opt in config/arm. I should have done that when committing the -march=armv7ve patch (r207237). I've regenerated it, made sure that the tests that were failing due to this PASS and committed it as r207418. Sorry for the noise, Kyrill 2014-02-03 Kyrylo Tkachov * config/arm/arm-tables.opt: Regenerate.
[PATCH][ARM] Adjust thumb2_movhi_insn patter
Hi all, This patch updates the thumb2_movhi_insn pattern for the -mrestrict-it rules. I had somehow missed it when doing the -mrestrict-it work last year, and it is possible to generate a deprecated IT block form in ARMv8 Thumb2 codegen without this patch. Tested arm-none-eabi and bootstrapped on arm-none-linux-gnueabihf. Ok for trunk? Thanks, Kyrill 2014-02-03 Kyrylo Tkachov * config/arm/thumb2.md (*thumb2_movhi_insn): Add alternatives for arm_restrict_it.diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md index 4f247f8..d84938f 100644 --- a/gcc/config/arm/thumb2.md +++ b/gcc/config/arm/thumb2.md @@ -317,20 +317,24 @@ ;; Thumb-2 always has load/store halfword instructions, so we can avoid a lot ;; of the messiness associated with the ARM patterns. (define_insn "*thumb2_movhi_insn" - [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r,m,r") - (match_operand:HI 1 "general_operand" "rI,n,r,m"))] + [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r,l,r,m,r") + (match_operand:HI 1 "general_operand" "r,I,Py,n,r,m"))] "TARGET_THUMB2 && (register_operand (operands[0], HImode) || register_operand (operands[1], HImode))" "@ mov%?\\t%0, %1\\t%@ movhi + mov%?\\t%0, %1\\t%@ movhi + mov%?\\t%0, %1\\t%@ movhi movw%?\\t%0, %L1\\t%@ movhi str%(h%)\\t%1, %0\\t%@ movhi ldr%(h%)\\t%0, %1\\t%@ movhi" - [(set_attr "type" "mov_imm,mov_reg,store1,load1") + [(set_attr "type" "mov_reg,mov_imm,mov_imm,mov_reg,store1,load1") (set_attr "predicable" "yes") - (set_attr "pool_range" "*,*,*,4094") - (set_attr "neg_pool_range" "*,*,*,250")] + (set_attr "predicable_short_it" "yes,no,yes,no,no,no") + (set_attr "length" "2,4,2,4,4,4") + (set_attr "pool_range" "*,*,*,*,*,4094") + (set_attr "neg_pool_range" "*,*,*,*,*,250")] ) (define_insn "*thumb2_storewb_pairsi"
[PATCH][RFC][libatomic] Override -mcpu option for arm linux ifunc targets
Hi all, There is a slight issue with the libatomic Makefile for arm linux ifunc targets. It adds an explicity -march=armv7-a option to the command line to enable building the exclusive instruction variants in libatomic. However, if the multilib machinery tries to add an -mcpu option that conflicts with the -march one (such as -mcpu=cortex-a15) gcc will give a warning about incompatible -march and -mcpu options, causing the -Werror build to fail. A workaround here is to override the -mcpu option as well as the -march one. This patch does that by adding an EXTRA_OVERRIDE variable and setting it to -mcpu=cortex-a9 under the same conditions as when -march=armv7-a is selected, so that it's added only when -march=armv70a is added. Can someone see a better way of achieving this? If this is acceptable, ok to commit? Build and test arm-none-linux-gnueabi with --enable-gnu-indirect-function Bootstrap on x86 with --enable-gnu-indirect-function Thanks, Kyrill 2014-02-03 Kyrylo Tkachov * Makefile.in: Override -mcpu option when building arm linux ifunc targets.diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in index 46e60c9..b51910a 100644 --- a/libatomic/Makefile.in +++ b/libatomic/Makefile.in @@ -297,7 +297,7 @@ PAT_BASE = $(word 1,$(PAT_SPLIT)) PAT_N = $(word 2,$(PAT_SPLIT)) PAT_S = $(word 3,$(PAT_SPLIT)) IFUNC_DEF = -DIFUNC_ALT=$(PAT_S) -IFUNC_OPT = $(word $(PAT_S),$(IFUNC_OPTIONS)) +IFUNC_OPT = $(word $(PAT_S),$(IFUNC_OPTIONS)) $(word $(PAT_S),$(EXTRA_OVERRIDE)) M_DEPS = -MT $@ -MD -MP -MF $(DEPDIR)/$(@F).Ppo M_SIZE = -DN=$(PAT_N) M_IFUNC = $(if $(PAT_S),$(IFUNC_DEF) $(IFUNC_OPT)) @@ -313,7 +313,13 @@ M_SRC = $(firstword $(filter %/$(M_FILE), $(all_c_files))) libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix \ _$(s)_.lo,$(SIZEOBJS))) $(am__append_1) $(am__append_2) \ $(am__append_3) +# For ARM, the -march option by itself conflicts with any -mcpu option that +# we might end up passing to the build, causing an error. +# Therefore we override the -mcpu option as well. +# This shouldn't affect tuning much because the affected code is mostly +# in inline assembly anyway. @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a -DHAVE_KERNEL64 +@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@EXTRA_OVERRIDE = -mcpu=cortex-a9 @ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=i586 @ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -mcx16 libatomic_convenience_la_SOURCES = $(libatomic_la_SOURCES)
Re: [PATCH] Fix PR 57662
Hello,
On 14.08.2013 17:12, Andrey Belevantsev wrote:
Hello,
As noted in Bugzilla, the problem is this PR is the rare case of removing
the unconditional jump that is used for traversing CFG when simplifying
control flow. We rescan the remaining successors when we know the flow
below the current point has changed, and when we have removed the jump we
are currently on, we segfault. The fix is just to break out of successor
iterator loop as in the unconditional jump case we have already visited the
only successor.
I've recently found another test case for this PR which exhibits the
segfault in the other spot of the CFG traversal driver -- we try to mark
the basic block as visited when it is already gone. Fixed with the below
patch, the test was reduced as much as multidelta could. Bootstrapped and
tested on ia64, committed to trunk.
Yours,
Andrey
gcc/
PR rtl-optimization/57662
* sel-sched.c (code_motion_path_driver): Do not mark already not
existing blocks in the visiting bitmap.
testsuite/
PR rtl-optimization/57662
* g++.dg/pr57662.C: New test.
Bootstrapped and tested on x86-64, ok for trunk? If yes, Alexander, could
you please commit this for me?
Andrey
2013-08-14 Andrey Belevantsev
PR rtl-optimization/57662
gcc/
* sel-sched.c (code_motion_process_successors): When the current insn
is removed after the recursive traversal, break from the loop.
Add comments and debug printouts.
testsuite/
* gcc.dg/pr57662.c: New test.
Index: gcc/ChangeLog
===
*** gcc/ChangeLog (revision 207420)
--- gcc/ChangeLog (revision 207422)
***
*** 1,5
--- 1,11
2014-02-03 Andrey Belevantsev
+ PR rtl-optimization/57662
+ * sel-sched.c (code_motion_path_driver): Do not mark already not
+ existing blocks in the visiting bitmap.
+
+ 2014-02-03 Andrey Belevantsev
+
* sel-sched-ir.c (sel_gen_insn_from_expr_after): Reset INSN_DELETED_P
on the insn being emitted.
Index: gcc/testsuite/ChangeLog
===
*** gcc/testsuite/ChangeLog (revision 207420)
--- gcc/testsuite/ChangeLog (revision 207422)
***
*** 1,3
--- 1,8
+ 2014-02-03 Andrey Belevantsev
+
+ PR rtl-optimization/57662
+ * g++.dg/pr57662.C: New test.
+
2014-02-02 Bill Schmidt
* gcc.dg/vmx/3b-15.c: Remove special handling for little endian.
Index: gcc/testsuite/g++.dg/pr57662.C
===
*** gcc/testsuite/g++.dg/pr57662.C (revision 0)
--- gcc/testsuite/g++.dg/pr57662.C (revision 207422)
***
*** 0
--- 1,339
+ /* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
+ /* { dg-options "-O2 -fselective-scheduling2 -fsel-sched-pipelining" } */
+
+ extern "C" {
+ typedef struct _IO_FILE FILE;
+ extern int putc(int __c, FILE * __stream);
+ extern int strcmp(__const char *__s1, __const char *__s2) throw()
+ __attribute__ ((__pure__)) __attribute__ ((__nonnull__(1, 2)));
+ } typedef union tree_node *tree;
+ struct gcc_options {
+ int x_flag_openmp;
+ };
+ extern struct gcc_options global_options;
+ struct ht_identifier {
+ const unsigned char *str;
+ };
+ enum cpp_ttype {
+ CPP_SEMICOLON, CPP_NAME
+ };
+ struct vl_embed {
+ };
+ struct va_heap {
+ };
+ struct va_gc {
+ typedef vl_embed default_layout;
+ };
+ template < typename T, typename A = va_heap, typename L =
+ typename A::default_layout > struct vec {
+ };
+ enum tree_code {
+ ERROR_MARK,
+ IDENTIFIER_NODE,
+ OMP_SIMD,
+ CILK_SIMD,
+ MAX_TREE_CODES
+ };
+ struct tree_identifier {
+ struct ht_identifier
+ id;
+ };
+ union tree_node {
+ struct tree_identifier
+ identifier;
+ };
+ inline tree
+ tree_check(tree __t, const char *__f, int __l, const char *__g, tree_code __c)
+ {
+ }
+
+ extern tree chainon(tree, tree);
+ extern vec < tree, va_gc > *make_tree_vector(void);
+ typedef unsigned long omp_clause_mask;
+ enum c_omp_clause_split {
+ C_OMP_CLAUSE_SPLIT_TARGET = 0, C_OMP_CLAUSE_SPLIT_COUNT
+ };
+ typedef struct cxx_saved_binding {
+ tree attributes;
+ } cp_decl_specifier_seq;
+ typedef enum pragma_kind {
+ PRAGMA_NONE = 0, PRAGMA_OMP_DECLARE_REDUCTION, PRAGMA_OMP_TARGET
+ } pragma_kind;
+ typedef enum pragma_omp_clause {
+ PRAGMA_OMP_CLAUSE_NONE =
+ 0, PRAGMA_OMP_CLAUSE_DEVICE, PRAGMA_OMP_CLAUSE_IF,
+ PRAGMA_OMP_CLAUSE_MAP
+ } pragma_omp_clause;
+ typedef struct cp_token {
+ enum cpp_ttype type:8;
+ union cp_token_value {
+ tree value;
+ } u;
+ } cp_token;
+ typedef struct cp_token *cp_token_position;
+ typedef struct cp_lexer {
+ cp_token_position next_token;
+ bool debugging_p;
+ cp_lexer *lexer;
+ } cp_parser;
+ static FILE *cp_lexer_debug_stream;
+ static inline bool cp_lexer_debugging_p(cp_lexer * lexer)
+ {
+ return lexer->debugging_p;
+ }
+
+ static inline cp_token *cp_lexer_peek_token(cp_lexer
[PATCH] Fix typo in doc/invoke.texi: (fprofile-reorder-functions)
Just noticed this typo while reading the man page.
Committed as obvious.
2014-02-03 Markus Trippelsdorf
* doc/invoke.texi: (fprofile-reorder-functions): Fix typo.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 268abf680653..5c396007a984 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9100,7 +9100,7 @@ from profiling values of expressions for usage in
optimizations.
Enabled with @option{-fprofile-generate} and @option{-fprofile-use}.
-@item -fprofile-reoder-functions
+@item -fprofile-reorder-functions
@opindex fprofile-reorder-functions
Function reordering based on profile instrumentation collects
first time of execution of a function and orders these functions
--
Markus
Contents of PO file 'cpplib-4.9-b20140202.uk.po'
cpplib-4.9-b20140202.uk.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
New Ukrainian PO file for 'cpplib' (version 4.9-b20140202)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Ukrainian team of translators. The file is available at: http://translationproject.org/latest/cpplib/uk.po (This file, 'cpplib-4.9-b20140202.uk.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
GCC trunk 4.9: documentation patch on plugins
Dear all,
The attached patch to trunk svn.rev 207422 is slightly improving the
documentation
of plugins (notably the few features & bugfixes I have introduced in 4.9)
gcc/ChangeLog entry
2014-02-03 Basile Starynkevitch
* doc/plugins.texi (Plugin callbacks): Mention PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after PLUGIN_FINISH.
Explain what pragmas with expansion are.
Comments are welcome. Recall that I am not a native English speaker,
so please improve my wordings in the documentation.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi (revision 207422)
+++ gcc/doc/plugins.texi (working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{"GCCPLUGIN"} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are allowing
+preprocessor expansions, like e.g.
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
Re: [gomp4] Merge trunk r206958 (was: gomp-4_0-branch)
Hi! On Mon, 3 Feb 2014 13:56:48 +0400, Ilya Tocar wrote: > > In r207132, I have now committed a merge of trunk r206958 (2014-01-23). > > Compared to a pristine trunk r206958 build, there is one regression: > > > > FAIL: g++.dg/gomp/declare-simd-1.C -std=c++98 (internal compiler error) > > FAIL: g++.dg/gomp/declare-simd-1.C -std=c++11 (internal compiler error) > Sorry for the delay, i was busy with AVX512. No problem. > I finally had time to look into this bug. > The problem in r205214 was in adding add_new_function hook in > inline_generate_summary with -O0 -fopenmp and not removing it, > before running expand_simd_clones. > I've changed inline_free_summary to always remove hooks. > Patch bellow. It bootstraps, passes make check, fixes declare-simd-1.C. > Ok for gomp4 branch? Thanks, and yes, please commit. Grüße, Thomas pgppMlKybNOwr.pgp Description: PGP signature
New Brazilian Portuguese PO file for 'cpplib' (version 4.9-b20140202)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Brazilian Portuguese team of translators. The file is available at: http://translationproject.org/latest/cpplib/pt_BR.po (This file, 'cpplib-4.9-b20140202.pt_BR.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Contents of PO file 'cpplib-4.9-b20140202.pt_BR.po'
cpplib-4.9-b20140202.pt_BR.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
> Additionally I'm not really sure
> why there is an additional load from the constant pool here - what is
> the constant in this case ?
> Given it is atmost a 16 bit constant
> surely that should be loaded with a single mov(w) instruction
> in armv7 land.
I've made some investigations with 4.8.
The problematic RTL is
(insn 1191 1190 1192 142 (set (reg:SI 1 r1)
(zero_extend:SI (subreg:HI (reg:SI 2606) 0))) svga_tgsi_emit.h:165
165 {*arm_zero_extendhisi2_v6}
(nil))
where RHS expression gets replaced with equivalent constant:
(const_int 1 [0x1])
in find_reloads. This constant is later matched against the constraints
of arm_zero_extendhisi2_v6: "r,m".
"r" fails, "m" succeeds and GCC decides to load constant from constant pool.
This latter causes errors in push_minipool_fix because
arm_zero_extendhisi2_v6 misses the pool_range attributes.
Everything looks reasonable but net result is ICE.
Thoughts?
-Y
Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
On Mon, Feb 3, 2014 at 3:14 PM, Yury Gribov wrote:
>> Additionally I'm not really sure
>> why there is an additional load from the constant pool here - what is
>> the constant in this case ?
>> Given it is atmost a 16 bit constant
>> surely that should be loaded with a single mov(w) instruction
>> in armv7 land.
>
> I've made some investigations with 4.8.
>
> The problematic RTL is
>
> (insn 1191 1190 1192 142 (set (reg:SI 1 r1)
> (zero_extend:SI (subreg:HI (reg:SI 2606) 0))) svga_tgsi_emit.h:165 165
> {*arm_zero_extendhisi2_v6}
> (nil))
>
> where RHS expression gets replaced with equivalent constant:
>
> (const_int 1 [0x1])
Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be
replaced by a move somewhere.
Ramana
Re: [PING] [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi Jakub! On 31.01.2014 15:45, Ilmir Usmanov wrote: Hi Jakub! Thank you for review and quick answer. The above are OpenACC specific clauses, so they should have OACC_LIST_*? I just followed Thomas's style recomendations: If we're adding new names for implementing OpenACC things, maybe we should also name these OMP_*, to keep things simple to read in the code that uses them. And I agree with him. + case OMP_LIST_DEVICE: type = "DEVICE"; break; This one is in OpenMP 4.0 too (though, I didn't get to OpenMP 4.0 / fortran support yet), so this should be OMP_LIST_DEVICE. As far as I know, OpenMP device clause requires integer-expression, not variable-list, so, I think, we can use OMP_LIST_DEVICE to represent OpenACC device clause. So, what should I do? Is current naming OK? Or you think it's better to use OACC_ prefix for OpenACC specific stuff in Fortran front-end and OMP_ prefix in middle-end? -- Ilmir.
Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
On 03/02/14 15:14, Yury Gribov wrote:
> > Additionally I'm not really sure
> > why there is an additional load from the constant pool here - what is
> > the constant in this case ?
> > Given it is atmost a 16 bit constant
> > surely that should be loaded with a single mov(w) instruction
> > in armv7 land.
>
> I've made some investigations with 4.8.
>
> The problematic RTL is
>
>(insn 1191 1190 1192 142 (set (reg:SI 1 r1)
> (zero_extend:SI (subreg:HI (reg:SI 2606) 0))) svga_tgsi_emit.h:165
> 165 {*arm_zero_extendhisi2_v6}
> (nil))
>
> where RHS expression gets replaced with equivalent constant:
>
>(const_int 1 [0x1])
>
No wonder GCC gets blamed for daft code generation The expression
should be replaced as a simple move, not a zero_extend of that constant.
If we did that we'd end up with
(set (reg) (const_int 1))
which in this case is a trivial MOV instruction; and in other cases
could at least access a literal pool with a sensible offset from the PC.
Failing to do that means everything goes down-hill from here.
Do we still get into this mess with LRA?
R.
> in find_reloads. This constant is later matched against the constraints
> of arm_zero_extendhisi2_v6: "r,m".
> "r" fails, "m" succeeds and GCC decides to load constant from constant pool.
>
> This latter causes errors in push_minipool_fix because
> arm_zero_extendhisi2_v6 misses the pool_range attributes.
>
> Everything looks reasonable but net result is ICE.
>
> Thoughts?
>
> -Y
>
[PATCH] Fix bug in vect dumping code causing infinite loop
This patch fixes a bug in the dumping code, whereby an inner loop index variable was the same as the outer loop index variable, and the redef caused an infinite loop. Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk? 2014-02-03 Teresa Johnson * tree-vect-slp.c (vect_supported_load_permutation_p): Avoid redef of outer loop index variable. Index: tree-vect-slp.c === --- tree-vect-slp.c (revision 207344) +++ tree-vect-slp.c (working copy) @@ -1103,8 +1103,8 @@ vect_supported_load_permutation_p (slp_instance sl FOR_EACH_VEC_ELT (node->load_permutation, j, next) dump_printf (MSG_NOTE, "%d ", next); else - for (i = 0; i < group_size; ++i) - dump_printf (MSG_NOTE, "%d ", i); + for (k = 0; k < group_size; ++k) + dump_printf (MSG_NOTE, "%d ", k); dump_printf (MSG_NOTE, "\n"); } -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
> Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be > replaced by a move somewhere. Actually the whole (zero_extend:SI (subreg:HI ...)) part is replaced by (const_int 1). It still ends up in constant pool though. -Y
[PATCH] Fix PR60012
This fixes PR60012 by considering TBAA for all DDRs in vectorizer
dependence analysis because the vectorizer can rely on at least
covering two scalar iterations.
It _should_ be a regression from 4.4 but I can't make a testcase
that has two TBAA disambiguatable types and is vectorized with 4.4
it seems ...
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok at this stage?
Thanks,
Richard.
2014-02-03 Richard Biener
PR tree-optimization/60012
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Apply
TBAA disambiguation to all DDRs.
* gcc.dg/vect/pr60012.c: New testcase.
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 207417)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -235,6 +235,18 @@ vect_analyze_data_ref_dependence (struct
|| (DR_IS_READ (dra) && DR_IS_READ (drb)))
return false;
+ /* Even if we have an anti-dependence then, as the vectorized loop covers at
+ least two scalar iterations, there is always also a true dependence.
+ As the vectorizer does not re-order loads and stores we can ignore
+ the anti-dependence if TBAA can disambiguate both DRs similar to the
+ case with known negative distance anti-dependences (positive
+ distance anti-dependences would violate TBAA constraints). */
+ if (((DR_IS_READ (dra) && DR_IS_WRITE (drb))
+ || (DR_IS_WRITE (dra) && DR_IS_READ (drb)))
+ && !alias_sets_conflict_p (get_alias_set (DR_REF (dra)),
+get_alias_set (DR_REF (drb
+return false;
+
/* Unknown data dependence. */
if (DDR_ARE_DEPENDENT (ddr) == chrec_dont_know)
{
Index: gcc/testsuite/gcc.dg/vect/pr60012.c
===
*** gcc/testsuite/gcc.dg/vect/pr60012.c (revision 0)
--- gcc/testsuite/gcc.dg/vect/pr60012.c (working copy)
***
*** 0
--- 1,21
+ /* { dg-do compile } */
+ /* { dg-additional-options "--param vect-max-version-for-alias-checks=0" } */
+
+ typedef struct
+ {
+ short real;
+ short imag;
+ } complex16_t;
+
+ void
+ libvector_AccSquareNorm_ref (unsigned long long *acc,
+const complex16_t *x, unsigned len)
+ {
+ unsigned i;
+ for (i = 0; i < len; i++)
+ acc[i] += ((unsigned long long)((int)x[i].real * x[i].real))
+ + ((unsigned long long)((int)x[i].imag * x[i].imag));
+ }
+
+ /* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" } } */
+ /* { dg-final { cleanup-tree-dump "vect" } } */
Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
[this time to the list] On 03/02/14 15:41, Yury Gribov wrote: > > Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be > > replaced by a move somewhere. > > Actually the whole (zero_extend:SI (subreg:HI ...)) part is replaced by > (const_int 1). It still ends up in constant pool though. > > -Y > I find that hard to believe. The subreg being replaced is believable, but not the zero_extend. That would mean we had a simple movhi pattern, not a zero-extend pattern. R.
Re: [PATCH] Fix bug in vect dumping code causing infinite loop
On Mon, Feb 3, 2014 at 4:29 PM, Teresa Johnson wrote: > This patch fixes a bug in the dumping code, whereby an inner loop > index variable was the same as the outer loop index variable, and the > redef caused an infinite loop. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk? Ok Thanks, Richard. > 2014-02-03 Teresa Johnson > > * tree-vect-slp.c (vect_supported_load_permutation_p): Avoid > redef of outer loop index variable. > > Index: tree-vect-slp.c > === > --- tree-vect-slp.c (revision 207344) > +++ tree-vect-slp.c (working copy) > @@ -1103,8 +1103,8 @@ vect_supported_load_permutation_p (slp_instance sl > FOR_EACH_VEC_ELT (node->load_permutation, j, next) > dump_printf (MSG_NOTE, "%d ", next); > else > - for (i = 0; i < group_size; ++i) > - dump_printf (MSG_NOTE, "%d ", i); > + for (k = 0; k < group_size; ++k) > + dump_printf (MSG_NOTE, "%d ", k); >dump_printf (MSG_NOTE, "\n"); > } > > > -- > Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [PATCH] Fix PR60012
On Mon, Feb 03, 2014 at 04:42:39PM +0100, Richard Biener wrote: > > This fixes PR60012 by considering TBAA for all DDRs in vectorizer > dependence analysis because the vectorizer can rely on at least > covering two scalar iterations. > > It _should_ be a regression from 4.4 but I can't make a testcase > that has two TBAA disambiguatable types and is vectorized with 4.4 > it seems ... > > Bootstrapped and tested on x86_64-unknown-linux-gnu, ok at this stage? Ok. > 2014-02-03 Richard Biener > > PR tree-optimization/60012 > * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Apply > TBAA disambiguation to all DDRs. > > * gcc.dg/vect/pr60012.c: New testcase. Jakub
New Russian PO file for 'cpplib' (version 4.9-b20140202)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Russian team of translators. The file is available at: http://translationproject.org/latest/cpplib/ru.po (This file, 'cpplib-4.9-b20140202.ru.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Contents of PO file 'cpplib-4.9-b20140202.ru.po'
cpplib-4.9-b20140202.ru.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
Re: PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
On Fri, Jan 31, 2014 at 10:19:12AM -0800, H.J. Lu wrote:
> On Fri, Jan 31, 2014 at 10:12 AM, Joseph S. Myers
> wrote:
> > On Fri, 31 Jan 2014, Andrew Pinski wrote:
> >
> >> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
> >> > Hi,
> >> >
> >> > For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
> >> > This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
> >> > Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128,
> >> > -mlong-double-64 and -mlong-double-80 negate each other so that the
> >> > last one on command line wins. It os OK since we don't support
> >> > -mlong-double-xxx in target attribute. I added some testcases to verify
> >> > it works correctly. OK for trunk?
> >>
> >> I don't see any where in the documentation that explains the
> >> difference between -mlong-double-128 and -m128bit-long-double. Can
> >> you please add that -mlong-double-128 causes soft-floating point.
>
> I will update it together with -m128bit-long-double clarification.
>
> >> Also what about the interactions between these two options.
>
> They have nothing to do with each other. -m128bit-long-double
> controls the storage size of __float80 amd -mlong-double-XXX
> controls the size of long double, 64, 80 and 128 bits.
I checked in my patch. Here is a patch to update invoke.texi. OK
for trunk?
Thanks.
H.J.
---
2014-02-03 H.J. Lu
* doc/invoke.texi: Document -m96bit-long-double/-m128bit-long-double
for the storage size of 80-bit long double. Mention software
floating-point for __float128.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 89e80ac..e2193a9 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15027,28 +15027,28 @@ without that switch.
@itemx -m128bit-long-double
@opindex m96bit-long-double
@opindex m128bit-long-double
-These switches control the size of @code{long double} type. The i386
-application binary interface specifies the size to be 96 bits,
+These switches control the storage size of 80-bit @code{long double} type.
+The i386 application binary interface specifies the size to be 96 bits,
so @option{-m96bit-long-double} is the default in 32-bit mode.
-Modern architectures (Pentium and newer) prefer @code{long double}
+Modern architectures (Pentium and newer) prefer 80-bit @code{long double}
to be aligned to an 8- or 16-byte boundary. In arrays or structures
conforming to the ABI, this is not possible. So specifying
-@option{-m128bit-long-double} aligns @code{long double}
-to a 16-byte boundary by padding the @code{long double} with an additional
-32-bit zero.
+@option{-m128bit-long-double} aligns 80-bit @code{long double}
+to a 16-byte boundary by padding the 80-bit @code{long double} with an
+additional 32-bit zero.
In the x86-64 compiler, @option{-m128bit-long-double} is the default choice as
-its ABI specifies that @code{long double} is aligned on 16-byte boundary.
+its ABI specifies that 80-bit @code{long double} is aligned on 16-byte
boundary.
Notice that neither of these options enable any extra precision over the x87
-standard of 80 bits for a @code{long double}.
+standard of 80 bits for an 80-bit @code{long double}.
@strong{Warning:} if you override the default value for your target ABI, this
changes the size of
-structures and arrays containing @code{long double} variables,
+structures and arrays containing 80-bit @code{long double} variables,
as well as modifying the function calling convention for functions taking
-@code{long double}. Hence they are not binary-compatible
+80-bit @code{long double}. Hence they are not binary-compatible
with code compiled without that switch.
@item -mlong-double-64
@@ -15061,7 +15061,8 @@ These switches control the size of @code{long double}
type. A size
of 64 bits makes the @code{long double} type equivalent to the @code{double}
type. This is the default for 32-bit Bionic C library. A size
of 128 bits makes the @code{long double} type equivalent to the
-@code{__float128} type. This is the default for 64-bit Bionic C library.
+@code{__float128} type, which is implemented with software floating-point
+support. This is the default for 64-bit Bionic C library.
@strong{Warning:} if you override the default value for your target ABI, this
changes the size of
[PATCH][ARM]fix potential testsuite/gcc.target/arm/fixed_float_conversion.c regression
Hi all,
This patch will ensure testsuite/gcc.target/arm/fixed_float_conversion.c
is checked only when "-mfpu=vfp3 -mfloat-abi=softfp" is applicable for
the target.
Accordingly, two procs (check_effective_target_arm_vfp3_ok and
add_options_for_arm_vfp3) are added into
gcc/testsuite/lib/target-supports.exp.
I have also update related documentation.
Okay for trunk?
Kind regards,
Renlin Li
gcc/testsuite/ChangeLog:
2014-02-03 Renlin Li
* gcc.target/arm/fixed_float_conversion.c: Add arm_vfp3 option to
the test case.
* lib/target-supports.exp: check_effective_target_arm_vfp3_ok: New.
add_options_for_arm_vfp3: New.
gcc/ChangeLog:
2014-02-03 Renlin Li
* doc/sourcebuild.texi: Document check_effective_target_arm_vfp3_ok and
add_options_for_arm_vfp3diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index f9bc880..1ea5753 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1551,6 +1551,10 @@ ARM target generates Thumb-2 code for @code{-mthumb}.
ARM target supports @code{-mfpu=vfp -mfloat-abi=softfp}.
Some multilibs may be incompatible with these options.
+@item arm_vfp3_ok
+ARM target supports @code{-mfpu=vfp3 -mfloat-abi=softfp}.
+Some multilibs may be incompatible with these options.
+
@item arm_v8_vfp_ok
ARM target supports @code{-mfpu=fp-armv8 -mfloat-abi=softfp}.
Some multilibs may be incompatible with these options.
@@ -1954,6 +1958,10 @@ NEON and half-precision floating point support. Only ARM targets
support this feature, and only then in certain modes; see
the @ref{arm_neon_ok,,arm_neon_fp16_ok effective target keyword}.
+@item arm_vfp3
+arm vfp3 floating point support; see
+the @ref{arm_vfp3_ok,,arm_vfp3_ok effective target keyword}.
+
@item bind_pic_locally
Add the target-specific flags needed to enable functions to bind
locally when using pic/PIC passes in the testsuite.
diff --git a/gcc/testsuite/gcc.target/arm/fixed_float_conversion.c b/gcc/testsuite/gcc.target/arm/fixed_float_conversion.c
index a8befd0..078b103 100644
--- a/gcc/testsuite/gcc.target/arm/fixed_float_conversion.c
+++ b/gcc/testsuite/gcc.target/arm/fixed_float_conversion.c
@@ -1,7 +1,8 @@
/* Check that vcvt is used for fixed and float data conversions. */
/* { dg-do compile } */
-/* { dg-options "-O1 -mfpu=vfp3" } */
-/* { dg-require-effective-target arm_vfp_ok } */
+/* { dg-require-effective-target arm_vfp3_ok } */
+/* { dg-options "-O1" } */
+/* { dg-add-options arm_vfp3 } */
float
fixed_to_float (int i)
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 5166679..4164d1b 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2245,6 +2245,19 @@ proc check_effective_target_arm_vfp_ok { } {
}
}
+# Return 1 if this is an ARM target supporting -mfpu=vfp3
+# -mfloat-abi=softfp.
+
+proc check_effective_target_arm_vfp3_ok { } {
+if { [check_effective_target_arm32] } {
+ return [check_no_compiler_messages arm_vfp3_ok object {
+ int dummy;
+ } "-mfpu=vfp3 -mfloat-abi=softfp"]
+} else {
+ return 0
+}
+}
+
# Return 1 if this is an ARM target supporting -mfpu=fp-armv8
# -mfloat-abi=softfp.
proc check_effective_target_arm_v8_vfp_ok {} {
@@ -2373,6 +2386,14 @@ proc add_options_for_arm_neonv2 { flags } {
return "$flags $et_arm_neonv2_flags"
}
+# Add the options needed for vfp3.
+proc add_options_for_arm_vfp3 { flags } {
+if { ! [check_effective_target_arm_vfp3_ok] } {
+return "$flags"
+}
+return "$flags -mfpu=vfp3 -mfloat-abi=softfp"
+}
+
# Return 1 if this is an ARM target supporting -mfpu=neon
# -mfloat-abi=softfp or equivalent options. Some multilibs may be
# incompatible with these options. Also set et_arm_neon_flags to the
[C++ Patch] PR 58871
Hi,
in this ICE on invalid regression, after a sensible error message about
the invalid base type we crash in implicit_declare_fn at the gcc_assert:
else if (trivial_p && cxx_dialect >= cxx11
&& (kind == sfk_copy_constructor
|| kind == sfk_move_constructor))
gcc_assert (constexpr_p);
This happens because synthesized_method_walk sets *trivial_p to true and
then envisages to check the vbases with:
if (vbases == NULL)
/* No virtual bases to worry about. */;
else if (!assign_p)
{
if (constexpr_p)
*constexpr_p = false;
FOR_EACH_VEC_ELT (*vbases, i, base_binfo)
the loop doesn't execute at all, vbases->is_empty is true, and
*constexpr_p remains false, inconsistently with *trivial_p.
Normally, that is outside error recovery, either vbases is null or the
vector is non-empty, but in the cases at issue, when xref_basetypes
bails out early with an error about the invalid base type, that isn't
true, the vector is allocated in xref_basetypes but remains empty.
I tried to figure out a way to completely avoid such circumstances, but
rearranging the loop in xref_basetypes doesn't seem easy, or at least
not completely safe at this stage, thus the below.
Thanks,
Paolo.
//
/cp
2014-02-03 Paolo Carlini
PR c++/58871
* method.c (synthesized_method_walk): If vbases is non-null but
is_empty is true, likewise don't worry about the virtual bases.
/testsuite
2014-02-03 Paolo Carlini
PR c++/58871
* g++.dg/cpp0x/pr58871.C: New.
Index: cp/method.c
===
--- cp/method.c (revision 207422)
+++ cp/method.c (working copy)
@@ -1366,7 +1366,9 @@ synthesized_method_walk (tree ctype, special_funct
}
vbases = CLASSTYPE_VBASECLASSES (ctype);
- if (vbases == NULL)
+ if (vbases == NULL
+ /* Can happen for invalid base types (c++/58871). */
+ || vbases->is_empty ())
/* No virtual bases to worry about. */;
else if (!assign_p)
{
Index: testsuite/g++.dg/cpp0x/pr58871.C
===
--- testsuite/g++.dg/cpp0x/pr58871.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr58871.C(working copy)
@@ -0,0 +1,12 @@
+// PR c++/59111
+// { dg-do compile { target c++11 } }
+
+template struct A : virtual T // { dg-error "base type" }
+{
+ A();
+ A(const A&);
+};
+
+template A::A(const A&) = default;
+
+A a = A();
Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
> The subreg being replaced is believable, but not the zero_extend. > That would mean we had a simple movhi pattern, not a zero-extend pattern. Sorry, you are right. It's just subreg without zero_extend! -Y
Re: [C++ Patch] PR 58871
Use vec_safe_is_empty instead of checking the two representations of an empty vector separately. OK with that change. Jason
Re: [patch] Add missing generated file to contrib/gcc_update list.
On Fri, Jan 31, 2014 at 10:43 PM, Brooks Moses wrote: > The gcc_update file is missing an entry for > gcc/config/aarch64/aarch64.md; this patch adds it. > > Ok for trunk? OK. Diego.
Re: [C++ Patch] PR 58871
On 02/03/2014 05:17 PM, Jason Merrill wrote:
Use vec_safe_is_empty instead of checking the two representations of
an empty vector separately. OK with that change.
Ah nice. Thanks.
Note, anyway, that unfortunately it's pretty easy to construct an ICE on
valid too, which doesn't seem a regression, but should be also looked at.
struct B { };
template struct A : virtual B
{
A();
A(const A&);
};
template A::A(const A&) = default;
A a = A();
What do you think? Shall I check for duplicates and in case open a new
Bugzilla?
Thanks,
Paolo.
Contents of PO file 'cpplib-4.9-b20140202.nl.po'
cpplib-4.9-b20140202.nl.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
New Dutch PO file for 'cpplib' (version 4.9-b20140202)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Dutch team of translators. The file is available at: http://translationproject.org/latest/cpplib/nl.po (This file, 'cpplib-4.9-b20140202.nl.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [C,C++] integer constants in attribute arguments
On 01/18/2014 05:33 PM, Marc Glisse wrote: So when we have: __attribute__((nonnull(bar,bar))) the parser will keep bar as an identifier for the first argument, but parse the second one as an expr-list and thus find the associated function_decl. OK, that makes sense. But why do we need to handle that specially? Isn't that an invalid argument whether or not it decays to a pointer? Jason
Re: RFA: MN10300: Fix building libstdc++-v3
On 02/03/14 10:11, Nick Clifton wrote: Hi Jeff, Hi Alex, Currently the mainline MN10300 toolchain does not build the libstdc++-v3 library because: /libstdc++-v3/include/bits/locale_facets_nonio.tcc:1213:5: error: unable to find a register to spill in class 'EXTENDED_REGS' mn10300-elf/mn10300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1213:5: internal compiler error: in spill_failure, at reload1.c:2106 Of course the MN10300 does not have any extended registers, so it is not surprising that reload cannot find any to spill. The reason why reload thinks that it can use the EXTENDED_REGS class however is the mn10300_register_move_cost() function which tells it that it only costs 2 to move via those registers. Hence the patch below. With the patch applied the libstdc++-v3 library now builds. OK to apply ? gcc/ChangeLog 2014-02-03 Nick Clifton * config/mn10300/mn10300.c (mn10300_register_move_cost): Prevent moves via extended registers in MN10300 mode. But how/why did an extended register get selected to begin with? HARD_REGNO_MODE_OK and other macros/hooks ought to be preventing this relatively early. Twiddling costs just seems to be papering over some deeper issue. jeff
Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be replaced by a move somewhere. So I'm all for fixing this but I don't really know where to start. Do you have any suggestions? Julian's patch now looks more like a workaround... -Y
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
On Mon, Feb 3, 2014 at 2:55 AM, Rainer Orth wrote: > Ian Lance Taylor writes: > >> On Mon, Jan 20, 2014 at 4:29 AM, Rainer Orth >> wrote: >>> >>> Given that there were no other comments, I'd like to install the patch >>> now. Ian, could you please install the ltmain.sh patch in libgo/config, >>> or should I do so myself? >> >> I'll do it. Thanks. > > Could you please take care of that, provided the RMs approve? The patch > was ok two weeks ago and is completely Solaris-specific, so I'd like to > get it into the 4.9.0 release. I was just waiting for you to commit it elsewhere. The patch to libgo/ltmain.sh is now committed to mainline. Ian
RFA: MN10300: Fix building libstdc++-v3
Hi Jeff, Hi Alex, Currently the mainline MN10300 toolchain does not build the libstdc++-v3 library because: /libstdc++-v3/include/bits/locale_facets_nonio.tcc:1213:5: error: unable to find a register to spill in class 'EXTENDED_REGS' mn10300-elf/mn10300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1213:5: internal compiler error: in spill_failure, at reload1.c:2106 Of course the MN10300 does not have any extended registers, so it is not surprising that reload cannot find any to spill. The reason why reload thinks that it can use the EXTENDED_REGS class however is the mn10300_register_move_cost() function which tells it that it only costs 2 to move via those registers. Hence the patch below. With the patch applied the libstdc++-v3 library now builds. OK to apply ? gcc/ChangeLog 2014-02-03 Nick Clifton * config/mn10300/mn10300.c (mn10300_register_move_cost): Prevent moves via extended registers in MN10300 mode. Index: gcc/config/mn10300/mn10300.c === --- gcc/config/mn10300/mn10300.c(revision 207416) +++ gcc/config/mn10300/mn10300.c(working copy) @@ -2216,6 +2214,11 @@ enum reg_class to = (enum reg_class) ito; enum reg_class scratch, test; + /* Make sure that moves via the extended register class + are too expensive to ever be chosen for the MN10300. */ + if (! TARGET_AM33 && (ifrom == EXTENDED_REGS || ito == EXTENDED_REGS)) +return 100; + /* Simplify the following code by unifying the fp register classes. */ if (to == FP_ACC_REGS) to = FP_REGS;
Re: [C,C++] integer constants in attribute arguments
On Mon, 3 Feb 2014, Jason Merrill wrote: On 01/18/2014 05:33 PM, Marc Glisse wrote: So when we have: __attribute__((nonnull(bar,bar))) the parser will keep bar as an identifier for the first argument, but parse the second one as an expr-list and thus find the associated function_decl. OK, that makes sense. But why do we need to handle that specially? Isn't that an invalid argument whether or not it decays to a pointer? The C version of default_conversion does not convert a function_decl to a pointer (that's done earlier, during parsing), it ICEs. As you can see for the one attribute that is C++-only, I don't have any protection before calling default_conversion, it is only for the C front-end (for which calling default_conversion is useless anyway, but that's how it is already done in a couple other attributes). -- Marc Glisse
Re: [C,C++] integer constants in attribute arguments
On 02/03/2014 12:46 PM, Marc Glisse wrote: The C version of default_conversion does not convert a function_decl to a pointer (that's done earlier, during parsing), it ICEs. Ah, I see. The patch is OK, then. Jason
Is testing libgomp outside of the build tree supported?
Greetings, We test GCC without access to the build tree (we only have convenient access to install and source trees). Building libgomp.c/affinity-1.c and libgomp.c++/affinity-1.C fails in such testing, because of '#include "config.h"' which is nowhere to be found. Is that a bug? Should I open a bugzilla issue for it? Thanks,
Re: [C++ Patch] PR 58871
On 02/03/2014 11:52 AM, Paolo Carlini wrote:
Note, anyway, that unfortunately it's pretty easy to construct an ICE on
valid too, which doesn't seem a regression, but should be also looked at.
struct B { };
template struct A : virtual B
{
A();
A(const A&);
};
template A::A(const A&) = default;
A a = A();
What do you think? Shall I check for duplicates and in case open a new
Bugzilla?
Please. I'd be surprised if that isn't a regression.
Jason
Re: [C++ Patch] PR 58871
Hi,
On 02/03/2014 05:55 PM, Jason Merrill wrote:
On 02/03/2014 11:52 AM, Paolo Carlini wrote:
Note, anyway, that unfortunately it's pretty easy to construct an ICE on
valid too, which doesn't seem a regression, but should be also looked
at.
struct B { };
template struct A : virtual B
{
A();
A(const A&);
};
template A::A(const A&) = default;
A a = A();
What do you think? Shall I check for duplicates and in case open a new
Bugzilla?
Please. I'd be surprised if that isn't a regression.
Done, it's c++/60047.
Thanks,
Paolo.
Re: Is testing libgomp outside of the build tree supported?
On Mon, Feb 3, 2014 at 10:03 AM, Paul Pluzhnikov wrote: > > We test GCC without access to the build tree (we only have convenient access > to > install and source trees). > > Building libgomp.c/affinity-1.c and libgomp.c++/affinity-1.C fails in > such testing, because of '#include "config.h"' which is nowhere to be > found. > > Is that a bug? > Should I open a bugzilla issue for it? If it's easy to fix then I think it should be fixed. But I don't think there should be a hard and fast rule that all GCC tests can be run without the build tree. If the presence of the build tree makes writing some tests significantly simpler, I think that is OK. Ian
Re: Is testing libgomp outside of the build tree supported?
On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote: > If the presence of the build > tree makes writing some tests significantly simpler, I think that is > OK. I would like to discourage that. Testing an already installed GCC for which no build tree exists is a very useful feature. Internally, we have a very strong dependency on this feature. If it were to disappear, it would be almost impossible for us to test the compiler at the massive scale that we do. Diego.
Re: Is testing libgomp outside of the build tree supported?
On Mon, Feb 03, 2014 at 11:11:31AM -0800, Ian Lance Taylor wrote: > On Mon, Feb 3, 2014 at 10:03 AM, Paul Pluzhnikov > wrote: > > > > We test GCC without access to the build tree (we only have convenient > > access to > > install and source trees). > > > > Building libgomp.c/affinity-1.c and libgomp.c++/affinity-1.C fails in > > such testing, because of '#include "config.h"' which is nowhere to be > > found. > > > > Is that a bug? > > Should I open a bugzilla issue for it? > > If it's easy to fix then I think it should be fixed. > > But I don't think there should be a hard and fast rule that all GCC > tests can be run without the build tree. If the presence of the build > tree makes writing some tests significantly simpler, I think that is > OK. If there is some effective target or similar way to limit the tests to build tree testing, then those tests probably could be guarded by that, otherwise you'll have to live with the FAILs, there isn't an easy way to reconstruct the configure tests whether it is ok to use the affinity or not. Jakub
Re: Is testing libgomp outside of the build tree supported?
On 02/03/14 12:15, Jakub Jelinek wrote: On Mon, Feb 03, 2014 at 11:11:31AM -0800, Ian Lance Taylor wrote: On Mon, Feb 3, 2014 at 10:03 AM, Paul Pluzhnikov wrote: We test GCC without access to the build tree (we only have convenient access to install and source trees). Building libgomp.c/affinity-1.c and libgomp.c++/affinity-1.C fails in such testing, because of '#include "config.h"' which is nowhere to be found. Is that a bug? Should I open a bugzilla issue for it? If it's easy to fix then I think it should be fixed. But I don't think there should be a hard and fast rule that all GCC tests can be run without the build tree. If the presence of the build tree makes writing some tests significantly simpler, I think that is OK. If there is some effective target or similar way to limit the tests to build tree testing, then those tests probably could be guarded by that, otherwise you'll have to live with the FAILs, there isn't an easy way to reconstruct the configure tests whether it is ok to use the affinity or not. Just a note, we (Red Hat) depend on out-of-tree testing working too, so it'd be good to get this resolved. jeff
Re: PR ipa/59831 (ipa-cp devirt issues)
Hi,
this is the first half of the original fix to the PR, bit expanded in length.
The main change is simple: we now devirtualize when aggregate propagation tells
us the virtual table pointer value. This is done to prevent fold() doing it
during inliner's function saving that confuses the cgraph on disappearing
speculation edges.
The patch has grown in size because I decided to remove some of code
duplication.
I noticed we have several places where we turn generic or gimple way of
representing &vtbl+offset that is now done by vtable_pointer_value_to_vtable.
I also decided to avoid the jump through BINFO. I.e. knowing the virtual table
pointer, then turning it into BINFO and then using BINFO to lookup the virtual
table pointer and do devirtualization. For this reason I broke out
gimple_get_virt_method_for_vtable from gimple_get_virt_method_for_binfo. There
are no functional changes.
This change however produce ICE on gcc.dg/ipa/devirt3.C. This is related
to other PR on ICE for type inconsistent program (the testcase is really
undefined and we are just overactive on sanity checking). I decided to this
do this in incremental patch - I want to figure out how much we want to warn
user about inconsistencies and how much of sanity check we can keep in,
since it was incredibly useful to hammer out various latent issues in devirt
code.
Last change is in ipa-prop.c where I noticed that
determine_known_aggregate_parts still uses TREE_TYPE (TREE_TYPE
(pointer_from_gimple_code)) to determine type of aggregate passed. This is
invalid, since we skip pointer type conversions. Last July with Martin we
updated ipa-prop to use param_type determined from a declaration. We missed a
case here that prevented me from building the testcase attached that tests
that we propagate vtbl pointer in object allocated by new. new returns VOID
pointer and the function just gave up. (I use new in the testcase to be sure
that our current type based machinery won't trigger)
Bootstrapped/regtested x86_64-linux, will commit it shortly.
PR ipa/59831
* g++.dg/ipa/devirt-24.C: New testcase.
* ipa-cp.c (ipa_get_indirect_edge_target_1): Give up on
-fno-devirtualize;
Try to devirtualize by the knowledge of virtual table pointer given by
aggregate propagation.
* ipa-prop.c (try_make_edge_direct_virtual_call): Likewise.
ipa_print_node_jump_functions): Dump also offset that
is relevant for polymorphic calls.
(determine_known_aggregate_parts): Add arg_type parameter; use it
instead of determining the type from pointer type.
(ipa_compute_jump_functions_for_edge): Update call of
determine_known_aggregate_parts.
* gimple-fold.c (gimple_get_virt_method_for_vtable): Break out from ...
(gimple_get_virt_method_for_binfo): ... here; simplify using
vtable_pointer_value_to_vtable.
* gimple-fold.h (gimple_get_virt_method_for_vtable): Declare.
* ipa-devirt.c (subbinfo_with_vtable_at_offset): Turn OFFSET parameter
to unsigned HOST_WIDE_INT; Use vtable_pointer_value_to_vtable.
(vtable_pointer_value_to_vtable): Break out from ...; handle also
POINTER_PLUS_EXPR.
(vtable_pointer_value_to_binfo): ... here.
* ipa-utils.h (vtable_pointer_value_to_vtable): Declare.
Index: testsuite/g++.dg/ipa/devirt-24.C
===
--- testsuite/g++.dg/ipa/devirt-24.C(revision 0)
+++ testsuite/g++.dg/ipa/devirt-24.C(revision 0)
@@ -0,0 +1,42 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-ipa-sra -fdump-ipa-inline -fdump-ipa-cp" } */
+void pad(void);
+class A {};
+class B {
+public:
+ A &operator[](int);
+};
+class C : B {
+public:
+ virtual int m_fn1() { return 0; }
+ inline A &operator[](int p1) {
+int a;
+a = m_fn1();
+static_cast(__builtin_expect(a, 0) ?: 0);
+return B::operator[](p1);
+ }
+};
+
+int *e;
+static void sort(C &p1, C &p2) {
+ for (int i=0;; i++) {
+A c, d = p2[0];
+ pad();
+ pad();
+ pad();
+ }
+}
+
+int test ();
+
+void update_sources() {
+while (test()) {
+C f;
+C *b = new (C);
+sort(f, *b);
+ }
+}
+/* { dg-final { scan-ipa-dump-times "Discovered a virtual call to a known
target" 1 "inline" } } */
+/* { dg-final { cleanup-ipa-dump "inline" } } */
+/* { dg-final { scan-ipa-dump-times "Aggregate passed by reference" 1 "cp" }
} */
+/* { dg-final { cleanup-ipa-dump "cp" } } */
Index: ipa-cp.c
===
--- ipa-cp.c(revision 207412)
+++ ipa-cp.c(working copy)
@@ -1479,7 +1479,7 @@ ipa_get_indirect_edge_target_1 (struct c
HOST_WIDE_INT token, anc_offset;
tree otr_type;
tree t;
- tree target;
+ tree target = NULL;
if (param_index == -1
|| known_vals.length () <= (unsigned int) param_index)
@@ -1527,14 +1527,53 @@ ipa_get_indirect_edge_target_1 (struct c
return NULL_TREE;
[jit] Add a gcc_jit_object base class, exposing debug strings and contexts
Committed to branch dmalcolm/jit: Expose the debug string facility to client code, to make it easier to write client code. In doing so, it makes sense to simply expose the ultimate base class of "contextual object" as gcc_jit_object, to better express which objects are "contextual", and to support querying which context an object is within. Make similar changes to the C++ API, including the ability to use "<<" with jit objects. As well as being usable from client code, this allows for usage from within the debugger, for the C API: (gdb) call gcc_jit_object_get_debug_string ((gcc_jit_object *)rvalue) $7 = 0x610220 "R1 < R2" and for the C++ API: (gdb) call lvalue.get_debug_string () $4 = "q->discriminant" (gdb) call rvalue.get_debug_string () $5 = "q->b * q->b - (double)4 * q->a * q->c" gcc/jit/ * libgccjit.h (struct gcc_jit_object): New. (gcc_jit_object_get_context): New. (gcc_jit_object_get_debug_string): New. (gcc_jit_location_as_object): New. (gcc_jit_type_as_object): New. (gcc_jit_field_as_object): New. (gcc_jit_param_as_object): New. (gcc_jit_function_as_object): New. (gcc_jit_label_as_object): New. (gcc_jit_lvalue_as_object): New. (gcc_jit_rvalue_as_object): New. (gcc_jit_loop_as_object): New. * libgccjit.map (gcc_jit_field_as_object): New. (gcc_jit_function_as_object): New. (gcc_jit_label_as_object): New. (gcc_jit_location_as_object): New. (gcc_jit_loop_as_object): New. (gcc_jit_lvalue_as_object): New. (gcc_jit_object_get_context): New. (gcc_jit_object_get_debug_string): New. (gcc_jit_param_as_object): New. (gcc_jit_rvalue_as_object): New. (gcc_jit_type_as_object): New. * libgccjit.c (struct gcc_jit_object): New. (gcc_jit_location_as_object): New. (gcc_jit_type_as_object): New. (gcc_jit_field_as_object): New. (gcc_jit_param_as_object): New. (gcc_jit_function_as_object): New. (gcc_jit_label_as_object): New. (gcc_jit_lvalue_as_object): New. (gcc_jit_rvalue_as_object): New. (gcc_jit_object_get_context): New. (gcc_jit_object_get_debug_string): New. (gcc_jit_loop_as_object): New. * internal-api.h (gcc::jit::recording::memento::get_context): New. (gcc::jit::recording::memento::as_object): New. * libgccjit++.h: Require iostream, for std::ostream. (class object): New base class. (operator << (std::ostream& stream, const object &obj)): New. (location): Inherit from the new "object" base class. (location::m_inner_loc): Remove, in favor of... (location::get_inner_location): ...new method. (field): Inherit from the new "object" base class. (field::m_inner_field): Remove, in favor of... (field::get_inner_field): ...new method. (type): Inherit from the new "object" base class. (type::m_inner_type): Remove, in favor of... (type::get_inner_type): ...new method. (function): Inherit from the new "object" base class. (function::m_inner_func): Remove, in favor of... (function::get_inner_function): ...new method. (label): Inherit from the new "object" base class. (label::m_inner_label): Remove, in favor of... (label::get_inner_label): ...new method. (rvalue) Inherit from the new "object" base class. (rvalue::m_inner_rvalue): Remove, in favor of... (rvalue::get_inner_rvalue): ...new method. (context::new_field): Update for move of inner pointer to the "object" base class. (context::new_struct_type): Likewise. (context::new_param): Likewise. (context::new_function): Likewise. (context::new_rvalue): Likewise. (context::zero): Likewise. (context::one): Likewise. (context::new_rvalue): Likewise. (context::new_rvalue): Likewise. (context::new_unary_op): Likewise. (context::new_binary_op): Likewise. (context::new_comparison): Likewise. (context::new_call): Likewise. (object::get_debug_string): New. (object::object): New. (object::get_inner_object): New. (operator << (std::ostream&, const object &)): New. (location::location): Update for move of inner pointer to the "object" base class. (location::get_inner_location): New. (field::field): Update for move of inner pointer to the "object" base class. (field::get_inner_field): New. (type::type): Update for move of inner pointer to the "object" base class. (type::get_pointer): Likewise. (type::get_inner_type): New. (function::function): Update for move of inner pointer to the "object" base class. (function::new_forward_label): Likewise. (function::
RE: Still fails with strict-volatile-bitfields
Hi,
On Mon, 13 Jan 2014 10:26:03, Joey Ye wrote:
>
> Bernd,
>
> If that's the case, can you please firstly fix invoke.texi where the
> behavior of strict-volatile-bitfields is described? At least my
> interpretation of current doc doesn't explain the behavior of the case
> we are discussing. Also it should be a generic definition rather than
> target specific one.
>
Yes,
if nobody objects I'd add a note like this to the documentation
regarding the -fstrict-volatile-bitfields:
Index: invoke.texi
===
--- invoke.texi (revision 207223)
+++ invoke.texi (working copy)
@@ -22456,6 +22456,10 @@
case GCC falls back to generating multiple accesses rather than code that
will fault or truncate the result at run time.
+Note: Due to restrictions of the C/C++11 memory model, write accesses are
+not allowed to touch non bit-field members. It is therefore recommended
+to define all bits of the field's type as bit-field members.
+
The default value of this option is determined by the application binary
interface for the target processor.
Thanks
Bernd.
> A related issue is that how would we expect users to build their
> original code with volatile bitfields usage? From the approach I
> understand they have to explicitly add -fstrict-volatile-bitfields for
> 4.9 (by default it is disabled now), and probably
> -fstrict-volatile-bitfields=aapcs (to allow C++ memory model conflict)
> later. Neither of them are obvious to users. How about a configure
> option to set default?
>
> Thanks,
> Joey
>
> On Fri, Jan 10, 2014 at 10:20 PM, Bernd Edlinger
> wrote:
>> On Fri, 10 Jan 2014 14:45:12, Richard Biener wrote:
>>>
>>> On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger
>>> wrote:
On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
>
> On 10/01/14 08:49, Bernd Edlinger wrote:
>> On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>>>
>>> On 09/01/14 08:26, Bernd Edlinger wrote:
Hi,
On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
>
> Sandra, Bernd,
>
> Can you take a look at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734
>
> It seems a siimple case still doesn't work as expected. Did I miss
> anything?
>
> Thanks,
> Joey
Yes,
this is a major case where the C++ memory model is
in conflict with AAPCS.
>>>
>>> Does the compiler warn about this? And if so, is the warning on by
>>> default? I think it's essential that we don't have quiet changes in
>>> behaviour without such warnings.
>>>
>>> R.
>>
>> No. This example was working in 4.6 and broken in 4.7 and 4.8.
>> Well, 4.7 should have warned about that.
>>
>> 4.9 does simply not change that, because it would violate the C++
>> memory model. Maybe that should go into release notes.
>
> That's no excuse for not generating a warning at compile time when the
> situation is encountered. Users of this feature are experiencing a
> quiet change of behaviour and that's unacceptable, even if the compiler
> is doing what it was intended to do; that doesn't necessarily match the
> user's expectations. There should always be a way to rewrite the C11
> intended semantics in a way that doesn't violate the strict volatile
> bitfields semantics.
>
Hmm...
You mean we should have a (ugly) warning enabled by default in 4.9 (at
expmed.c)
if a bit-field access would be perfectly aligned and so, but is in
conflict with the
C++ memory model, and -fstrict-volatile-bitfields is in effect.
Maybe only once per compilation?
>>>
>>> I'd say you want a warning for the structure declaration instead
>>> "Accesses to XYZ will not follow AACPS due to C++ memory model
>>> constraints".
>>>
>>> Richard.
>>>
>>
>> Yes, that would be the way how we wanted to implement the
>> -Wportable-volatility warning, except that it would be on by default
>> if -fstrict-volatile-bitfields is in effect.
>> And it would not only warn if the member is declared volatile,
>> because the structure can be declared volatile later.
>>
>> Except that I did not even start to implement it that way, that
>> would be quite late for 4.9 now?
>>
>> Bernd.
>>
>> At the same time we had all kinds of invalid code generation,
>> starting at 4.6, especially with packed structures in C and Ada(!),
>> (writing not all bits, and using unaligned accesses)
>> and that is fixed in 4.9.
>>
>
> I'm not worried about packed structures. You can't sensibly implement
> the strict volatile bitfields rules when things aren't aligned.
>
> R.
>
>>
>> Bernd.
>>
>>>
You can get the expected code, by changing the struct
like this:
struct str {
volatile unsigned f1: 8;
>
Re: Is testing libgomp outside of the build tree supported?
On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo wrote: > On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote: > >> If the presence of the build >> tree makes writing some tests significantly simpler, I think that is >> OK. > > I would like to discourage that. Testing an already installed GCC for > which no build tree exists is a very useful feature. I agree. Here at Cavium, we use the packaged up toolchain that comes from a RPM and test it so we are testing exactly what we ship out to our customers. > > Internally, we have a very strong dependency on this feature. If it > were to disappear, it would be almost impossible for us to test the > compiler at the massive scale that we do. We (Cavium) have the same strong dependency too. Thanks, Andrew Pinski > > > Diego.
Re: [PATCH] fix PR58602 (.gcno files not truncated at gcov_close)
On 02/03/14 01:55, Laurent Alfonsi wrote: Jeff, All, As you suggested, I have extended my testing around this fix to prevent race condition issues. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602#c8 All my tests passed successfully. Is it ok for trunk ? Yes, thanks for running those tests. I've installed the patch on the trunk for you. Thanks again, Jeff
Re: [PATCH] Fix up cprop to canonicalize PLUS/MINUS with 2 CONSTANT_P arguments (PR rtl-optimization/57915)
On 02/01/14 02:58, Jakub Jelinek wrote: I think AND is necessary for certain variants of the Alpha. In theory a shift-add might be possible here, but I don't know if it happens in practice. Well, from what I can read in simplify-rtx.c, it only adds CONST around PLUS/MINUS, not around anything else. True. But is that the only place that creates the expressions? I'd certainly agree that PLUS is by far the most important. I've never the other forms, but those are more likely an artifact of the ports I've worked on through the years. Anyway, another variant would be (untested so far) say following patch. BTW, I wonder why each pass rolls it's own kind of simplification, e.g. fwprop has propagate_rtx_1, cprop this function, etc., while we have simplify_replace_fn_rtx that would be used perhaps with some hook that will handle special cases for each of the pass, but otherwise will take care of simplifying everything that has actually changed. But that is likely not what we want to change in stage4. Some is certainly historical. Even just unifying the simplifications in combine and simplify_rtx would be a big (but useful) change. Agreed it's not stage4 material. 2014-02-01 Jakub Jelinek PR rtl-optimization/57915 * recog.c (simplify_while_replacing): If all unary/binary/relational operation arguments are constant, attempt to simplify those. * gcc.target/i386/pr57915.c: New test. Looks good to me. Jeff
[PING][RFA][PR 16361] Add warnings for NULL pointer dereferences and such
Ping: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01715.html
Fix pr/59924
The problem with this pr is that the -uninit pass could get itself
into a loop while processing nodes. Within this loop, it would
allocate memory, therefore the visible symptom was allocation
failure instead of a non-terminating loop.
Amusingly, the case that prods the -uninit pass into this behaviour
contains an uninitialized variable.
I briefly tried to produce a reduced test case, but didn't manage
to do so. The one in the PR is a bit big to commit...
r~
* tree-ssa-uninit.c (push_to_worklist): Don't re-push if we've
already processed this node.
(normalize_one_pred_1): Pass along mark_set.
(normalize_one_pred): Create and destroy a pointer_set_t.
(normalize_one_pred_chain): Likewise.
diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index 2b55e10..71a564c 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -1821,8 +1821,13 @@ push_pred (pred_chain_union *norm_preds, pred_info pred)
OP != 0 and push it WORK_LIST. */
inline static void
-push_to_worklist (tree op, vec *work_list)
+push_to_worklist (tree op, vec *work_list,
+ pointer_set_t *mark_set)
{
+ if (pointer_set_contains (mark_set, op))
+return;
+ pointer_set_insert (mark_set, op);
+
pred_info arg_pred;
arg_pred.pred_lhs = op;
arg_pred.pred_rhs = integer_zero_node;
@@ -1905,7 +1910,8 @@ normalize_one_pred_1 (pred_chain_union *norm_preds,
pred_chain *norm_chain,
pred_info pred,
enum tree_code and_or_code,
- vec *work_list)
+ vec *work_list,
+ pointer_set_t *mark_set)
{
if (!is_neq_zero_form_p (pred))
{
@@ -1945,39 +1951,37 @@ normalize_one_pred_1 (pred_chain_union *norm_preds,
if (integer_zerop (op))
continue;
- push_to_worklist (op, work_list);
+ push_to_worklist (op, work_list, mark_set);
}
- }
- else if (gimple_code (def_stmt) != GIMPLE_ASSIGN)
- {
- if (and_or_code == BIT_IOR_EXPR)
- push_pred (norm_preds, pred);
- else
- norm_chain->safe_push (pred);
- }
- else if (gimple_assign_rhs_code (def_stmt) == and_or_code)
- {
-push_to_worklist (gimple_assign_rhs1 (def_stmt),
- work_list);
-push_to_worklist (gimple_assign_rhs2 (def_stmt),
- work_list);
- }
- else if (TREE_CODE_CLASS (gimple_assign_rhs_code (def_stmt))
-== tcc_comparison)
- {
- pred_info n_pred = get_pred_info_from_cmp (def_stmt);
- if (and_or_code == BIT_IOR_EXPR)
- push_pred (norm_preds, n_pred);
- else
- norm_chain->safe_push (n_pred);
- }
- else
- {
- if (and_or_code == BIT_IOR_EXPR)
- push_pred (norm_preds, pred);
- else
- norm_chain->safe_push (pred);
- }
+}
+ else if (gimple_code (def_stmt) != GIMPLE_ASSIGN)
+{
+ if (and_or_code == BIT_IOR_EXPR)
+ push_pred (norm_preds, pred);
+ else
+ norm_chain->safe_push (pred);
+}
+ else if (gimple_assign_rhs_code (def_stmt) == and_or_code)
+{
+ push_to_worklist (gimple_assign_rhs1 (def_stmt), work_list, mark_set);
+ push_to_worklist (gimple_assign_rhs2 (def_stmt), work_list, mark_set);
+}
+ else if (TREE_CODE_CLASS (gimple_assign_rhs_code (def_stmt))
+ == tcc_comparison)
+{
+ pred_info n_pred = get_pred_info_from_cmp (def_stmt);
+ if (and_or_code == BIT_IOR_EXPR)
+ push_pred (norm_preds, n_pred);
+ else
+ norm_chain->safe_push (n_pred);
+}
+ else
+{
+ if (and_or_code == BIT_IOR_EXPR)
+ push_pred (norm_preds, pred);
+ else
+ norm_chain->safe_push (pred);
+}
}
/* Normalize PRED and store the normalized predicates into NORM_PREDS. */
@@ -1987,6 +1991,7 @@ normalize_one_pred (pred_chain_union *norm_preds,
pred_info pred)
{
vec work_list = vNULL;
+ pointer_set_t *mark_set = NULL;
enum tree_code and_or_code = ERROR_MARK;
pred_chain norm_chain = vNULL;
@@ -2014,16 +2019,19 @@ normalize_one_pred (pred_chain_union *norm_preds,
}
work_list.safe_push (pred);
+ mark_set = pointer_set_create ();
+
while (!work_list.is_empty ())
{
pred_info a_pred = work_list.pop ();
normalize_one_pred_1 (norm_preds, &norm_chain, a_pred,
-and_or_code, &work_list);
+and_or_code, &work_list, mark_set);
}
if (and_or_code == BIT_AND_EXPR)
norm_preds->safe_push (norm_chain);
work_list.release ();
+ pointer_set_destroy (mark_set);
}
static void
@@ -2031,21 +2039,26 @@ normalize_one_pred_chain (pred_chain_union *norm_preds,
pred_chain one_chain)
{
vec work_list = vNULL;
+ pointer_set_t *mark_set = pointer_set_create ();
pred_chain norm_chain = vNULL;
size_t i;
Re: Is testing libgomp outside of the build tree supported?
On Mon, 3 Feb 2014, Andrew Pinski wrote: > On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo wrote: > > On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote: > > > >> If the presence of the build > >> tree makes writing some tests significantly simpler, I think that is > >> OK. > > > > I would like to discourage that. Testing an already installed GCC for > > which no build tree exists is a very useful feature. > > I agree. Here at Cavium, we use the packaged up toolchain that comes > from a RPM and test it so we are testing exactly what we ship out to > our customers. Similarly at Mentor. -- Joseph S. Myers jos...@codesourcery.com
Re: Fix pr/59924
On Mon, Feb 03, 2014 at 03:18:49PM -0800, Richard Henderson wrote:
> The problem with this pr is that the -uninit pass could get itself
> into a loop while processing nodes. Within this loop, it would
> allocate memory, therefore the visible symptom was allocation
> failure instead of a non-terminating loop.
>
> Amusingly, the case that prods the -uninit pass into this behaviour
> contains an uninitialized variable.
Thanks.
> I briefly tried to produce a reduced test case, but didn't manage
> to do so. The one in the PR is a bit big to commit...
I've committed a testcase for this, delta can do wonders :)
2014-02-04 Jakub Jelinek
PR tree-optimization/59924
* gcc.dg/pr59924.c: New test.
--- gcc/testsuite/gcc.dg/pr59924.c.jj 2014-02-04 01:42:43.691929830 +0100
+++ gcc/testsuite/gcc.dg/pr59924.c 2014-02-04 01:42:24.0 +0100
@@ -0,0 +1,27 @@
+/* PR tree-optimization/59924 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -Wall" } */
+
+struct S { struct T *a; double b; struct S *c; };
+struct T { struct S *d; };
+extern void bar (double);
+
+void
+foo (struct S * x, int y, int z, int w)
+{
+ int e;
+ struct S *f;
+ for (f = x->a->d; f; f = f->c)
+{
+ if (5 < w)
+ {
+ e = -w;
+ z = w;
+ }
+}
+ if (y != 0 || z != 0)
+{
+ double g = x->b + (double) e * (double) y; /* { dg-warning "may be used
uninitialized in this function" } */
+ bar (g * g);
+}
+}
Jakub
Make inliner to not ICE when folder produce unreachable
Hi,
while playing around with devirtualization I tried to make it to always produce
builtin_unreachable (). This makes early inliner to ICE, since the callgraph
edges
are not properly updated after folding. This is because
cgraph_update_edges_for_call_stmt
is called on a wrong statement.
Does something like this look resonable?
Honza
* tree-inline.c (fold_marked_statements): Correctly handle cases where
folding produes extra statement.
Index: tree-inline.c
===
--- tree-inline.c (revision 207438)
+++ tree-inline.c (working copy)
@@ -4480,8 +4480,14 @@ fold_marked_statements (int first, struc
if (pointer_set_contains (statements, gsi_stmt (gsi)))
{
gimple old_stmt = gsi_stmt (gsi);
+ gimple_stmt_iterator prev = gsi;
+ gimple prev_stmt = NULL;
tree old_decl = is_gimple_call (old_stmt) ? gimple_call_fndecl
(old_stmt) : 0;
+ gsi_prev (&prev);
+ if (!gsi_end_p (prev))
+ prev_stmt = gsi_stmt (prev);
+
if (old_decl && DECL_BUILT_IN (old_decl))
{
/* Folding builtins can create multiple instructions,
@@ -4541,8 +4547,31 @@ fold_marked_statements (int first, struc
if (is_gimple_call (old_stmt)
|| is_gimple_call (new_stmt))
- cgraph_update_edges_for_call_stmt (old_stmt, old_decl,
- new_stmt);
+ {
+ if (!is_gimple_call (new_stmt))
+ {
+ prev = gsi;
+ gsi_prev (&prev);
+
+ /* Fold stmt may turn
+
+retval = call ();
+
+statement into
+
+__builtin_unreachable ();
+retval = dummy.
+
+Be sure to look up the call. */
+
+ if (!gsi_end_p (prev)
+ && gsi_stmt (prev) != prev_stmt
+ && is_gimple_call (gsi_stmt (prev)))
+new_stmt = gsi_stmt (prev);
+ }
+ cgraph_update_edges_for_call_stmt (old_stmt, old_decl,
+new_stmt);
+ }
if (maybe_clean_or_replace_eh_stmt (old_stmt, new_stmt))
gimple_purge_dead_eh_edges (BASIC_BLOCK_FOR_FN (cfun,
Re: Allow passing arrays in registers on AArch64
Ping? I'm attaching a marginally cleaner version of the test. I've had
a look at integrating this into aapcs64.exp but got defeated in the
end. If go-torture-execute took a list of sources as c-torture-execute
does, then I think adding something like this to aapcs64.exp would work:
# Test passing arrays by value
set src $srcdir/$subdir/test_array.go
if {[runtest_file_p $runtests $src]} {
go-torture-execute [list $src $srcdir/$subdir/abitest.S
$srcdir/$subdir/_test_array_c.c] \
$additional_flags
}
but it doesn't. I also think that some stuff needs to be set up before
go-torture-execute can be called that I don't really understand and I
also also don't know how to avoid executing this test if gccgo hasn't
been built.
All that said, is there any chance of getting the original ABI fix
committed? It would be nice to have it in 4.9.
Cheers,
mwh
Michael Hudson-Doyle writes:
> Richard Earnshaw writes:
>
>> On 17/01/14 23:56, Michael Hudson-Doyle wrote:
>>> Ian Lance Taylor writes:
>>>
On Fri, Jan 17, 2014 at 11:32 AM, Michael Hudson-Doyle
wrote:
>
> On 18 Jan 2014 07:50, "Yufeng Zhang" wrote:
>>
>> Also can you please try to add some new test(s)? It may not be that
>> straightforward to add non-C/C++ tests, but give it a try.
>
> Can you give some hints? Like at least where in the tree such a test would
> go? I don't know this code at all.
There is already a test in libgo, of course.
I think it would be pretty hard to write a test that doesn't something
like what libgo does. The problem is that GCC is entirely consistent
with and without your patch. You could add a Go test that passes an
array in gcc/testsuite/go.go-torture/execute/ easily enough, but it
would be quite hard to add a test that doesn't pass whether or not
your patch is applied.
>>>
>>> I think it would have to be a code generation test, i.e. that compiling
>>> something like
>>>
>>> func second(e [2]int64) int64 {
>>> return e[1]
>>> }
>>>
>>> does not access memory or something along those lines. I'll have a look
>>> next week.
>>>
>>> Cheers,
>>> mwh
>>>
>>
>> Michael,
>>
>> Can you have a look at how the tests in gcc.target/aarch64/aapcs64 work;
>> it ought to be possible to write a test (though not in C) to catch this.
>
> Yeah, I had found those tests. It would be much easier if I could write
> this in C :-)
>
>> The tests work by calling a wrapper function written in assembler --
>> that wrapper stores out all the registers used for parameter passing and
>> then calls back into the test's validator with the register dump
>> available. Code can then check that values are passed in the places
>> expected. This gives the compiler the separation between caller and
>> callee that's needed to test this feature.
>
> Right, that much makes sense. I'm not sure I completely understand all
> the preprocessor trickery involved but the output of it seems clear
> enough.
>
>> My preferred languages for these tests would be (in approximate order)
>> c, c++, fortran, java, ada, go. That order is based on which languages
>> are tested most by users.
>
> Well of course it cannot be done in C or C++. A commenter on the PR
> said that while fortran does allow passing arrays by value, it's all
> handled in the frontend. No idea about Java. Ada has arrays by value
> but I don't know it even slightly. So it's the last one on your list
> but here's a diff that adds hack at a test in Go:
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.S
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.S
> index 86ce7be..365cd91 100644
> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.S
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.S
> @@ -1,9 +1,12 @@
> .global dumpregs
> .global myfunc
> + .global main.myfunc
> .type dumpregs,%function
> .type myfunc,%function
> + .type main.myfunc,%function
> dumpregs:
> myfunc:
> +main.myfunc:
>movx16, sp
>movx17, sp
>subsp, sp, 352 // 336 for registers and 16 for old sp and lr
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_array.go
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_array.go
> new file mode 100644
> index 000..b5e90e4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_array.go
> @@ -0,0 +1,9 @@
> +package main
> +
> +func myfunc(e [2]int64)
> +
> +func main() {
> + myfunc([2]int64{40, 50})
> +}
> +
> +
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_array.sh
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_array.sh
> new file mode 100755
> index 000..0b3202d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_array.sh
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +GCC=${GCC:-gcc}
> +AARCH64HOST=${AARCH64HOST:-localhost}
> +
> +set -x
> +
> +${GCC}go -g -c test_array.go -o test_array.o
> +${GCC} -g -c abitest.S -o abi
Re: Is testing libgomp outside of the build tree supported?
On Feb 3, 2014, at 3:52 PM, Joseph S. Myers wrote: > On Mon, 3 Feb 2014, Andrew Pinski wrote: >> On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo wrote: >>> On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote: >>> If the presence of the build tree makes writing some tests significantly simpler, I think that is OK. >>> >>> I would like to discourage that. Testing an already installed GCC for >>> which no build tree exists is a very useful feature. >> >> I agree. Here at Cavium, we use the packaged up toolchain that comes >> from a RPM and test it so we are testing exactly what we ship out to >> our customers. > > Similarly at Mentor. And the maintainer of the test suite thinks that supporting the people that ship gcc to large numbers of people who help ensure the quality of gcc is useful. :-) It is nice to hear from people that this type of testing is useful; thanks.
[PATCH][PING^2] Fix for PR59600 (prohibit inlining if no_sanitize_address)
Original Message
Subject: [PATCH][PING] Fix for PR59600 (prohibit inlining if
no_sanitize_address)
Date: Tue, 28 Jan 2014 09:13:10 +0400
From: Yury Gribov
To: GCC Patches
Original Message
Subject: [PATCH] Fix for PR59600
Date: Tue, 21 Jan 2014 14:42:31 +0400
From: Yury Gribov
To: GCC Patches
Hi,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 : functions with
mismatching no_sanitize_address attributes should not be considered for
inlining, otherwise the meaning of no_sanitize_address will not be
preserved.
I didn't get feedback in Bugzilla so I'm sending the patch here.
Bootstrapped/regtested on x64.
-Y
gcc/ChangeLog:
2014-01-21 ygribov
* cif-code.def (OPTION_MISMATCH): New CIF code.
* ipa-inline.c (report_inline_failed_reason): Handle mismatched
sanitization attributes.
(sanitize_attrs_match_for_inline_p): New function.
(can_inline_edge_p): Likewise.
gcc/testsuite/ChangeLog:
2014-01-21 ygribov
* gcc.dg/asan/nosanitize-and-inline.c: : New test.
diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index f1df5a0..1418f8e 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -109,3 +109,6 @@ DEFCIFCODE(OPTIMIZATION_MISMATCH, N_("optimization level attribute mismatch"))
/* We can't inline because the callee refers to comdat-local symbols. */
DEFCIFCODE(USES_COMDAT_LOCAL, N_("callee refers to comdat-local symbols"))
+
+/* We can't inline because of mismatched options. */
+DEFCIFCODE(OPTION_MISMATCH, N_("option mismatch"))
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 12ee84c..9118561 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -234,7 +234,25 @@ report_inline_failed_reason (struct cgraph_edge *e)
}
}
-/* Decide if we can inline the edge and possibly update
+ /* Decide whether sanitizer-related attributes allow inlining. */
+
+static bool
+sanitize_attrs_match_for_inline_p (const_tree caller, const_tree callee)
+{
+ /* Don't care if sanitizer is disabled */
+ if (!(flag_sanitize & SANITIZE_ADDRESS))
+return true;
+
+ if (!caller || !callee)
+return true;
+
+ return lookup_attribute ("no_sanitize_address",
+ DECL_ATTRIBUTES (caller)) ==
+lookup_attribute ("no_sanitize_address",
+ DECL_ATTRIBUTES (callee));
+}
+
+ /* Decide if we can inline the edge and possibly update
inline_failed reason.
We check whether inlining is possible at all and whether
caller growth limits allow doing so.
@@ -327,6 +345,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
e->inline_failed = CIF_TARGET_OPTION_MISMATCH;
inlinable = false;
}
+ /* Don't inline a function with mismatched sanitization attributes. */
+ else if (!sanitize_attrs_match_for_inline_p (e->caller->decl, callee->decl))
+{
+ e->inline_failed = CIF_OPTION_MISMATCH;
+ inlinable = false;
+}
/* Check if caller growth allows the inlining. */
else if (!DECL_DISREGARD_INLINE_LIMITS (callee->decl)
&& !disregard_limits
diff --git a/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c b/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c
index e69de29..5853801 100644
--- a/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c
+++ b/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c
@@ -0,0 +1,57 @@
+/* { dg-do run } */
+
+/* This is a simplified version of what Emacs does internally,
+ when marking its stack. */
+
+static unsigned long sum;
+static void *stack_base;
+
+/* A simple substitute for what Emacs actually does. */
+static void
+mark_maybe_pointer (void *p)
+{
+ sum ^= (unsigned long) p;
+}
+
+static inline void __attribute__ ((no_sanitize_address))
+mark_memory (void **start, void **end)
+{
+ void **pp;
+
+ if (end < start)
+{
+ void **tem = start;
+ start = end;
+ end = tem;
+}
+
+ for (pp = start; pp < end; pp++)
+{
+ /* This is the dereference that we don't want sanitized. */
+ void *p = *pp;
+
+ mark_maybe_pointer (p);
+}
+}
+
+static void
+mark_stack (void)
+{
+ void *end;
+ mark_memory (stack_base, &end);
+}
+
+void
+garbage_collect (void)
+{
+ mark_stack ();
+}
+
+int
+main (void)
+{
+ void *dummy;
+ stack_base = &dummy;
+ garbage_collect ();
+ return 0;
+}
Re: PR ipa/59831 (ipa-cp devirt issues)
Hi,
this patch solves the actual ICE in PR59831 by using ipa-devirt instead of
gimple_extract_devirt_binfo_from_cst as discussed in the first post.
Honza
PR ipa/59831
* ipa-cp.c (ipa_get_indirect_edge_target_1): Use ipa-devirt
to figure out targets of polymorphic calls with known decl.
* ipa-prop.c (try_make_edge_direct_virtual_call): Likewise.
* ipa-utils.h (get_polymorphic_call_info_from_invariant): Declare.
* ipa-devirt.c (get_polymorphic_call_info_for_decl): Break out from ...
(get_polymorphic_call_info): ... here.
(get_polymorphic_call_info_from_invariant): New function.
* g++.dg/ipa/devirt-22.C: New testcase.
Index: ipa-cp.c
===
--- ipa-cp.c(revision 207447)
+++ ipa-cp.c(working copy)
@@ -1601,15 +1601,24 @@ ipa_get_indirect_edge_target_1 (struct c
if (TREE_CODE (t) != TREE_BINFO)
{
- tree binfo;
- binfo = gimple_extract_devirt_binfo_from_cst
-(t, ie->indirect_info->otr_type);
- if (!binfo)
+ ipa_polymorphic_call_context context;
+ vec targets;
+ bool final;
+
+ if (!get_polymorphic_call_info_from_invariant
+(&context, t, ie->indirect_info->otr_type,
+ anc_offset))
return NULL_TREE;
- binfo = get_binfo_at_offset (binfo, anc_offset, otr_type);
- if (!binfo)
+ targets = possible_polymorphic_call_targets
+(ie->indirect_info->otr_type,
+ ie->indirect_info->otr_token,
+ context, &final);
+ if (!final || targets.length () > 1)
return NULL_TREE;
- target = gimple_get_virt_method_for_binfo (token, binfo);
+ if (targets.length () == 1)
+ target = targets[0]->decl;
+ else
+ target = builtin_decl_implicit (BUILT_IN_UNREACHABLE);
}
else
{
Index: testsuite/g++.dg/ipa/devirt-22.C
===
--- testsuite/g++.dg/ipa/devirt-22.C(revision 0)
+++ testsuite/g++.dg/ipa/devirt-22.C(revision 0)
@@ -0,0 +1,41 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-early-inlining -fno-ipa-sra -fdump-ipa-cp" } */
+class A {};
+class B {
+public:
+ A &operator[](int);
+};
+class C : B {
+public:
+ virtual int m_fn1() { return 0; }
+ A &operator[](int p1) {
+int a;
+a = m_fn1();
+static_cast(__builtin_expect(a, 0) ?: 0);
+return B::operator[](p1);
+ }
+};
+
+C b;
+int *e;
+static void sort(C &p1, C &p2) {
+ for (int i=0;; i++) {
+A c, d = p2[0];
+p1[0] = c;
+p2[0] = d;
+ }
+}
+
+void lookupSourceDone() { b[0]; }
+
+void update_sources() {
+ if (e) {
+C f;
+sort(f, b);
+ }
+}
+/* Note that we miss one devirtualization because we are not able to track the
+ vtbl store in destructor.
+ Previously we devirtualized to C::m_fn1 instead of B::m_fn1. */
+/* { dg-final { scan-tree-dump-times "Discovered a virtual call to a known
target" 1 "cp" } } */
+/* { dg-final { cleanup-ipa-dump "cp" } } */
Index: ipa-utils.h
===
--- ipa-utils.h (revision 207439)
+++ ipa-utils.h (working copy)
@@ -87,6 +87,8 @@ tree method_class_type (tree);
tree get_polymorphic_call_info (tree, tree, tree *,
HOST_WIDE_INT *,
ipa_polymorphic_call_context *);
+bool get_polymorphic_call_info_from_invariant (ipa_polymorphic_call_context *,
+ tree, tree, HOST_WIDE_INT);
tree vtable_pointer_value_to_binfo (tree t);
bool vtable_pointer_value_to_vtable (tree, tree *, unsigned HOST_WIDE_INT *);
Index: ipa-prop.c
===
--- ipa-prop.c (revision 207447)
+++ ipa-prop.c (working copy)
@@ -2731,19 +2731,38 @@ try_make_edge_direct_virtual_call (struc
if (TREE_CODE (binfo) != TREE_BINFO)
{
- binfo = gimple_extract_devirt_binfo_from_cst
-(binfo, ie->indirect_info->otr_type);
- if (!binfo)
+ ipa_polymorphic_call_context context;
+ vec targets;
+ bool final;
+
+ if (!get_polymorphic_call_info_from_invariant
+(&context, binfo, ie->indirect_info->otr_type,
+ ie->indirect_info->offset))
+ return NULL;
+ targets = possible_polymorphic_call_targets
+(ie->indirect_info->otr_type,
+ ie->indirect_info->otr_token,
+ context, &final);
+ if (!final || targets.length () > 1)
return NULL;
+ if (targets.length () == 1)
+ target = targets[0]->decl;
+ else
+ {
+ target = builtin_decl_implicit (BUILT_IN_UNREACHABLE);
+ cgraph_get_create_node (target);
+ }
}
-
- binfo = get_binfo_at_offset (binfo, ie->indirect_info->offset,
- ie->indirect_info->otr_type);
- if (binfo)
-
Properly merge forced_by_abi when merging nodes
Hi,
while merging nodes in lto-symtab, we need to copy the force_output and
forced_by_abi flags.
Thanks to Markus who noticed the issue.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 207438)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2014-02-04 Jan Hubicka
+ Markus Trippelsdorf
+
+ * lto-symtab.c (lto_cgraph_replace_node, lto_varpool_replace_node):
+ merge force_output and forced_by_abi flags.
+
2014-01-24 Balaji V. Iyer
* lto-lang.c (lto_init): Replaced flag_enable_cilkplus with
Index: lto-symtab.c
===
--- lto-symtab.c(revision 207438)
+++ lto-symtab.c(working copy)
@@ -59,6 +59,8 @@ lto_cgraph_replace_node (struct cgraph_n
/* Merge node flags. */
if (node->force_output)
cgraph_mark_force_output_node (prevailing_node);
+ if (node->forced_by_abi)
+prevailing_node->forced_by_abi = true;
if (node->address_taken)
{
gcc_assert (!prevailing_node->global.inlined_to);
@@ -110,6 +112,10 @@ lto_varpool_replace_node (varpool_node *
gcc_assert (!vnode->analyzed || prevailing_node->analyzed);
ipa_clone_referring (prevailing_node, &vnode->ref_list);
+ if (vnode->force_output)
+prevailing_node->force_output = true;
+ if (vnode->forced_by_abi)
+prevailing_node->forced_by_abi = true;
/* Be sure we can garbage collect the initializer. */
if (DECL_INITIAL (vnode->decl)
Allow references to symbols with user specified DEFAULT bisibility
Hi, while implementing checks in can_refer_decl_in_current_unit_p I had primarily symbols with HIDDEN visibility in mind. I just noticed that libstdc++ makes quite few symbols with default visbility specified by hand. I see no reason for disabling optimization here. Bootstrapped/regtested x86_64-linux, OK? * gimple-fold.c (can_refer_decl_in_current_unit_p): Allow references to symbols with user specified default visibility. Index: gimple-fold.c === --- gimple-fold.c (revision 207450) +++ gimple-fold.c (working copy) @@ -114,6 +114,7 @@ can_refer_decl_in_current_unit_p (tree d unit may be in separate DSO and the symbol may be hidden. */ if (DECL_VISIBILITY_SPECIFIED (decl) && DECL_EXTERNAL (decl) + && DECL_VISIBILITY (decl) != VISIBILITY_DEFAULT && (!(snode = symtab_get_node (decl)) || !snode->in_other_partition)) return false; /* When function is public, we always can introduce new reference.
PR ipa/59882
Hi,
this patch fixes two bugs I introducedinto get_binfo_at_offset in the previous
changes.
First BINFO_OFFSET is pointer to INTEGER_CST and not integer as the code
assumes.
Second the code gets confused by presence of empty classes (such as in
testcase) that
may interpose with non-empty.
I fixed it by looking only into basses with virtual table.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
PR ipa/59882
* tree.c (get_binfo_at_offset): Do not get confused by empty classes;
* g++.dg/torture/pr59882.C: New testcase
Index: tree.c
===
--- tree.c (revision 207438)
+++ tree.c (working copy)
@@ -12005,10 +12005,15 @@ get_binfo_at_offset (tree binfo, HOST_WI
break;
}
else
- if (BINFO_OFFSET (base_binfo) - BINFO_OFFSET (binfo) < pos
+ if ((tree_to_shwi (BINFO_OFFSET (base_binfo))
+ - tree_to_shwi (BINFO_OFFSET (binfo)))
+ * BITS_PER_UNIT < pos
+ /* Rule out types with no virtual methods or we can get
confused
+here by zero sized bases. */
+ && BINFO_VTABLE (TYPE_BINFO (BINFO_TYPE (base_binfo)))
&& (!containing_binfo
- || (BINFO_OFFSET (containing_binfo)
- < BINFO_OFFSET (base_binfo
+ || (tree_to_shwi (BINFO_OFFSET (containing_binfo))
+ < tree_to_shwi (BINFO_OFFSET (base_binfo)
containing_binfo = base_binfo;
if (found_binfo)
{
Index: testsuite/g++.dg/torture/pr59882.C
===
--- testsuite/g++.dg/torture/pr59882.C (revision 0)
+++ testsuite/g++.dg/torture/pr59882.C (revision 0)
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+class A;
+class B {};
+struct C {
+ virtual void dispatch();
+ int traversal_map_;
+};
+template class F : public virtual C {};
+
+struct I : F, F {};
+struct J : B, I {};
+class D {};
+struct L {
+ L(D &, int &p2) : map_(p2) {}
+ virtual void traverse(int &p1) {
+int &s = p1;
+names(s, names_);
+ }
+ int &map_;
+ J names_;
+ template void names(int &, C &p2) { p2.dispatch(); }
+};
+
+struct G : D {
+ G(D &, int &p2) : map_(p2) { L(*this, map_); }
+ int &map_;
+};
+
+int a;
+void fn1(D &p1) { G(p1, a); }
[PATCH] Handle older glibc versions in ThreadDescriptorSize (PR sanitizer/60038)
Hi!
As discussed in the PR, this patch hardcodes more sizeof (thread)
sizes for various glibc versions and checks at runtime which one to use.
While I don't like the hardcoding at all and Kostya is asking for some glibc
API to query it, having hardcoded values that are just wrong is worse than
this. The patch has been committed today to compiler-rt SVN, this is just a
backport of it, committed to trunk.
2014-02-04 Jakub Jelinek
PR sanitizer/60038
* sanitizer_common/sanitizer_linux_libcdep.cc: Include
sanitizer_atomic.h and unistd.h.
(kThreadDescriptorSize): Made static, remove initializer and const,
change type to atomic_uintptr_t.
(ThreadDescriptorSize): Use confstr(_CS_GNU_LIBC_VERSION, ...) to
query glibc version, compute kThreadDescriptorSize depending on
glibc version minor number.
(GetThreadStackAndTls): Use ThreadDescriptorSize() instead of
kThreadDescriptorSize directly.
--- libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc2014/02/04
01:28:36 200732
+++ libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc2014/02/04
04:09:38 200733
@@ -19,6 +19,7 @@
#include "sanitizer_placement_new.h"
#include "sanitizer_procmaps.h"
#include "sanitizer_stacktrace.h"
+#include "sanitizer_atomic.h"
#include
#include
@@ -29,6 +30,7 @@
#if !SANITIZER_ANDROID
#include
#include
+#include
#endif
// This function is defined elsewhere if we intercepted pthread_attr_getstack.
@@ -205,16 +207,41 @@ uptr GetTlsSize() {
#if defined(__x86_64__) || defined(__i386__)
// sizeof(struct thread) from glibc.
-// There has been a report of this being different on glibc 2.11 and 2.13. We
-// don't know when this change happened, so 2.14 is a conservative estimate.
-#if __GLIBC_PREREQ(2, 14)
-const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1216, 2304);
-#else
-const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304);
-#endif
+static atomic_uintptr_t kThreadDescriptorSize;
uptr ThreadDescriptorSize() {
- return kThreadDescriptorSize;
+ char buf[64];
+ uptr val = atomic_load(&kThreadDescriptorSize, memory_order_relaxed);
+ if (val)
+return val;
+#ifdef _CS_GNU_LIBC_VERSION
+ uptr len = confstr(_CS_GNU_LIBC_VERSION, buf, sizeof(buf));
+ if (len < sizeof(buf) && internal_strncmp(buf, "glibc 2.", 8) == 0) {
+char *end;
+int minor = internal_simple_strtoll(buf + 8, &end, 10);
+if (end != buf + 8 && (*end == '\0' || *end == '.')) {
+ /* sizeof(struct thread) values from various glibc versions. */
+ if (minor <= 3)
+val = FIRST_32_SECOND_64(1104, 1696);
+ else if (minor == 4)
+val = FIRST_32_SECOND_64(1120, 1728);
+ else if (minor == 5)
+val = FIRST_32_SECOND_64(1136, 1728);
+ else if (minor <= 9)
+val = FIRST_32_SECOND_64(1136, 1712);
+ else if (minor == 10)
+val = FIRST_32_SECOND_64(1168, 1776);
+ else if (minor <= 12)
+val = FIRST_32_SECOND_64(1168, 2288);
+ else
+val = FIRST_32_SECOND_64(1216, 2304);
+}
+if (val)
+ atomic_store(&kThreadDescriptorSize, val, memory_order_relaxed);
+return val;
+ }
+#endif
+ return 0;
}
// The offset at which pointer to self is located in the thread descriptor.
@@ -242,7 +269,7 @@ void GetThreadStackAndTls(bool main, upt
*tls_addr = ThreadSelf();
*tls_size = GetTlsSize();
*tls_addr -= *tls_size;
- *tls_addr += kThreadDescriptorSize;
+ *tls_addr += ThreadDescriptorSize();
#else
*tls_addr = 0;
*tls_size = 0;
Jakub
