Small typo in gcc/params.def
Noticed while doing translation of the gcc messages. Please apply to trunk if OK as I have no rfead/write access anymore AFAIK. 2015-07-10 Philipp Thomas p...@suse.de * params.def: fix typo. index 3e4ba3a..08b5c7f 100644 --- a/gcc/params.def +++ b/gcc/params.def @@ -572,7 +572,7 @@ DEFPARAM(PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS, DEFPARAM(PARAM_VECT_MAX_PEELING_FOR_ALIGNMENT, vect-max-peeling-for-alignment, - Max number of loop peels to enhancement alignment of data references in a loop, + Max number of loop peels to enhance alignment of data references in a loop, -1, -1, 64) DEFPARAM(PARAM_MAX_CSELIB_MEMORY_LOCATIONS,
config/mep/mep.c: don't translate syntax description.
While checking the current german tanslations I noticed that
mep_validate_vliw passes the syntax description directly to inform and thus
they appear in the message catalogue which is IMO bogus. This patch makes
the syntax descriptions untanslkatable.
OK to check in?
2011-05-04 Philipp Thomas p...@suse.de
* config/mep/mep.c (mep_validate_vliw): Syntax description
should not be translated.
Index: config/mep/mep.c
===
--- config/mep/mep.c(Revision 173334)
+++ config/mep/mep.c(Arbeitskopie)
@@ -4122,16 +4122,16 @@
if (TREE_CODE (*node) == POINTER_TYPE
!gave_pointer_note)
{
- inform (input_location, to describe a pointer to a VLIW function,
use syntax like this:);
- inform (input_location, typedef int (__vliw *vfuncptr) (););
+ inform (input_location, to describe a pointer to a VLIW function,
use syntax like this: %s,
+ typedef int (__vliw *vfuncptr) (););
gave_pointer_note = 1;
}
if (TREE_CODE (*node) == ARRAY_TYPE
!gave_array_note)
{
- inform (input_location, to describe an array of VLIW function
pointers, use syntax like this:);
- inform (input_location, typedef int (__vliw *vfuncptr[]) (););
+ inform (input_location, to describe an array of VLIW function
pointers, use syntax like this: %s,
+ typedef int (__vliw *vfuncptr[]) (););
gave_array_note = 1;
}
}
Re: Poor internal documentation (was: dragonegg in FSF gcc?)
On Fri, 23 Apr 2010 16:23:29 +0200, Manuel López-Ibáñez lopeziba...@gmail.com wrote: Great! Go ahead, please. The wiki is easy to edit. Finally I got around to do it. Editing is easy ... kind of :) Creating the Links was easy but I failed do discover how I could actually make them point to other wiki pages. Bonus points if you collect there links to the existing documentation, so anyone wishing to help has the many sources at hand. Maybe I will find the time but I doubt that. Philipp
Re: Poor internal documentation (was: dragonegg in FSF gcc?)
* Ian Lance Taylor (i...@google.com) [20100413 00:41]: Details of GIMPLE IR: poor. Details of tree IR: poor. How to write a new optimization pass: poor. How to write a new frontend: nonexistent. General overview of compiler source: nonexistent. Overview of internal compiler datastructures: nonexistent. I'd say these these warrant an additional bullet Documentation under Improving GCC on the GCC wiki that then lists (at least) these points. It's not much, but it at least shows the GCC developers are aware and just maybe it does attract the interest of someone. Philipp
Re: Where to get a list of warning and error messages
* Simon Toth ([EMAIL PROTECTED]) [20080718 13:16]: Is there any full database of gcc warnings and errors? AFAIK, there isn't one. I guess your best choice is gcc.pot (i.e. the message catalog) in the po subdir. Philipp
Re: 64-Bit Operator Overloading Adventure
On Fri, 11 Jan 2008 09:59:41 -0800, Brian D. McGrew wrote: We're trying to move to 64-Bit now and this same code that has compiled for years is barking about operators cannot be overloaded. Please stick to gcc-help, as gcc is the wrong list for such questions. Philipp
Re: Help on compiling with Japanese Text
* Alan Ong ([EMAIL PROTECTED]) [20061201 03:35]: Hello, I am trying to compile my code with hard-coded Japanese Kanji and full-width katakana string text but the compiler view some of the text as escape characters. Please ask on [EMAIL PROTECTED] This list deals with the development of GCC. Philipp
Re: GCC Error Codes
On Sun, 15 Jan 2006 10:40:19 -0600, Perry Smith wrote: From Andreas's reply, it may not. In AIX, they want the message to come out in the user's native language so they print out the translated message (that comes from a separate file). It's the same with gettext. You have a file containing key and value (i.e. original text and it's translation) for each language, normally residing under /usr/share/locale/languge/LC_MESSAGE/package name.mo . Now in order to retrieve the localized message, the library will search for a translation matching the message in the program by searching the relevant message catalog for the current locale. Philipp
Re: Memory leak in bt-load.c ?
* Christophe Jaillet ([EMAIL PROTECTED]) [20060109 20:00]: in file 'bt-load.c', in function 'augment_live_range', some memory is xmalloc'ed. It seems to be possible to never free it, if all the first tests are true. This is now PR 25739. Philipp
Re: identifying c++ aliasing violations
On Sun, 4 Dec 2005 20:07:33 -0500 (EST), Jack Howarth wrote: swigpy.cc: In function 'int SWIGPY_Python_ConvertPtr(PyObject*, void**, swig_typ e_info*, int)': swigpy.cc:620: warning: dereferencing type-punned pointer will break strict-alia sing rules My recent encounters with python (in my case libboost_python) have shown me that code that uses the Python interface has to use no-strict-aliasing. Even the Python folks decided to use that switch in 2003 for the Python code (written in C). This is mostly because Python code is riddled with casts to PyObject. Philipp
