[Bug fortran/29635] debug info of modules

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-08-18 08:11 ---
To expand on the duplicate DIE issue in C++, say:
namespace N
{
  int i;
}
int foo ()
{
  using N::i;
  return i;
}
emits:
.uleb128 0x3# (DIE (0x55) DW_TAG_imported_declaration)
.byte   0x1 # DW_AT_decl_file (mno2.C)
.byte   0x7 # DW_AT_decl_line
.long   0x6d# DW_AT_import
in foo (correct) and then:
.uleb128 0x5# (DIE (0x64) DW_TAG_namespace)
.ascii "N\0"# DW_AT_name
.byte   0x1 # DW_AT_decl_file (mno2.C)
.byte   0x2 # DW_AT_decl_line
.long   0x8c# DW_AT_sibling
.uleb128 0x6# (DIE (0x6d) DW_TAG_variable)
.ascii "i\0"# DW_AT_name
.byte   0x1 # DW_AT_decl_file (mno2.C)
.byte   0x3 # DW_AT_decl_line
.long   .LASF0  # DW_AT_MIPS_linkage_name: "_ZN1N1iE"
.long   0x5d# DW_AT_type
.byte   0x1 # DW_AT_external
.byte   0x1 # DW_AT_declaration
.uleb128 0x6# (DIE (0x7c) DW_TAG_variable)
.ascii "i\0"# DW_AT_name
.byte   0x1 # DW_AT_decl_file (mno2.C)
.byte   0x3 # DW_AT_decl_line
.long   .LASF0  # DW_AT_MIPS_linkage_name: "_ZN1N1iE"
.long   0x5d# DW_AT_type
.byte   0x1 # DW_AT_external
.byte   0x1 # DW_AT_declaration
.byte   0x0 # end of children of DIE 0x64
.uleb128 0x7# (DIE (0x8c) DW_TAG_variable)
.long   0x7c# DW_AT_specification
.byte   0x9 # DW_AT_location
.byte   0x3 # DW_OP_addr
.quad   _ZN1N1iE
.byte   0x0 # end of children of DIE 0xb
Note not just 2, but 3, 2 DW_AT_declaration inside and one DW_AT_specification
DIE outside of the namespace.  If extern int i; is used instead, then the
DW_AT_specification is missing.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot
   ||org, drow at gcc dot gnu dot
   ||org


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

[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff

[jan dot kratochvil at redhat dot com]

--- Comment #3 from jan dot kratochvil at redhat dot com  2008-08-18 08:24 
---
The fix was posted at:
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01857.html


-- 


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

[Bug fortran/29635] debug info of modules

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-08-18 08:43 ---
Looking at the original namespace support in dwarf2out patches I found the
declaration in the namespace and specification in CU is being done for
compatibility with (at that time) existing debuggers.  I'm not sure if we need
to do the same for Fortran (maybe not, what does gdb do with DW_TAG_module?) or
if we couldn't drop compatibility hacks for more than 5 years old dwarf2
debuggers by now even for C++.  The duplicate declaration DIEs are still
unexpected.


-- 


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

[Bug ada/15808] Illegal program not detected, RM 3.9.3(10)

[sam at gcc dot gnu dot org]

--- Comment #3 from sam at gcc dot gnu dot org  2008-08-18 09:00 ---
Subject: Bug 15808

Author: sam
Date: Mon Aug 18 08:58:58 2008
New Revision: 139190

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139190
Log:
gcc/ada/
PR ada/15808
* sem_ch6.adb (Check_Private_Overriding): Check for generic packages
as well.

gcc/testsuite/
PR ada/15808
* gnat.dg/specs/abstract_private.ads: New.

Added:
trunk/gcc/testsuite/gnat.dg/specs/abstract_private.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/sem_ch6.adb
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug ada/15808] Illegal program not detected, RM 3.9.3(10)

[sam at gcc dot gnu dot org]

--- Comment #4 from sam at gcc dot gnu dot org  2008-08-18 09:10 ---
This has been fixed in SVN trunk.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug ada/30827] [Ada] GNAT.compiler_version problem for official releases?

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-08-18 09:10 ---
Subject: Bug 30827

Author: sam
Date: Mon Aug 18 09:09:24 2008
New Revision: 139192

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139192
Log:
2008-08-18  Samuel Tardieu  <[EMAIL PROTECTED]>
Robert Dewar  <[EMAIL PROTECTED]>
gcc/ada/
PR ada/30827
* bindgen.adb (Gen_Output_File_Ada): Zero-terminate the
version string.
Move comment in the right place.
* g-comver.adb (Version): Look for a zero-termination in
addition to a closing parenthesis.

2008-08-18  Robert Dewar  <[EMAIL PROTECTED]>
gcc/testsuite/
PR ada/30827
* gnat.dg/test_version.adb: New.

Added:
trunk/gcc/testsuite/gnat.dg/test_version.adb
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/bindgen.adb
trunk/gcc/ada/g-comver.adb
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug ada/30827] [Ada] GNAT.compiler_version problem for official releases?

[sam at gcc dot gnu dot org]

--- Comment #3 from sam at gcc dot gnu dot org  2008-08-18 09:10 ---
Fixed in SVN trunk.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug ada/37110] Assert_Failure at atree.adb:886 caused by legal prefixed notation

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-08-18 09:49 ---
This may be a duplicate of PR 34598.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at gcc dot gnu dot org


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

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[manu at gcc dot gnu dot org]

--- Comment #15 from manu at gcc dot gnu dot org  2008-08-18 11:31 ---
Subject: Bug 7263

Author: manu
Date: Mon Aug 18 11:30:32 2008
New Revision: 139194

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139194
Log:
2008-08-18  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR cpp/7263
* c-opts.c (cpp_opts): Remove static.
* c-parser.c (cpp_opts): Declare it extern.
(disable_extension_diagnostics): Handle cpp options.
(enable_extension_diagnostics): Likewise.
testsuite/
* gcc.dg/cpp/pr7263-2.c: New.
* gcc.dg/cpp/pr7263-2.h: New.
* gcc.dg/cpp/pr7263-3.c: New.
* gcc.dg/cpp/pr7263-3.h: New.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/pr7263-2.c
trunk/gcc/testsuite/gcc.dg/cpp/pr7263-2.h
trunk/gcc/testsuite/gcc.dg/cpp/pr7263-3.c
trunk/gcc/testsuite/gcc.dg/cpp/pr7263-3.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-opts.c
trunk/gcc/c-parser.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37146] New: ICE - Compiler segfaults

[springl-gcc at bfw-online dot de]

g++ from snapshot gcc-4.4-20080815.tar.bz2 gives

v.cc: In member function 'kostenbezug_e
verteilung_c::bezug_ausrechnen(kostenbezug_e) const':
v.cc:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

on this program:
-
enum kostenbezug_e
{ kostenbezug_keiner = 0,
  kostenbezug_einheitlich = 'E',
};

struct verteilung_c
{ kostenbezug_e bezug: 8;
  enum kostenbezug_e bezug_ausrechnen (kostenbezug_e) const;
};

kostenbezug_e
verteilung_c::bezug_ausrechnen (kostenbezug_e b) const
{ return bezug && bezug != kostenbezug_einheitlich? bezug: b;
}
-
when called as
  g++ -O2 -c -o v.o v.cc

This is running on Linux version 2.6.26.2, glibc 2.6.1.
gcc was configured using:
  configure --prefix=/scratch/gcc/4.4-2008-08-08 --enable-shared \
--enable-languages=all --with-sysroot=/usr/i686-pc-linux-gnulibc2


-- 
   Summary: ICE - Compiler segfaults
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: springl-gcc at bfw-online dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-18 12:16 ---
confirmed.

