Re: %pc relative addressing of string literals/const data
Michael Meissner wrote on 2010/10/07 20:21:38:
>
> On Thu, Oct 07, 2010 at 04:50:50PM +0200, Joakim Tjernlund wrote:
> > Why not offer some of this on PowerPC32? mcmodel=small would probably be
> > enough.
>
> Well as they say, contributions are welcome. Note, 32-bit mode doesn't need
A first contribution, support msingle-pic-base on ppc.
>From b418def9575d6ea3698077888157ae52631e52f3 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund
Date: Sat, 9 Oct 2010 12:45:39 +0200
Subject: [PATCH] PowerPC: Add msingle-pic-base option.
Do not generate PIC prolougue.
---
rs6000.c |4
rs6000.opt |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/rs6000.c b/rs6000.c
index 5e6f301..71d095d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15323,6 +15323,10 @@ void
rs6000_emit_load_toc_table (int fromprolog)
{
rtx dest;
+
+ if (TARGET_SINGLE_PIC_BASE)
+return; /* Do not set PIC register */
+
dest = gen_rtx_REG (Pmode, RS6000_PIC_OFFSET_TABLE_REGNUM);
if (TARGET_ELF && TARGET_SECURE_PLT && DEFAULT_ABI != ABI_AIX && flag_pic)
diff --git a/rs6000.opt b/rs6000.opt
index 8a62352..5f6e6ca 100644
--- a/gcc/config/rs6000/rs6000.opt
+++ b/gcc/config/rs6000/rs6000.opt
@@ -103,6 +103,10 @@ mold-mnemonics
Target Report RejectNegative InverseMask(NEW_MNEMONICS)
Use old mnemonics for PowerPC architecture
+msingle-pic-base
+Target Report Mask(SINGLE_PIC_BASE)
+Do not load the PIC register in function prologues
+
msoft-float
Target Report RejectNegative Mask(SOFT_FLOAT)
Do not use hardware floating point
--
1.7.2.2
Re: GCC and out-of-range constant array indexes?
On 9 October 2010 05:22, Geert Bosch wrote: > > On Oct 8, 2010, at 18:18, Manuel López-Ibáñez wrote: > >> It is possible to do it quite fast. Clang implements all warnings, >> including Wuninitialized, in the FE using fast analysis and they claim >> very low false positives. >> However, there are various reasons why it has not been attempted in GCC: >> >> * GCC is too slow already at -O0, slowing it down further would not be >> acceptable. So you need a really high-performing implementation. > > The Ada front end has very extensive warnings. I don't think > they really contribute measurably to performance. > We don't try to construct call graphs to determine > wether the array reference will be executed or not. > If the line appears in your program, it will cause an > error if executed, so we will warn: either you wrote > dead code, or wrong code. This may be acceptable for Ada, but it seems not acceptable for C/C++. In fact, warnings have been removed/tweaked because they broke GCC build for such code. In any case, it is possible to implement a basic flow-sensitive CFG in the FE: http://clang.llvm.org/docs/InternalsManual.html#CFG but it is not clear whether such a thing would be accepted in GCC. My intention by answering Gary is to point out that if he is thinking about working on this problem, he should consider building a cheap FE-specific CFG, rather than try to share the current infrastructure between FE and middle-end. I would like to see this implemented, so I'd rather have a good-enough implementation committed to GCC than a near-perfect solution that is never completed or accepted in trunk. > To avoid false positives in inlined code, code instantiated > from templates and the like, we have a notion of code that > comes from source or not. For many warnings, we will only > post the warning if the code comes from source, that is: > is not generated by the compiler as part of the compilation > process. Good for Ada! Unfortunately, the C/C++ FEs do not have such infrastructure. There is some promising work for macros http://gcc.gnu.org/PR7263 but it is far from ready and it would still require the diagnostics machinery to start using it, which is even further away. I hope Dodji manages to find some time to finish it, because the possibilities are impressive. See "Automatic Macro Expansion" here: http://clang.llvm.org/diagnostics.html I think for templates it is currently feasible to do this for each warning, but there is no general or straight-forward way. See the often-reported bug: http://gcc.gnu.org/PR11856 A counter-example: http://gcc.gnu.org/PR43167 And (for once!!!) Clang doesn't get this right this either: http://llvm.org/PR6418 I think it is generally acknowledged that Ada has the best diagnostics among GCC FEs. Too bad Adacore customers do not use C/C++ ;-) Cheers, Manuel.
Re: GCC and out-of-range constant array indexes?
On Sat, Oct 09, 2010 at 09:22:42PM +0200, Manuel L?pez-Ib??ez wrote: > My intention by answering Gary is to point out that if he is thinking > about working on this problem, he should consider building a cheap > FE-specific CFG, rather than try to share the current infrastructure > between FE and middle-end. I would like to see this implemented, so I don't think that's a good idea. Much better would be just to not emit diagnostics, which shouldn't be emitted for dead code, right away, but instead of that queue it into the IL (in a form of something like __builtin_diagnostics, or something similar). Then after cfg cleanup + DCE has been run (or at expansion time?) we could issue diagnostics for the __builtin_diagnostics left in the IL afterwards. For -O0 if no DCE happens at all we could have some cheap pass that would just nuke obviously unreachable __builtin_diagnostics and don't modify the IL otherwise (of course gated on whether there are any in the IL). Jakub
Re: GCC and out-of-range constant array indexes?
On 9 October 2010 21:34, Jakub Jelinek wrote: > On Sat, Oct 09, 2010 at 09:22:42PM +0200, Manuel L?pez-Ib??ez wrote: >> My intention by answering Gary is to point out that if he is thinking >> about working on this problem, he should consider building a cheap >> FE-specific CFG, rather than try to share the current infrastructure >> between FE and middle-end. I would like to see this implemented, so > > I don't think that's a good idea. Much better would be just to > not emit diagnostics, which shouldn't be emitted for dead code, right away, > but instead of that queue it into the IL (in a form of something > like __builtin_diagnostics, or something similar). Then after cfg cleanup + > DCE > has been run (or at expansion time?) we could issue diagnostics for the > __builtin_diagnostics left in the IL afterwards. For -O0 if no DCE happens > at all we could have some cheap pass that would just nuke obviously > unreachable > __builtin_diagnostics and don't modify the IL otherwise (of course gated on > whether there are any in the IL). That doesn't solve the problem of diagnostics changing at different optimization levels. But I don't care much about that, so I wouldn't complain if anyone implemented either option. Cheers, Manuel.
Re: GCC and out-of-range constant array indexes?
* Geert Bosch: > The Ada front end has very extensive warnings. I don't think > they really contribute measurably to performance. > We don't try to construct call graphs to determine > wether the array reference will be executed or not. > If the line appears in your program, it will cause an > error if executed, so we will warn: either you wrote > dead code, or wrong code. In other languages, dead code doesn't come not just from the programmer, but also from the preprocessor and from expansion of generics (in fact, I've seen misleading warnings involving Ada generics, too). So the Ada exprience is not likely to translate to other front ends.
gcc-4.6-20101009 is now available
Snapshot gcc-4.6-20101009 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101009/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 165242 You'll find: gcc-4.6-20101009.tar.bz2 Complete GCC (includes all of below) MD5=1f8f11e5c8fa5056f9f0e9d2a6bb8899 SHA1=f2e1b515683077e5822a5776228b4e58fb6f938a gcc-core-4.6-20101009.tar.bz2C front end and core compiler MD5=22f19683eb242d94e950b004ff2f7848 SHA1=35a5c2ba6a10feee5bf263fe1a3b2210cc1228e1 gcc-ada-4.6-20101009.tar.bz2 Ada front end and runtime MD5=157045093d6bbcd027edebb33f758475 SHA1=b70a2529294b2a74baec5a183bf85955a73c85d5 gcc-fortran-4.6-20101009.tar.bz2 Fortran front end and runtime MD5=16a4cc315c59501a99a97ee63099248a SHA1=a3b0505dcfdaf2e4e9de9bcd5adcf14c030b8d6d gcc-g++-4.6-20101009.tar.bz2 C++ front end and runtime MD5=ddd02724d5ffe1bb39d5f79be3fd9a59 SHA1=67c45563d1d014fea7d17b11cba98142e8b4599b gcc-java-4.6-20101009.tar.bz2Java front end and runtime MD5=67992e25dcba336d10ef046c3ec15b05 SHA1=531eb6e429ccd4bc6e6fea37ed2a1d353d86f20d gcc-objc-4.6-20101009.tar.bz2Objective-C front end and runtime MD5=3d4b88397d95add843d9eeba99b15c68 SHA1=e3ce517b8091dfbbf11806addbb188990b593b01 gcc-testsuite-4.6-20101009.tar.bz2 The GCC testsuite MD5=59cc38ebfba6d64e0bfdfa38624552fc SHA1=34deedc9bb6d0af985c841aae77f4cd61b60af6d Diffs from 4.6-20101002 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
MIPS64 GCC not building at r165246
Hi Richard, I was just trying to build the trunk GCC at r165246 Configured thusly: $ ../trunk/configure --target=mips64-linux --with-sysroot=/home/daney/mips64-linux --prefix=/home/daney/mips64-linux --with-arch=mips64r2 --enable-languages=c --disable-libmudflap Back on: r162086 | rsandifo | 2010-07-12 11:53:01 -0700 (Mon, 12 Jul 2010) | 36 lines gcc/ * doc/tm.texi.in (SWITCHABLE_TARGET): Document. [...] You added SWITCHABLE_TARGET, but it seems to break building now in expr.c gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/include/libelf ../../trunk/gcc/expr.c -o expr.o In file included from ../../trunk/gcc/expr.c:57: ../../trunk/gcc/target-globals.h:24: error: expected identifier or ‘(’ before ‘&’ token ../../trunk/gcc/target-globals.h: In function ‘restore_target_globals’: ../../trunk/gcc/target-globals.h:63: error: lvalue required as left operand of assignment This seems to be caused by: flags.h:243 #define this_target_flag_state (&default_target_flag_state) target-globals.h:24 extern struct target_flag_state *this_target_flag_state; Which when preprocessed we get: expr.i:??? extern struct target_flag_state *(&default_target_flag_state); Which evidently is not valid C. I am not sure how to go about fixing this. Do you have any ideas? David Daney
