Re: front-page news rotation policy?
On 07/29/2018 04:28 PM, Gerald Pfeifer wrote: Hi Sandra, On Sun, 29 Jul 2018, Sandra Loosemore wrote: Gerald, do we have a policy on when to rotate the News items on the main GCC web page to the "Older news" page? Joseph asked me to post a patch for adding a news item for the proposed new C-SKY port, but the items that are there now seem somewhat bit-rotten (e.g., referring to last year's Cauldron in the future tense and no link for this year's event) that is a good question and also a fair observation that I've fallen behind on rotating the news recently. Let me try to address two birds with one stone, by means of the patch below which (a) adds a note on rotating news to index.html and (b) does a bit of rotation, and which I just applied. Hope this makes sense and addresses your question? (Modulo my typo.) independently of anything to do with C-SKY. Of course I can fix that too (with a separate patch), given some hint about whether/how much pruning is considered appropriate. That would be lovely, thank you! OK, done with the attached patch (also fixed the typo). -Sandra ? htdocs/index.html.~1.1089.~ Index: htdocs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.1089 diff -r1.1089 index.html 48c48 < become longer than the paralle one, whatever happens first. --- > become longer than the parallel one, whatever happens first. 54a55,58 > https://gcc.gnu.org/wiki/cauldron2018;>GNU Tools Cauldron 2018 > [2018-07-29] > Will be held in Manchester, September 7-9 2018 > 81c85 < Will be held in Prague, September 8-10 2017 --- > Held in Prague, September 8-10 2017
Re: [PATCH] Fix wrong code with truncated string literals (PR 86711/86714)
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C.
If by valid you are referring to declarations like the one in
the added test:
const char a[2][3] = { "1234", "xyz" };
then (as I explained), the excess elements in "1234" make
the char[3] initialization and thus the test case undefined.
I have resolved bug 86711 as invalid on those grounds.
Bug 86711 has a valid test case that needs to be fixed, along
with bug 86688 that I raised for the same underlying problem:
considering the excess nul as part of the string. As has been
discussed in a separate bug, rather than working around
the excessively long strings in the middle-end, it would be
preferable to avoid creating them to begin with.
I'm already working on a fix for bug 86688, in part because
I introduced the code change and also because I'm making other
changes in this area -- bug 86552. Both of these in response
to your comments.
I would normally welcome someone else helping with my work
but (as I already made clear last week) it's counteproductive
to have two people working in the very same area at the same
time, especially when they are working at cross purposes as
you seem to be hell-bent on doing.
I have xfailed strlenopt-49.c, which tests this feature.
That's not appropriate. The purpose of the test is to verify
the fix for bug 86428: namely, that a call to strlen() on
an array initialized with a string of the same length is
folded, such as in:
const char b[4] = "123\0";
That's a valid initializer that can and should continue to be
folded. The test needs to continue to exercise that feature.
The test also happens to exercise invalid/overlong initializers.
This is because that, in my view, it's safer to fold the result
of such calls to a constant than than to call the library
function and have it either return an unpredictable value or
perhaps even crash.
Personally I don't think that it is worth the effort to
optimize something that is per se invalid in C++.
This is a C test, not C++. (I don't suppose you are actually
saying that only the common subset between C and C++ is worth
optimizing.)
Just in case it isn't clear from the above: the point of
the test exercising the behavior for overlong strings isn't
optimizing undefined behavior but rather avoiding the worst
consequences of it. I have already explained this once
before so I'm starting to wonder if I'm being insufficiently
clear or if you are not receiving or reading (or understanding)
my responses. We can have a broader discussion about whether
this is the best approach for GCC to take either in this instance
or in general, but in the meantime I would appreciate it if you
refrained from undoing my changes just because you don't agree
with or don't understand the motivation behind them.
Martin
PS I continue to wonder about your motivation and ethics. It's
rare to have someone so openly, blatantly and persistently try
to undermine someone else's work.
Re: front-page news rotation policy?
Hi Sandra, On Sun, 29 Jul 2018, Sandra Loosemore wrote: > Gerald, do we have a policy on when to rotate the News items on the main > GCC web page to the "Older news" page? Joseph asked me to post a patch > for adding a news item for the proposed new C-SKY port, but the items > that are there now seem somewhat bit-rotten (e.g., referring to last > year's Cauldron in the future tense and no link for this year's event) that is a good question and also a fair observation that I've fallen behind on rotating the news recently. Let me try to address two birds with one stone, by means of the patch below which (a) adds a note on rotating news to index.html and (b) does a bit of rotation, and which I just applied. Hope this makes sense and addresses your question? (Modulo my typo.) > independently of anything to do with C-SKY. Of course I can fix that > too (with a separate patch), given some hint about whether/how much > pruning is considered appropriate. That would be lovely, thank you! Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.1088 diff -u -r1.1088 index.html --- index.html 26 Jul 2018 10:40:16 - 1.1088 +++ index.html 29 Jul 2018 22:23:29 - @@ -43,6 +43,11 @@ + + News @@ -79,33 +84,6 @@ [2017-05-24] ...instead of bzip2. -GCC 7.1 released -[2017-05-02] - - -GNU Toolchain Fund - [2017-03-09] - A fund under the auspices of the Free Software Foundation specifically to benefit the components of the GNU Toolchain (GCC, GDB, GLIBC, Binutils, etc.) now https://www.fsf.org/news/gnu-toolchain-now-accepting-donations-with-the-support-of-the-free-software-foundation;>accepting donations. - -RISC-V support - [2017-02-02] - Support for the https://riscv.org;>RISC-V ISA was added, contributed by Palmer Dabbelt and Andrew Waterman. - -BRIG/HSAIL (Heterogeneous Systems Architecture Intermediate Language) front end added - [2017-02-01] - http://www.hsafoundation.com/;> Heterogeneous Systems - Architecture 1.0 BRIG (HSAIL) - front end was added to GCC, - enabling HSAIL finalization for gcc-supported - targets. The code was developed by - http://parmance.com;>Parmance with sponsorship from - https://www.generalprocessortech.com;>General Processor Technologies. - -Fuchsia OS support - [2017-01-10] - https://fuchsia.googlesource.com/;>Fuchsia OS - support was added to GCC, contributed by Google. - Index: news.html === RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v retrieving revision 1.161 diff -u -r1.161 news.html --- news.html 2 Jun 2018 21:16:10 - 1.161 +++ news.html 29 Jul 2018 22:23:29 - @@ -15,6 +15,33 @@ +GCC 7.1 released +[2017-05-02] + + +GNU Toolchain Fund + [2017-03-09] + A fund under the auspices of the Free Software Foundation specifically to benefit the components of the GNU Toolchain (GCC, GDB, GLIBC, Binutils, etc.) now https://www.fsf.org/news/gnu-toolchain-now-accepting-donations-with-the-support-of-the-free-software-foundation;>accepting donations. + +RISC-V support + [2017-02-02] + Support for the https://riscv.org;>RISC-V ISA was added, contributed by Palmer Dabbelt and Andrew Waterman. + +BRIG/HSAIL (Heterogeneous Systems Architecture Intermediate Language) front end added + [2017-02-01] + http://www.hsafoundation.com/;> Heterogeneous Systems + Architecture 1.0 BRIG (HSAIL) + front end was added to GCC, + enabling HSAIL finalization for gcc-supported + targets. The code was developed by + http://parmance.com;>Parmance with sponsorship from + https://www.generalprocessortech.com;>General Processor Technologies. + +Fuchsia OS support + [2017-01-10] + https://fuchsia.googlesource.com/;>Fuchsia OS + support was added to GCC, contributed by Google. + GCC 6.3 released [2016-12-21]
front-page news rotation policy?
Gerald, do we have a policy on when to rotate the News items on the main GCC web page to the "Older news" page? Joseph asked me to post a patch for adding a news item for the proposed new C-SKY port, but the items that are there now seem somewhat bit-rotten (e.g., referring to last year's Cauldron in the future tense and no link for this year's event) independently of anything to do with C-SKY. Of course I can fix that too (with a separate patch), given some hint about whether/how much pruning is considered appropriate. -Sandra
[wwwdocs] Replace by id= attributes in all of projects/
...and avoid a few that weren't referenced. This is the next step in cleaning up and simplifying our pages for a transition to the (simpler) HTML 5. Applied; and below a follow-up patch since a few idosyncracies escaped my own verification. Gerald Index: projects/ast-optimizer.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/ast-optimizer.html,v retrieving revision 1.10 diff -u -r1.10 ast-optimizer.html --- projects/ast-optimizer.html 2 Jun 2018 21:16:20 - 1.10 +++ projects/ast-optimizer.html 12 Jul 2018 23:26:41 - @@ -91,7 +91,7 @@ See https://gcc.gnu.org/ml/gcc-patches/2001-07/msg00859.html;>this thread. -SSA for trees +SSA for trees The tree SSA infrastructure is maintained by mailto:dnovi...@redhat.com;>Diego Novillo Index: projects/cfg.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfg.html,v retrieving revision 1.25 diff -u -r1.25 cfg.html --- projects/cfg.html 2 Jun 2018 21:16:20 - 1.25 +++ projects/cfg.html 12 Jul 2018 23:26:42 - @@ -114,7 +114,7 @@ algorithms and keep code size under control. The purpose of this pass is to minimize the number of branches and cache misses. It uses code duplication to avoid jumps. A trivial example is copying the return -instruction instead of jumping to it. See [6] for a +instruction instead of jumping to it. See [6] for a detailed description. Implementation in GCC @@ -356,7 +356,7 @@ Implementation in GCC We plan to do loop peeling and superblock formation in single pass -as described in [3]. +as described in [3]. Enhancements that are currently only in the cfg-branch: @@ -404,7 +404,7 @@ look like a real file format. There are a few references to much more advanced profiling systems -in [3]. +in [3]. This is done using NOTE_INSN_PREDICTION emitted in the stream converted to REG_PREDICTION later. For instance, @@ -450,55 +450,55 @@ homepage. Some other papers: -[1] +[1] https://doi.org/10.1145/155090.155119;>Branch Prediction for Free; Ball and Larus; PLDI '93. -[2] +[2] https://doi.org/10.1145/192724.192725;>Static Branch Frequency and Program Profile Analysis; Wu and Larus; MICRO-27. -[3] +[3] Design and Analysis of Profile-Based Optimization in Compaq's Compilation Tools for Alpha; Journal of Instruction-Level Parallelism 3 (2000) 1-25. -[4] +[4] http://www.lighterra.com/papers/valuerangeprop/Patterson1995-ValueRangeProp.pdf;>Accurate Static Branch Prediction by Value Range Propagation; Jason R. C. Patterson (jas...@fit.qut.edu.au), 1995 -[5] +[5] https://doi.org/10.1145/258916.258932;>Near-optimal Intraprocedural Branch Alignment; Cliff Young, David S. Johnson, David R. Karger, Michael D. Smith, ACM 1997 -[6] +[6] https://doi.org/10.1145/305138.305178;>Software Trace Cache; International Conference on Supercomputing, 1999 -[7] +[7] https://doi.org/10.1002/spe.4380211204;>Using Profile Information to Assist Classic Code Optimizations; Pohua P. Chang, Scott A. Mahlke, and Wen-mei W. Hwu, 1991 -[8] +[8] http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.1922;>Hyperblock Performance Optimizations For ILP Processors; David Isaac August, 1996 (Master Thesis) -[9] +[9] https://doi.org/10.1145/173262.155118;>Reverse If-Conversion; Nancy J. Warter, Scott A. Mahlke, Wen-mei W. Hwu, B. Index: projects/cfo.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfo.html,v retrieving revision 1.11 diff -u -r1.11 cfo.html --- projects/cfo.html 2 Jun 2018 21:16:20 - 1.11 +++ projects/cfo.html 12 Jul 2018 23:26:42 - @@ -19,7 +19,7 @@ To do -Latest News +Latest News 2005-08-11 @@ -33,7 +33,7 @@ -Introduction +Introduction Code factoring is the name of a class of useful optimization techniques developed especially for code size reduction. These approaches aim to reduce @@ -43,7 +43,7 @@ size optimization of GCC with code factoring methods (code motion and merging algorithms). The implementation currently resides on the branch. -Contributing +Contributing Checkout the cfo-branch branch from our respository. @@ -52,7 +52,7 @@ [cfo] in the subject. The usual contribution and testing rules apply. This branch is maintained by mailto:l...@gcc.gnu.org;>Gabor Loki. -Documentation +Documentation The project includes the following two code factoring algorithms: @@ -146,7 +146,7 @@ ftp://gcc.gnu.org/pub/gcc/summit/2004/Code%20Factoring.pdf;> GCC Summit Proceedings (2004). -Features +Features Currently the following algorithms are implemented on the branch: @@ -157,7 +157,7 @@ Sequence abstraction on Tree (-ftree-seqabstr) -Preliminary results +Preliminary results The following results have been prepared using the http://szeged.github.io/csibe/;>CSiBE benchmark with respect @@
[PATCH] Move -Walloca and related warnings from c.opt to common.opt
Hi, Since r262910, it was noticed that new -Walloca-larger-than= warnings started appearing when building the D frontend's standard library. These have been checked and verified as valid, and appropriate fixes will be sent on upstream. As for the warning itself, as it is now default on, it would be preferable to be able control it. Given the choice between adding these options to the D frontend or moving them to common, I'd rather move them to common. Regards Iain. --- gcc/ChangeLog * common.opt (-Walloca): Moved from common.opt. (Walloca-larger-than=): Likewise. (Wno-alloca-larger-than): Likewise. gcc/c-family/ChangeLog * c.opt (-Walloca): Move to common.opt. (Walloca-larger-than=): Likewise. (Wno-alloca-larger-than): Likewise. diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt index d6148380710..67da5a9e401 100644 --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -299,10 +299,6 @@ Wall C ObjC C++ ObjC++ Warning Enable most warning messages. -Walloca -C ObjC C++ ObjC++ Var(warn_alloca) Warning -Warn on any use of alloca. - Walloc-size-larger-than= C ObjC C++ LTO ObjC++ Var(warn_alloc_size_limit) Joined Host_Wide_Int ByteSize Warning Init(HOST_WIDE_INT_MAX) -Walloc-size-larger-than= Warn for calls to allocation functions that @@ -316,16 +312,6 @@ Walloc-zero C ObjC C++ ObjC++ Var(warn_alloc_zero) Warning -Walloc-zero Warn for calls to allocation functions that specify zero bytes. -Walloca-larger-than= -C ObjC C++ LTO ObjC++ Var(warn_alloca_limit) Warning Joined Host_Wide_Int ByteSize Init(HOST_WIDE_INT_MAX) --Walloca-larger-than= Warn on unbounded uses of -alloca, and on bounded uses of alloca whose bound can be larger than - bytes. - -Wno-alloca-larger-than -C ObjC C++ LTO ObjC++ Alias(Walloca-larger-than=,18446744073709551615EiB,none) Warning --Wno-alloca-larger-than Disable Walloca-larger-than= warning. Equivalent to Walloca-larger-than= or larger. - Warray-bounds LangEnabledBy(C ObjC C++ LTO ObjC++) ; in common.opt diff --git a/gcc/common.opt b/gcc/common.opt index 4bf8de90331..fa68eda4213 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -538,6 +538,20 @@ Waggressive-loop-optimizations Common Var(warn_aggressive_loop_optimizations) Init(1) Warning Warn if a loop with constant number of iterations triggers undefined behavior. +Walloca +Common Var(warn_alloca) Warning +Warn on any use of alloca. + +Walloca-larger-than= +Common Var(warn_alloca_limit) Warning Joined Host_Wide_Int ByteSize Init(HOST_WIDE_INT_MAX) +-Walloca-larger-than= Warn on unbounded uses of +alloca, and on bounded uses of alloca whose bound can be larger than + bytes. + +Wno-alloca-larger-than +Common Alias(Walloca-larger-than=,18446744073709551615EiB,none) Warning +-Wno-alloca-larger-than Disable Walloca-larger-than= warning. Equivalent to Walloca-larger-than= or larger. + Warray-bounds Common Var(warn_array_bounds) Warning Warn if an array is accessed out of bounds.
[committed] Move non-PIC jump table to rodata on 32-bit linux
The attached patch fixes a problem noted by Helge Deller. When a
non-PIC jump table is
placed in the text section, the local label marking the head of the
table ends up in the
unwind data. This is due to the R_PARISC_DIR21L and R_PARISC_DIR14R
relocations needed
to load the address of the table. This breaks the unwind data.
On the 32-bit Linux target, we can simply put non-PIC jump tables in
rodata. This has the
added benefit that it shortens the text section and avoids potential
issues in calculating
branch distances.
We should also do this for the HP-UX SOM target. However, this requires
deferring the output
of branch tables to final.
When generating PIC code, the references are relative and the label is
removed by the assembler.
Tested change on hppa-unknown-linux-gnu. Committed change to active
branches.
Dave
--
John David Anglin dave.ang...@bell.net
2018-07-29 John David Anglin
* config/pa/pa.c (pa_output_addr_vec): Align address table.
* config/pa/pa.h (JUMP_TABLES_IN_TEXT_SECTION): Revise comment.
* config/pa/pa32-linux.h (JUMP_TABLES_IN_TEXT_SECTION): Define.
Index: config/pa/pa.c
===
--- config/pa/pa.c (revision 263009)
+++ config/pa/pa.c (working copy)
@@ -10680,6 +10680,8 @@
{
int idx, vlen = XVECLEN (body, 0);
+ if (!TARGET_SOM)
+fputs ("\t.align 4\n", asm_out_file);
targetm.asm_out.internal_label (asm_out_file, "L", CODE_LABEL_NUMBER (lab));
if (TARGET_GAS)
fputs ("\t.begin_brtab\n", asm_out_file);
Index: config/pa/pa.h
===
--- config/pa/pa.h (revision 263009)
+++ config/pa/pa.h (working copy)
@@ -1143,22 +1143,24 @@
#define ASM_OUTPUT_ASCII(FILE, P, SIZE) \
pa_output_ascii ((FILE), (P), (SIZE))
-/* Jump tables are always placed in the text section. Technically, it
- is possible to put them in the readonly data section. This has the
- benefit of getting the table out of .text and reducing branch lengths
- as a result.
+/* Jump tables are always placed in the text section. We have to do
+ this for the HP-UX SOM target as we can't switch sections in the
+ middle of a function.
- The downside is that an additional insn (addil) is needed to access
+ On ELF targets, it is possible to put them in the readonly-data section.
+ This would get the table out of .text and reduce branch lengths.
+
+ A downside is that an additional insn (addil) is needed to access
the table when generating PIC code. The address difference table
- also has to use 32-bit pc-relative relocations. Currently, GAS does
- not support these relocations, although it is easily modified to do
- this operation.
+ also has to use 32-bit pc-relative relocations.
The table entries need to look like "$L1+(.+8-$L0)-$PIC_pcrel$0"
when using ELF GAS. A simple difference can be used when using
- SOM GAS or the HP assembler. The final downside is GDB complains
- about the nesting of the label for the table when debugging. */
+ the HP assembler.
+ The final downside is GDB complains about the nesting of the label
+ for the table. */
+
#define JUMP_TABLES_IN_TEXT_SECTION 1
/* This is how to output an element of a case-vector that is absolute. */
Index: config/pa/pa32-linux.h
===
--- config/pa/pa32-linux.h (revision 263009)
+++ config/pa/pa32-linux.h (working copy)
@@ -67,3 +67,12 @@
layout compatibility with the original linux thread implementation. */
#undef MALLOC_ABI_ALIGNMENT
#define MALLOC_ABI_ALIGNMENT 128
+
+/* Place jump tables in the text section except when generating non-PIC
+ code. When generating non-PIC code, the relocations needed to load the
+ address of the jump table result in a text label in the final executable
+ if the jump table is placed in the text section. This breaks the unwind
+ data for the function. Thus, the jump table needs to be placed in
+ rodata when generating non-PIC code. */
+#undef JUMP_TABLES_IN_TEXT_SECTION
+#define JUMP_TABLES_IN_TEXT_SECTION (flag_pic)
[PATCH] Fix PR middle-end/86705
pr45678-2.c ICEs for msp430-elf with -mlarge, because an alignment of POINTER_SIZE is attempted. POINTER_SIZE with -mlarge is 20-bits, so further code in the middle-end that expects this to be a power or 2 causes odd alignments to be set, in this case eventually resulting in an ICE. The test ICEs on gcc-7-branch, gcc-8-branch, and current trunk. It successfully builds on gcc-6-branch. The failure is caused by r235172. Successfully bootstrapped and regtested the attached patch for x86-64-pc-linux-gnu, and msp430-elf with -mlarge, on trunk. Ok for gcc-7-branch, gcc-8-branch and trunk? >From e655a518a06a848dc398504f28272750e1a2be9f Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Tue, 13 Mar 2018 11:25:56 + Subject: [PATCH] When aligning to POINTER_SIZE, round alignment to largest power of 2 that is <= POINTER_SIZE PR middle-end/86705 * gcc/cfgexpand.c (set_parm_rtl): Before using POINTER_SIZE as an alignment value, round it to the largest power of 2 less than or equal to itself. (expand_one_ssa_partition): Likewise. (expand_one_var): Likewise. --- gcc/cfgexpand.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c index d6e3c38..a56db7a 100644 --- a/gcc/cfgexpand.c +++ b/gcc/cfgexpand.c @@ -1258,9 +1258,12 @@ set_parm_rtl (tree parm, rtx x) pointer. ??? We've got a pseudo for sure here, do we actually dynamically allocate its spilling area if needed? ??? Isn't it a problem when POINTER_SIZE also exceeds - MAX_SUPPORTED_STACK_ALIGNMENT, as on cris and lm32? */ + MAX_SUPPORTED_STACK_ALIGNMENT, as on cris and lm32? + POINTER_SIZE may not be a power of 2 e.g. for msp430-elf with the large + data model, so align to the largest power of 2 that is + <= POINTER_SIZE. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) - align = POINTER_SIZE; + align = (unsigned)1 << floor_log2 (POINTER_SIZE); record_alignment_for_reg_var (align); } @@ -1381,7 +1384,7 @@ expand_one_ssa_partition (tree var) /* If the variable alignment is very large we'll dynamicaly allocate it, which means that in-frame portion is just a pointer. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) -align = POINTER_SIZE; +align = (unsigned)1 << floor_log2 (POINTER_SIZE); record_alignment_for_reg_var (align); @@ -1608,7 +1611,7 @@ expand_one_var (tree var, bool toplevel, bool really_expand) /* If the variable alignment is very large we'll dynamicaly allocate it, which means that in-frame portion is just a pointer. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) - align = POINTER_SIZE; + align = (unsigned)1 << floor_log2 (POINTER_SIZE); } record_alignment_for_reg_var (align); -- 2.7.4
[PATCH] libbacktrace: Move define of HAVE_ZLIB into check for -lz
This is really to suppress the default action-if-found for
AC_CHECK_LIBS. Zlib is not a dependency of libbacktrace, and so it
shouldn't be added to LIBS. When looking at the check, saw that could
remove the test for ac_cv_lib_z_compress also.
Regards
Iain
---
2018-07-29 Iain Buclaw
* configure.ac: Move define of HAVE_ZLIB into check for -lz.
* Makefile.in: Regenerate.
* config.h.in: Likewise.
* configure: Likewise.
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index f7f849bdeaf..8b5dc3e5b41 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -16,7 +16,7 @@
@SET_MAKE@
# Makefile.am -- Backtrace Makefile.
-# Copyright (C) 2012-2017 Free Software Foundation, Inc.
+# Copyright (C) 2012-2018 Free Software Foundation, Inc.
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
diff --git a/libbacktrace/config.h.in b/libbacktrace/config.h.in
index c19b6e430cb..6205fc55fa5 100644
--- a/libbacktrace/config.h.in
+++ b/libbacktrace/config.h.in
@@ -34,9 +34,6 @@
/* Define to 1 if you have the header file. */
#undef HAVE_INTTYPES_H
-/* Define to 1 if you have the `z' library (-lz). */
-#undef HAVE_LIBZ
-
/* Define to 1 if you have the header file. */
#undef HAVE_LINK_H
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 87cadda6c8c..d5a9d79e15c 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -12973,19 +12973,11 @@ fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_compress" >&5
$as_echo "$ac_cv_lib_z_compress" >&6; }
if test "x$ac_cv_lib_z_compress" = x""yes; then :
- cat >>confdefs.h <<_ACEOF
-#define HAVE_LIBZ 1
-_ACEOF
-
- LIBS="-lz $LIBS"
-
-fi
-
-if test $ac_cv_lib_z_compress = "yes"; then
$as_echo "#define HAVE_ZLIB 1" >>confdefs.h
fi
+
if test "$ac_cv_lib_z_compress" = yes; then
HAVE_ZLIB_TRUE=
HAVE_ZLIB_FALSE='#'
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 6f7b5eabca6..fd367451602 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -426,10 +426,8 @@ AC_SUBST(PTHREAD_CFLAGS)
AM_CONDITIONAL(HAVE_PTHREAD, test "$libgo_cv_lib_pthread" = yes)
-AC_CHECK_LIB([z], [compress], [])
-if test $ac_cv_lib_z_compress = "yes"; then
- AC_DEFINE(HAVE_ZLIB, 1, [Define if -lz is available.])
-fi
+AC_CHECK_LIB([z], [compress],
+[AC_DEFINE(HAVE_ZLIB, 1, [Define if -lz is available.])])
AM_CONDITIONAL(HAVE_ZLIB, test "$ac_cv_lib_z_compress" = yes)
dnl Test whether the linker supports the --compress_debug_sections option.
New Swedish PO file for 'gcc' (version 8.2.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-8.2.0.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/gcc/ 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/gcc.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.
[PATCH] Fix wrong code with truncated string literals (PR 86711/86714)
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C.
I have xfailed strlenopt-49.c, which tests this feature.
Personally I don't think that it is worth the effort to
optimize something that is per se invalid in C++.
The hunk in builtins.c is unrelated, but I would like
to use tree_to_shwi here, to be in line with the
tree_fits_shwi_p check above, and the rest of that
function which uses signed HWI throughout.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2018-07-29 Bernd Edlinger
PR middle-end/86711
PR middle-end/86714
* builtins.c (c_strlen): Use tree_to_shwi because maxelts is signed.
* expr.c (string_constant): Don't return truncated string literals.
* fold-const.c (c_getstr): Fix function comment. Remove unused third
argument. Fix range checks.
* fold-const.c (c_getstr): Adjust protoype.
testsuite:
2018-07-29 Bernd Edlinger
PR middle-end/86711
PR middle-end/86714
* gcc.c-torture/execute/pr86711.c: New test.
* gcc.c-torture/execute/pr86714.c: New test.
* gcc.dg/strlenopt-49.c: Add xfail.
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 263045)
+++ gcc/builtins.c (working copy)
@@ -617,7 +617,7 @@ c_strlen (tree src, int only_value)
if (tree size = TYPE_SIZE_UNIT (type))
if (tree_fits_shwi_p (size))
{
- maxelts = tree_to_uhwi (size);
+ maxelts = tree_to_shwi (size);
maxelts = maxelts / eltsize - 1;
}
Index: gcc/expr.c
===
--- gcc/expr.c (revision 263045)
+++ gcc/expr.c (working copy)
@@ -11410,24 +11410,14 @@ string_constant (tree arg, tree *ptr_offset)
if (!init || TREE_CODE (init) != STRING_CST)
return NULL_TREE;
- tree array_size = DECL_SIZE_UNIT (array);
- if (!array_size || TREE_CODE (array_size) != INTEGER_CST)
-return NULL_TREE;
-
/* Avoid returning a string that doesn't fit in the array
- it is stored in, like
- const char a[4] = "abcde";
- but do handle those that fit even if they have excess
- initializers, such as in
- const char a[4] = "abc\000\000";
- The excess elements contribute to TREE_STRING_LENGTH()
- but not to strlen(). */
- unsigned HOST_WIDE_INT charsize
-= tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (init;
- unsigned HOST_WIDE_INT length = TREE_STRING_LENGTH (init);
- length = string_length (TREE_STRING_POINTER (init), charsize,
- length / charsize);
- if (compare_tree_int (array_size, length + 1) < 0)
+ it is stored in, like:
+ const char a[4] = "abcd";
+ because callers expect to be able to access the string
+ up to the limit imposed by TREE_STRING_LENGTH which
+ always includes the terminating NUL char. */
+ if (compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)),
+ TREE_STRING_LENGTH (init)) < 0)
return NULL_TREE;
*ptr_offset = offset;
Index: gcc/fold-const.c
===
--- gcc/fold-const.c (revision 263045)
+++ gcc/fold-const.c (working copy)
@@ -14577,16 +14577,12 @@ fold_build_pointer_plus_hwi_loc (location_t loc, t
/* Return a pointer P to a NUL-terminated string representing the sequence
of constant characters referred to by SRC (or a subsequence of such
characters within it if SRC is a reference to a string plus some
- constant offset). If STRLEN is non-null, store stgrlen(P) in *STRLEN.
- If STRSIZE is non-null, store in *STRSIZE the size of the array
- the string is stored in; in that case, even though P points to a NUL
- terminated string, SRC need not refer to one. This can happen when
- SRC refers to a constant character array initialized to all non-NUL
- values, as in the C declaration: char a[4] = "1234"; */
+ constant offset). If STRLEN is non-null, store the number of bytes
+ in the string constant including the terminating NUL char. *STRLEN is
+ typically strlen(P) + 1 in the absence of embedded NUL characters. */
const char *
-c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* = NULL */,
- unsigned HOST_WIDE_INT *strsize /* = NULL */)
+c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* = NULL */)
{
tree offset_node;
@@ -14613,40 +14609,24 @@ const char *
unsigned HOST_WIDE_INT string_size = string_length;
tree type = TREE_TYPE (src);
if (tree size = TYPE_SIZE_UNIT (type))
-if (tree_fits_shwi_p (size))
+if (tree_fits_uhwi_p (size))
string_size = tree_to_uhwi (size);
+ if (offset >= string_size)
+return NULL;
+
if (strlen)
{
/* Compute and store the length of the substring at OFFSET.
All offsets past the initial length refer to null strings. */
- if (offset <= string_length)
+ if
Re: [PATCH] libgcc: m68k: avoid TEXTRELs in shared library (PR 86224)
On Sat, 28 Jul 2018 21:11:22 -0400 Rich Felker wrote: > On Sat, Jul 28, 2018 at 08:47:33PM +0200, Andreas Schwab wrote: > > On Jul 28 2018, sly...@inbox.ru wrote: > > > > > From: Sergei Trofimovich > > > > > > Cc: Ian Lance Taylor > > > Cc: Jeff Law > > > Cc: Andreas Schwab > > > Signed-off-by: Sergei Trofimovich > > > --- > > > libgcc/config/m68k/lb1sf68.S | 19 ++- > > > 1 file changed, 14 insertions(+), 5 deletions(-) > > > > > > diff --git a/libgcc/config/m68k/lb1sf68.S b/libgcc/config/m68k/lb1sf68.S > > > index 325a7c17d9b..16c6dc3f5a7 100644 > > > --- a/libgcc/config/m68k/lb1sf68.S > > > +++ b/libgcc/config/m68k/lb1sf68.S > > > @@ -435,7 +435,10 @@ $_exception_handler: > > > .text > > > FUNC(__mulsi3) > > > .globl SYM (__mulsi3) > > > + .globl SYM (__mulsi3_internal) > > > + .hidden SYM (__mulsi3_internal) > > > > No need for extra entry symbols, just mark the real entry point as > > hidden, like in the static library. > > That's clearly not correct or valid, as these are public interfaces. > If you make them hidden they'll be dropped from the dynamic symbol > table of libgcc_s.so. > > Of course for libgcc.a they need to be hidden (it's an ABI bug if > they're not hidden there already but I think there's a separate layer > of the build system that forces them to be hidden). > > Rich Oh, that's a good point! gcc/doc/libgcc.texi also suggests __ is the libgcc_s API. Would it make sense for gcc/doc/libgcc.texi to be expanded to more explicitly articulate expectation of symbol visibility on ELF platforms? -- Sergei pgpFr9m_8Gb8s.pgp Description: Цифровая подпись OpenPGP
[PATCH] Avoid another non zero terminated string constant
Hi!
This fixes another not NUL terminated string literal that is created
in tree-ssa-forwprop.c at simplify_builtin_call.
src_buf is set up to contain a NUL at src_buf[src_len], thus use src_len + 1
as length parameter to build_string_literal. All other uses of
build_string_literal do it right, as far as I can see.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-07-29 Bernd Edlinger
* tree-ssa-forwprop.c (simplify_builtin_call): Don't create a not NUL
terminated string literal.
Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 263045)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -1391,7 +1391,7 @@ simplify_builtin_call (gimple_stmt_iterator *gsi_p
src_buf, ptr1_align, false))
break;
- new_str_cst = build_string_literal (src_len, src_buf);
+ new_str_cst = build_string_literal (src_len + 1, src_buf);
if (callee1)
{
/* If STMT1 is a mem{,p}cpy call, adjust it and remove
