Re: string.h bug Benjamin-Elias Probst

[Martin Sebor via Gcc-bugs]

On 3/21/21 9:01 AM, Benjamin-Elias Probst wrote:

Hello,


my computer tried to build gcc in gcc-10.2.0

This happend after ./configure ... sudo make on ubuntu mint 20.1:


If you are reporting a bug then please enter it in GCC Bugzilla
(https://gcc.gnu.org/bugzilla/).  This list simply collects
Bugzilla updates and isn't meant for directly posting bugs or
for discussion.

If you are asking a usage question then please use the gcc-help
mailing list.

Martin




TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/bash ./mkconfig.sh config.h
TARGET_CPU_DEFAULT="" \
HEADERS="options.h insn-constants.h config/vxworks-dummy.h config/i386/biarch64.h 
config/i386/i386.h config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h 
config/gnu-user.h config/glibc-stdint.h config/i386/x86-64.h config/i386/gnu-user-common.h 
config/i386/gnu-user64.h config/linux.h config/linux-android.h config/i386/linux-common.h 
config/i386/linux64.h config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1 
LIBC_UCLIBC=2 LIBC_BIONIC=3 LIBC_MUSL=4 DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0" \
/bin/bash ./mkconfig.sh tm.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/i386/i386-protos.h config/linux-protos.h tm-preds.h" DEFINES="" 
\
/bin/bash ./mkconfig.sh tm_p.h
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/bash ./mkconfig.sh bconfig.h
g++ -c   -g   -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  
-DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I. -I./build 
-I./../include  -I./../libcpp/include  \
 -o build/genmodes.o genmodes.c
In file included from bconfig.h:3,
  from genmodes.c:20:
auto-host.h:2539:16: error: declaration does not declare anything [-fpermissive]
  2539 | #define rlim_t long
   |^~~~
In file included from genmodes.c:21:
system.h:495:14: error: conflicting declaration of C function 'void* sbrk(int)'
   495 | extern void *sbrk (int);
   |  ^~~~
In file included from system.h:301,
  from genmodes.c:21:
/usr/include/unistd.h:1041:14: note: previous declaration 'void* sbrk(intptr_t)'
  1041 | extern void *sbrk (intptr_t __delta) __THROW;
   |  ^~~~
In file included from genmodes.c:21:
system.h:503:14: error: ambiguating new declaration of 'char* strstr(const 
char*, const char*)'
   503 | extern char *strstr (const char *, const char *);
   |  ^~
In file included from /usr/include/c++/9/cstring:42,
  from system.h:241,
  from genmodes.c:21:
/usr/include/string.h:312:20: note: old declaration 'const char* strstr(const 
char*, const char*)'
   312 | extern const char *strstr (const char *__haystack, const char 
*__needle)
   |^~
In file included from genmodes.c:21:
system.h:551:20: error: conflicting declaration of C function 'const char* 
strsignal(int)'
   551 | extern const char *strsignal (int);
   |^
In file included from /usr/include/c++/9/cstring:42,
  from system.h:241,
  from genmodes.c:21:
/usr/include/string.h:447:14: note: previous declaration 'char* strsignal(int)'
   447 | extern char *strsignal (int __sig) __THROW;
   |  ^
In file included from system.h:702,
  from genmodes.c:21:
./../include/libiberty.h:112:14: error: ambiguating new declaration of 'char* 
basename(const char*)'
   112 | extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL 
ATTRIBUTE_NONNULL(1);
   |  ^~~~
In file included from /usr/include/c++/9/cstring:42,
  from system.h:241,
  from genmodes.c:21:
/usr/include/string.h:484:26: note: old declaration 'const char* basename(const 
char*)'
   484 | extern "C++" const char *basename (const char *__filename)
   |  ^~~~
make: *** [Makefile:2798: build/genmodes.o] Error 1


Best regards,

Benjamin-Elias Probst

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Martin Sebor]

On 08/15/2017 10:27 AM, Joseph Myers wrote:

