--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-27 07:31 ---
The inliner can perfectly cope with varargs if they are unused. See
gcc.dg/inline-23.c:
/* { dg-do compile } */
/* { dg-options -std=gnu89 } */
/* Make sure we can inline a varargs function whose variable
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-27 07:45 ---
reducing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33195
--- Comment #12 from andreast at gcc dot gnu dot org 2007-08-27 07:57
---
Created an attachment (id=14120)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14120action=view)
Preprocessed source at O1 java_raw_api
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
--- Comment #13 from andreast at gcc dot gnu dot org 2007-08-27 07:58
---
Created an attachment (id=14121)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14121action=view)
Assembly output from preprocessing the java_raw_api at O1
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-27 08:08 ---
Created an attachment (id=14122)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14122action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33195
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-27 08:09 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-27 08:52 ---
More reduced testcase, which fails both on the trunk (though just with -O1)
and on 4.2 (both -O1 and -O2):
int
foo (unsigned int *p, int *q, unsigned int w, unsigned int b)
{
unsigned int i;
int mask;
if (q[0]
Short Story:
With Current gcc/libstdc++ + uclibc you cannot put a float/double in a iostream
(f.e. cout)
Attached Patch fix this, because the size of the allocated Buffer given to
__convert_from_v is
needed from uclibc. If GLIBCXX_C99 is defined libstdc++ give the cs_size to the
function.
Long
--- Comment #1 from g dot janak at unicontrol dot de 2007-08-27 09:40
---
Created an attachment (id=14123)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14123action=view)
Fix the Bug, by using cs_size as the size.
Dont know if anythink goes broken. It works with uclibc at powerpc
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-27 09:51
---
(In reply to comment #2)
FX, do you have an idea of the time it will take for
this to make it into Cygwin update?
None at all. You can ask on the cygwin list, though, it's not a
subscriber-restricted list.
--- Comment #2 from pcarlini at suse dot de 2007-08-27 09:58 ---
Sorry, but the analysis doesn't make sense to me: if __convert_from_v is called
that way in _M_insert_float, it means _GLIBCXX_USE_C99 is undefined. In that
case __convert_from_v does *not* use __size for the simple reason
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-27 10:10
---
So everything (target == host) is cygwin. I'm sorry for the confusion, but as
you talked about MSYS in your original report, I thought it would be some kind
of cygwin-hosted mingw compiler...
About the failures
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-27 10:14 ---
Caused by PR25600.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from g dot janak at unicontrol dot de 2007-08-27 10:59
---
Hm, if i look in
libstdc++-v3/config/locale/uclibc/c_locale.h
(please say if this is the wrong place)
__convert_from_v is implemented,
// Convert numeric value of type double to string and return length of
--- Comment #4 from pcarlini at suse dot de 2007-08-27 11:17 ---
(In reply to comment #3)
Hm, if i look in
libstdc++-v3/config/locale/uclibc/c_locale.h
Then you are using a special version of GCC, not the official FSF one for which
we provide support, because such /uclibc directory
--- Comment #5 from g dot janak at unicontrol dot de 2007-08-27 11:39
---
Ohh. Now I see it.
It seems this is patched in by buildroot. a uclibc Toolchain build-helper.
ok, Im will put this in the Buildroot Bugsystem...
Perhaps uclibc config is added somewhere in the Feature to the
--- Comment #9 from jakub at gcc dot gnu dot org 2007-08-27 12:05 ---
Sounds like a dup of PR32855.
The patch in comment #7 certainly fixes that.
So, what can be done to speed up acceptance of this?
I can try to bootstrap/regtest on ia64-linux this later today, only arm in
addition to
gfortran/ version gcc 4.1.1 20070105 (Red Hat 4.1.1-51)
Runtime problem with code compiled using gfortran.
The following declaration were in the code:
Call Routine(var)
and then
SUBROUTINE Routine(var1, var2)
INTEGER, INTENT(IN) :: var1
CHARACTER(LEN=3), INTENT(IN) :: var2
The code
--- Comment #7 from dir at lanl dot gov 2007-08-27 13:12 ---
My programs fail in the save way on MSYS and GYGWIN, but on none of the other
versions of gfortran.
I tried intrinsic_integer.f90 by hand and it does not fail on my gfortran
version.
Here is the traceback for pr32417.f90 -
--- Comment #17 from lloyd at randombit dot net 2007-08-27 13:14 ---
This should probably be reexamined with regards to C++0x, since it includes
'long long' and my reading of the working group draft is that a constant too
large to fit into a long should be considered a long long or
A native i386-pc-mingw32 bootstrap of mainline fails in libstdc++-v3 with:
libtool: compile: /home/FX/ibin/./gcc/xgcc -shared-libgcc
-B/home/FX/ibin/./gcc -nostdinc++
-L/home/FX/ibin/i386-pc-mingw32/libstdc++-v3/src
-L/home/FX/ibin/i386-pc-mingw32/libstdc++-v3/src/.libs
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-27 13:44 ---
Segmentation fault means: The program accessed memory it was not supposed to
access. There is no error if it accesses memory which is garbage but it may
access. Seemingly the first it happening with g95 and ifort and
--- Comment #2 from leroux at lpmc dot univ-montp2 dot fr 2007-08-27 13:47
---
Subject: Re: 'NO' runtime problem with a code compiled
using gfotran ... and it should !
Thank you very much for your detailed and very clear answer.
Best.
Sébastien Le Roux
--
Currently, miss matches of the arguments can only be detected if an explicit
interface is available.
NAG f95 supports run time checking by having a global struct available which
contains information (number of arguments, type/kind of the arguments, pointer
to the function).
Before each procedure
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-27 13:53 ---
See also:
- Run-time checking, PR33204
- Whole-file checking: PR26227
- Generating .mod files for procedures which are not contained in modules or
the PROGRAM: PR30658
--
--- Comment #3 from hjl at gcc dot gnu dot org 2007-08-27 14:14 ---
Subject: Bug 31385
Author: hjl
Date: Mon Aug 27 14:14:31 2007
New Revision: 127833
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127833
Log:
gcc/
2007-08-27 H.J. Lu [EMAIL PROTECTED]
PR target/31385
--- Comment #4 from hjl at lucon dot org 2007-08-27 14:17 ---
Fixed by
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01809.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-08-27 14:18 ---
Subject: Bug 33173
Author: dberlin
Date: Mon Aug 27 14:18:36 2007
New Revision: 127834
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127834
Log:
2007-08-27 Daniel Berlin [EMAIL PROTECTED]
Fix PR
--- Comment #32 from jakub at gcc dot gnu dot org 2007-08-27 14:49 ---
What's the state of the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961#c27
patch? I haven't seen it posted to gcc-patches...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-27 15:27 ---
Doesn't fail for me on x86_64 with -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199
test.cxx
--
#include iostream
struct A
{
unsigned short x:14;
unsigned short y:14;
};
extern unsigned n;
int main()
{
A a;
a.x = n 0x3FFF;
a.y = (n14) 0x3FFF;
unsigned expected = n 0x3FFF;
if( a.x != expected
--- Comment #6 from hjl at lucon dot org 2007-08-27 16:11 ---
I saw it on Linux/ia64 running RHEL4, on Linux/ia32 running RHEL4 and RHEL5
as well as with -m32 on Linux/x86-64 running F7, RHEL4 and RHEL5. If I
have to guess, some vararg functions may be only available on certain
--- Comment #7 from rguenther at suse dot de 2007-08-27 16:16 ---
Subject: Re: [4.3 Regression]
tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
On Mon, 27 Aug 2007, hjl at lucon dot org wrote:
--- Comment #6 from hjl at lucon dot org 2007-08-27 16:11 ---
I saw it on
--- Comment #53 from jason at gcc dot gnu dot org 2007-08-27 16:32 ---
Reassigning since H.J. fixed the bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hjl at lucon dot org 2007-08-27 16:43 ---
Created an attachment (id=14124)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14124action=view)
A testcase
It should be compiled with
-O2 -m32 -g -O2 -ffunction-sections -fdata-sections -fmessage-length=0 -g -O2
--- Comment #33 from hjl at lucon dot org 2007-08-27 18:38 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01865.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #31 from jason at gcc dot gnu dot org 2007-08-27 18:41 ---
It seems that G++ is setting TREE_ADDRESSABLE on the RETURN_DECL properly, so
the remaining problem is in the mudflap code. Reassigning to fche.
--
jason at gcc dot gnu dot org changed:
What
--- Comment #54 from hjl at lucon dot org 2007-08-27 18:43 ---
(In reply to comment #52)
Hi, this backport to gcc-4.1-4.1.2-9 on debian breaks the glibc build on hppa.
The link of librt.so is missing the declaration of symbol
__librt_multiple_threads.
For all the bug reports
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Keywords||build
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-08-27 19:01 ---
I'll have to come up with some other solution when these POSIX macros aren't
available.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33203
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-08-27 19:02 ---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from jason at gcc dot gnu dot org 2007-08-27 20:02 ---
Subject: Bug 31337
Author: jason
Date: Mon Aug 27 20:02:22 2007
New Revision: 127838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127838
Log:
PR c++/31337
* gimplify.c (gimplify_modify_expr):
--- Comment #3 from ubizjak at gmail dot com 2007-08-27 20:22 ---
Patch and the description of the problem at
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01880.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #9 from hjl at lucon dot org 2007-08-27 20:39 ---
This patch:
Index: decl.c
===
--- decl.c (revision 127763)
+++ decl.c (working copy)
@@ -11525,6 +11525,9 @@ finish_function (int flags)
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
The following invalid code snippet triggers an ICE on mainline
(it was wrongly accepted before):
namespace N { }
struct N;
struct N* p;
bug.cc:2: error: 'struct N' redeclared as different kind of symbol
bug.cc:1: error: previous declaration of 'namespace
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33207
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33207
The following invalid code snippet triggers a broken diagnostic since
at least GCC 2.95.3:
struct A
{
bool b;
};
void f(A a)
{
a.b--;
}
bug.cc: In function 'void f(A)':
bug.cc:8: error: invalid use of '--' on bool variable '#'component_ref' not
The following invalid code snippet triggers a broken diagnostic on mainline:
templatetypename T void foo(int, T::x);
bug.cc:1: error: '#'template_type_parm' not supported by dump_expr#expression
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33209
--- Comment #10 from jakub at gcc dot gnu dot org 2007-08-27 21:42 ---
This really can't be worked around, but has to be fixed properly.
for i in -g; do ./g++ -B ./ -O2 $i -m32 -o auto_ptr /tmp/auto_ptr.ii
-L../x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/
The following invalid code snippet triggers a broken diagnostic since GCC
3.4.2:
==
templateint struct A;
templatetemplatetypename class B ABint::x operator() ();
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Broken diagnostics: |[4.1/4.2/4.3 regression]
gcc.target/spu/fixed-range.c fails now. It appreaded between revision 127789
and 127837.
This test is testing -mfixed-range which should be the same as multiple
-ffixed- but it fails now.
We get now:
lqd $2,32($sp)
Which is wrong.
--
Summary: [4.3 Regression] FAIL:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33211
--- Comment #12 from janis at gcc dot gnu dot org 2007-08-27 21:54 ---
Trunk currently fails on powerpc64-linux building
libstdc++-v3/src/system_error.cc. Hacking libtool a bit allows seeing the
message std::system_category causes a section type conflict. The file is
compiled with -O2
--- Comment #11 from hjl at lucon dot org 2007-08-27 21:57 ---
build_new_1 has
/* Now, check to see if this function is actually a placement
allocation function. This can happen even when PLACEMENT is NULL
because we might have something like:
struct S { void*
The following invalid code snippet triggers a broken diagnostic on mainline:
==
templateint void foo()
{
__is_class((int);
}
==
bug.cc: In function 'void
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33212
The following invalid code snippet triggers a broken diagnostic on mainline:
==
templatetemplatetypename class... struct A;
templatetemplatetypename... class... B struct AB... {};
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33213
--- Comment #6 from jason at gcc dot gnu dot org 2007-08-27 22:04 ---
Subject: Bug 31337
Author: jason
Date: Mon Aug 27 22:04:37 2007
New Revision: 127840
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127840
Log:
PR c++/31337
* gimplify.c (gimplify_modify_expr):
The following invalid code snippet triggers a broken diagnostic on mainline:
==
templatetypename... struct A {};
templatetemplatetypename... class T, typename ...U struct B
{
Atypename TU::X... a;
};
BA,int b;
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33214
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-27 22:10 ---
I verified this was caused by revision 127832:
http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00726.html
So what is most likely is happening is the inialization is happening in a
different order now which is wrong.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-28 00:05 ---
This is related to PR 31490
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|pcarlini at suse dot de |
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
69 matches
Mail list logo
