Yes i did... i always do and have never had a problem doing so before.
I will try building in a different directory though and report back.
http://gcc.gnu.org/install/configure.html
To be honest I'm always surprised when it works at all.
Ok, that fixed it, thanks.
Maybe a warning
This patch fixes PR/1025. It also shows up on many platforms where
indirect symbols aren't handled properly, like
http://gcc.gnu.org/ml/gcc/2005-06/msg00842.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109
Those platforms need similar patch.
H.J.
-
2005-06-19 H.J. Lu [EMAIL
Mark Williams (MWP) wrote:
Thought i should report this...
Building 4.0.1 RC2, i get this error:
make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl'
Looks like you're trying to build GCC in the source
folder itself - this is not supported (yet).
Try creating a
PR 22111 is about libstdc++-v3 being built with binutils 2.15, while
2.15.90 or later are required by the patch.
I say we solve this instead by enabling the abi checking rule only for
those platforms that are using symbol versioning. In addition, we try
to come up with an autoconf macro that
[Gaby wants Vincent to explain:]
Vincent Lefevre [EMAIL PROTECTED] writes:
# This is complete non-sense. One doesn't prepare a patch for an invalid
# bug.
[Michael tries to interpret Vincent:]
| I think that what Vincent meant was:
| One doesn't prepare a patch for a PR marked as INVALID.
On Jun 20, 2005 09:51 AM, Michael Veksler [EMAIL PROTECTED] wrote:
Despite being descriptive and friendly, bug masters
frustrate me and other users by being too eager
to close the PR. I would suggest a policy change,
a PR should be closed (as duplicate or as INVALID)
only after discussion
On Sun, Jun 19, 2005 at 06:49:32PM -0400, Bill wrote:
Below is the error I receive when attempting to run a newly installed
version of netscape 4.79 on centOS 4.0 (RHEL 3), which is my personal
computer at home. This is the only browser that works on linux that is
compatible with the Thorium
Paul Schlie wrote on 20/06/2005 08:55:20:
y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2]
Invalid syntax, what did you mean?
I guess I simply believe that optimizations should never alter the
logical
behavior of a specified program relative to it's un-optimized form unless
Mike Stump [EMAIL PROTECTED] writes:
On Friday, June 17, 2005, at 07:13 AM, Sergei Organov wrote:
The first thing I'd like to get some advice on is which codebase do I
use, gcc-4_0-branch?
No, mainline. If it doesn't work there, is won't work anyplace else. :-(
Once you get it working
Paul Schlie wrote:
My position is simply that an optimization should never remove a specified
operation unless it is known to yield logically equivalent behavior, as
producing a program which does not behave as specified is not a good idea
That may be your position, but it is not the position
Robert Dewar wrote:
That may be your position, but it is not the position of the standard, and
indeed it is not a well-formed position. Why, because the whole point is
that
when the behavior is undefined, then the change DOES yield a logically
equivalent behavior, because undefined means
On Mon, 20 Jun 2005, Mark Williams (MWP) wrote:
Yes i did... i always do and have never had a problem doing so before.
I will try building in a different directory though and report back.
http://gcc.gnu.org/install/configure.html
To be honest I'm always surprised when it
From: Michael Veksler [EMAIL PROTECTED]
Paul Schlie wrote on 20/06/2005 08:55:20:
y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2]
Invalid syntax, what did you mean?
Sorry, meant:
y = z + x; // y == [INT_MIN, INT_MAX] + [1, 2] == [INT_MIN+1, INT_MAX+2]
I guess I simply believe that
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
My position is simply that an optimization should never remove a specified
operation unless it is known to yield logically equivalent behavior, as
producing a program which does not behave as specified is not a good idea
That may be
From: Robert Dewar [EMAIL PROTECTED]
Robert Dewar wrote:
That may be your position, but it is not the position of the standard, and
indeed it is not a well-formed position. Why, because the whole point is
that
when the behavior is undefined, then the change DOES yield a logically
Paul Schlie wrote:
As in my mind, the semantics of foo() dictate that it print the value of
the storage location which was allocated to the variable a, where unless
a is initialized with an explicit value, may be arbitrary. So I've got no
problem with arbitrary results or behavior, I just
Paul Schlie wrote:
I too believe I understand your position, however don't believe it's the
compiler's job to make life for the programmer harder than it need be when
a program may contain an undefined behavior; but agree it would likely
always be helpful to for it to point them out when
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
As in my mind, the semantics of foo() dictate that it print the value of
the storage location which was allocated to the variable a, where unless
a is initialized with an explicit value, may be arbitrary. So I've got no
problem with
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
I too believe I understand your position, however don't believe it's the
compiler's job to make life for the programmer harder than it need be when
a program may contain an undefined behavior; but agree it would likely
always be
Michael Veksler [EMAIL PROTECTED] writes:
| [Gaby wants Vincent to explain:]
| Vincent Lefevre [EMAIL PROTECTED] writes:
| # This is complete non-sense. One doesn't prepare a patch for an invalid
| # bug.
|
| [Michael tries to interpret Vincent:]
| | I think that what Vincent meant was:
| |
Paul Schlie wrote:
- You may be correct, although it's not obviously the case? (As requiring
all undefined behavior be encapsulated between sequence points already
seems implied to me, as I don't see any explicit counter examples
requiring otherwise.
There don't need to be examples.
Michael Veksler wrote:
Getting a consistent definition of bounded side-effects
is a nontrivial task. Simply hacking and patching the
definition does not work. Trust me, I've been there done
that, got burnt and are still paying for my sins.
Indeed! I think anyone who has been involved in the
Paul Schlie wrote on 20/06/2005 14:13:33:
From: Robert Dewar [EMAIL PROTECTED]
...
Note that in the cases where something is statically optimized away
(these
are the easy cases), it is nice if the compiler warns that this is
happening
(that would certainly be the case in Ada in the
Michael Veksler wrote:
As for overflow, you can say that you want instead of undefined
to treat is unspecified.
In Ada 95 we introduced a new category of behavior, called a bounded
error. We tried to recategorize as many erroneous (= C undefined)
cases as possible to bounded error.
A
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
- You may be correct, although it's not obviously the case? (As requiring
all undefined behavior be encapsulated between sequence points already
seems implied to me, as I don't see any explicit counter examples
requiring
I checked in the following patch to fix PR 1022.
H.J.
2005-06-20 H.J. Lu [EMAIL PROTECTED]
PR 1022
* elf32-hppa.c (elf32_hppa_check_relocs): Handle indirect
symbol.
--- bfd/elf32-hppa.c.got2005-05-19 06:51:55.0 -0700
+++ bfd/elf32-hppa.c
Paul Schlie wrote:
There don't need to be examples. The as-if rule always applies, if you cannot
write a legitimate C program that shows the difference between two possible
implementations, then both are correct.
??? as-if means they're logically equivalent (i.e. there is no logical
Paul Schlie wrote:
- yes, effectively I don't perceive any necessity for undefined, vs
unspecified; as I don't perceive any necessity to give the compiler
the freedom to treat generate an arbitrary program which may contain
a potentially ambiguous specific and isolatable behavior.
OK, then
Robert Dewar wrote:
Yes, absolutely, a compiler should generate warnings as much as possible when
it is making these kind of assujmptions.
Then, you will like the following kind of patches:
Index: tree-data-ref.c
===
RCS file:
Hi,
Using gcc compiled from gcc-4_0-branch, in an attempt to see which
particular optimization option makes my test case to be mis-optimized, I
try to replace -O1 (which toggles on the problem) with corresponding set
of -fxxx optimization options. I first compile my code like this:
gcc -v
Sergei Organov writes:
Hi,
Using gcc compiled from gcc-4_0-branch, in an attempt to see which
particular optimization option makes my test case to be mis-optimized, I
try to replace -O1 (which toggles on the problem) with corresponding set
of -fxxx optimization options.
In general
Sergei Organov wrote:
Using gcc compiled from gcc-4_0-branch, in an attempt to see which
particular optimization option makes my test case to be mis-optimized,
This sort of problem is exactly what my Acovea program was designed for;
it will identify the pessimistic option by analyzing GCC's
On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote:
How one finds out what optimization pass misbehaves?
Look at the dumps. If you use the gcc option -da you'll get a full
set of RTL dump files.
And -fdump-tree-all for the tree dumps.
Thanks,
Andrew Pinski
On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote:
2. The resulting assembly is different from what I get with -O1 and
doesn't contain the mis-optimization I'm trying to debug though it
doesn't seem to have anything to do with loops. For reference, the
code I'm trying to compile is:
Paul Schlie [EMAIL PROTECTED] wrote on 20/06/2005 16:09:16:
From: Michael Veksler [EMAIL PROTECTED]
As for overflow, you can say that you want instead of undefined
to treat is unspecified. Where each architecture / opsys / compiler
must consistently define what happens on overflow:
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote:
How one finds out what optimization pass misbehaves?
Look at the dumps. If you use the gcc option -da you'll get a full
set of RTL dump files.
And -fdump-tree-all for the tree dumps.
The last
Richard Henderson [EMAIL PROTECTED] wrote on 20/06/2005 01:13:11:
On Sun, Jun 19, 2005 at 11:46:52PM +0300, Dorit Naishlos wrote:
The thought was to supply an API that would let the vectorizer ask for
the
minimal capability it needs - if all we need is a vector shift of a
constant value
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when
-O1
is turned on. Seems to be something at tree-to-RTX conversion time.
Constant folding?
No, it would mean that the target says that this is not a small data.
Also try
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote:
2. The resulting assembly is different from what I get with -O1 and
doesn't contain the mis-optimization I'm trying to debug though it
doesn't seem to have anything to do with loops. For
On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when
-O1
is turned on. Seems to be something at tree-to-RTX conversion time.
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
is turned on. Seems
On Jun 20, 2005, at 11:39 AM, Daniel Berlin wrote:
This is blocking me fixing the structure aliasing regressions.
This was caused by:
2005-06-15 Joseph S. Myers [EMAIL PROTECTED]
* c-tree.h (default_function_array_conversion): Declare.
* c-typeck.c
It is my strong preference to not do macro defines in c++config.h as
per your last patch.
Strike this, it's incorrect. Sorry Jakub.
If doing this gets around the bad link behavior, at this point, I'm
for it. I suggest you put in a link to 22109 to your patch. Then, the
patches for 22109 and
On Jun 20, 2005, at 11:39 AM, Daniel Berlin wrote:
This is new, i assume.
This is blocking me fixing the structure aliasing regressions.
I've attached pex-unix.i. Compile with -pendantic to see the crash.
Here is a reduced testcase:
typedef union
{
union wait *__uptr;
int
On Mon, 20 Jun 2005, Daniel Berlin wrote:
The crash line is
3729 if (pedantic !DECL_IN_SYSTEM_HEADER (fundecl))
Here, fundecl is null.
Any problem with fundecl being null should also be reproducible with a
call through a function pointer where fundecl would never have been
On Mon, 2005-06-20 at 16:05 +, Joseph S. Myers wrote:
On Mon, 20 Jun 2005, Daniel Berlin wrote:
The crash line is
3729 if (pedantic !DECL_IN_SYSTEM_HEADER (fundecl))
Here, fundecl is null.
Any problem with fundecl being null should also be reproducible with a
Knowing that you do regular Cygwin builds of gcc, I wonder can you advise
me, please? For the better part of a month, I have not succeeded in
building gcc from the CVS tree under Cygwin_NT-5.1 for one reason or
another.
That's PR 21766 (appropriately named Bootstrap failure on
Thanks Francois-Xavier and Andrew for replying,
That's PR 21766 (appropriately named Bootstrap failure on
i686-pc-cygwin). Opened almost a month ago. GCC mainline doesn't
build on cygwin or mingw since that time.
Seeing that almost no comment had been made by the maintainers on it,
and no
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
Andrew Pinski [EMAIL PROTECTED] writes:
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
is turned on. Seems
Then, you will like the following kind of patches:
+ warning (0, %H undefined behavior if loop runs for more than %qE
iterations,
+find_loop_location (loop), estimation);
I think we would like them better if you could choose to silence them,
especially when people use
[EMAIL PROTECTED] (Tommy Vercetti) wrote on 19.06.05 in [EMAIL PROTECTED]:
I was looking on different ones, for C, that claimed to have ability to find
security problems. One that I found the best, is splint. But it's still not
able to find such obvious problem:
Did you look at sparse? That
[EMAIL PROTECTED] (Robert Dewar) wrote on 19.06.05 in [EMAIL PROTECTED]:
Kai Henningsen wrote:
But at least, in that case, the compiler could easily issue the
(presumably not required by the standard) warning that the else branch is
unreachable code.
Yes, absolutely, a compiler should
On Monday 20 June 2005 10:12, Kai Henningsen wrote:
[EMAIL PROTECTED] (Tommy Vercetti) wrote on 19.06.05 in
[EMAIL PROTECTED]:
I was looking on different ones, for C, that claimed to have ability to
find security problems. One that I found the best, is splint. But it's
still not able to
On Jun 16, 2005, at 3:06 PM, Mike Stump wrote:
Actually, by try, I meant try your application. :-)
I can't seem to build any 64-bit shared library on powerpc-apple-
darwin8.1.0, although I can now run the test suite more effectively; see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
General note, please, this list is for developers of gcc to develop
gcc. Using it as a way to teach yourself how to read the C standard,
isn't ok, please stop.
On Saturday, June 18, 2005, at 07:15 AM, Paul Schlie wrote:
Maybe I didn't phrase my statement well;
I think you did, you are
On Jun 18, 2005, at 11:50 AM, Paul Schlie wrote:
[ curiously can't find any actual reference stating that integer
overflow
is specifically results in undefined behavior, although it's
obviously ill defined?
Every operation that isn't defined is undefined. Only the operations
that are
--- Additional Comments From hjl at lucon dot org 2005-06-20 06:23 ---
It is a linker bug. I posted a patch for ia32/x86_64:
http://sourceware.org/ml/binutils/2005-06/msg00500.html
--
What|Removed |Added
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-20 06:39
---
Ugh. Well, that's that way it used to work apparently now it's different.
Here, this gets to the same place, and removes some misleading bits in the
current configury.
-benjamin
--
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-20 06:39
---
Ugh. Well, that's that way it used to work apparently now it's different.
Here, this gets to the same place, and removes some misleading bits in the
current configury.
-benjamin
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-20
06:48 ---
Subject: Bug 22111
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-20 06:48:28
Modified files:
libstdc++-v3 : ChangeLog Makefile.in acinclude.m4
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-20 07:04
---
We need a way to test for this in autoconf instead of just using a version
number.
Doing this seems hard. Can somebody smart figure it out while I'm sleeping?
-benjamin
--
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-06-20
07:25 ---
Apparently it has been decided that co-arrays will be included in the next
revision of the Fortran standard. See http://www.nag.co.uk/sc22wg5/ and
ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650/N1639.txt
When trying to compile gcc3.4.3 I get the following error
gmake[1]: Entering directory `/raid/tmp/gcc-3.4.3/gcc'
gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-
prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H -o cc1 \
c-parse.o c-lang.o
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-20
07:59 ---
So the regression is fixed on mainline. Changing subject and keyword.
Note that the ICE was apparently caused by a missing processing of the nested
procedure, probably middle-end rather than front-end
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-20
08:00 ---
Since ZCX is now the default on darwin and linux, and since I doubt
anyone will look at __builsetjmp/longjmp issues on GCC 4.x, I am
closing this PR.
--
What|Removed
--- Additional Comments From dcb314 at hotmail dot com 2005-06-20 08:10
---
I fiddled with the supplied patch, and got this
--- expr.c.sav 2005-06-18 14:45:34.0 +0100
+++ expr.c 2005-06-19 11:19:02.0 +0100
@@ -5537,6 +5537,20 @@
tree low_bound = (domain
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-20
08:12 ---
Closing, as discussed, it would be an undesirable performance hit to make
changes
in this area.
Arno
--
What|Removed |Added
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-20
08:48 ---
(In reply to comment #2)
This was fixed by reverting the patch which caused this.
Which patch was this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21848
--- Additional Comments From falk at debian dot org 2005-06-20 09:36
---
(In reply to comment #5)
I fiddled with the supplied patch, and got this
--- expr.c.sav2005-06-18 14:45:34.0 +0100
+++ expr.c2005-06-19 11:19:02.0 +0100
@@ -5537,6 +5537,20 @@
--- Additional Comments From Ralf dot Wildenhues at gmx dot de 2005-06-20
09:38 ---
Thanks a lot for fixing this so promptly. I can confirm that the code which
triggered this compiles now and seems to be working fine again with CVS HEAD.
(BTW, even with its share of bugs, CLN might be
--- Additional Comments From pcarlini at suse dot de 2005-06-20 10:39
---
Up-to-date baselines are now both in 4_0-branch and mainline.
--
What|Removed |Added
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-20
10:56 ---
The patch is ok, it removes the testsuite failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
12:04 ---
the linking is picking up the wrong libintl.
*** This bug has been marked as a duplicate of 12482 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
12:04 ---
*** Bug 22126 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
12:09 ---
(In reply to comment #3)
(In reply to comment #2)
This was fixed by reverting the patch which caused this.
Which patch was this?
2005-05-31 Pat Haugen [EMAIL PROTECTED]
* loop.c
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-20
13:05 ---
(In reply to comment #4)
2005-05-31 Pat Haugen [EMAIL PROTECTED]
* loop.c (loop_invariant_p, valid_initial_value_p): Revert last
change.
The last change was:
2005-05-30 Pat Haugen
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-20
13:21 ---
P.S.: I realize now that the code in gcc/java/jcf-io.c is no longer miscompiled
for i686-pc-linux-gnu because the memory addresses contain stack pointer
references, and the stack pointer is a fixed
--- Additional Comments From dir at lanl dot gov 2005-06-20 13:33 ---
My example no longer crashes on powerpc-apple-darwin7.9.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20970
--- Additional Comments From hjl at lucon dot org 2005-06-20 13:40 ---
I checked in the linker patch to fix it.
--
What|Removed |Added
Status|NEW
--- Additional Comments From dir at lanl dot gov 2005-06-20 13:46 ---
PR21083 ,also, works Ok on the powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20970
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
14:46 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01667.html.
--
What|Removed |Added
--- Additional Comments From abilalh at yahoo dot com 2005-06-20 14:52
---
(In reply to comment #7)
I think you're trying to configure and compile GCC in
the source folder. Unfortunately, this is not yet supported.
Try creating a new folder totally outside of the GCC source
tree
--- Additional Comments From ro at techfak dot uni-bielefeld dot de
2005-06-20 15:18 ---
Subject: Re: New IRIX 6.5 testsuite failures with gas: .space repeat count is
zero, ignored
echristo at redhat dot com writes:
Did you happen to catch where the .space 0 were being emitted
On Jun 20, 2005, at 11:39 AM, Daniel Berlin wrote:
This is blocking me fixing the structure aliasing regressions.
This was caused by:
2005-06-15 Joseph S. Myers [EMAIL PROTECTED]
* c-tree.h (default_function_array_conversion): Declare.
* c-typeck.c
On Jun 20, 2005, at 11:39 AM, Daniel Berlin wrote:
This is new, i assume.
This is blocking me fixing the structure aliasing regressions.
I've attached pex-unix.i. Compile with -pendantic to see the crash.
Here is a reduced testcase:
typedef union
{
union wait *__uptr;
int
On Mon, 20 Jun 2005, Daniel Berlin wrote:
The crash line is
3729 if (pedantic !DECL_IN_SYSTEM_HEADER (fundecl))
Here, fundecl is null.
Any problem with fundecl being null should also be reproducible with a
call through a function pointer where fundecl would never have been
--- Additional Comments From ovidr at users dot sourceforge dot net
2005-06-20 16:25 ---
I've tried to create a testcase but can't seem to get a crash or infinite loop
lockup.
Anyway, I think I understand conceptually what must be done, but in practice
I'm still unsure of how to go
I found that following program loops infinitely on SPARC if it is optimized.
% uname -a
SunOS mule 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-80
% cat tst.i
typedef unsigned int size_t;
extern int printf(const char *, ...);
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
typedef
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:04 ---
Hmm, why do you think getcontext should return twice?
It does not, GCC is emmitting correct asm for a normal function, why should
getcontext be different?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:05 ---
GCC is emmitting correct asm for a normal function, why should getcontext be
different?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
On Mon, 2005-06-20 at 16:05 +, Joseph S. Myers wrote:
On Mon, 20 Jun 2005, Daniel Berlin wrote:
The crash line is
3729 if (pedantic !DECL_IN_SYSTEM_HEADER (fundecl))
Here, fundecl is null.
Any problem with fundecl being null should also be reproducible with a
--- Additional Comments From akr at m17n dot org 2005-06-20 17:22 ---
It's because getcontext is similar to setjmp.
Since setjmp/getcontext doesn't save registers in register window, modifications
to the registers between first setjmp/getcontext return and longjmp/setcontext
call is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:27 ---
Does this work correctly with say Sun's compiler?
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-20
17:31 ---
Confirmed. This happens to work with 2.95.3 so we have a regression.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-20
17:32 ---
Does this work correctly with say Sun's compiler?
Yes it does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--- Additional Comments From akr at m17n dot org 2005-06-20 17:36 ---
Although I have no Sun's Compiler, I found some pragmas about header file in
SunOS:
#pragma unknown_control_flow(setjmp)
#pragma unknown_control_flow(_setjmp)
#pragma unknown_control_flow(sigsetjmp)
#pragma
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:36 ---
This is not a front-end bug. But I still think it accidentally worked in
2.95.3 or any compiler really
because why do we have to treat function special.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-20
17:43 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01685.html.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-20
17:46 ---
This is not a front-end bug.
I disagree, the front-end should automatically recognize the function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
1 - 100 of 142 matches
Mail list logo
