--- Comment #3 from bkoz at gcc dot gnu dot org 2005-10-27 06:04 ---
Naming wise I think __gnu_ext makes more sense. It's what we should have used
for the extension namespace from the beginning.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24537
The member variable named "hash" in the gnu.gcj.convert.IOConverter class
should have a map entry key named "EUC_JP".
The encoding alias "EUC_JP" is on the list of the Sun's document:
"Supported Encoding"
http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.html
So GCJ should support th
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||21391, 23336
Status|UNCONFIRMED |NEW
Just a meta-bug to record -feliminate-unused-debug-types issues.
--
Summary: [meta-bug] -feliminate-unused-debug-types does not emit
types in some used cases
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: met
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-27 01:56
---
I might have a fix for the two error messages, though it might also cause other
issues, let see what happens in the test results.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23426
--- Comment #12 from reddy at pixar dot com 2005-10-27 01:41 ---
Having code coverage emit a "-" instead of "#" in this case sounds
appropriate and would certainly solve the problem for me.
Is there a way to workaround this issue by reorganizing code, or something
else, so that I ca
--- Comment #4 from reddy at pixar dot com 2005-10-27 01:36 ---
Thanks for the bugdb digging Andrew. I did do some searching to see if these
problems were reported, but didn't catch those reports. Sorry 'bout that.
PR 12076 does sound like a dupe, and the alternate behavior just suggest
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-27 01:10 ---
*** Bug 24550 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 2005-10-27 01:10 ---
(In reply to comment #2)
> There might be antoher bug about this too, I have to look.
And there is, PR 15369.
Since both of these issues have been filed already, I am going to close this as
a dup of last one.
***
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 01:07 ---
And the EOF issue is also a front-end issue too:
(static destructors for t.cc) ()
{
:
[t.cc : 24] __static_initialization_and_destruction_0 (0, 65535);
[t.cc : 24] return;
There might be antoher bug about this
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 01:02 ---
// instantiating this string and calling a method on it causes the
// 'return' line to be marked as having never been executed
This is PR 12076, the problem is more in the front-end for that one, it is not
a
I have come across a number of cases where gcov 4.0 and beyond produces
incorrect output, causing false reporting of code coverage. For example, lines
beyond the end of the source file are marked as executable with zero coverage,
and some lines are marked with zero coverage even though they are dir
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-27 00:50 ---
For 4.2, this should be fixed on the tree level by load PRE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
--- Comment #31 from pinskia at gcc dot gnu dot org 2005-10-27 00:47
---
(In reply to comment #30)
> This patch could help; I need to benchmark it before submitting it.
Any news about this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-27 00:20 ---
Hmm, this is truely all bit-field issues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-27 00:12 ---
I should note that this is a true code gen regression and not just a missed one
at the tree level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-27 00:08 ---
CCing Zdenek as he introduced this regression by enabling rename registers for
unrolling loops.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
> I found the following patch necessary to build libiberty with newlib
> headers. Although, glibc seems to use the same signature now.
While I'm generally OK with this...
1. The patch is incomplete, as you don't update the documentation to
match the new prototype.
2. GCC patches go to [EMAIL
--- 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
--- 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
> > wi
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 chan
--- 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
--- 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:
W
--- 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
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 #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,
--- 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 #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
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 #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
--- 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=10067&action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
--- 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=10066&action=view)
preprocessed output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
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 l
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.
--
Su
--- 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
--- 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=10065&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17362
--- 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 #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 #7 from abalkiss at redhat dot com 2005-10-26 19:15 ---
Fixed, patch attached.
--
abalkiss at redhat dot com changed:
What|Removed |Added
Status|A
--- 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=10064&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17360
--- 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 interface.c
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: P2
--- 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 sigpro
--- 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 b
--- 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
ideology
--- 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
IMPLICIT
--- 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[] args)
--- 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 #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 fol
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 #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
# include
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 sure acts
--- 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
-
--- 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 #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 #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.
--
http://gcc.gnu.org/bugzilla/s
--- 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 ju
--- 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 #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 p
--- 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 s
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--- 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 #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 #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 #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=10063&action=view)
the gzip'ed (prepreocessed) source causing the crash
This source cuases the crash.
Call it
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 verwende
--- 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 in
--- Comment #2 from alexey at hyperroll dot com 2005-10-26 15:03 ---
Created an attachment (id=10062)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10062&action=view)
example of code to warn, proposed partial patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
--- 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.
--
http://gcc.gnu.org/bugzilla/s
--- 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
compare.er
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 ove
--- 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));
__as
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 25
--- 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
--- 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
--
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
cgraph_expand_functio
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
cgraph_expand_functio
--- 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
gcc.c-torture/compile/labels-1.c
--- 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 #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 #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 l
--- 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 regis
--- 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 thi
--- 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 #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|R
--- 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 #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 #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 #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 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
Status|UN
--- 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 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 #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 #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 #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 #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 fo
--- 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;
voi
--- 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=10061&action=view)
unreduced testcase
unreduced testcase for verification
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2453
--- 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:
1 - 100 of 115 matches
Mail list logo
