From: Jakub Jelinek <jakub@redhat.com>
To: Dodji Seketeli <dodji@redhat.com>
Cc: "GCC Patches" <gcc-patches@gcc.gnu.org>,
"Tom Tromey" <tromey@redhat.com>,
"Manuel López-Ibáñez" <lopezibanez@gmail.com>,
"Bernd Edlinger" <bernd.edlinger@hotmail.de>
Subject: Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals
Date: Mon, 11 Nov 2013 14:35:00 -0000 [thread overview]
Message-ID: <20131111142159.GZ27813@tucnak.zalov.cz> (raw)
In-Reply-To: <87zjpbb5qu.fsf@redhat.com>
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
next prev parent reply other threads:[~2013-11-11 14:22 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 14:48 Bernd Edlinger
2013-10-31 15:06 ` Jakub Jelinek
2013-10-31 15:19 ` Dodji Seketeli
2013-10-31 18:26 ` Jakub Jelinek
2013-11-04 11:52 ` Dodji Seketeli
2013-11-04 11:59 ` Jakub Jelinek
2013-11-04 15:42 ` Dodji Seketeli
2013-11-05 0:10 ` Bernd Edlinger
2013-11-05 9:50 ` Dodji Seketeli
2013-11-05 11:19 ` Bernd Edlinger
2013-11-05 11:43 ` Dodji Seketeli
2013-11-06 22:27 ` Bernd Edlinger
2013-11-04 12:06 ` Bernd Edlinger
2013-11-04 12:15 ` Jakub Jelinek
2013-11-04 12:32 ` Bernd Edlinger
2013-11-04 15:21 ` Dodji Seketeli
2013-11-11 10:49 ` Dodji Seketeli
2013-11-11 14:35 ` Jakub Jelinek [this message]
2013-11-11 17:13 ` Dodji Seketeli
2013-11-12 16:42 ` Dodji Seketeli
2013-11-13 5:10 ` Bernd Edlinger
2013-11-13 9:40 ` Dodji Seketeli
2013-11-13 9:43 ` Bernd Edlinger
2013-11-13 9:49 ` Dodji Seketeli
2013-11-13 9:49 ` Dodji Seketeli
2013-11-13 9:51 ` Jakub Jelinek
2013-11-14 15:12 ` Dodji Seketeli
2013-12-09 20:11 ` Tom Tromey
2014-01-21 12:28 ` Bernd Edlinger
2014-01-22 8:16 ` Dodji Seketeli
2014-01-23 17:12 ` Jakub Jelinek
2014-01-24 2:58 ` Bernd Edlinger
2014-01-24 7:53 ` Dodji Seketeli
2014-01-24 15:05 ` Markus Trippelsdorf
2014-01-24 15:41 ` Dodji Seketeli
2014-01-24 15:44 ` Jakub Jelinek
2014-01-24 16:09 ` Dodji Seketeli
2014-01-24 16:13 ` Jakub Jelinek
2014-01-24 23:02 ` Markus Trippelsdorf
2014-01-24 23:20 ` Markus Trippelsdorf
2014-01-28 13:20 ` Dodji Seketeli
2014-01-28 13:23 ` Dodji Seketeli
2014-01-28 18:40 ` H.J. Lu
2014-01-29 11:28 ` Dodji Seketeli
-- strict thread matches above, loose matches on Subject: below --
2013-10-31 13:45 Dodji Seketeli
2013-10-31 17:30 ` Manuel López-Ibáñez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131111142159.GZ27813@tucnak.zalov.cz \
--to=jakub@redhat.com \
--cc=bernd.edlinger@hotmail.de \
--cc=dodji@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=lopezibanez@gmail.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).