[Bug c++/33212] [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr

[pcarlini at suse dot de]

-- 

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
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-28 01:48:52
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33212

[Bug target/33168] [4.3 Regression] GCC Boot failure, building libstc++

[pinskia at gcc dot gnu dot org]

--- 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

[Bug middle-end/33211] [4.3 Regression] FAIL: gcc.target/spu/fixed-range.c scan-assembler lqd.*21

[pinskia at gcc dot gnu dot org]

--- 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.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33211

[Bug c++/33214] [4.3 regression] Broken diagnostic: 'argument_pack_select' not supported by dump_expr

[reichelt at gcc dot gnu dot org]

-- 

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

[Bug c++/33214] New: [4.3 regression] Broken diagnostic: 'argument_pack_select' not supported by dump_expr

[reichelt at gcc dot gnu dot org]

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;
==

bug.cc: In instantiation of 'B >':
bug.cc:8:   instantiated from here
bug.cc:5: error: no type named 'X' in 'struct A'


-- 
   Summary: [4.3 regression] Broken diagnostic:
'argument_pack_select' not supported by dump_expr
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33214

[Bug c++/31337] [4.2/4.3 regression] ICE with statement expression

[jason at gcc dot gnu dot org]

--- 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): Discard the assignment of
zero-sized types after calling gimplify_modify_expr_rhs.

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/gimplify.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337

[Bug c++/33213] [4.3 regression] Broken diagnostic: 'type_pack_expansion' not supported by dump_decl

[reichelt at gcc dot gnu dot org]

-- 

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

[Bug c++/33213] New: [4.3 regression] Broken diagnostic: 'type_pack_expansion' not supported by dump_decl

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers a broken diagnostic on mainline:

==
template class...> struct A;

template class... B> struct A {};
==

bug.cc:3: error: type/value mismatch at argument 1 in template parameter list
for 'template class > struct A'
bug.cc:3: error:   expected a template of type 'template
class', got '#'type_pack_expansion' not supported by
dump_decl#'


-- 
   Summary: [4.3 regression] Broken diagnostic:
'type_pack_expansion' not supported by dump_decl
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33213