On Tue, 15 Aug 2017, Martin Sebor wrote:


It looks like the data loss extends beyond 8/14.  Bug 81840
was created Sunday afternoon but is not in the database:

  https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html

(Strangely, 81841 is there, as is 81839.)


That's another 81839 replacing the original 81839.  As I noted on
overseers, the cut-off for GCC Bugzilla appears to be between
<https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01289.html> and
<https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01290.html>, early Sunday
morning UTC (and for sourceware Bugzilla it may well be similar).


Thanks for the update.  Can I subscribe to this list?

(It might be helpful to post an announcement of what's going on
here for those of us who aren't subscribed to the overseers list
or even are aware of its archives.)

Martin

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Martin Sebor]

On 08/15/2017 07:27 AM, Jonathan Wakely wrote:

On 15 August 2017 at 04:10, Martin Sebor wrote:

On 08/14/2017 04:22 PM, Eric Gallager wrote:


I'm emailing this manually to the list because Bugzilla is down and I
can't file a bug on Bugzilla about Bugzilla being down. The error
message looks like this:



Even if it were possible, there wouldn't be any point in filing a bug
that bugzilla's down, and so not much point emailing gcc-bugs either
(since that's for bugzilla mail).  Using gcc@ seems like the right
list to me.

N.B. since the server is being restored from a backup all of
yesterday's changes to bugzilla have been lost, including all Richi's
7.2 release changes, and Eric's housekeeping.

I don't suggest redoing all that work until all services are fully
restored, in case it's lost again.


It looks like the data loss extends beyond 8/14.  Bug 81840
was created Sunday afternoon but is not in the database:

  https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html

(Strangely, 81841 is there, as is 81839.)

Is there a plan to restore the lost data somehow or should
we try to do that ourselves for the bugs we know about?

Martin

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Martin Sebor]

On 08/14/2017 04:22 PM, Eric Gallager wrote:

I'm emailing this manually to the list because Bugzilla is down and I
can't file a bug on Bugzilla about Bugzilla being down. The error
message looks like this:


Bugzilla and the rest of gcc.gnu.org have been down much of
the afternoon/evening due to a hard drive upgrade (the old disk
apparently failed).  You're not the only one who found out about
it the hard way.  I (and I suspect most others) also discovered
it when things like Git and SVN (and Bugzilla) stopped working.

I've CC'd the gcc list to let others know (not sure what list
to subscribe to in order to get a heads up on these kinds of
maintenance issues).

Martin



Software error:

Can't connect to the database.
Error: Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2)
  Is your database installed and up and running?
  Do you have the correct username and password selected in localconfig?


For help, please send mail to the webmaster
(sourcemas...@sourceware.org), giving this error message and the time
and date of the error.

Unfortunately, the email address listed for the webmaster,
, sends me its own error message when I
try to email it, because the address apparently doesn't exist. I'm
forwarding a copy of the failure email with this message. Is there a
different address I should be emailing instead?

Thanks,
Eric Gallager

-- Forwarded message --
From: mailer-dae...@sourceware.org
Date: 14 Aug 2017 22:03:54 -
Subject: failure notice
To: eg...@gwmail.gwu.edu

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: 
Received: (qmail 24677 invoked by uid 89); 14 Aug 2017 22:03:52 -
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.5 required=5.0
tests=RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no
version=3.3.2 spammy=
X-Spam-Status: No, score=0.5 required=5.0
tests=RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no
version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level:
X-HELO: mail-wm0-f42.google.com
Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com)
(74.125.82.42)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon,
14 Aug 2017 22:03:51 +
Received: by mail-wm0-f42.google.com with SMTP id i66so3361599wmg.0
for ; Mon, 14 Aug 2017 15:03:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gwmail-gwu-edu.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=A6iFIzlnSazSObmM6Wb7tDW+ZAb4ojY1zG6bxpdCLCQ=;
b=cvRTbJxAB1UKTO01xqOGTtvgLjbLLOumX/FUdM3ruLkvMpJx6QiO7X51cU6X6jcx24
 ReoVRxaW8NwWcVJts9JB5tPJSg/8+ljL8ywMoa9Aa6S1MQ4PS246aVgKM5aUNmaB1E+u
 NrQMAmsxixJG/wmrAnSpQ/imIt7XNHRBNnZ5/B1JiGAt3ChjHwTNKV/9W4fxydsJL9BE
 iL9D/duAl6C/RAvBPQ5BC0Kv+/HtzhH8bwgElbjP93hMJk/nAfceI7Rh/4zIgY5V6ZHS
 E7LzrUetB7aeyzdlTy6i/3Lsyb0wnUuocZdZtGndQD24WSngk3fInlHwWrcUVdTpRMQ5
 e4tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=A6iFIzlnSazSObmM6Wb7tDW+ZAb4ojY1zG6bxpdCLCQ=;
