--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-26 06:24 ---
This is a dup of bug 24024. The trailing backslash needs to be translated but
we are getting it wrong.
*** This bug has been marked as a duplicate of 24024 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-26 06:24 ---
*** Bug 23779 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 06:27 ---
GCC should produce:
/* Execute example with: gcc -E -P -C -x c dummy.txt
a b c
*/
As mentioned by comment #2.
This is not related to at all the backslash whitespace newline thread or PR
8270. Well PR 23779 is in
--- Comment #28 from pinskia at gcc dot gnu dot org 2005-10-26 06:29
---
You might as well look into PR 24024 which is only semi related but since you
are looking at preprocessor with backslash, it might be easy to fix that one
too.
--
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-26 07:03
---
Subject: Bug 24460
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-26 07:03:32
Modified files:
gcc: ChangeLog bb-reorder.c dwarf2out.c output.h
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-26 07:10
---
See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01409.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2005-10-26 07:57 ---
Fixed on mainline and 4.03
Farewell cvs!
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
the following valid code snippet recently stopped to compile cleanly:
module gfcbug28
! A publicly visible derived type with private components
type, public :: my_t
private
type(offset_t) :: offset
end type my_t
! Everything else is private...
private
type offset_t
--
Summary: ICE
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
--- Comment #1 from igodard at pacbell dot net 2005-10-26 08:17 ---
Created an attachment (id=10059)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10059action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24535
--- Comment #2 from igodard at pacbell dot net 2005-10-26 08:20 ---
Created an attachment (id=10060)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10060action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24535
--- Comment #6 from aeby at graeff dot com 2005-10-26 08:48 ---
I have just tested against 4.0.2 and the bug is still there (no surprise, of
course).
--
aeby at graeff dot com changed:
What|Removed |Added
--- Comment #7 from tromey at gcc dot gnu dot org 2005-10-26 09:01 ---
Sorry for the delay on this.
The patch looks reasonable enough to me. It needs a small
amount of reformatting and a ChangeLog entry.
Also I think the call to signal() is not needed, a custom
handler is reset to the
--- Comment #1 from cvs-commit at gcc dot gnu dot org 2005-10-26 09:20
---
Subject: Bug 24512
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gomp-20050608-branch
Changes by: [EMAIL PROTECTED] 2005-10-26 09:20:37
Modified files:
gcc:
We fail to allocate an mmx register to class 'X' since the last couple of weeks
(20051015 worked). Testcase:
typedef union {
long long q;
unsigned long long uq;
} __attribute__ ((aligned (8))) mmx_t;
static mmx_t mmx_0x8080s = (mmx_t) 0x8080808080808080LL;
void
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-26 10:06 ---
Note this makes libdv fail to compile. Oh, and it did not work with 20051015 -
every compiler I tried fails on the testcase. Hmm, which maybe makes it
invalid?
--
rguenth at gcc dot gnu dot org changed:
This is to keep track of this issue:
http://gcc.gnu.org/ml/libstdc++/2005-10/msg00077.html
In short, there is a small issue, with __gnu_cxx::char_traits (actually, we
should do an audit), and a larger issue with the legacy HP/SGI free functions
included via headers like ext/algorithm,
--- Comment #8 from schlie at comcast dot net 2005-10-26 10:33 ---
Subject: Re: BLK ptr's losing original ptr's
static-constant readonly attribute.
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-25 19:22
(In reply to comment #6)
- For some reason, GCC is casting
Mingw32 Platforms.(might be all win32 platforms)
--enable-shared=libstdc++ You kinda expect to get a dll.
Development version and Production Versions would be great.
Ie Development version linked to dll Production Version using static.
If you don't have the time to fix it point me to the
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-26 10:54 ---
I just verified that we build the unreduced testcase with gcc 4.0. So it might
be good/bad luck that it worked. Practically it still is a regression from
4.0.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-26 10:54 ---
Created an attachment (id=10061)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10061action=view)
unreduced testcase
unreduced testcase for verification
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-10-26 11:01 ---
Reduced testcase that works with 4.0 and fails with 4.1
typedef union {
long long q;
unsigned long long uq;
} __attribute__ ((aligned (8))) mmx_t;
static mmx_t mmx_0x8080s = (mmx_t) 0x8080808080808080LL;
--- Comment #11 from cvs-commit at gcc dot gnu dot org 2005-10-26 11:02
---
Subject: Bug 15586
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-26 11:02:00
Modified files:
gcc/fortran: ChangeLog resolve.c
Log message:
PR
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2005-10-26 11:05
---
Fixed, now no message is built from pieces anymore.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-10-26 11:05
---
Fixed on the gomp branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-10-26 11:28 ---
Ok, libdv is really crap.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from segher at kernel dot crashing dot org 2005-10-26 11:44
---
The (first) carriage return issue is a separate bug, though.
Please reopen?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23779
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-26 12:18 ---
X means any register by the way (this is why this is invalid).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-26 12:19 ---
Fixed in CVS.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-10-26 12:20 ---
Yeah - noticed that after taking X for x ... which wouldn't have made sense,
too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:25
---
This is a duplicate
*** This bug has been marked as a duplicate of 22331 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-10-26 12:25
---
*** Bug 24529 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-26 12:31 ---
IIRC there were recent patches to fix this BUT I don't know the state of them.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:33
---
If you can't upgrade to gcc-3.4, see the patch link in the bug this is a
duplicate of
*** This bug has been marked as a duplicate of 22528 ***
--
rearnsha at gcc dot gnu dot org changed:
What
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:33
---
*** Bug 24528 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-26 12:34 ---
Seems like to me, this is what namespaces are for anyways? and non-uglified
names are correct, maybe it needs to be a different namespace like
__gnu_cxx::__implemenation instead which seems like the more correct
--- Comment #8 from pluto at agmk dot net 2005-10-26 12:36 ---
(In reply to comment #7)
Yeah - noticed that after taking X for x ... which wouldn't have made sense,
too.
I've detected an ICE-on-invalid code with y constraint (MMX register)
pr24536.c:16: error: impossible register
--- Comment #2 from pcarlini at suse dot de 2005-10-26 12:37 ---
(In reply to comment #1)
Seems like to me, this is what namespaces are for anyways? and non-uglified
names are correct, maybe it needs to be a different namespace like
__gnu_cxx::__implemenation instead which seems
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-10-26 12:54
---
reload - Micha, can you try to track this down? It makes xvid ICE on
beta-ppc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rakdver at gcc dot gnu dot org 2005-10-26 13:02 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01527.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from micis at gmx dot de 2005-10-26 14:17 ---
With the snapshot gcc-4.1-20051022 I get the following additional errors when I
use --enable-checking=fold and run make check
gcc.c-torture/compile/20021108-1.c
gcc.c-torture/compile/920501-7.c
Also posted to the GCC mailing list:
http://gcc.gnu.org/ml/gcc/2005-10/msg00932.html
http://gcc.gnu.org/ml/gcc/2005-10/msg00938.html
While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
Also posted to the GCC mailing list:
http://gcc.gnu.org/ml/gcc/2005-10/msg00932.html
http://gcc.gnu.org/ml/gcc/2005-10/msg00938.html
While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
--- Comment #1 from gary at intrepid dot com 2005-10-26 14:39 ---
*** This bug has been marked as a duplicate of 24539 ***
--
gary at intrepid dot com changed:
What|Removed |Added
--- Comment #1 from gary at intrepid dot com 2005-10-26 14:39 ---
*** Bug 24540 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539
When I run a FORTRAN program, compiled with gcc 4.0, against libgfortran in
gcc 4.1, I got
a.out: Symbol `_gfortran_ioparm' has different size in shared object, consider
re-linking
[EMAIL PROTECTED] 0004]$ readelf -s /usr/gcc-4.1/lib/libgfortran.so| grep
_gfortran_ioparm
636: 000688e0
--- Comment #9 from uros at kss-loka dot si 2005-10-26 14:41 ---
(In reply to comment #8)
I've detected an ICE-on-invalid code with y constraint (MMX register)
You should use memory input/output:
__asm__ __volatile__ (paddb %0, %% mm2::m (mmx_0x8080s));
__asm__
The following code is ISO and ANSI standard compliant:
unsigned x1, x2;
unsigned long long y1;
... /* here we assign to x1 and x2 */
y1 = x1 * x2; /* no castings -- silent overflow may occur on assignment */
...
{
unsigned long long y2 = x1 * x2; /* no castings -- silent
--- Comment #1 from hjl at lucon dot org 2005-10-26 15:01 ---
I built SPEC CPU 2K with gcc 4.0 and ran with libgfortran.so in gcc 4.1. I
got
Specinvoke: /export/spec/src/2000/spec/bin/specinvoke -E -d
/export/spec/src/2000/spec/benchspec/CFP2000/172.mgrid/run/0002 -c 1 -e
--- Comment #1 from alexey at hyperroll dot com 2005-10-26 15:01 ---
I'm not familiar with the parse tree, so I could do only a partial patch
(assignment, not initialization). The example file, original and patched source
files archived and attached.
--
--- Comment #4 from abalkiss at redhat dot com 2005-10-26 15:23 ---
This appears to be a problem with JScrollPane.getPreferredSize(), as the
FlowLayout sets the size of the JScrollPane to its preferredSize, and then this
is a bound for the layout in ScrollPaneLayout which then sets an
Hi,
g++ crashes with the source attached.
I called g++ as:
g++ bug.i
sql_pars.c:117154: interner Compiler-Fehler: Speicherzugriffsfehler
my translation of the german error message:
internal compiler error, memory access violation
g++ -v results:
Es werden eingebaute Spezifikationen
--- Comment #1 from juergen dot vollmer at informatik-vollmer dot de
2005-10-26 15:53 ---
Created an attachment (id=10063)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10063action=view)
the gzip'ed (prepreocessed) source causing the crash
This source cuases the crash.
Call it
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-26 15:54 ---
I think analyze_expr should be removed as by the time we get there, we are
always in gimple.
As for expand_function, we really should have a default one now as almost no
language does not support unit at a time.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-26 15:56 ---
This is actually the issue is that 4.0.x's gfortran is experimental and really
should not be thought about be used in normal use, even to compile and then
link with a newer version. This has been discussed before.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-26 15:59 ---
You should be patching the mainline as the C parser has changed to a non bison
based parser.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 16:00 ---
Please also make the warning conditional based on an option and make the
option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from hjl at lucon dot org 2005-10-26 16:06 ---
Then rename _gfortran_ioparm to something like _gfortran_version_4.1_ioparm
and change soname of libgfortran from libgfortran.so.0 to something like
libgfortran.so.0.1. When libgfortran's ABI is changed, we should update
its
--- Comment #3 from gary at intrepid dot com 2005-10-26 16:07 ---
All/most GCC-supplied dialects may support unit-at-a-time, however,
the dialect we're working on (UPC) does not at present support
unit-at-a-time.
For now, we're de-asserting flag_unit_at_a_time in the language
specific
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 16:07 ---
This is still minor as the ABI was expected to change and really you should not
be doing this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 16:09 ---
(In reply to comment #3)
For now, we're de-asserting flag_unit_at_a_time in the language
specific post_options routine.
You should note that non unit-at-a-time will be removed in the future so you
may as well
--- Comment #5 from hjl at lucon dot org 2005-10-26 16:19 ---
So what? ABI of glibc changes. ABI of libstdc++ changes. When the ABI changes,
we should manage it in such a way that it won't cause problems for existing
executables and shared libraries.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-26 16:20 ---
Fixed in at least 4.0.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-26 16:29 ---
Actually this was fixed in the 4.0.2 release. This is a dup of bug 21135.
*** This bug has been marked as a duplicate of 21135 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-10-26 16:29
---
*** Bug 24543 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
# include stdio.h
main()
{
printf( HELLO WORLD\n);
}
If Above is called h.c it compiles if it is called H.C it doesn't. However it
compiles with g++. It seems to me that at compile time H.C is taken to be a C++
programme but at link time it is treated as a C programme. If this is not a bug
it
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-26 16:50 ---
This is not a bug. You have to link C++ programs with g++ or link in the
libstdc++ library.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
The code example listed at the end of this email fails to compile with gfortran
4.1.0 20051025 (experimental). Compiling like so:
gfortran -c gfortran_test.f90
produces the error message:
In file gfortran_test.f90:16
END INTERFACE OPERATOR (.EqualTo.)
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-26 16:54 ---
(In reply to comment #7)
With the snapshot gcc-4.1-20051022 I get the following additional errors when
I
use --enable-checking=fold and run make check
Thanks, that is only one bug now as they all have the
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-26 16:59 ---
Confirmed, There might be just some missing check for this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from abalkiss at redhat dot com 2005-10-26 17:00 ---
An even more specific test case shows that the problem is in ScrollPaneLayout's
preferredLayoutSize method.
***TESTCASE***
import java.awt.*;
import javax.swing.*;
class Test
{
public static void main(String[]
--- Comment #1 from kargl at gcc dot gnu dot org 2005-10-26 17:05 ---
Here's a reduced code that shows the problem. Gfortran is
not handling the END INTERFACE OPERATOR (.EqualTo.) correctly.
This confuses the heck out of the error recovery code.
MODULE Compare_Float_Numbers
--- Comment #5 from alexey at hyperroll dot com 2005-10-26 17:12 ---
Sir, it's my first report here, and I see the code first time. I hope that both
comments #3 and #4 are not for me. Or am I mistaken?
Otherwise, what document (preferably, short) should I read to understand the
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-26 17:46 ---
Re. comment #5, yes other library ABIs change too, but libgfortran is special
in that what shipped with GCC 4.0 was highly experimental and never intended to
be a stable interface. The decision at the time was that
--- Comment #8 from aeby at graeff dot com 2005-10-26 18:04 ---
no problem ...
I thought, resetting the signal handler to SIG_DFL before unblocking might be a
good idea in the (not very probable) case a SIGCHLD signal is either in the
signal queue or is otherwise received between
This is a meta-bug to catch all gfortran debugging problems.
--
Summary: [meta-bug] gfortran debugging problems
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: meta-bug, wrong-debug
Severity: normal
Priority:
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-26 18:54 ---
Perhaps this cures it.
Index: interface.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/interface.c,v
retrieving revision 1.21
diff -u -3 -p -r1.21
--- Comment #6 from abalkiss at redhat dot com 2005-10-26 19:15 ---
Created an attachment (id=10064)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10064action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17360
--- Comment #7 from abalkiss at redhat dot com 2005-10-26 19:15 ---
Fixed, patch attached.
--
abalkiss at redhat dot com changed:
What|Removed |Added
--- Comment #4 from abalkiss at redhat dot com 2005-10-26 19:16 ---
This has gone backwards and is no longer fixed.
--
abalkiss at redhat dot com changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2005-10-26 19:44 ---
This was fixed on mainline and 4.0
The testcase now gives:
[EMAIL PROTECTED] mytests]# /gcc-clean/bin/gfortran -c pr21986.f90
In file pr21986.f90:4
public:: dummysub ! comment out, lose the bug
--- Comment #5 from abalkiss at redhat dot com 2005-10-26 19:59 ---
Created an attachment (id=10065)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10065action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17362
--- Comment #6 from abalkiss at redhat dot com 2005-10-26 20:00 ---
Fixed.
--
abalkiss at redhat dot com changed:
What|Removed |Added
Status|REOPENED
In i386.c, there are
if (optimize_size)
ix86_cost = size_cost;
else
ix86_cost = processor_target_table[ix86_tune].cost;
...
ix86_branch_cost = processor_target_table[ix86_tune].cost-branch_cost;
As the result, -Os may generate bigger code than it should have.
--
This looks similar to bug 19449, but with just __builtin_constant_p not
__builtin_choose_expr so I'm opening a new bug for this.
The following code works with 3.3.6, but with 3.4.4 it fails to resolve
__builtin_constant_p leading to link errors of unresolved symbols.
Code I'm seeing this in is
--- Comment #1 from djohnson+gcc at sw dot starentnetworks dot com
2005-10-26 20:55 ---
Created an attachment (id=10066)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10066action=view)
preprocessed output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
--- Comment #2 from djohnson+gcc at sw dot starentnetworks dot com
2005-10-26 20:56 ---
Created an attachment (id=10067)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10067action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-26 21:25 ---
I don't think this is a GCC bug as what is happening is that something is being
inlined which did not get inlined before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
Hi,
the IMPORT statement of Fortran2003 is not yet implemented.
Trying to use it provokes an ICE:
module gfcbug29_import
integer, parameter :: dp = kind (1d0)
interface
subroutine foo (x)
import :: dp
real (kind=dp) :: x
end subroutine foo
end interface
end module
--- Comment #29 from pinskia at gcc dot gnu dot org 2005-10-26 21:41
---
Hmm, there consense is that at the least we should warn for comments. But the
consense from non Apple people it seems to not to change the behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
--- Comment #30 from echristo at apple dot com 2005-10-26 21:46 ---
That would be the consensus from Andrew, not from people concerned that deal
with language issues routinely.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
--- Comment #31 from pinskia at gcc dot gnu dot org 2005-10-26 21:49
---
(In reply to comment #30)
That would be the consensus from Andrew, not from people concerned that deal
with language issues routinely.
Wait a minute, if you actually look at the people agrueing for the change,
I found the following patch necessary to build libiberty with newlib
headers. Although, glibc seems to use the same signature now.
Cheers,
Shaun
2005-10-26 Shaun Jackman [EMAIL PROTECTED]
* libiberty/strsignal.c (psignal): Change the signo parameter from
unsigned to int, and
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 22:38 ---
This is a combined return slot optimization and inliner bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-26 22:42 ---
I have the simple/obvious patch which fixes this one at least the issue in this
PR and not the one in PR 24365 so this will still not work on the mainline.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-26 22:51 ---
Note in the mathematical sense complex numbers are scalars, I know in the
compiler world this is different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
pinskia at gcc dot gnu dot org wrote:-
That would be the consensus from Andrew, not from people concerned that deal
with language issues routinely.
Wait a minute, if you actually look at the people agrueing for the change, it
is only Apple employees. Joe has said we should not change it.
--- Comment #32 from neil at daikokuya dot co dot uk 2005-10-26 23:07
---
Subject: Re: [3.4/4.0/4.1 Regression] back-slash newline extension can't be
removed
pinskia at gcc dot gnu dot org wrote:-
That would be the consensus from Andrew, not from people concerned that deal
with
--- Comment #33 from dj at redhat dot com 2005-10-26 23:13 ---
Subject: Re: [3.4/4.0/4.1 Regression] back-slash newline extension can't be
removed
It looks like DJ is saying the same in the new thread which shows
the real issues with the other compilers implemenation.
I would be
1 - 100 of 117 matches
Mail list logo