[Bug c++/33212] [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr

[reichelt at gcc dot gnu dot org]

-- 

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

[Bug c++/33212] New: [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers a broken diagnostic on mainline:

==
template void foo()
{
  __is_class((int);
}
==

bug.cc: In function 'void foo()':
bug.cc:3: error: expected type-specifier before '(' token
bug.cc:3: error: expected `)' before '(' token
bug.cc:3: error: expected primary-expression before 'int'
bug.cc:3: error: '#'trait_expr' not supported by dump_expr#'
cannot be used as a function


-- 
   Summary: [4.3 regression] Broken diagnostic: 'trait_expr' not
supported by dump_expr
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33212

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[hjl at lucon dot org]

--- 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* operator new (size_t, int i = 0); };

 A call to `new S' will get this allocation function, even though
 there is no explicit placement argument.  If there is more than
 one argument, or there are variable arguments, then this is a
 placement allocation function.  */
  placement_allocation_fn_p
= (type_num_arguments (TREE_TYPE (alloc_fn)) > 1
   || varargs_function_p (alloc_fn));

  /* Preevaluate the placement args so that we don't reevaluate them for a
 placement delete.  */
  if (placement_allocation_fn_p)
{
  tree inits;
  stabilize_call (alloc_call, &inits);
  if (inits)
alloc_expr = build2 (COMPOUND_EXPR, TREE_TYPE (alloc_expr), inits,
 alloc_expr);
}

...
/* If any part of the object initialization terminates by throwing an
 exception and a suitable deallocation function can be found, the
 deallocation function is called to free the memory in which the
 object was being constructed, after which the exception continues
 to propagate in the context of the new-expression. If no
 unambiguous matching deallocation function can be found,
 propagating the exception does not cause the object's memory to be
 freed.  */
  if (flag_exceptions && ! use_java_new)
{
  enum tree_code dcode = array_p ? VEC_DELETE_EXPR : DELETE_EXPR;
  tree cleanup;

  /* The Standard is unclear here, but the right thing to do
 is to use the same method for finding deallocation
 functions that we use for finding allocation functions.  */
  cleanup = build_op_delete_call (dcode, alloc_node, size,
  globally_qualified_p,
  (placement_allocation_fn_p
   ? alloc_call : NULL_TREE),
  alloc_fn);

I think it is related.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199

[Bug middle-end/31490] Compile error section type conflict

[janis at gcc dot gnu dot org]

--- 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 and -fdata-sections; if either of those is removed then the
bootstrap succeeds.

This PR looked related (and Andrew Pinski confirmed that it is) so I tried the
patch from comment #10; it needs more parens to avoid warnings, but with that
patch the bootstrap succeeds.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490

[Bug middle-end/33211] [4.3 Regression] FAIL: gcc.target/spu/fixed-range.c scan-assembler lqd.*21

[pinskia at gcc dot gnu dot org]

-- 

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

[Bug middle-end/33211] New: [4.3 Regression] FAIL: gcc.target/spu/fixed-range.c scan-assembler lqd.*21

[pinskia at gcc dot gnu dot org]

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.target/spu/fixed-range.c
scan-assembler lqd.*21
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: spu-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33211

[Bug c++/33210] [4.1/4.2/4.3 regression] Broken diagnostics: 'bound_template_template_parm' not supported by pp_cxx_unqualified_id/dump_decl

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Broken diagnostics: |[4.1/4.2/4.3 regression]
   |'bound_template_template_par|Broken diagnostics:
   |m' not supported by |'bound_template_template_par
   |pp_cxx_unqualified_id/dump_d|m' not supported by
   |ecl |pp_cxx_unqualified_id/dump_d
   ||ecl
   Target Milestone|--- |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33210

[Bug c++/33210] New: Broken diagnostics: 'bound_template_template_parm' not supported by pp_cxx_unqualified_id/dump_decl

[reichelt at gcc dot gnu dot org]

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: `A<#`bound_template_template_parm' not supported by
pp_cxx_unqualified_id#::x> operator()()' must be a nonstatic member function

A similar error message is generated by the following code snippet since
GCC 3.4.0:

==
template class T> void foo(int, T::x);
==

bug.cc:1: error: `#`bound_template_template_parm' not supported by
dump_decl#::x' is not a type
bug.cc:1: error: ISO C++ forbids declaration of `parameter' with no type


-- 
   Summary: Broken diagnostics: 'bound_template_template_parm' not
supported by pp_cxx_unqualified_id/dump_decl
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33210

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[jakub at gcc dot gnu dot org]

--- 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-unknown-linux-gnu/32/libstdc++-v3/src/.libs/; ./auto_ptr;
echo $?; done
0
auto_ptr:
/export/gnu/import/rrs/127763/src/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc:72:
int test01(): Assertion `A::dtor_count == 1' failed.
Aborted
134

This shows -g affects code generation in this case, which is a very severe
problem.  Will look into this tomorrow unless somebody beats me to do that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199

[Bug c++/33209] Broken diagnostic: 'template_type_parm' not supported by dump_expr

[reichelt at gcc dot gnu dot org]

-- 

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

[Bug c++/33209] New: Broken diagnostic: 'template_type_parm' not supported by dump_expr

[reichelt at gcc dot gnu dot org]

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

Before we got the message:

bug.cc:1: error: 'T::x' is not a type


-- 
   Summary: Broken diagnostic: 'template_type_parm' not supported by
dump_expr
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33209

[Bug c++/33208] New: Broken diagnostic: 'component_ref' not supported by dump_decl

[reichelt at gcc dot gnu dot org]

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
supported by dump_decl#'


-- 
   Summary: Broken diagnostic: 'component_ref' not supported by
dump_decl
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33208

[Bug c++/33207] [4.3 regression] ICE redeclaring namespace as struct

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33207

[Bug c++/33207] [4.3 regression] ICE redeclaring namespace as struct

[reichelt at gcc dot gnu dot org]

-- 

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

[Bug c++/33207] New: [4.3 regression] ICE redeclaring namespace as struct

[reichelt at gcc dot gnu 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 N { }'
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3 regression] ICE redeclaring namespace as struct
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33207

[Bug c++/28558] [4.0/4.1/4.2/4.3 regression] Trouble with __attribute__ and non-PODs

[jason at gcc dot gnu dot org]

-- 

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 |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-08-06 14:41:54 |2007-08-27 21:16:03
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[hjl at lucon 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)
   && !DECL_REPLACEABLE_P (fndecl))
 TREE_NOTHROW (fndecl) = 1;

+  if (varargs_function_p (fndecl))
+DECL_UNINLINABLE (fndecl) = 1;
+
   /* This must come after expand_function_end because cleanups might
  have declarations (from inline functions) that need to go into
  this function's blocks.  */

also works on the testcase. I don't know if it is correct.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199

[Bug middle-end/33187] Missed cmove opportunity

[ubizjak at gmail dot com]

--- 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

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||08/msg01880.html
 Status|NEW |ASSIGNED
   Keywords||patch
   Last reconfirmed|2007-08-25 13:25:44 |2007-08-27 20:22:49
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33187

[Bug c++/31337] [4.2/4.3 regression] ICE with statement expression

[jason at gcc dot gnu dot org]

--- 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): Discard the assignment of
zero-sized types after calling gimplify_modify_expr_rhs.
* testsuite/g++.dg/ext/stmtexpr11.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/stmtexpr11.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337

[Bug tree-optimization/33173] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704

[dberlin at gcc dot gnu dot org]

--- 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 |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173

[Bug libstdc++/33203] [4.3 regression] libstdc++-v3 build broken on i386-pc-mingw32

[bkoz at gcc dot gnu dot org]

--- 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

[Bug libstdc++/33203] [4.3 regression] libstdc++-v3 build broken on i386-pc-mingw32

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
   Keywords||build
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33203

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[hjl at lucon dot org]

--- 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 related to this change I have seen, every single
one is the bug in the source code, not in gcc.  I don't believe this one
is an exception. Please check if you have mismatched symbol visibilities
in your source code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

[jason at gcc dot gnu dot org]

--- 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|Removed |Added

 AssignedTo|jason at redhat dot com |fche at redhat dot com
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319

[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves

[hjl at lucon dot org]

--- 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

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||08/msg01865.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[hjl at lucon dot org]

--- 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,--gc-sections 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[jason at gcc dot gnu dot org]

--- 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

 AssignedTo|jason at gcc dot gnu dot org|hjl at lucon dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[rguenther at suse dot de]

--- 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 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. I can provide a preprocessed testcase.
> 
> BTW, is that possible to create a C++ testcase to show the problem with
> vararg functions?

preprocessed source would be nice for a failing case.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[hjl at lucon dot org]

--- 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. I can provide a preprocessed testcase.

BTW, is that possible to create a C++ testcase to show the problem with
vararg functions?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199

[Bug c++/33205] New: bitfield optimizations causes corrupt bitfield expansion at runtime

[xk-corpse at hotmail dot com]

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 )
{
std::cout << "test failed: "
<< " (x=" << a.x
<< ") != " << expected
<< ", y=" << a.y
<< std::endl;
return 1;
}

std::cout << "test succedeed" << std::endl;

return 0;
}

unsigned n = 0xFE7B4873U;
--

output:
test failed:  (x=18547) != 2163, y=14829

14-bit unsigned field expands with non-zero padding bits


appears with gcc-4.2.1, gcc-4.1.2, gcc-4.2-20070822
does not appear with gcc-3.4.6

gcc was configured and built with crosstool-0.43 (with glibc-2.3.2)

powerpc-603-linux-gnu-g++ -v
Using built-in specs.
Target: powerpc-603-linux-gnu
Configured with:
/home/corpse/tmp/interlink/crosstool-0.43/build/powerpc-603-linux-gnu/gcc-4.2.1-glibc-2.3.2/gcc-4.2.1/configure
--target=powerpc-603-linux-gnu --host=i686-host_pc-linux-gnu
--prefix=/opt/compilers/gcc-4.2.1-glibc-2.3.2/powerpc-603-linux-gnu
--with-cpu=603 --enable-cxx-flags=-mcpu=603
--with-headers=/opt/compilers/gcc-4.2.1-glibc-2.3.2/powerpc-603-linux-gnu/powerpc-603-linux-gnu/include
--with-local-prefix=/opt/compilers/gcc-4.2.1-glibc-2.3.2/powerpc-603-linux-gnu/powerpc-603-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.2.1


-- 
   Summary: bitfield optimizations causes corrupt bitfield expansion
at runtime
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xk-corpse at hotmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-603-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33205

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[rguenth at gcc dot gnu dot org]

--- 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

[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves

[jakub at gcc dot gnu dot org]

--- 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

[Bug tree-optimization/33173] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704

[dberlin at gcc dot gnu dot org]

--- 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 PR tree-optimization/33173
* tree-ssa-alias.c (find_used_portions): Fix reversed test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr33173.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr26421.c
trunk/gcc/tree-ssa-alias.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173

[Bug target/31385] gcc fails to find spill register for decimal arithmetic

[hjl at lucon dot org]

--- 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

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31385

[Bug target/31385] gcc fails to find spill register for decimal arithmetic

[hjl at gcc dot gnu dot org]

--- 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/31385
* config/i386/i386.h (VALID_DFP_MODE_P): New.
* config/i386/i386.c (ix86_hard_regno_mode_ok): Allow DFP in
GPR.

gcc/testsuite/

2007-08-27  H.J. Lu  <[EMAIL PROTECTED]>

PR target/31385
* gcc.dg/dfp/pr31385.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/pr31385.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31385

[Bug fortran/33202] 'NO' runtime problem with a code compiled using gfotran ... and it should !

[burnus at gcc dot gnu dot org]

--- 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?id=33202

[Bug fortran/33204] New: Run-time argument check for procedures (run-time interface checking)

[burnus at gcc dot gnu dot org]

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 call, these are initialized.
In each procedure, they are compared with the settings needed for the dummy
argument. As not all files might be compiled with the same option, one has
additionally to check whether the address of the function matches the address
of the called function.

Related bugs:
- Whole-file checking: PR26227 
- Generating .mod files for procedures which are not contained in modules or
the PROGRAM: PR30658


-- 
   Summary: Run-time argument check for procedures (run-time
interface checking)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33204

[Bug fortran/33202] 'NO' runtime problem with a code compiled using gfotran ... and it should !

[leroux at lpmc dot univ-montp2 dot fr]

--- 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

-- 

Sébastien Le Roux
Doctorant
LPMC-Institut C. Gerhardt UMR 5253
CC003
Université de Montpellier II
Place E. Bataillon
34095 MONTPELLIER cedex 05
E mail: [EMAIL PROTECTED]
Tel: +33(0)4.67.14.41.21
Fax: +33(0)4.67.14.41.90



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33202

[Bug fortran/33202] 'NO' runtime problem with a code compiled using gfotran ... and it should !

[burnus at gcc dot gnu dot org]

--- 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 the latter with
gfortran *for your program*.

Depending on the exact program and compiler options, it crashes using one or
the other compiler. It also depends (using glibc) on the setting of
MALLOC_CHECK_ (see "man 3 malloc").

A much more reliable way to catch such errors is to run the program through
valgrind which shows e.g. "Invalid read of size 1" - though this also does not
work always (see below).

Using the program
--
SUBROUTINE Routine(var1, var2)
INTEGER, INTENT(IN) :: var1
CHARACTER(LEN=3), INTENT(IN) :: var2
print *, var1
print *, var2
end subroutine
--
Call Routine(5)
end
--
- gfortran does not crash here (and valgrind does not find the error either)
- ifort does not crash here (and valgrind does not find the error either)
- g95 crashes

The actual call of g95 and gfortran is the same (dump of the tree):
  routine_ (&U0);;// g95
and
  routine (&C.1016);  // gfortran

There are essentially only two possibilities to detect this:
a) Using an explicit interface at compile time
b) Doing an explicit checking at run time

