[Bug c++/28560] [4.1/4.2 regression] Trouble with __attribute__ in template parameter

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-01-23 08:21 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] Trouble
   |Trouble with __attribute__  |with __attribute__ in
   |in template parameter   |template parameter


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

[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)

[Ralf dot Wildenhues at gmx dot de]

--- Comment #3 from Ralf dot Wildenhues at gmx dot de  2008-01-23 08:21 
---
Created an attachment (id=15005)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15005&action=view)
reduced testcase


-- 


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

[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)

[Ralf dot Wildenhues at gmx dot de]

--- Comment #4 from Ralf dot Wildenhues at gmx dot de  2008-01-23 08:23 
---
valgrind output (gcc (GCC) 4.3.0 20080122 (experimental)):

send_tiny.i: In function ‘sendto_realops_lev’:
send_tiny.i:77: warning: implicit declaration of function ‘strlen’
send_tiny.i:77: warning: incompatible implicit declaration of built-in function
‘strlen’
send_tiny.i:78: warning: implicit declaration of function ‘vsendto_one’
--17488-- REDIR: 0x4ccb070 (memmove) redirected to 0x4a1c0f0 (memmove)
==17488== Invalid write of size 8
==17488==at 0x82D8D9: reachable_at_most_once (tree-stdarg.c:101)
==17488==by 0x82F530: va_list_ptr_read (tree-stdarg.c:377)
==17488==by 0x8307B5: execute_optimize_stdarg (tree-stdarg.c:823)
==17488==by 0x656302: execute_one_pass (passes.c:1118)
==17488==by 0x6564CB: execute_pass_list (passes.c:1171)
==17488==by 0x6564DD: execute_pass_list (passes.c:1172)
==17488==by 0x734718: tree_rest_of_compilation (tree-optimize.c:404)
==17488==by 0x8F44D1: cgraph_expand_function (cgraphunit.c:1152)
==17488==by 0x8F63F8: cgraph_optimize (cgraphunit.c:1215)
==17488==by 0x4174FC: c_write_global_declarations (c-decl.c:8079)
==17488==by 0x6D3F45: toplev_main (toplev.c:1055)
==17488==by 0x4C7549A: (below main) (in /lib/libc-2.3.6.so)
==17488==  Address 0x51177b8 is 0 bytes after a block of size 152 alloc'd
==17488==at 0x4A19DAB: malloc (vg_replace_malloc.c:207)
==17488==by 0xB34CA7: xmalloc (xmalloc.c:147)
==17488==by 0x82D73D: reachable_at_most_once (tree-stdarg.c:61)
==17488==by 0x82F530: va_list_ptr_read (tree-stdarg.c:377)
==17488==by 0x8307B5: execute_optimize_stdarg (tree-stdarg.c:823)
==17488==by 0x656302: execute_one_pass (passes.c:1118)
==17488==by 0x6564CB: execute_pass_list (passes.c:1171)
==17488==by 0x6564DD: execute_pass_list (passes.c:1172)
==17488==by 0x734718: tree_rest_of_compilation (tree-optimize.c:404)
==17488==by 0x8F44D1: cgraph_expand_function (cgraphunit.c:1152)
==17488==by 0x8F63F8: cgraph_optimize (cgraphunit.c:1215)
==17488==by 0x4174FC: c_write_global_declarations (c-decl.c:8079)
==17488==
==17488== Invalid read of size 8
==17488==at 0x82D819: reachable_at_most_once (tree-stdarg.c:76)
==17488==by 0x82F530: va_list_ptr_read (tree-stdarg.c:377)
==17488==by 0x8307B5: execute_optimize_stdarg (tree-stdarg.c:823)
==17488==by 0x656302: execute_one_pass (passes.c:1118)
==17488==by 0x6564CB: execute_pass_list (passes.c:1171)
==17488==by 0x6564DD: execute_pass_list (passes.c:1172)
==17488==by 0x734718: tree_rest_of_compilation (tree-optimize.c:404)
==17488==by 0x8F44D1: cgraph_expand_function (cgraphunit.c:1152)
==17488==by 0x8F63F8: cgraph_optimize (cgraphunit.c:1215)
==17488==by 0x4174FC: c_write_global_declarations (c-decl.c:8079)
==17488==by 0x6D3F45: toplev_main (toplev.c:1055)
==17488==by 0x4C7549A: (below main) (in /lib/libc-2.3.6.so)
==17488==  Address 0x51177c0 is 8 bytes after a block of size 152 alloc'd
==17488==at 0x4A19DAB: malloc (vg_replace_malloc.c:207)
==17488==by 0xB34CA7: xmalloc (xmalloc.c:147)
==17488==by 0x82D73D: reachable_at_most_once (tree-stdarg.c:61)
==17488==by 0x82F530: va_list_ptr_read (tree-stdarg.c:377)
==17488==by 0x8307B5: execute_optimize_stdarg (tree-stdarg.c:823)
==17488==by 0x656302: execute_one_pass (passes.c:1118)
==17488==by 0x6564CB: execute_pass_list (passes.c:1171)
==17488==by 0x6564DD: execute_pass_list (passes.c:1172)
==17488==by 0x734718: tree_rest_of_compilation (tree-optimize.c:404)
==17488==by 0x8F44D1: cgraph_expand_function (cgraphunit.c:1152)
==17488==by 0x8F63F8: cgraph_optimize (cgraphunit.c:1215)
==17488==by 0x4174FC: c_write_global_declarations (c-decl.c:8079)
==17488==
==17488== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 2 from 1)


-- 

Ralf dot Wildenhues at gmx dot de changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

[Bug c++/34829] [4.3 Regression] placement new with primitive Java types rejected

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-01-23 08:34 ---
Subject: Bug 34829

Author: jakub
Date: Wed Jan 23 08:33:22 2008
New Revision: 131756

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131756
Log:
PR c++/34829
* g++.dg/ext/pr34829.C (operator new): Use size_t instead of
unsigned int for the first argument.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/pr34829.C


-- 


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

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

--- Comment #48 from steven at gcc dot gnu dot org  2008-01-23 08:52 ---
The priority of this bug is too high.  If it wasn't just for recording that
this behavior exists in VRP and CPROP, I would propose to just close this bug
as WONTFIX.  The test case is just too obscure, no man or machine would
normally generate anything like this.

So can a release manager please lower the priority of this bug report?

For GCC 4.4 I hopefully will nuke the CPROP problem.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug fortran/34872] [4.3 Regression] Spurious error in snapshot of 01/18/08: Statement at (1) is not a valid branch target statement for the branch statement at (2)

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2008-01-23 08:54 ---
Having slept on it, I know where the problem is - old_locus in decode_statement
points to the whitespace after a statement label.  In consequence, if the label
is deleted, it is not parsed again.

A fix is regtesting.

Paul


-- 


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

