--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-07
07:27 ---
CRIS is not a primary target. Removing target milestone.
--
What|Removed |Added
Target M
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
07:36 ---
Subject: Bug 19269
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 07:36:12
Modified files:
gcc/fortran: ChangeLog simplify.c
gcc/tes
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-07
07:45 ---
Java bugs are not release-critical; removing target milestone.
--
What|Removed |Added
Tar
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org |dot au
Status|NEW
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-07
09:00 ---
I'll take care of it.
Arno
--
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-07
09:26 ---
I agree with the analysis and the fix. Care to submit the patch to gcc-patches?
Do you have a copyright assignment on file with the FSF? If not the patch may
be simple enough to be accepted regardless of
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-07
09:59 ---
Long-standing problem in Gigi, will be fixed by the next push from AdaCore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22418
--- Additional Comments From goweol at gmail dot com 2005-09-07 10:20
---
After reported this bug, I built several m6811-elf-gcc compiler.
Those are 20050318, 20050426, 20050516, and 20050907 version.
At this time, 20050318 and 20050426 generates ICE.
But 20050516 and 20050907 version
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:23
---
Not a regression, in any sense. Given that, and the "almost-deprecated" status
of vector, better not touching this for the current release branch. Fixed
for 4.1.0, anyway.
--
What|Removed
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
10:37 ---
Is this still a problem? The other two testcases seem to work now.
--
What|Removed |Added
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
10:40 ---
Fixed by the partial patch for 19269
--
What|Removed |Added
OtherBugsDependingO|
--
Bug 19276 depends on bug 21825, which changed state.
Bug 21825 Summary: [4.0/4.1 Regression] 2D array initialization with reshape
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21825
What|Old Value |New Value
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:42
---
Not a but, this behavior is intended and correct. According to the Standard
(Table 57), the stdio equivalent for hex formatting will be exactly %x (or %X).
Then try printf("%x", -1) on your machine.
--
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
10:45 ---
Fixed by the same patch as 15326.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:55
---
Fixed for 4.1.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
11:58 ---
Subject: Bug 23747
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 11:57:47
Modified files:
gcc: ChangeLog
gcc/config/m32r: m
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
12:05 ---
Subject: Bug 23747
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 12:04:42
Modified files:
gcc: Change
Setting java.library.path on the gij command line should set the module loader
path to the given argument. Currently an attempt is made to do this in
natSystemProperties.cc:
// If java.library.path is set, tell libltdl so we search the new
// directories as well. FIXME: does this work proper
If java.library.path was not specified on the command line its value should
default to the contents of LD_LIBRARY_PATH on GNU/Linux systems or
LTDL_SHLIBPATH_VAR generally.
--
Summary: java.library.path should default to value of environment
variable specified by LT
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 12:36
---
Filed two new bugs for the remaining java.library.path issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23761
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23762
I'm closing this bug.
--
Wh
Showcase: compile exectest.c, run test.java calling 'exectest'
Runtime.exec() seems to pass down some strange signal configuration to child
processes in GCC >=4.0.0. When run from test.java the exectest.c parent process
does never get CHLD signals - they seem to get blocked (as I've seen the
rtsig
--- Additional Comments From aeby at graeff dot com 2005-09-07 13:17
---
Created an attachment (id=9686)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9686&action=view)
Execs "exectest" and demonstrates how it hangs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
--- Additional Comments From aeby at graeff dot com 2005-09-07 13:18
---
Created an attachment (id=9687)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9687&action=view)
Sample program that hangs when executed via Runtime.exec()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07
13:20 ---
This is not a problem with dynamic stack allocation, but rather with the
instrumentation code.
The following diagram is supposed to show what the V4 stack layout looks like
just after the function prologu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
13:23 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-07
13:36 ---
Subject: Re: CCP not fully propagating
constants
On Wed, 2005-09-07 at 04:19 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
13:43 ---
It's not clear who's on the hook to the fix the transpose() call.
I'll unassign myself in the meantime.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
14:03 ---
Fixed by:
2005-09-07 Andreas Krebbel <[EMAIL PROTECTED]>
* reload1.c (fixup_eh_region_note): Remove assertion.
(fixup_abnormal_edges): Reverted removal of call to
find_many_sub_bas
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
--
What|Removed |Added
Target Milestone|--- |3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6181
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5942
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2956
--
What|Removed |Added
Target Milestone|--- |3.0.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1392
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23746
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23565
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1391
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21255
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19481
--
What|Removed |Added
Keywords||build, ice-on-valid-code
Summary|pt.c:9462: ICE: in |[4.1 Regression] pt.c:9462:
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23661
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23561
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23607
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23475
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-09-07 14:18
---
Updated patch for mainline here:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00302.html
--
What|Removed |Added
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07
14:39 ---
Simplified testcase. This bug is probably a WONTFIX.
int bar (int *);
int foo (void)
{
int x;
__builtin_memset (&x, 0, 32);
return bar (&x);
}
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
15:25 ---
Subject: Bug 22555
CVSROOT:/cvs/gcc
Module name:gcc
Branch: improved-aliasing-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 15:25:13
Modified files:
gcc
Trying to compile the following code on a FreeBSD 5.4 machine, using GCC
4.0.1
# 1 "Test.cpp"
# 0 ""
# 1 ""
# 1 "Test.cpp"
class OutStream
{
public:
OutStream();
};
inline OutStream & operator<<( OutStream & output, const int & value )
{
return output;
}
class Client
{
public:
OutStre
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 15:48
---
I filed a bug against GTK:
http://bugzilla.gnome.org/show_bug.cgi?id=315462
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21598
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
15:49 ---
Not a bug as you cannot bind a rvalue to the reference type.
Basicially what you have is:
int g(void);
void h(int&);
void j(void)
{
h(g());
}
And that is invalid. You can bind a rvalue to a const refe
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
15:59 ---
Testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsa
[EMAIL PROTECTED]:~/src/tests> cat pr16404.f90
REAL, TARGET :: B(2,2)
common x/b/
B = 1.
END
[EMAIL PROTECTED]:~/src/tests> ../gcc/build/gcc/f951 pr16404.f90
MAIN__
pr16404.f90:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if approp
--- Additional Comments From x at xman dot org 2005-09-07 16:03 ---
The ANSI definition for %x (or %X) only covers unsigned integers. Surely then
doing hex formatting on a signed integer would at the very least be undefined
behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2375
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-07
16:07 ---
Can someone ping this patch on the gcc-patches ml?
--
What|Removed |Added
Last reconfirm
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
16:07 ---
Confirmed, backtrace:
#0 0x080a2406 in translate_common (common=0x96d29b8, var_list=Variable
"var_list" is not
available.
) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-common.c:879
#1 0x0
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-07 16:09
---
(In reply to comment #16)
> Since number 2 is already reported, we only have 3 and 6 left:
I have a patch for 3 and will try to sort out 6 (+pr21986) as soon as I have a
moment.
--
http://gcc.gnu.org/bugz
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 16:17
---
Reduced testcase:
common /b/
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:28
---
(In reply to comment #7)
> The ANSI definition for %x (or %X) only covers unsigned integers. Surely then
> doing hex formatting on a signed integer would at the very least be undefined
> behavior.
Yes, you have a
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
16:30 ---
Subject: Bug 23358
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 16:30:38
Modified files:
libstdc++-v3 : Change
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:32
---
Fixed for 4.0.2 too.
--
What|Removed |Added
Target Milestone|4.1.0 |4.0.2
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:51
---
(In reply to comment #8)
> Yes, you have a point that the mapping prescribed by the ISO/IEC Standards is
> not very precise, because, strictly speaking, the C Standard speaks only about
> unsigned int and the C++ S
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
16:58 ---
Hmm. I supposed I'd better check. Is the following code
also valid:
program main
implicit none
real, dimension (:), pointer :: x
x => null()
x => test ()
contains
function test
real, dimens
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:02
---
Patch here: http://gcc.gnu.org/ml/fortran/2005-09/msg00089.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
The following code does not compile. According to the compiler,
't' is overloaded ambiguously.
#include
struct T {
typedef std::vector Vector;
typedef Vector::iterator iterator;
typedef Vector::const_iterator const_iterator;
int t( iterator f) { return *f; }
int t( const
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:04
---
I don't have the standard at hand, but both the Intel and the Portland Group
compiler accept this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
--- Additional Comments From afra at cs dot stanford dot edu 2005-09-07
17:04 ---
Created an attachment (id=9688)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9688&action=view)
complete program showing bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--
What|Removed |Added
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From richard at codesourcery dot com 2005-09-07
17:07 ---
Subject: Re: Functions returning pointers with pointer argument
"tobi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> I don't have the standard at hand, but both the Intel and the Portland Group
> c
--
What|Removed |Added
Known to fail||3.0.4 3.3.3 3.4.0 4.0.0
Known to work||2.95.3
http://gcc.gnu.org/bugzilla/sh
--
What|Removed |Added
Keywords|missed-optimization |diagnostic
Last reconfirmed|2005-05-16 02:30:28 |2005-09-07 17:43:18
date|
--- Additional Comments From nico at cam dot org 2005-09-07 18:24 ---
I just tested with HEAD today and the problem doesn't appear to be there any
longer. Therefore gcc 4.1.0 should be OK.
--
What|Removed |Added
---
The JCE spec for Cipher.doFinal states:
"Upon finishing, this method resets this cipher object to the state it was in
when previously initialized via a call to init. That is, the object is reset and
available to encrypt or decrypt (depending on the operation mode that was
specified in the call to
--
What|Removed |Added
Keywords||alias
Last reconfirmed|2005-07-04 21:36:12 |2005-09-07 18:35:18
date|
--
What|Removed |Added
Component|libgcj |classpath
Product|gcc |classpath
Version|4.0.1
--
What|Removed |Added
CC||bug-classpath at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
--- Additional Comments From x at xman dot org 2005-09-07 18:40 ---
The behavior we are mimicing isn't printf()'s behavior. printf() doesn't print
out hexadecimal signed integers as though they were unsigned integers. Intead,
C's type coercion allows the signed integers to be interpreted
--- Additional Comments From jakub at gcc dot gnu dot org 2005-09-07 18:58
---
Looking into it.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub
--
What|Removed |Added
Target Milestone|4.0.2 |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16888
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:09
---
(In reply to comment #10)
> The behavior we are mimicing isn't printf()'s behavior.
This statement of yours is by and large incorrect, in the face of the actual
way the C++ Standard is formulated. Please read agai
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
19:11 ---
Hmm, this works correctly with the C front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
I noticed when compiling with gcc -std=c99 -Winline that this function
inline uint16_t f(uint16_t x) { return x; }
wasn't getting inlined. Inlining is also not done even when the function is
attributed with "__attribute__ ((always_inline))", nor does inlining happen
when there no attribut
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
19:14 ---
3.3.x is old and does not have the inlining improvements that went into 3.4.x.
You might want to try
3.4.x or even 4.0.x. 4.1.x (the mainline) has better inlining still.
But without a full testcase, we
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18
---
I'm on Cywin and couldn't find a later version of gcc - is there one somewhere
that I can use?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18
---
(Cygwin)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:19
---
(In reply to comment #10)
> one of the key differentiators
> with iostreams is type safety, which is effectively broken with the current
> behavior.
By the way, I don't
--- Additional Comments From chris at bubblescope dot net 2005-09-07 19:22
---
Hmm.. this is I believe a bug, but a very hard one to trigger.
1) This bug is very sensitive. It only occurs if the const_iterator member
function is const and the
iterator member function isn't. It doesn't
--
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:33
---
(In reply to comment #2)
> Unfortunatly I don't believe thats possible without passing
> extra information by more template parameters, which would break binary
> compatability.
I'm not going to disc
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:37
---
(In reply to comment #3)
> Unfortunatly I don't believe thats possible without passing extra
> information by more template parameters, which would break binary
> compatability.
In short, in my preliminary opini
--
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
Currently, the buffers for reading/writing integers
and reals in the i/o library are of type char[], which forces
the use of memcpy(), as in the fix for PR 23356. It would
be better for performance if suitable alignment could be
forced on the buffers.
--
Summary: unaligned buffers in
This code
--
template struct length {
static const int value = 3;
};
template ::value> struct S {};
template
S bar (T);
template void foo () {
bar (1);
}
-
Used to compile with gcc 4.0.1pre (20050531), but it doesn't any mor
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03
---
This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre
but doesn't anymore with today's 4.0.2pre.
W.
*** This bug has been marked as a duplicate of 23771 ***
--
What|Remo
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03
---
*** Bug 23691 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
20:06 ---
Used to work with 4.1 20050822 but does not with 4.1 20050903.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
20:06 ---
(In reply to comment #11)
> This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre
> but doesn't anymore with today's 4.0.2pre.
Actually it is not really as this one works on the mainlin
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:06
---
You are right, I previously didn't think it was possible without adding some
more template parameters.
However, I should have known there is nothing you can't do with a few templates
:)
How about something
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
20:08 ---
Note unlike PR 23691, this one does ___not___ work on the mainline. They might
be the same issue but
we won't really know until either one is fixed.
--
What|Removed |A
--
What|Removed |Added
CC||bangerth at dealii dot org
Last reconfirmed|2005-09-06 18:49:14 |2005-09-07 20:12:20
d
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:14
---
(In reply to comment #5)
> How about something like:
Yes, in my mind earlier today I considered that solution. In principle should
work. However, there are issues, I'm afraid: optimization issues with the
extra du
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
20:16 ---
Subject: Bug 23419
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 20:16:47
Modified files:
libgfortran: ChangeLog
libgfortran/io : w
1 - 100 of 144 matches
Mail list logo