For (a):
- Best: put the routine in a module and USE it or in a CONTAINS of the PROGRAM.
- Write an interface so that still the checking
(Useful e.g. for Lapack which as Fortran 77 code does not come as module.)

- Put them in the same file, this allows the compiler to do more checks.
(gfortran currently does not do same file checks, though this is planned)
- Use a compiler option to generate .mod files to check for this; ifort has
-gen-interfaces which does so. (Also planned for gfortran.)

For (b): Some compiler such as NAG f95 pass additional information so that the
arguments can be checked at run time. This slows down the program a lot and
also needs an extra option.

Anything else such as relying on a segmentation fault is (unfortunately?) not
reliable.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   GCC host triplet| i686   |i686
 Resolution||INVALID
Summary|'NO' runtime problem with a |'NO' runtime problem with a
   |code compiled using gfotran |code compiled using gfotran
   |... and it should ! |... and it should !


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33202

[Bug libstdc++/33203] New: [4.3 regression] libstdc++-v3 build broken on i386-pc-mingw32

[fxcoudert at gcc dot gnu dot org]

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-mingw32/winsup/mingw
-L/home/FX/ibin/i386-pc-mingw32/winsup/w32api/lib -isystem
/home/FX/trunk/winsup/mingw/include -isystem
/home/FX/trunk/winsup/w32api/include -B/mingw/i386-pc-mingw32/bin/
-B/mingw/i386-pc-mingw32/lib/ -isystem /mingw/i386-pc-mingw32/include -isystem
/mingw/i386-pc-mingw32/sys-include
-I/home/FX/ibin/i386-pc-mingw32/libstdc++-v3/include/i386-pc-mingw32
-I/home/FX/ibin/i386-pc-mingw32/libstdc++-v3/include
-I/home/FX/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -std=gnu++0x -c
../../../../trunk/libstdc++-v3/src/system_error.cc  -DDLL_EXPORT -DPIC -o
.libs/system_error.o
In file included from ../../../../trunk/libstdc++-v3/src/system_error.cc:32:
C:/msys/1.0.10/home/FX/ibin/i386-pc-mingw32/libstdc++-v3/include/system_error:58:
error: 'EAFNOSUPPORT' was not declared in this scope
C:/msys/1.0.10/home/FX/ibin/i386-pc-mingw32/libstdc++-v3/include/system_error:59:
error: 'EADDRINUSE' was not declared in this scope
C:/msys/1.0.10/home/FX/ibin/i386-pc-mingw32/libstdc++-v3/include/system_error:60:
error: 'EADDRNOTAVAIL' was not declared in this scope