[Bug rtl-optimization/19580] [4.0/4.1/4.2/4.3 Regression] missed load/store motion

[steven at gcc dot gnu dot org]

--- Comment #36 from steven at gcc dot gnu dot org  2008-01-23 08:54 ---
What is the relation between the LIM patch and the alias oracle patch that was
floated some time ago?


-- 


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

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[rguenth at gcc dot gnu dot org]

--- Comment #49 from rguenth at gcc dot gnu dot org  2008-01-23 09:06 
---
I think it is reasonable to build in limits into passes that do work not
linear (or at least quadratic) in the number of statements, BBs or edges.

The testcase is probably just extracting the core problem from a real-world
testcase (where the situation is probably also not that bad).


-- 


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

[Bug middle-end/34856] [4.3 Regression] ICE with some constant vectors

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2008-01-23 09:21 ---
Subject: Re:  [4.3 Regression] ICE with some
 constant vectors

On Tue, 22 Jan 2008, dominiq at lps dot ens dot fr wrote:

> --- Comment #8 from dominiq at lps dot ens dot fr  2008-01-22 23:50 
> ---
> On i686-apple-darwin9, testsuite/gcc.c-torture/compile/pr34856.c gives an ICE
> at -O3 with trunk rev.131745:
> 
> [ibook-dhum] f90/bug% /opt/gcc/w1-gcc4.3w/bin/gcc -O3
> /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr34856.c
> /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr34856.c: In function
> 'f1':
> /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr34856.c:16: error:
> invalid reference prefix
> {(unsigned int) &g[16]}
> 
> /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr34856.c:16: internal
> compiler error: verify_stmts failed

Works for me.  The tree-cfg.c hunk was supposed to fix this.  Instead
it should ICE in

internal compiler error: in simplify_immed_subreg, at simplify-rtx.c:4761

Richard.


-- 


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

[Bug middle-end/34856] [4.3 Regression] ICE with some constant vectors

[dominiq at lps dot ens dot fr]

--- Comment #11 from dominiq at lps dot ens dot fr  2008-01-23 09:28 ---
> The tree-cfg.c hunk was supposed to fix this.

Additional info: on i686-apple-darwin9 the failures disappear with -m64.


-- 


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

[Bug rtl-optimization/19580] [4.0/4.1/4.2/4.3 Regression] missed load/store motion

[rguenth at gcc dot gnu dot org]

--- Comment #37 from rguenth at gcc dot gnu dot org  2008-01-23 09:12 
---
The lim patch applies alias-oracle techniques to the loop invariant and store
motion parts of tree-ssa-loop-im.c.  I have a forward-port of Zdeneks patch to
current trunk.

Note that the alias-oracle patch for SCCVN does not fix this PR (it seems to
be mostly ineffective for PRE, possibly PHI translation needs adjustments
as well).


-- 


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

[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/34931] FAIL: gcc.dg/pr28796-[12].c (test for excess errors)

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-01-23 10:34 ---
Of course I tested the backport on x86_64-unknown-linux-gnu, where it worked
for me.  And it should via

