[Bug c++/60258] Member initialization for atomic fail.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c/57896] [4.8 Regression] ICE in expand_expr_real_2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.8.4
Summary|ICE in expand_expr_real_2   |[4.8 Regression] ICE in
   ||expand_expr_real_2

--- Comment #7 from Marek Polacek  ---
Currently, I see ICE only with 4.8:

./cc1 xx.c -m32 -quiet -march=x86-64

In function ‘__get_cpuid_max’:
Segmentation fault
 }
 ^
0xa3924f crash_signal
/home/marek/src/gcc/gcc/toplev.c:332
0x11fc5fe pp_base_string(pretty_print_info*, char const*)
/home/marek/src/gcc/gcc/pretty-print.c:835
0x11fd0a4 pp_base_format(pretty_print_info*, text_info*)
/home/marek/src/gcc/gcc/pretty-print.c:496
0x11fa7ac diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/marek/src/gcc/gcc/diagnostic.c:755
0x11faabb internal_error(char const*, ...)
/home/marek/src/gcc/gcc/diagnostic.c:1094
0x9b9aa7 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/home/marek/src/gcc/gcc/rtl.c:773
0xc93a5d pro_epilogue_adjust_stack
/home/marek/src/gcc/gcc/config/i386/i386.c:9517
0xca0b20 ix86_expand_prologue()
/home/marek/src/gcc/gcc/config/i386/i386.c:10491
0xd645da gen_prologue()
/home/marek/src/gcc/gcc/config/i386/i386.md:11810
0x80dc79 thread_prologue_and_epilogue_insns
/home/marek/src/gcc/gcc/function.c:5949
0x8110a2 rest_of_handle_thread_prologue_and_epilogue
/home/marek/src/gcc/gcc/function.c:6973
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #8 from Marek Polacek  ---
Not a C FE issue.

[Bug c/60170] No -Wtype-limits warning with -O1

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c/59933] for loop goes wild with assert() enabled

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
There's no good reproducer, but if -fno-aggressive-loop-optimizations helps,
most likely the code invokes undefined behavior.  Tentatively closing as
invalid (PR59982 was closed too).