and lots others. The full list of missing macros is: EAFNOSUPPORT EADDRINUSE
EADDRNOTAVAIL EISCONN EBADMSG ECONNABORTED EALREADY ECONNREFUSED ECONNRESET
EDESTADDRREQ EHOSTUNREACH EIDRM EMSGSIZE ENETDOWN ENETRESET ENETUNREACH ENOBUFS
ENOLINK ENODATA ENOMSG ENOPROTOOPT ENOSR ENOTSOCK ENOSTR ENOTCONN ENOTSUP
ECANCELED EINPROGRESS EOPNOTSUPP EWOULDBLOCK EPROTO EPROTONOSUPPORT ETIME
ETXTBSY ETIMEDOUT ELOOP EOVERFLOW EPROTOTYPE

It's been a long time since I last bootstrapped with C++ on i386-pc-mingw32,
but this seems to have been introduced by:

2007-08-23  Benjamin Kosnik  <[EMAIL PROTECTED]>

* include/std/system_error: New file.


-- 
   Summary: [4.3 regression] libstdc++-v3 build broken on i386-pc-
mingw32
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: i386-pc-mingw32
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33203

[Bug c++/13358] long long and C++ do not mix well

[lloyd at randombit dot net]

--- 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 unsigned long long
just as in C99. I think that would mean this warning should be disabled (in
C++0x mode) on all platforms.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358