#0  0x00bca7e9 in bitmap_insert_into_set_1 (set=0x0, expr=0x1621e58, 
allow_constants=0 '\0')
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:640
#1  0x00bca82d in bitmap_insert_into_set (set=0x0, expr=0x1621e58)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:650
#2  0x00bcb036 in bitmap_value_replace_in_set (set=0x0, expr=0x1621e58)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:846
#3  0x00bd1162 in create_expression_by_pieces (block=0x77597b40, 
expr=0x1621d18, stmts=0x7fffd7d8, domstmt=0x77eb7f50, 
type=0x7758f540)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2820
#4  0x00bd0c5f in find_or_generate_expression (block=0x77597b40, 
expr=0x1621dd8, stmts=0x7fffd7d8, domstmt=0x77eb7f50)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2682
#5  0x00bd0f78 in create_expression_by_pieces (block=0x77597b40, 
expr=0x1621e38, stmts=0x7fffd7d8, domstmt=0x77eb7f50, type=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2777
#6  0x00bd4409 in do_SCCVN_insertion (stmt=0x77eb7f50, 
ssa_vn=0x7759bb60)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:3761
#7  0x00bd4816 in eliminate ()
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:3853
#8  0x00bd5c0a in execute_pre (do_fre=1 '\001')

3848  tree val = VN_INFO (lhs)->valnum;
3849  if (val != VN_TOP
3850  && TREE_CODE (val) == SSA_NAME
3851  && VN_INFO (val)->needs_insertion
3852  && can_PRE_operation (vn_get_expr_for (val)))
3853sprime = do_SCCVN_insertion (stmt, val);
3854}
3855  if (sprime
3856  && sprime != lhs
3857  && (rhs == NULL_TREE
(gdb) call VN_INFO (val)
$1 = (struct vn_ssa_aux *) 0x1604aa0
(gdb) print *$1
$2 = {valnum = 0x7759bb60, expr = 0x77599f00, value_id = 10, 
  dfsnum = 0, low = 0, visited = 0, on_sccstack = 0, has_constants = 0, 
  use_processed = 0, needs_insertion = 1}
(gdb) call debug_generic_expr (0x77599f00)
VIEW_CONVERT_EXPR(b_8)

b_8 is an enum of precision 32 (and thus not folded to a NOP_EXPR by fold).

But it looks like we miss a conversion and thus have an IL with invalid types
here from the start.

((const struct verteilung_c *) this)->bezug != 0 && ((const struct verteilung_c
*) this)->bezug != 69 ? ((const struct verteilung_c *) this)->bezug : b

  unit size

...
arg 2 
...

with

  constant 32>


which leads to invalid types after gimplification already.  4.3 is not
affected by the ICE.

The type-verifier is basically disabled on the trunk ... :/


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, wrong-
   ||code
  Known to work||4.3.2
   Last reconfirmed|-00-00 00:00:00 |2008-08-18 12:16:21
   date||
Summary|ICE - Compiler segfaults|[4.4 Regression] Invalid
   ||types with COND_EXPR
   Target Milestone|--- |4.4.0


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

[Bug libstdc++/37147] New: [4.4 Regression]: 20_util/ratio/comparisons/comp2.cc et al

[hp at gcc dot gnu dot org]

Last known good revision:139006
Known to fail with revision: 139008 .. 139189.

For the changes in this range I only see a few libstdc++ configury changes that
moved tests and generalized them in a seemingly correct manner without typos or
obvious ordering issues, but perhaps there's non-obvious ordering issues.

Either way, I now see (the FAIL lines are regressions):
...
Running /x/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
FAIL: 20_util/ratio/comparisons/comp2.cc (test for excess errors)
WARNING: 20_util/ratio/comparisons/comp2.cc compilation failed to produce
executable
...
FAIL: 20_util/ratio/operations/ops2.cc (test for excess errors)
WARNING: 20_util/ratio/operations/ops2.cc compilation failed to produce
executable
FAIL: 20_util/ratio/operations/ops3.cc (test for excess errors)
WARNING: 20_util/ratio/operations/ops3.cc compilation failed to produce
executable
...
FAIL: 27_io/basic_ostream/inserters_other/char/error_code.cc (test for excess
errors)
WARNING: 27_io/basic_ostream/inserters_other/char/error_code.cc compilation
failed to produce executable

with this in the .log:
/x/gcc/libstdc++-v3/testsuite/20_util/ratio/comparisons/comp2.cc:25: error:
'INTMAX_MAX' was not declared in this scope
(various errors followed)
and similar for the other tests.

Not sure at a glance what caused this, but maybe it's obvious to the author
(CCed).
N.B.: cross-target, newlib.


-- 
   Summary: [4.4 Regression]: 20_util/ratio/comparisons/comp2.cc et
al
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-18 12:16 ---
Fixing it yields

t.i: In member function 'kostenbezug_e
verteilung_c::bezug_ausrechnen(kostenbezug_e) const':
t.i:12: error: non-trivial conversion at assignment
iftmp.0
this->bezug
iftmp.0 = this->bezug;

t.i:12: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug fortran/29635] debug info of modules

[drow at gcc dot gnu dot org]

--- Comment #9 from drow at gcc dot gnu dot org  2008-08-18 12:38 ---
Interesting, I didn't know this was for the benefit of some debugger.  I don't
think GDB has needed it in several years.  If things work with GDB 6.8 and
without these DIEs, I think it's safe to combine the declaration and the
reference to it.

(It's not right to call a DIE with DW_AT_specification a specification; the
target of the attribute is the specification.)


-- 


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

[Bug tree-optimization/28632] VRP should understand bitwise OR and AND

[vda dot linux at googlemail dot com]

--- Comment #12 from vda dot linux at googlemail dot com  2008-08-18 13:02 
---
Bootstrap with -O2 on current svn fails. Bootstrap with -Os works.
Bootstrap with -O2 on 4.3.1 works.

Instrumented patch emits C code which can be used to test for incorrect VRP
predictions.

I ran such tests and found no such incorrect predictions. Either patch is buggy
in some subtle way or it exposes a latent bug elsewhere :(


-- 


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

[Bug libstdc++/37147] [4.4 Regression]: 20_util/ratio/comparisons/comp2.cc et al

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-08-18 13:03 
---
Therefore, are *all* the errors cause by INTMAX_MAX not being defined? That may
have only to do with the macros on top of bits/postypes.h. Thus you should
check what happens with _GLIBCXX_HAVE_INT64_T, _GLIBCXX_HAVE_INT64_T_LONG, and
_GLIBCXX_HAVE_INT64_T_LONG_LONG.

Something you should also immediately check is whether those tests actually
were run before the changes and not skipped, because the problems are at the
interaction of the dg-require-cstdint and the actual availability of some
specific stdint.h facilities, the macros, which unfortunately in C++ are not
always available together with the rest, but only when __STDC_LIMIT_MACROS is
defined before including the first time ...

In any case, please attach pre-processed comp2.cc.


-- 


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

[Bug libstdc++/37147] [4.4 Regression]: 20_util/ratio/comparisons/comp2.cc et al

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-08-18 13:16 
---
Actually, correctly, in the compilation of comp2.cc, bits/postypes.h doesn't
end up be included, at least on x86_64-linux. Please confirm that, is the most
important thing now. The preprocessed comp2.cc is very small for me, easy to
debug ;) Then I'm now suspecting that for some reason, when
include/tr1_impl/cstdint defines __STDC_LIMIT_MACROS and then include_next
stdint.h, on your target the macros (INTMAX_MAX, in particular) does not become
available.


-- 


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

[Bug libstdc++/37147] [4.4 Regression]: 20_util/ratio/comparisons/comp2.cc et al

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-08-18 13:22 
---
Yes, just to confirm that the first paragraph in my Comment #1 is a red
herring, sorry. Luckily we are debugging comp2.cc which includes very little,
does not include postypes.h. We should concentrate on the test
GLIBCXX_CHECK_C99_TR1 instead, that now is run unconditionally: the part about
stdint.h isn't strict enough for your target: it seems the macros do not become
available, it seems we have to strengthen it adding a check for the macros.


-- 


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

[Bug c/37148] New: -Wunintialized fails in the face of conditional assignment.

[thutt at vmware dot com]

Although I demonstrated this using 4.1.2 on my host, it probably affects
other versions as well.

As the following code shows:

gcc -c -O1 -Wall -Werror uninitialized-warning.c

extern void called_function(unsigned p);
extern unsigned g;

void
f0(unsigned parm)
{
   unsigned v;
   if (parm == 0) {
  v = 4;
   }
   called_function(v);
}

void
f1(unsigned parm)
{
   unsigned v;
   if (parm == 0) {
  v = 4;
   } else {
  g = 0;
   }
   called_function(v);
}

void
f2(unsigned parm)
{
   unsigned v;
   called_function(v);
}

gcc does not produce the 'uninitialized' warning when the automatic
variable is conditionally assigned.

This gives a very bad false sense of security that the automatic
variables are indeed initialized.


-- 
   Summary: -Wunintialized fails in the face of conditional
assignment.
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com


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

[Bug c/37148] -Wunintialized fails in the face of conditional initialization.

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-08-18 13:46 ---
CCP removes the uninitialized use.

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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used unintialized' warning (CCP)

[manu at gcc dot gnu dot org]

--- Comment #17 from manu at gcc dot gnu dot org  2008-08-18 13:46 ---
*** Bug 37148 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||thutt at vmware dot com


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

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[manu at gcc dot gnu dot org]

--- Comment #16 from manu at gcc dot gnu dot org  2008-08-18 13:55 ---
__extension__ now works for CPP warnings in the C front-end.

The issue with system headers is more difficult since it depends on having two
locations.

C++ lexes everything up front before parsing anything, so the warnings from CPP
are all emitted before any C++ warning and __extension__ are handled. I don't
see any easy fix to this (apart from moving pedantic CPP warnings to c-common.c
but that won't be trivial).


-- 


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

[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used unintialized' warning (CCP)

[thutt at vmware dot com]

--- Comment #18 from thutt at vmware dot com  2008-08-18 13:55 ---
This defect has been open nearly 4 years.  Any hope of 
actually getting a fix commited?


-- 


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] possible integer codegen bug

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/37125] [4.3/4.4 Regression] possible integer codegen bug

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/36817] [4.3 Regression] internal compiler error: in compare_values_warnv

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug libstdc++/37147] New failures: 20_util/ratio/comparisons/comp2.cc et al

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2008-08-18 14:05 ---
(In reply to comment #1)
> Something you should also immediately check is whether those tests actually
> were run before the changes and not skipped,

You're right, all of
20_util/ratio/comparisons/comp2.cc
20_util/ratio/operations/ops2.cc
20_util/ratio/operations/ops3.cc
were UNSUPPORTED as of 139006.  The reason they show up as regressions is that
they have actually passed at least once since 2008-05-30 14:24:17 (r136209, the
last regression-free revision for cris-elf, not counting xfails).  Ignoring 
PASS -> UNSUPPORTED or PASS -> deleted while not in a regression-free state is
a feature of the regression tester.  Sorry for the confusion, I should have
double-checked.

Yes, likely the GLIBCXX_CHECK_C99_TR1 macro should be tightened.

Please ignore 27_io/basic_ostream/inserters_other/char/error_code.cc mentioned
in this PR.  It will get a separate PR; it showed up at an earlier revision;
not the same cause or behavior.

I'm not sure, do you still need more information?


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 Regression]:   |New failures:
   |20_util/ratio/comparisons/co|20_util/ratio/comparisons/co
   |mp2.cc et al|mp2.cc et al


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