b=GQbdg3EVSV+aMfKeSffGxae54jos3nNUt3qQWoSthUOEFy57YAeV5Fn86IOYLTw4fI
 gZKi7samoFHs0yHdF4sawi+xVMfZMzGPqGrJjsAIHYSE9T+o9vx0cEJPhPs0rswqinCO
 WovmT8Kh1jNEaIyxLwZGk07lt5oyWTk72zaT+CxWjamKbLJzDfqWMfpahDuTVI74QQie
 m8qtMTBQjek1Di51mxiBcuaLlr1xNqwrVS3JQEjdl2NCOBEDodLosGkUJCFR29hw6EAK
 ag3Lo96yUeNlfjOXv8/FYbCTrbcrhxbms02n0p3oK3cSHkoqZKcUOQQJzuNq0c38W9PU
 6A0w==
X-Gm-Message-State: AHYfb5ilSTxPFsi8yTAJsSJ6LpZu+DahzJygxoF6Q5usa2PIRZDQhD5i
b5akwEZnwfnttac6yAR/os3Kbj3Gqwbh
X-Received: by 10.80.215.68 with SMTP id i4mr25610854edj.258.1502748228995;
 Mon, 14 Aug 2017 15:03:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.129.227 with HTTP; Mon, 14 Aug 2017 15:03:48 -0700 (PDT)
From: Eric Gallager 
Date: Mon, 14 Aug 2017 18:03:48 -0400
Message-ID: 

Re: -Wformat-truncation outputs emtpy lines instead of source

[Martin Sebor]

On 05/02/2017 02:13 PM, Simon Sobisch wrote:

I'm responding here as it was "opened" in this list directly.
You were right, adding -fno-diagnostics-color doesn't show anything
empty, changing it to -fdiagnostics-color bring the nice colors in - and
the spaces instead of the code (yes, I've copied it directly from the
terminal).

I'm on the following machine:

hostname = mymachine-trisquel
uname -m = x86_64
uname -r = 3.13.0-116-lowlatency
uname -s = Linux
uname -v = #163+7.0trisquel2 SMP PREEMPT Thu Apr 6 13:16:46 UTC 2017

I've just got the latest revision 247521 from branch-gcc-7 and did a
recompile (this time using the GCC 7 that was previously built) and the
issue stays.

I've just placed the output into a vim stdin pipe and can see the source
+ its control attributes:

make 2>&1 | vim - -R -c 'set filetype=nomodified nomodifiable nonu'