fold_builtin_classify
...
case BUILT_IN_FINITE:
  if (!HONOR_NANS (TYPE_MODE (TREE_TYPE (arg)))
  && !HONOR_INFINITIES (TYPE_MODE (TREE_TYPE (arg
return omit_one_operand (type, integer_zero_node, arg);

ha!  And indeed we miss:

2006-10-21  Richard Guenther  <[EMAIL PROTECTED]>

* builtins.c (fold_builtin_classify): Fix typo.

I'll take care of it.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 10:34:45
   date||


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

[Bug middle-end/34931] FAIL: gcc.dg/pr28796-[12].c (test for excess errors)

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-01-23 10:38 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.3


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

[Bug middle-end/34882] g++: Internal error: Killed (program cc1plus)

[myway dot cn at gmail dot com]

--- Comment #2 from myway dot cn at gmail dot com  2008-01-23 10:40 ---
Created an attachment (id=15006)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15006&action=view)
source file


-- 


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

[Bug libgcj/14759] ServerSocketChannel causes Selector.select() to return immediatly

[debian-gcc at lists dot debian dot org]

--- Comment #5 from debian-gcc at lists dot debian dot org  2008-01-23 
10:40 ---
2005-01-15> I'm working on it.
Michael, any progress ;-?

  Matthias


-- 


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

[Bug middle-end/34882] g++: Internal error: Killed (program cc1plus)

[myway dot cn at gmail dot com]

--- Comment #3 from myway dot cn at gmail dot com  2008-01-23 10:41 ---
(In reply to comment #1)
> >g++: Internal error: Killed (program cc1plus)
> How much memory do you have?  How much swap space do you have?
> Can you attach command_download.ii?

32M RAM of NSLU2
200MB swap space 


-- 


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

[Bug libgcj/14759] ServerSocketChannel causes Selector.select() to return immediatly

[konqueror at gmx dot de]

--- Comment #6 from konqueror at gmx dot de  2008-01-23 10:43 ---
Give back.


-- 

konqueror at gmx dot de changed:

   What|Removed |Added

 AssignedTo|konqueror at gmx dot de |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug bootstrap/33200] install fails when trying to install fix-header since fix-header wasn't built

[aldot at gcc dot gnu dot org]

--- Comment #7 from aldot at gcc dot gnu dot org  2008-01-23 10:43 ---
I've "fixed" superH locally via


\\ gcc PR33200
Index: gcc-4.3.0/gcc/config.gcc
===
--- gcc-4.3.0/gcc/config.gcc(revision 131628)
+++ gcc-4.3.0/gcc/config.gcc(working copy)
@@ -2302,7 +2305,7 @@ sh-*-symbianelf* | sh[12346l]*-*-symbian
if test x${enable_incomplete_targets} = xyes ; then
tm_defines="$tm_defines SUPPORT_SH1=1 SUPPORT_SH2E=1
SUPPORT_SH4=1 SUPPORT_SH4_SINGLE=1 SUPPORT_SH2A=1 SUPPORT_SH2A_SINGLE=1
SUPPORT_SH5_32MEDIA=1 SUPPORT_SH5_32MEDIA_NOFPU=1 SUPPORT_SH5_64MEDIA=1
SUPPORT_SH5_64MEDIA_NOFPU=1"
fi
-   use_fixproto=yes
+   # XXX: why? use_fixproto=yes
;;
 sh-*-rtemscoff*)
tmake_file="sh/t-sh t-rtems sh/t-rtems"


until somebody knowledgeable explains how this should be fixed for good.


-- 


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

[Bug c++/34935] [4.3 regression] ICE with attribute may_alias

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-23 10:46 ---
Confirmed.  They should not have the same canonical type.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-checking, wrong-code
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 10:46:20
   date||


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

[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-01-23 10:47 ---
Works for me on the trunk, even with

Index: tree-stdarg.c
===
--- tree-stdarg.c   (revision 131756)
+++ tree-stdarg.c   (working copy)
@@ -98,7 +98,10 @@ reachable_at_most_once (basic_block va_a
{
  SET_BIT (visited, src->index);
  FOR_EACH_EDGE (e, ei, src->preds)
+ {
+   gcc_assert (sp < n_basic_blocks + 1);
stack[sp++] = e;
+ }
}
 }


-- 


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

[Bug c++/34936] ICE with double and attribute may_alias

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-23 10:50 ---
This is not a regression.  From write_builtin_type:

case REAL_TYPE:
  if (type == float_type_node
  || type == java_float_type_node)
write_char ('f');
  else if (type == double_type_node
   || type == java_double_type_node) 
write_char ('d');
  else if (type == long_double_type_node)
write_char ('e');
  else
gcc_unreachable ();
  break;

this is probably too simplistic and instead should try fancy stuff like
the integer case.

Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 10:50:51
   date||
Summary|[4.1/4.2/4.3 regression] ICE|ICE with double and
   |with double and attribute   |attribute may_alias
   |may_alias   |
   Target Milestone|4.1.3   |---


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

[Bug c++/34937] [4.1/4.2/4.3 regression] ICE with attribute weak

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-23 10:56 ---
Confirmed.  We mangle the function type and come along the CONST_DECL for b
which refers to the CONST_DECL of a.  Some recursion is missing somewhere
here.

But we should not mangle for this non-instantiated template anyway, which
happens if you remove the attribute.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to work||3.3.6
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 10:56:18
   date||


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

[Bug fortran/33432] g77 extension: Support for the .XOR. operator

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-01-23 10:56 
---
*** Bug 34933 has been marked as a duplicate of this bug. ***


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bdavis at gcc dot gnu dot
   ||org


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

[Bug fortran/34933] no .XOR. operator

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2008-01-23 10:56 
---
We chose not to implement it (I remember discussing it with Jerry and someone
else on IRC, and I think I asked for opinions on the mailing-list before
closing the bugreport as WONTFIX), because of the potential problems and the
extra cost. Of course, if someone comes up with a patch (including an
-fxo-is-neqv or similarly named option), things are different :)

*** This bug has been marked as a duplicate of 33432 ***


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/34938] ICE with function pointers and attribute noreturn

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-23 10:57 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 10:57:21
   date||


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

[Bug c++/34939] [4.1/4.2/4.3 regression] ICE with friend and attribute weak

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-23 10:58 ---
Confirmed.  Related to PR34937.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||34937
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 10:58:52
   date||


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

[Bug c++/34936] [4.1/4.2/4.3 regression] ICE with double and attribute may_alias

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-01-23 10:59 ---
This is actually a big can of worms.
may_alias causes a distinct type code to be created.
For mangling I've tried:
--- mangle.c.jj128  2007-10-08 10:44:57.0 +0200
+++ mangle.c2008-01-23 11:11:12.0 +0100
@@ -1,5 +1,5 @@
 /* Name mangling for the 3.0 C++ ABI.
-   Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005, 2007
+   Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005, 2007, 2008
Free Software Foundation, Inc.
Written by Alex Samuel <[EMAIL PROTECTED]>

@@ -1768,6 +1768,8 @@ write_CV_qualifiers_for_type (const tree
 static void
 write_builtin_type (tree type)
 {
+  tree name = NULL;
+
   switch (TREE_CODE (type))
 {
 case VOID_TYPE:
@@ -1781,7 +1783,9 @@ write_builtin_type (tree type)
 case INTEGER_TYPE:
   /* TYPE may still be wchar_t, since that isn't in
 integer_type_nodes.  */
-  if (type == wchar_type_node)
+  if (TYPE_NAME (type))
+   name = DECL_NAME (TYPE_NAME (type));
+  if (name && name == DECL_NAME (TYPE_NAME (wchar_type_node)))
write_char ('w');
   else if (TYPE_FOR_JAVA (type))
write_java_integer_type_codes (type);
@@ -1792,7 +1796,7 @@ write_builtin_type (tree type)
 it in the array of these nodes.  */
iagain:
  for (itk = 0; itk < itk_none; ++itk)
-   if (type == integer_types[itk])
+   if (name && name == DECL_NAME (TYPE_NAME (integer_types[itk])))
  {
/* Print the corresponding single-letter code.  */
write_char (integer_type_codes[itk]);
@@ -1837,13 +1841,15 @@ write_builtin_type (tree type)
   break;

 case REAL_TYPE:
-  if (type == float_type_node
- || type == java_float_type_node)
+  gcc_assert (TYPE_NAME (type));
+  name = DECL_NAME (TYPE_NAME (type));
+  if (name == DECL_NAME (TYPE_NAME (float_type_node))
+ || name == DECL_NAME (TYPE_NAME (java_float_type_node)))
write_char ('f');
-  else if (type == double_type_node
-  || type == java_double_type_node)
+  else if (name == DECL_NAME (TYPE_NAME (double_type_node))
+  || name == DECL_NAME (TYPE_NAME (java_double_type_node)))
write_char ('d');
-  else if (type == long_double_type_node)
+  else if (name == DECL_NAME (TYPE_NAME (long_double_type_node)))
write_char ('e');
   else
gcc_unreachable ();

i.e. compare type names rather than types, because for distinct type copies
TYPE_MAIN_VARIANT doesn't point us to the original builtin type.
But there are still issues, say on:
// PR c++/34936
// { dg-do compile }

typedef float f __attribute ((may_alias));
typedef double d __attribute ((may_alias));
typedef long double e __attribute ((may_alias));
typedef char c __attribute ((may_alias));
typedef unsigned char uc __attribute ((may_alias));
typedef signed char sc __attribute ((may_alias));
typedef short int s __attribute ((may_alias));
typedef unsigned int u __attribute ((may_alias));
typedef long int l __attribute ((may_alias));
typedef long long int ll __attribute ((may_alias));
typedef wchar_t w __attribute ((may_alias));
typedef bool b __attribute ((may_alias));

void foo1 (char, unsigned char, signed char, short int, unsigned int, long int,
long long int, wchar_t, bool)
{
}
void bar1 (c, uc, sc, s, u, l, ll, w, b)
{
}
void foo2 (float, double, long double)
{
}
void bar2 (f, d, e)
{
}
which IMHO should be mangled the same between foo and bar, after s/bar/foo/g
but e.g. sc is mangled differently from signed char and ll from long long int.
Here the problem is type hashing which disregards type names, so throws
typedef char __attribute__((may_alias)) into the same equivalence set as
typedef signed char __attribute__((may_alias)).

Or consider:
// PR c++/34936
// { dg-do compile }

typedef float f __attribute ((may_alias));
typedef double d __attribute ((may_alias));
typedef long double e __attribute ((may_alias));
typedef char c __attribute ((may_alias));
typedef unsigned char uc __attribute ((may_alias));
typedef signed char sc __attribute ((may_alias));
typedef short int s __attribute ((may_alias));
typedef unsigned int u __attribute ((may_alias));
typedef long int l __attribute ((may_alias));
typedef long long int ll __attribute ((may_alias));
typedef wchar_t w __attribute ((may_alias));
typedef bool b __attribute ((may_alias));

void foo1 (unsigned char, signed char, short int, unsigned int, long int, bool)
{
}
void foo1 (uc, sc, s, u, l, b)
{
}
which isn't rejected (as C++ treats them as overloads), but are mangled the
same,
so this fails to assemble.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE with double and |[4.1/4.2/4.3 regression] ICE
   |attribute may_alias |with double and at

[Bug c++/34936] ICE with double and attribute may_alias

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-01-23 11:01 ---
It is unclear whether this can be considered a regression or not.
In GCC 3.2 and earlier the may_alias attribute was ignored, so while it meant
something else, we weren't ICEing on it.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 regression] ICE|ICE with double and
   |with double and attribute   |attribute may_alias
   |may_alias   |
   Target Milestone|4.1.3   |---


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

[Bug fortran/34928] volatile does not accept a common block name

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 11:01:56
   date||


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

[Bug libgcj/31700] [JNI] -X options not recognised by JNI_CreateJavaVM

[debian-gcc at lists dot debian dot org]

--- Comment #4 from debian-gcc at lists dot debian dot org  2008-01-23 
11:07 ---
this patch is applied on the current trunk; the bug should be closed.

  Matthias


-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

 CC||debian-gcc at lists dot
   ||debian dot org


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

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2008-01-23 11:27 ---
It is not always a win.  A function called once on a cold path should not be
inlined for e.g. icache reasons.

For your test case however, CS1 should have been inlined.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 11:27:01
   date||


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

[Bug tree-optimization/34940] New: contained subroutines called only once are not inlined

[jv244 at cam dot ac dot uk]

contained subroutines called only once are not inlined, despite the fact that
it is always a win (independent of the size of the contained subroutine). It
'only requires' counting the number of calls to cs1 in the routine s1, if it is
1, it should be inlined, as there can not be other callers.

example that shows no inlining at -O3 with 
GNU Fortran (GCC) 4.3.0 20080121 (experimental) [trunk revision 131689]

SUBROUTINE S1(X)
  CALL CS1(X)
CONTAINS
  SUBROUTINE CS1(X)
 CALL RANDOM_NUMBER(X)
 WRITE(6,*) X
  END SUBROUTINE CS1
END SUBROUTINE S1


-- 
   Summary: contained subroutines called only once are not inlined
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug target/34571] [4.3 Regression] Segfault in alpha_expand_mov at -O3

[tbm at cyrius dot com]

--- Comment #8 from tbm at cyrius dot com  2008-01-23 12:11 ---
Rask, can you please submit the patch?


-- 


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

[Bug middle-end/31529] [4.3 Regression] ICE in cgraph_expand_function with IMA

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-12-15 17:23:07 |2008-01-23 13:09:46
   date||


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

[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++

[nickc at redhat dot com]

--- Comment #9 from nickc at redhat dot com  2008-01-23 13:13 ---
Created an attachment (id=15007)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15007&action=view)
Improve --help= output


-- 


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

[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++

[nickc at redhat dot com]

--- Comment #10 from nickc at redhat dot com  2008-01-23 13:13 ---
Subject: Re:  [4.3 Regression] gcc -v --help returns no options
 for C, C++

Hi Manuel,

> % gcc -v --help=c
> 
> returns the following for me
> 
> The following options are language-independent:
>   --help  Display this information
>   --help=  Display descriptions of a specific class of
>   options.   is one or more of optimizers,
>   target, warnings, undocumented, params
> 
> I think it should say "The following options are supported by the language C".

It should - that was a bug.

> My proposal would be:
> 
> 1) Change the current empty message to mention --help= as described
> above.
> 
> 2) List all options with --help -v, even if they are undocumented (abusing of
> -Wextra for this seems unjustified to me). I would further propose that if
> checking is enabled, then show the message "This switch lacks documentation",
> otherwise (for releases) just show the empty string "".
> 
> Can we agree on this?