[Bug fortran/33174] Testsuite: unexpected failures

[dir at lanl dot gov]

--- 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 -

(gdb) run
Starting program: /usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.3.0/f951.exe
pr32417.f90 -quiet -dumpbase pr32417.f90 -mtune=generic -auxbase pr32417 -O
-version -fintrinsic-modules-path
/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.3.0/finclude
Loaded symbols for /cygdrive/d/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/d/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/d/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/d/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/cygiconv-2.dll
Loaded symbols for /usr/bin/cygintl-8.dll
GNU F95 version 4.3.0 20070723 (experimental) (i686-pc-cygwin)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.125), GMP version 4.1.4, MPFR version 2.2.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Breakpoint 1, fancy_abort (file=0xbc554b "../../gcc/gcc/tree.c", line=3077,
function=0xbc5f2f "build2_stat") at ../../gcc/gcc/diagnostic.c:656
656   internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) traceback
Undefined command: "traceback".  Try "help".
(gdb) backtrace
#0  fancy_abort (file=0xbc554b "../../gcc/gcc/tree.c", line=3077,
function=0xbc5f2f "build2_stat") at ../../gcc/gcc/diagnostic.c:656
#1  0x004bb42e in build2_stat (code=MINUS_EXPR, tt=0x7ff90cb0, arg0=0x7fcbef60,
arg1=0x7fcbef40) at ../../gcc/gcc/tree.c:3101
#2  0x0056a7a7 in fold_build2_stat (code=MINUS_EXPR, type=0x7ff90cb0,
op0=0x7fcbef60, op1=0x7fcbef40) at ../../gcc/gcc/fold-const.c:13097
#3  0x00561937 in fold_binary (code=PLUS_EXPR, type=0x7ff90cb0, op0=0x7fcbeea0,
op1=0x7fcbef20) at ../../gcc/gcc/fold-const.c:9278
#4  0x0056a77f in fold_build2_stat (code=PLUS_EXPR, type=0x7ff90cb0,
op0=0x7fcbeea0, op1=0x7fcbef20) at ../../gcc/gcc/fold-const.c:13095
#5  0x005fdd3a in add_to_parts (parts=0x7fcbeea0, elt=0x7ff90cb0) at
../../gcc/gcc/tree-ssa-address.c:426
#6  0x005fe0ab in create_mem_ref (bsi=0x22c810, type=0x7ff90b60, addr=0x22c790)
at ../../gcc/gcc/tree-ssa-address.c:546
#7  0x0097c8da in rewrite_use (data=0x22ca10, use=0x1ef97a0, cand=0x1f0db90) at
../../gcc/gcc/tree-ssa-loop-ivopts.c:5091
#8  0x0097edf3 in tree_ssa_iv_optimize_loop (data=0x22ca10, loop=) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5179
#9  0x009801ce in tree_ssa_iv_optimize () at
../../gcc/gcc/tree-ssa-loop-ivopts.c:5382
#10 0x00a55b8b in tree_ssa_loop_ivopts () at ../../gcc/gcc/tree-ssa-loop.c:514
#11 0x006dc1e8 in execute_one_pass (pass=0xb8e6e0) at
../../gcc/gcc/passes.c:1125
#12 0x006dc38e in execute_pass_list (pass=0xb8ea20) at
../../gcc/gcc/passes.c:1178
#13 0x006dc3a1 in execute_pass_list (pass=0xb8dc30) at
../../gcc/gcc/passes.c:1179
#14 0x006dc3a1 in execute_pass_list (pass=0xb8b350) at
../../gcc/gcc/passes.c:1179
#15 0x00714298 in tree_rest_of_compilation (fndecl=0x7fc9b900) at
../../gcc/gcc/tree-optimize.c:406
#16 0x006dd380 in cgraph_expand_function (node=0x7fc9ba80) at
../../gcc/gcc/cgraphunit.c:1073
#17 0x006def9f in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1142
#18 0x0046ca1f in gfc_be_parse_file (set_yydebug=0) at
../../gcc/gcc/fortran/f95-lang.c:305
#19 0x00523800 in toplev_main (argc=12, argv=0x1eb2d58) at
../../gcc/gcc/toplev.c:1044
#20 0x004b131a in main (argc=12, argv=0x1eb2d58) at ../../gcc/gcc/main.c:35


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174

