[Bug c++/56493] Performance regression in google dense hashmap

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||ktietz at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
The reduced testcase has been slowed down by r176072, aka PR45437.  If you want
to speed it up by source code changes, q += (unsigned int) f(i); would do
instead of q += f(i);, or you can do q = q + f(i);.
Before that bugfix, the C++ FE produced
(void) (q = (int) ((unsigned int) f (i) + (unsigned int) q))
which is generally wrong (say if q was addressable and f could modify it),
after it we generate
(void) (q = TARGET_EXPR ;, (int) ((long unsigned int) q +
D.2078);)
The question is why the narrowing of the operation (to be done on unsigned int
rather than long unsigned int) isn't performed here, that is something we do
right now solely in the FE.  There are PRs (PR45397 and PR47477) about lack of
type demotion (and promotion) on GIMPLE, but don't know what the current state
of that is.

[Bug c++/57618] OpenMP atomic read and write are not sequentially consistent

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
No idea where you got that #pragma omp atomic should be sequentially
consistent, it is relaxed.  OpenMP 4.0 introduces seq_cst clause on all the
#pragma omp atomic {,update,read,write,capture} variants that makes it
sequentially consistent.

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Simon Richter from comment #4)
> Testcase is simple:
> 
> $ cat tt.cpp
> 
> void bar(int baz) { }
> 
> $ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp 
> 
> $ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp 
> tt.cpp:1:6: error: unused parameter ‘baz’ [-Werror=unused-parameter]
>  void bar(int baz) { }
>   ^
> cc1plus: all warnings being treated as errors

There is a bug in the logic of the autogenerated code:

  if (!opts_set->x_warn_unused_parameter && (opts->x_warn_unused &&
opts->x_extra_warnings))
  handle_generated_option (opts, opts_set,
   OPT_Wunused_parameter, NULL, value,
   lang_mask, kind, loc, handlers, dc);

When processing -Wno-unused, opts->x_warn_unused is false, so we don't turn off
OPT_Wunused_parameter. I think the generated code should be:


  if (!opts_set->x_warn_unused_parameter && opts->x_extra_warnings)

for case OPT_Wunused and


  if (!opts_set->x_warn_unused_parameter && opts->x_warn_unused)

for the case OPT_Wextra. So optc-gen.awk needs adjusting. Let me see if I can
find time to do this in the coming weeks/months, but if anyone wants to
investigate how to fix it, please go ahead.

I think this is a different bug than the -Wno-tabs, since that is not handled
by the autogenerated code.

[Bug c++/57622] New: -W -Wall -Werror -Wno-unused gives Wunused-parameter warning

[manu at gcc dot gnu.org]

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

Bug ID: 57622
   Summary: -W -Wall -Werror -Wno-unused gives Wunused-parameter
warning
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, manu at gcc dot gnu.org,
Simon.Richter at hogyros dot de
Depends on: 52347

+++ This bug was initially created as a clone of Bug #52347 +++

Testcase is simple:

$ cat tt.cpp

void bar(int baz) { }

$ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp 

$ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp 
tt.cpp:1:6: error: unused parameter ‘baz’ [-Werror=unused-parameter]
 void bar(int baz) { }
  ^
cc1plus: all warnings being treated as errors

There is a bug in the logic of the autogenerated code:

  if (!opts_set->x_warn_unused_parameter && (opts->x_warn_unused &&
opts->x_extra_warnings))
  handle_generated_option (opts, opts_set,
   OPT_Wunused_parameter, NULL, value,
   lang_mask, kind, loc, handlers, dc);

When processing -Wno-unused, opts->x_warn_unused is false, so we don't turn off
OPT_Wunused_parameter. I think the generated code should be:


  if (!opts_set->x_warn_unused_parameter && opts->x_extra_warnings)

for case OPT_Wunused and


  if (!opts_set->x_warn_unused_parameter && opts->x_warn_unused)

for the case OPT_Wextra. So optc-gen.awk needs adjusting. Let me see if I can
find time to do this in the coming weeks/months, but if anyone wants to
investigate how to fix it, please go ahead.

I think this is a different bug than the -Wno-tabs, since that is not handled
by the autogenerated code.