[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used unintialized' warning (CCP)

[manu at gcc dot gnu dot org]

--- Comment #19 from manu at gcc dot gnu dot org  2008-08-18 14:09 ---
(In reply to comment #18)
> This defect has been open nearly 4 years.  Any hope of 
> actually getting a fix commited?

To be bluntly honest. No, do not expect a fix in the near/medium future. Not
for GCC 4.4 for sure.

CCP relies on this behaviour to optimize code, so we cannot disable it. Moving
passes around (warning before CCP, warning before DCE) would just generate
different false positives/negatives. This is a complex issue:

http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#problem_ccp

Plus, no one is working or planning to work on this at the moment AFAIK.


-- 


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

[Bug libstdc++/37147] New failures: 20_util/ratio/comparisons/comp2.cc et al

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2008-08-18 14:11 
---
Thanks Hans-Peter, probably I don't need further information. I'm already
testing the fix. If you want, you can try to compile ** as a C++ program, this
is important ** the below. If my analysis is correct, should not compile,
meaning we can't really assume a C99-conforming  for your target:

#define __STDC_LIMIT_MACROS
#include 

int main()
{
  typedef intmax_tmy_intmax_t;
  my_intmax_t im = INTMAX_MAX;
  im = INTMAX_MIN;
}


-- 


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

[Bug libstdc++/37147] New failures: 20_util/ratio/comparisons/comp2.cc et al

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2008-08-18 14:49 ---
(In reply to comment #5)
> If you want, you can try to compile ** as a C++ program, this
> is important ** the below. If my analysis is correct, should not compile,
> meaning we can't really assume a C99-conforming  for your target:

Correct.  Cutnpasting compiler options from the feature tests in the libstdc++
testsuite, I get:

/n/slask/hp_tmp/c991.cxx: In function 'int main()':
/n/slask/hp_tmp/c991.cxx:7: error: 'INTMAX_MAX' was not declared in this scope
/n/slask/hp_tmp/c991.cxx:8: error: 'INTMAX_MIN' was not declared in this scope

thanks.


-- 

hp 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-08-18 14:49:11
   date||


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

[Bug libstdc++/37147] New failures: 20_util/ratio/comparisons/comp2.cc et al

[paolo at gcc dot gnu dot org]

--- Comment #7 from paolo at gcc dot gnu dot org  2008-08-18 15:03 ---
Subject: Bug 37147

Author: paolo
Date: Mon Aug 18 15:02:10 2008
New Revision: 139200

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139200
Log:
2008-08-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/37147
* acinclude.m4 ([GLIBCXX_CHECK_C99_TR1]): Tighten checks on stdint.h,
check the macros too.
* configure: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/configure


-- 


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

[Bug libstdc++/37147] New failures: 20_util/ratio/comparisons/comp2.cc et al

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2008-08-18 15:05 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5

[paul at epcc dot ed dot ac dot uk]

--- Comment #5 from paul at epcc dot ed dot ac dot uk  2008-08-18 15:09 
---
Hi,

Just to add, I too have seen this bug (using gcc 4.2.0, not tried other
versions yet) on a powerpc-ibm-aix5.3.0.0, so I'd be keen to hear of any
resolution.

Regards,
Paul Graham


-- 


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

[Bug tree-optimization/31079] 20% difference between ifort/gfortran, missed vectorization

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-08-18 15:20 ---
The problem for the GCC vectorizer is that there are no loads or stores left
in the loop and it doesn't handle vectorizing "registers" only.  This is a
case where real vectorization of straight-line code would be necessary.


-- 


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

[Bug testsuite/37149] New: [4.4 Regression]: 27_io/basic_ostream/inserters_other/char/error_code.cc

[hp at gcc dot gnu dot org]

Worked with: 138952
Known to fail with: 138966 (and up to at least 139189)

Running /x/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
...
FAIL: 27_io/basic_ostream/inserters_other/char/error_code.cc (test for excess
errors)
WARNING: 27_io/basic_ostream/inserters_other/char/error_code.cc compilation
failed to produce executable

.log:
/x/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:
In function 'void test()':

/x/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:49:
error: 'sprintf' was not declared in this scope


Apparently just a case of missing
#include 
in the test-case.  A guess is that the libstdc++ configury change making
GLIBCXX_CHECK_STDIO_MACROS unconditional caused it to fail, where it worked
before.


-- 
   Summary: [4.4 Regression]:
27_io/basic_ostream/inserters_other/char/error_code.cc
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug tree-optimization/31079] 20% difference between ifort/gfortran, missed vectorization

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-08-18 15:22 ---
That is, GCCs inner loop is

.L6:
addl$1, %eax
addsd   %xmm12, %xmm11
cmpl$1, %eax
addsd   %xmm14, %xmm3
addsd   %xmm15, %xmm2
addsd   %xmm13, %xmm1
jne .L6

which doesn't necessarily look slower than ICCs.


-- 


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

[Bug testsuite/37149] [4.4 Regression]: 27_io/basic_ostream/inserters_other/char/error_code.cc

[hp at gcc dot gnu dot org]

-- 

hp 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-08-18 15:22:47
   date||


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

[Bug testsuite/37149] [4.4 Regression]: 27_io/basic_ostream/inserters_other/char/error_code.cc

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-08-18 15:24 ---
Trivial enough not to bother others...


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-18 15:22:47 |2008-08-18 15:24:35
   date||


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

[Bug middle-end/37150] New: vectorizer issue

[jv244 at cam dot ac dot uk]

As pointed out :

http://gcc.gnu.org/ml/gcc/2008-08/msg00290.html

The attached testcase yields (on a core2 duo, gcc trunk):

gfortran -O3 -ftree-vectorize -ffast-math -march=native test.f90
time ./a.out

real 0m3.414s

ifort -xT -O3  test.f90
time ./a.out

real 0m1.556s

The assembly contains:

ifort   gfortran
mulpd 140  0
mulsd   0280


so the reason seems that ifort vectorizes the attached testcase


-- 
   Summary: vectorizer issue
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/37150] vectorizer issue

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-08-18 15:33 ---
Created an attachment (id=16082)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16082&action=view)
testcase