We can and the uploaded patch implements this.  If you are happy with it I will 
submit it to the list for official approval.

Cheers
   Nick


-- 


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

[Bug target/28508] Assembler Error: operand out of range (145 not between -128 and 127) form m32r-target

[debian-gcc at lists dot debian dot org]

--- Comment #8 from debian-gcc at lists dot debian dot org  2008-01-23 
13:34 ---
please mark it as closed, if it is not a candidate for a backport.

  Matthias


-- 


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

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-01-23 13:54 ---
It's considered too big and it's not static.


-- 


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

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-01-23 13:55 ---
Considering cs1 with 52 insns
 to be inlined into s1
 Estimated growth after inlined into all callees is -13 insns.
 Estimated badness is 86, frequency 1.00.
 Not inlining into s1:--param large-stack-frame-growth limit reached.

the fortran IO param structure is blowing the stack limit ;)


-- 


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

[Bug middle-end/31529] [4.3 Regression] ICE in cgraph_expand_function with IMA

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-01-23 14:20 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/31529] [4.3 Regression] ICE in cgraph_expand_function with IMA

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-01-23 14:20 
---
Subject: Bug 31529

Author: rguenth
Date: Wed Jan 23 14:20:07 2008
New Revision: 131758

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131758
Log:
2008-01-23  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/31529
* cgraphunit.c (cgraph_reset_node): Always mark the node
not reachable if it is not queued already.

* gcc.dg/pr31529-1.c: New testcase.
* gcc.dg/pr31529-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr31529-1.c
trunk/gcc/testsuite/gcc.dg/pr31529-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #32 from rguenth at gcc dot gnu dot org  2008-01-23 14:24 
---
Patches pending for review:

http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00862.html
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00951.html


-- 


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

[Bug middle-end/8081] ICE with variably sized types and nested functions

[debian-gcc at lists dot debian dot org]

--- Comment #19 from debian-gcc at lists dot debian dot org  2008-01-23 
14:38 ---
$ gcc-4.3 --version
gcc-4.3 (Debian 4.3-20080116-1) 4.3.0 20080116 (experimental) [trunk revision
131577]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-4.3 -O2 -Wall -g foo.c
foo.c: In function 'main':
foo.c:5: warning: unused variable 'i'
foo.c:15: internal compiler error: in declare_return_variable, at
tree-inline.c:1791
Please submit a full bug report,
with preprocessed source if appropriate.


-- 


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

[Bug bootstrap/33396] add --enable-intermodule

[aldot at gcc dot gnu dot org]

--- Comment #7 from aldot at gcc dot gnu dot org  2008-01-23 14:41 ---
Created an attachment (id=15008)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15008&action=view)
libgcc patch #2

