[Bug tree-optimization/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|hppa*-*-* (32-bit)  |hppa*-*-* (32-bit),
   ||sparc-sun-solaris2.*,
   ||mips-sgi-irix6.5
  Component|middle-end  |tree-optimization
   Host|hppa*-*-* (32-bit)  |
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
  Build|hppa*-*-* (32-bit)  |

--- Comment #39 from Eric Botcazou  2010-11-24 
07:16:39 UTC ---
Undo latest bogus changes.

[Bug middle-end/46637] [4.6 Regression] SIGSEGV in if_then_else_cond - too deep recursion

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev  
2010-11-24 06:59:44 UTC ---
Created attachment 22506
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22506
Backtrace in GDB

[Bug middle-end/46637] New: [4.6 Regression] SIGSEGV in if_then_else_cond - too deep recursion

[d.g.gorbachev at gmail dot com]

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

   Summary: [4.6 Regression] SIGSEGV in if_then_else_cond - too
deep recursion
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
  Host: i686-pc-linux-gnu-gcc
Target: i686-pc-linux-gnu-gcc
 Build: i686-pc-linux-gnu-gcc


Created attachment 22505
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22505
Preprocessed Linux source file (in bzip2 format)

Compile with:

gcc -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2
-fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks
-freg-struct-return -ffreestanding -fno-asynchronous-unwind-tables
-fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-strict-overflow -fconserve-stack -Os tcp_input.i

[Bug c/46636] New: attribute aligned is documented as using bytes, uses addressable units instead.

[amylaar at gcc dot gnu.org]

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

   Summary: attribute aligned is documented as using bytes, uses
addressable units instead.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 46489


attribute aligned - and also linked to that pragma align - are documented
as specifying an alignment in bytes.  However, the implementation uses
BITS_PER_UNIT, which could be 1 on a bit-addressed architecture, or
something largish like 16, 32 or 36 on a word-addressed architecture.

[Bug c/46635] New: c-family/c-common.c uses BITS_PER_UNIT in lieu of TYPE_PRECISION (char_type_node)

[amylaar at gcc dot gnu.org]

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

   Summary: c-family/c-common.c uses BITS_PER_UNIT in lieu of
TYPE_PRECISION (char_type_node)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 46633

[Bug c++/46634] New: cp/typeck2.c: uses BITS_PER_UNIT in lieu of TYPE_PRECISION (char_type_node)

[amylaar at gcc dot gnu.org]

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

   Summary: cp/typeck2.c: uses BITS_PER_UNIT in lieu of
TYPE_PRECISION (char_type_node)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 46633

[Bug other/46633] New: [meta-bug] frontends use BITS_PER_UNIT when they mean TYPE_PRECISION (char_type_node)

[amylaar at gcc dot gnu.org]

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

   Summary: [meta-bug] frontends use BITS_PER_UNIT when they mean
TYPE_PRECISION (char_type_node)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 46489


In some places the front ends use BITS_PER_UNIT when they mean
TYPE_PRECISION (char_type_node).
E.g. consider this code from c-family/c-common.c:fix_string_type :

  else if (TREE_TYPE (value) == char16_array_type_node)
{
  nchars = length / (TYPE_PRECISION (char16_type_node) / BITS_PER_UNIT);
  e_type = char16_type_node;

On a bit-addressed architecture, you would have BITS_PER_UNIT == 1, but
probably TYPE_PRECISION (char_type_node) == 8.

[Bug java/46632] New: libjava: fortify catches memcpy overflow in parseAnnotationElement() for 64bit targets

[vapier at gentoo dot org]

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

   Summary: libjava: fortify catches memcpy overflow in
parseAnnotationElement() for 64bit targets
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vap...@gentoo.org


when compiling gcc-4.5.1 with fortify enabled, we see the warnings:

In file included from /usr/include/string.h:642:0,
 from libjava/java/lang/natClass.cc:15:

In function ‘void* memcpy(void*, const void*, size_t)’,
inlined from ‘java::lang::Object*
parseAnnotationElement(java::lang::Class*, _Jv_Constants*, unsigned char*&,
unsigned char*)’ at libjava/java/lang/natClass.cc:1168:60:
/usr/include/bits/string3.h:52:71: warning: call to void*
__builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned
int) will always overflow destination buffer

In function ‘void* memcpy(void*, const void*, size_t)’,
inlined from ‘java::lang::Object*
parseAnnotationElement(java::lang::Class*, _Jv_Constants*, unsigned char*&,
unsigned char*)’ at libjava/java/lang/natClass.cc:1184:60:
/usr/include/bits/string3.h:52:71: warning: call to void*
__builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned
int) will always overflow destination buffer

if we look at the code in question:
...
  case 'D':
{
  int cindex = read_u2 (bytes, last);
  check_constant (pool, cindex, JV_CONSTANT_Double);
  _Jv_word2 word;
  memcpy (&word, &pool->data[cindex], 2 * sizeof (_Jv_word));
  result = Double::valueOf (word.d);
}
break;
...
  case 'J':
{
  int cindex = read_u2 (bytes, last);
  check_constant (pool, cindex, JV_CONSTANT_Long);
  _Jv_word2 word;
  memcpy (&word, &pool->data[cindex], 2 * sizeof (_Jv_word));
  result = Long::valueOf (word.l);
}
break;
...

while it seems like _Jv_word2 would always be twice the size of _Jv_word, the
libjava/include/jvm.h header implies otherwise:
...
union _Jv_word
{
  jobject o; 
  jint i;   // Also stores smaller integral types.
  jfloat f;
  jint ia[1];   // Half of _Jv_word2.
  void* p;

#if SIZEOF_VOID_P == 8
  // We can safely put a long or a double in here without increasing
  // the size of _Jv_Word; we take advantage of this in the interpreter.
  jlong l;   
  jdouble d;
#endif

  jclass clazz;
  jstringstring;
  struct _Jv_Field  *field;
  struct _Jv_Utf8Const  *utf8;
  struct _Jv_ResolvedMethod *rmethod;
};

union _Jv_word2
{
  jint ia[2];
  jlong l;
  jdouble d;
};
...

on a 32bit host, the _Jv_word2 probably is twice the size of _Jv_word (see the
"jint ia[...]" lines).  but on 64bit hosts, both unions include a single
jlong/jdouble entry which means they're probably both 8 bytes.  so the memcpy()
in libjava overwrites 8 random bytes on the stack.

[Bug lto/46629] [4.6 Regression] Failed to build 200.sixtrack in SPEC CPU 2000

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2010-11-24 01:09:20 
UTC ---
Created attachment 22504
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22504
A testcase

[...@gnu-35 delta-fortran]$ /export/gnu/import/svn/gcc-test-spec/usr/bin/gcc -S
-O3 -ffast-math -funroll-loops -msse2 -mfpmath=sse  -m32  -ffast-math 
-fwhole-program -flto=jobserver -fuse-linker-plugin testcase-min.f
testcase-min.f: In function ‘daexx_.part.0’:
testcase-min.f:1:0: internal compiler error: in maybe_cleanup_end_of_block, at
cfgexpand.c:1700
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-35 delta-fortran]$

[Bug lto/46629] [4.6 Regression] Failed to build 200.sixtrack in SPEC CPU 2000

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2010-11-24 00:48:30 
UTC ---
(gdb) call debug_rtx (insn)
(insn 2359 2358 2360 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 2633)
(const_int 0 [0]))) foxys.f:4119 -1
 (nil))

There are 2 jump insns:

(gdb) call debug_rtx_list (last, 100)
(insn 2356 2355 2357 (parallel [
(set (reg:SI 1940 [ ratio_mult_vf.4917 ])
(ashift:SI (reg:SI 1939 [ bnd.4916 ])
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
]) foxys.f:4119 -1
 (nil))

(insn 2357 2356 2358 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 1940 [ ratio_mult_vf.4917 ])
(const_int 0 [0]))) foxys.f:4119 -1
 (nil))