-- 


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

[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

[rguenth at gcc dot gnu dot org]

--- Comment #27 from rguenth at gcc dot gnu dot org  2008-08-18 15:34 
---
This should be fixed by disabling the asserts in question.


-- 


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

[Bug testsuite/37149] [4.4 Regression]: 27_io/basic_ostream/inserters_other/char/error_code.cc

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-08-18 15:37 
---
Ok, thanks, patch to include  preapproved for mainline.


-- 


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

[Bug testsuite/37149] [4.4 Regression]: 27_io/basic_ostream/inserters_other/char/error_code.cc

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-08-18 15:41 
---
Well, for 4_3-branch too, because the testcase is buggy anyway, you cannot
assume any of the existing includes to bring in .


-- 


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

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

--- Comment #7 from dodji at gcc dot gnu dot org  2008-08-18 15:47 ---
Manuel, yes I know that patches go to gcc-patches@ :-)

I am stacking these here to not loose them, but at the same time, I am not sure
if they are solid enough for submission to gcc-patches. I am still working on
them.

I will submit a patch to gcc-patches when I fill a bit more confident :-)


-- 


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

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

--- Comment #8 from dodji at gcc dot gnu dot org  2008-08-18 15:52 ---
Created an attachment (id=16083)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16083&action=view)
Fourth fix candidate

The previous patch was broken for say cross-compilers addressing a 64 target on
a 32 bits host.

I hope this one is better.

Bootstrapped and regtested on x86_64.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16074|0   |1
is obsolete||


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

[Bug middle-end/37150] vectorizer issue

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-18 15:55 ---
Note that there is no loop left on the trunk for the testcase, but after
the vectorizer it is all unrolled completely (unvectorized, of course).
Again this looks like missing vectorization of scalar code.

Note that the first complete unrolling pass unrolls loops that result in
smaller code.  This interferes with vectorization in your case, so can
you try

