I was going to re-subscribe my dropped subscription to gcc-patches,
but the only links (that I can find) on gcc.gnu.org lead to the archives,
not to the subscription page. Thanks - Bruce
Hi Kaveh,
Requiring this is a bit of a nuisance. mpfr requires gmp so I had to
go pull and build that only to find:
checking if gmp.h version and libgmp version are the same...
(4.2.1/4.1.4) no
which is a problem because I cannot have /usr/local/lib found before
/usr/lib for
some things, yet for
Hi Kaveh,
Kaveh R. GHAZI wrote:
>
> It's not clear from your message whether this is a problem limited to
> mpfr-2.2.1, or 2.2.0 had this also. In any case, I think the mpfr
> configure process is right to stop you from shooting yourself by using a
> mismatched gmp header and library.
Here-to-fore
Paul Eggert wrote:
> I don't feel a strong need for 'configure' to default to
> -fstrict-aliasing with GCC. Application code that violates
> strict aliasing assumptions is often unportable in practice
> for other reasons, and needs to be rewritten anyway, even if
> optimization is disabled. So -f
Daniel Berlin wrote:
>> Admittedly it's only two small tests, and it's with 4.1.1. But that's
>> two more tests than the -fwrapv naysayers have done, on
>> bread-and-butter applications like coreutils or gzip or Emacs (or GCC
>> itself, for that matter).
>
> These are not performance needing appl
Daniel Berlin wrote:
> I generally have no problem with turning on -fwrapv at O2, but i'm
> curious where this ends.
> After all, strict aliasing makes it hard to write a bunch of styles of
> code people really want to write, and breaks real world programs and
> GNU software.
>
> Yet we decided t
Daniel Berlin wrote:
> Sorry, but it's rather impossible to argue against someone who seems
> to believe users should not be responsible and held responsible for
> knowing the rules of the language they are programming in. Down this
> path, madness lies.
> "strict aliasing" is really just "what th
> I don't agree with this point. There is a substantial number of
> application developers who would prefer -failsafe. There is a
> substantial number who would prefer -frisky. We don't know which set
> is larger. We get a lot of bug reports about missed optimizations.
six vs. half a dozen.
itted.
This is because we now fixinclude sysmacros.h and libgfortran is built with
-std=gnu99.
Caused by:
2007-02-03 Bruce Korb <[EMAIL PROTECTED]>
* inclhack.def (glibc_c99_inline_4): replace "extern" only if
surrounded by space characters.
Which means ther
Hello,
I mess around with a lot of generated code. That means I do automated
construction of libraries that use literal strings. In order to
reduce address fixups, I often put all the literal strings into one long
string with each piece separated from the others with a NUL byte.
Unfortunately, I
This bootstraps in Linux i686 & I can use -Wno-format-contains-nul to
suppress that warning. OK?
Bruce Korb wrote:
> Hello,
>
> I mess around with a lot of generated code. That means I do automated
> construction of libraries that use literal strings. In order to
> reduc
On 3/26/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> > use of -Wformat-contains-nul
>
> But, you do think the option is useful overall, then, and that Bruce
> should proceed with the additional steps you mention?
Yes, I think it makes sense in principle (and the existing patch is
p
On 10/21/14 02:30, Uros Bizjak wrote:
2014-10-21 Uros Bizjak
* inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
* fixincl.x: Regenerate.
Bootstrapped and regression tested on CentOS 5.11 x86_64-linux-gnu {,-m32}.
OK for mainline?
On 10/25/14 10:40, Bruce Korb wrote:
On 10/21/14 02:30, Uros Bizjak wrote:
2014-10-21 Uros Bizjak
* inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
* fixincl.x: Regenerate.
Bootstrapped and regression tested on CentOS 5.11 x86_64-linux-gnu {,-m32}.
OK for mainline
after 2 hours and 10 minutes:
/bin/sh ./libtool --tag=CXX --mode=compile
/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/xg++
-B/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/ -nostdinc++ `if
test -f
/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts
On 12/23/14 09:07, Aldy Hernandez wrote:
Andrew Haley writes:
On 12/21/2014 02:38 AM, Bruce Korb wrote:
Shouldn't the configure step have made config.h?
It's probably because you are building in srcdir. That is not
supported.
Hmm, newbies run into this often enough that I wond
On 06/01/17 07:24, Douglas B Rupp wrote:
>
> This is a reproducer for a problem we have with fixincludes on
> vxworks6.6. The desired output is
> FOO= 1
>
> The problem is the rules for handling headers enclosed in quotes can
> cause gcc to #include the original header not the patched header.
>
T-Bird snafu resend:
On 06/05/17 14:52, Bruce Korb wrote:
> On 06/01/17 07:24, Douglas B Rupp wrote:
>>
>> This is a reproducer for a problem we have with fixincludes on
>> vxworks6.6. The desired output is
>> FOO= 1
>>
>> The problem is the rules for
I know about all these theoretical possibilities of numbers behaving
in strange ways when arithmetic optimizations assume that signed
overflow won't occur when they actually might. Yep, it creates subtle
bugs. The warning is worthwhile. Still and all:
485 tvdiff = abs_tval(sub_tval(tim
Per request, the inlined functions
On Sat, Sep 2, 2017 at 12:59 PM, Bruce Korb wrote:
> I know about all these theoretical possibilities of numbers behaving
> in strange ways when arithmetic optimizations assume that signed
> overflow won't occur when they actually might. Yep, it
Hi,
On Sun, Sep 3, 2017 at 1:48 PM, Florian Weimer wrote:
> * Bruce Korb:
>
>> I know about all these theoretical possibilities of numbers behaving
>> in strange ways when arithmetic optimizations assume that signed
>> overflow won't occur when they actually might. Y
On 09/04/17 08:54, Manuel López-Ibáñez wrote:
> I wrote an explanation of the current status of Wstrict-overflow to the
> best of my knowledge:
> https://gcc.gnu.org/wiki/VerboseDiagnostics#Wstrict_overflow
>
> I didn't mention GIMPLE because it is often the case that the root of
> the problem i
Years and years ago, I went to a mess of trouble to implement this
specialized warning so I would not have to see it anymore. I use a code
generator that puts constant strings into one huge buffer with all the
contained strings NUL separated. Today, I was trying to build on OS/X:
libtool: compile
Thanks. I guess clang forked after the clever NUL-in-format-string was
added, but before my fix. :( I'll add -Wno-format if I can identify clang
over GCC.
On Wed, Jun 20, 2018 at 11:32 AM Jakub Jelinek wrote:
> On Wed, Jun 20, 2018 at 11:17:50AM -0700, Bruce Korb wrote:
> > Years
Yeah, I guess this is Clang, but is it a legal interpretation for Clang?
In file included from gnu-pw-mgr.c:24:
In file included from ./fwd.h:288:
*./seed.c:178:43: **warning: **sizeof on pointer operation will return size
of 'const char *' instead of 'const char [2042]'*
* [-Wsizeof-array
OK. My mistake. "Nevermind" -- side effect of another change.
On Wed, Jun 20, 2018 at 11:47 AM Bruce Korb wrote:
> Yeah, I guess this is Clang, but is it a legal interpretation for Clang?
>
> In file included from gnu-pw-mgr.c:24:
>
> In file included from ./fwd.h:
../../autoopts/makeshell.c: In function ‘text_to_var’:
../../autoopts/makeshell.c:324:14: error: this statement may fall
through [-Werror=implicit-fallthrough=]
(*(opts->pUsageProc))(opts, EXIT_SUCCESS);
~^~~~
This warning goes away if
On Sat, Jul 28, 2018 at 10:44 AM Jakub Jelinek wrote:
>
> On Sat, Jul 28, 2018 at 10:22:35AM -0700, Bruce Korb wrote:
> > ../../autoopts/makeshell.c: In function ‘text_to_var’:
> > ../../autoopts/makeshell.c:324:14: error: this statement may fall
> > through [-Wer
On Sat, Jul 28, 2018 at 11:48 AM Jakub Jelinek wrote:
> You don't need to use configure for this, something like:
> #ifdef __has_attribute
> #if __has_attribute(__noreturn__)
> #define NORETURN __attribute__((__noreturn__))
> #endif
OK. Thanks. It _will_ be a bit more complicated because my
On 07/11/11 10:14, Kurt Roeckx wrote:
That means that hurd has a non-standard definition for _IOWR.
#ifdef HURD
#define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t)
#endif
5.12 still failed with the same error message.
Then "HURD" is not #defined in hurd. I had to read
The intent was to clear up some stuff in the README.
When I noticed that I had affected other files, I had tried to put
everything back. Obviously a glitch. I'll fix it when I get home
tonight.
On Mon, Mar 15, 2010 at 11:00 PM, David Miller wrote:
>
> Ever since your changes installed on March
David Miller wrote:
> You said you would fix this several nights ago, but I still
> haven't seen any changes to fixincludes since then.
>
> When will you get around to fixing these regressions you
> introduced?
>
> Thank you.
Done. Terribly sorry for the delay. I became unemployed and
got a tw
Hi,
What does this message really mean?
i.e. What should I do about it?
ld.so should be loading shared objects in /usr/local/lib,
and that is where libmpc.so lives, so what gives?
Thanks - Bruce
> $ cat /etc/SuSE-release
> openSUSE 11.1 (x86_64)
> VERSION = 11.1
> $ ../configure --prefix=/old-ho
Hi Richard,
On Fri, Mar 19, 2010 at 9:12 AM, Richard Guenther
wrote:
> On Fri, Mar 19, 2010 at 5:02 PM, Bruce Korb wrote:
>> Hi,
>>
>> What does this message really mean?
>> i.e. What should I do about it?
>
> run ldconfig or use binaries from
> http://down
o I don't know how it went
missing. I'm chalking it up to some update anomaly.
Thanks for the response, tho! Regards, Bruce
On Fri, Mar 19, 2010 at 3:18 PM, Ralf Wildenhues wrote:
> Hi Bruce,
>
> * Bruce Korb wrote on Fri, Mar 19, 2010 at 05:22:15PM CET:
>> On Fri, M
Hi,
I was trying to figure out how come a memory allocation was short.
I think I've stumbled onto the issue. "evt_t" is a 48 byte structure
and "tpd_uptr" is a uintptr_t. "sz" initializes to 52 (decimal).
The value would be correct if I were not trying to multiply the
size of the pointer by 4.
0. It is still present in
>> 4.3.3. Giovanni Bajo came up with a patch to fixincludes to take care of
>> it. Bruce Korb was supposed to apply it, but he seems to have gone AWOL.
>>
>> To whoever is currently maintaining fixincludes: Please apply this fix, and
>> let this bug
Hi all,
This got far enough along to run fixincludes, so I can test this
``Old GCC-on-Tru64 bugfix'' thing, but still. Using current SVN source:
# If this is the top-level multilib, build all the other
# multilibs.
/home/gnu/proj/gcc/_bld/./gcc/xgcc -B/home/gnu/proj/gcc/_bld/./gcc/
-B/usr/local
On Sat, Feb 28, 2009 at 9:31 AM, H.J. Lu wrote:
>> In file included from /usr/include/features.h:354,
>> from /usr/include/stdio.h:28,
>> from ../../../../libgcc/../gcc/tsystem.h:90,
>> from ../../../../libgcc/../gcc/libgcc2.c:34:
>> /usr/include/gnu
On Wed, May 20, 2009 at 2:47 PM, Steve Ellcey wrote:
> I have a question about the use of sed by fixincl and mkheaders
> and a change that was made between 4.3.* and 4.4.0.
> After this patch, the sed used when building GCC is saved in a config
> file and that path to sed is used when you run mkh
The problem seems to be that GDB thinks all the code belongs to a
single line of text. At first, it was a file of mine, so I presumed
I had done something strange and passed it off. I needed to do some
more debugging again and my "-g -O0" output still said all code
belonged to that one line. So,
On 08/06/10 10:19, Bruce Korb wrote:
> The problem seems to be that GDB thinks all the code belongs to a
> single line of text. At first, it was a file of mine, so I presumed
> I had done something strange and passed it off. I needed to do some
> more debugging again and my "-g
On 08/06/10 10:24, David Daney wrote:
> On 08/06/2010 10:19 AM, Bruce Korb wrote:
>> The problem seems to be that GDB thinks all the code belongs to a
>> single line of text. At first, it was a file of mine, so I presumed
>> I had done something strange and passed it off.
On Fri, Aug 6, 2010 at 11:19 AM, David Daney wrote:
>> That seems to work. There are one or two or three bugs then.
>> Either gdb needs to recognize an out of sync object code
>
> It cannot do this as it was released before GCC-4.5.
GDB and GCC communicate with each other with particular convent
Hi Richard,
On Fri, Aug 6, 2010 at 11:43 AM, Richard Guenther
wrote:
> The gdb version on openSUSE that ship with GCC 4.5 is perfectly fine
> (it's 7.1 based). No idea what the reporter is talking about (we don't ship
> insight IIRC).
You are remembering correctly. I was not clear enough. I u
Hi,
I write a lot of code that emits code and it is a nuisance to try to
keep track of which index values have been initialized and which not.
This initialization extension would be really, really cool and if I
can find some of that mythical "copious spare time" I may provide
a patch:
int foo[
CF: http://gcc.gnu.org/ml/gcc/2005-11/msg00950.html
http://gcc.gnu.org/ml/gcc/2005-11/msg00951.html
Since Google did not yield an answer, I'm re-asking the question,
though with a slightly different file. Help, please, from anybody
knowing how to work around the issue. Thank you! - Bruce
$
Philip Martin wrote:
Bruce Korb <[EMAIL PROTECTED]> writes:
-- declaration. It Is important that all references to the type point to
The capital 'I' in 'Is' looks wrong.
$ svn cat -r108304 svn://gcc.gnu.org/svn/gcc/trunk/gcc/ada/sem_
Hi Bob,
On 5/21/06, Bob Proulx <[EMAIL PROTECTED]> wrote:
Bruce Korb wrote:
> Philip Martin wrote:
> >The capital 'I' in 'Is' looks wrong.
> ...
> That's what I wanted: a nice, simple answer that was short of re-pulling
> the entire repository.
Hi,
I've added `` xxx = 0'' to my code, but nevertheless it would be nice
if there were a way to tell the compiler to not worry. If I could not
find the right way, I apologize in advance. So, two suggestions:
int xxx = __random__;
or else:
extern void yyy( int* zzz __sets_value__ );
vo
Here is the real code. The complaint is about pOptTitle.
The compiler is GCC 4.1.1. Both "set*OptFmts" functions
*WILL* set pOptTitle to something. Option level is -O4, so
flow analysis is being done:
void
optionOnlyUsage(
tOptions* pOpts,
int ex_code )
{
const char * pOptTitle;
As you probably know by now, one can't look at a bug of this sort
without a compilable test case. Andrew correctly pointed out that this
optimization is affected by (for instance) inlining.
Hi Daniel,
The function referenced is in a separate compilation unit and
even if it were in the same uni
Kaveh R. Ghazi wrote:
Thoughts on fixing it?
Blech! :-)
However I believe since fixincludes moved to the top level directory
we're no longer looking in the target headers and getting that
definition and thus the __STRICT_ANSI__ changes are always applied,
even when they're not supposed to be
# fake us into system header land...
#if __STDC__ - 0 == 0
#error "STDC_0_IN_SYSTEM_HEADERS"
#endif
If it fails, then fixincludes knows we have stdc_0_in_system_headers.
That looks about right to me. KIASAP (as simple as possible,
no way is this coming out "simple". :) Cheers -Bruce
On 07/04/13 09:40, Jack Howarth wrote:
Currently I am forced to manually patch fixincludes/fixinc.in to have the DIR
passed to
--with-sysroot honored during the bootstrap. Thanks in advance for any help in
getting
this oversight in fixincludes fixed for gcc 4.9.
Jack
I saw the bu
make[5]: Entering directory
`/u/gnu/proj/gcc-bld/x86_64-unknown-linux-gnu/32/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
DEFINES='' HEADERS='../../../../gcc-svn/libgcc/config/i386/value-unwind.h' \
../../../../gcc-svn/libgcc/mkheader.sh > tmp-libgcc_tm.h
On 07/06/13 09:02, Andrew Haley wrote:
On 07/06/2013 04:41 PM, Bruce Korb wrote:
Why is it that configure worked but stubs-32.h was not found?
Googling leads me to:
You're missing the 32 bit libc dev package:
but the configure step should detect that
The trouble with making suggestions
On 07/06/13 11:53, Andreas Schwab wrote:
Bruce Korb writes:
Why is it that configure worked but stubs-32.h was not found?
This is testing the host compiler which doesn't need that file. You
need to build the target compiler before you can test it.
Sorry, I'm still confused
Hi,
On Sun, Jul 7, 2013 at 10:19 PM, Andrew Pinski wrote:
> I think disable multilib by default is a mistake and is a broken
> choice for broken distros which don't install the 32bit development by
> default when you install the development part.
If a distro does something that you consider wron
On Mon, Jul 8, 2013 at 8:24 AM, Jakub Jelinek wrote:
> Far easier would be if not inhibit_libc to try to compile some trivial
> program using say stdlib.h include in libgcc configure and error out there,
> if it isn't for the primary multilib hint that either development support
> for the non-prim
On 07/08/13 10:27, Jonathan Wakely wrote:
I added http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h to improve things
slightly.
Ever so, but thank you. Ultimately, searching for just "stubs-32.h"
will take you there and not require you to wade through too much chaff.
You're still Googling instead of
On Tue, Jul 16, 2013 at 7:25 AM, Andrew Pinski wrote:
>> GCC sources could contain a gnu/stubs-32.h header with an #error and
>> ensure that the right directory to find it is searched when building
>> the target libraries, but only after all other directories. It
>> wouldn't need to be installed
On Tue, Jul 16, 2013 at 8:11 AM, Jonathan Wakely wrote:
> On 16 July 2013 16:04, Gabriel Dos Reis wrote:
>> Agreed. It is surprising that we allowed ourselves to
>> break the most common target this way.
>
> It isn't broken, we just don't list one of the prerequisites in the
> installation docs.
On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote:
> There should be a better diagnostic.
If you remember, the start of this thread was:
> Why is it that configure worked but stubs-32.h was not found?
That is the correct thing to do. The reply, basically, was:
It's too hard.
OK, fine,
Googling:
gcc undefined reference to `lexer_line'
yields:
http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6
Please check for it in configure and mention it in the dependency message. :)
Thank you!
On 12/07/13 12:59, Bruce Korb wrote:
Googling:
gcc undefined reference to `lexer_line'
yields:
http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6
Please check for it in configure and mention it in the dependency message. :)
Thank you!
Oops -- I was too optim
On 12/08/13 07:21, Jonathan Wakely wrote:
It usually means you don't have bison and/or flex installed.
Flex.
They are documented as prerequisites for building from svn.
Documented prerequisites may as well be documented:
in the cellar...in the bottom of a locked filing cabinet stuck in
Hi, this is for 4.3.3, which is a bit old, so I'm not filing a bug.
static inline void * get_resp_ptr(U32 bkade, U32 q_id)
{
blade_data_t * bd = bfr_blade_data + ssdId;
bfr_pendcmd_q_t * pcq = bd->bfrpb_ques + q_id;
blade_resp_t *res = pcq->bfrpq_resp;
return (void *)(res +
On 03/05/12 09:01, Rainer Orth wrote:
This is where I need explicit approval and/or guidance:
* There are some fixincludes hacks that from their names seem to be
osf-specific, but are not restricted to alpha*-dec-osf*. Bruce,
what's the best way to handle those? Disable them e.g. with a
Hi,
This command:
gcc -Wno-format-contains-nul -Wall -Werror
falls over if a format string contains a nul byte.
I think it should not. There needs to be a way for
collective warning options (e.g. "-Wall") to skip
over anything set by a more specific option.
("format-contains-nul" being fair
Hi,
On Thu, Aug 9, 2012 at 1:42 PM, Joseph S. Myers wrote:
> On Thu, 9 Aug 2012, Bruce Korb wrote:
>> This command:
>>
>>gcc -Wno-format-contains-nul -Wall -Werror
>>
>> falls over if a format string contains a nul byte.
>> I think it should not. Ther
From Makefile.tpl:
EXTRA_TARGET_FLAGS = \
'AR=$$(AR_FOR_TARGET)' \
'AS=$(COMPILER_AS_FOR_TARGET)' \
'CC=$$(CC_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \
'CFLAGS=$$(CFLAGS_FOR_TARGET)' \
'CXX=$$(CXX_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)'
> $ ../configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr
> --prefix=/u/gnu/proj/gcc-git/_i \
> --enable-languages=c,c++,ftn --enable-bootstrap
> [...]
> Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
> their locations. Source code for these libraries can be found a
On 09/22/12 15:02, Gabriel Dos Reis wrote:
> On Sat, Sep 22, 2012 at 4:36 PM, Marc Glisse wrote:
>> Are you looking for gcc-h...@gcc.gnu.org?
>
>> mpc-devel ? (not my platform, I don't even know if that package exists, but
>> your grep pattern excludes such a package)
>
> yes, it is "mpc-devel"
I have realized that it would be real useful to know which fixinclude fixes
are actually in use so that old cruft can get retired. Since nobody at all
has direct access to all the actively maintained platforms, it makes it
difficult to know. Therefore, it seems reasonable to me to jigger up some
I wrote a loop that figures out how many items are in a list,
counts down from that count to -1, changes direction and counts
up from 0 to the limit, a la:
inc = -1;
int idx = 0;
while (opts->papzHomeList[idx+1] != NULL)
idx++;
for (;;) {
if (idx < 0) { <<<=== li
Hi Florian,
On Sat, Dec 29, 2012 at 2:38 AM, Florian Weimer wrote:
>> ../../autoopts/configfile.c: In function 'intern_file_load':
>> ../../autoopts/configfile.c:1025:12: error: assuming signed overflow does
>> not occur \
>> when simplifying conditional to constant [-Werror=strict-overflow]
(Tarball attachment (75K) stripped.)
On 12/29/12 10:56, Florian Weimer wrote:
>> Not easily. git clone git://git.savannah.gnu.org/autogen.git
>
> Uhm, I get:
>
> configure.ac:30: error: AC_INIT should be called with package and version
> arguments
I ought to have directed you to a pre-release
You may have been thinking you were using "memcpy", but you were
using "bcopy" instead. Please apply the patch to md5.c. Thanks!
$ gcc -c shar-i.c
shar-i.c: In function 'md5_process_bytes':
shar-i.c:3087:13: error: invalid use of void expression
1034 extern void bcopy (__const void *__src,
On Mon, Mar 17, 2008 at 5:54 AM, Dave Korn <[EMAIL PROTECTED]> wrote:
> Dave Korn wrote on :
>
>
> > Jakub Jelinek wrote on 17 March 2008 12:00:
>
>
> > > The fixincl.x change on 4.1 branch should be IMNSHO reverted.
> >
>
> > I tend to agree. I'll revert this change under the own-patches rule
Dave Korn wrote:
> Jakub Jelinek wrote on 17 March 2008 12:00:
>
>> On Mon, Mar 17, 2008 at 10:27:17AM -, Dave Korn wrote:
>>> Eric Botcazou wrote on :
>>>
> fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
By accident I presume?
>>>
>>> As an epiphenonmenal side-ef
I must be missing something. I'm trying to forward declare some
static data arrays, but I'm getting this:
> static type_info_t const type_info_table[257] = {
> evlib-tables.c 169 Error 31: Redefinition of symbol 'type_info_table'
> compare
> with line 21, file evlib-tables.h
the "evlib-ta
Never mind. Thank you anyway. This is not a GCC message as I had thought.
Under the covers somewhere, a lint program got fired up. The lint
program is not good enough. Thanks anyway.
- Bruce
Bruce Korb wrote:
> I must be missing something. I'm trying to forward declare some
>
$ /usr/bin/gcc-3.3 -I../../tpd-include -E -DKERNEL_26 emlib.c -o emlib.i
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instr
On Nov 27, 2007 12:03 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> gcc-3.3 is quite old and is no longer maintained, though if the bug you
> found is still present in current sources, it should be reported.
I know. Debian's fresh releases are always full of really old stuff.
Anyway, 4.1 too:
$ /usr/
I don't write a lot of code anymore, but this sure seems like a
gratuitous irritation to me. I've been using
// FALLTHRU and
// FALLTHROUGH
for *DECADES*, so it's pretty incomprehensible why the compiler should
have to invalidate my code because it thinks a different coding
comment is bet
On Mon, Sep 7, 2020 at 3:45 PM Florian Weimer wrote:
>
> * Bruce Korb via Gcc:
>
> > I don't write a lot of code anymore, but this sure seems like a
> > gratuitous irritation to me. I've been using
> >
> > // FALLTHRU and
> > //
On Tue, Sep 8, 2020 at 2:33 AM Jonathan Wakely wrote:
> > Nope. I had /* FALLTHROUGH */ on the line before a blank line before
> > the case label. After Googling, I found an explicit reference that you
> > had to spell it: // fall through
> > I did that, and it worked. So I'm moving on, but still
On Tue, Sep 8, 2020 at 7:36 AM Jakub Jelinek wrote:
> > The fall through comment was polluted with a colon that I hadn't noticed,
> > as in:
> >
> > /* FALLTHROUGH: */
> >
> > and your fall through regex doesn't allow for that.
> > I'd add a colon to the space, tab and '!' that the regex acce
Hi,
You are supposed to be able to post once you've subscribed.
Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than
MAXNAMELEN characters. That is provable.
"def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at an
offset maximum of MAXNAMELEN+1 (also provable
Hi Martin,
On 1/10/21 11:01 AM, Martin Sebor wrote:
On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:
This is the code that must be confusing to GCC. "def_str" points to
the second character in the 520 byte buffer. "def_scan" points to a
character that we already know we'
Hi,
On 1/10/21 3:56 PM, Martin Sebor wrote:
Sure. I was confirming that based on the GCC dump there is no risk
of an overflow in the translation unit, and so there is no warning.
OK. :) I didn't understand the GCC dump. Despite having commit privs,
I'm not actually a compiler guru.
It can
92 matches
Mail list logo