^[[01m^[[K../../../cobc/typeck.c:1064:2:^[[m^[[K ^[[01;36m^[[Knote:
^[[m^[[K'^[[01m^[[Ksnprintf^[[m^[[K' output between 17 and 63 bytes into
a destination of size 17
  ^[[01;36m^[[Ksnprintf (buff, (size_t)17,
"%02d/%02d/%02d%02d%c%02d%c%02d",^M^[[m^[[K

^[[01;36m^[[K^~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.day_of_month,^M^[[m^[[K
   ^[[01;36m^[[K~~~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.month,^M^[[m^[[K
   ^[[01;36m^[[K^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.year % 100,^M^[[m^[[K
   ^[[01;36m^[[K~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.hour, '.',^M^[[m^[[K
   ^[[01;36m^[[K^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.minute, '.',^M^[[m^[[K
   ^[[01;36m^[[K~~^[[m^[[K
 ^[[01;36m^[[K  current_compile_time.second)^[[m^[[K;^M
   ^[[01;36m^[[K^[[m^[[K

The main question is: is this a GCC problem or a Trisquel problem?
If it is the later is there any option for GCC to recognize this problem?


From the above it looks like GCC does output the text suggesting
that the problem is not in it, but the GCC colorization is not my
area of expertise (I just wrote the -Wformat-truncation warning).
It's strange to me that you can see the tildes but not the plain
text. I would suggest to try a different terminal.  Otherwise,
post your question to gcc-help where people who know more about
these things than me can help you.

Martin



Simon
Am 02.05.2017 um 01:29 schrieb Martin Sebor:

On 05/01/2017 01:39 PM, Simon Sobisch wrote:

Hi,

I've just got GCC7 (build from svn worked like a charm, even if it
took hours but I was warned) and like the new warnings and hints very
much.

When compiling GnuCOBOL from vcs (sources on mount, therefore the long
path) I got one warning with multiple and very long tilde lines.

/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c: In
function 'cb_build_registers':
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:30:
warning: 'snprintf' output may be truncated before the last format
character [-Wformat-truncation=]
  snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
  ^~~~
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:2: note:
'snprintf' output between 17 and 63 bytes into a destination of size 17

  ^~

   ~~~

   

   ~

   

   ~~
   current_compile_time.second);
   

It looks like the source in the lines between are missing (the number
of tildes is correct).
The source reads:

snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
current_compile_time.day_of_month,
current_compile_time.month,
current_compile_time.year % 100,
current_compile_time.hour, '.',
current_compile_time.minute, '.',
current_compile_time.second);


Hmm, that's quite odd.  I'm not able to reproduce this "effect"
and I have never seen anything like it.  My first thought was
that it could be a problem with the terminal you are using (try
compiling with -fno-diagnostics-color to see if it improves)
but since you presumably copied the error message above from
the terminal that's probably not going to help.  If it doesn't,
can you please create a new bug and attach to it a preprocessing
translation unit (compile the source file with -E and save the
output)?  Also include the full set of command line options you
invoked the compiler with when you got the "invisible" message.

[...}

Martin

Re: -Wformat-truncation outputs emtpy lines instead of source

[Martin Sebor]

On 05/01/2017 01:39 PM, Simon Sobisch wrote:

Hi,

I've just got GCC7 (build from svn worked like a charm, even if it took hours 
but I was warned) and like the new warnings and hints very much.

When compiling GnuCOBOL from vcs (sources on mount, therefore the long path) I 
got one warning with multiple and very long tilde lines.

/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c: In function 
'cb_build_registers':
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:30: 
warning: 'snprintf' output may be truncated before the last format character 
[-Wformat-truncation=]
  snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
  ^~~~
/media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:2: note: 
'snprintf' output between 17 and 63 bytes into a destination of size 17

  ^~

   ~~~

   

   ~

   

   ~~
   current_compile_time.second);
   

It looks like the source in the lines between are missing (the number of tildes 
is correct).
The source reads:

snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d",
current_compile_time.day_of_month,
current_compile_time.month,
current_compile_time.year % 100,
current_compile_time.hour, '.',
current_compile_time.minute, '.',
current_compile_time.second);


Hmm, that's quite odd.  I'm not able to reproduce this "effect"
and I have never seen anything like it.  My first thought was
that it could be a problem with the terminal you are using (try
compiling with -fno-diagnostics-color to see if it improves)
but since you presumably copied the error message above from
the terminal that's probably not going to help.  If it doesn't,
can you please create a new bug and attach to it a preprocessing
translation unit (compile the source file with -E and save the
output)?  Also include the full set of command line options you
invoked the compiler with when you got the "invisible" message.



Thank you for this compiler!
Simon

BTW: is it really useful to have the complete function in the output message?
The output may get *very* long...


You mean the complete function call in the note, including
the arguments?  GCC tries to provide as much useful context
in diagnostic messages as necessary to help users see their
root cause.  The trend has been toward more verbose messages,
and so some message can get long (that's especially true for
C++ code heavy on templates).  In this case, showing the full
call is probably not particularly helpful but I have never
though about it as being a problem.  Each diagnostic message
printed by GCC is associated with some location in the source
code, often a declaration or a full expression, but sometimes
a subexpression.  In this case the choice is between the location
of the format string and that of the function call. The warning
is associated with the location of the format so the note is
attached to the whole call.  Off the top of my head I can't
think of anything else to attach it to that would make sense.

Martin

PS gcc-bugs is used for automated emails sent in response to
changes to the GCC Bugzilla.  Please use gcc-help for questions
about GCC (or open new bugs for suspected defects).

Re: Was gcc-2.95.2 EH thread-safe ?

[Martin Sebor]

Eric Noulard wrote:

I shall maintain
an HW/SW configuration
running Linux 2.2.14 / glibc 2.1.2 / LinuxThread 0.8

I have a C++ application compiled using gcc 2.95.2
which has several thread that may throw exception.

I experience weird and not 100% repeatable mis-behaviour of
the application which is hogging all CPU-time.
(some threads are SCHED_RR)

Which leads me to the question:

Was the C++ Exception Handling thread-safe in gcc 2.95.2.


Based on the result of our configuration test I would have
to say no. Try it and see: http://tinyurl.com/yl5dxw.

Martin



I wonder because gcc-2.95.2/gcc/except.c tells:




  The mechanism in C++ for handling data associated with the
  exception is clearly not thread-safe. For a thread-based
  environment, another mechanism must be used (possibly using a
  per-thread allocation mechanism if the size of the area that needs
  to be allocated isn't known at compile time.)





Whereas

gcc-4.1.1/gcc/except.c does not.

I know there are MANY gcc release between those two but I would be glad
if any GCC historian may tell me what was the first C++ EH thread-safe
version of gcc?

Re: error building 4.1 on Solaris 9

[Martin Sebor]

Martin Sebor wrote:

Andrew Pinski wrote:



On Mar 1, 2006, at 7:48 PM, Martin Sebor wrote:


Is there a recommended version of GNU binutils for 4.1? I have been
using 2.13 but the latest compiler doesn't seem to be happy with it.
I tried the latest, 2.16.1, but I get the same error with it as well.
I don't see anything about this in INSTALL/specific.html.




You did not follow directions.



Guilty as charged. I guess I never have and I've just been getting
away with it (that is, until now).



 From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13486:

- You must tell the configure script that you use GNU binutils and not 
the Sun

tools. See http://gcc.gnu.org/install/configure.html



Thank you. Using the options --with-gnu-as --with-gnu-ld fixed the
error.


But only to build the compiler, not when running the installed gcc.
I see I still missed something: the rules for finding the assembler
and linker used by the installed compiler.

It seems that the rules to find these utilities are different when
building than when using the compiler. When building gcc, it looks
for them in PATH. When using gcc, it considers system directories
first.

Btw., is there a way to switch between the native and GNU assembler
and linker without rebuilding the compiler? It seems that 4.1 with
the GNU utilities is a lot slower than 4.0.2 was when using the
native ones (I wasn't actually using the GNU utilities with 4.0.2
despite what I said before).

Martin

error building 4.1 on Solaris 9

[Martin Sebor]

Is there a recommended version of GNU binutils for 4.1? I have been
using 2.13 but the latest compiler doesn't seem to be happy with it.
I tried the latest, 2.16.1, but I get the same error with it as well.
I don't see anything about this in INSTALL/specific.html.

Here's the error I get (building 4.1 with 4.0.2):

/usr/local/binutils-2.13/bin/ld:libgcc/./libgcc.map: file format not 
recognized; treating as linker script

/usr/local/binutils-2.13/bin/ld:libgcc/./libgcc.map:1: parse error
collect2: ld returned 1 exit status
make[3]: *** [libgcc_s.so] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory `/build/sebor/gcc-4.1.0-build/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/build/sebor/gcc-4.1.0-build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/build/sebor/gcc-4.1.0-build/gcc'
make: *** [bootstrap] Error 2

Martin

Re: error building 4.1 on Solaris 9

[Martin Sebor]

Andrew Pinski wrote:


On Mar 1, 2006, at 7:48 PM, Martin Sebor wrote:


Is there a recommended version of GNU binutils for 4.1? I have been
using 2.13 but the latest compiler doesn't seem to be happy with it.
I tried the latest, 2.16.1, but I get the same error with it as well.
I don't see anything about this in INSTALL/specific.html.



You did not follow directions.


Guilty as charged. I guess I never have and I've just been getting
away with it (that is, until now).



 From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13486:

- You must tell the configure script that you use GNU binutils and not 
the Sun

tools. See http://gcc.gnu.org/install/configure.html


Thank you. Using the options --with-gnu-as --with-gnu-ld fixed the
error.


- You don't follow the Solaris-specific instructions to build GCC. See
http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2*


I had read this but I didn't see anything relevant and I still
don't even after rereading it. Could you be more specific about
which part I should follow? (The build went fine, I just want
to be sure I don't run into something down the line.)

Thanks
Martin

Re: [Bug c++/26062] New: Class object(); is not interpreted as a call to default constructor

[Martin Sebor]

sylvain dot joyeux at m4x dot org wrote:

The following testcase

#include iostream

bool flag = true;
class guardian
{
public:
guardian() { flag = false; }
~guardian() { flag = true; }
bool get() { return flag; }
};

int main()
{
guardian guard();
std::cout  guard.get()  std::endl;
std::cout  flag  std::endl;
}

Leads to the error
error: request for member 'get' in 'guard', which is of non-class type
'guardian ()()'


FWIW, here's the HP aCC 3 error message for this program. Does it make
it clear where the problem is?

Error 583: t.cpp, line 15 # Left side of '.' requires a class object; 
type found was a function 'guardian ()'. Did you try to declare an 
object with a nested constructor call? Such a declaration is interpreted 
as a function declaration guardian

guard() [t.cpp, line 14].
std::cout  guard.get()  std::endl;
 ^

Martin

behavior of -E with -g3

[Martin Sebor]

I was surprised to see macro definitions in the output of gcc
-E -g3 (see below). Is that behavior by design or is it a bug?
(I haven't seen anything about it in the manual, other than what
-g/leve/ mentions about debugger support for macro expansion).
Thanks
Martin
$ cat t.cpp  gcc -E t.cpp -g3 | grep -v #define __
#define FOO bar
# 1 t.cpp
# 1 /tmp//
# 1 built-in
#define sparc 1
#define unix 1
#define sun 1
#define _XOPEN_SOURCE 500
#define _LARGEFILE_SOURCE 1
#define _LARGEFILE64_SOURCE 1
# 1 command line
# 1 t.cpp
#define FOO bar

-Winline: function body not available

[Martin Sebor]

Could someone help me understand what's causing the following
warning so that I can silence it? Gcc 3.4.3 emits it for an
implicitly inline one-line definition of the function (ctor,
actually, see below), so I'm not sure what the function body
not available bit is supposed to mean. The base ctor is also
a one liner defined completely inline. The base derives from
two other class, one of whose ctor is outlined and the other
is trivial (i.e., compiler generated).
I've searched Bugzilla but couldn't find anything relevant.
Thanks
Martin
_codecvt.h:436:line: warning: inlining failed in call to 
'std::codecvt_byname_InternT, _ExternT, _StateT::codecvt_byname(const 
char*, unsigned int) [with _InternT = char, _ExternT = char, _StateT = 
mbstate_t]': function body not available
codecvt.cpp:262: warning: called from here

template class _InternT, class _ExternT, class _StateT
class codecvt_byname: public codecvt_InternT, _ExternT, _StateT
{
char _C_namebuf [32];
public:
typedef _InternT intern_type;
typedef _ExternT extern_type;
typedef _StateT  state_type;
_EXPLICIT codecvt_byname (const char *__name, _RWSTD_SIZE_T __ref = 0)
: codecvt _InternT, _ExternT, _StateT (__ref) {
this-_C_set_name (__name, _C_namebuf, sizeof _C_namebuf);
}
};

Re: -Winline: function body not available

[Martin Sebor]

Andrew Pinski wrote:
On Mar 25, 2005, at 7:59 PM, Martin Sebor wrote:
Could someone help me understand what's causing the following
warning so that I can silence it? Gcc 3.4.3 emits it for an
implicitly inline one-line definition of the function (ctor,
actually, see below), so I'm not sure what the function body
not available bit is supposed to mean. The base ctor is also
a one liner defined completely inline. The base derives from
two other class, one of whose ctor is outlined and the other
is trivial (i.e., compiler generated).
I've searched Bugzilla but couldn't find anything relevant.

This is either PR 17248 or PR 14950.  This is only a bug in 3.4.x.
Thanks for the pointers. I saw those two but they seemed different.
I don't get the sorry, unimplemented and I don't have any
__attribute__((always_inline)) anywhere. But from 14950, comment
#13 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950#c13) it
sounds like it actually might be the same thing (I hadn't read
that far before).
In any case, it doesn't seem like there is a known way to silence
the warning, is there? (Other than by a command line switch).
Martin

Re: Rq4Clarification: std::uncaught_exception

[Martin Sebor]

Attila Feher F (JO/LMF) wrote:
Hi,
I have been reading http://gcc.gnu.org/bugs.html, but I cannot figure out if 
the bug I have found in the way std::uncaught_exception works is a gcc or a 
libstdc++ bug.  Since the faulty behavior is the same with MinGW and Linux 
native gcc, I guess it is a language/compiler issue.
(The bug is that std::uncaught_exception returns false in a corner case, when 
the standard asks for true return.  I think it is probably the least important 
issue, but I still would like to get it registered somewhere.)
Please let me know where should I report this bug!
You might find this bug report helpful:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10606
Martin

Re: aren't specialized templates templates?

[Martin Sebor]

Tim Janik wrote:
hi all.
the code snippet below is extracted from a much more
complicated piece of code. basically the problem is that
g++ (3.3 and 3.4) demand different typedef syntax inside
template bodies, depending on whether full or partial
specialization is used.
is this really the correct behaviour and standard conform?
(to me it seems, line20 should still be considered part of
a template and thus accept the typename)
Unfortunately, it is the correct behavior. But because it makes
typename hard to use, a relaxation of the rule that would make
your code well-formed is now being considered. For the status
of this proposed change see:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#382
Martin
snip-
templateclass C
struct Base {
  typedef C* Iterator;
};
templateclass C, class D
struct Derived : BaseD {
  typedef typename BaseD::Iterator Iterator;
};
#define BASE_ITER(BASE) typename BASE :: Iterator
templateclass D
struct Derivedchar, D : BaseD {
  typedef BASE_ITER (BaseD) Iterator; // line15
};
template
struct Derivedchar, int : Baseint {
  typedef BASE_ITER (Baseint) Iterator;   // line20
};
// test.cc:20: error: using `typename' outside of template
snip-
---
ciaoTJ

Re: [Bug c++/19172] strcpy bug? or mine?

[Martin Sebor]

rolosworld at gmail dot com wrote:
--- Additional Comments From rolosworld at gmail dot com  2004-12-28 01:00 
---
(In reply to comment #1)
You forgot C strings are null terminated.

I did this:
  word = new char( strlen(str) + 1 );
Don't you mean new char [strlen(str) + 1]? I.e., brackets, not
parentheses (the latter allocates a single char and initializes
it with the length of str).
Martin