This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals


On Mon, Nov 11, 2013 at 11:19:21AM +0100, Dodji Seketeli wrote:
>  .../c-c++-common/cpp/warning-zero-in-literals-1.c  | Bin 0 -> 240 bytes
>  libcpp/include/line-map.h                          |   8 +
>  libcpp/line-map.c                                  |  40 ++
>  8 files changed, 585 insertions(+), 39 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/cpp/warning-zero-in-literals-1.c
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 49285e5..50c2482 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1469,7 +1469,7 @@ OBJS = \
>  
>  # Objects in libcommon.a, potentially used by all host binaries and with
>  # no target dependencies.
> -OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o input.o version.o
> +OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o vec.o input.o version.o

Too long line?

> +      if (c == '\0')
> +	c = ' ';
>        pp_character (context->printer, c);

Does that match how libcpp counts the embedded '\0' character in column
computation?

> +    /* The position (byte count) the the last byte of the line.  This
> +       normally points to the '\n' character, or to one byte after the
> +       last byte of the file, if the file doesn't contain a '\n'
> +       character.  */
> +    size_t end_pos;

Does it really help to note this?  You can always just walk the line from
start_pos looking for '\n' or end of file.

> +static fcache*
> +add_file_to_cache_tab (const char *file_path)
> +{
> +  static size_t idx;
> +  fcache *r;
> +
> +  FILE *fp = fopen (file_path, "r");
> +  if (ferror (fp))
> +    {
> +      fclose (fp);
> +      return NULL;
> +    }
> +
> +  r = &fcache_tab[idx];

Wouldn't it be better to use some LRU algorithm to determine which
file to kick out of the cache?  Have some tick counter of cache lookups (or
creation) and assign the tick counter to the just created resp. used
cache entry, and remove the one with the smallest counter?
> +  fcache * r = lookup_file_in_cache_tab (file_path);
> +  if (r ==  NULL)

Formatting (no space after *, extra space after ==).

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]