[Bug middle-end/4210] should not warning with dead code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210

Andrew Pinski  changed:

   What|Removed |Added

 CC||brooks at gcc dot gnu.org

--- Comment #24 from Andrew Pinski  ---
*** Bug 62074 has been marked as a duplicate of this bug. ***

[Bug c++/62074] "right shift count >= width of type" warning on dead branch in template code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62074

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of much older bug: 4210.

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

[Bug c++/62074] New: "right shift count >= width of type" warning on dead branch in template code

[brooks at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62074

Bug ID: 62074
   Summary: "right shift count >= width of type" warning on dead
branch in template code
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brooks at gcc dot gnu.org

Consider the following code:

--cut here-
typedef unsigned int uint32;

template 
int foo(uint32 x) {
  if (offset <= 1) {
return x << offset;
  } else {
// this branch is dead for offset = 0, but it still generates a warning
return (x << (offset - 1)) +
   (x >> (32 - offset));
  }
}

int main(int argc, char** argv) {
  return foo<0>(argc);
}
--cut here-

As noted in the comment, the "else" branch is dead code for the offset=0
instantiation, but (at r213772 on trunk) we still generate warnings for the
shifts that are out of range in the offset=0 case:

$ /home/bmoses/gcc-archive/213772/bin/g++ b16825807.cc -o b16825807
b16825807.cc: In instantiation of ‘int foo(uint32) [with unsigned int offset =
0u; uint32 = unsigned int]’:
b16825807.cc:15:21:   required from here
b16825807.cc:9:15: warning: left shift count >= width of type
 return (x << (offset - 1)) +
   ^
b16825807.cc:10:15: warning: right shift count >= width of type
(x >> (32 - offset));
   ^

(This is also present in the google/gcc-4_9 branch, and thus I suspect present
on upstream 4.9.1 although I have not yet tested it.)

Google bug: 16825807

[Bug c/62073] New: Segmentation fault with tree vectorize

[fei.yang0953 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62073

Bug ID: 62073
   Summary: Segmentation fault with tree vectorize
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fei.yang0953 at gmail dot com

1. Testcase generated by Csmith:

struct S0
{
int f7;
};
struct S0 g_50;
int g_70;
int g_76;

int foo (long long p_56, int * p_57)
{
int *l_77;
int l_101;

for (; g_70;)
{
int **l_78 = &l_77;
if (g_50.f7)
continue;
*l_78 = 0;
}
for (g_76 = 1; g_76 >= 0; g_76--)
{
int *l_90;
for (l_101 = 4; l_101 >= 0; l_101--)
if (l_101)
*l_90 = 0;
else
{
int **l_113 = &l_77;
*l_113 = p_57;
}
}

return *l_77;
}

2. Compile option and result:
supertux@localhost:~/test> ~/gcc-devel/install/bin/gcc -O1 foo.c -S
-ftree-vectorize
foo.c: In function ‘foo’:
foo.c:10:5: internal compiler error: Segmentation fault
 int foo (long long p_56, int * p_57)
 ^
0xbeaed9 crash_signal
../../trunk/gcc/toplev.c:337
0x773af6 flow_bb_inside_loop_p(loop const*, basic_block_def const*)
../../trunk/gcc/cfgloop.c:789
0xe40de0 vect_is_simple_reduction_1
../../trunk/gcc/tree-vect-loop.c:2324
0xe41bc6 vect_force_simple_reduction(_loop_vec_info*, gimple_statement_base*,
bool, bool*)
../../trunk/gcc/tree-vect-loop.c:2617
0xe45eee vect_analyze_scalar_cycles_1
../../trunk/gcc/tree-vect-loop.c:710
0xe4607c vect_analyze_scalar_cycles
../../trunk/gcc/tree-vect-loop.c:784
0xe475db vect_analyze_loop_2
../../trunk/gcc/tree-vect-loop.c:1665
0xe47b92 vect_analyze_loop(loop*)
../../trunk/gcc/tree-vect-loop.c:1864
0xe5b742 vectorize_loops()
../../trunk/gcc/tree-vectorizer.c:432
0xd687b0 execute
../../trunk/gcc/tree-ssa-loop.c:232
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

3. GCC version:
supertux@localhost:~/test> ~/gcc-devel/install/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/supertux/gcc-devel/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/supertux/gcc-devel/install/libexec/gcc/x86_64-suse-linux/4.10.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../trunk/configure --build=x86_64-suse-linux
--prefix=/home/supertux/gcc-devel/install --enable-languages=c
--enable-checking --disable-libmudflap --disable-libssp --with-cpu=generic
--disable-bootstrap
Thread model: posix
gcc version 4.10.0 20140809 (experimental) (GCC)

[Bug c++/62072] New: [4.9/4.10 regression] No SFINAE performed for function type

[lucdanton at free dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62072

Bug ID: 62072
   Summary: [4.9/4.10 regression] No SFINAE performed for function
type
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr

$ cat main.cpp
template struct tuple_size {};
template struct tuple_size: tuple_size {};

template
struct query {
static constexpr bool value = false;
};
template
struct query::type> {
static constexpr bool value = true;
};

int main()
{
// fine
static_assert( !query::value, "" );
static_assert( !query::value, "" );

// error: invalid use of incomplete type 'struct tuple_size'
static_assert( !query::value, "" );
}
$ g++-trunk --version
g++-trunk (GCC) 4.10.0 20140809 (experimental)
Copyright (C) 2014 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.

$ g++-trunk -std=c++11 main.cpp
main.cpp: In instantiation of 'struct tuple_size':
main.cpp:20:34:   required from here
main.cpp:2:29: error: invalid use of incomplete type 'struct
tuple_size'
 template struct tuple_size: tuple_size {};
 ^
main.cpp:2:29: note: declaration of 'struct tuple_size'

--

The testcase compiles fine against GCC 4.8.2 and 4.9.0.

[Bug target/61641] [4.9/4.10 Regression] undefined label in jump_table_data

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61641

John David Anglin  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #7 from John David Anglin  ---
The brtab markers break delete_related_insns().  On SOM, we need
to use ASM_OUTPUT_ADDR_DIFF_VEC to generate the markers, instead
of pa_reorg.

[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

[kugan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

--- Comment #11 from kugan at gcc dot gnu.org ---
I agree. I will post a patch to add this test-case and let the maintainers
decide if this is necessary.

[Bug c/62070] [4.10 Regression] ICE: verify_ssa failed

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62070

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|[GCC-4.10.0] ICE:   |[4.10 Regression] ICE:
   |verify_ssa failed   |verify_ssa failed

--- Comment #2 from Dominique d'Humieres  ---
Marked as a regression.

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068

--- Comment #7 from Andreas Schwab  ---
Please reread comment#1.

[Bug c/62070] [GCC-4.10.0] ICE: verify_ssa failed

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62070

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on x86_64-apple-darwin13 at revision r213759, revision r213645 is OK.

[Bug tree-optimization/62071] New: [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071

Bug ID: 62071
   Summary: [4.10 Regression] ICE: in before_dom_children, at
tree-ssa-pre.c:4411
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org

During Firefox -flto libxul link I get:

/var/tmp/mozilla-central/dom/events/TextComposition.cpp: In member function
‘_ZN7mozilla15TextComposition26CompositionEventDispatcher3RunEv.part.96’:
/var/tmp/mozilla-central/dom/events/TextComposition.cpp:217:0: internal
compiler error: in before_dom_children, at tree-ssa-pre.c:4411
 TextComposition::CompositionEventDispatcher::Run()
 ^
0xa7760b eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-pre.c:4411
0xdfd667 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:177
0xa74402 eliminate
../../gcc/gcc/tree-ssa-pre.c:4526
0xa74645 execute
../../gcc/gcc/tree-ssa-pre.c:4941
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[6]: *** [/tmp/cceU40zS.ltrans9.ltrans.o] Error 1
make[6]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: fatal error

Started with r213739.

I will try to reduce this next week.

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068

--- Comment #6 from David Binderman  ---
(In reply to Andreas Schwab from comment #2)
> There is no such requirement for va_start/va_end.

I am not sure what you mean here. I checked K & R 2
and va_start and va_end seem to be a matched pair
to me. 

AFAIK, each va_end is 121 with each va_start.

In practice, some systems might be able to handle one 
of them being missing, but the language requirement is
still there.

Unless you know different ?

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068

--- Comment #5 from Tom Tromey  ---
(In reply to Andreas Schwab from comment #4)
> varargs isn't stdargs.

Doh.  Thanks.

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068

--- Comment #4 from Andreas Schwab  ---
varargs isn't stdargs.

[Bug c/62070] New: [GCC-4.10.0] ICE: verify_ssa failed

[sabrinadfs at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62070

Bug ID: 62070
   Summary: [GCC-4.10.0] ICE: verify_ssa failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sabrinadfs at gmail dot com

GCC-4.10.0 (trunk)
x86_64-apple-darwin11.4.2

Running the following test:
make -s -C gcc check-gcc RUNTESTFLAGS="dg.exp=pr47684.c
--target_board=unix/-O3/-fno-tree-vectorize"

GCC throw an ICE:

/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:
In function 'foo':
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
error: no immediate_use list
for SSA_NAME: _16 in statement:
_13 = PHI 
PHI argument
_16
for PHI node
_13 = PHI 
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
internal compiler error: verify_ssa failed

/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)
compiler exited with status 1
output is:
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:
In function 'foo':
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
error: no immediate_use list
for SSA_NAME: _16 in statement:
_13 = PHI 
PHI argument
_16
for PHI node
_13 = PHI 
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
internal compiler error: verify_ssa failed

/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)

FAIL: gcc.dg/pr47684.c (internal compiler error)
FAIL: gcc.dg/pr47684.c (test for excess errors)
Excess errors:
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
error: no immediate_use list
for SSA_NAME: _16 in statement:
_13 = PHI 
PHI argument
_16
for PHI node
_13 = PHI 
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
internal compiler error: verify_ssa failed
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr47684.c:10:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)


Can anyone confirm this bug?


Thanks,
Sabrina Souto.

[Bug c/62069] New: ICE: in int_cst_value, at tree.c:10625

[sabrinadfs at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62069

Bug ID: 62069
   Summary: ICE: in int_cst_value, at tree.c:10625
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sabrinadfs at gmail dot com

GCC-4.10.0 (trunk)
x86_64-apple-darwin11.4.2

Running the following test:
make -s -C gcc check-gcc RUNTESTFLAGS="dg.exp=20090922-1.c
--target_board=unix/-fcheck-data-deps"

GCC throw an ICE:

/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/20090922-1.c:
In function 'test':
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: in int_cst_value, at tree.c:10625

/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)
compiler exited with status 1
output is:
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/20090922-1.c:
In function 'test':
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: in int_cst_value, at tree.c:10625

/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)

FAIL: gcc.dg/20090922-1.c (internal compiler error)
FAIL: gcc.dg/20090922-1.c (test for excess errors)
Excess errors:
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: in int_cst_value, at tree.c:10625
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)


Can anyone confirm this bug?


Thanks,
Sabrina Souto.

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068

--- Comment #3 from Tom Tromey  ---
It was documented that way on some systems.
Eg: http://www.cs.rit.edu/~hpb/Man/_Man_SunOS_4.1.3_html/html3/varargs.3.html
Perhaps that isn't operative language any more;
I guess I'm mildly curious to know.

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068

--- Comment #2 from Andreas Schwab  ---
There is no such requirement for va_start/va_end.  You are probably thinking of
pthread_cleanup_push/pop.

[Bug rtl-optimization/61641] [4.9/4.10 Regression] undefined label in jump_table_data

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61641

--- Comment #6 from John David Anglin  ---
The patch does what it's supposed to but it's not right:

.LVL58:
comib,<> 0,%r28,.L70
nop
.L74:
.L80:
.begin_brtab
.word .L73-.L80
.word .L81-.L80
.word .L74-.L80
.word .L84-.L80
.word .L74-.L80
.word .L74-.L80
.word .L74-.L80
.word .L72-.L80
.end_brtab
.L72:
.LBE104:
.LBE103:
.LBB105:
.LBB106:
.loc 2 228 0
ldi 3,%r28

The branch table is in the text section.  It appears from the above
that the execution flow can drop into the branch table.  So, either
removal of the associated casesi insn was wrong or the branch table
needs to be removed when the table label is removed.

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #1 from Tom Tromey  ---
I thought va_start and va_end could expand to anything,
including code to introduce and close a block, so they
needed to be lexically paired.
This means that the fix here would have to rewrite
the logic in the function a little bit.

[Bug libgcj/62068] New: libjava/prims.cc:807: possible missing call to va_end ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068

Bug ID: 62068
   Summary: libjava/prims.cc:807: possible missing call to va_end
?
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libgcj
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

[trunk/libjava/prims.cc:807]: (error) va_list 'args' was opened but not closed
by va_end().

  for (int i = 0; i < dimensions; ++i)
{
  jint size = va_arg (args, jint);
  if (size < 0)
throw new java::lang::NegativeArraySizeException;

Suggest add call to va_end just before throw.

[Bug lto/62067] New: lto-lang.c:549: too many calls to va_end on some code paths ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62067

Bug ID: 62067
   Summary: lto-lang.c:549: too many calls to va_end on some code
paths ?
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

[trunk/gcc/lto/lto-lang.c:549]: (error) va_list 'list' used before va_start()
was called.

 egress:
  builtin_types[def] = t;
  va_end (list);

For function def_fn_type, there are some code paths
where va_end is called twice.

Suggest code rework. If that means removing the goto statement,
even better.

[Bug target/62066] New: config/arm/arm.c:25298: possible missing call to va_end ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62066

Bug ID: 62066
   Summary: config/arm/arm.c:25298: possible missing call to
va_end ?
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

[trunk/gcc/config/arm/arm.c:25298]: (error) va_list 'ap' was opened but not
closed by va_end().

case NEON_ARG_MEMORY:
  /* Check if expand failed.  */
  if (op[argc] == const0_rtx)
return 0;

Suggest add missing call to va_end just before return.

[Bug ada/62065] New: ada/sysdep.c:868: possible coding error ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62065

Bug ID: 62065
   Summary: ada/sysdep.c:868: possible coding error ?
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

[trunk/gcc/ada/sysdep.c:868] -> [trunk/gcc/ada/sysdep.c:869]: (performance)
Variable 'tz_end' is reassigned a value before the old one has been used.

Normally, I wouldn't bother with this kind of message, but have
a look at this code

/* The format of the data contained in TIMEZONE is N::U:S:E where N is the
   name of the time zone, U are the minutes difference from UTC, S is the
   start of DST in mmddhh and E is the end of DST in mmddhh. Extracting
   the value of U involves setting two pointers, one at the beginning and
   one at the end of the value. The end pointer is then set to null in
   order to delimit a string slice for atol to process. */

tz_start = index (tz_str, ':') + 2;
tz_end = index (tz_start, ':');
tz_end = '\0';

Maybe

/* The format of the data contained in TIMEZONE is N::U:S:E where N is the
   name of the time zone, U are the minutes difference from UTC, S is the
   start of DST in mmddhh and E is the end of DST in mmddhh. Extracting
   the value of U involves setting two pointers, one at the beginning and
   one at the end of the value. The end pointer is then set to null in
   order to delimit a string slice for atol to process. */

tz_start = index (tz_str, ':') + 2;
tz_end = index (tz_start, ':');
*tz_end = '\0';

was intended ?

[Bug c++/62064] Private inheritance and conversion function id in class member access

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62064

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Rejected even if ::A is used everywhere, which should definitely be valid as it
doesn't go through the private "access path" in the base class.

Same behaviour back to at least GCC 4.3

[Bug testsuite/62060] g++.dg/tsan/cond_race.C triggers heap-use-after-free

[tetra2005 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060

Yuri Gribov  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Yuri Gribov  ---
Also added Jakub. Looks like LLVM and GCC use orthogonal approaches to deflake
TSan tests: GCC does this in source code
(https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI) whereas
LLVM chose to go with retrying testrunner
(http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/218813.html).

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850

--- Comment #34 from Tom Tromey  ---
Created attachment 33277
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33277&action=edit
initial patch

This is my current patch.  I'm uploading it for safekeeping
as I probably won't be working on this in the near future.

Note that as mentioned in the comments, this doesn't pass
the sparse validation suite.  So, it needs some work...
feel free to take it over if you are so moved.  A good
chunk of it should still be relevant even with the needed
updates.

[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers

[dodji at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861

Dodji Seketeli  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org
 Resolution|FIXED   |DUPLICATE

--- Comment #8 from Dodji Seketeli  ---
Hello,

I was on the road when this patch was submitted so I missed it.  Sorry.

It looks too like this issue is related to PR61817.  I even sent a patch for
this at http://comments.gmane.org/gmane.comp.gcc.patches/316794 but then later
you sent your patch and it went in :-)

I think the initial patch I sent solves this issue as well.  Both of our
patches have a something common:  they make builtin_macro() take an additional
parameter that is the location of the expansion point of the built-in macro we
are looking at.

One the differences in handling is that you set the token->src_loc to the
location of the expansion point of the built-in macro; but then normally, the
convention is that that token->src_loc must always be spelling location.  It
must never be a virtual location.  And the issue is that the location of the
expansion point can be a virtual location.  So we should not set token->src_loc
like that, I think.

But do not worry; I'll update the patch, test it, submit it and keep you guys
posted.

Cheers.

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

[Bug preprocessor/61817] Inconsistent location of tokens in the expansion list of a built-in macro

[dodji at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817

Dodji Seketeli  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #2 from Dodji Seketeli  ---
*** Bug 61861 has been marked as a duplicate of this bug. ***

[Bug preprocessor/61817] Inconsistent location of tokens in the expansion list of a built-in macro

[dodji at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817

--- Comment #1 from Dodji Seketeli  ---
I sent a patch for this at
http://comments.gmane.org/gmane.comp.gcc.patches/316794

[Bug testsuite/62060] g++.dg/tsan/cond_race.C triggers heap-use-after-free

[tetra2005 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060

Yuri Gribov  changed:

   What|Removed |Added

 CC||kcc at gcc dot gnu.org

--- Comment #4 from Yuri Gribov  ---
Adding kcc. It may make sense to detect testsuite changes during libsanitizer
merges.

[Bug c/57612] add builtin to assert that expression does not have side effects

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612

--- Comment #1 from Tom Tromey  ---
You can see the thread here:

http://patchwork.ozlabs.org/patch/343858/

My proposed patch didn't handle C++, which seems like
something it probably should do.

[Bug c++/62064] New: Private inheritance and conversion function id in class member access

[roger.ferrer at bsc dot es]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62064

Bug ID: 62064
   Summary: Private inheritance and conversion function id in
class member access
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roger.ferrer at bsc dot es

Hi,

the snippet below causes an access error in g++ 4.9.1 if the
conversion-function-id is referenced in a class-member access.

Intel C++ 14.0.2 and clang 3.3 accept it.

This problem can be worked around with -fno-access-control

(There is also some weirdness like 'struct A A::A' in the diagnostic messages
themselves, but I guess this would belong to another bug)

Should the code be ill-formed, then the "OK" case should be rejected as well.

// -- test.cc
struct A
{
typedef int some_type;
operator some_type();
};

struct  B : private A
{
typedef bool some_type;
void foo(B &r)
{
B *p;
B o;

A::operator A::some_type(); // OK

o.A::operator A::some_type(); // ERR
r.A::operator A::some_type(); // ERR
p->A::operator A::some_type(); // ERR
(*this).A::operator A::some_type(); // ERR
}
};
// -- end of test.cc

$ g++ --version
g++ (Debian 4.9.1-1) 4.9.1
$ g++ -c test.cc
test.cc: In member function ‘void B::foo(B&)’:
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
 {
 ^
test.cc:18:23: error: within this context
 o.A::operator A::some_type(); // ERR
   ^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
 typedef int some_type;
 ^
test.cc:18:26: error: within this context
 o.A::operator A::some_type(); // ERR
  ^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
 {
 ^
test.cc:19:23: error: within this context
 r.A::operator A::some_type(); // ERR
   ^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
 typedef int some_type;
 ^
test.cc:19:26: error: within this context
 r.A::operator A::some_type(); // ERR
  ^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
 {
 ^
test.cc:20:24: error: within this context
 p->A::operator A::some_type(); // ERR
^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
 typedef int some_type;
 ^
test.cc:20:27: error: within this context
 p->A::operator A::some_type(); // ERR
   ^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
 {
 ^
test.cc:21:29: error: within this context
 (*this).A::operator A::some_type(); // ERR
 ^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
 typedef int some_type;
 ^
test.cc:21:32: error: within this context
 (*this).A::operator A::some_type(); // ERR
^

Kind regards,

[Bug lto/62061] FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62061

--- Comment #2 from Uroš Bizjak  ---
This ICE can be triggered also on x86_64 Fedora 20 by passing
-fno-use-linker-plugin to testsuite flags:

make check-c++ RUNTESTFLAGS="--target_board=unix/-fno-use-linker-plugin
lto.exp=20100302_?.C"

FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto
-fabi-version=2 (internal compiler error)

[Bug c++/62063] g++ disregards template specialization and skips try/catch blocks

[ferenc.geczi at ericsson dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62063

--- Comment #2 from Ferenc Géczi  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Ferenc Géczi from comment #0)
> > Created attachment 33276 [details]
> > Source code for reproducing the reported issue
> > 
> > g++ disregards that template specialization might happen in a different
> > compilation unit. 
> 
> How is the compiler supposed to know that?
> 
> If you don't declare a specialization before it would be needed the compiler
> will not use it, and the program has undefined behaviour.
> 
> > For comparison, clang++ works as expected with -O0, without the
> > -fnon-callexceptions. 
> > Although it has the same the behavior with higher optimization levels.
> 
> That should tell you your expectation is wrong.

Indeed. (In reply to Jonathan Wakely from comment #1)
> (In reply to Ferenc Géczi from comment #0)
> > Created attachment 33276 [details]
> > Source code for reproducing the reported issue
> > 
> > g++ disregards that template specialization might happen in a different
> > compilation unit. 
> 
> How is the compiler supposed to know that?
> 
> If you don't declare a specialization before it would be needed the compiler
> will not use it, and the program has undefined behaviour.
> 
> > For comparison, clang++ works as expected with -O0, without the
> > -fnon-callexceptions. 
> > Although it has the same the behavior with higher optimization levels.
> 
> That should tell you your expectation is wrong.


Thank you for the quick reply, and I apologize for the false alarm.
Now I found it in the standard. You are absolutely right.

[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to kugan from comment #9)
> Incorrect warning is gone from the latest trunk build. VRP is now able to
> detect the correct range. This bug can now be closed.

Since it was probably fixed by accident, it will get unfixed by accident again.
If you don't add the testcase to the regression testsuite, this will happen
again:

https://gcc.gnu.org/wiki/HowToPrepareATestcase

If you add a testcase pointing to this PR, when it fails people can come back
here and read the discussion.

[Bug c++/62063] g++ disregards template specialization and skips try/catch blocks

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62063

--- Comment #1 from Jonathan Wakely  ---
(In reply to Ferenc Géczi from comment #0)
> Created attachment 33276 [details]
> Source code for reproducing the reported issue
> 
> g++ disregards that template specialization might happen in a different
> compilation unit. 

How is the compiler supposed to know that?

If you don't declare a specialization before it would be needed the compiler
will not use it, and the program has undefined behaviour.

> For comparison, clang++ works as expected with -O0, without the
> -fnon-callexceptions. 
> Although it has the same the behavior with higher optimization levels.

That should tell you your expectation is wrong.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901

Tom Tromey  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2014-08-08
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #6 from Tom Tromey  ---
I finally decided I would just reopen it.
If this is in error someone can easily close it again.
However please take note of the arguments in favor of
this being a bug in comment #5.  Thanks.

[Bug c++/62063] New: g++ disregards template specialization and skips try/catch blocks

[ferenc.geczi at ericsson dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62063

Bug ID: 62063
   Summary: g++ disregards template specialization and skips
try/catch blocks
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ferenc.geczi at ericsson dot com

Created attachment 33276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33276&action=edit
Source code for reproducing the reported issue

g++ disregards that template specialization might happen in a different
compilation unit. 

When compiling the attached example:

With -O0, it eliminates a catch block since it can instantiate a template
resulting a non throwing method, but disregards the specialization in which an
exception is actually thrown. Adding the '-fnon-call-exceptions' flag this
doesn't happen, but that flag shouldn't be required. 

With -O2 and -O3 even the try block gets eliminated, but in that case the
'-fnon-call-exceptions' doesn't help.

Please see attachment:

$ g++-4.9 -O0 -Wall Client.cpp Test.cpp main.cpp && ./a.out
Throwing exception
terminate called after throwing an instance of 'int'
Aborted

$ g++-4.9 -O0 -Wall -fnon-call-exceptions Client.cpp Test.cpp main.cpp &&
./a.out
Throwing exception
Exception handled!
END

$ g++-4.9 -O2 -Wall Client.cpp Test.cpp main.cpp && ./a.out
END

$ g++-4.9 -O3 -Wall Client.cpp Test.cpp main.cpp && ./a.out
END

$ g++-4.9 -O2 -Wall -fnon-call-exceptions Client.cpp Test.cpp main.cpp &&
./a.out
END

$ g++-4.9 -O3 -Wall -fnon-call-exceptions Client.cpp Test.cpp main.cpp &&
./a.out
END

For comparison, clang++ works as expected with -O0, without the
-fnon-callexceptions. 
Although it has the same the behavior with higher optimization levels.

[Bug tree-optimization/62035] [4.9/4.10 Regression] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035

--- Comment #5 from Marc Glisse  ---
(In reply to Richard Biener from comment #4)
> Marc, do you think it's possible to warn about such "return of local
> addresses"?

It doesn't seem easy. Here are some random thoughts.

At the exit of a block, we can say that the address of sv becomes nonsense, but
we don't have an easy way to replace it with 0 or undefined. The front end
doesn't track the leaking address. In the middle-end, we don't know anymore
that &sv is meaningless. AFAIK, in SSA, all variables live for the whole
function, the clobber only tells us that the content is nonsense, but the
address itself can perfectly well be reused to write new content. So we are
left with trying to warn about the read-after-clobber.

bb 10 ends with:
  # .MEM_37 = VDEF <.MEM_36>
  svD.22441 ={v} {CLOBBER};

bb 11 contains:
  # svp_2 = PHI <&svD.22441(10), svp_28(9)>
  # .MEM_3 = PHI <.MEM_37(10), .MEM_40(9)>
  if (_41 != 0)
goto ;

and bb 12 starts with:
  # VUSE <.MEM_3>
  _42 = *svp_2;

It is possible to see from this that _42 will receive garbage if we take the
path 10 -> 11 -> 12. But that's going to be an awfully specific piece of code
(and we don't want to start a walk of vdefs every time something is
dereferenced). I haven't yet studied the passes that track values in memory, so
I don't know if they can be adapted. I think there are lower hanging fruits
than this though.

[Bug testsuite/62060] g++.dg/tsan/cond_race.C triggers heap-use-after-free

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 33275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33275&action=edit
script to find differences

It seems we're missing more changes:
...
$ ./find.sh
--- compiler-rt/test/tsan/cond_race.cc2014-08-08 14:23:28.907916207 +0200
+++ devel/src/gcc/testsuite/g++.dg/tsan/cond_race.C2014-07-28
09:45:52.277091371 +0200
@@ -6,7 +5,6 @@
 #include 
 #include 
 #include 
-#include 

 struct Ctx {
   pthread_mutex_t m;
@@ -33,8 +31,6 @@
   while (!c->done)
 pthread_cond_wait(&c->c, &c->m);
   pthread_mutex_unlock(&c->m);
-  // w/o this sleep, it can be reported as use-after-free
-  sleep(1);
   delete c;
   pthread_join(th, 0);
 }
--- compiler-rt/test/tsan/thread_leak2.c2014-08-08 14:23:28.927916207 +0200
+++ devel/src/gcc/testsuite/c-c++-common/tsan/thread_leak2.c2014-07-28
09:45:52.185091367 +0200
@@ -1,16 +1,19 @@
+
 #include 
-#include 
+#include 

 void *Thread(void *x) {
   return 0;
 }

 int main() {
+  int i;
+  for (i = 0; i < 5; i++) {
   pthread_t t;
   pthread_create(&t, 0, Thread, 0);
-  pthread_detach(t);
-  printf("PASS\n");
+  }
+  sleep(1);
   return 0;
 }

--- compiler-rt/test/tsan/mutexset1.cc2014-08-08 14:23:28.919916207 +0200
+++ devel/src/gcc/testsuite/c-c++-common/tsan/mutexset1.c2014-07-28
16:48:55.546509594 +0200
@@ -16,7 +17,8 @@

 void *Thread2(void *x) {
   Global--;
-  return NULL;
+
 }

 int main() {
@@ -34,4 +29,12 @@
   pthread_join(t[0], NULL);
   pthread_join(t[1], NULL);
   pthread_mutex_destroy(&mtx);
+  return 0;
 }
+
--- compiler-rt/test/tsan/tls_race.cc2014-08-08 14:23:28.907916207 +0200
+++ devel/src/gcc/testsuite/c-c++-common/tsan/tls_race.c2014-07-28
09:45:52.185091367 +0200
@@ -1,10 +1,9 @@
+
 #include 
 #include 
-#include 

 void *Thread(void *a) {
-  sleep(1);
   *(int*)a = 43;
   return 0;
 }
--- compiler-rt/test/tsan/atomic_stack.cc2014-08-08 14:23:28.995916208
+0200
+++ devel/src/gcc/testsuite/c-c++-common/tsan/atomic_stack.c2014-07-28
09:45:52.185091367 +0200
@@ -21,9 +22,10 @@
   pthread_create(&t[1], NULL, Thread2, NULL);
   pthread_join(t[0], NULL);
   pthread_join(t[1], NULL);
+  return 0;
 }

[Bug c++/62062] Missed optimization: write ptr reloaded in each loop iteration

[petschy at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62062

--- Comment #3 from petschy at gmail dot com ---
(In reply to Andrew Pinski from comment #2)
> Your inline asm is broken.
How? In unaliased_storeb()? That's for only proving that the redundant
loads/stores are not an artifact of aliasing, and is not used by the functions
that write to int*'s.

[Bug c++/62062] Missed optimization: write ptr reloaded in each loop iteration

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62062

--- Comment #2 from Andrew Pinski  ---
Your inline asm is broken. 

This sounds like a missing partial store not being optimized. Not something we
do right now. Refernces are pointers really, syntax hides the semantics.

[Bug c++/62062] Missed optimization: write ptr reloaded in each loop iteration

[petschy at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62062

--- Comment #1 from petschy at gmail dot com ---
Created attachment 33274
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33274&action=edit
source

[Bug c++/62062] New: Missed optimization: write ptr reloaded in each loop iteration

[petschy at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62062

Bug ID: 62062
   Summary: Missed optimization: write ptr reloaded in each loop
iteration
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com

When developing a binary i/o lib, I ran into some performance degradation in
the writer functions. My investigation revealed that the write pointer was
loaded/stored in each loop iteration. Although this can be dodged by
hand-tuning the code via local variables kept in registers, the resulting code
is longer, less clear, harder to maintain, etc. 

For this report, I recompiled w/ 4.9.2, but earlier versions in 4.x give the
same results. The test box is an AMD FX w/ Debian Jessie.

gcc compiled from git commit f964b16:
g++-4.9.2 -v
Using built-in specs.
COLLECT_GCC=g++-4.9.2
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-4.9.2
Thread model: posix
gcc version 4.9.2 20140808 (prerelease) (GCC)

compiler/linker flags used:
g++-4.9.2 -c 20140725-reg_vs_mem.cpp -g -std=c++11 -Wall -Wextra -Werror
-Wundef -Wshadow -O3 -fno-tree-vectorize
g++-4.9.2 -o 20140725-reg_vs_mem 20140725-reg_vs_mem.o -g

Tried with less optimization, too, but made no difference.

-fno-tree-vectorize was used because otherwise the code generated for the
encoder functions used the vector registers, which resulted in serious code
size bloat and ~2-3x runtimes, opposed to the ~1.5x runtime increase due to the
redundant loads/stores.

For the tests, I made two versions for each function: one that expects a ptr
ref (baseline version), and another one that expects a buffer object (w/
beg/end ptrs for advanced functionality, which is not used here). As expected,
the same code is generated for these two.

I ruled out the aliasing rules first: I use int ptrs in this test, so that the
'char* aliases everything' rule is dodged. To prove my case:

write_run_char_ptr_ref() loads/stores the char ptr in each loop, since the
character written invalidates the pointer itself:
   0x00400570 <+0>: sub$0x1,%edx
   0x00400573 <+3>: js 0x40058d 
   0x00400575 <+5>: nopl   (%rax)
   0x00400578 <+8>: mov(%rdi),%rax  # loop beg, load ptr
   0x0040057b <+11>:sub$0x1,%edx
   0x0040057e <+14>:cmp$0x,%edx
   0x00400581 <+17>:lea0x1(%rax),%rcx
   0x00400585 <+21>:mov%rcx,(%rdi)  # store updated ptr
   0x00400588 <+24>:mov%sil,(%rax)
   0x0040058b <+27>:jne0x400578 
   0x0040058d <+29>:repz retq 

write_run_char_ptr_ref_unaliased() keeps the ptr in a register, but this was
achieved w/ some platform dependent asm trickery, see unaliased_storeb() [btw,
some platform independent builtin would be nice for this], I use this in the
production code, which writes bytes at the lowest level.
   0x00400590 <+0>: test   %edx,%edx
   0x00400592 <+2>: jle0x4005af

   0x00400594 <+4>: mov(%rdi),%rax   # load ptr
   0x00400597 <+7>: sub$0x1,%edx
   0x0040059a <+10>:lea0x1(%rax,%rdx,1),%rdx # end ptr
   0x0040059f <+15>:nop
   0x004005a0 <+16>:mov%sil,(%rax)   # loop body, no
ptr load/store
   0x004005a3 <+19>:add$0x1,%rax
   0x004005a7 <+23>:cmp%rdx,%rax
   0x004005aa <+26>:jne0x4005a0

   0x004005ac <+28>:mov%rax,(%rdi)   # store ptr after
the loop
   0x004005af <+31>:repz retq 

write_run_ptr_ref() uses int ptr, and the ptr is kept in a register for the
loop, without any trickery. The disassembly is the same as
write_run_char_ptr_ref_unaliased() above, except ints are written.
write_run_buf() is exactly the same. So far so good.

The next step is a variable length encoder, encode_ptr_ref(). This is not a
real working encoding, just for demonstration. Since the probabilities are
implied from the encoding lengths, the if conditions are peppered with
builtin_expect's. Again, the ptr ref and buf object versions are exactly the
same. However, I noticed that the ptr is written back multiple times, depending
on which 'if' becomes true. For the most likely case, it doesn't matter: only
one write is performed, but before the conditional jump. For the last two less
likely cases, two redundant writes are performed. Moreover, for the 3rd 'if'
block th

[Bug testsuite/62060] g++.dg/tsan/cond_race.C triggers heap-use-after-free

[chefmax at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060

--- Comment #2 from Maxim Ostapenko  ---
(In reply to vries from comment #1)
> Tentative patch:
> ...
> diff --git a/gcc/testsuite/g++.dg/tsan/cond_race.C
> b/gcc/testsuite/g++.dg/tsan/cond_race.C
> index a937614..90dfb19 100644
> --- a/gcc/testsuite/g++.dg/tsan/cond_race.C
> +++ b/gcc/testsuite/g++.dg/tsan/cond_race.C
> @@ -1,5 +1,5 @@
>  /* { dg-shouldfail "tsan" } */
> -/* { dg-output "ThreadSanitizer: data race.*" } */
> +/* { dg-output "ThreadSanitizer: (data race|heap-use-after-free).*" } */
>  /* { dg-output "pthread_cond_signal.*" } */
>  
>  #include 
> ...

This test was copied from LLVM compiler-rt testsuite. I see that compiler-rt
developers added sleep (1) right after pthread_mutex_unlock to avoid this
problem. Perhaps we should do the same?

diff --git a/gcc/testsuite/g++.dg/tsan/cond_race.C
b/gcc/testsuite/g++.dg/tsan/cond_race.C
index a937614..805465d 100644
--- a/gcc/testsuite/g++.dg/tsan/cond_race.C
+++ b/gcc/testsuite/g++.dg/tsan/cond_race.C
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 

 struct Ctx {
   pthread_mutex_t m;
@@ -31,6 +32,8 @@ int main() {
   while (!c->done)
 pthread_cond_wait(&c->c, &c->m);
   pthread_mutex_unlock(&c->m);
+  // w/o this sleep, it can be reported as use-after-free
+  sleep(1);
   delete c;
   pthread_join(th, 0);
 }

[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-08
 Ever confirmed|0   |1

[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #6 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00891.html

[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #4 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00891.html

[Bug lto/62061] FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62061

--- Comment #1 from Uroš Bizjak  ---
Created attachment 33273
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33273&action=edit
Object files

[Bug testsuite/62060] g++.dg/tsan/cond_race.C triggers heap-use-after-free

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chefmax at gcc dot gnu.org

--- Comment #1 from vries at gcc dot gnu.org ---
Tentative patch:
...
diff --git a/gcc/testsuite/g++.dg/tsan/cond_race.C
b/gcc/testsuite/g++.dg/tsan/cond_race.C
index a937614..90dfb19 100644
--- a/gcc/testsuite/g++.dg/tsan/cond_race.C
+++ b/gcc/testsuite/g++.dg/tsan/cond_race.C
@@ -1,5 +1,5 @@
 /* { dg-shouldfail "tsan" } */
-/* { dg-output "ThreadSanitizer: data race.*" } */
+/* { dg-output "ThreadSanitizer: (data race|heap-use-after-free).*" } */
 /* { dg-output "pthread_cond_signal.*" } */

 #include 
...

[Bug lto/62061] New: FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62061

Bug ID: 62061
   Summary: FAIL: g++.dg/lto/20100302
cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto
-fabi-version=2
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
Target: i686-pc-linux-gnu

Currently g++.dg/lto/20100302 ICEs in:

Executing on host: /home/uros/gcc-build/gcc/testsuite/g++/../../xg++
-B/home/uros/gcc-build/gcc/testsuite/g++/../../ cp_lto_20100302_0.o
cp_lto_20100302_1.o  -fno-diagnostics-show-caret -fdiagnostics-color=never 
-nostdinc++
-I/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/uros/gcc-svn/trunk/libstdc++-v3/libsupc++
-I/home/uros/gcc-svn/trunk/libstdc++-v3/include/backward
-I/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -flto
-fabi-version=2
-L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs 
-B/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs 
-L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs 
-m32  -o g++-dg-lto-20100302-01.exe

lto1: internal compiler error: in add_symbol_to_partition, at
lto/lto-partition.c:232
0x50a74f add_symbol_to_partition
../../gcc-svn/trunk/gcc/lto/lto-partition.c:232
0x50a34b add_references_to_partition
../../gcc-svn/trunk/gcc/lto/lto-partition.c:94
0x50a4a3 add_symbol_to_partition_1
../../gcc-svn/trunk/gcc/lto/lto-partition.c:168
0x50ab0e lto_balanced_map(int)
../../gcc-svn/trunk/gcc/lto/lto-partition.c:494
0x504b24 do_whole_program_analysis
../../gcc-svn/trunk/gcc/lto/lto.c:3271
0x504b24 lto_main()
../../gcc-svn/trunk/gcc/lto/lto.c:3425
Please submit a full bug report,
with preprocessed source if appropriate.

target is i686-linux-gnu GNU ld version 2.17.50.0.6-26.el5 20061020 (CENTOS 5).

[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

[kugan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kugan at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #9 from kugan at gcc dot gnu.org ---
Incorrect warning is gone from the latest trunk build. VRP is now able to
detect the correct range. This bug can now be closed.


Value ranges after VRP:

channel_8: [1, 1023]  EQUIVALENCES: { channel_10 } (1 elements)
channel_10: [1, 1024]
channel_15: [0, 1023]
.MEM_16: VARYING


Removing basic block 5
wait_reading_process_output ()
{
  int channel;
  int nfds;

  :

  :
  # channel_15 = PHI 
  foo (channel_15);
  channel_10 = channel_15 + 1;
  if (channel_10 != 1024)
goto ;
  else
goto ;

  :
  return 0;

}

[Bug lto/62032] FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Aug  8 10:21:12 2014
New Revision: 213755

URL: https://gcc.gnu.org/viewcvs?rev=213755&root=gcc&view=rev
Log:

PR lto/62032
* lto/lto-lang.c (lto_init): Switch mis-matched arguments.


Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c

[Bug c++/61341] internal compiler error: in tsubst, at cp/pt.c:11313

[trtrmitya at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61341

Dmitry  changed:

   What|Removed |Added

 CC||trtrmitya at gmail dot com

--- Comment #2 from Dmitry  ---
I confirm that this example program leads to internal compiler error for the
latest snapshots of gcc-4.8 and gcc-4.9
(tested on FreeBSD-10/STABLE with gcc built from ports collection)

[Bug testsuite/62060] New: g++.dg/tsan/cond_race.C triggers heap-use-after-free

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060

Bug ID: 62060
   Summary: g++.dg/tsan/cond_race.C triggers heap-use-after-free
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

When testing a gcc patch, I ran into this failure
...
-./gcc/testsuite/g++/g++.sum:PASS: g++.dg/tsan/cond_race.C   -O2  output
pattern test, ThreadSanitizer: data race.*pthread_cond_signal.*
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/tsan/cond_race.C   -O2  output
pattern test, is ==
...

I've run into the same failure before, here:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01758.html .

Also, I've noticed it here:
https://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00127.html .


The complete failure from the log is:
...
FAIL: g++.dg/tsan/cond_race.C   -O2  output pattern test, is ==
WARNING: ThreadSanitizer: heap-use-after-free (pid=5192)
  Read of size 8 at 0x7d18efc8 by thread T1:
#0 pthread_cond_signal src/libsanitizer/tsan/tsan_interceptors.cc:1011
(libtsan.so.0+0x00027794)
#1 thr(void*) src/gcc/testsuite/g++.dg/tsan/cond_race.C:20
(cond_race.exe+0x1033)

  Previous write of size 8 at 0x7d18efc8 by main thread:
#0 operator delete(void*) src/libsanitizer/tsan/tsan_interceptors.cc:583
(libtsan.so.0+0x00025ab9)
#1 main src/gcc/testsuite/g++.dg/tsan/cond_race.C:34
(cond_race.exe+0x0ea0)

  Location is heap block of size 96 at 0x7d18efa0 allocated by main thread:
#0 operator new(unsigned long)
src/libsanitizer/tsan/tsan_interceptors.cc:551 (libtsan.so.0+0x00025863)
#1 main src/gcc/testsuite/g++.dg/tsan/cond_race.C:25
(cond_race.exe+0x0e12)

  Thread T1 (tid=5200, running) created by main thread at:
#0 pthread_create src/libsanitizer/tsan/tsan_interceptors.cc:853
(libtsan.so.0+0x00026f54)
#1 main src/gcc/testsuite/g++.dg/tsan/cond_race.C:29
(cond_race.exe+0x0e5a)

SUMMARY: ThreadSanitizer: heap-use-after-free
src/gcc/testsuite/g++.dg/tsan/cond_race.C:20 thr(void*)
==
ThreadSanitizer: reported 1 warnings
, should match ThreadSanitizer: data race.*pthread_cond_signal.*
...

When compiling and running from the command line, the expected output is
produced:
...
WARNING: ThreadSanitizer: data race (pid=6294)
  Write of size 8 at 0x7d18efc8 by main thread:
#0 operator delete(void*) src/libsanitizer/tsan/tsan_interceptors.cc:583
(libtsan.so.0+0x00025ab9)
#1 main src/gcc/testsuite/g++.dg/tsan/cond_race.C:34
(cond_race.exe+0x0d00)

  Previous read of size 8 at 0x7d18efc8 by thread T1:
#0 pthread_cond_signal src/libsanitizer/tsan/tsan_interceptors.cc:1011
(libtsan.so.0+0x00027794)
#1 thr(void*) src/gcc/testsuite/g++.dg/tsan/cond_race.C:20
(cond_race.exe+0x0e93)

  Location is heap block of size 96 at 0x7d18efa0 allocated by main thread:
#0 operator new(unsigned long)
src/libsanitizer/tsan/tsan_interceptors.cc:551 (libtsan.so.0+0x00025863)
#1 main src/gcc/testsuite/g++.dg/tsan/cond_race.C:25
(cond_race.exe+0x0c72)

  Thread T1 (tid=6296, running) created by main thread at:
#0 pthread_create src/libsanitizer/tsan/tsan_interceptors.cc:853
(libtsan.so.0+0x00026f54)
#1 main src/gcc/testsuite/g++.dg/tsan/cond_race.C:29
(cond_race.exe+0x0cba)

SUMMARY: ThreadSanitizer: data race
src/gcc/testsuite/g++.dg/tsan/cond_race.C:34 main
...

So, it seems there is a data race between:
- the write from the delete at line 34, and
- the read from the pthread_cond_signal at line 20.

If the write comes first, we get the heap-use-after-free message. If the read
comes first, we get the data race message.

Tentatively setting component to testsuite.

[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.10.0
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/62053] [4.10 Regression] ICE: in remap_type_1, at tree-inline.c:540

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

[Bug tree-optimization/62053] [4.10 Regression] ICE: in remap_type_1, at tree-inline.c:540

[aivchenk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053

Alexander Ivchenko  changed:

   What|Removed |Added

 CC||aivchenk at gmail dot com

--- Comment #2 from Alexander Ivchenko  ---
Stuck on the same error when building Android.

[Bug tree-optimization/62035] [4.9/4.10 Regression] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035

Richard Biener  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Marc, do you think it's possible to warn about such "return of local
addresses"?

[Bug tree-optimization/62035] [4.9/4.10 Regression] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Richard Biener  ---
I can reproduce the bad assembly with -O -g -fwrapv -fstack-protector -fPIC
--param ssp-buffer-size=4 --param ssp-buffer-size=4

The only dead store deleted in modperl_env_table_populate is

  Deleted dead store 'sv = sv.5_31;

and that's ok because we have a clobber of 'sv' in this path.

  :
  _29 = _22->val;
  sv.5_31 = Perl_newSVpv (my_perl_7(D), _29, 0);
  sv = sv.5_31;
  _33 = _22->key;
  Perl_hv_common_key_len (my_perl_7(D), hv_10, _33, klen_26, 36, sv.5_31, 0);
  _35 = _22->key;
  Perl_sv_magic (my_perl_7(D), sv.5_31, 0B, 101, _35, klen_26);
  # DEBUG svp => &sv
  sv ={v} {CLOBBER};

  :
  # svp_2 = PHI <&sv(7), svp_28(6)>
  # DEBUG svp => svp_2
  _41 = my_perl_7(D)->Itainting;
  if (_41 != 0)
goto ;
  else
goto ;

  :
  _42 = *svp_2;
  Perl_sv_magic (my_perl_7(D), _42, 0B, 116, 0B, 0);

but a use-after-free here through *svp_2.  Prettified preprocessed souce
looks like

SV **svp = ((SV**) Perl_hv_common_key_len(my_perl,
(hv),(elts[i].key),(klen),((0)) ? (0x20 | 0x10) : 0x20,((void *)0),0));
if (svp) { 
  Perl_sv_setpv(my_perl, *svp,elts[i].val);
} else { 
  SV *sv = Perl_newSVpv(my_perl, elts[i].val,0);
  (void)((SV**) Perl_hv_common_key_len(my_perl,
(hv),(elts[i].key),(klen),(0x04|0x20),(sv),((0;
  Perl_sv_magic(my_perl, sv,(SV *)((void *)0),'e',elts[i].key,klen);
  svp = &sv;
} 
if (0) modperl_trace(__func__, "$ENV{%s} = \"%s\";", elts[i].key,
elts[i].val);
(void)({ 
  if(((my_perl->Itainting))){Perl_sv_magic(my_perl, (*svp),((void
*)0),'t',((void *)0),0);

so 'sv' is declared inside the 'else' but you make its address escape
through the 'svp' variable declared in the outer block.

Invalid.

A fix is to move the declaration of SV *sv up one block.

[Bug c/62059] New: signed integer overflow in diagnostic.c adjust_line

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62059

Bug ID: 62059
   Summary: signed integer overflow in diagnostic.c adjust_line
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com

Created attachment 33272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33272&action=edit
Used by test case

// gcc 4.9.1
// ../../gcc-4.9.1/gcc/diagnostic.c:274:42: runtime error: signed integer
overflow: 2147483646 - -4 cannot be represented in type 'int'
// installparse.l is a one line file containing "%{%}" I am attaching it anyway
// offending instruction in diagnostic.c function adjust_line is
// right_margin = max_width - right_margin;
// where max_width==INT_MAX and right_margin is negative (here is -4) 
# 1 "installparse.l"
static foo(void);
void bar(void)
{
 foo();
}

I am attaching installparse.l

[Bug c/62058] New: Undefined behaviour in tree-data-ref.c with options -O1 -ftree-loop-vectorize

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62058

Bug ID: 62058
   Summary: Undefined behaviour in tree-data-ref.c with options
-O1 -ftree-loop-vectorize
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com

/* from testsuite p60183.c */
/* gcc 4.9.1 -S -O1 -ftree-loop-vectorize */
/* ../../gcc-4.9.1/gcc/tree-data-ref.c:2423:16: runtime error: signed integer
overflow: 65536 * -65536 cannot be represented in type 'int' */
/* ../../gcc-4.9.1/gcc/tree-data-ref.c:2334:38: runtime error: signed integer
overflow: 1073741824 + 1073741824 cannot be represented in type 'int' */
/* ../../gcc-4.9.1/gcc/tree-data-ref.c:2425:16: runtime error: negation of
-2147483648 (INT_MIN) cannot be represented in type 'int'; cast to an unsigned
type to negate this value to itself */
/* ../../gcc-4.9.1/gcc/tree-data-ref.c:2424:16: runtime error: negation of
-2147483648 (INT_MIN) cannot be represented in type 'int'; cast to an unsigned
type to negate this value to itself */
/* on x86-64 from testsuite pr60183.c */
unsigned char c[0x30001] = { 1 };
int j = 0; /* independent of the j initialization value */ 

static void
foo (unsigned long *x, unsigned char *y)
{
  int i;
  unsigned long w = x[0];
  for (i = 0; i < j; i++)
{
  w += *y;
  y += 0x1;
  w += *y;
}
  x[1] = w;
}

void
bar (unsigned long *x)
{
  foo (x, c);
}

[Bug tree-optimization/62053] [4.10 Regression] ICE: in remap_type_1, at tree-inline.c:540

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/62055] missed optimization: recognize fnabs (FP negative absolute value) (x86-64)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62055

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-08
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed also with -ffast-math.

[Bug target/51726] LTO and attribute 'selectany'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51726

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
  Component|lto |target

--- Comment #4 from Richard Biener  ---
On trunk the backend has to use varpool_node::get (decl)->get_constructor ().

But seriously the backend should process the attribute once at compile-time
and then discard it rather than trying to re-do the job at WPA/LTRANS time.

That is, _not_ do this in i386_pe_encode_section_info which is way too late
but instead directly in ix86_handle_selectany_attribute so LTO can see
the decl is one-only (and also the linker is informed correctly).

Still completely a backend bug.  IMHO as soon as it's not necessary to
retain the attribute on the decl it's a sign of a good implementation.

[Bug c++/62057] __builtin_offsetof works but std::offsetof doesn't

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62057

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Offsetof is always a macro so it is never used with a namespace.

[Bug c++/62057] New: __builtin_offsetof works but std::offsetof doesn't

[igodard at pacbell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62057

Bug ID: 62057
   Summary: __builtin_offsetof works but std::offsetof doesn't
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igodard at pacbell dot net

This code:
#include

class A {
public:
int i;
};

int main() {
int x = __builtin_offsetof(A, i);
int j = std::offsetof(A, i);
}

gets you this:

s6:~/ootbc/genAsm$ gcc foo.cc
foo.cc: In function âint main()â:
foo.cc:10:16: error: expected unqualified-id before â__builtin_offsetofâ
foo.cc:10:16: error: expected â,â or â;â before â__builtin_offsetofâ


Version:
s6:~/ootbc/genAsm$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc/4.6.4/libexec/gcc/x86_64-unknown-linux-gnu/4.6.4/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6.4/configure --prefix=/usr/local/gcc/4.6.4
--libdir=/usr/local/gcc/4.6.4/lib64 --enable-languages=c,c++
Thread model: posix
gcc version 4.6.4 (GCC)