--
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
--- 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
--- 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.
--
--
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
The following invalid code snippet triggers a broken diagnostic on mainline:
==
template struct A {};
template class T, typename ...U> struct B
{
A::X...> a;
};
B b;
--- 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=gcc&view=rev&rev=127840
Log:
PR c++/31337
* gimplify.c (gimplify_modify_expr):
--
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
The following invalid code snippet triggers a broken diagnostic on mainline:
==
template class...> struct A;
template class... B> struct A {};
==
bug.cc:3: erro
--
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:
==
template void foo()
{
__is_class((int);
}
==
bug.cc: In function 'void foo()':
--- 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* opera
--- 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 -O
--
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
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: gcc
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Broken diagnostics: |[4.1/4.2/4.3 regression]
|'bound_template_template
The following invalid code snippet triggers a broken diagnostic since GCC
3.4.2:
==
template struct A;
template class B> A::x> operator() ();
==
bug.cc:3: error
--- 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/
-Wl,-rpath,../x86_64
--
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
The following invalid code snippet triggers a broken diagnostic on mainline:
template void foo(int, T::x);
bug.cc:1: error: '#'template_type_parm' not supported by dump_expr#::x' is not a type
Befor
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
suppo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33207
--
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
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
--
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
--- 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)
&& !DEC
--- 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 #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=gcc&view=rev&rev=127838
Log:
PR c++/31337
* gimplify.c (gimplify_modify_expr):
--- 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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Keywords||build
Targ
--- 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 repo
--- 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|Remov
--- 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 #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=14124&action=view)
A testcase
It should be compiled with
-O2 -m32 -g -O2 -ffunction-sections -fdata-sections -fmessage-length=0 -g -O2
-Wl,
--- 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 #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 o
--- 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
platforms
test.cxx
--
#include
struct A
{
unsigned short x:14;
unsigned short y:14;
};
extern unsigned n;
int main()
{
A a;
a.x = n & 0x3FFF;
a.y = (n>>14) & 0x3FFF;
unsigned expected = n & 0x3FFF;
if( a.x != expected )
--- 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
--- 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 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=gcc&view=rev&rev=127834
Log:
2007-08-27 Daniel Berlin <[EMAIL PROTECTED]>
Fix P
--- 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 #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=gcc&view=rev&rev=127833
Log:
gcc/
2007-08-27 H.J. Lu <[EMAIL PROTECTED]>
PR target/313
--- 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
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 #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
--
=
--- 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
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
-L/home/FX/ibin/i386-pc-mi
--- 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 unsig
--- 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 -
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 compile
--- 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 i
--- 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 ma
--- 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 #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 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
AssignedTo|u
--- 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 t
--- 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 #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.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- 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=14123&action=view)
Fix the Bug, by using cs_size as the size.
Dont know if anythink goes broken. It works with uclibc at powerp
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 S
--- 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]
--- 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
Status|UNCON
--- 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=14122&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33195
--- 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=14121&action=view)
Assembly output from preprocessing the java_raw_api at O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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=14120&action=view)
Preprocessed source at O1 java_raw_api
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
--- 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 #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 argumen
69 matches
Mail list logo