Index: tree-ssa-loop-ivcanon.c
===
*** tree-ssa-loop-ivcanon.c (revision 139200)
--- tree-ssa-loop-ivcanon.c (working copy)
*** tree_unroll_loops_completely (bool may_i
*** 359,374 

FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
{
! if (may_increase_size && maybe_hot_bb_p (loop->header)
! /* Unroll outermost loops only if asked to do so or they do
!not cause code growth.  */
! && (unroll_outer
! || loop_outer (loop_outer (loop
ul = UL_ALL;
  else
ul = UL_NO_GROWTH;
! changed |= canonicalize_loop_induction_variables
!  (loop, false, ul, !flag_tree_loop_ivcanon);
}

if (changed)
--- 359,378 

FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
{
! /* Unroll outermost loops only if asked to do so.  */
! if (!unroll_outer
! && !loop_outer (loop_outer (loop)))
!   ul = UL_SINGLE_ITER;
! else if (may_increase_size && maybe_hot_bb_p (loop->header))
ul = UL_ALL;
  else
ul = UL_NO_GROWTH;
! if (canonicalize_loop_induction_variables
!   (loop, false, ul, !flag_tree_loop_ivcanon))
!   {
! statistics_counter_event (cfun, "Loops completely unrolled", 1);
! changed = true;
!   }
}

if (changed)


?


-- 

rguenth 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=37150

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2008-08-18 16:03 ---
(In reply to comment #7)
> 
> I am stacking these here to not loose them, but at the same time, I am not 
> sure
> if they are solid enough for submission to gcc-patches. I am still working on
> them.

s/loose/lose/

OK but if you are expecting comments you should send the patch to gcc-patches.
If they bootstrap+regtest they are solid enough to get comments in gcc-patches.
;-)

> I will submit a patch to gcc-patches when I fill a bit more confident :-)

s/fill/feel/

Do as you please but gcc-patches is where you will get the highest visibility.
Just say that you are asking for comments [RFC] or help [RFH] and be clear that
you are unsure about your approach. This will give reviewers a hint that they
must be extra-careful.

Plus, you can ask for extra testing in different machines.


-- 


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

[Bug middle-end/37150] vectorizer issue

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-08-18 16:09 ---
Same trend with "ifort -O3" (ifort 11beta) and "gfortran -O3 --fast-math
-march=native" on AMD Athlon64 X2 4800+ / openSUSE 11. [same mulsd/mulpd
numbers]
ifort 2.452s, gfortran 3.848s -> 57% slower.

With Richard's patch: 3.040s (and mulsd = 0; mulpd = 140)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug c++/36912] [4.2/4.3/4.4 regression] ICE with "-frounding-math -g"

[sylvain dot pion at sophia dot inria dot fr]

--- Comment #6 from sylvain dot pion at sophia dot inria dot fr  2008-08-18 
16:12 ---
Maybe my comment is going to be out of scope, but the question is also
to know what the "primary question" is here, that is, what usage is supposed
to be supported by -frounding-math.

g++ currently accepts code like the following (in non-pedantic mode) :

  template  struct A {};
  A<(int) (1.5-2.0)> a;

I am not sure it would be wise to have -frounding-math break this
(I understand that this would be a consequence of one of Jakub's proposals).

There are users who would like to see constant propagation of floats,
obviously, even with -frounding-math.
(see also C++0x's constexpr which requires this ability, I think).

And there are users who would like to have constant propagation aware
of the rounding mode (either deferring the computation at runtime,
and/or have a way to tell the compiler which rounding mode to use at
compile-time).  It's also related to the FENV_ACCESS pragma.

The current behavior of -frounding-math which keeps on propagating
floats constants is not nice for interval arithmetic code (the main
user of -frounding-math I guess?): you need to protect against the
compiler in ways which affects performance (and code clarity like
introducing volatiles or other workarounds in odd places...).

The fact that -frounding-math affects the whole translation unit is
also problematic.  Usually, it's only in very particular places that
you need to tell the compiler that a block of code needs such an
attention.


Ideally, for me, one should have the option to tell the compiler that
a block of code (e.g. using the new option attributes, or a pragma
a la FENV_ACCESS), or maybe even a single operation, depends on a
non-default rounding-mode, hence stopping inexact constant propagation
and other transformations.
As a bonus, it would be great to also have a way to tell the compiler
that the rounding-mode to be used is known at compile-time.


One could add another option e.g. -frounding-math-at-runtime to distinguish
the two behaviors mentioned by Jakub, but IMO this would not be helpful
for the users who want to mix the 2 features in the same translation unit.


My 2 cents.


-- 


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

[Bug middle-end/37096] conditional evaluation incorrect with -O3

[erik dot moller at cycos dot com]

--- Comment #3 from erik dot moller at cycos dot com  2008-08-18 16:20 
---
Created an attachment (id=16084)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16084&action=view)
main() for the testcase


-- 


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

[Bug middle-end/37096] conditional evaluation incorrect with -O3

[erik dot moller at cycos dot com]

--- Comment #4 from erik dot moller at cycos dot com  2008-08-18 16:20 
---
Created an attachment (id=16085)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16085&action=view)
the test case

it's as minimal I could get it...


-- 


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

[Bug middle-end/37151] New: [4.4 Regression] ICE with -fprofile-use and -ftree-loop-linear

[burnus at gcc dot gnu dot org]

Polyhedron benchmark's mdbx (http://www.polyhedron.co.uk/MFL6VW74649)

gfortran -fprofile-generate -ffast-math -march=opteron -ftree-loop-linear -O3
mdbx.f90
./a.out
gfortran -fprofile-use -ffast-math -march=opteron -ftree-loop-linear -O3
mdbx.f90

gives an segmentation fault. No segfault without -ffast-math or
without -ftree-loop-linear

Valgrind reports:

==23369== Invalid read of size 8
==23369==at 0x4D05B3: ggc_set_mark (ggc-page.c:579)
==23369==by 0x48ABB4: gt_ggc_mx_lang_tree_node (gt-fortran-f95-lang.h:49)
==23369==by 0x62A03C: gt_ggc_mx_rtx_def (gtype-desc.c:1500)
==23369==by 0x48ADB6: gt_ggc_mx_lang_tree_node (gt-fortran-f95-lang.h:204)
==23369==by 0x6228E4: gt_ggc_mx_varpool_node (gtype-desc.c:118)
==23369==by 0x5F9826: ggc_mark_roots (ggc-common.c:107)
==23369==by 0x4D1097: ggc_collect (ggc-page.c:1941)
==23369==by 0x66DC04: execute_todo (passes.c:1050)
==23369==by 0x66DE90: execute_one_pass (passes.c:1304)
==23369==by 0x66E064: execute_pass_list (passes.c:1330)
==23369==by 0x66E07C: execute_pass_list (passes.c:1331)
==23369==by 0x66E07C: execute_pass_list (passes.c:1331)
==23369==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
mdbx.f90: In function 'mstep':
mdbx.f90:822: internal compiler error: Segmentation fault


-- 
   Summary: [4.4 Regression] ICE with -fprofile-use and -ftree-loop-
linear
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
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=37151

[Bug middle-end/37096] conditional evaluation incorrect with -O3

[erik dot moller at cycos dot com]

--- Comment #5 from erik dot moller at cycos dot com  2008-08-18 16:22 
---

the printf("shouldn't happen: %d\n", pAR[0]) happens when debug flags -O2 or
-O3 and -msse2 are set.
the printf("nz: %d\n", nZ); seems to do something awful...

void fun(short *pAR)
{
const short tmp = Transform4x4(pAR);
pAR[0] = 0;

int nZ = 0;
for( int i=0; i<4 ; ++i )
if ( pAR[i] ) {
++nZ;
}

printf("nz: %d\n", nZ);
if ( pAR[0] )
printf("shouldn't happen: %d\n", pAR[0]);
pAR[0] = tmp;
}


-- 


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

[Bug middle-end/37151] [4.4 Regression] ICE with -fprofile-use and -ftree-loop-linear

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-08-18 16:24 ---
Presumably working was 2008-08-15-r139121; failing is 2008-08-18-r139184


-- 


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

[Bug c/29888] No error when "too few arguments" or "conflicting types" would be expected

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-08-18 16:32 ---
The code is correct in -std=c89 (the default). Use -Wall or -std=c99 if you
want to be warned about implicit declarations.


See http://c-faq.com/decl/implfdecl.html


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-08-18 16:42 ---
Alias Wuninitialized


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  Alias||Wuninitialized
Summary|[meta-bug] bug to track all |[meta-bug] bug to track all
   |uninit variable issues  |Wuninitialized issues


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

[Bug c/31893] Please provide an "inout" attribute for function parameters.

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-08-18 16:50 ---
This would need to be a GCC extension and those need some high-level approval,
so still unconfirmed, however I am marking as waiting until a decision is
taken.

You should seek opinions/support in the gcc mailing list. It seems no one has
asked for such an extension before.

I think the standard answer will be "GCC is a C compiler, use other language if
you want other features" but who knows...


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


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

[Bug fortran/13615] -Wuninitialized produces wrong error message for characters

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2008-08-18 16:53 ---
To assess whether this is a middle-end issue, the alias dump (with VOPS and
linenumbers) would be relevant.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||24639
  nThis||


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

[Bug c/31893] Please provide an "inout" attribute for function parameters.

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-08-18 17:14 ---
There is no support for this in the middle-end anyway. Not even for Fortran.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||31094


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2008-08-18 17:24 ---
Please provide a preprocessed reduced testcase as similar to the original as
possible. 

I think this is not only predicated PHI but our representation of loops may
also have something to do.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
OtherBugsDependingO||24639
  nThis||
 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[manu at gcc dot gnu dot org]

-- 

manu 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-08-18 17:29:25
   date||
Summary|Wrong "may be used  |Wrong "may be used
   |uninitialized" warning  |uninitialized" warning
   ||(conditional PHIs)


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

[Bug testsuite/37149] [4.4 Regression]: 27_io/basic_ostream/inserters_other/char/error_code.cc

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-08-18 17:35 
---
Don't worry, I'm handling it together with a few other missing ...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|hp at gcc dot gnu dot org   |paolo dot carlini at oracle
   ||dot com


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

[Bug c++/36814] G++ won't warn about an uninitialized value

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-08-18 17:35 ---
We need a preprocessed self-contained, preferably small, testcase. Otherwise we
cannot reproduce the bug ourselves.

See http://gcc.gnu.org/bugs.html

Thanks.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
OtherBugsDependingO||24639
  nThis||
 Status|UNCONFIRMED |WAITING


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

[Bug c++/15766] bad parse error recovery (2 bugs)

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-08-18 17:48 ---
These are two different bugs.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|bad error messages  |bad parse error recovery (2
   ||bugs)


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

[Bug testsuite/37149] [4.4 Regression]: 27_io/basic_ostream/inserters_other/char/error_code.cc

[paolo at gcc dot gnu dot org]

--- Comment #5 from paolo at gcc dot gnu dot org  2008-08-18 17:49 ---
Subject: Bug 37149

Author: paolo
Date: Mon Aug 18 17:48:15 2008
New Revision: 139206

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139206
Log:
2008-08-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/37149
* testsuite/27_io/basic_ostream/inserters_other/char/4.cc: Include
.
* testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:
Likewise.
* testsuite/27_io/objects/char/12048-1.cc: Likewise.
* testsuite/27_io/objects/char/12048-3.cc: Likewise.
* testsuite/27_io/objects/wchar_t/12048-1.cc: Likewise.
* testsuite/27_io/objects/wchar_t/12048-3.cc: Likewise.
* testsuite/ext/malloc_allocator/deallocate_global.cc: Likewise.
* testsuite/ext/malloc_allocator/deallocate_local.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_global-2.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_global-4.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_global_thread-1.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_global_thread-3.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_local-2.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_local-4.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_local-6.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_local-8.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_local_thread-1.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_local_thread-3.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_local_thread-5.cc: Likewise.
* testsuite/ext/mt_allocator/deallocate_local_thread-7.cc: Likewise.
* testsuite/ext/new_allocator/deallocate_global.cc: Likewise.
* testsuite/ext/new_allocator/deallocate_local.cc: Likewise.
* testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc: Likewise.
* include/std/regex: Include .
* include/tr1/regex: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/regex
trunk/libstdc++-v3/include/tr1/regex
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/4.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc
trunk/libstdc++-v3/testsuite/27_io/objects/char/12048-1.cc
trunk/libstdc++-v3/testsuite/27_io/objects/char/12048-3.cc
trunk/libstdc++-v3/testsuite/27_io/objects/wchar_t/12048-1.cc
trunk/libstdc++-v3/testsuite/27_io/objects/wchar_t/12048-3.cc
trunk/libstdc++-v3/testsuite/ext/malloc_allocator/deallocate_global.cc
trunk/libstdc++-v3/testsuite/ext/malloc_allocator/deallocate_local.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_global-2.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_global-4.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_global_thread-1.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_global_thread-3.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_local-2.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_local-4.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_local-6.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_local-8.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_local_thread-1.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_local_thread-3.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_local_thread-5.cc
trunk/libstdc++-v3/testsuite/ext/mt_allocator/deallocate_local_thread-7.cc
trunk/libstdc++-v3/testsuite/ext/new_allocator/deallocate_global.cc
trunk/libstdc++-v3/testsuite/ext/new_allocator/deallocate_local.cc
trunk/libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc


-- 


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

[Bug testsuite/37149] [4.4 Regression]: 27_io/basic_ostream/inserters_other/char/error_code.cc

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-08-18 17:50 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug c++/15179] bad parse error recovery with missing typename

[manu at gcc dot gnu dot org]

--- Comment #13 from manu at gcc dot gnu dot org  2008-08-18 17:51 ---
Let's give meaningful short descriptions to the bugs, please.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Error message can be|bad parse error recovery
   |improved|with missing typename


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

[Bug c++/36814] G++ won't warn about an uninitialized value

[jellegeerts at gmail dot com]

--- Comment #2 from jellegeerts at gmail dot com  2008-08-18 18:14 ---
Created an attachment (id=16086)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16086&action=view)
output of G++ with the `-v -save-temps' flags


-- 


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

[Bug c++/36814] G++ won't warn about an uninitialized value

[jellegeerts at gmail dot com]

--- Comment #3 from jellegeerts at gmail dot com  2008-08-18 18:15 ---
Created an attachment (id=16087)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16087&action=view)
the `.ii' file that G++ created


-- 


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

[Bug c++/36814] G++ won't warn about an uninitialized value

[jellegeerts at gmail dot com]

--- Comment #4 from jellegeerts at gmail dot com  2008-08-18 18:16 ---
Please see the attachments I created for more information.


-- 


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

[Bug c/20385] Lame parse error message for undefined type

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-08-18 18:28 ---
This is hard. Even the simple cases are hard since the error is detected very
very late. There are far too many ways to declare anything. Perhaps using a
slightly different code patch for C99 would help with -std=c99.

Deprecating the GNU C extension that allows definitions at file scope of
objects with no declaration specifiers would simplify things.

But in the end I think we would need to parse the whole declaration more or
less tentatively before figuring out which errors emit. I think not diagnosing
"unknown type" for the following testcase is ok:

unknowntype (foo)() { return 0; }

We should be worried about simpler cases like:

unknowntype f() { return 0; }
unknowntype *f() { return 0; }

int f(unknowntype a) { return 0; }
int f(unknowntype *a) { return 0; }

unknowntype a;
unknowntype *a;

and so on. Those are the ones users complain about. Also, if other compilers
get them right, then surely we can get them right as well. Now we only need
some brave volunteer to implement it ;-)


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Lame error message for  |Lame parse error message for
   |undefined type  |undefined type


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