Updated patch


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #14190|0   |1
is obsolete||


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

[Bug c/34941] New: Option to warn on printf of ptrdiff_t without t size modifier

[debian-gcc at lists dot debian dot org]

[forwarded from http://bugs.debian.org/425623]

This code:

#include 
int main(int argc, char *argv[])
{
void *a, *b;
printf("%d\n", a - b);
return 0;
}

will generate this warning on a 64-bit platform:

temp.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has type
‘long int’

because a - b has type ptrdiff_t and sizeof(ptrdiff_t) == 8 on a 64-bit
platform.  However, on a 32-bit platform the code will generate no warning.  I
believe it should generate a warning like this on all platforms, if not by
default then with an appropriate option:

temp.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has type
‘ptrdiff_t’

In C99, such code can use %td; the t size modifier corresponds to the
ptrdiff_t type.  If the code does not want to count on c99, it could cast the
difference to a long and use %ld.


-- 
   Summary: Option to warn on printf of ptrdiff_t without t size
modifier
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug tree-optimization/26854] Inordinate compile times on large routines

[lucier at math dot purdue dot edu]

--- Comment #61 from lucier at math dot purdue dot edu  2008-01-23 15:03 
---
Subject: Re:  Inordinate compile times on large routines

Kenny:

Even after you backed out this latest patch the CPU usage was down  
(to 203 seconds from 280 seconds on my machine) and the maximum  
memory usage was down (to 7.3 GB from 10.2 GB).  That's a big  
improvement.

Brad


-- 


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

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

[joel at gcc dot gnu dot org]

--- Comment #60 from joel at gcc dot gnu dot org  2008-01-23 15:12 ---
I did a build of powerpc-rtems4.9 on the trunk and it built much more quickly. 
I haven't had a chance to run the ACATS yet to check run-time behavior.  Thanks
for all the effort for this one.


-- 


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

[Bug fortran/32760] [4.3 Regression] Error defining subroutine named PRINT

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org
 AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
   |org |dot org
 Status|REOPENED|NEW
   Priority|P3  |P4
Summary|Error defining subroutine   |[4.3 Regression] Error
   |named PRINT |defining subroutine named
   ||PRINT


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

[Bug c/34720] ICE in real_to_decimal, at real.c:1656

[tgall dot foo at gmail dot com]

--- Comment #4 from tgall dot foo at gmail dot com  2008-01-23 15:28 ---
Hi Ben,

Yesterday I picked this up again using the 0118 snapshot. Same failure. 

Yes this is being built inside of portage. No patches are being applied. (I've
disabled that)

Following the direction of Peter Bergner I've also modified the params to
configure to be more inline with what he says is being used for gcc testing.

These values are:

--prefix=/usr   
--bindir=/usr/powerpc64-unknown-linux-gnu/gcc-bin/4.3.0-alpha20080118   
   
--includedir=/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.3.0-alpha20080118/include
 
   
--datadir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.3.0-alpha20080118   
   
--mandir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.3.0-alpha20080118/man
 
   
--infodir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.3.0-alpha20080118/info
 
   
--with-gxx-include-dir=/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.3.0-alpha20080118/include/g++-v4
 
--host=powerpc64-unknown-linux-gnu 
--build=powerpc64-unknown-linux-gnu 
--disable-altivec 
--enable-nls 
--without-included-gettext  
--with-system-zlib  
--disable-checking  
--disable-werror
--enable-secureplt  
--disable-libunwind-exceptions 
--disable-multilib 
--disable-libmudflap 
--disable-libssp 
--disable-libgcj 
--enable-decimal-float=yes 
--with-cpu=default64 
--with-long-double-128 
--disable-alsa 
--with-gmp=/usr/lib 
--with-mpfr=/usr/lib 
--enable-languages=c,c++,treelang 
--enable-shared 
--enable-threads=posix 
--enable-__cxa_atexit 
--enable-clocale=gnu  

See how much further I get today looking into this.


-- 


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

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2008-01-23 15:45 ---
(In reply to comment #2)
> It's considered too big and it's not static.
> 

not sure if my C is good enough to reply, but CS1 is visible only from within
the subroutine S1. That's somewhat similar to (or stricter than) 'static' ?


-- 


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

[Bug middle-end/34921] Misalign stack variable referenced by nested function

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-01-23 15:47 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01062.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||01/msg01062.html


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

[Bug preprocessor/34692] [4.2/4.3 regression] Internal error with pragma in macro

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-01-23 15:59 ---
Testing a patch.


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2008-01-07 20:18:16 |2008-01-23 15:59:04
   date||


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

[Bug c++/34942] New: -frepo only works with C locale

[debian-gcc at lists dot debian dot org]

[forwarded from http://bugs.debian.org/426809]

seen with trunk 20080123

another possibility might be to unset the locale, or set it to C

  Matthias

The g++ -frepo option only works with C locale, not with es_UY for example.
A possible test case is:
template class C
{
public:
C();
};

template
C::C()
{
}

int
main(void)
{
C x;
return 0;
}

g++ -c -frepo a.C
g++ -frepo -o a a.o

If you set the locale to C, then it will compile, if you set the locale to a
non english one, it will fail.
I guess that collect2 binutils ld output parser doesn't recognise the
internationalized output (file gcc/tlink.c).
One possible solution is to internationalize the strings in
scan_linker_output() to match those internationalized in binutils ld.


-- 
   Summary: -frepo only works with C locale
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug c++/34935] [4.3 regression] ICE with attribute may_alias

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2008-01-23 16:20 ---
CCing the canonical type expert.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dgregor at gcc dot gnu dot
   ||org


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

[Bug c++/34937] [4.1/4.2/4.3 regression] ICE with attribute weak

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2008-01-23 16:30 ---
What would be the semantics of "weak" on a template member?  That is, how would
the weak reference be overridden?

What I'm looking for is an example of what GCC did with this declaration when
it was still accepted.

The question behind the question is: Should this be valid code? ;-)


-- 


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

[Bug fortran/32760] [4.3 Regression] Error defining subroutine named PRINT

[burnus at gcc dot gnu dot org]

--- Comment #21 from burnus at gcc dot gnu dot org  2008-01-23 16:36 ---
Another test case

module m
  public :: volatile
contains
  subroutine foo
volatile :: bar
  end subroutine foo
  subroutine volatile
  end subroutine volatile
end module


-- 


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

[Bug c++/34829] [4.3 Regression] placement new with primitive Java types rejected

[tromey at gcc dot gnu dot org]

--- Comment #9 from tromey at gcc dot gnu dot org  2008-01-23 16:43 ---
Reopened while I look at the new problem


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug debug/34895] [4.1/4.2/4.3 Regression] ICE in force_type_die, at dwarf2out.c:12923

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2008-01-23 16:45 ---
Subject: Bug 34895