[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-15
 CC|burnus at gcc dot gnu.org  |
 Ever confirmed|0   |1

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC|manu at gcc dot gnu.org|
 Blocks|57622   |

--- Comment #6 from Manuel López-Ibáñez  ---
I created bug 52347 to track the autogenerated code issue. This bug should be
fixed if Fortran's -Wall is moved to the autogenerated method of handling group
options (see options.texi)

[Bug c++/57620] Phantom terminator confuses raw string literal parsing.

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
There seems to be more issues in the raw string literal lexing.  E.g.
const char *s = R"a??/(x)a??/";
should be I think handled the same as
const char *s = "x";
with -std=c++11 or -std=gnu++11 -trigraphs, but is not.  We only revert the
phase 1 and phase 2 transformations in between ( and ), but they should
actually be reverted everywhere between the " after R and the final ".

[Bug middle-end/56977] gcc -Og incorrectly warns about 'constant zero length parameter'

[harald at gigawatt dot nl]

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

--- Comment #2 from Harald van Dijk  ---
Inlining isn't relevant:

__attribute__((__error__("error"))) void error ();

void f (int i) {
  if (__builtin_constant_p (i)) {
error ();
  }
}

fails the same way. But it doesn't fail with all uses of __builtin_constant_p:

__attribute__((__error__("error"))) void error ();

void f () {
  int g ();
  if (!__builtin_constant_p (1)) {
error ();
  }
  if (__builtin_constant_p (g ())) {
error ();
  }
}

compiles without any problems.

[Bug testsuite/57606] Failure in testing stage 3 of gcc-4.7.2

[ExtraLeveLInSoftware at ntlworld dot com]

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

--- Comment #1 from Ellis N. Thomas  
---
On further consideration of the Bug 57606 reported for host_gnatmake and
host_gnatchop produced in run_acats, the entire approach seems flawed.

It uses dirname to extract the directory name from the full name obtained from
"type -p" to prefix a directory name to PATH for each of host_gnatmake and
host_gnatchop.
Since the details obtained for gnatmake (and gnatchop) are already what the
shell would use, there seems little point in forcing this directory name to the
head of PATH, or even to use the easier approach of simply executing the full
name just returned by "type -p".
Of course, gnatmake will lead to calls of other tools, which might be
influenced
by the adapted PATH, but if control is needed over which version(s) are called
then greater care needs to be taken anyway.

Ellis N. Thomas

[Bug fortran/56136] [OOP] ICE on lhs-reallocation of an object with overloaded (elemental) assignment operator

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #3 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #2)
> This PR seems to have been fixed between revisions 200062 and 200078
> (r200069?).

Yes it is the same bug as PR49074.
The ingredients are:
 - typebound assignment (though I'm not sure it is necessary),
 - elemental procedure with polymorphic dummies,
 - need for a temporary.

[Bug fortran/41827] [Cleanup] Remove SET_EXPR_LOCATION in gfc_trans_code

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Is this PR another WONTFIX?

[Bug fortran/44978] extended derived types are resolved more than once

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-15
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Still present at revision 200122.

[Bug fortran/47915] Type declaration: Recursive specification expression not detected.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-15
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
STill present at revision 200122.

[Bug libstdc++/57619] [4.8/4.9 Regression] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |4.8.1
Summary|std::unordered_map and  |[4.8/4.9 Regression]
   |std::unordered_multimap::in |std::unordered_map and
   |sert invoking std::pair |std::unordered_multimap::in
   |move constructor|sert invoking std::pair
   ||move constructor

--- Comment #4 from Jonathan Wakely  ---
That was quick, thanks, Paolo!

[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range

[tomga at wp dot pl]

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

--- Comment #9 from Tomasz Gajewski  ---
Following patch seems to solve this problem although I don't like it very much.
I think whole get_basic_type function should be moved to the beginning of
printers.py.

And additionally I'm not sure if this change does not break something somewhere
else. If not I think get_basic_type and find_type should be merged into one
function. If not calls to them should be replaced appappropriately. I leave it
to someone else.


Index: libstdcxx/v6/printers.py
===
--- libstdcxx/v6/printers.py(revision 200105)
+++ libstdcxx/v6/printers.py(working copy)
@@ -39,7 +39,7 @@
 # handles searching upward through superclasses.  This is needed to
 # work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615.
 def find_type(orig, name):
-typ = orig.strip_typedefs()
+typ = Printer.get_basic_type(orig)
 while True:
 search = str(typ) + '::' + name
 try:

[Bug fortran/52788] -fbounds-check fails for 2-rank allocatable arrays when reading

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-15
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Still present at revision 200122.

[Bug fortran/45608] Bogus error about procedure attribute

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-15
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Still present at revision 200122. I share the Tobias' opinion that it won't be
easy to get a better error message. This PR should probably be closed as
WONTFIX.

[Bug fortran/45619] intent(out) dummy arguements in specification statements

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-15
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Still present at revision 200122.

[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g

[tejohnson at google dot com]

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

--- Comment #5 from Teresa Johnson  ---
On Fri, Jun 14, 2013 at 4:19 PM, ccoutant at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451
>
> --- Comment #4 from Cary Coutant  ---
> The problem is a lexical block in main() that appears to be getting split by
> -freorder-blocks-and-partition, but when debug info is emitted during
> rest_of_handle_final(), this particular lexical block still appears to be a
> single block -- BLOCK_FRAGMENT_CHAIN is NULL, so the DWARF output code decides
> that it can emit a DW_AT_low_pc/high_pc pair instead of a DW_AT_ranges. The
> DW_AT_high_pc is now being output relative to DW_AT_low_pc, so we see an
> assembly expression .LBE14 - .LBB14, which are labels attached to the block
> start and block end, and should be in the same section.
>
> Here's the block:
>
> (gdb) p stmt
> $1 = (tree) 0x75f4c4b0
> (gdb) pt
> warning: Expression is not an assignment (and might have no effect)
>   vars  type  MyException>
> sizes-gimplified unsigned DI
> size 
> unit size 
> align 64 symtab 0 alias set -1 canonical type 0x7609b930>
> readonly tree_1 tree_3 unsigned decl_5 DI file pr49115.C line 21 col 
> 25
> size  unit size 
> align 64 context >
> supercontext  vars  Data>
> used tree_1 tree_3 decl_5 SI file pr49115.C line 18 col 8
> size 
> unit size 
> align 128 context 
> (reg/v:SI 64 [ data ])>
> supercontext  
> subblocks  0x7608bb48 data> supercontext  subblocks  0x75f4c4b0> chain 
>
> (gdb) p stmt->block
> $2 = {base = {code = BLOCK, side_effects_flag = 0, constant_flag = 0,
> addressable_flag = 0,
> volatile_flag = 0, readonly_flag = 0, asm_written_flag = 1, nowarning_flag
> = 0, visited = 0,
> used_flag = 1, nothrow_flag = 0, static_flag = 0, public_flag = 0,
> private_flag = 0,
> protected_flag = 0, deprecated_flag = 0, default_def_flag = 0, u = {bits =
> {lang_flag_0 = 0,
> lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
> lang_flag_5 = 0,
> lang_flag_6 = 0, saturating_flag = 0, unsigned_flag = 0, packed_flag =
> 0, user_align = 0,
> nameless_flag = 1, spare0 = 0, spare1 = 0, address_space = 0}, length 
> =
> 2048,
>   version = 2048}}, chain = 0x0, abstract_flag = 0, block_num = 14, locus 
> =
> 0,
>   vars = 0x7608bc78, nonlocalized_vars = 0x0, subblocks = 0x0, 
> supercontext
> = 0x760c00f0,
>   abstract_origin = 0x0, fragment_origin = 0x0, fragment_chain = 0x0}
>
> Here's the fragment of assembly code between .LBB14 and .LBE14:
>
> .LBB14:
> # pr49115.C:21
> .loc 1 21 0
> call__cxa_begin_catch
> .LVL7:
> call__cxa_end_catch
> .LVL8:
> .p2align 4,,5
> # SUCC: 3 [100.0%]  count:1
> jmp .L15
> .cfi_endproc
> .section.text.unlikely
> .cfi_startproc
> .cfi_personality 0x3,__gxx_personality_v0
> .cfi_lsda 0x3,.LLSDAC4
> # BLOCK 6 freq:5000 seq:4
> # PRED: 4 [50.0%]  (CROSSING,CAN_FALLTHRU)
> .L14:
> .cfi_def_cfa_offset 16
> .p2align 4,,8
> .LEHB1:
> # SUCC:
> call_Unwind_Resume
> .LEHE1:
> .LVL9:
> .LBE14:
> .LBE15:
> .cfi_endproc
>
> You can see that the block from .LBB14 to .LBE14 has been split across two
> sections. In order for dwarf2out to generate the proper debug info,
> BLOCK_FRAGMENT_CHAIN(stmt) needs to be non-NULL. I'm not sure why that's not
> happening when the block is split.

It looks like this is all done during the final pass when assembly is
being emitted. In final_start_function the NOTE_INSN_BLOCK_{BEG/END}
notes are inserted based on lexical scopes (in
reemit_insn_block_notes). At the end of reemit_insn_block_notes,
reorder_blocks is called to identify blocks references by more than
one NOTE_INSN_BLOCK_{BEG/END}. Any such blocks are duplicated and the
BLOCK_FRAGMENT_CHAIN is setup.

I'm not familiar with this code, but perhaps when a switch section
note is seen by reemit_insn_block_notes, it should invoke change_scope
to emit the necessary NOTE_INSN_BLOCK_* notes?

Thanks,
Teresa

>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.



--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Bug target/57623] New: BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

Bug ID: 57623
   Summary: BEXTR intrinsic has memory operands switched around
(fails to compile code)
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com

Hi,

Given I'm on gcc 4.8.1 (Debian 4.8.1-2). Given the following test program:

sesse@gruessi:~$ cat bextr-test.c 
#include 

uint64_t func(uint64_t x, uint64_t *y)
{
return __builtin_ia32_bextr_u64(x, *y);
}

trying to compile it fails:

sesse@gruessi:~$ gcc-4.8 -O2 -mbmi -c bextr-test.c --save-temps
bextr-test.s: Assembler messages:
bextr-test.s:9: Error: operand size mismatch for `bextr'

seemingly because GCC's idea of r/m is broken for this instruction:


sesse@gruessi:~$ cat bextr-test.s
.file"bextr-test.c"
.text
.p2align 4,,15
.globlfunc
.typefunc, @function
func:
.LFB0:
.cfi_startproc
bextr(%rsi), %rdi, %rax
ret
.cfi_endproc
.LFE0:
.sizefunc, .-func
.ident"GCC: (Debian 4.8.1-2) 4.8.1"
.section.note.GNU-stack,"",@progbits

As far as I understand, the second operand can be r/m64, but the first can only
be r64.

[Bug target/57624] New: BZHI instrinsic is missing

[sgunderson at bigfoot dot com]

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

Bug ID: 57624
   Summary: BZHI instrinsic is missing
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com

Hi,

The GCC documentation
(http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html) claims
there should be such an intrinsic, added in gcc 4.7:

 unsigned long long _bzhi_u64 (unsigned long long, unsigned long long)

Yet, with gcc 4.8.1 (Debian 4.8.1-2), nothing of the sort exists:

sesse@gruessi:~$ gcc-4.8 -Wall -O2 -mbmi2 -c bzhi-test.c
bzhi-test.c: In function ‘func’:
bzhi-test.c:5:2: warning: implicit declaration of function ‘_bzhi_u64’
[-Wimplicit-function-declaration]
  return _bzhi_u64(x, y);
  ^

A function call is generated instead, which was obviously not what I intended.
:-)

I thought this was maybe just a documentation error, but
__builtin_ia32_bzhi_u64 also does not exist.

[Bug preprocessor/57620] Phantom terminator confuses raw string literal parsing.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 30306
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30306&action=edit
gcc49-pr57620.patch

So far only very lightly tested patch, passes raw-string* tests (except for
raw-string-2.c which contains also trigraph tests that were valid in the
earlier raw string paper, but aren't valid in C++11) and this plus a few other
tests.
Will still need to adjust raw-string-2.c, and add sufficient test coverage for
all the corner cases.

[Bug target/57624] BZHI instrinsic is missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
If you forget to include
#include 
then don't be surprised.

[Bug libgcj/51615] Condition Variable queue state corruption and infinite loop

[pashev.igor at gmail dot com]

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

Igor Pashev  changed:

   What|Removed |Added

 CC||pashev.igor at gmail dot com

--- Comment #1 from Igor Pashev  ---
Here is what I see on illumos:

21071:gij-4.7 -classpath
build/bootstrap/eclipse-ecj.jar:/usr/share/ant/lib/
-  lwp# 1 / thread# 1  
 fd7f4e16f427 lwp_park (0, 0, 0)
 fd7f4e167b06 mutex_lock_impl () + 156
 fd7f4e167bdb mutex_lock () + b
 fd7f42984a81 _Z13_Jv_MutexLockP11_Jv_Mutex_t () + 51
 00733840  ()
 f2f1e001  ()
   ()
 0002  ()
-  lwp# 2 / thread# 2  
 fd7f4e16f427 lwp_park (0, 0, 0)
 fd7f4e168f8f cond_wait_queue () + 4f
 fd7f4e1695e2 __cond_wait () + b2
 fd7f4e169612 cond_wait () + 22
 fd7f4e169649 pthread_cond_wait () + 9
 fd7f42984c1c _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi ()
+ 13c
   ()
-  lwp# 3 / thread# 3  
 fd7f4e16f427 lwp_park (0, 0, 0)
 fd7f4e167b06 mutex_lock_impl () + 156
 fd7f4e167bdb mutex_lock () + b
 fd7f42984c3d _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi ()
+ 15d
   ()
-  lwp# 4 / thread# 4  
 fd7f42984bc7 _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi ()
+ e7
 0100  ()


I also tried to build openjdk6, and gcj "compiles" 250 files forever :-) I've
waited for day or two :-\

[Bug libgcj/51615] Condition Variable queue state corruption and infinite loop

[pashev.igor at gmail dot com]

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

--- Comment #2 from Igor Pashev  ---
See also #34574

[Bug libgcj/34574] wait() call hangs in _Jv_CondWait taking the monitor with it causing the application to hang

[pashev.igor at gmail dot com]

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

Igor Pashev  changed:

   What|Removed |Added

 CC||pashev.igor at gmail dot com

--- Comment #2 from Igor Pashev  ---
I can confirm it on illumos with gcc 4.7. Tjis prevent me from building openjdk
anf ecj. For ecj:

21071:gij-4.7 -classpath
build/bootstrap/eclipse-ecj.jar:/usr/share/ant/lib/
-  lwp# 1 / thread# 1  
 fd7f4e16f427 lwp_park (0, 0, 0)
 fd7f4e167b06 mutex_lock_impl () + 156
 fd7f4e167bdb mutex_lock () + b
 fd7f42984a81 _Z13_Jv_MutexLockP11_Jv_Mutex_t () + 51
 00733840  ()
 f2f1e001  ()
   ()
 0002  ()
-  lwp# 2 / thread# 2  
 fd7f4e16f427 lwp_park (0, 0, 0)
 fd7f4e168f8f cond_wait_queue () + 4f
 fd7f4e1695e2 __cond_wait () + b2
 fd7f4e169612 cond_wait () + 22
 fd7f4e169649 pthread_cond_wait () + 9
 fd7f42984c1c _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi ()
+ 13c
   ()
-  lwp# 3 / thread# 3  
 fd7f4e16f427 lwp_park (0, 0, 0)
 fd7f4e167b06 mutex_lock_impl () + 156
 fd7f4e167bdb mutex_lock () + b
 fd7f42984c3d _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi ()
+ 15d
   ()
-  lwp# 4 / thread# 4  
 fd7f42984bc7 _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi ()
+ e7
 0100  ()

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 30307
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30307&action=edit
gcc49-pr57623.patch

The fix for the compiler is easy, but at least the AVX2 spec documents that
_bextr_u{32,64} intrinsics actually take 3 arguments (source, start and
length),
with the latter two always unsigned int, while our intrinsic has only two
arguments (where the latter is expected to be (start & 255) | (length << 8)).
Not sure if we want to change this, and if so, just for 4.9+, or also for
4.8.2+ and 4.7.4+?

[Bug c/57625] New: internal compiler error: seg fault when building gcc 4.7.2

[je.suis.bon at googlemail dot com]

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

Bug ID: 57625
   Summary: internal compiler error: seg fault when building gcc
4.7.2
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: je.suis.bon at googlemail dot com

Created attachment 30308
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30308&action=edit
libgcc2.c

I was attempting to build gcc 4.7.2 using gcc 4.8.1.

to reproduce:
mkdir build-gcc
cd build-gcc
../gcc-4.7.2/configure --disable-nls --enable-languages=c
echo "MAKEINFO = :" >> Makefile # otherwise compile fails!
make all-gcc
make all-target-libgcc

The following error occurs:
../../../../originalsrc/gcc-4.7.2/libgcc/libgcc2.c: In function '__absvdi2':
../../../../originalsrc/gcc-4.7.2/libgcc/libgcc2.c:273:1: internal compiler
error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_absvdi2.o] Error 1


In compliance with gcc's dying wishes, I have submitted a bug report. Although
I'm sure you already have it, for rapid perusal, I have attached the source
file that caused the seg fault.

extra information:
$gcc --version: gcc (GCC) 4.8.1
system: archlinux amd64, using the gcc package "gcc-4.8.1-1"

If any further information is required, please ask.

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

--- Comment #2 from sgunderson at bigfoot dot com ---
On Sat, Jun 15, 2013 at 04:33:14PM +, jakub at gcc dot gnu.org wrote:
> The fix for the compiler is easy, but at least the AVX2 spec documents that
> _bextr_u{32,64} intrinsics actually take 3 arguments (source, start and
> length),
> with the latter two always unsigned int, while our intrinsic has only two
> arguments (where the latter is expected to be (start & 255) | (length << 8)).
> Not sure if we want to change this, and if so, just for 4.9+, or also for
> 4.8.2+ and 4.7.4+?

If you decide to change it, at least consider keeping the old version around;
for instance, the start/length combination could come from a table. In
general, if you actually have to do shifting and stuff to create this
operand, the gain of the instruction is already lost.

/* Steinar */

[Bug c++/57626] New: [C++11] ICE with template alias and member function pointer

[bluescarni at gmail dot com]

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

Bug ID: 57626
   Summary: [C++11] ICE with template alias and member function
pointer
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com

Created attachment 30309
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30309&action=edit
Test case showing the problem

The attached reduced code snippet produces an ICE in both GCC 4.8.1 and 4.7.3.
The error messages are respectively:

---
bug.cpp: In substitution of ‘template class TT,
class ... Args> using bar = void (T::*)(TT&, const symbol_set&) [with
T = Term; TT = Args ...; Args = {Args ...}]’:
bug.cpp:8:86:   required from here
bug.cpp:4:58: internal compiler error: in tsubst, at cp/pt.c:11324
 using bar = void(T::*)(TT &, const symbol_set &);
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
---

and

---
bug.cpp:4:58: internal compiler error: in tsubst, at cp/pt.c:11057
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
---

Note that the code snippet is malformed and it is not supposed to compile.
clang++ 3.2 produces the error message:

---
bug.cpp:8:79: error: template argument for template template parameter must be
a class template or type alias template
 template (&Term::multiply))>
  ^
1 error generated.
---

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to sgunderson from comment #2)
> On Sat, Jun 15, 2013 at 04:33:14PM +, jakub at gcc dot gnu.org wrote:
> > The fix for the compiler is easy, but at least the AVX2 spec documents that
> > _bextr_u{32,64} intrinsics actually take 3 arguments (source, start and
> > length),
> > with the latter two always unsigned int, while our intrinsic has only two
> > arguments (where the latter is expected to be (start & 255) | (length << 
> > 8)).
> > Not sure if we want to change this, and if so, just for 4.9+, or also for
> > 4.8.2+ and 4.7.4+?
> 
> If you decide to change it, at least consider keeping the old version around;
> for instance, the start/length combination could come from a table. In
> general, if you actually have to do shifting and stuff to create this
> operand, the gain of the instruction is already lost.

If both start and length are constants, then it will be folded by the compiler,
similarly if you use it inside of loop and start/length will be loop
invariants, the computation can be hoisted out of the loop.
While C++ has function overloading, C does not, so we can't have both with the
same name.

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)

[sgunderson at bigfoot dot com]

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

--- Comment #4 from sgunderson at bigfoot dot com ---
On Sat, Jun 15, 2013 at 05:10:57PM +, jakub at gcc dot gnu.org wrote:
> If both start and length are constants, then it will be folded by the 
> compiler,
> similarly if you use it inside of loop and start/length will be loop
> invariants, the computation can be hoisted out of the loop.

Sure, but again, neither of these match my situation. I really need to do a
lookup into a table (with a non-constant index) to get the value.

/* Steinar */

[Bug preprocessor/57620] Phantom terminator confuses raw string literal parsing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-15
 CC|jakub at gcc dot gnu.org   |
 Ever confirmed|0   |1

--- Comment #4 from Paolo Carlini  ---
Thanks!

[Bug middle-end/57625] internal compiler error: seg fault when building gcc 4.7.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Severity|major   |normal

[Bug c++/56996] no warning on using extern "C" in namespace

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Closing.

[Bug c++/55203] No unused warning for variables of non-trivial types

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
I guess this could be the right time to properly submit something to
gcc-patches (for 4.9)

[Bug c++/53184] Unnecessary anonymous namespace warnings

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||zeratul976 at hotmail dot com

--- Comment #5 from Paolo Carlini  ---
*** Bug 54060 has been marked as a duplicate of this bug. ***

[Bug c++/54060] G++ warning mixes up anonymous types and anonymous namespaces

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Paolo Carlini  ---
Same issue, right? And it seems easy to fix, we have only to reword a bit the
message.

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

[Bug c++/57626] [C++11] ICE with template alias and member function pointer

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-15
 Ever confirmed|0   |1

[Bug c/57627] New: -Wsizeof-pointer-memaccess should make an exception for character types

[harald at gigawatt dot nl]

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

Bug ID: 57627
   Summary: -Wsizeof-pointer-memaccess should make an exception
for character types
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: harald at gigawatt dot nl

$ cat test.c
void f1(int *dst, int *src)
{ __builtin_memcpy(dst, src, sizeof(int *)); }

void f2(char *dst, char *src)
{ __builtin_memcpy(dst, src, sizeof(char *)); }

void f3(unsigned char *dst, unsigned char *src)
{ __builtin_memcpy(dst, src, sizeof(unsigned char *)); }
$ gcc -c test.c -Wall
test.c: In function ‘f1’:
test.c:2:36: warning: argument to ‘sizeof’ in ‘__builtin_memcpy’ call is the
same pointer type ‘int *’ as the destination; expected ‘int’ or an explicit
length [-Wsizeof-pointer-memaccess]
 { __builtin_memcpy(dst, src, sizeof(int *)); }
^
test.c: In function ‘f2’:
test.c:5:36: warning: argument to ‘sizeof’ in ‘__builtin_memcpy’ call is the
same pointer type ‘char *’ as the destination; expected ‘char’ or an explicit
length [-Wsizeof-pointer-memaccess]
 { __builtin_memcpy(dst, src, sizeof(char *)); }
^
test.c: In function ‘f3’:
test.c:8:36: warning: argument to ‘sizeof’ in ‘__builtin_memcpy’ call is the
same pointer type ‘unsigned char *’ as the destination; expected ‘unsigned
char’ or an explicit length [-Wsizeof-pointer-memaccess]
 { __builtin_memcpy(dst, src, sizeof(unsigned char *)); }
^
$ gcc --version
gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
Copyright (C) 2013 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.

The warning makes sense for most types (f1), but for character types, I don't
think GCC should give any warning (f2 and f3). I'm seeing this warning for
correct code that stores pointers in raw byte buffers, and I would be surprised
if that is less common than code that really means to memcpy a single byte.

[Bug rtl-optimization/57425] [4.8/4.9 regression] RTL alias analysis unprepared to handle stack slot sharing

[amylaar at gcc dot gnu.org]

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

--- Comment #7 from Jorn Wolfgang Rennecke  ---
Created attachment 30310
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30310&action=edit
patch for alias problem during cse pass

(In reply to Richard Biener from comment #4)
> Note that I only recently fixed a wrong alias query from using
> true_dependence
> to anti_dependence.  Similar issues may exist elsewhere.

Indeed, looking at the .172r.cse1 dump more closely, I saw it
actually contained actually two dumps, first looking OK, the
second with the deleterious changes in place.

First, cse is applied to the asms.  I'm not sure if this should
be called a bug or a feature.
At any rate, cse does have an alias problem as you suspected.
The attached patch addresses this issue, but doesn't fix the testcase;
something goes again wrong between the reload and postreload dump.

[Bug rtl-optimization/57425] [4.8/4.9 regression] RTL alias analysis unprepared to handle stack slot sharing

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

  Attachment #30310|0   |1
is obsolete||

--- Comment #8 from Jorn Wolfgang Rennecke  ---
Created attachment 30311
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30311&action=edit
patch with cselib / testsuite bits added

I'm currently testing this patch.

[Bug middle-end/57625] internal compiler error: seg fault when building gcc 4.7.2

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  ---
I can't reproduce with FSF gcc 4.8.1 and 4.7.2 on Fedora 17 x86_64.  Your
archlinux system compiler is presumably somewhat modified; can you try again
with an FSF 4.8.1?  Also please make sure the 4.7.2 you're building is
unmodified.

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[mikael at gcc dot gnu.org]

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

--- Comment #14 from Mikael Morin  ---
Author: mikael
Date: Sat Jun 15 21:20:29 2013
New Revision: 200128

URL: http://gcc.gnu.org/viewcvs?rev=200128&root=gcc&view=rev
Log:
fortran/
PR fortran/49074
PR fortran/56136
* dependency.c (gfc_check_argument_var_dependency): Return 0 in the
array constructor case.

testsuite/
PR fortran/49074
PR fortran/56136
* gfortran.dg/typebound_assignment_5.f03: Check the absence of any
packing.
* gfortran.dg/typebound_assignment_6.f03: New.


Added:
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_6.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_5.f03

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[mikael at gcc dot gnu.org]

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

--- Comment #15 from Mikael Morin  ---
Comment #14 removes an unnecessary packing/unpacking.
The bug remains fixed. :-)

[Bug fortran/56136] [OOP] ICE on lhs-reallocation of an object with overloaded (elemental) assignment operator

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin  ---
Author: mikael
Date: Sat Jun 15 21:20:29 2013
New Revision: 200128

URL: http://gcc.gnu.org/viewcvs?rev=200128&root=gcc&view=rev
Log:
fortran/
PR fortran/49074
PR fortran/56136
* dependency.c (gfc_check_argument_var_dependency): Return 0 in the
array constructor case.

testsuite/
PR fortran/49074
PR fortran/56136
* gfortran.dg/typebound_assignment_5.f03: Check the absence of any
packing.
* gfortran.dg/typebound_assignment_6.f03: New.


Added:
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_6.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_5.f03

[Bug fortran/56136] [OOP] ICE on lhs-reallocation of an object with overloaded (elemental) assignment operator

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #5 from Mikael Morin  ---
Comment #4 removes an unnecessary packing/unpacking and adds a variant of the
testcase of this PR in the testsuite.

(In reply to Mikael Morin from comment #3)
> Yes it is the same bug as PR49074.

So the resolution status should be DUPLICATE.

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

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||alipasha.celeris at gmail dot 
com

--- Comment #16 from Mikael Morin  ---
*** Bug 56136 has been marked as a duplicate of this bug. ***

[Bug fortran/22210] gfc_conv_array_initializer weirdness

[bdavis at gcc dot gnu.org]

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

Bud Davis  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bdavis at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #17 from Bud Davis  ---
Closing due to no clear problem defined.  If more info is available, please
re-open.

[Bug c++/56493] Performance regression in google dense hashmap

[jim at meyering dot net]

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

jim at meyering dot net changed:

   What|Removed |Added

 CC||jim at meyering dot net

--- Comment #12 from jim at meyering dot net ---
Thank you, Jakub.

[Bug c++/53184] Unnecessary anonymous namespace warnings

[zeratul976 at hotmail dot com]

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

--- Comment #6 from Nathan Ridge  ---
(In reply to Jason Merrill from comment #4)
> (In reply to comment #3)
> > Because then the anonymous class has the name "Foo" for linkage purposes, 
> > and
> > has external linkage.  When Foo referes to the const or volatile qualified 
> > form
> > of the class, the anonymous class itself has no name and so no linkage, only
> > the cv-qualified form has a name for linkage purposes.
> > 
> > I'm not sure if that behaviour is correct though, let's ask Jason
> 
> Yes, that's right. 7.1.3:
> 
> If the typedef declaration defines an unnamed class (or enum), the first
> typedef-name declared by the declaration to be that class type (or enum
> type) is used to denote the class type (or enum type) for linkage purposes
> only (3.5).
> 
>   typedef struct { } *ps, S;  // S is the class name for linkage purposes
> 
> Adding volatile means that Foo doesn't name the class, it names the volatile
> variant of the class, so it isn't the class's name for linkage purposes, so
> the class has no linkage.  The warning complains about using a type with no
> linkage as a member type in a header file, since including that header in
> multiple source files would be an ODR violation as the type Foo is different
> in each translation unit.

Is this ODR violation an actual problem in practice, with GCC? I find these
warnings annoying to work around, and I wouldn't mind seeing an option to
silence them if they don't indicate an actual problem.

[Bug fortran/57628] New: spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

Bug ID: 57628
   Summary: spurious error: division by zero in if statement
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: furue at hawaii dot edu

Dear gfortran maintainers,

Division by zero causes error even when it's not executed:

program try
  implicit NONE
  real, parameter:: a = 0.0
  if (a > 0) then
write(*,*) 1/a
  end if
end program try

$ /usr/bin/gfortran tmp.f90
tmp.f90:5.16:

write(*,*) 1/a
1
Error: Division by zero at (1)
$

If it's difficult to give a correct diagnosis, please demote this to a warning.

I have a lot of constructs like this because I change the parameter often and
so this behavior of gfortran is very inconvenient (because I have to rewrite my
source code to be able to compile it).

Regards,
Ryo