[Bug bootstrap/37152] New: tree-vect-transform.c: use of "=" where "==" may have been intended

[dcb314 at hotmail dot com]

I just tried to compile GNU CC version 4.4 snapshot 20080815 with the
Intel C compiler and it said

gcc/tree-vect-transform.c(2488): warning #187: use of "=" where "==" may have
been intended

The source code is

  gcc_assert (ncopies = 1);

Perhaps 

  gcc_assert (ncopies == 1);

was intended ?


-- 
   Summary: tree-vect-transform.c: use of "=" where "==" may have
been intended
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com


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

[Bug c++/36814] G++ won't warn about an uninitialized value

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-08-18 18:56 ---
possible_bug.cc:1: error: `cMyClass' has not been declared
possible_bug.cc: In function `bool Init()':
possible_bug.cc:5: error: `some_function' was not declared in this scope
possible_bug.cc:5: warning: unused variable 'some_function'

Anyway, I guess the following reproduces the original problem:

bool some_function(void);

bool Init()
{
bool retval;

if (some_function())
{
// If the `goto' is executed, 'return retval;' will use the
// uninitialized value of 'retval'.
goto error;
}

retval = true;
error:
return retval;
}


which is converted to:

bool Init() ()
{
  boolD.2365 retvalD.2430;
  boolD.2365 retval.0D.2432;

  # BLOCK 2
  # PRED: ENTRY (fallthru,exec)
  [pr36814.C : 7] retval.0D.2432_2 = some_functionD.2427 ();
  [pr36814.C : 7] retval.0D.2432_3 = retval.0D.2432_2;
  [pr36814.C : 7] if (retval.0D.2432_3 != 0)
goto  (error);
  else
goto ;
  # SUCC: 4 (true,exec) 3 (false,exec)

  # BLOCK 3
  # PRED: 2 (false,exec)
  [pr36814.C : 14] retvalD.2430_5 = 1;
  # SUCC: 4 (fallthru,exec)

  # BLOCK 4, starting at line 0
  # PRED: 2 (true,exec) 3 (fallthru,exec)
  # retvalD.2430_1 = PHI 
errorL.1:
  return 1;
  # SUCC: EXIT

}

by the first CCP pass. So this is CCP again.

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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu dot org]

--- Comment #20 from manu at gcc dot gnu dot org  2008-08-18 18:56 ---
*** Bug 36814 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jellegeerts at gmail dot com


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

[Bug bootstrap/37153] New: [4.4 Regression] Revision 139210 failed to bootstrap

[hjl dot tools at gmail dot com]

On Linux/x86-64, I got

cc1: warnings being treated as errors
../../src-trunk/gcc/value-prof.c: In function ‘check_counter’:
../../src-trunk/gcc/value-prof.c:469: error: cast from pointer to integer of
different size
../../src-trunk/gcc/value-prof.c:478: error: cast from pointer to integer of
different size
make[6]: *** [value-prof.o] Error 1


-- 
   Summary: [4.4 Regression] Revision 139210 failed to bootstrap
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/37153] [4.4 Regression] Revision 139210 failed to bootstrap

[hjl at gcc dot gnu dot org]

--- Comment #1 from hjl at gcc dot gnu dot org  2008-08-18 19:50 ---
Subject: Bug 37153

Author: hjl
Date: Mon Aug 18 19:48:41 2008
New Revision: 139211

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139211
Log:
2008-08-18  H.J. Lu  <[EMAIL PROTECTED]>

PR bootstrap/37153
* value-prof.c (check_counter): Dereference pointer to overall
count when printing it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/value-prof.c


-- 


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

[Bug bootstrap/37152] tree-vect-transform.c: use of "=" where "==" may have been intended

[dorit at gcc dot gnu dot org]