Author: matz
Date: Wed Jan 23 16:44:27 2008
New Revision: 131761

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131761
Log:
PR debug/34895
* dwarf2out.c (force_type_die): Use modified_type_die instead of
gen_type_die.

* g++.dg/debug/pr34895.cc: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr34895.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/34943] New: -fno-strict-overflow fails to prevent use of signed overflow

[ian at airs dot com]

Consider this C test case:

const char *
f(long v)
{
  if (v < 0)
v = - v;
  if (v > 0x7fff)
return "negative";
  else
return "positive";
}

When this is compiled with -O2, it always returns "positive".  This is fine
because when v == LONG_MIN, negating it is undefined signed overflow.  However,
the same is true when this is compiled with -O2 -fno-strict-overflow, which is
not fine.  With -fno-strict-overflow, we can not assume that negating a signed
value yields a nonnegative number.

This bug is neither serious nor a regression, so I'm recording it here in order
to fix it for gcc 4.4.


-- 
   Summary: -fno-strict-overflow fails to prevent use of signed
overflow
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug tree-optimization/34943] -fno-strict-overflow fails to prevent use of signed overflow

[ian at airs dot com]

--- Comment #1 from ian at airs dot com  2008-01-23 16:46 ---
Created an attachment (id=15009)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15009&action=view)
Proposed patch

I believe that this is the correct patch for this bug.  This should be tested
and committed for gcc 4.4.


-- 


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

[Bug tree-optimization/34943] -fno-strict-overflow fails to prevent use of signed overflow

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-01-23 16:48 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
OtherBugsDependingO||33702
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 16:48:42
   date||


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

[Bug c++/34829] [4.3 Regression] placement new with primitive Java types rejected

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2008-01-23 16:49 
---
(In reply to comment #9)
> Reopened while I look at the new problem
> 

Jakub fixed it last night with:

Author: jakub
Date: Wed Jan 23 08:33:22 2008
New Revision: 131756

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131756
Log:
PR c++/34829
* g++.dg/ext/pr34829.C (operator new): Use size_t instead of
unsigned int for the first argument.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug debug/34895] [4.1/4.2/4.3 Regression] ICE in force_type_die, at dwarf2out.c:12923

[matz at gcc dot gnu dot org]

--- Comment #6 from matz at gcc dot gnu dot org  2008-01-23 16:54 ---
Fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)

[Ralf dot Wildenhues at gmx dot de]

--- Comment #6 from Ralf dot Wildenhues at gmx dot de  2008-01-23 17:12 
---
With the patch I get this:

xgcc -m32 -O1 -c send_tiny.i

send_tiny.i: In function ‘sendto_realops_lev’:
send_tiny.i:77: warning: incompatible implicit declaration of built-in function
‘strlen’
send_tiny.i:25: internal compiler error: in reachable_at_most_once, at
tree-stdarg.c:102
Please submit a full bug report,

Note that I cannot reproduce the failure without -m32 (on x86_64).


-- 


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

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

[jv244 at cam dot ac dot uk]

--- Comment #5 from jv244 at cam dot ac dot uk  2008-01-23 17:22 ---
just a note, ifort does inline the function cs1


-- 


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

[Bug bootstrap/34944] New: Tree check: at cp/typecheck.c

[aj at gcc dot gnu dot org]

On both Linux/x86-64 and Linux/ppc I get an tree check error bootstrapping
current GCC 4.2 SVN:

/abuild/aj/gcc/powerpc64-suse-linux-gnu/libstdc++-v3/include/bits/cpp_type_traits.h:3
71: internal compiler error: tree check: expected class ‘type’, have
‘declaration’ (n
amespace_decl) in complete_type, at cp/typeck.c:105
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [powerpc64-suse-linux-gnu/bits/stdc++.h.gch/O0g.gch] Error 1

Jason, this looks like your commit (did not verify - it is the only change in
gcc/cp since my last bootstrap):
2008-01-21  Jason Merrill  <[EMAIL PROTECTED]>

PR c++/33959
* pt.c (tsubst_aggr_type): Make sure our context is complete.


-- 
   Summary: Tree check: at cp/typecheck.c
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aj at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/34945] New: LBOUND fails for array with KIND(complex) used in zero-sized dimension

[dick dot hendrickson at gmail dot com]

With compiler
gcc version 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)

I get the following error message


>gfortran vf0009.f
vf0009.f: In function 'vf0009':
vf0009.f:11: error: size of variable 'test_array' is too large

If I replace the second line in the declaration of test_array with
any of
 $   KIND(IDA1):5,
 $   KIND(YDA):9,
 $   8:5,
the program compiles without an error message.
The LBOUND function is needed to trigger the error message

Dick Hendrickson

  SUBROUTINE VF0009(IDA1,IDA2,YDA,HDA)
  INTEGER(4) IDA1(4)
  INTEGER(4) IDA2(4)
  COMPLEX(8) YDA(2)
  INTEGER(4) HDA(3)
!  I N I T I A L I Z A T I O N  S E C T I O N
  COMPLEX(KIND=4) :: TEST_ARRAY
 $(  4:5,
 $   KIND(YDA):5,
 $   4:5,
 $   4:5  )
!  T E S T  S T A T E M E N T S
   IDA1(1:4) = LBOUND(TEST_ARRAY)
  END SUBROUTINE


-- 
   Summary: LBOUND fails for array with KIND(complex) used in zero-
sized dimension
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug rtl-optimization/34902] Wrong code on -O3

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2008-01-23 17:57 ---
(In reply to comment #7)
> This is bison 2.0.
> The latest version is 2.3. If haven't found anything in the ChangeLog which
> sounds like there was a bug fix in this area.
> 

You should really try bison 2.3 just in case and/or report the issue to the
bison developers. Meanwhile, the workaround is to use -fno-strict-aliasing.

There is little else we can do. Thanks for the report anyway.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/34944] Tree check: at cp/typecheck.c

[aj at gcc dot gnu dot org]

--- Comment #1 from aj at gcc dot gnu dot org  2008-01-23 17:30 ---
configure line is:
# /cvs/gcc-svn/branches/gcc-4_2-branch/configure   --prefix=/opt/gcc/4.2-devel
--enable-checking=yes,rtl --enable-threads=posix --enable-clocale=gnu
--enable-ssp --disable-libssp --enable-libstdcxx-allocator=new
--enable-__cxa_atexit --enable-shared --with-system-zlib x86_64-suse-linux-gnu
--enable-languages=c,ada,c++,fortran,java,objc,treelang


-- 


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

[Bug libgcj/31700] [JNI] -X options not recognised by JNI_CreateJavaVM

[tromey at gcc dot gnu dot org]

--- Comment #5 from tromey at gcc dot gnu dot org  2008-01-23 17:59 ---
Fix checked in a while ago.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug c/34389] -Wconversion produces wrong warning

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-01-23 18:00 ---
I don't think this will be fixed before GCC 4.3 is released, which is a shame.
But if anyone has a suggestion on how to fix this, I will try to submit a patch
ASAP.