[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887

[jakub at gcc dot gnu.org]

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

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

Untested fix for the preprocessing ICE.  So, with this patch you should be able
to preprocess the file now.

[Bug rtl-optimization/60268] [4.9 regression] ICE: in rank_for_schedule, at haifa-sched.c:2557

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug ipa/60266] [4.9 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:261 during LibreOffice LTO build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

--- Comment #1 from Richard Biener  ---
Similar to recently fixed maybe this is either the call fn or the static chain?

[Bug fortran/59537] "Automatic array cannot have an initializer", for -finit-real and a SAVE statement present in subroutine

[bugs at stellardeath dot org]

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

--- Comment #1 from Lorenz Hüdepohl  ---
Maybe related to the already fixed #51800?

[Bug fortran/59537] "Automatic array cannot have an initializer", for -finit-real and a SAVE statement present in subroutine

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> Maybe related to the already fixed #51800?

Maybe, but this PR is still present on trunk (4.9 r207856), 4.7.4 and 4.8.2.

[Bug ipa/60243] IPA is slow on large cgraph tree

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 19 09:29:34 2014
New Revision: 207879

URL: http://gcc.gnu.org/viewcvs?rev=207879&root=gcc&view=rev
Log:
2014-02-19  Richard Biener  

PR ipa/60243
* ipa-prop.c: Include stringpool.h and tree-ssanames.h.
(ipa_modify_call_arguments): Emit an argument load explicitely and
preserve virtual SSA form there and for the replacement call.
Do not update SSA form nor free dominance info.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c

[Bug rtl-optimization/60268] [4.9 regression] ICE: in rank_for_schedule, at haifa-sched.c:2557

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

--- Comment #3 from Andrey Belevantsev  ---
I'm out of office today, so I'll have a look properly tomorrow, but...

(In reply to Jakub Jelinek from comment #2)
> So perhaps:
> --- gcc/haifa-sched.c 2014-02-18 08:18:53.045024428 +0100
> +++ gcc/haifa-sched.c 2014-02-19 07:58:38.191381581 +0100
> @@ -2550,7 +2550,7 @@ rank_for_schedule (const void *x, const
>   return INSN_LUID (tmp) - INSN_LUID (tmp2);
>  }
>  
> -  if (live_range_shrinkage_p)
> +  if (live_range_shrinkage_p && sched_pressure != SCHED_PRESSURE_NONE)
>  {
>/* Don't use SCHED_PRESSURE_MODEL -- it results in much worse
>code.  */

...  the fired assert below this code means that we have turned off
sched-pressure on the new region (unexpectedly to live_range_shrinkage) and I'd
like to know how this region was added.  I guess I missed some entry point
within the new scheduler code when fixing the previous PR.

> 
> BTW, why
>   if (sched_pressure != SCHED_PRESSURE_NONE)
> free_global_sched_pressure_data ();
> when free_global_sched_pressure_data () contains the same guard and thus
> could be called unconditionally?

Pilot error while being over cautious, I will simplify that too.

[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-02-19
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Jakub Jelinek  ---
Created attachment 32168
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32168&action=edit
gcc49-pr60267-2.patch

Untested fix for the tsubst ICE.  Of course, without preprocessed testcase I
can't be sure if this patch fixed it.

[Bug c/59193] Unused postfix operator temporaries

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Max TenEyck Woodbury from comment #4)
> Since there are hundreds, if not thousands of instances of this defect in the
> GCC code and there is no urgency in correcting these defects, this bug will
> only
> get resolved slowly.  Closing it for invalid reasons does the community a
> disservice.

Are you planning to help in fixing these and other problems? If so, please
start the copyright assignment process:
http://gcc.gnu.org/contribute.html#legal

Then, to get your feet wet, it would be better to start with some
uncontroversial bugs like: PR25801, or PR55080, or PR57622 or PR52347.

I have a long list of easy hacks that would help a lot GCC and its users.

[Bug c++/60269] New: #pragma simd tsubst related ICE

[jakub at gcc dot gnu.org]

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

Bug ID: 60269
   Summary: #pragma simd tsubst related ICE
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: bviyer at gcc dot gnu.org

template 
void
foo (int *a, int *b, int *c)
{
#pragma simd vectorlength (N)
  for (int i = 0; i < N; i++)
a[i] = b[i] * c[i];
}

void
bar (int *a, int *b, int *c)
{
  foo <64> (a, b, c);
}

ICEs with -fcilkplus, so clearly tsubst on it is not performed correctly.

[Bug target/60204] struct with __m512i is mishandled in function parameter passing and return

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
   Target Milestone|--- |4.9.0
   Severity|normal  |major

--- Comment #3 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #2)

> It is a bug in psABI.  It should read as "eight \eightbytes".

So, let's fix the psABI first and then fix gcc.

This PR should be resolved before 4.9 is released.

[Bug target/60204] struct with __m512i is mishandled in function parameter passing and return

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)

> So, let's fix the psABI first and then fix gcc.

psABI is fixed in [1].

[1]
https://github.com/hjl-tools/x86-64-psABI/commit/6d7ccd614fe67111d2aecec853c3df0310b372d2

[Bug target/57232] wcstol.c:213:1: internal compiler error

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #15 from Alexandre Oliva  ---
Mine.  It looks like the call to cselib_preserve_cfa_base_value in
vt_initialize should be guarded by some conditions, like this:

  if (reg != hard_frame_pointer_rtx && fixed_regs[REGNO (reg)])
cselib_preserve_cfa_base_value (val, REGNO (reg));

This fixes the reported problem for me (though I haven't otherwise regtested
it).  Daniel, Jon, Nick, Sebastian, does it fix the problem for you?

[Bug c/59193] Unused postfix operator temporaries

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Andrew Pinski  ---
Take:
int f(int a)
{
  a++;
  return a;
}

int g(int a)
{
  ++a;
  return a;
}
--- CUT --- 

The gimplifier produces the exact same IR for both cases:
f (int a)
{
  int D.1790;

  a = a + 1;
  D.1790 = a;
  return D.1790;
}


g (int a)
{
  int D.1792;

  a = a + 1;
  D.1792 = a;
  return D.1792;
}
--- CUT --- 

So the compiler is already smart enough to remove the "temporary storage" even
at -O0.

With:
int f(int a)
{
  int b = a++;
  return a;
}
It does not remove it but that is because the result of a++ is not unused.

So it is the gimplifier knows if the result is unused and will not use them
otherwise.  This is the same issue as memcpy and its return value.

[Bug fortran/60255] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

[Bug fortran/60238] Allow colon-separated triplet in array initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-02-19
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Anybody against closing this PR as WONTFIX?

[Bug c/59193] Unused postfix operator temporaries

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Also note that even at -O0, at no point during compilation with GCC/G++ if the
value of ++a or a++ isn't used and a has integral/pointer type one form is more
efficient than the other.  It is just a different tree code
({PRE,POST}{IN,DE}CREMENT_EXPR), but with the same operand, type etc.
So, there is no waste of any resources, it is not a defect to use either style,
it is purely coding convention matter.

[Bug libstdc++/60270] New: [C++1y] std::quoted is too eager to clear the string

[redi at gcc dot gnu.org]

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

Bug ID: 60270
   Summary: [C++1y] std::quoted is too eager to clear the string
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

Lars Gullik Bjønnes pointed out that we clear the string too early in
std::quoted, which causes this to fail:

#include 
#include 
#include 
#include 

int main()
{
  std::istringstream in;
  std::string s = "xxx";
  in >> s;
  assert( !s.empty() );
  in >> std::quoted(s);
  assert( !s.empty() );  // fails
}

[Bug libstdc++/60271] New: [C++1y] std::max(initializer_list) cannot use std::max_element

[redi at gcc dot gnu.org]

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

Bug ID: 60271
   Summary: [C++1y] std::max(initializer_list) cannot use
std::max_element
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3893.html#2350
(approved in Issaquah) adds constexpr to std::max(initializer_list), which
means we can't use std::max_element to implement it.

[Bug target/60204] struct with __m512i is mishandled in function parameter passing and return

[tocarip.intel at gmail dot com]

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

--- Comment #5 from tocarip.intel at gmail dot com ---
Created attachment 32169
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32169&action=edit
Proposed patch.

Currently testing attached patch.

[Bug c++/60272] New: atomic<>::compare_exchange_weak has spurious store and can cause race conditions

[anthony.ajw at gmail dot com]

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

Bug ID: 60272
   Summary: atomic<>::compare_exchange_weak has spurious store and
can cause race conditions
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anthony.ajw at gmail dot com

Created attachment 32170
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32170&action=edit
Sample code that demonstrates the problem

G++ 4.8.1 is producing incorrect code for std::atomic<>::compare_exchange_weak
on x86-64 linux.

In particular, if the exchange succeeds, then there is an additional spurious
store to the "expected" parameter after the exchange, which may race with other
threads and cause problems.

e.g.

#include 
struct Node { Node* next; };
void Push(std::atomic& head, Node* node)
{
node->next = head.load();
while(!head.compare_exchange_weak(node->next, node))
;
}

When compiled with

g++-4.8 -S -std=c++11 -pthread -O3 t.cpp

the generated code is:

movq(%rdi), %rax
movq%rax, (%rsi)
movq(%rsi), %rax
.p2align 4,,10
.p2align 3
.L3:
lock; cmpxchgq%rsi, (%rdi)
movq%rax, (%rsi) ***
jne.L3
rep; ret

The line marked *** is an unconditional store to node->next in this
example, and will be executed even if the exchange is successful.

This will cause a race with code that uses the compare-exchange to order memory
operations.

e.g.

void Pop(std::atomic& head){
for(;;){
Node* value=head.exchange(nullptr);
if(value){
delete value;
break;
}
}
}

If the exchange successfully retrieves a non-null value, it should be OK to
delete it (assuming the node was allocated with new). However, if one thread is
calling Push() and is suspended after the CMPXCHG and before the line marked
*** is executed then another thread running Pop() can successfully complete
the exchange and call delete. When the first thread is resumed, the line marked
*** will then store to deallocated memory.

This is in contradiction to 29.6.5p21 of the C++ Standard, which states that
"expected" is only updated in the case of failure.

[Bug c++/60272] atomic<>::compare_exchange_weak has spurious store and can cause race conditions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/60172] ARM performance regression from trunk@207239

[joey.ye at arm dot com]

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

--- Comment #10 from Joey Ye  ---
(In reply to rguent...@suse.de from comment #9)
> On Mon, 17 Feb 2014, joey.ye at arm dot com wrote:
> 
> 
> But that doesn't make sense - it means that -fdisable-tree-forwprop4
> should get numbers back to good speed, no?  Because that's the
> only change forwprop4 does.
-fdisable-tree-forwprop4 dooms other transformation and results slightly worse
code than before. So the number isn't back to the best. I think forwprop4 does
some good stuff here and disabling it isn't the solution.
> 
> For completeness please base checks on r207316 (it contains a fix
> for the blamed revision, but as far as I can see it shouldn't make
> a difference for the testcase).
I'm playing with r207686 and it is the same for this case.
> 
> Did you check whether my hackish patch fixes things?
I did with trunk 20140208. But it didn't make any difference to Proc_8

[Bug tree-optimization/60172] ARM performance regression from trunk@207239

[joey.ye at arm dot com]

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

--- Comment #11 from Joey Ye  ---
Repost from another record. It is annoying that after commenting one record it
automatically jumps to the next.

Here is good expansion:
;; _41 = _42 * 4;

(insn 20 19 0 (set (reg:SI 126 [ D.5038 ])
(ashift:SI (reg/v:SI 131 [ Int_1_Par_Val ])
(const_int 2 [0x2]))) -1
 (nil))

;; _40 = _2 + _41;

(insn 21 20 22 (set (reg:SI 136 [ D.5035 ])
(plus:SI (reg/v/f:SI 130 [ Arr_2_Par_Ref ])
(reg:SI 119 [ D.5036 ]))) -1
 (nil))

(insn 22 21 0 (set (reg/f:SI 125 [ D.5035 ])
(plus:SI (reg:SI 136 [ D.5035 ])
(reg:SI 126 [ D.5038 ]))) -1
 (nil))


;; MEM[(int[25] *)_51 + 20B] = _34;

(insn 29 28 30 (set (reg:SI 139)
(plus:SI (reg/v/f:SI 130 [ Arr_2_Par_Ref ])
(reg:SI 119 [ D.5036 ]))) Proc_8.c:23 -1
 (nil))

(insn 30 29 31 (set (reg:SI 140)
(plus:SI (reg:SI 139)
(reg:SI 126 [ D.5038 ]))) Proc_8.c:23 -1
 (nil))

(insn 31 30 32 (set (reg/f:SI 141)
(plus:SI (reg:SI 140)
(const_int 1000 [0x3e8]))) Proc_8.c:23 -1
 (nil))

(insn 32 31 0 (set (mem:SI (plus:SI (reg/f:SI 141)
(const_int 20 [0x14])) [2 MEM[(int[25] *)_51 + 20B]+0 S4 A32])
(reg:SI 124 [ D.5039 ])) Proc_8.c:23 -1
 (nil))

After cse1 140 can be replaced by 125, thus lead a series of transformation
make it much more efficient.

Here is bad expansion:
;; _40 = Arr_2_Par_Ref_22(D) + _12;

(insn 22 21 23 (set (reg:SI 138 [ D.5038 ])
(plus:SI (reg:SI 128 [ D.5038 ])
(reg:SI 121 [ D.5036 ]))) -1
 (nil))

(insn 23 22 0 (set (reg/f:SI 127 [ D.5035 ])
(plus:SI (reg/v/f:SI 132 [ Arr_2_Par_Ref ])
(reg:SI 138 [ D.5038 ]))) -1
 (nil))

;; _32 = _20 + 1000;

(insn 29 28 0 (set (reg:SI 124 [ D.5038 ])
(plus:SI (reg:SI 121 [ D.5036 ])
(const_int 1000 [0x3e8]))) Proc_8.c:23 -1
 (nil))

;; MEM[(int[25] *)_51 + 20B] = _34;

(insn 32 31 33 (set (reg:SI 141)
(plus:SI (reg/v/f:SI 132 [ Arr_2_Par_Ref ])
(reg:SI 124 [ D.5038 ]))) Proc_8.c:23 -1
 (nil))

(insn 33 32 34 (set (reg/f:SI 142)
(plus:SI (reg:SI 141)
(reg:SI 128 [ D.5038 ]))) Proc_8.c:23 -1
 (nil))

(insn 34 33 0 (set (mem:SI (plus:SI (reg/f:SI 142)
(const_int 20 [0x14])) [2 MEM[(int[25] *)_51 + 20B]+0 S4 A32])
(reg:SI 126 [ D.5039 ])) Proc_8.c:23 -1
 (nil))

Here cse doesn't happen, resulting in less optimal insns. Reason why cse
doesn't happen is unclear yet.

[Bug tree-optimization/54742] Switch elimination in FSM loop

[joey.ye at arm dot com]

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

--- Comment #36 from Joey Ye  ---
Please ignore previous comment as it shouldn't be here.

[Bug fortran/60232] [OOP] The rank of the element in the structure constructor does not match that of the component

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Feb 19 11:52:39 2014
New Revision: 207896

URL: http://gcc.gnu.org/viewcvs?rev=207896&root=gcc&view=rev
Log:
2014-02-19  Janus Weil  

PR fortran/60232
* expr.c (gfc_get_variable_expr): Don't add REF_ARRAY for dimensionful
functions, which are used as procedure pointer target.


2014-02-19  Janus Weil  

PR fortran/60232
* gfortran.dg/typebound_proc_33.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_proc_33.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/60232] [OOP] The rank of the element in the structure constructor does not match that of the component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from janus at gcc dot gnu.org ---
Fixed on trunk with r207896. Closing.

Thanks for the report!

[Bug fortran/60255] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Antony, is it possible for you to try the patch in comment 2, in order to check
if it produces the expected runtime behavior for your code?

[Bug debug/56563] no debuginfo for "explicit" operator

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #1 from Mark Wielaard  ---
PR debug/37959 did add support for explicit constructors by adding a
LANG_HOOKS_FUNCTION_DECL_EXPLICIT_P that dwarf2out uses to tag functions with
DW_AT_explicit attributes.

[Bug c/59933] for loop goes wild with assert() enabled

[warnerme at ptd dot net]

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

--- Comment #5 from Mark Warner  ---
sizeof(NSQ_del_dec_struct) / sizeof(opus_int32) is guaranteed to produced a
even number with a remainder of 0.
Note the __attribute__ ((__aligned__ (8))) to make it a multiple of 8 in size.

[Bug c++/60272] atomic<>::compare_exchange_weak has spurious store and can cause race conditions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rth at gcc dot gnu.org,
   ||torvald at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Even our __atomic_compare_exchange* documentation states that:
If they are not equal, the current contents of
@code{*@var{ptr}} is written into @code{*@var{expected}}.
But then expand_builtin_atomic_compare_exchange doesn't care:
  oldval = expect;
  if (!expand_atomic_compare_and_swap ((target == const0_rtx ? NULL : &target),
   &oldval, mem, oldval, desired,
   is_weak, success, failure))
return NULL_RTX;

  if (oldval != expect)
emit_move_insn (expect, oldval);

That effectively means that expect will be stored unconditionally.
So, either we'd need to change this function, so that it sets oldval to
NULL_RTX
first, and passes ..., &oldval, mem, expected, ... and needs to also always ask
for target, then conditionally on target store to expected, or perhaps add
extra parameter to expand_atomic_compare_and_swap and do the store only
conditionally in that case.  Richard/Torvald?

[Bug c++/60273] New: gcc gets confused when one class uses variadic

[walter.mascarenhas at gmail dot com]

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

Bug ID: 60273
   Summary: gcc gets confused when one class uses variadic
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walter.mascarenhas at gmail dot com

Created attachment 32171
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32171&action=edit
gcc asked me to submit this file

//
// When compiling this file in Ubuntu 13.04, gcc 4.8.1 crashes with the
// following message. Clang 3.0 compiles the file with no problems.
//
// /home/walter/code/klein/tests/platform/gcc_bug/main.cc:-1: In instantiation
of 'struct Bar >':
// /home/walter/code/klein/tests/platform/gcc_bug/main.cc:25: required from
here
// /home/walter/code/klein/tests/platform/gcc_bug/main.cc:20: internal compiler
error: Segmentation fault
//  template using Buggy = typename X::template S;
// :-1: error: [main.o] Error 1^
//

struct A {};

template 
struct Foo
{
  using Type = int;

  // if the next line is replaced by template  then all is fine
  template 
  using S = A;
};

template 
struct Bar
{
  // if the next line is commented then all is fine.
  using Type = typename X::Type;

  // if the next line is commented then all is fine.
  template using Buggy = typename X::template S;
};

void foobar()
{
  Bar< Foo > bf;
}

[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887

[slayoo at staszic dot waw.pl]

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

--- Comment #7 from Sylwester Arabas  ---
Created attachment 32172
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32172&action=edit
preprocessed source trigerring ICE with g++ snapshot 20140212

Thanks a lot for looking at it.
I'm attaching the source proprocessed with g++ 4.8.2.
It gives the tsubst_copy ICE with the 20140212 g++ snapshot.

HTH,
Sylwester

[Bug c++/60274] New: String as template parameter - regression in 4.8.2

[ondrej.kolacek1 at centrum dot cz]

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

Bug ID: 60274
   Summary: String as template parameter - regression in 4.8.2
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ondrej.kolacek1 at centrum dot cz

Greetings, this issue happened to me with Debian's g++ so it is possible it is
just their bug but hopefully (well this is debatable :) ) it is not.



typedef const char *const&  ProtocolIdType;
//typedef int ProtocolIdType;

template 
class C {
public:
typedef int ProtocolVersion;

class D
{
public:
ProtocolVersion GetProtocolVersion();
};

};
template 
typename C::ProtocolVersion C::D::GetProtocolVersion()
{
return 1;
}

int main(void)
{
}


>g++ test.cpp
test.cpp:18:41: error: prototype for ‘typename C::ProtocolVersion
C::D::GetProtocolVersion()’ does not match any in class
‘C::D’
 typename C::ProtocolVersion C::D::GetProtocolVersion()
 ^
test.cpp:13:19: error: candidate is: C::ProtocolVersion
C::D::GetProtocolVersion()
   ProtocolVersion GetProtocolVersion();


The code used to work for ages, is compilable with MSVC, clang and gcc on
various platforms, was compilable with 4.8.1 but broke with 4.8.2. The issue is
with string template parameter; replacing 
typedef const char *const&  ProtocolIdType;
by 
typedef int ProtocolIdType;
makes the error go away.


> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-15'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-15)

[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887

[slayoo at staszic dot waw.pl]

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

--- Comment #8 from Sylwester Arabas  ---
BTW, I have initially reported it as a comment to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60198 (the same file/line in ICE
error message).

S.

[Bug c++/60274] [4.8/4.9 Regression] String as template parameter - regression in 4.8.3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||4.8.2
   Keywords||rejects-valid
   Last reconfirmed||2014-02-19
 Ever confirmed|0   |1
Summary|String as template  |[4.8/4.9 Regression] String
   |parameter - regression in   |as template parameter -
   |4.8.2   |regression in 4.8.3
   Target Milestone|--- |4.8.3
  Known to fail||4.8.3, 4.9.0

--- Comment #1 from Richard Biener  ---
Actually 4.8.2 works but the top of the branch doesn't.

[Bug sanitizer/60275] New: [UBSAN] Add -f[no-]sanitize-recover/-fsanitize-undefined-trap-on-error to make UBSAN's runtime errors fatal

[burnus at gcc dot gnu.org]

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

Bug ID: 60275
   Summary: [UBSAN] Add
-f[no-]sanitize-recover/-fsanitize-undefined-trap-on-e
rror to make UBSAN's runtime errors fatal
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
mpolacek at gcc dot gnu.org

While I personally would like to see more fine tuning via UBSAN_FLAGS - similar
to ASAN, LSAN and TSAN, adding CLANG's -fsanitize-recover/-fno-sanitize-recover
and  -fsanitize-undefined-trap-on-error would be useful as additional feature.

>From CLANG:

   Extra features of UndefinedBehaviorSanitizer:

   -  ``-fno-sanitize-recover``: By default, after a sanitizer diagnoses
  an issue, it will attempt to continue executing the program if there
  is a reasonable behavior it can give to the faulting operation. This
  option causes the program to abort instead.
   -  ``-fsanitize-undefined-trap-on-error``: Causes traps to be emitted
  rather than calls to runtime libraries when a problem is detected.
  This option is intended for use in cases where the sanitizer runtime
  cannot be used (for instance, when building libc or a kernel module).
  This is only compatible with the sanitizers in the ``undefined-trap``
  group.

That would be BUILT_IN_UNREACHABLE and BUILT_IN_TRAP. (But unreachable
shouldn't be dressed by SANITIZE_UNREACHABLE ;-)

See also LLVM's
* tools/clang/docs/UsersManual.rst
* tools/clang/lib/CodeGen/CGExpr.cpp (search for SanitizeUndefinedTrapOnError
and SanitizeRecover)

[Bug c/59933] for loop goes wild with assert() enabled

[warnerme at ptd dot net]

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

--- Comment #6 from Mark Warner  ---
If it is invalid, why does -Wall not trigger anything ?

[Bug ipa/60266] [4.9 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:261 during LibreOffice LTO build

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
It's caused by mixing -O0 and -O2 with LTO:

markus@x4 ~S % cat TableCopyHelper.ii
namespace com {
namespace sun {
namespace star {}
}
}
namespace css = com::sun::star;
namespace com {
namespace sun {
namespace star {
class A {};
template  class C : A {
public:
  interface_type *operator->();
};
}
}
typedef struct {
} uno_Any;
namespace sun {
namespace star {
class D : uno_Any {};
class B {
  virtual css::D m_fn1();
  virtual void m_fn2();
  virtual void m_fn3();
};
class F : css::B {
  virtual int m_fn4();
};
namespace sdb {
namespace application {
class XCopyTableWizard : css::F {
public:
  virtual void m_fn5();
  virtual void m_fn6();
};
}
}
}
}
using namespace com::sun::star;
using namespace com::sun::star::sdb::application;
void fn1(C &&) try {
  C a;
  a->m_fn6();
}
catch (int &) {
}
}


markus@x4 ~S % cat copytablewizard.ii
namespace com {
namespace sun {
namespace star {
class A {};
namespace sdb {
namespace application {
class XCopyTableWizard {
  virtual int m_fn1();
};
}
}
}
}
}
class OPropertyArrayUsageHelper {
public:
  virtual ~OPropertyArrayUsageHelper();
};
using com::sun::star::A;
using com::sun::star::sdb::application::XCopyTableWizard;
class CopyTableWizard : XCopyTableWizard, OPropertyArrayUsageHelper {
  ~CopyTableWizard();
};
CopyTableWizard::~CopyTableWizard() try {}

catch (A &) {
}


markus@x4 ~S % g++ -flto -fPIC -O0 -c copytablewizard.ii
markus@x4 ~S % g++ -flto -fPIC -std=gnu++11 -O2 -c TableCopyHelper.ii
markus@x4 ~S % g++ -w -r -nostdlib -O2 TableCopyHelper.o copytablewizard.o
lto1: internal compiler error: in ipa_get_parm_lattices, at ipa-cp.c:261
0x50c7ac ipa_get_parm_lattices
../../gcc/gcc/ipa-cp.c:261
0xc41824 ipa_get_parm_lattices
../../gcc/gcc/ipa-cp.c:261
0xc41824 propagate_constants_accross_call
../../gcc/gcc/ipa-cp.c:1443
0xc44308 propagate_constants_topo
../../gcc/gcc/ipa-cp.c:2231
0xc44308 ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:2327
0xc44308 ipcp_driver
../../gcc/gcc/ipa-cp.c:3705
0xc44308 execute
../../gcc/gcc/ipa-cp.c:3804
Please submit a full bug report,
with preprocessed source if appropriate.

(I think the ODR violation got introduced during reduction.)

[Bug sanitizer/60275] [UBSAN] Add -f[no-]sanitize-recover/-fsanitize-undefined-trap-on-error to make UBSAN's runtime errors fatal

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-02-19
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Mine.  I think this is 5.0 material.

[Bug other/50925] [4.7/4.8/4.9 Regression][avr] ICE at spill_failure, at reload1.c:2118

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #28 from Jorn Wolfgang Rennecke  ---
I can't reproduce this with the current trunk.  Can was mark this
as "known to work" for 4.9 ?

[Bug ipa/60243] IPA is slow on large cgraph tree

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 19 14:25:47 2014
New Revision: 207899

URL: http://gcc.gnu.org/viewcvs?rev=207899&root=gcc&view=rev
Log:
2014-02-19  Richard Biener  

PR ipa/60243
* tree-inline.c (estimate_num_insns): Avoid calling cgraph_get_node
for all calls.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-inline.c

[Bug c/59933] for loop goes wild with assert() enabled

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
(int)(sizeof(NSQ_del_dec_struct) / sizeof(opus_int32) seems to be 1168/4 = 292,
but sLPC_Q14 has only 112 elements.

[Bug rtl-optimization/60155] ICE: in get_pressure_class_and_nregs at gcse.c:3438

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||mikulas at artax dot 
karlin.mff.cu
   ||ni.cz

--- Comment #5 from John David Anglin  ---
*** Bug 54737 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/54737] ICE on PA-RISC with LTO and -ftrapv

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||danglin at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from John David Anglin  ---
There is a patch in 60155 that probably fixes this PR.

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

[Bug target/57232] wcstol.c:213:1: internal compiler error

[gcc at jaseg dot net]

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

--- Comment #16 from Sebastian Götte  ---
Alexandre, curiously, applying this patch to the cross-compiler source tree
fixes the problem for me building 4.8.2 for rx-elf using a 4.8.2 x86_64 host
gcc. I did not even have to rebuild the host gcc.

[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation

[yroux at gcc dot gnu.org]

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

--- Comment #9 from yroux at gcc dot gnu.org ---
Author: yroux
Date: Wed Feb 19 15:32:54 2014
New Revision: 207908

URL: http://gcc.gnu.org/viewcvs?rev=207908&root=gcc&view=rev
Log:
2014-02-19  Michael Hudson-Doyle  

 PR target/59799
* config/aarch64/aarch64.c (aarch64_pass_by_reference): The rules for
passing arrays in registers are the same as for structs, so remove the
special case for them.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug target/57232] wcstol.c:213:1: internal compiler error

[nickc at redhat dot com]

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

--- Comment #17 from Nick Clifton  ---
Hi Alex,

>   if (reg != hard_frame_pointer_rtx && fixed_regs[REGNO (reg)])
>  cselib_preserve_cfa_base_value (val, REGNO (reg));

This works for the RX port - thanks!

Cheers
   Nick

[Bug c++/60274] [4.8/4.9 Regression] String as template parameter - regression in 4.8.3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r207167.

[Bug c++/60064] [c++1y] ICE with auto as parameter of friend function

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #3 from Volker Reichelt  ---
Fixed with Adam's patch.

[Bug debug/56563] no debuginfo for "explicit" operator

[mark at gcc dot gnu.org]

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

--- Comment #2 from Mark Wielaard  ---
Jakub proposed a patch:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01166.html

[Bug c/59933] for loop goes wild with assert() enabled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
The code is not invalid C, just triggers undefined behavior, so it is not
invalid at compile time, just at runtime if you ever hit this.
GCC optimizes based on the assumption that undefined behavior doesn't happen in
a correct program.
While we have -Waggressive-loop-optimizations warning, it (intentionally) warns
solely about the case where the loop has single exit and constant loop
iteration count, which is not the case here, the number of iterations is
i >= 292 ? 0 : 292 - i.
The loop will trigger undefined behavior whenever i is < 292, if it is bigger,
then there is no bug.

[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org ---
The latest patch posted at

http://gcc.gnu.org/ml/fortran/2014-02/msg00109.html

works smoothly on the test case in comment 12.

[Bug target/59794] [4.7/4.8 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes

[uros at gcc dot gnu.org]

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

--- Comment #17 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Feb 19 15:53:59 2014
New Revision: 207910

URL: http://gcc.gnu.org/viewcvs?rev=207910&root=gcc&view=rev
Log:
PR target/59794
* config/i386/i386.c (type_natural_mode): Warn for ABI changes
only when -Wpsabi is enabled.

testsuite/ChangeLog:

PR target/59794
* gcc.target/i386/pr39162.c: Add dg-prune-output.
(dg-options): Remove -Wno-psabi.
* gcc.target/i386/59794-2.c: Ditto.
* gcc.target/i386/60205-1.c: Ditto.
* gcc.target/i386/sse-5.c: Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr39162.c
trunk/gcc/testsuite/gcc.target/i386/pr59794-2.c
trunk/gcc/testsuite/gcc.target/i386/pr59794-3.c
trunk/gcc/testsuite/gcc.target/i386/pr60205-1.c
trunk/gcc/testsuite/gcc.target/i386/sse-5.c

[Bug c++/60251] [4.9 Regression] [c++11] ICE capturing variable-length array

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
Not sure this is valid. Anyway, the ICE is due to the COMPONENT_REF being
wrapped in a NOP_EXPR.

[Bug target/59797] GCC doesn't warn AVX-512 ABI change

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #3 from Uroš Bizjak  ---
Dup.

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

[Bug target/60205] No ABI warning for AVX-512

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
*** Bug 59797 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/57320] [4.9 Regression] Shrink-wrapping leaves unreachable blocks in the CFG

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This has been fixed by r204211 on the trunk, any reason to keep this PR open?

Note that Steven's patch has been approved, but never committed:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01020.html

[Bug c/59933] for loop goes wild with assert() enabled

[ian at g0tcd dot com]

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

--- Comment #9 from Ian Hamilton  ---
Yes, that's all proper and correct. The invalid C code induces undefined
behaviour. I don't think anyone is disputing that.

However, to be pragmatic for a moment, the experience of thousands of
developers out there, working with legacy code, and trying to update their
toolset to include gcc 4.8 is that code which compiled without warnings and
worked with the old gcc compiler now still compiles without warnings, but fails
at runtime with the 4.8 series compiler.

Sometimes, the runtime failures are occasional and difficult to track down if
(for example) it lies on an error handling path. This makes it even harder for
these developers to figure out what's going on.

If the compiler could provide a warning when it encounters this sort of invalid
code, that would be a good thing, as it would highlight the old latent bugs and
give developers the opportunity to fix them.

However, it doesn't, so the developers working on legacy code really have no
alternative to either using the -fno-aggressive-loop-optimizations switch to
stabilse their legacy code (even assuming they understand what's happening), or
sticking with the old version of the compiler.

So I think the request to the gcc developers is to find a way of providing a
compiler warning when the loop optimiser encounters problem code, to give
developers a fighting chance of debugging their legacy code.

[Bug c/59933] for loop goes wild with assert() enabled

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
We have -fsanitize=undefined which can catch some issues, though the array
bounds instrumentation (nor __builtin_object_size based instrumentation) has
not been added yet for GCC 4.9, will be hopefully there in the next release.
As for warnings, even the current -Waggressive-loop-optimizationsh warning (for
the const number of iterations, single loop exit easy case where you know that
if the loop is reachable, if there is undefined behavior in some loop
iteration, you will trigger it) still has occassional false positives (various
PRs about that, usually the issue is that while it is true there is such a
loop, the loop is actually dead), further warnings would have huge false
positive rate, to the extent that it would be rarely useful.

[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 19 16:45:21 2014
New Revision: 207911

URL: http://gcc.gnu.org/viewcvs?rev=207911&root=gcc&view=rev
Log:
PR c++/60267
* c-pragma.c (init_pragma): Don't call cpp_register_deferred_pragma
for PRAGMA_IVDEP if flag_preprocess_only.

* gcc.dg/pr60267.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr60267.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/testsuite/ChangeLog

[Bug target/59794] [4.7/4.8 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes

[uros at gcc dot gnu.org]

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

--- Comment #18 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Feb 19 16:50:22 2014
New Revision: 207912

URL: http://gcc.gnu.org/viewcvs?rev=207912&root=gcc&view=rev
Log:
Backport from mainline
2014-02-19  Uros Bizjak  

PR target/59794
* config/i386/i386.c (type_natural_mode): Warn for ABI changes
only when -Wpsabi is enabled.

testsuite/ChangeLog:

Backport from mainline
2014-02-19  Uros Bizjak  

PR target/59794
* gcc.target/i386/pr39162.c: Add dg-prune-output.
(dg-options): Remove -Wno-psabi.
* gcc.target/i386/pr59794-2.c: Ditto.
* gcc.target/i386/sse-5.c: Ditto.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59794-1.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59794-2.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59794-3.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59794-4.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59794-5.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59794-6.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59794-7.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr39162.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/sse-5.c

[Bug target/59797] GCC doesn't warn AVX-512 ABI change

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59797
Bug 59797 depends on bug 59794, which changed state.

Bug 59794 Summary: [4.7/4.8 Regression] i386 backend fails to detect 
MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug target/59794] [4.7/4.8 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.7.4   |4.8.3

--- Comment #19 from Uroš Bizjak  ---
This is now implemented for 4.8.3 and 4.9, including -Wpsabi option.

No plan to backport these patches to 4.7.x.

FIXED for 4.8.3+.

[Bug other/50925] [4.7/4.8/4.9 Regression][avr] ICE at spill_failure, at reload1.c:2118

[corsepiu at gcc dot gnu.org]

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

Ralf Corsepius  changed:

   What|Removed |Added

 CC||corsepiu at gcc dot gnu.org

--- Comment #29 from Ralf Corsepius  ---
(In reply to Jorn Wolfgang Rennecke from comment #28)
> I can't reproduce this with the current trunk.
Confirmed. gcc-4.9 doesn't show this bug for --target=avr-rtems4.11, anymore.

>  Can was mark this
> as "known to work" for 4.9 ?
I am inclined to agree.

[Bug c/37743] Bogus printf format warning with __builtin_bswap32.

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
Yes, we could do something like that (but I also think it's time to put 
the targets without this type information on the deprecation list and warn 
their maintainers that the target support will be removed in the absence 
of this information being added soon).

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Vittorio Zecca from comment #6)

> As an aside, in gcc 4.8.1 source code, before line 6995 of gcc/expr.c I put
>  
> printf("\nexpr.c:6995 value->code=%d NUM_RTX_CODE=%d\n",(int)
> value->code,NUM_RTX_CODE);
> gcc_assert((int) value->code < NUM_RTX_CODE);
> 
> and I get an ICE there because value->code is 34816 and NUM_RTX_CODE is 145
> 
> Indeed at line 6995 ARITHMETIC_P (value) accesses rtx_class[(int)
> value->code]
> but the array rtx_class has only NUM_RTX_CODE elements.
> However, I do not know how this is relevant to this issue.

This one points to infrastructure problem.

Adding a debug patch:

--cut here--
Index: explow.c
===
--- explow.c(revision 207910)
+++ explow.c(working copy)
@@ -186,8 +186,13 @@ plus_constant (enum machine_mode mode, rtx x, HOST
 }

   if (c != 0)
-x = gen_rtx_PLUS (mode, x, GEN_INT (c));
+{
+  rtx z = GEN_INT (c);
+  printf ("cc, %li\n", c);
+  debug_rtx (z);

+  x = gen_rtx_PLUS (mode, x, z);
+}
   if (GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF)
 return x;
   else if (all_constant)
--cut here--

~/gcc-build-48/gcc/cc1 pr57896.c

...
 __get_cpuidcc, -4
(const_int -4 [0xfffc])
cc, -16
(const_int -16 [0xfff0])
cc, -24
(const_int -24 [0xffe8])
cc, -32
(const_int -32 [0xffe0])
cc, -40
(??? bad code 47104
)

pr57896.c: In function ‘__get_cpuid’:
pr57896.c:5:5: internal compiler error: in emit_move_insn_1, at expr.c:3437
 int __get_cpuid (unsigned int __level, unsigned int *__eax, unsigned int
*__ebx, unsigned int *__ecx, unsigned int *__edx) {
 ^
0x62d74d emit_move_insn_1(rtx_def*, rtx_def*)
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/expr.c:3437
0x62d7b5 emit_move_insn(rtx_def*, rtx_def*)
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/expr.c:3535

Please note that the debug patch only encloses GEN_INT (...)

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Vittorio Zecca from comment #5)

> Adding option -m32 I get ICE in ix86_expand_prologue, at
> config/i386/i386.c:10559

I can confirm this with:

gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910] (GCC)

~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

pr57896.c: In function ‘__get_cpuid_max’:
pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at
config/i386/i386.c:10539
 }
 ^
0x98fdf5 ix86_expand_prologue()
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10539
0xa1ce5a gen_prologue()
   
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829
0x673927 thread_prologue_and_epilogue_insns
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949
0x673927 rest_of_handle_thread_prologue_and_epilogue
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973

The output from the debug patch doesn't look suspicious, so this looks like a
real bug to me. Can someone please bisect which commit fixed/hid this bug?

[Bug c/37743] Bogus printf format warning with __builtin_bswap32.

[jakub at gcc dot gnu.org]

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

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

Untested fix.  The deprecation can hopefully be done separately.

[Bug target/60207] Wrong TFmode check in construct_container

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Feb 19 18:10:04 2014
New Revision: 207913

URL: http://gcc.gnu.org/viewcvs?rev=207913&root=gcc&view=rev
Log:
Remove TFmode check for X86_64_INTEGER_CLASS

PR target/60207
* config/i386/i386.c (construct_container): Remove TFmode check
for X86_64_INTEGER_CLASS.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 19 18:11:54 2014
New Revision: 207914

URL: http://gcc.gnu.org/viewcvs?rev=207914&root=gcc&view=rev
Log:
PR c++/60267
* pt.c (tsubst_expr): Handle ANNOTATE_EXPR.

* g++.dg/ext/ivdep-1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/ivdep-1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/56563] no debuginfo for "explicit" operator

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 19 18:12:31 2014
New Revision: 207915

URL: http://gcc.gnu.org/viewcvs?rev=207915&root=gcc&view=rev
Log:
PR debug/56563
* cp-objcp-common.c (cp_function_decl_explicit_p): Remove
FUNCTION_FIRST_USER_PARMTYPE (decl) != void_list_node check.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.c

[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/60272] atomic<>::compare_exchange_weak has spurious store and can cause race conditions

[torvald at gcc dot gnu.org]

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

--- Comment #2 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> So, either we'd need to change this function, so that it sets oldval to
> NULL_RTX
> first, and passes ..., &oldval, mem, expected, ... and needs to also always
> ask for target, then conditionally on target store to expected, or perhaps
> add extra parameter to expand_atomic_compare_and_swap and do the store only
> conditionally in that case.  Richard/Torvald?

I'm not sure what's better.  But getting this fixed in 4.9.0 would be good! :)

[Bug c/37743] Bogus printf format warning with __builtin_bswap32.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Jakub Jelinek  ---
Fixed.  That said, both testcases in this PR are inherently non-portable, on
some targets __builtin_bswap32 returns unsigned long, on most unsigned int,
could be even unsigned long long.  So, one should really use uint32_t and
PRIu32.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to Vittorio Zecca from comment #5)
> 
> > Adding option -m32 I get ICE in ix86_expand_prologue, at
> > config/i386/i386.c:10559
> 
> I can confirm this with:
> 
> gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910]
> (GCC)
> 
> ~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

This is the same problem, as confirmed by following debug patch:

--cut here--
Index: i386.c
===
--- i386.c  (revision 207912)
+++ i386.c  (working copy)
@@ -10449,8 +10449,12 @@ ix86_expand_prologue (void)
   else if (!ix86_target_stack_probe ()
   || frame.stack_pointer_offset < CHECK_STACK_LIMIT)
 {
+  rtx x = GEN_INT (-allocate);
+
+  printf ("\nTestP1 %li\n", -allocate);
+  debug_rtx (x);
   pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
-GEN_INT (-allocate), -1,
+x, -1,
 m->fs.cfa_reg == stack_pointer_rtx);
 }
   else
@@ -10536,6 +10540,7 @@ ix86_expand_prologue (void)
  gen_frame_mem (word_mode, t));
}
 }
+  printf ("\nTestP2 %li %li\n", m->fs.sp_offset, frame.stack_pointer_offset);
   gcc_assert (m->fs.sp_offset == frame.stack_pointer_offset);

   /* If we havn't already set up the frame pointer, do so now.  */
--cut here--

GEN_INT (...) produces some non-sensical RTX, and INTVAL at the end of
pro_epilogue_adjust_stack chokes on it.

  m->fs.sp_offset = ooffset - INTVAL (offset);
  m->fs.sp_valid = valid;

~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

...

TestP1 -56
(??? bad code 42752
)

TestP2 -139787679344504 64

pr57896.c: In function ‘__get_cpuid_max’:
pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at
config/i386/i386.c:10544
 }
 ^
0x98fe35 ix86_expand_prologue()
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10544
0xa1ce9a gen_prologue()
   
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829
0x673927 thread_prologue_and_epilogue_insns
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949
0x673927 rest_of_handle_thread_prologue_and_epilogue
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973

[Bug c++/60272] atomic<>::compare_exchange_weak has spurious store and can cause race conditions

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Henderson  ---
Agreed.  Mine.

[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jakub Jelinek  ---
Should be fixed now.

[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at redhat dot com
  Component|target  |middle-end
Version|4.8.1   |4.8.3

--- Comment #12 from Uroš Bizjak  ---
Reconfirmed on 4.8.3 as "middle-end" catch-all bug.

Adding some CCs that might be interested in this PR.

[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887

[slayoo at staszic dot waw.pl]

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

--- Comment #12 from Sylwester Arabas  ---
Thanks a lot! I'll try it as soon as it will get into Debian's gcc-snapshot
package.

Sylwester

[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Feb 19 19:03:19 2014
New Revision: 207917

URL: http://gcc.gnu.org/viewcvs?rev=207917&root=gcc&view=rev
Log:
PR c++/60046
* pt.c (maybe_instantiate_noexcept): Don't instantiate exception
spec from template context.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/noexcept22.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Seems like r196890 made this latent.

[Bug tree-optimization/45833] Unnecessary runtime versioning for aliasing

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Same thing without a union:

struct v { int v[4]; } __attribute__ ((aligned (4 * sizeof (int;
void
f (struct v *x, struct v *y, struct v *z)
{
  for (int i = 0; i < 4; i++)
x->v[i] = y->v[i] + z->v[i];
}

produces (with -msee4.2):

leaq16(%rsi), %rcx
leaq16(%rdi), %rax
cmpq%rcx, %rdi
setae   %r8b
cmpq%rsi, %rax
setbe   %cl
orb %cl, %r8b
je  .L5
leaq16(%rdx), %rcx
cmpq%rcx, %rdi
setae   %cl
cmpq%rdx, %rax
setbe   %al
orb %al, %cl
je  .L5
vmovdqa (%rsi), %xmm0
vpaddd  (%rdx), %xmm0, %xmm0
vmovaps %xmm0, (%rdi)
ret
...

[Bug c/60276] New: -O3 autovectorizer breaks on a particular loop

[maister at archlinux dot us]

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

Bug ID: 60276
   Summary: -O3 autovectorizer breaks on a particular loop
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maister at archlinux dot us

Created attachment 32174
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32174&action=edit
Reduced testcase

GCC 4.8.2 with -O3 breaks a certain loop I'm compiling. Disabling the
vectorizer with -fno-tree-vectorize fixes the issue, as well as compiling with
-O2.

I've reduced the problem to a small test case which is attached as legall.c.

Distro: Arch Linux x86_64
gcc -v: 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8-20140206/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-cloog-version-check --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.2 20140206 (prerelease) (GCC)

Miscompile: gcc -o legall legall.c -std=gnu99 -O3
Working: gcc -o legall legall.c -std=gnu99 -O3 -fno-tree-vectorize

Expected output:
(0) (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17)
(18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30) (31) (32) (33)
(34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46) (47) (48)

Wrong output by -O3:
(0) (1) (2) (2) (4) (3) (6) (4) (8) (5) (10) (6) (12) (7) (14) (8) (16) (17)
(18) (10) (20) (11) (22) (12) (24) (13) (26) (14) (28) (15) (30) (16) (32) (33)
(34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46) (47) (48)

[Bug c++/60277] New: Bogus "inline function virtual ..." used but never defined

[ppluzhnikov at google dot com]

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

Bug ID: 60277
   Summary: Bogus "inline function virtual ..." used but never
defined
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Test case:

struct Foo {
  inline virtual void func() = 0;
};

struct Bar : public Foo {
  void func() { }
};

int main()
{
  Foo *f = new Bar;
  f->func();
}


Using trunk:
g++ (GCC) 4.9.0 20140219 (experimental)

g++ -c -Wall -Wextra t.cc
t.cc:2:23: warning: inline function 'virtual void Foo::func()' used but never
defined
   inline virtual void func() = 0;
   ^


But Foo::func is never actually used.

Analysis by Nick Lewycky:


The relevant [basic.odr]/2 text is:
  "A virtual member function is odr-used if it is not pure. A non-overloaded
function whose name appears as a potentially-evaluated expression or a member
of a set of candidate functions, if selected by overload resolution when
referred to from a potentially-evaluated expression, is odr-used, unless it is
a pure virtual function and its name is not explicitly qualified."

Since the function isn't ODR-used, there's no need for it to have a definition:
  "An inline function shall be defined in every translation unit in which it is
odr-used." [basic.odr]/3

[Bug debug/56563] no debuginfo for "explicit" operator

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Mark Wielaard  ---
With the patch we get the following for the example in the description:

 [37]  subprogram
   external (flag_present) Yes
   name (strp) "operator int"
   decl_file(data1) 1
   decl_line(data1) 3
   linkage_name (strp) "_ZN1qcviEv"
   type (ref4) [51]
   declaration  (flag_present) Yes
   explicit (flag_present) Yes
   object_pointer   (ref4) [4a]

[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Feb 19 19:59:07 2014
New Revision: 207921

URL: http://gcc.gnu.org/viewcvs?rev=207921&root=gcc&view=rev
Log:
PR c++/60046
* pt.c (maybe_instantiate_noexcept): Don't instantiate exception
spec from template context.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/noexcept22.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/pt.c

[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Feb 19 19:59:09 2014
New Revision: 207922

URL: http://gcc.gnu.org/viewcvs?rev=207922&root=gcc&view=rev
Log:
PR c++/60046
* pt.c (maybe_instantiate_noexcept): Don't instantiate exception
spec from template context.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/noexcept22.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/pt.c

[Bug c++/60273] gcc gets confused when one class uses variadic

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
My understanding is that your example is touching an open language issue,
namely

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1430

The current tendency seems to be that this should be ill-formed (personally I'm
not happy with that decision). Current clang and gcc do both reject your code.
I suggest to mark this issue as deferred pending 1430.

[Bug c++/60273] gcc gets confused when one class uses variadic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2014-02-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Ok, suspended for now.

[Bug c/59933] for loop goes wild with assert() enabled

[warnerme at ptd dot net]

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

--- Comment #11 from Mark Warner  ---
I'm confused .. what about..
for (k = i; k < (int)(sizeof(NSQ_del_dec_struct) / sizeof(opus_int32)); ++k)
... is illegal or invalid ?
Why does it only fail if -DDEBUG is defined ?
I mean, this code worked fine for months .. and now

[Bug c/59933] for loop goes wild with assert() enabled

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Mark Warner from comment #11)
> I'm confused .. what about..
> for (k = i; k < (int)(sizeof(NSQ_del_dec_struct) / sizeof(opus_int32)); ++k)
> ... is illegal or invalid ?
> Why does it only fail if -DDEBUG is defined ?
> I mean, this code worked fine for months .. and now

The undefined behavior is if i is smaller than 292, you access out of bound
array members (well, in C already the address arithmetics is undefined behavior
when you go further than one past the last element of the array).
The sLPC_Q14 has only 112 entries, so say if i is 0, then when k is 112, you
invoke undefined behavior, because you can't read or write sLPC_Q14[112].

[Bug libstdc++/51823] [DR 198] [DR 2204] reverse iterator returns uninitialized values

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

--- Comment #17 from Jonathan Wakely  ---
The definition of reverse_iterator has been reverted to the C++03 version,
which does not use an extra member, so "stashing iterators" can not be used
with reverse_iterator.

[Bug c++/60277] Bogus "inline function virtual ..." used but never defined

[nlewycky at google dot com]

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

--- Comment #1 from Nick Lewycky  ---
Furthermore, if the testcase ended with:

  f->Foo::func();

then the warning should be issued.

[Bug middle-end/52306] [4.8 regression] ICE in cselib_record_set, at cselib.c:2158

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

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

--- Comment #31 from Andreas Schwab  ---
Created attachment 32175
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32175&action=edit
Testcase from jumpnbump

After backporting the patch to 4.8 there is still a package that fails with the
same error, though it doesn't fail with 4.9.

$ gcc/xgcc -B gcc/ -O -fomit-frame-pointer filter.i 
filter.i: In function ‘do_scale2x’:
filter.i:202:1: internal compiler error: in cselib_record_set, at cselib.c:2373
 }
 ^
0x5c092e cselib_record_set
../../gcc/gcc/cselib.c:2373
0x5c092e cselib_record_sets
../../gcc/gcc/cselib.c:2590
0x5c0c8f cselib_process_insn(rtx_def*)
../../gcc/gcc/cselib.c:2665
0x753c27 reload_cse_regs_1
../../gcc/gcc/postreload.c:222
0x75426b reload_cse_regs
../../gcc/gcc/postreload.c:68
0x75426b rest_of_handle_postreload
../../gcc/gcc/postreload.c:2287