--- Comment #1 from dorit at gcc dot gnu dot org  2008-08-18 20:11 ---
(In reply to comment #0)
> I just tried to compile GNU CC version 4.4 snapshot 20080815 with the
> Intel C compiler and it said
> gcc/tree-vect-transform.c(2488): warning #187: use of "=" where "==" may have
> been intended
> The source code is
>   gcc_assert (ncopies = 1);
> Perhaps 
>   gcc_assert (ncopies == 1);
> was intended ?

no... thanks for the catch, I'll commit a fix 


-- 

dorit at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|tree-vect-transform.c: use  |tree-vect-transform.c: use
   |of "=" where "==" may have  |of "=" where "==" may have
   |been intended   |been intended


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

[Bug bootstrap/37153] [4.4 Regression] Revision 139210 failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-08-18 20:15 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal


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

[Bug fortran/37032] including "file.F90" - no CPP processing

[dfranke at gcc dot gnu dot org]

--- Comment #9 from dfranke at gcc dot gnu dot org  2008-08-18 20:47 ---
Subject: Bug 37032

Author: dfranke
Date: Mon Aug 18 20:46:08 2008
New Revision: 139215

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139215
Log:
2008-08-18  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/37032
* gfortran.texi: Document decision on include file handling in
preprocessed files.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi


-- 


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

[Bug fortran/37032] including "file.F90" - no CPP processing

[dfranke at gcc dot gnu dot org]

--- Comment #10 from dfranke at gcc dot gnu dot org  2008-08-18 20:51 
---
Closing as WONTFIX.

Reference:
http://gcc.gnu.org/ml/fortran/2008-08/msg00071.html
(and following).

(Updated) Documentation about gfortran's behaviour with preprocessing can be
found in sections 1.3 and 2.3 of the manual
(http://gcc.gnu.org/onlinedocs/gfortran/).


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX
   Target Milestone|--- |4.4.0


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

[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2008-08-18 20:56 ---
Reminder: libbackend.a(cpp_include_defaults) seems to be the place where
standard include paths for targets are available -- including, but not limited
to, /usr/include.


-- 


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

[Bug c/37154] New: static inline function problem

[wrobell at pld-linux dot org]

i am getting SIGSEGV while starting two glib2 applications.
please take a look at glib2/gogject/gsignal.c code:

-
2280  gboolean continue_emission;
2281
2282  if (!accumulator)
2283return TRUE;
2284
2285  continue_emission = accumulator->func (ihint, return_accu,
handler_return, accumulator->data);
2286  g_value_reset (handler_return);
--

gdb claims that problem is at line 2285, variable "accumulator" is 0x0,
which should not happen due to lines 228{2,3}.

the function is declared as 'static inline'. removing inline keyword and
recompilation helps. commmand used to compile gsignal.c file:


ppc-pld-linux-gcc -DHAVE_CONFIG_H -I. -I.. -DG_LOG_DOMAIN=\"GLib-GObject\" -I..
-I../glib -I.. -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED
-DGOBJECT_COMPILATION -DG_DISABLE_CONST_RETURNS -D_FORTIFY_SOURCE=2 -pthread
-O2 -fno-strict-aliasing -fwrapv -fsigned-char -gdwarf-2 -g2 -Wall -MT
gsignal.lo -MD -MP -MF .deps/gsignal.Tpo -c gsignal.c  -fPIC -DPIC -o
.libs/gsignal.o
-


-- 
   Summary: static inline function problem
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wrobell at pld-linux dot org
 GCC build triplet: ppc-pld-linux-gcc
  GCC host triplet: ppc-pld-linux-gcc
GCC target triplet: ppc-pld-linux-gcc


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

[Bug c/37154] static inline function problem

[wrobell at pld-linux dot org]

--- Comment #1 from wrobell at pld-linux dot org  2008-08-18 21:05 ---
Created an attachment (id=16088)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16088&action=view)
gsignal.i file


-- 


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

[Bug c/37154] static inline function problem

[wrobell at pld-linux dot org]

--- Comment #2 from wrobell at pld-linux dot org  2008-08-18 21:05 ---
Created an attachment (id=16089)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16089&action=view)
gsignal.s file created by gcc before 'inline' keyword removal


-- 


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

[Bug c/37154] static inline function problem

[wrobell at pld-linux dot org]

--- Comment #3 from wrobell at pld-linux dot org  2008-08-18 21:06 ---
Created an attachment (id=16090)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16090&action=view)
gsignal.s file after 'inline' keyword removal


-- 


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

[Bug middle-end/37154] static inline function problem

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-08-18 21:11 ---
>gdb claims that problem is at line 2285, variable "accumulator" is 0x0,

well with optimization, debugging info is not always fully correct.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end


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

[Bug target/35658] between -funroll-loops -fno-automatic -O2 and common block variable

[sje at cup dot hp dot com]

--- Comment #9 from sje at cup dot hp dot com  2008-08-18 21:51 ---
Kevin, I can no longer reproduce this bug.  I think it was fixed by the same
patch that fixed PR 35659.  Are you able to reproduce this or can we close it
as fixed?


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

Summary|[4.3/4.4 regression] Bad|between -funroll-loops -fno-
   |interaction on ia64 between |automatic -O2 and common
   |-funroll-loops -fno-|block variable
   |automatic -O2 and common|
   |block variable  |


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

[Bug bootstrap/37155] New: [4.4 Regression] Failed to bootstrap on Linux/ia64

[hjl dot tools at gmail dot com]

Gcc 4.4 revision 139215 failed to bootstrap on Linux/ia64:

/export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/
-B/usr/local/ia64-unknown-linux-gnu/bin/ -c  -DUSE_LIBUNWIND_EXCEPTIONS -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -I. -I. -I../../src-trunk/gcc -I../../src-trunk/gcc/.
-I../../src-trunk/gcc/../include -I../../src-trunk/gcc/../libcpp/include 
-I../../src-trunk/gcc/../libdecnumber -I../../src-trunk/gcc/../libdecnumber/dpd
-I../libdecnumber  ../../src-trunk/gcc/dwarf2asm.c -o dwarf2asm.o
../../src-trunk/gcc/dwarf2asm.c: In function 'dw2_asm_output_data_raw':
../../src-trunk/gcc/dwarf2asm.c:91: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [dwarf2asm.o] Error 1
make[6]: *** Waiting for unfinished jobs

Revision 139204 is OK.


-- 
   Summary: [4.4 Regression]  Failed to bootstrap on Linux/ia64
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug c/37156] New: Hangwith -g -O2 (or higher) (discovered with malloc.c in sqlite3)

[cw at f00f dot org]

[EMAIL PROTECTED]:~/wk/sqlite-cvs-git/build$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-2'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-2)

I get a hang:

[EMAIL PROTECTED]:~/wk/sqlite-cvs-git/build$ gcc -Wall -c -O2 -g malloc.i
malloc.i: In function ‘sqlite3_memory_used’:
malloc.i:10: warning: call to ‘sqlite3_status’ declared with attribute warning:
is experimental
  <...hang...>

malloc.i (below, and which i will also attach if i can) is derived from
malloc.c from sqlite (CVS as of this morning), i butchered it as much a i could
to make it as small as possible but still show the problem.

-O1 -g hangs
-O2 is ok
-O2 -g hangs

if you take out either function or any calls the hang seems to go away


[EMAIL PROTECTED]:~/wk/sqlite-cvs-git/build$ cat malloc.i

typedef long long int sqlite_int64;
typedef sqlite_int64 sqlite3_int64;

__attribute__ ((warning ("is experimental"))) int sqlite3_status(int op, int
*pCurrent, int *pHighwater, int resetFlag);

sqlite3_int64 sqlite3_memory_used(void){
  int n, mx;
  sqlite3_int64 res;
  sqlite3_status(0, &n, &mx, 0);
  res = (sqlite3_int64)n;
  return res;
}

void sqlite3_soft_heap_limit(int n){
  int overage;
  overage = sqlite3_memory_used() - n;
}


-- 
   Summary: Hangwith -g -O2 (or higher)  (discovered with malloc.c
in sqlite3)
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cw at f00f dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug debug/37156] Hangwith -g -O2 (or higher) (discovered with malloc.c in sqlite3)

[cw at f00f dot org]

--- Comment #1 from cw at f00f dot org  2008-08-18 22:34 ---
Created an attachment (id=16091)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16091&action=view)
malloc.i hangs with -O2 -g on gcc 4.3.1


-- 


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

[Bug debug/37156] Hangwith -g -O2 (or higher) (discovered with malloc.c in sqlite3)

[cw at f00f dot org]

--- Comment #2 from cw at f00f dot org  2008-08-18 22:37 ---
(sorry, this should have been clarified earlier)