-- 


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

[Bug other/31955] [4.2/4.3 regression] gcc_release does not generate HTML files from install manual

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-01-23 18:13 ---
I think this is a regression since it used to work in GCC 4.0.0 and 4.1.0.

>From the duplicated report:

gcc_release is supposed to generate html files in HTML/ from
gcc/doc/install.texi for release candidates and final releases. This doesn't
happen since GCC 4.2.0


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.2.0 4.2.2 4.3.0
  Known to work||4.0.0 4.1.0
   Last reconfirmed|-00-00 00:00:00 |2008-01-23 18:13:15
   date||
Summary|gcc-4.2.0.tar.bz2 is missing|[4.2/4.3 regression]
   |INSTALL html files  |gcc_release does not
   ||generate HTML files from
   ||install manual


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

[Bug other/31955] [4.2/4.3 regression] gcc_release does not generate HTML files from install manual

[manu at gcc dot gnu dot org]

-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.3


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

[Bug fortran/34784] [4.2/4.3 Regression] implicit character(s) hides type of selected_int_kind intrinsic

[dick dot hendrickson at gmail dot com]

--- Comment #8 from dick dot hendrickson at gmail dot com  2008-01-23 18:31 
---
Subject: Re:  [4.2/4.3 Regression] implicit character(s) hides type of
selected_int_kind intrinsic

I have another example of what might be the same problem, although the
symptoms are
a little different.  the error message is

C:gfortran v_ice.f
v_ice.f:21.72:

  END MODULE TESTS
   1
Internal Error at (1):
gfc_convert_constant(): Unexpected type

If I use either
  IMPLICIT CHARACTER (D)
  IMPLICIT CHARACTER (E)
things compile, although I'd have expected a problem with either
DIGITS or EPSILON.

A procedure question.  Is this the One True Way to add additional
comments or tests
about a bug report?  Or is there a better way?

Dick Hendrickson


  MODULE TESTS
  IMPLICIT CHARACTER (M)
  CONTAINS
  SUBROUTINE VF0010(IDA1,IDA2,RDA,QDA)
  INTEGER(4) IDA1(5)
  INTEGER(4) IDA2(5)
  REAL(4) RLA(5)
  REAL(4) RDA(5)
  REAL(8) QDA(5)
  REAL(8) DCA(5)
!  I N I T I A L I Z A T I O N  S E C T I O N
  INTEGER(KIND=4) :: TEST_ARRAY
 $(SUM((/DIGITS(1),DIGITS(RLA(2)),DIGITS(DCA),DIGITS(QDA)/))/10,
 $  MIN(6_4,
 $   INT((EPSILON(RLA)+EPSILON(ABS(QDA))+EPSILON(DCA))*1.E6)),
 $  INT(MIN(RDA(1),HUGE(RLA)/10)+MIN(QDA(1),HUGE(QDA)/10)
 $  +MIN(1,HUGE(IDA2))),
 $  MIN(6,MAXEXPONENT(1.0_8)+MAXEXPONENT(RLA)+
 $  MAXEXPONENT(QDA)))
  END SUBROUTINE
  END MODULE TESTS


On 20 Jan 2008 16:59:09 -, pault at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #7 from pault at gcc dot gnu dot org  2008-01-20 16:59 ---
> Subject: Bug 34784
>
> Author: pault
> Date: Sun Jan 20 16:58:15 2008
> New Revision: 131679
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131679
> Log:
> 2008-01-20  Paul Thomas  <[EMAIL PROTECTED]>
>
> PR fortran/34861
> * resolve.c (resolve_entries): Do not do an array bounds check
> if the result symbols are the same.
>
> PR fortran/34854
> * module.c (read_module) : Hide the symtree of the previous
> version of the symbol if this symbol is renamed.
>
> 2008-01-20  Paul Thomas  <[EMAIL PROTECTED]>
>
> PR fortran/34784
> * gfortran.dg/mapping_2.f90: Correct ubound expression for h4.
>
> PR fortran/34861
> * gfortran.dg/entry_array_specs_3.f90: New test.
>
> PR fortran/34854
> * gfortran.dg/use_rename_1.f90: New test.
>
> Added:
> trunk/gcc/testsuite/gfortran.dg/entry_array_specs_3.f90
> trunk/gcc/testsuite/gfortran.dg/use_rename_1.f90
> Modified:
> trunk/gcc/fortran/ChangeLog
> trunk/gcc/fortran/module.c
> trunk/gcc/fortran/resolve.c
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gfortran.dg/mapping_2.f90
>
>
> --
>
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34784
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug c++/28475] [4.1/4.2/4.3 Regression] Internal error: Segmentation fault (program cc1plus)

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-01-23 18:34 ---
Regressions should have a target milestone


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug target/31070] [4.1/4.2/4.3] ICE in function_arg_slotno

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-01-23 18:35 ---
Regressions should have a target milestone


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug other/31405] [4.3] fixincludes needed for wchar from glibc 2.3.6

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-01-23 18:36 ---
Regressions should have a target milestone.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug target/34916] [4.3 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2008-01-23 18:37 ---
Regressions should have a target milestone


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

--- Comment #145 from jv244 at cam dot ac dot uk  2008-01-23 19:02 ---
current gfortran trunk seems to fail on CVS sources of CP2K with:

/data03/vondele/clean/cp2k/src/../src/realspace_grid_types.F: In function
‘rs_grid_create’:
/data03/vondele/clean/cp2k/src/../src/realspace_grid_types.F:297: internal
compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug fortran/34946] New: internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592

[jv244 at cam dot ac dot uk]

GNU Fortran (GCC) 4.3.0 20080121 (experimental) [trunk revision 131689] yields

> gfortran -ffree-form bug.F
bug.F: In function ‘rs_grid_create’:
bug.F:147: internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:592
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: internal compiler error: in gfc_trans_create_temp_array,
at fortran/trans-array.c:592
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug fortran/34946] internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-01-23 19:25 ---
Created an attachment (id=15010)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15010&action=view)
testcase


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