[Bug fortran/33202] New: 'NO' runtime problem with a code compiled using gfotran ... and it should !

[leroux at lpmc dot univ-montp2 dot fr]

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 compiled perfecty with gfortran .. with the bad number of variables
in the call. 
It works too with ifortran and g95 ... but with this two the execution failed
with an segmentation fault ... and not with the code compiled with gfotran.
(gfortran used compilation option were: 
-x f95-cpp-input -fbounds-check -DD -fimplicit-none -pedantic -g -pg)
The code should stop and


-- 
   Summary: 'NO' runtime problem with a code compiled using gfotran
... and it should !
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: leroux at lpmc dot univ-montp2 dot fr
  GCC host triplet:  i686
GCC target triplet: Linux FC6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33202

[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu

[jakub at gcc dot gnu dot org]

--- 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 ia64 defines TARGET_UNWIND_INFO and arm.h defines
DWARF2_UNWIND_INFO 1, so the defaults.h change shouldn't affect arm at all.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552

[Bug libstdc++/33201] libstc++ togehter wiht uclibc cannot format double in iostream

[g dot janak at unicontrol dot de]

--- 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 mainstream gcc.
(I think not in the near feature).

Soory...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33201

[Bug libstdc++/33201] libstc++ togehter wiht uclibc cannot format double in iostream

[pcarlini at suse dot de]

--- 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 doesn't exist here.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33201

[Bug libstdc++/33201] libstc++ togehter wiht uclibc cannot format double in iostream

[g dot janak at unicontrol dot de]

--- 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
  // string.  If vsnprintf is available use it, otherwise fall back to
  // the unsafe vsprintf which, in general, can be dangerous and should
  // be avoided.
"

and line 111:
const int __ret = std::vsnprintf(__out, __size, __fmt, __args);


Where is the sprintf ???
I dont understand it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33201

[Bug rtl-optimization/33148] [4.2/4.3 Regresion] ICE in trunc_int_for_mode, at explow.c:56 during combine

[jakub at gcc dot gnu dot org]

--- 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|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-27 10:14:50
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148

[Bug fortran/33174] Testsuite: unexpected failures

[fxcoudert at gcc dot gnu dot org]

--- 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 themselves:
  * it is currently expected that
gfortran.fortran-torture/execute/intrinsic_integer.f90 fails, because of a bug
in the cygwin math library; I'm surprised that it doesn't fail for you
  * could you try to compile pr32417.f90 yourself, and produce a backtrace of
the ICE? Use "gfortran -v pr32417.f90", from the output of that command, look
at the command-line for the "f951" command, run it under gdb (gdb -args
/path/to/f951 .), set a breakpoint on fancy_abort ("break fancy_abort") and
when the breakpoint (or a segfault) is hit, ask for backtrace ("backtrace").
Copy-paste the result here.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet||i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174

[Bug libstdc++/33201] libstc++ togehter wiht uclibc cannot format double in iostream

[pcarlini at suse dot de]

--- 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 that is uses
sprintf.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33201

[Bug target/33177] Wrong result from nint() on Cygwin

[fxcoudert at gcc dot gnu 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33177

[Bug libstdc++/33128] std::tr1::uniform_int returns value out of range

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-27 09:47:32
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33128

[Bug libstdc++/33201] libstc++ togehter wiht uclibc cannot format double in iostream

[g dot janak at unicontrol dot de]

--- 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 powerpc where I
found the Problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33201

[Bug libstdc++/33201] New: libstc++ togehter wiht uclibc cannot format double in iostream

[g dot janak at unicontrol dot de]

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 Story:

First i thought its an uclibc Bug:
http://bugs.busybox.net/view.php?id=1090

The problem was:
putting a double in a stream:
cout << 10.5 ;

Produce an empty string, or some garbage characters.

Searchign the reason I found locale_facets.tcc the do_put impleemtation which
is used for formating a double into a string in c++ iostream's. (gcc 4.2.1 :
line 1143) but its in all gcc 4.x.x i looked .


In the implementation the __convert_from_v the __cs_size is used.
You can verify this with the following testCode

#define protected public
#include 
using namespace std;

int main()
{
float d=23.12;

char * __cs = (char*) malloc(100);
int __cs_size=100;
char __fbuf[16]="%f";
const streamsize __prec = 6;
__c_locale loc;
locale::facet::_S_create_c_locale(loc, "C");

__convert_from_v(loc, __cs, 0, __fbuf, __prec, d);

printf("test: %s\n",__cs);
return 0;
}

This Fails in g++ + uclibc  on a PowerPC Architecture.


I hope I understand it correctly, i'm not very deep inside gcc/libstdc++
sources.

--- gcc-4.2.1/libstdc++-v3/include/bits/locale_facets.tcc.orig  2007-08-27
11:19:50.0 +0200
+++ gcc-4.2.1/libstdc++-v3/include/bits/locale_facets.tcc   2007-08-27
11:19:52.0 +0200
@@ -1143,7 +1143,7 @@
const int __cs_size = __fixed ? __max_exp + __prec + 4
  : __max_digits * 2 + __prec;
char* __cs = static_cast(__builtin_alloca(__cs_size));
-   __len = std::__convert_from_v(_S_get_c_locale(), __cs, 0, __fbuf, 
+   __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
__fbuf, 
  __prec, __v);
 #endif


-- 
   Summary: libstc++ togehter wiht uclibc cannot format double in
iostream
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: g dot janak at unicontrol dot de
 GCC build triplet: powerpc-linux-uclibc
GCC target triplet: powerpc-linux-uclibc


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33201

[Bug rtl-optimization/33148] [4.2/4.3 Regresion] ICE in trunc_int_for_mode, at explow.c:56 during combine

[jakub at gcc dot gnu dot org]

--- 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] < q[1])
mask = 0xff;
  else