(insn 2358 2357 2359 (set (reg:QI 2633)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) foxys.f:4119 -1
 (nil))

(insn 2359 2358 2360 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 2633)
(const_int 0 [0]))) foxys.f:4119 -1
 (nil))

(jump_insn 2360 2359 2361 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 0)
(pc))) foxys.f:4119 -1
 (expr_list:REG_BR_PROB (const_int 0 [0])
(nil)))

(jump_insn 2361 2360 2362 (set (pc)
(label_ref 0)) foxys.f:4119 -1
 (nil))

(barrier 2362 2361 0)

(gdb)

[Bug target/46631] New: Change operands order so we can use 16bit and instead of 32bit in thumb2

[carrot at google dot com]

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

   Summary: Change operands order so we can use 16bit and instead
of 32bit in thumb2
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
CC: car...@google.com


Compile the following code with options -march=armv7-a -mthumb -Os

struct S {
  int bi_buf;
  int bi_valid;
};

int tz (struct S* p, int bits, int value)
{
  if (p == 0) return 1;
  p->bi_valid = bits;
  p->bi_buf = value & ((1 << bits) - 1);
  return 0;
}

GCC 4.6 generates:

 :
   0:2301  movsr3, #1
   2:b138  cbzr0, 14 
   4:408b  lslsr3, r1
   6:6041  strr1, [r0, #4]
   8:3b01  subsr3, #1
   a:ea03 0202 and.wr2, r3, r2 // A
   e:6002  strr2, [r0, #0]
  10:2000  movsr0, #0
  12:4770  bxlr
  14:4618  movr0, r3
  16:4770  bxlr

Notice instruction A is 32 bit, if we change it to

   and  r2, r2, r3

then we can encode it as 16bit.

[Bug fortran/45636] Failed to fold simple Fortran string

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #28 from John David Anglin  2010-11-24 
00:26:15 UTC ---
Sorry, I didn't intend to reopen.  The web interface seems to
unexpected change fields sometimes.

[Bug c++/46527] Member of template class gets wrong debug location when template (but not member) is used before member is defined

[jyasskin at gcc dot gnu.org]

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

--- Comment #2 from Jeffrey Yasskin  2010-11-24 
00:25:01 UTC ---
Author: jyasskin
Date: Wed Nov 24 00:24:54 2010
New Revision: 167104

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167104
Log:
Propagate the source location from a template function's definition to
any already-instantiated declarations.

PR c++/46527
* gcc/cp/pt.c (instantiate_decl): Propagate the template's
location to its instance.
* gcc/testsuite/g++.dg/debug/dwarf2/pr46527.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr46527.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/45568] [4.6 Regression] stack overflow (or erroneous memory access) building gnattools

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

   Priority|P3  |P4
Version|4.5.3   |4.6.0

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[cestrauss at gmail dot com]

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

--- Comment #14 from Cesar Strauss  2010-11-24 
00:00:00 UTC ---
(In reply to comment #8)
> Created attachment 22400 [details]
> Proposed patch
> 
> Does this patch work for you on Cygwin?
> 

Dear Jorn,

I tried your patch on MinGW, and it does solve the issue for me. The tm.texi
file does not have CR anymore, allowing the build to proceed normally past this
point.

On Cygwin, the patch is not needed (but does no harm) because the default line
end encoding on Cygwin is already LF. So, in the patch, I suggest replacing the
comment "To make this work on Cygwin, remove \r." by "To make this work on
MinGW, remove \r.".

I do not know why your patch didn't work for Anh Vo, maybe the build directory
was not clean from a previous build. In any case, the tests you asked for do
run normally for me on both MinGW and Cygwin:

$ echo -e '\r' |od -x
000 0a0d
002

$ echo -e '\r' |tr -d '\015'|od -x
000 000a
001

$ case `echo X|tr X '\101'` in \
>A) echo ascii;;\
>*) echo ebdic;;\
>  esac
ascii

[Bug objc/31056] objc bogus warning when using const

[nicola at gcc dot gnu.org]

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

--- Comment #4 from Nicola Pero  2010-11-23 23:54:06 
UTC ---
Created attachment 22503
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22503
Testcase constructed by Nicola, showing the problem