-O1 -g is fine
-O2 is fine
-O2 -g HANGS

dropping __attribute__((warning...) also makes the hang go away --- so
interaction with that an debugging?

gcc 4.1 is fine
gcc 4.2 is fine
gcc 4.4 untested


-- 


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

[Bug middle-end/37154] static inline function problem

[wrobell at pld-linux dot org]

--- Comment #5 from wrobell at pld-linux dot org  2008-08-18 22:40 ---
(In reply to comment #4)
> >gdb claims that problem is at line 2285, variable "accumulator" is 0x0,
> 
> well with optimization, debugging info is not always fully correct.
> 

i've changed function declaration again to 'static inline'
and inserted

printf('acc %d\n', accumulator);

just before line 2285.

i've got 'acc 0'. so it is really 0x0 and the condition at line 2282
is not evaluated properly (or was optimized out/whatever :)


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

--- Comment #9 from vincent at vinc17 dot org  2008-08-18 22:58 ---
(In reply to comment #8)
> Please provide a preprocessed reduced testcase as similar to the original as
> possible. 

Here's a similar testcase.

$ cat tst.c
void *foo (void);
void bar (void *);

void f (void)
{
  int init = 0;
  void *p;

  while (1)
{
  if (init == 0)
{
  p = foo ();
  init = 2;
}
  bar (p);
}
}

$ gcc -Wall -O2 tst.c -c
tst.c: In function 'f':
tst.c:7: warning: 'p' may be used uninitialized in this function

This is quite strange: if I replace the value 2 by 1 or if I replace foo() by
0, the warning is no longer displayed.

Note: in the reality (in MPFR), the variable I called init here is the size of
the array (0 when the array hasn't been allocated yet).


-- 


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

[Bug bootstrap/37155] [4.4 Regression] Revision 139207 failed to bootstrap on Linux/ia64

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-08-18 23:07 ---
Revision 139207:

http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00769.html

is the cause.

[EMAIL PROTECTED] gcc]$ cat x.i
extern int printf (__const char *__restrict __format, ...);
extern void dw2_asm_output_data_raw (int, unsigned long);

void
dw2_asm_output_data_raw (int size, unsigned long value)
{
  unsigned char bytes[8];
  int i;

  for (i = 0; i < 8; ++i)
{
  bytes[i] = value & 0xff;
  value >>= 8;
}

{
  for (i = 0; i < size - 1; ++i)
 printf ("0x%x,", bytes[i]);
  printf ("0x%x", bytes[i]);
}
}
[EMAIL PROTECTED] gcc]$ /export/gnu/import/rrs/139207/bld/./prev-gcc/xgcc
-B/export/gnu/import/rrs/139207/bld/./prev-gcc/
-B/export/gnu/import/rrs/139207/usr/ia64-unknown-linux-gnu/bin/ -c 
-DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -I.
-I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include
-I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber
-I../../src/gcc/../libdecnumber/dpd -I../libdecnumber  x.i -S
x.i: In function ‘dw2_asm_output_data_raw’:
x.i:21: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] gcc]$ 


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org
Summary|[4.4 Regression]  Failed to |[4.4 Regression] Revision
   |bootstrap on Linux/ia64 |139207 failed to bootstrap
   ||on Linux/ia64


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

[Bug bootstrap/37155] [4.4 Regression] Revision 139207 failed to bootstrap on Linux/ia64

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-08-18 23:24 ---
The particular insn is

(insn 72 70 73 8 x.i:17 (set (reg:SI 386)
(minus:SI (subreg:SI (reg/f:DI 376 [ ivtmp.14 ]) 0)
(subreg:SI (reg/f:DI 335 virtual-stack-vars) 0))) 165 {subsi3}
(nil))

(gdb) f 0
#0  subreg_offset_representable_p (xregno=328, xmode=DImode, offset=0, 
ymode=SImode) at ../../src/gcc/rtlanal.c:3244
3244  return (info.representable_p
(gdb) f 1
#1  0x40377740 in validate_subreg (omode=SImode, imode=DImode, 
reg=0x235506c0, offset=0) at ../../src/gcc/emit-rtl.c:755
755   return subreg_offset_representable_p (regno, imode, offset,
omode);
(gdb) call debug_rtx (reg)
(reg/f:DI 328 sfp)
(gdb) 


-- 


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation)

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2008-08-18 23:38 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Please provide a preprocessed reduced testcase as similar to the original as
> > possible. 
> 
> Here's a similar testcase.

Thanks.

This is the optimized SSA dump:

f ()
{
  voidD.39 * pD.1952;
  intD.0 initD.1951;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # SUCC: 3 [100.0%]  (fallthru,exec)

  # BLOCK 3 freq:1
  # PRED: 2 [100.0%]  (fallthru,exec) 5 [100.0%]  (fallthru,dfs_back,exec)
  # initD.1951_1 = PHI <0(2), initD.1951_2(5)>
  # pD.1952_3 = PHI 
  [/home/manuel/src/pr36296.c : 11] if (initD.1951_1 == 0)
goto ;
  else
goto ;
  # SUCC: 4 [29.0%]  (true,exec) 5 [71.0%]  (false,exec)

  # BLOCK 4 freq:2900
  # PRED: 3 [29.0%]  (true,exec)
  [/home/manuel/src/pr36296.c : 13] # SMT.10D.1967_13 = VDEF 
{ SMT.10D.1967 }
  pD.1952_7 = fooD.1945 ();
  # SUCC: 5 [100.0%]  (fallthru,exec)

  # BLOCK 5 freq:1
  # PRED: 3 [71.0%]  (false,exec) 4 [100.0%]  (fallthru,exec)
  # initD.1951_2 = PHI 
  # pD.1952_4 = PHI 
  [/home/manuel/src/pr36296.c : 16] # SMT.10D.1967_14 = VDEF 
{ SMT.10D.1967 }
  barD.1947 (pD.1952_4);
  [/home/manuel/src/pr36296.c : 17] goto ;
  # SUCC: 3 [100.0%]  (fallthru,dfs_back,exec)

}

Because we create a PHI node for p in BB 3, we think that p can be used
uninitialized. Notice also that we are not able to move the 'if' and the call
to foo() out of the infinite loop. This is perhaps a missed optimization.


> This is quite strange: if I replace the value 2 by 1 or if I replace foo() by
> 0, the warning is no longer displayed.

If you replace foo() by 0, then CCP just assumes the p is always 0. In fact, it
will remove p altogether, even if you use 'if (init == 2)', thus missing a real
uninitialized use. This behaviour is known to hide warnings, both correct and
wrong warnings.

If I replace the value 2 by 1 I still get the warning in GCC 4.4, so that
really sounds strange. Are you sure about that?

Anyway, this is a confirmed bug but not easy to fix.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-18 23:38:16
   date||
Summary|wrong warning about |bogus uninitialized warning
   |potential uninitialized |(loop representation)
   |variable|


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

[Bug debug/37156] Hang with -g -O2 (or higher) (discovered with malloc.c in sqlite3)

[cw at f00f dot org]

--- Comment #3 from cw at f00f dot org  2008-08-19 00:38 ---
Someone was able to reproduce the hang and pointed out the first attachment I
put up as edited without the __attribute__

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
 --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile
--enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib
--with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.1 20080708 (Red Hat 4.3.1-4) (GCC)


-- 

cw at f00f dot org changed:

   What|Removed |Added

Summary|Hangwith -g -O2 (or higher) |Hang with -g -O2 (or higher)
   |(discovered with malloc.c in|(discovered with malloc.c in
   |sqlite3)|sqlite3)


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

[Bug debug/37156] Hang with -g -O2 (or higher) (discovered with malloc.c in sqlite3)

[cw at f00f dot org]

--- Comment #4 from cw at f00f dot org  2008-08-19 00:41 ---
Created an attachment (id=16092)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16092&action=view)
updated test case that actually shows the hang


-- 


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