mask = 0;

  for (i = 0; 8 * i < w; i++)
{
  b ^= mask;
  *p++ = b;
}
  return 0;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148

[Bug middle-end/33195] [4.2 Regression] ICE: calc_dfs_tree, at dominance.c:374

[rguenth at gcc dot gnu dot org]

--- 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|UNCONFIRMED |NEW
  Component|c++ |middle-end
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.2.1
  Known to work||4.1.2 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-08-27 08:09:50
   date||
Summary|ICE: calc_dfs_tree, at  |[4.2 Regression] ICE:
   |dominance.c:374 |calc_dfs_tree, at
   ||dominance.c:374
   Target Milestone|--- |4.2.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33195

[Bug c++/33195] ICE: calc_dfs_tree, at dominance.c:374

[rguenth at gcc dot gnu dot org]

--- 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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

--- 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=32758

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

--- 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

[Bug c++/33195] ICE: calc_dfs_tree, at dominance.c:374

[rguenth at gcc dot gnu dot org]

--- 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

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

[rguenth at gcc dot gnu dot org]

--- 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 arguments
   are not used.  See PR32493.  */
#include 
static inline __attribute__((always_inline)) void __check_printsym_format(const
char *fmt, ...)
{
}
static inline __attribute__((always_inline)) void print_symbol(const char *fmt,
ptrdiff_t addr)
{
 __check_printsym_format(fmt, "");
}
void do_initcalls(void **call)
{
   print_symbol(": %s()", (ptrdiff_t) *call);
}


That is, for C we didn't exclude varargs functions from inlining.  (Not
that I think this is particular wise, but we'd regress in the testcase
above)

I'll have a look.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199