[Bug lto/46629] [4.6 Regression] Failed to build 200.sixtrack in SPEC CPU 2000

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2010-11-23 
23:57:00 UTC ---
If so, can you please:
1) put a breakpoint in maybe_cleanup_end_of_block (after the first BARRIER_P
test), with a condition that current_function_decl is the one in which it
crashes, see on which one of those it crashes and p debug_rtx_list (last, 100)
ad that point
2) see where the jump_insn has been created (e.g. put a breakpoint into
make_jump_insn_raw, with condition that insn->u.fld[0].rt_int at the end has
the expected uid and current_function_decl is the expected one, print backtrace
at that spot?

Thanks.

[Bug ada/45568] [4.6 Regression] stack overflow (or erroneous memory access) building gnattools

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

   Priority|P4  |P3
   Last reconfirmed|2010-11-02 13:48:16 |
Version|4.6.0   |4.5.3

--- Comment #5 from John David Anglin  2010-11-23 
23:56:17 UTC ---
Appears to be fixed.

[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|hppa*-*-* (32-bit), |hppa*-*-* (32-bit)
   |sparc-sun-solaris2.*,   |
   |mips-sgi-irix6.5|
   Last reconfirmed|2010-11-04 20:24:00 |
  Component|tree-optimization   |middle-end
   Host|hppa*-*-* (32-bit), |hppa*-*-* (32-bit)
   |sparc-sun-solaris2.*,   |
   |mips-sgi-irix6.5|
 AssignedTo|ebotcazou at gcc dot|unassigned at gcc dot
   |gnu.org |gnu.org
  Build|hppa*-*-* (32-bit), |hppa*-*-* (32-bit)
   |sparc-sun-solaris2.*,   |
   |mips-sgi-irix6.5|

--- Comment #38 from John David Anglin  2010-11-23 
23:54:29 UTC ---
Fixed.

[Bug objc/31056] objc bogus warning when using const

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |nicola at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0

[Bug lto/45702] [4.6 Regression] New LTO test failures

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

   Priority|P2  |P3

--- Comment #25 from John David Anglin  2010-11-23 
23:51:07 UTC ---
This is resolved on hppa, so changing status to fixed.

[Bug objc/31056] objc bogus warning when using const

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Nicola Pero  2010-11-23 23:51:54 
UTC ---
I have been able to construct a testcase myself.  I'll attach it.

Thanks

[Bug libgomp/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed|2010-11-03 15:47:43 |
  Component|middle-end  |libgomp
 AssignedTo|jakub at gcc dot gnu.org|unassigned at gcc dot
   ||gnu.org
   Target Milestone|4.6.0   |---

--- Comment #14 from John David Anglin  2010-11-23 
23:47:56 UTC ---
Resolved.

[Bug fortran/45636] Failed to fold simple Fortran string

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 CC||danglin at gcc dot gnu.org
 Resolution|FIXED   |

--- Comment #27 from John David Anglin  2010-11-23 
23:45:32 UTC ---
(In reply to comment #26)
> The mempcpy is not inlined with -Os.  Presumbably because that would increase
> the size of the resulting object.

Possibly, but based on Rainer's comment, the issue would appear to
affect targets with strict alignment.

Sorry for the mail spamage.  It was caused by a hardware failure at NRC.

[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin

[hjl.tools at gmail dot com]

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

--- Comment #29 from H.J. Lu  2010-11-23 23:43:55 
UTC ---
Please note that -pass-through is a hack, not a real solution.
See

http://www.sourceware.org/bugzilla/show_bug.cgi?id=12248

for a testcase to show why it doesn't work correctly.

[Bug lto/46629] [4.6 Regression] Failed to build 200.sixtrack in SPEC CPU 2000

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2010-11-23 23:33:57 
UTC ---
I can only reproduce it with LTO. I don't have a testcase without
LTO.

[Bug lto/46629] [4.6 Regression] Failed to build 200.sixtrack in SPEC CPU 2000

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2010-11-23 
23:22:43 UTC ---
Do you have a testcase?  Or can you find out where the unconditional jump has
been created and why no barrier has been emitted after it?

[Bug fortran/46520] [4.6 Regression] libquadmath: Build also with --enable-languages=c; fails with some cross targets

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2010-11-23 
23:02:43 UTC ---
Cf. partially complimentary, partially overlapping patches at
http://gcc.gnu.org/ml/fortran/2010-11/msg00291.html and
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02189.html

[Bug fortran/46543] libquadmath: Add documentation

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2010-11-23 
23:01:52 UTC ---
First patch: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02394.html

TODO:
- Get it included
- Document the math functions
- Make sure it is included at http://gcc.gnu.org/onlinedocs/

[Bug fortran/46594] [4.6 Regression] libquadmath intrudes generic (file system) namespace

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2010-11-23 
23:01:01 UTC ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02394.html

[Bug c/46619] gcc thinks line of code can be removed.

[eskil at obsession dot se]

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

--- Comment #16 from Eskil Steenberg  2010-11-23 
22:31:14 UTC ---
Hi again!

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46619
>
> --- Comment #15 from Andrew Pinski  2010-11-23
> 22:09:44 UTC ---
>>Not true. it is not undefined, it is implementation specific.
>
> Huh?  Why do you think that is true?  The C standard is explicit when it
> comes
> to signed integer overflow is undefined behavior.  In fact when talking
> about
> an undefined behavior at the very beginning of the standard, it lists it.

I see this now, i was looking at this:

3.2.1.2 Signed and unsigned integers

   When an unsigned integer is converted to another integral type, if
the value can be represented by the new type, its value is unchanged.

   When a signed integer is converted to an unsigned integer with
equal or greater size, if the value of the signed integer is
nonnegative, its value is unchanged.  Otherwise: if the unsigned
integer has greater size, the signed integer is first promoted to the
signed integer corresponding to the unsigned integer; the value is
converted to unsigned by adding to it one greater than the largest
number that can be represented in the unsigned integer type. /22/

   When an integer is demoted to an unsigned integer with smaller
size, the result is the nonnegative remainder on division by the
number one greater than the largest unsigned number that can be
represented in the type with smaller size.  When an integer is demoted
to a signed integer with smaller size, or an unsigned integer is
converted to its corresponding signed integer, if the value cannot be
represented the result is implementation-defined.

---
Still one could argue that this text:

Undefined behavior --- behavior, upon use of a nonportable or
   erroneous program construct, of erroneous data, or of
   indeterminately-valued objects, for which the Standard imposes no
   requirements.  Permissible undefined behavior ranges from ignoring the
   situation completely with unpredictable results, to behaving during
   translation or program execution in a documented manner characteristic
   of the environment (with or without the issuance of a diagnostic
   message), to terminating a translation or execution (with the issuance
   of a diagnostic message).

...Allows the undefined behavior, to either doing something (witch it
does), doing nothing, or terminating (the compilation or execution). It
does not allow the implementation to change the behavior of things defined
in the spec.

Cheers

E

[Bug c/46619] gcc thinks line of code can be removed.

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski  2010-11-23 
22:09:44 UTC ---
>Not true. it is not undefined, it is implementation specific. 

Huh?  Why do you think that is true?  The C standard is explicit when it comes
to signed integer overflow is undefined behavior.  In fact when talking about
an undefined behavior at the very beginning of the standard, it lists it.

-- Pinski

[Bug c/46619] gcc thinks line of code can be removed.

[eskil at obsession dot se]

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

--- Comment #14 from Eskil Steenberg  2010-11-23 
22:06:39 UTC ---
Hi again!

> because the c standard has specific rules about integral types smaller
> than
> int; they are all promoted to int.

promoting a value to one type in order to do an operation that the type
can not express the answer to, only to then promote it to another that
can, seams absolutely stupid to me, but i guess the C spec is stupid then.

>> Assuming the silliness above is right, it still shouldn't matter.
>
> Oh you forgot that signed integer overflow in C/C++ is undefined which is
> what
> the warning is about in the first place.

Not true. it is not undefined, it is implementation specific. The line
after can only be optimized away if you know that the behavior you specify
in your implementation can only yield values that render it void. your
implementation clearly outputs values that don't do that.

If I get a value from an implementation specific behavior, and use it in a
operation clearly defined in the c spec, you still need to do that
operation.

This is fun!

Cheers

E

 the line that gcc do optimize away is

[Bug libstdc++/46624] istream::sync() doesn't work

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-11-23 
22:00:07 UTC ---
(In reply to comment #2)
> 
> Oh, I guess you are right. Standard doesn't specify behaviour for cin's
> streambuf type. It is implementation-specific. It worked for me on different
> platforms and compilers. I was also reading it's definition on cplusplus.com
> but I should look what standard says.

cplusplus.com has always been a poor reference

> Anyway, it would be nice if it worked as I expected. cin.ignore() statements
> inside loops could be avoided.

It couldn't be avoided in portable code, because other implementation still
might not have the semantics given by cplusplus.com

[Bug c++/46630] Front end issue

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2010-11-23 
21:59:46 UTC ---
(In reply to comment #0)
> Should compile fine per ISO/IEC 14882:2005, 14.6 (Name resolution).

Why?  T::N is not a typename

ISO/IEC 14882:2003 14.6 paragraph 4 seems pretty clear to me:

If a specialization of a template is instantiated for a set of
template-arguments such that the qualified-id prefixed by typename does not
denote a type, the specialization is ill-formed.

[Bug lto/46629] [4.6 Regression] Failed to build 200.sixtrack in SPEC CPU 2000

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug lto/46629] [4.6 Regression] Failed to build 200.sixtrack in SPEC CPU 2000

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #1 from H.J. Lu  2010-11-23 21:58:13 
UTC ---
It is caused by revision 167082:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00971.html

[Bug c++/46630] New: Front end issue

[slarin at codeaurora dot org]

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

   Summary: Front end issue
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sla...@codeaurora.org


The following C++ code: 


class C {
public:
static int N;
union U {
int m;
char k;
};
typedef void (*A[3])(int);
} c;

int C::N = 0;
int n = 0;

template  struct S {
void f(void) { (void) sizeof(typename T::N); }
};
S s;
void g(void) { s.f(); }

Should compile fine per ISO/IEC 14882:2005, 14.6 (Name resolution). It fails
with plain vanilla x86 4.5.1 release:

g++ -v
Using built-in specs.
COLLECT_GCC=.../bin_x86/bin/g++
COLLECT_LTO_WRAPPER=.../bin_x86/libexec/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-threads=posix --prefix=.../bin_x86
--enable-languages=c,c++ --disable-checking
Thread model: posix
gcc version 4.5.1 (GCC)

(any option)

g++ -S test.C 
test.C: In member function 'void S::f() [with T = C]':
test.C:56:   instantiated from here
test.C:53: error: no type named 'N' in 'class C'

[Bug c/46619] gcc thinks line of code can be removed.

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski  2010-11-23 
21:34:35 UTC ---
Oh overflow != wrapping.

[Bug c/46619] gcc thinks line of code can be removed.

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  2010-11-23 
21:34:11 UTC ---
>double is also bigger then
unsigned short, why not promote it to double if we are bringing in random
types?


because the c standard has specific rules about integral types smaller than
int; they are all promoted to int.

> Assuming the silliness above is right, it still shouldn't matter.

Oh you forgot that signed integer overflow in C/C++ is undefined which is what
the warning is about in the first place.

[Bug c/46619] gcc thinks line of code can be removed.

[eskil at obsession dot se]

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

--- Comment #11 from Eskil Steenberg  2010-11-23 
21:29:12 UTC ---
Hi Again!

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46619
>
> --- Comment #10 from Andrew Pinski  2010-11-23
> 20:24:00 UTC ---
>uv = (unsigned int)((int)x[1 + j] * (int)x[1 + i]);
>
> Is what the C standard says should be done as unsigned short is smaller
> than int so it is promoted to int.
   ^^^

Yes, but it ISNT an int, its an unsigned int. double is also bigger then
unsigned short, why not promote it to double if we are bringing in random
types?

>  So we have a 16x16 unsigned to a 31+1
> multiple which can overflow.

Assuming the silliness above is right, it still shouldn't matter.

If it can overflow it means that the product value of the two positive x
values can be negative, and then in turn would become bigger then max
signed int when it gets converted to a unsigned int (uv) from the type int
where you claim the multiplication should be made, making it illegal to
optimize away the later line.

If you read out the data after the line doing the addition it outputs a
unsinged int value larger then max signed int. So the compiler thinks
something could never happen that clearly happens when you run the code.

Cheers

E

[Bug fortran/46545] libquadmath: Update gfortran.texi

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Tobias Burnus  2010-11-23 
20:56:32 UTC ---
(In reply to comment #0)
> That's something trivial, but I am currently swamped in libquad bugs - and 
> thus
> I defer it.

Still swamped - but FIXED as it is simple :-)

[Bug fortran/46545] libquadmath: Update gfortran.texi

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2010-11-23 
20:54:53 UTC ---
Author: burnus
Date: Tue Nov 23 20:54:49 2010
New Revision: 167096

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167096
Log:
2010-11-23  Tobias Burnus  

PR fortran/46545
* gfortran.texi (KIND Type Parameters): Quadmath and F2008
changes.


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

[Bug lto/46629] New: [4.6 Regression] Failed to build 200.sixtrack in SPEC CPU 2000

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] Failed to build 200.sixtrack in SPEC
CPU 2000
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, revision 167092 failed to build 200.sixtrack in SPEC CPU 2000
with

-m32 -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math -fwhole-program
-flto=jobserver -fuse-linker-plugin

I got

foxys.f:1658.17:

  CALL DAALL(IALL,1,'$$UNPACK$$',NOMAX,NVMAX)   
 1
Warning: Rank mismatch in argument 'ic' at (1) (rank-1 and scalar)
foxys.f:1664.17:

  CALL DAALL(IALL,1,AA,I,NVMAX) 
 1
Warning: Rank mismatch in argument 'ic' at (1) (rank-1 and scalar)
foxys.f: In function 'dafunt_':
foxys.f:4119:0: internal compiler error: in maybe_cleanup_end_of_block, at
cfgexpand.c:1700
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
specmake[1]: *** [foxys.o] Error 1
specmake[1]: *** Waiting for unfinished jobs

[...@gnu-35 gcc-test-spec]$ ./usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=./usr/bin/gcc
COLLECT_LTO_WRAPPER=/export/gnu/import/svn/gcc-test-spec/usr/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc/configure --enable-clocale=gnu
--with-system-zlib --with-demangler-in-ld --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --enable-haifa --prefix=/usr/gcc-4.6.0
--with-local-prefix=/usr/local --with-fpmath=sse --with-plugin-ld=ld
Thread model: posix
gcc version 4.6.0 20101123 (experimental) (GCC) 
[...@gnu-35 gcc-test-spec]$

[Bug c/46619] gcc thinks line of code can be removed.

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  2010-11-23 
20:24:00 UTC ---
   uv = (unsigned int)((int)x[1 + j] * (int)x[1 + i]);

Is what the C standard says should be done as unsigned short is smaller than
int so it is promoted to int.  So we have a 16x16 unsigned to a 31+1 multiple
which can overflow.

[Bug c/46619] gcc thinks line of code can be removed.

[eskil at obsession dot se]

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

--- Comment #9 from Eskil Steenberg  2010-11-23 
20:20:51 UTC ---
Hi

> typedef unsigned short VBigDig;
>uv = x[1 + j] * x[1 + i];
>high = (uv & 0x8000u) != 0;
>
> Is really
>uv = (int)x[1 + j] * (int)x[1 + i];
>high = (uv & 0x8000u) != 0;
>
> So overflow is undefined.

Wait... From where does it get int?

I could imagine it doing:

   uv = (unsigned int)x[1 + j] * (unsigned int)x[1 + i];

since uv is unsigned int, or:

   uv = (unsigned int)((unsigned short)x[1 + j] * (unsigned short)x[1 + i]);

because x is a pointer to unsigned short. In this case I can understand
that uv could not get bigger then max unsigned short, but it does go all
the way up to max singed int, since max signed int lower then 0x8000u
i can understand that it optimizes away the later line.

The line contains 2 types, yet the compiler decides to do math in a third!

Both input and output are unsingend, from where does the compiler get the
idea to go anything signed?

Cheers

E

[Bug middle-end/46628] New: [4.6 Regression] FAIL: g++.dg/tree-prof/partition1.C

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] FAIL: g++.dg/tree-prof/partition1.C
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org


On Linux/ia32, revision 167085:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00974.html

caused:

FAIL: g++.dg/tree-prof/partition1.C compilation,  -O3 -g  -fprofile-generate
FAIL: g++.dg/tree-prof/partition1.C compilation,  -g  -fprofile-generate
FAIL: g++.dg/tree-prof/partition2.C compilation,  -O3 -g  -fprofile-generate
FAIL: g++.dg/tree-prof/partition2.C compilation,  -g  -fprofile-generate

[Bug libstdc++/46624] istream::sync() doesn't work

[MyAdEss at seznam dot cz]

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

MyAdEss at seznam dot cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from MyAdEss at seznam dot cz 2010-11-23 20:01:30 UTC ---
(In reply to comment #1)
> I don't see a requirement in the standard for the behaviour you expect.
> 
> istream::sync() calls streambuf::sync(), the behaviour of which depends on the
> specific streambuf type.  Since the type of streambuf used by std::cin is
> unspecified, the behaviour of cin.sync() is also unspecified.

Oh, I guess you are right. Standard doesn't specify behaviour for cin's
streambuf type. It is implementation-specific. It worked for me on different
platforms and compilers. I was also reading it's definition on cplusplus.com
but I should look what standard says.
Anyway, it would be nice if it worked as I expected. cin.ignore() statements
inside loops could be avoided.

Thank you for your fast reply.

[Bug c++/46626] [4.6 Regression] simple use of virtual methods causes pure virtual method call in c++0x mode

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2010-11-23 19:58:33 
UTC ---
(In reply to comment #1)
> related to PR 46526 ?

Revision 167049 still fails.

[Bug c++/46626] [4.6 Regression] simple use of virtual methods causes pure virtual method call in c++0x mode

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.23 19:57:55
 CC||jason at redhat dot com
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-11-23 19:57:55 
UTC ---
It is caused by revision 166167:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00053.html

[Bug c++/46626] [4.6 Regression] simple use of virtual methods causes pure virtual method call in c++0x mode

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2010-11-23 
19:37:08 UTC ---
related to PR 46526 ?

[Bug inline-asm/20468] LABEL already defined in inline-asm

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||cacheflood at gmail dot com

--- Comment #3 from Andrew Pinski  2010-11-23 
19:26:10 UTC ---
*** Bug 46627 has been marked as a duplicate of this bug. ***

[Bug c/46627] "Error: symbol `again' is already defined" error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2010-11-23 
19:26:10 UTC ---
Using a label in the inline-asm is incorrect as inline-asm could be duplicated
for multiple of reasons: inlining, and unrolling loops are just two examples. 
See PR 20468#c1 for how to get around by using a local label.

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

[Bug objc/46473] 'in' not allowed in 'for' loop

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.23 19:24:54
 Ever Confirmed|0   |1

[Bug c/46619] gcc thinks line of code can be removed.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #8 from Andrew Pinski  2010-11-23 
19:19:49 UTC ---
v_bignum.c:772: warning: assuming signed overflow does not occur when
simplifying conditional to constant


typedef unsigned short VBigDig;
   uv = x[1 + j] * x[1 + i];
   high = (uv & 0x8000u) != 0;

Is really
   uv = (int)x[1 + j] * (int)x[1 + i];
   high = (uv & 0x8000u) != 0;

So overflow is undefined.

[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin

[davek at gcc dot gnu.org]

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

--- Comment #28 from Dave Korn  2010-11-23 19:18:46 
UTC ---
Author: davek
Date: Tue Nov 23 19:18:39 2010
New Revision: 167091

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167091
Log:
PR driver/42690
* gcc.c (LINK_COMMAND_SPEC): Remove hard-coded pass-through plugin
options, replace by call of pass-through-libs spec function to process
link_gcc_c_sequence spec.
(lto_libgcc_spec): Delete variable.
(static_specs[]): Remove related entry.
(static_spec_functions[]): Add new entry for pass-through-libs.
(main): Don't generate deleted lto_libgcc_spec.
(pass_through_libs_spec_func): New function to implement the new
pass-through-libs spec function.
* doc/invoke.texi (pass-through-libs): Document new spec function.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/gcc.c

[Bug c/46627] New: "Error: symbol `again' is already defined" error

[cacheflood at gmail dot com]

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

   Summary: "Error: symbol `again' is already defined" error
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cachefl...@gmail.com


function containing assembler code with intel syntax failed to compile if
optimization flag is set (-O2/-O3) on compiler.

  int test()
  {
asm(
"again:"
"mov edx,dword ptr [esi];"
 ... blalblbalbl ...
   );
  }
  int main(int argc,char **argv)
  {
test();
  }


if changed to:
  inline int test()
  {..
does not work either.

by changing function to:
  static int test()
  { ..
works!!!


Here is the compile command:
gcc -pg -masm=intel main.c -march=core2 -mfpmath=sse -mtune=pentium -O3

bug?

[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin

[davek at gcc dot gnu.org]

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

--- Comment #27 from Dave Korn  2010-11-23 19:08:45 
UTC ---
(In reply to comment #25)
> The current linker plugin scheme may be flawed.  The order of
> linking libraries (archive and DSO) is very important. They
> have to be placed between crti.o and crtn.o. We may not link
> an archive after crtn.o.

Sounds like crtn.o should be sent to the link via a further -pass-through
option (positioned after the ones that re-scan the libraries) rather than
directly on the command-line when the plugin is in use.

[Bug c/46619] gcc thinks line of code can be removed.

[eskil at obsession dot se]

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

--- Comment #7 from Eskil Steenberg  2010-11-23 
19:07:23 UTC ---
Created attachment 22502
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22502
full test case.

Test case that should run the code (sorry i dont have gcc on the machine om
on). Still i do think actively trying to run the code is very complicated way
of looking for this bug. A much better way is just to compile the file and look
at the generated assembler code.

[Bug libstdc++/36104] [4.3/4.4/4.5/4.6 Regression] gnu-versioned-namespace is broken

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik  changed:

   What|Removed |Added

   Target Milestone|4.3.6   |4.6.0

--- Comment #8 from Benjamin Kosnik  2010-11-23 
19:02:52 UTC ---

Yes, I'm targeting 4.6.0 for this. I've adjusted the target milestone
appropriately. Paolo already reverted the directory changes that made this stop
working, so I anticipate that fixes for this will be confined to c++config and
marking up spots that weren't there 3 years ago.

[Bug c++/46626] New: [4.6 Regression] simple use of virtual methods causes pure virtual method call in c++0x mode

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] simple use of virtual methods causes
pure virtual method call in c++0x mode
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Target: x86_64-pc-linux-gnu


Created attachment 22501
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22501
reduced testcase

$ g++ -std=c++0x testcase.C
$ ./a.out 
pure virtual method called
terminate called without an active exception
Aborted

Tested revisions
r167054 - fail
r167002 - fail
r165699 - OK

[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #7 from dave at hiauly1 dot hia.nrc.ca 2010-11-23 18:45:14 UTC ---
> Any reason why this patch isn't submitted/commited? 

No.  I was traveling and forgot about it.  Access to the arm box
on my desk is unreliable.

Dave

[Bug c/46619] gcc thinks line of code can be removed.

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2010-11-23 18:41:05 
UTC ---
(In reply to comment #5)
> 
> You will find them in v_randgen.c
> 
> Here you find (among other things) the entire verse lib:
> 
> http://www.quelsolaar.com/files/verse_apps.zip
> 

Please upload a complete testcase here.

[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared

[laurent at guerby dot net]

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

--- Comment #6 from Laurent GUERBY  2010-11-23 
18:29:43 UTC ---
I see the same errors, the patch has:

+#   define INIT_ARRAY_SECTION_ASM_OP ARM_EABI_CTORS_SECTION_OP
+#   define FINI_ARRAY_SECTION_ASM_OP ARM_EABI_DTORS_SECTION_OP

So might be related.

[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared

[doko at ubuntu dot com]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at ubuntu dot com

--- Comment #5 from Matthias Klose  2010-11-23 18:18:31 
UTC ---
applying this patch, I see excess errors in every testcase:

/usr/bin/ld: warning: .init_array section has zero size
/usr/bin/ld: warning: .fini_array section has zero size

[Bug fortran/46625] New: libquadmath: Mangle internal symbols; rename __float128 <-> string functions

[burnus at gcc dot gnu.org]

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

   Summary: libquadmath: Mangle internal symbols; rename
__float128 <-> string functions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


For libquadmath.a it makes sense to mangle non-exported symbols, e.g. by
prefixing them with __quadmath_

quadmath_strtopQ and quadmath_dtoaq look ugly, Jakub suggests:
   quadmath_strtoq and quadmath_qtostr


C example (to have one somewhere):

/* Compile with  gcc test.c -lquadmath -lm  shows:
:+1.41421356237309504880e+00:
:+1.2345678000e-05:
*/

#include 
#include 

int main()
{
  __float128 r;
  char str[200];

  r = 2.0q;
  r = sqrtq(r);
  quadmath_dtoaq (str, 200, 20, r);
  printf(":%s:\n", str);

  quadmath_strtopQ ("1.2345678", NULL, &r);
  r = r/10.0q;
  quadmath_dtoaq (str, 200, 10, r);
  printf(":%s:\n", str);

  return 0;
}

[Bug c/46619] gcc thinks line of code can be removed.

[eskil at obsession dot se]

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

--- Comment #5 from Eskil Steenberg  2010-11-23 
18:13:23 UTC ---
Hi

> /tmp/ccaJLFo2.o: In function `v_bignum_set_random':
> v_bignum.c:(.text+0x25c): undefined reference to `v_randgen_new'
> v_bignum.c:(.text+0x276): undefined reference to `v_randgen_get'
> v_bignum.c:(.text+0x232): undefined reference to `v_randgen_get'
> v_bignum.c:(.text+0x290): undefined reference to `v_randgen_destroy'
> collect2: ld returned 1 exit status

You will find them in v_randgen.c

Here you find (among other things) the entire verse lib:

http://www.quelsolaar.com/files/verse_apps.zip

Cheers

E

[Bug preprocessor/12258] -Wold-style-cast triggers on casts in macros from system headers

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  2010-11-23 
18:09:39 UTC ---
Author: hjl
Date: Tue Nov 23 18:09:34 2010
New Revision: 167090

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167090
Log:
Properly check default linker.

2010-11-23  H.J. Lu  

PR binutils/12258
* configure.ac: Correct comments for --enable-gold/--enable-ld.
Properly check default linker.
* configure: Regnerated.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac

[Bug c/46619] gcc thinks line of code can be removed.

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2010-11-23 18:06:37 
UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Do you have a run-time testcase?
> 
> There is a test you can run in v_prime.c , it should fail to set the high bit

It won't link:

[...@gnu-35 pr46619]$ gcc -O2 v_bignum.c
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64/crt1.o: In function
`_start':
(.text+0x20): undefined reference to `main'
/tmp/ccaJLFo2.o: In function `v_bignum_set_random':
v_bignum.c:(.text+0x25c): undefined reference to `v_randgen_new'
v_bignum.c:(.text+0x276): undefined reference to `v_randgen_get'
v_bignum.c:(.text+0x232): undefined reference to `v_randgen_get'
v_bignum.c:(.text+0x290): undefined reference to `v_randgen_destroy'
collect2: ld returned 1 exit status

[Bug libstdc++/46624] istream::sync() doesn't work

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2010-11-23 
18:00:30 UTC ---
I don't see a requirement in the standard for the behaviour you expect.

istream::sync() calls streambuf::sync(), the behaviour of which depends on the
specific streambuf type.  Since the type of streambuf used by std::cin is
unspecified, the behaviour of cin.sync() is also unspecified.

[Bug c/46619] gcc thinks line of code can be removed.

[eskil at obsession dot se]

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

--- Comment #3 from Eskil Steenberg  2010-11-23 
17:55:56 UTC ---
(In reply to comment #2)
> Do you have a run-time testcase?

There is a test you can run in v_prime.c , it should fail to set the high bit
and therefor should not ever find a prime. Testing that something is broken by
finding that some thing doesn't do some thing is kind of hard, so I would
rather recommend looking at just the assembly code and try to figure out why it
thinks that the specific line can be removed. (the obvious one to me is that it
thinks that uv is signed and therefor can never go as high as 0x8000).

Cheers

E

[Bug libstdc++/46624] New: istream::sync() doesn't work

[MyAdEss at seznam dot cz]

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

   Summary: istream::sync() doesn't work
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: myad...@seznam.cz


Created attachment 22500
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22500
information file generated by g++-4.5 -v -save-temps sync.cpp

istream::sync() doesn't work properly. It returns zero value, so it looks like
it synchronizes the buffer, but it does not.
When I ask user for input, I should be able to get part of this input and
ignore the rest with cin.sync(). Then I should be able to ask for input again
without reading those old ignored characters.
However when I do that, no characters are discarded and user is not even asked
for the second input.
I have this problem with g++ versions 4.5.1-7ubuntu2 and 4.4.4-14ubuntu5.

--- Example ---
-source--
char a,b;
cout << "Enter word: ";
a = cin.get();

cin.sync();

cout << "Enter another word: ";
b = cin.get();

cout << a << " " << b;
-expected input--
Enter word: hello
Enter another word: world
expected output--
h w
-real input--
Enter word: hello
Enter another word:
-real output--
h e
---

--- sync.cpp: ---
#include 
using namespace std;

int main () {
  char first, second;

  cout << "Please, enter a word: ";
  // this gets the first character of the first word
  first=cin.get();

  // this should discard all unread characters
  cin.sync();

  cout << "Please, enter another word: ";
  // this should wait for another word, but it gets
  // the second character of the first word instead
  second=cin.get();

  cout << "The first word began by " << first << endl;
  cout << "The second word began by " << second << endl;

  return 0;
}

--- Generated .ii file as attachment ---

--- Output of g++-4.5 -v -save-temps sync.cpp ---
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.1-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.1 (Ubuntu/Linaro 4.5.1-7ubuntu2) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/cc1plus -E -quiet -v -D_GNU_SOURCE
sync.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=x86-64 -fpch-preprocess
-fstack-protector -o sync.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.5
 /usr/include/c++/4.5/x86_64-linux-gnu
 /usr/include/c++/4.5/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/include
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/cc1plus -fpreprocessed sync.ii -quiet
-dumpbase sync.cpp -mtune=generic -march=x86-64 -auxbase sync -version
-fstack-protector -o sync.s
GNU C++ (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (x86_64-linux-gnu)
compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version
3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (x86_64-linux-gnu)
compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version
3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 50e33501336f77ceb788d88860a1807b
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -V -Qy --64 -o sync.o sync.s
GNU assembler version 2.20.51 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.20.51-system.20100908
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/:/usr/lib/gcc/x86_64-linux-gnu/

[Bug target/46623] New: microblaze --enable-werror-always build fails

[amylaar at gcc dot gnu.org]

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

   Summary: microblaze --enable-werror-always build fails
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 44756
Target: microblaze-elf


gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumberinsn-preds.c -o
insn-preds.o
../../../gcc/gcc/config/microblaze/predicates.md: In function
‘arith_operand32’:
../../../gcc/gcc/config/microblaze/predicates.md:31:2: error: comparison
between signed and unsigned integer expressions [-Werror=sign-compare]
../../../gcc/gcc/config/microblaze/predicates.md:31:2: error: comparison
between signed and unsigned integer expressions [-Werror=sign-compare]

[Bug c/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-11-23 
16:55:12 UTC ---
GCC 4.5 produces the desired result.

[Bug target/46622] New: ARM --target-help headings not translated

[jsm28 at gcc dot gnu.org]

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

   Summary: ARM --target-help headings not translated
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org
Blocks: 40883
Target: arm*-*-*


arm.c:arm_target_help prints lists of -march and -mcpu values for
--target-help.  The headings of these lists should be translated, but are
passed straight to printf without translation.

  printf ("  Known ARM CPUs (for use with the -mcpu= and -mtune= options):\n");

  printf ("\n\n  Known ARM architectures (for use with the -march=
option):\n");

[Bug target/33637] [4.3/4.4/4.5/4.6 Regression] "checking for nm: test: too many arguments" causes "Undefined symbol: __gxx_personality_v0"

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2010-11-23 
16:27:40 UTC ---
Actually, the gcc/configure.ac hunks are needed too (just tested on
x86_64-linux
with a hack which added the (ignored) -X32_64 to extra_nmflags_for_target in
toplevel configure{,.ac}).
Which in the end means that the

http://overlays.gentoo.org/proj/alt/export/51702/trunk/prefix-overlay/sys-devel/gcc/files/4.3.0/targettools-checks.patch

patch is correct and should be applied.

Michael, can you please write a ChangeLog entry for it and mail to
gcc-patc...@gcc.gnu.org ?

[Bug tree-optimization/46621] New: gimple.h includes tm.h

[amylaar at gcc dot gnu.org]

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

   Summary: gimple.h includes tm.h
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 46489

[Bug c/46620] New: 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[bnitulescu at tremend dot ro]

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

   Summary: 32-bit structures containing bitfields are not copied
correctly on -O2 , x86 backend
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bnitule...@tremend.ro


Created attachment 22499
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22499
Test case exhibiting the error

The attached code contains a copy between two structures containing bitfields.

The x86 code generated on -O2 fails to copy two fields in the structure. It is
also very complex, trying to break the structure in sets of bitfields and copy
them independently.

I have attached an archive containing
- file exhibiting the error (bitfield-error.c)
- main file driving the example
- generated assembly code (gcc -c -O2 bitfield-error.c -S)

To run the code in the attachment

gcc -c -O2 bitfield-error.c
gcc -c -O0 bitfield-error-main.c
gcc -o bitfield-error bitfield-error.o bitfield-error-main.o
./bitfield-error

Result: 0, expected 1

Running at -O0 gives a different answer

gcc -c -O0 bitfield-error.c
gcc -o bitfield-error bitfield-error.o bitfield-error-main.o
./bitfield-error

Result: 1, expected 1

The gcc used is the one from Ubuntu 10.04.1 LTS :

$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 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 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-11-23 
16:06:44 UTC ---
Created attachment 22498
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22498
wip patch

Work in progress patch.  Needs to transition functions elsewhere, hookize
fold_const_aggregate_ref and friends and also make VRP use
gimple_fold_stmt_to_constant.

[Bug c++/45940] [trans-mem] Error of unsafe function even if annotated

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Aldy Hernandez  2010-11-23 
15:53:43 UTC ---
Fixed by:

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02354.html

Waiting for approval.

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  2010-11-23 15:44:35 
UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > They can use the new rdtsc builtin.
> 
> In which GCC version will it appear ? will be cool if you can share a little
> example as well.

GCC 4.5 supports it:

[...@gnu-6 tmp]$ cat x.c
#include 

unsigned long long
foo ()
{
  return __rdtsc ();
}
[...@gnu-6 tmp]$ gcc -O2 x.c -S
[...@gnu-6 tmp]$ cat x.s
.file"x.c"
.text
.p2align 4,,15
.globl foo
.typefoo, @function
foo:
.LFB535:
.cfi_startproc
rdtsc
salq$32, %rdx
orq%rdx, %rax
ret
.cfi_endproc
.LFE535:
.sizefoo, .-foo
.ident"GCC: (GNU) 4.5.1 20100924 (Red Hat 4.5.1-4)"
.section.note.GNU-stack,"",@progbits
[...@gnu-6 tmp]$ gcc -O2 x.c -S -m32
[...@gnu-6 tmp]$ cat x.s
.file"x.c"
.text
.p2align 4,,15
.globl foo
.typefoo, @function
foo:
pushl%ebp
movl%esp, %ebp
rdtsc
popl%ebp
ret
.sizefoo, .-foo
.ident"GCC: (GNU) 4.5.1 20100924 (Red Hat 4.5.1-4)"
.section.note.GNU-stack,"",@progbits
[...@gnu-6 tmp]$

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |
   Target Milestone|4.4.6   |---

--- Comment #13 from H.J. Lu  2010-11-23 15:29:30 
UTC ---
They can use the new rdtsc builtin.

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #15 from Richard Guenther  2010-11-23 
15:35:16 UTC ---
Doesn't make it non-invalid.

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[crrodriguez at opensuse dot org]

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

--- Comment #14 from Cristian Rodríguez  
2010-11-23 15:34:19 UTC ---
(In reply to comment #13)
> They can use the new rdtsc builtin.

In which GCC version will it appear ? will be cool if you can share a little
example as well.

[Bug middle-end/46500] target.h includes tm.h

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2010-11-23 15:30:08 UTC ---
On Tue, 23 Nov 2010, amylaar at gcc dot gnu.org wrote:

> I then posted an update of the first (void * based) patch that
> encapsulated the void * in a struct or union:
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01994.html

You should just stick with this version and seek to get a review of it 
rather than posting yet more alternatives.  The basic problem is that you 
have posted far too many variants and continued to post inferior variants 
after posting this patch which seems to use the right approach.

[Bug middle-end/46499] [4.5/4.6 Regression] gcc.c-torture/execute/20051021-1.c FAILs with -fno-tree-dominator-opts -fno-tree-ccp

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2010-11-23 
15:16:52 UTC ---
Author: jakub
Date: Tue Nov 23 15:16:43 2010
New Revision: 167082

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167082
Log:
PR middle-end/46499
* cfgexpand.c (maybe_cleanup_end_of_block): Remove also BARRIERs
following unconditional jumps.

* gcc.dg/pr46499-1.c: New test.
* gcc.dg/pr46499-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr46499-1.c
trunk/gcc/testsuite/gcc.dg/pr46499-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/46614] [4.5/4.6 Regression] gcc.dg/vect/vect-strided-u8-i8-gap4.c FAILs with -fno-rename-registers -fsched2-use-superblocks

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2010-11-23 
15:12:54 UTC ---
Created attachment 22497
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22497
gcc46-pr46614.patch

Untested fix that cures this testcase.

[Bug c++/45940] [trans-mem] Error of unsafe function even if annotated

[patrick.marlier at gmail dot com]

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

Patrick Marlier  changed:

   What|Removed |Added

 CC||patrick.marlier at gmail
   ||dot com

--- Comment #4 from Patrick Marlier  
2010-11-23 15:11:49 UTC ---
(In reply to comment #3)
> push_back() is not annotated as transaction_pure.

True. It was just a annotation test and thus others functions are not
annotated. So it seems correct.

> Please verify that this is the case on your end, because my upcoming patch 
> will
> only fix the error in the PR, not this additional error I see.

I think it is ok. Did you send the patch in gcc-patches?

Patrick Marlier.

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2010-11-23 
15:01:37 UTC ---
The original testcase should just use

  __asm__ __volatile__("rdtsc":"=a"(havege_hardtick)::"dx");

everywhere.  That fixes the original testcase for me.

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #11 from Richard Guenther  2010-11-23 
14:55:31 UTC ---
Anwyay.  Invalid.

[Bug rtl-optimization/46614] [4.5/4.6 Regression] gcc.dg/vect/vect-strided-u8-i8-gap4.c FAILs with -fno-rename-registers -fsched2-use-superblocks

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2010-11-23 
14:47:43 UTC ---
So, the bug is that we have two kinds of INSNs in
deps->last_pending_memory_flush
1) jumps added there via:
deps->last_pending_memory_flush
  = alloc_INSN_LIST (insn, deps->last_pending_memory_flush);
   in deps_analyze_insn
2) any instructions added there via:
  deps->last_pending_memory_flush = alloc_INSN_LIST (insn, NULL_RTX);
   in flush_pending_lists

This list is used to add dependencies in flush_pending_lists (correct),
sched_analyze_1 (for writes, also correct, and one correct for write spot in
sched_analyze_insn) and then in sched_analyze_2 and sched_analyze_insn for
reads/DEBUG_INSNs, where it differentiates between 1) and 2) above using JUMP_P
test on the insn in the last_pending_memory_flush list.  E.g. in
sched_analyze_2
it adds deps always for the (assumed) category 2) and only adds something for
category 1) if it the memory can trap.  The problem is that JUMP_P is not a
good
test between 1) and 2), as flush_pending_lists can be also called on JUMP_Ps:
  /* Flush pending lists on jumps, but not on speculative checks.  */
  if (JUMP_P (insn) && !(sel_sched_p ()
 && sel_insn_is_speculation_check (insn)))
flush_pending_lists (deps, insn, true, true);
and (what happens here):
  if (!deps->readonly
  && JUMP_P (insn)
  && !(sel_sched_p ()
   && sel_insn_is_speculation_check (insn)))
{
  /* Keep the list a reasonable size.  */
  if (deps->pending_flush_length++ > MAX_PENDING_LIST_LENGTH)
flush_pending_lists (deps, insn, true, true);
  else
deps->last_pending_memory_flush
  = alloc_INSN_LIST (insn, deps->last_pending_memory_flush);
}

What happens on the testcase is that pending_flush_length gets too large and
so we flush_pending_lists and flushes everything, adding needed dependencies
and sets deps->last_pending_memory_flush to contain just that jump.
A few insns later we process a read and go through last_pending_memory_flush,
see it only contains a JUMP_P and that the memory can't trap and don't add any
dependency.  But in this case, because the jump was added as result of
flush_pending_lists and thus represents all the memory writes before it as
well,
it is wrong, we need to add a dependency.

I guess we need to keep the information whether a jump was added as part of
flush_pending_lists or for 1) somewhere, wonder if mode of the INSN_LIST
wouldn't be usable in this case for it.

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2010-11-23 
14:38:00 UTC ---
(In reply to comment #9)
> Looks just like bogus inline asm.  For rdtsc which sets 32-bits in %eax and
> 32-bits in %edx, for 32-bit code you want "=A" (long_long_variable) and
> for 64-bit code you need "=a" (one_int_variable), "=d" (another_int_variable)
> Otherwise you are lying on what the insn does.
> "=A" with an lvalue which is smaller or equal to word size means allocate it
> either in ax or in dx.  Only with double word sized lvalue it means both ax 
> and
> dx.

The split result for 64bit code is non-intuitive - I would have expected
that "=A" (int64_t variable) always works.

We should issue a warning here - I suspect the broken variants never make
sense.

[Bug c/46619] gcc thinks line of code can be removed.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.11.23 14:30:25
 CC||hjl.tools at gmail dot com
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-11-23 14:30:25 
UTC ---
Do you have a run-time testcase?

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2010-11-23 
14:26:53 UTC ---
Looks just like bogus inline asm.  For rdtsc which sets 32-bits in %eax and
32-bits in %edx, for 32-bit code you want "=A" (long_long_variable) and
for 64-bit code you need "=a" (one_int_variable), "=d" (another_int_variable)
Otherwise you are lying on what the insn does.
"=A" with an lvalue which is smaller or equal to word size means allocate it
either in ax or in dx.  Only with double word sized lvalue it means both ax and
dx.

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.3.4
   Target Milestone|4.5.2   |4.4.6
Summary|[4.5/4.6 Regression]|[4.4/4.5/4.6 Regression]
   |Miscompiles computed goto   |Miscompiles computed goto

[Bug rtl-optimization/46598] [4.5/4.6 Regression] Miscompiles computed goto

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work|4.3.4   |
   Target Milestone|4.4.6   |4.5.2
Summary|[4.4/4.5/4.6 Regression]|[4.5/4.6 Regression]
   |Miscompiles computed goto   |Miscompiles computed goto

--- Comment #8 from Andrew Pinski  2010-11-23 
14:21:29 UTC ---
I think this might be related to PR 46164.

[Bug rtl-optimization/46598] [4.4/4.5/4.6 Regression] Miscompiles computed goto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
  Known to work||4.3.4
   Target Milestone|4.5.2   |4.4.6
Summary|[4.5/4.6 Regression]|[4.4/4.5/4.6 Regression]
   |Miscompiles computed goto   |Miscompiles computed goto

--- Comment #7 from Richard Guenther  2010-11-23 
14:18:40 UTC ---
Works with 4.3, so I suspect an IRA issue instead of an alias-improvement one
(which probably triggered it only on the non-reduced testcase).

[Bug rtl-optimization/46598] [4.5/4.6 Regression] Miscompiles computed goto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 AssignedTo|rguenth at gcc dot gnu.org  |unassigned at gcc dot
   ||gnu.org

--- Comment #6 from Richard Guenther  2010-11-23 
14:15:33 UTC ---
Making havege_hardtick long long doesn't solve the problem.  Now we have

(insn 23 22 26 3 pr46598_0.i:20 (parallel [
(set (reg:DI 1 dx)
(asm_operands/v:DI ("rdtsc") ("=A") 0 []
 []
 [] pr46598_0.i:36))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
]) -1 (nil))

with -m32 we get (reg:DI 0 ax) instead which is ok.  With int havege_hardtick
it's (reg:SI 1 dx) again.

This is not really my area of expertise.  Eh.

Reproducible in a similar way on trunk.

[Bug rtl-optimization/46598] [4.5/4.6 Regression] Miscompiles computed goto

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2010-11-23 
14:11:33 UTC ---
Even smaller testcase:

static int havege_bigarray [0x10 + 16384];
static int andpt = 0;
static volatile int *havege_pwalk = 0;
static int PT = 0;
static int PT2 = 0;
void collect_ndrand(int xxx)
{
   static const int jumps[] = { &&loop40-&&loop40 };
   volatile int *const RESULT = havege_bigarray;
   volatile int *Pt0, *Pt1, *Pt2, *Pt3;
   int i, pt, havege_hardtick;
   i = 0;
   goto loop00;

loop40:
  pt = (PT >> 18) & 7;
  PT = PT & andpt;

  __asm__ __volatile__("rdtsc":"=A"(havege_hardtick));

  Pt0 = &havege_pwalk[PT];
  Pt1 = &havege_pwalk[PT2];
  Pt2 = &havege_pwalk[PT ^ 1];
  Pt3 = &havege_pwalk[PT2 ^ 4];

  RESULT[i++] ^= *Pt0;
  RESULT[i++] ^= *Pt1;
  RESULT[i++] ^= *Pt2;
  RESULT[i++] ^= *Pt3;

  PT = (((RESULT[(i - 8) ^ pt] ^ havege_pwalk[PT ^ pt ^ 7])) &
(0xffef)) ^ ((PT2 ^ 0x10) & 0x10);
loop00:
   if (i < 0x10) goto *(&&loop40+jumps[xxx]);
}

which shows, hah:

collect_ndrand:
.LFB0:
.cfi_startproc
movlPT(%rip), %edx
movl$havege_bigarray, %eax
...

#APP
# 19 "pr46598_0.i" 1
rdtsc
# 0 "" 2
#NO_APP
movl(%rax), %esi


Same thing after regalloc:

(insn 23 22 26 3 pr46598_0.i:19 (parallel [
(set (reg:SI 1 dx)
(asm_operands/v:SI ("rdtsc") ("=A") 0 []
 []
 [] pr46598_0.i:35))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
]) -1 (nil))

of course the output is now completely unused, still "=A" should have
clobbered both ax and dx.

[Bug middle-end/46500] target.h includes tm.h

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

   Keywords||patch
   Severity|normal  |major

--- Comment #1 from Jorn Wolfgang Rennecke  
2010-11-23 13:59:25 UTC ---
The conclusion of the previous discussion about the inappropriateness of
target hooks taking target-dependent types like CUMULATIVE_ARGS or
CUMULATIVE_ARGS * was to convert to void * after initial hookization:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02607.html

I have posted a patch that does just that:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01769.html
but in the parallel discussion on the GCC mailing list there was now
resistance against using void pointers and casts in general, as can be
seen in the replies to this message:
http://gcc.gnu.org/ml/gcc/2010-11/msg00385.html

Nathan Froyd, who had before vigorously propagated the offending hooks, now
proposed to put the target-dependent function pointers in a place outside
of targetm for a C++ based solution:
http://gcc.gnu.org/ml/gcc/2010-11/msg00413.html

In response to this, I've posted a patch proposal that moved the offending
hooks out of targetm into a separate vector that is not needed by
target-independent code:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01810.html

I also noted that this patch, although conceptually very simple, was
largish because of all the target hook sites changed.  I proposed a
strategy how have a set of smaller patches by first making the hooks
easier to move around:
http://gcc.gnu.org/ml/gcc/2010-11/msg00455.html
, but that was met with disapproval.
One thing that came out of this discussion, though, was an apparent
agreement that casts would be acceptable if kept in a few small functions
that implement type conversions, as long as the bulk of the code was
type-safe.  Although the initial proposal missed the point of defining
a target-independent type, we eventually got something that provides
type-safety hook using code using a target-independent type:
http://gcc.gnu.org/ml/gcc/2010-11/msg00479.html

I then posted an update of the first (void * based) patch that
encapsulated the void * in a struct or union:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01994.html

I noted that a problem with the patch was its sheer size, which might
make it hard to get all of it reviewed, so I also posted a variant with
the target-independent / dependent changes separated, using a bit of
extra Makefile logic and fall-back code in target.h so that un-converted
targets could continue to function for a transitory period.
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02284.html

So, to summarize, I made two alternative proposals how to solve the problem:
- Alternative 1:
  Change the hooks so that they are suitable for a target-independent hook
  vector.
  We can do this either in one mega-patch if we get a hero reviewer:
  http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01994.html
  or do the target-independent stuff first, and then review the target
  dependent code either one-by-one or in group(s):
  http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02284.html
- Alternative 2:
  Move the hooks with target-dependent types out of targetm:
  http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01810.html