--- Comment #146 from jv244 at cam dot ac dot uk  2008-01-23 19:30 ---
(In reply to comment #145)
> current gfortran trunk seems to fail on CVS sources of CP2K with:

PR34946


-- 


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

[Bug c/34947] New: Clobbered float registers not popped

[vincent dot riviere at freesbee dot fr]

This problem is about functions that push some float registers at the
beginning, but forget to pop them at the end. The stack pointer is not adjusted
as expected, so the function return to an invalid address.

It appears when the following is true:
- the file is compiled with -m68020-60 -O1 -fomit-frame-pointer
- the function uses floats
- the function is complicated enough to have some float registers backed up on
the stack
- there is an early return in the function

The problem appears in the following test case:
$ cat bug.c
volatile float g1;
float g2;

void f(void)
{
float i;

if (g2 >= 0)
return;

for (i = 0; i < 10; ++i)
g1 = g2 + i;
}

$ gcc -S bug.c -o - -m68020-60 -O2 -fomit-frame-pointer
...
.globl  f
.type   f, @function
f:
fmovm #0x4,-(%sp)
fmove.s g2,%fp2
fbnge .L9
.L5:
rts
.L9:
...

We can see that some float registers are backuped at the beginning. Then (g2 >=
0) is checked. If it is the case, the function returns with a simple rts,
without restoring the registers, to an invalid address.

This happens in gcc 4.2.2 and gcc-4.2-20080116


-- 
   Summary: Clobbered float registers not popped
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent dot riviere at freesbee dot fr
GCC target triplet: m68k-linux


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

[Bug c++/28475] [4.1/4.2/4.3 Regression] Internal error: Segmentation fault (program cc1plus)

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-01-23 20:26 ---


*** This bug has been marked as a duplicate of 34824 ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/34824] [4.1/4.2/4.3 Regression] ICE with explicit copy constructor

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-01-23 20:26 ---
*** Bug 28475 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jkherciueh at gmx dot net


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

[Bug c++/34944] Tree check: at cp/typecheck.c

[aj at gcc dot gnu dot org]

--- Comment #2 from aj at gcc dot gnu dot org  2008-01-23 20:43 ---
Note: This appears with *both* x86_64-unknown-linux-gnu and
powerpc64-suse-linux-gnu.


-- 


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

[Bug target/34916] [4.3 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug middle-end/32395] false positive warning about use of uninitialized variable.

[pluto at agmk dot net]

--- Comment #14 from pluto at agmk dot net  2008-01-23 21:01 ---
> :-( I cannot compile this testcase

please try the latest testcase.


-- 


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

[Bug c++/34948] New: += operator on pointers with a function call having side effects on the right hand side

[daniel dot fredouille at gmail dot com]

The problem is shown by the following code: basically, when using the +=
operator on a pointer which is the member of a class as in a line like below:  
 a.myptr += a.SideEffect();
if the a.myptr pointer is modified by the a.SideEffect() call, the += still
takes into account only the old pointer value to compute the += result. I was
expecting it to use the value modified by the a.SideEffect() call. See code
below to reproduce.

The behaviour I expected can be obtained if, in the code below, the class A is
removed and all variables/functions are changed to be global
variables/function.

Compiled under RHEL5, kernel 2.6.20-hardened-r2
gcc --version gives:
gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)

-- sample code ---
#include 

class A{
public:
  int SideEffect(void){
// prints that we are at position 0 in the buffer (correct)
printf("position in buffer when entering SideEffect: %d\n",
myptr-buffer);
myptr += 2;
// prints that we are at position 2 in the buffer (correct)
printf("position in buffer when leaving SideEffect: %d\n",
myptr-buffer);
return 10;
  }
  char buffer[256];
  char * myptr;
};


int main(void){
  A a;
  a.myptr = a.buffer;
  a.myptr += a.SideEffect();
  // Likely bug: prints position 10, I was expecting 12
  printf("position in buffer after calling SideEffect and += operator, expected
value is 12: %d\n", a.myptr-a.buffer);
  return 0;
}


-- 
   Summary: += operator on pointers with a function call having side
effects on the right hand side
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daniel dot fredouille at gmail dot com


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

[Bug libgomp/28482] Cannot use libgomp in shared library

[peter dot waller at gmail dot com]

--- Comment #8 from peter dot waller at gmail dot com  2008-01-23 21:15 
---
Still no sign of 4.2 fix?


-- 

peter dot waller at gmail dot com changed:

   What|Removed |Added

 CC||peter dot waller at gmail
   ||dot com


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

[Bug c++/34944] Tree check: at cp/typecheck.c

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-01-23 21:24 ---
Subject: Bug 34944

Author: jason
Date: Wed Jan 23 21:23:32 2008
New Revision: 131765

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131765
Log:
PR bootstrap/34944

Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog


-- 


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

[Bug c++/34944] Tree check: at cp/typecheck.c

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2008-01-23 21:24 ---
That's bizarre, I'm not sure how I managed to check in a different version of
that patch on 4.2 than the one I tested.  Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/34720] ICE in real_to_decimal, at real.c:1656

[tgall dot foo at gmail dot com]

--- Comment #5 from tgall dot foo at gmail dot com  2008-01-23 21:31 ---
so the call path involved here is from gcc/c-cppbuiltin.c 
builtin_define_with_hex_fp_value

which is calling real_to_decimal and its in that function we're running into
problems.

The string rep of the real is : 0x0.ffp128 aka  __FLT_MAX_10_EXP__

I am able to do a real_to_hexadecimal successfully and get : 0x0.ffp+128

Inside of real_to_decimal once we get down to digit=rtd_divmod(&r, &pten) we're
in obvious trouble as digit comes back with a value of:

7378697629483820646  which in hex comes out to be all 6's or a pattern of
repeating nibbles of "0110". 

This is making my head hurt.




-- 


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

[Bug tree-optimization/33826] [4.1/4.2 Regression] GCC generates wrong code for infinitely recursive functions

[rguenth at gcc dot gnu dot org]

--- Comment #20 from rguenth at gcc dot gnu dot org  2008-01-23 21:35 
---
Not fixed on the branches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Known to work||4.3.0
 Resolution|FIXED   |
Summary|[4.1/4.2/4.3 Regression] GCC|[4.1/4.2 Regression] GCC
   |generates wrong code for|generates wrong code for
   |infinitely recursive|infinitely recursive
   |functions   |functions


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

[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-01-23 21:44 ---
I checked both a 32bit compiler and x86_64 with -m32 (with the reduced
testcase).


-- 


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

[Bug fortran/34946] [4.3 Regression] internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-01-23 21:46 ---
Fortran is not release-critical.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.3.0


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

[Bug c++/34948] += operator on pointers with a function call having side effects on the right hand side

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-23 21:49 ---
There's no sequence point, the order of evaluation is undefined.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/34325] Wrong error message for syntax error

[terry at chem dot gu dot se]

--- Comment #8 from terry at chem dot gu dot se  2008-01-23 21:54 ---
Rather than open a new bug, I'll tack onto this one as it's pretty much the
same bug in a different context.

The latest gfortran does indeed give a sensible error for the test case above.

However, if we put something like:

real(kind=8),dimension(1))::r2

into that code, we still get strange and bizarre errors:

aa.f90:4.13:

real(kind=8),dimension(1))::r2
1
Error: Invalid character in name at (1)

This is with 4.3.0 20080118.


-- 

terry at chem dot gu dot se changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2008-01-23 22:21 
---
Run is fine, invalid.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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