--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-27 06:56 ---
Created an attachment (id=12335)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12335&action=view)
Patch for saying SAVE_EXPRs are not lvalues
I looked into the history of lvalue_p and SAVE_EXPR has been there
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-27 06:40 ---
(In reply to comment #3)
> This only fails with the C front-end, here is a testcase that also compiles
> with the C++ front-end but only fails with the C front-end:
But I think that is only because the C++ front-end
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-27 06:37 ---
This only fails with the C front-end, here is a testcase that also compiles
with the C++ front-end but only fails with the C front-end:
static inline __attribute__((always_inline)) void ip_finish_output2(){}
void ip_
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-27 05:14 ---
#define STACK_BOUNDARY (16*BITS_PER_UNIT)
This is a target issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from bangerth at dealii dot org 2006-09-27 04:57 ---
Filing bug reports is certainly a good think no matter what happens:
a) If code is finally merged from the branch, we will have to go back to
these bug reports to make sure they're really fixed
b) If code is never mer
--- Comment #4 from bangerth at dealii dot org 2006-09-27 04:50 ---
This code can't work. The check() function is not a virtual function,
so calling
((&broken)->*func) ();
is translated to
( ((Base*)(&broken))->*func) ();
because func is of type
void (Base::*) (...)
Then, when you
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-27 04:42 ---
Can you give the output of gcc -v for powerpc-wrs-vxworks? I bet vxworks
enables altivec by default which means it is a dup still.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29248
--- Comment #4 from bangerth at dealii dot org 2006-09-27 04:30 ---
This is definitely firmly in the class of "extension to the language that
requires a thorough proposal to be presented to the standards committee"
things. I don't think anyone is even remotely interested in implementing
--- Comment #3 from atgraham at gmail dot com 2006-09-27 04:28 ---
Ack! Sorry--I had indicated the wrong target on that one. The target is
vxworks, not linux. My 4.1.1 powerpc-linux compiler *does* get this
optimization right. So something in the vxworks-specific code is causing this
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-27 04:08 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Use autoconf like the GNU coding style recommends.
>
> That is exactly the the main "gross hack" I refer to.
How is it a gross hack. Really what you are requ
--- Comment #2 from acahalan at gmail dot com 2006-09-27 04:03 ---
(In reply to comment #1)
> Use autoconf like the GNU coding style recommends.
That is exactly the the main "gross hack" I refer to.
Hacks like autoconf should not be necessary. People
also hack around the problem with cm
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-27 04:01 ---
Why do you think this is a bug? Again the options should not act this way at
all, it is a bit crazy to treat system headers different than normal headers.
In fact you can get different behavior when you do:
#includ
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-27 03:59 ---
This works for me on the mainline:
[EMAIL PROTECTED] gcc]$ ./cc1 -m32 -Os t.c -o - -quiet
.file "t.c"
.section".text"
.align 2
.globl foo
.type foo, @function
foo:
--- Comment #8 from acahalan at gmail dot com 2006-09-27 03:47 ---
(In reply to comment #5)
> Did you read the documention?
> Warning: if you use this switch, and num is nonzero, then you must build all
> modules with the same value, including any libraries. This includes the system
> li
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-27 03:26 ---
How did you configure 4.1.1?
I bet this is really a dup of bug 28966.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-27
03:23 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> Imagine building gcc itself with regparm 3. You probably don't want
> to mark up the gcc source to enable this, but ma
Consider the following two functions:
int foo() { return 1; }
void bar() {}
Disassembly when compiled with gcc 2.95.2: (-Os)
:
0: 38 60 00 01 li r3,1
4: 4e 80 00 20 blr
0008 :
8: 4e 80 00 20 blr
Disassembly when compiled with gcc 4.1.1: (-Os
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-27 02:53 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-27 02:51 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-27 02:51 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-27 02:51 ---
Maybe it is not invalid but still undefined so I don't think this should work
at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-27 02:47 ---
Confirmed reduced testcase:
static inline __attribute__((always_inline)) void ip_finish_output2(){}
static inline __attribute__((always_inline)) void ip_finish_output()
{
ip_fragment(ip_finish_output2);
ip_finish_o
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-27 02:44 ---
*** Bug 29247 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-27 02:44 ---
Mark as a dup of bug 19727.
*** This bug has been marked as a duplicate of 19727 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-27 02:44 ---
Actually this was fixed in 3.4.0.
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-27 02:41 ---
It warns for me with 4.1.2 and the mainline:
[EMAIL PROTECTED] regressions1]$ ~/gcc-4.1/bin/gcc ~/t2.c -W -Wall -S -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/pinskia/src/gcc/gcc-4.1/gcc
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-27 02:34 ---
(In reply to comment #4)
> Imagine building gcc itself with regparm 3. You probably don't want
> to mark up the gcc source to enable this, but marking up the system
> header files is definitely not an option.
Or even
A warning is missing. When functions differ by number of args,
a warning gets produced. None is provided for an ABI difference.
foo 0 $ cat mismatch.c
#ifdef TWO
typedef int(*fn_t)(int a, int b)__attribute__(( regparm(0) ));
#else
typedef int(*fn_t)(int a, int b, int c)__attribute__(( regparm(0) )
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-27 02:33 ---
Did you read the documention?
Warning: if you use this switch, and num is nonzero, then you must build all
modules with the same value, including any libraries. This includes the system
libraries and startup modules.
--- Comment #4 from acahalan at gmail dot com 2006-09-27 02:19 ---
(In reply to comment #3)
> (In reply to comment #2)
> First you should not be using options that change the ABI if you don't know
> what you are doing. because they change the ABI. Second, none of options you
> gave are r
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-09-27 02:14 ---
Subject: Re: ICE with -fipa-pta
>
>
> --- Comment #4 from micis at gmx dot de 2006-09-26 08:16 ---
> I don't want to offend you but I know that already because last time I
> reported
> a bug with -fipa-pt
--- Comment #41 from dberlin at gcc dot gnu dot org 2006-09-27 02:12
---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
On 26 Sep 2006 15:57:28 -, pcarlini at suse dot de
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #40 from pcarlini at suse dot d
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-09-27 02:11 ---
Subject: Re: -fno-strict-aliasing disables restrict
On 27 Sep 2006 02:07:50 -, acahalan at gmail dot com
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #5 from acahalan at gmail dot com 2006-09-27 02:07
--- Comment #5 from acahalan at gmail dot com 2006-09-27 02:07 ---
(In reply to comment #4)
> Except it is better just to fix your code for aliasing issues.
Yes, and all other bugs should be fixed as well.
This is often impractical. Is there even one large modern
kernel which is compil
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-09-27 01:26
---
Can you provide a small working example of what you are trying to do?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29240
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-27 00:55
---
The only solutions to this problem I see is to either:
1. close this bug and leave the test case deleted or
2. write a C function to query for disk space and if enough available, proceed
with the test.
I am lea
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-27 00:35 ---
Except it is better just to fix your code for aliasing issues. The reason why
restrict does not work without strict aliasing is because it needs aliasing
sets and the only way to get that is with strict aliasing.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-27 00:32 ---
Use autoconf like the GNU coding style recommends.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-27 00:32 ---
(In reply to comment #2)
First you should not be using options that change the ABI if you don't know
what you are doing. because they change the ABI. Second, none of options you
gave are really options because some p
--- Comment #3 from acahalan at gmail dot com 2006-09-27 00:18 ---
[EMAIL PROTECTED] is correct, it's a missed-optimization bug.
(if this isn't a bug, then no missed optimization is a bug)
--
acahalan at gmail dot com changed:
What|Removed |Added
--- Comment #2 from acahalan at gmail dot com 2006-09-27 00:15 ---
(In reply to comment #1)
> Yes those change the ABI which means don't use them unless you know what you
> are doing.
I damn well do know what I want to do, and gcc does not support it.
What, you expect me to edit the sy
Over the years, many gross hacks have been created to determine what header
files are available. Just as #ifdef is the solution to discovering if something
is defined, there should be a built-in solution for discovering if something is
successfully included. Ultimately this should be presented to t
--- Comment #2 from cummings at cacr dot caltech dot edu 2006-09-26 23:32
---
Yes, I read through both the gfortran and the older g77 documentation on this
before I posted my bug report. However, I am puzzled as to why there is no
support for this third optional argument to the signal(
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2006-09-26
23:27 ---
Created an attachment (id=12333)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12333&action=view)
revised libjava patch preventing double deincrementation
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #18 from raj dot khem at gmail dot com 2006-09-26 22:33 ---
Paul
The patch is also needed on gcc-4_1-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-26 22:29 ---
gfortran supports an intrinsic function and an intrinsic subroutine
as defined by g77. See the g77 documentation. These routines are
provided solely for backwards compatibility with g77, and I doubt
anyone will upda
--- Comment #7 from sebor at roguewave dot com 2006-09-26 21:43 ---
You're right, those weren't the best examples, but I still think they
illustrate the point. The code in them is plain ill-formed even though
it never gets executed, because it just doesn't make sense. deleting
an array a
--- Comment #2 from joseph at codesourcery dot com 2006-09-26 21:01 ---
Subject: Re: -fno-strict-aliasing disables restrict
On Tue, 26 Sep 2006, pinskia at gcc dot gnu dot org wrote:
> And this is not a bug, restrict can be ignored by a compiler in terms of
> optimization which is wha
--- Comment #2 from jmbnyc at gmail dot com 2006-09-26 20:58 ---
Subject: Re: bad relocation section name
As I suggested in my post, I am fully updated as of one hour ago. I
reported the problem to redhat last week and never received a
response. Do you have any idea what 'bad relocatio
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-26 20:56 ---
This code is invalid and should be rejected as the function types are
different.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-26 20:46 ---
collect2: ld terminated with signal 11 [Segmentation fault]
/usr/bin/ld: build/ia32.linux/gcc32/cc-g/subscribeClient.o: bad
relocation section name `'
This is most likely a bug in your binutils you have install.
I w
I continue to get the errors below when trying to link fairly straight forward
C++ programs. The same code will compile/link fine with the opposite compile
type (the two compile types are -O2 and -g). If I mod the code slighly, I can
usually narrow it down to a single line that when commented out a
--- Comment #1 from gcc-bklyn at sneakemail dot com 2006-09-26 20:42
---
Created an attachment (id=12332)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12332&action=view)
Test Case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29243
I know the attached code is horrible, but I inherited something like it at my
place of work.
The call through the "Broken" function pointer works correctly (e.g. doesn't
assert) on gcc 3.3 and gcc 3.4, but asserts on gcc 4.1.1 because the "this"
pointer is incorrect. If "mem_fun" is changed to be
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-26 20:32 ---
Yes those change the ABI which means don't use them unless you know what you
are doing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-26 20:28 ---
And this is not a bug, restrict can be ignored by a compiler in terms of
optimization which is what is happening with -fno-strict-aliasing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
A number of options, -mregparm=3 and -mrtd for example, change the calling
convention in ways that would be incompatible with normal system header files.
These options are thus useless outside of freestanding code. Distinct settings
should be available for the app itself and for other stuff.
Ideal
--- Comment #1 from gcc at tommay dot net 2006-09-26 19:40 ---
Created an attachment (id=12331)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12331&action=view)
Pre-processed output causing the fault.
Here's the pre-processed output to cause the fault.
--
http://gcc.gnu.org/b
This gcc command causes a segmentation fault. The pre-processed file this
output says to include in the bug report is far too large (675K) to inline in
this report, and I see no way to attach it to the report. Let me know if you
want me to email it or something.
gcc -v -save-temps -Wp,-MD,net/ip
Most other Linux Fortran compilers that I have used provide support for an
optional third argument to the intrinsic function signal(). This argument is
an integer flag that is passed to the handler function when it is called. Why
is there no support in gfortran for this optional third argument?
This really shouldn't happen. Rather than disabling the whole
analysis, -fno-strict-aliasing should should simply cause gcc
to use the (char*) rules for everything.
It can be useful to add "restrict", even if it is not
practical to find and fix all aliasing-related problems.
$ cat restrict.c
void
--- Comment #6 from pinskia at physics dot uc dot edu 2006-09-26 19:00
---
Subject: Re: inconsistent warning: deleting array
>
>
>
> --- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
> You mean something like: if (is_pointer (p)) delete p;
>
> I suppose
>
>
>
> --- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
> You mean something like: if (is_pointer (p)) delete p;
>
> I suppose that could happen but why should it be any different than other
> non-sensical but lexically valid constructs with undefined behavior that
--- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
You mean something like: if (is_pointer (p)) delete p;
I suppose that could happen but why should it be any different than other
non-sensical but lexically valid constructs with undefined behavior that
require a diagnos
--- Comment #2 from jakub at gcc dot gnu dot org 2006-09-26 18:11 ---
Subject: Bug 28790
Author: jakub
Date: Tue Sep 26 18:10:58 2006
New Revision: 117235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117235
Log:
PR middle-end/25261
PR middle-end/28790
*
--- Comment #5 from jakub at gcc dot gnu dot org 2006-09-26 18:11 ---
Subject: Bug 25261
Author: jakub
Date: Tue Sep 26 18:10:58 2006
New Revision: 117235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117235
Log:
PR middle-end/25261
PR middle-end/28790
*
--- Comment #9 from alfred dot minarik dot 1 at aon dot at 2006-09-26
18:08 ---
Hello, well I did the paperworks then
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01299.html
and resent after that with minor modification too
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00597.html
would
--- Comment #1 from jakub at gcc dot gnu dot org 2006-09-26 18:07 ---
Subject: Bug 29097
Author: jakub
Date: Tue Sep 26 18:06:55 2006
New Revision: 117234
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117234
Log:
PR fortran/29097
* scanner.c (include_line): Hand
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-26 17:47 ---
When I get home, I might have a look at this, most likely pt.c needs to be
extended.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29226
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-26 17:46 ---
> This is invalid as a->*mem_ptr cannot be used outside of a function.
that should be a "function call".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29225
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-26 17:45 ---
Note I marked this as a missed optimization also because we don't record b as
restrict which means we don't get a new aliasing set.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29230
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-26 17:42 ---
(In reply to comment #3)
> FWIW, I think it should be ill-formed with diagnostic required since the
> behavior of the expression is always undefined.
There are cases where this can show up in templates, someway or a
--- Comment #4 from tromey at gcc dot gnu dot org 2006-09-26 17:23 ---
Fix checked in.
I also forwarded it to Hans.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from tromey at gcc dot gnu dot org 2006-09-26 17:21 ---
Subject: Bug 29180
Author: tromey
Date: Tue Sep 26 17:21:32 2006
New Revision: 117232
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117232
Log:
2006-09-26 Jack Howarth <[EMAIL PROTECTED]>
PR targe
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-26 16:59 ---
Just needed to add a check for types before calling check_dtor_name.
Testing the new fix right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
--- Comment #3 from sebor at roguewave dot com 2006-09-26 16:31 ---
The response I got from EDG is that the expression is well-formed because of
5, p8. They do agree that issuing a warning would be useful and opened an
enhancement request.
FWIW, I think it should be ill-formed with diag
--- Comment #6 from kethgen at inf dot ethz dot ch 2006-09-26 15:58 ---
Subject: Re: Wrong installation for standard headers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Di den 26. Sep 2006 um 17:40 schrieb pinskia at gcc dot gnu dot org:
> Oh, so you compiled the GCC and then cop
--- Comment #40 from pcarlini at suse dot de 2006-09-26 15:57 ---
(In reply to comment #38)
> We have our reasons to enable strict aliasing by default.
In my opinion, this is a central point. I think we should try to explain what
strict aliasing buys from the point of view of the optimi
--- Comment #4 from kethgen at inf dot ethz dot ch 2006-09-26 15:33 ---
Subject: Re: Wrong installation for standard headers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Am Di den 26. Sep 2006 um 17:21 schrieb pinskia at gcc dot gnu dot org:
> --- Comment #3 from pinskia
--- Comment #37 from acahalan at gmail dot com 2006-09-26 15:33 ---
(In reply to comment #36)
> > Evidence: this bug has existed for ages, meanwhile aliasing violations keep
> > getting reported as compiler bugs.
> This bug (PR28778) has only existed for the last two major releases whic
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-26 14:21 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #2 from 4ekucT at tut dot by 2006-09-26 14:14 ---
I've just tested this code under VC8 and it accepted it without errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-26 15:25 ---
Newest patch:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01182.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-26 15:21 ---
Can you add -v when invoking gcc and give that output because stdio.h should
have already been in /usr/include because that is the standard place for it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29233
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-26 14:05 ---
*** This bug has been marked as a duplicate of 26917 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from kethgen at inf dot ethz dot ch 2006-09-26 15:17 ---
Subject: Re: Wrong installation for standard headers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Di den 26. Sep 2006 um 16:02 schrieb pinskia at gcc dot gnu dot org:
> --- Comment #1 from pinskia at gcc d
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-26 14:18
---
(In reply to comment #10)
There is a fixme in the code right now:
/* Allow 'restrict' on arrays of pointers.
FIXME currently we just ignore it. */
--
pinskia at gcc dot gnu dot org changed:
The following code does not compile because class TestBad has both template in
template argument T2 and friend operators.
template
class Temp {};
template class T2>
class TestBad
{
public:
template class OtherT2>
friend bool operator == (const TestBad& a, const
TestBad& b);
template cla
The following was found and tested on Gentoo system.
Compiler corrupts memory when a C++ file is compiled with -frepo and .rpo file
exists from previous (successful) compilation.
When .rpo file is removed, the problem disappears.
Reproducing the problem:
$ cat main.cpp
--- Comment #35 from acahalan at gmail dot com 2006-09-26 14:16 ---
(In reply to comment #34)
> Subject: Re: [4.0/4.1/4.2 Regression] alias
> bug with cast and call clobbered
>
> On Tue, 2006-09-26 at 04:44 +, acahalan at gmail dot com wrote:
> >
> > Although it wouldn't w
--- Comment #1 from 4ekucT at tut dot by 2006-09-26 14:07 ---
Created an attachment (id=12330)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12330&action=view)
Friend operators with template in template argument
Test example which shows compiler error message.
--
http://gcc.g
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-26 14:05 ---
*** Bug 29235 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |bootstrap
ht
--- Comment #5 from tbm at gcc dot gnu dot org 2006-09-26 13:37 ---
This doesn't happen with gcc 4.2, nor, apparently, with 4.0.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #4 from tbm at cyrius dot com 2006-09-26 13:21 ---
Created an attachment (id=12329)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12329&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29230
)46:[EMAIL PROTECTED]: ~]
This is with 4.1.2 20060926.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29230
--- Comment #3 from zaniyah at gmail dot com 2006-09-26 12:53 ---
Subject: Re: cc1: internal compiler error: Segmentation Fault
Thanks, I have since spoken to our techies and discovered that this is
a wierd custom build that has just been left floating around on our
servers and somehow
--- Comment #36 from pinskia at gcc dot gnu dot org 2006-09-26 14:32
---
> It's also wrong to assume that unions can be used for type punning, but so
> what? It is allowed by gcc.
No, it is less there as the behavior with unions is unspecified and not
undefined unlike type punning via
1 - 100 of 120 matches
Mail list logo
