[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 11 09:06:37 2014
New Revision: 207686

URL: http://gcc.gnu.org/viewcvs?rev=207686&root=gcc&view=rev
Log:
PR target/59927
* gcc.target/i386/pr59927.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr59927.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Seems to be fixed.

[Bug libfortran/59836] [4.7/4.8 Regression] Wrong outputs with rounding formats for some values.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Wrong
   |Wrong outputs with rounding |outputs with rounding
   |formats for some values.|formats for some values.

--- Comment #11 from Dominique d'Humieres  ---
Fixed on trunk (4.9).

[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[4.8/4.9 Regression]|[4.8 Regression]
   |Inconsistent rounding   |Inconsistent rounding
   |between -m32 and -m64   |between -m32 and -m64

--- Comment #16 from Dominique d'Humieres  ---
Fixed on trunk (4.9).

[Bug c/60139] Imprecise column number for -pedantic on non-computable initializer element

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I have a trivial patch for 1), queued up for 5.0.

Re 2), the bug is that pedwarn had 0 instead of OPT_Wpedantic.  I'll fix it up
in a separate patch.
(Seems like we're going to drop the "[enabled by default]" altogether, see
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00653.html.)

[Bug sanitizer/60142] New: [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[burnus at gcc dot gnu.org]

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

Bug ID: 60142
   Summary: [4.9 Regression][asan] -fsanitize=address breaks
debugging - stepping into functions no longer possible
   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

Created attachment 32100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32100&action=edit
Small C++ testcase

Debugging the following code works (on x86-64-linux) with GCC 4.8.3 20131205 -
or with GCC 4.9.0 20140211 and *without* -fsanitize=address.

Using ASAN, one has the following result. Namely, it is not possible to step
into the function "test()".

$ g++ -fsanitize=address -O0 -g test2.cxx
$ gdb ./a.out
...
(gdb) b main
Breakpoint 1 at 0x401131: file test2.cxx, line 15.

(gdb) run
Starting program: /data/local_users/tobiasb/xpcbool/unittests/a.out
Breakpoint 1, main () at test2.cxx:15
15test();

(gdb) s
0: 1
1: 2
2: 3
[Inferior 1 (process 6022) exited normally]

[Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Jakub Jelinek  ---
> Well, this isn't about main alignment (and, after all, main realigns the stack
> anyway), but about stack alignment upon entering pthread_create callbacks.
> If the Solaris libraries don't maintain 16-byte stack alignment, then either
> you could arrange to compile parts of libgomp with -mincoming-stack-boundary=2
> (or -mstackrealign) on Solaris/i?86 32-bit.  Or just make sure the default on
> Solaris is -mincoming-stack-boundary=2 or whatever the libraries do guarantee.

I've checked the Solaris 9 and OpenSolaris sources: on S9, there's just
the 4-byte alignment guaranteed by the i386 psABI.  On S10 and up, they
enforce 16-byte alignment for the benefit of SSE.

IMO, the best (most general) solution is to change STACK_REALIGN_DEFAULT
to 1 on Solaris 9/x86.  While it comes at a performance and code size
penalty, it's guaranteed to be correct.

I've bootstrapped a patch to do just that and as expected, the libgomp
failures are gone.

Unlike I'm overlooking something important, I'd like to check this patch
into mainline for 4.9.0.

Rainer

[Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-11
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
Created attachment 32101
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32101&action=edit
proposed patch

[Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
>From RM POV this is ok for 4.9.

[Bug fortran/60060] [4.9 Regression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Tobias Burnus from comment #6)
> (In reply to Dominique d'Humieres from comment #0)
> > warning: invalid DWARF generated by the compiler: DIE 0x01f0 has
> > multiple  AT_calling_convention attributes in
> > '/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccLHCwpM.ltrans0.ltrans.
> > o'.
> 
> (In reply to Dominique d'Humieres from comment #5)
> > The ICE is gone with the patch in comment 4 without regression. However on
> > darwin I still get the warnings reported in comment 0.
> 
> The calling convention should be (except on sh, cf. sh/sh.c's
> TARGET_DWARF_CALLING_CONVENTION) be always DW_CC_normal - which is not
> emitted as DWARF symbol. The only exception is Fortran's MAIN__ function,
> which is set to DW_CC_program.
> 
> I wonder whether you see twice DW_CC_program or some other DW_CC_*. You
> could try readelf to find out which AT_calling_convention are generated.

I see

 <1><18c>: Abbrev Number: 3 (DW_TAG_subprogram)
<18d>   DW_AT_name: (indirect string, offset: 0x175): mem_nml   
<191>   DW_AT_decl_file   : 1   
<192>   DW_AT_decl_line   : 4   
<193>   DW_AT_main_subprogram: 1
<193>   DW_AT_calling_convention: 2 (program)
<194>   DW_AT_inline  : 1   (inlined)
<195>   DW_AT_main_subprogram: 1
<195>   DW_AT_calling_convention: 2 (program)
<196>   DW_AT_sibling : <0x50b> 

with -O3 -g -flto and

 <1><185>: Abbrev Number: 2 (DW_TAG_subprogram)
<186>   DW_AT_name: (indirect string, offset: 0x1e0): mem_nml   
<18a>   DW_AT_decl_file   : 1   
<18b>   DW_AT_decl_line   : 4   
<18c>   DW_AT_main_subprogram: 1
<18c>   DW_AT_calling_convention: 2 (program)
<18d>   DW_AT_low_pc  : 0x400f45
<195>   DW_AT_high_pc : 0x15
<19d>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<19f>   DW_AT_GNU_all_tail_call_sites: 1
<19f>   DW_AT_main_subprogram: 1
<19f>   DW_AT_calling_convention: 2 (program)
<1a0>   DW_AT_sibling : <0x2a3> 

with -g

Looks like a different bug - can you please file it separately as this bug
assigned to me is about LTO issues?

add_calling_convention_attribute is called twice.  First via

Breakpoint 5, add_calling_convention_attribute (subr_die=0x76da1730, decl=
)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:16859
16859 enum dwarf_calling_convention value = DW_CC_normal;
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.18-4.11.1.x86_64 libgmp10-debuginfo-5.1.3-58.2.x86_64
(gdb) bt
#0  add_calling_convention_attribute (subr_die=0x76da1730, 
decl=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:16859
#1  0x008bc477 in gen_subprogram_die (
decl=, context_die=0x76d71000)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:18535
#2  0x008c1668 in force_decl_die (
decl=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20119
#3  0x008c1581 in get_context_die (
context=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20089
#4  0x008c15e6 in force_decl_die (decl=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20105
#5  0x008c2fb0 in gen_namelist_decl (
name=, scope_die=0x76da1640, 
item_decls=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20672
#6  0x008c27d0 in gen_decl_die (
decl=, origin=, 
context_die=0x76da1640)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20475
#7  0x008c0d75 in process_scope_var (stmt=, 
decl=, origin=, 
context_die=0x76da1640)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19984
#8  0x008c0df1 in decls_for_scope (stmt=, 
context_die=0x76da1640, depth=0)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20009
#9  0x008bbd94 in gen_subprogram_die (
decl=, context_die=0x0)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:18383
#10 0x008c220a in gen_decl_die (
decl=, origin=, 
context_die=0x0) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20376
#11 0x008c345f in dwarf2out_decl (
decl=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20808
#12 0x008c3481 in dwarf2out_function_decl (
decl=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20816
#13 0x0092e677 in rest_of_handle_final ()

and once via

Breakpoint 5, add_calling_convention_attribute (subr_die=0x76da1640, 
decl=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:16859
16859 enum dwarf_calling_convention value = DW_CC_normal;
#0  add_calling_convention_attribute (subr_die=0x76da1640, 
decl=)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:16859
#1  0x008bc477 in gen_subprogram_die (
decl=, context_die=0x0)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:18535
#2  0x00

[Bug c++/60143] New: AIX: gcc-4.8.2: for loop not entered when -maix64 and -O are set

[tgard at opentext dot com]

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

Bug ID: 60143
   Summary: AIX: gcc-4.8.2: for loop not entered when -maix64 and
-O are set
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tgard at opentext dot com

Created attachment 32102
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32102&action=edit
Makefile and simple repro of the bug

The bug disappears if I remove a member of SubpathRecord struct or if I change
int num_subpaths() to size_t num_subpaths() or if I use the commented code that
uses a variable for num_subpaths. Expected output is “0“, but with the bug I
get nothing

#include 
#include 

class Path
{
public:
int num_subpaths() const { return static_cast(m_subpaths.size()); }

struct SubpathRecord
{
intm_start_index;
intm_closed;
intm_type;
};

public:
Path()
{
m_subpaths.push_back( SubpathRecord() );
}

private:
std::vectorm_subpaths;
};


int main( void )
{
Path path;
//int num_subpaths( path.num_subpaths() );
//for( int j=0; j

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
So, I've started to add hash tables into the picture if tlist go over certain
number of elements, but while doing that I've noticed two issues in the
original code.

The first one is that merge_tlist either has misnamed argument (copy), or does
the wrong thing, because it copies when copy is false and doesn't copy if it is
true.  Most of the merge_tlist calls are with 0 and I think can reuse the tlist
structures, because the original list is not used anymore for anything
afterwards.  I don't understand:
  merge_tlist (pbefore_sp, tmp_list2, 1);
in COND_EXPR handling, tmp_tlist isn't used afterwards either, and
merge_tlist (pbefore_sp, t->cache_before_sp, 1);
in SAVE_EXPR handling looks to be the only place where we need to make copies
during merge_tlist.

The second issue is the SAVE_EXPR handling, where I don't understand at all
what is meant by the while (tmp_nosp) loop, because every merge_tlist iteration
already merges in all the tmp_nosp list elements into tmp_list3 (and because of
the broken merge_tlist copy handling creates copies of all those elements),
then it attempts to merge again all but the first one (but, that shouldn't add
anything, all the entries should be already merged in by the previous
merge_tlist call).

--- c-common.c.jj2014-02-08 10:07:12.0 +0100
+++ c-common.c2014-02-11 13:18:53.270521683 +0100
@@ -2976,7 +2976,7 @@ merge_tlist (struct tlist **to, struct t
   }
   if (!found)
 {
-  *end = copy ? add : new_tlist (NULL, add->expr, add->writer);
+  *end = copy ? new_tlist (NULL, add->expr, add->writer) : add;
   end = &(*end)->next;
   *end = 0;
 }
@@ -3134,7 +3134,7 @@ verify_tree (tree x, struct tlist **pbef
   verify_tree (TREE_OPERAND (x, 0), &tmp_before, &tmp_list2, NULL_TREE);
   warn_for_collisions (tmp_list2);
   merge_tlist (pbefore_sp, tmp_before, 0);
-  merge_tlist (pbefore_sp, tmp_list2, 1);
+  merge_tlist (pbefore_sp, tmp_list2, 0);

   tmp_list3 = tmp_nosp = 0;
   verify_tree (TREE_OPERAND (x, 1), &tmp_list3, &tmp_nosp, NULL_TREE);
@@ -3238,12 +3238,7 @@ verify_tree (tree x, struct tlist **pbef
 warn_for_collisions (tmp_nosp);

 tmp_list3 = 0;
-while (tmp_nosp)
-  {
-struct tlist *t = tmp_nosp;
-tmp_nosp = t->next;
-merge_tlist (&tmp_list3, t, 0);
-  }
+merge_tlist (&tmp_list3, tmp_nosp, 0);
 t->cache_before_sp = tmp_before;
 t->cache_after_sp = tmp_list3;
   }

make check RUNTESTFLAGS=dg.exp=*seq*
passes with this change and the testcase from this PR finishes in under a
second.  Manuel, can you please try to explain what you were trying to achieve
in the SAVE_EXPR case and whether the reversal of copy behavior in merge_tlist
was on purpose?

[Bug c/60129] Imprecise column numbers in NOTEs on discarding const qualifiers from pointer target type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I'll look into this in 5.0.  Seems that convert_for_assignment should use
expr_loc instead of location.

[Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  ---
Author: ro
Date: Tue Feb 11 12:56:39 2014
New Revision: 207688

URL: http://gcc.gnu.org/viewcvs?rev=207688&root=gcc&view=rev
Log:
Only assume 4-byte stack alignment on Solaris 9/x86 (PR libgomp/60107)

PR libgomp/60107
* config/i386/sol2-9.h: New file.
* config.gcc (i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*,
*-*-solaris2.9*): Use it.

Added:
trunk/gcc/config/i386/sol2-9.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc

[Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #7 from Rainer Orth  ---
Fixed for 4.9.0.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #7)
> passes with this change and the testcase from this PR finishes in under a
> second.  Manuel, can you please try to explain what you were trying to
> achieve in the SAVE_EXPR case and whether the reversal of copy behavior in
> merge_tlist was on purpose?

I don't remember I implemented this part (the revision that you mention is not
adding the handling of SAVE_EXPR or the reversal of copy behavior). My patch
simply extended the definition of what is considered candidates for warning (by
looking at the operands of operators). I took a look at my patch, and I don't
fully understand how it triggers the bug that you mention. Perhaps there is
some duplication between the code path that I added (since it is meant to
recurse on operands) and some special-handling that was there for SAVE_EXPR and
COND_EXPR.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Ah, sorry, Manuel, it seems that code is older, has been added already in
http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00541.html

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 32103
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32103&action=edit
WIP patch

And just for completeness, I'm attaching my WIP (about 50% of work done) patch
to introduce the hash tables.  But, if this new testcase doesn't need it,
perhaps there is no point in hacking on that further, unless we hit it on
larger testcases.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  ---
Sorry for not being more helpful, it was a long time ago that I worked on that.
Perhaps if you tell me which revision did the reversal/implemented the
special-handling of SAVE_EXPR, I can figure out what is going on.

[Bug fortran/60144] New: Misleading error message when missing "then" after "if" and "else if"

[loximann at gmail dot com]

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

Bug ID: 60144
   Summary: Misleading error message when missing "then" after
"if" and "else if"
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: loximann at gmail dot com

Compiler version:
GNU Fortran (Ubuntu 20130917-1ubuntu1) 4.9.0 20130917 (experimental) [trunk
revision 202647]

Test program:

program ifelif
if (.TRUE.)
else if (.FALSE.)
end if
end program


Error messages:
--
if.F90:2.15:

if (.TRUE.)
   1
Error: Cannot assign to a named constant at (1)
if.F90:3.11:

else if (.FALSE.)
   1
Error: Unexpected junk after ELSE statement at (1)
[...]
--

Both errors should read something like "Missing THEN after IF/ELSE IF".

The first error message doesn't even make sense...

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
   Target Milestone|--- |4.9.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

So, do we want to do this instead?  In this particular case, even no
DW_OP_GNU_reinterpret is needed.

[Bug middle-end/54041] [4.7/4.8/4.9 regression] -mshort ICE in convert_memory_address_addr_space, at explow.c:327

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 11 13:58:46 2014
New Revision: 207689

URL: http://gcc.gnu.org/viewcvs?rev=207689&root=gcc&view=rev
Log:
PR middle-end/54041
* expr.c (expand_expr_addr_expr_1): Handle expand_expr returning an
object with an undesirable mode.

PR middle-end/54041
* gcc.target/m68k/pr54041.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/m68k/pr54041.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/54041] [4.7/4.8/4.9 regression] -mshort ICE in convert_memory_address_addr_space, at explow.c:327

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #12 from Jeffrey A. Law  ---
Fixed on trunk.  No plans to backport fix to release branches.

[Bug regression/60133] [4.8/4.9 Regression] wrong multiarch name on aarch64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Severity|blocker |normal

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 32104 [details]
> gcc49-pr59776.patch
> 
> So, do we want to do this instead?  In this particular case, even no
> DW_OP_GNU_reinterpret is needed.

Yes, thanks a lot.

[Bug rtl-optimization/56965] nonoverlapping_component_refs_p is bogus

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Another testcase, doesn't require scheduling:

extern void abort (void);

struct S { int i; int j; };
struct X { struct S s; int k; };
struct Y { int k; struct S s; };
union U { struct X x; struct Y y; } __attribute__((may_alias));

int __attribute__((noinline))
foo (union U *p, union U *q)
{
  p->x.s.j = 1;
  q->y.s.i = 0;
  return p->x.s.j;
}

struct R { int i; int j; } __attribute__((may_alias));

int __attribute__((noinline))
bar (struct R *p, struct R *q)
{
  p->i = 1;
  q->j = 0;
  return p->i;
}

int main()
{
  int a[3];
  if (foo ((union U *)&a[0], (union U *)&a[0]) != 0)
abort ();
  if (bar ((struct R *)&a[1], (struct R *)&a[0]) != 0)
abort ();
  return 0;
}

[Bug other/60145] New: [AVR] Suboptimal code for byte order shuffling using shift and or

[matthijs at stdin dot nl]

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

Bug ID: 60145
   Summary: [AVR] Suboptimal code for byte order shuffling using
shift and or
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthijs at stdin dot nl

(Not sure what the component should be, just selected "other" for now)

Using shifts and bitwise-or to compose multiple bytes into a bigger integer
results in suboptimal code on AVR.

For example, a few simple functions that take two or four bytes and
compose them into (big endian) integers. Since AVR is an 8-bit platform,
this essentially just means moving two bytes from the argument register
to the return value registers. However, the outputted assembly is
significantly bigger than that and contains obvious optimization
opportunities.

The example below also contains a version that uses a union to compose the
integer, which gets optimized as expected (but only works on little-endian
systems, since it relies on the native endianness of uint16_t).

matthijs@grubby:~$ cat foo.c
#include 

uint16_t join2(uint8_t a, uint8_t b) {
return ((uint16_t)a << 8) | b;
}

uint16_t join2_efficient(uint8_t a, uint8_t b) {
union {
uint16_t uint;
uint8_t arr[2];
} tmp = {.arr = {b, a}};
return tmp.uint;
}

uint32_t join4(uint8_t a, uint8_t b, uint8_t c, uint8_t d) {
return ((uint32_t)a << 24) | ((uint32_t)b << 16) | ((uint32_t)c << 8) |
d;
}
matthijs@grubby:~$ avr-gcc -c foo.c -O3 && avr-objdump -d foo.o

foo.o: file format elf32-avr


Disassembly of section .text:

 :
   0:   70 e0   ldi r23, 0x00   ; 0
   2:   26 2f   mov r18, r22
   4:   37 2f   mov r19, r23
   6:   38 2b   or  r19, r24
   8:   82 2f   mov r24, r18
   a:   93 2f   mov r25, r19
   c:   08 95   ret

000e :
   e:   98 2f   mov r25, r24
  10:   86 2f   mov r24, r22
  12:   08 95   ret

0014 :
  14:   0f 93   pushr16
  16:   1f 93   pushr17
  18:   02 2f   mov r16, r18
  1a:   10 e0   ldi r17, 0x00   ; 0
  1c:   20 e0   ldi r18, 0x00   ; 0
  1e:   30 e0   ldi r19, 0x00   ; 0
  20:   14 2b   or  r17, r20
  22:   26 2b   or  r18, r22
  24:   38 2b   or  r19, r24
  26:   93 2f   mov r25, r19
  28:   82 2f   mov r24, r18
  2a:   71 2f   mov r23, r17
  2c:   60 2f   mov r22, r16
  2e:   1f 91   pop r17
  30:   0f 91   pop r16
  32:   08 95   ret

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jkratoch at gcc dot gnu.org,
   ||tromey at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Works also with -O1 -fsanitize=address -g or -O0 -fsanitize=address -g --param
asan-use-after-return=0.
My guess is that for -O0 gdb has some code to detect function
prologues/epilogues and get's upset by the conditionals in use-after-return
prologue (or epilogue?) instrumentation.  CCing some GDB folks to find out if
it isn't just a GDB bug, or what exactly would they like to see from GCC in
this case, so that they can handle it.

[Bug tree-optimization/52252] An opportunity for x86 gcc vectorizer (gain up to 3 times)

[evstupac at gmail dot com]

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

--- Comment #4 from Stupachenko Evgeny  ---
The patch giving an expected 3 times gain submitted for a discussion at:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00670.html

[Bug rtl-optimization/56965] nonoverlapping_component_refs_p is bogus

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Besides that nonoverlapping_component_refs_p is O(3) in the size of the refs
involved.

It also seems to ignore inner VIEW_CONVERT_EXPRs which means that doing the
struct X vs. struct Y dance with a VIEW_CONVERT_EXPR exposes a similar issue
(insert suitable Ada testcase here).

In the end I'd like to get rid of nonoverlapping_component_refs_p by moving
it to the tree oracle (where there is a similar but less aggressive
aliasing_component_refs_p).

It appears to me that nonoverlapping_component_refs_p could avoid its O(3)
complexity by doing sth like

  ... search for innermost VIEW_CONVERT_EXPR and start at its base ...
  vec> comprefs1;
  while (handled_component_ref_p (ref))
{
  if (TREE_CODE (ref) == COMPONENT_REF)
comprefs.safe_push (pair (ref, TYPE_MAIN_VARIANT (TYPE_CONTEXT
(TREE_OPERAND (ref, 1);
  ref = TREE_OPERAND (ref, 0);
}

same for the other ref.  Then sort the two vectors after the context type
(using TYPE_UID as key for example) and then comparing the two vectors
in lock-step.

 -> O (n * log (n))

(and we can skip over non-component-handled-components as in the code above).

[Bug fortran/60144] Misleading error message when missing "then" after "if" and "else if"

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Sergio Losilla from comment #0)
> Compiler version:
> GNU Fortran (Ubuntu 20130917-1ubuntu1) 4.9.0 20130917 (experimental) [trunk
> revision 202647]
> 
> Test program:
> 
> program ifelif
> if (.TRUE.)
> else if (.FALSE.)
> end if
> end program
> 
> 
> Error messages:
> --
> if.F90:2.15:
> 
> if (.TRUE.)
>1
> Error: Cannot assign to a named constant at (1)
> if.F90:3.11:
> 
> else if (.FALSE.)
>1
> Error: Unexpected junk after ELSE statement at (1)
> [...]
> --
> 
> Both errors should read something like "Missing THEN after IF/ELSE IF".
> 
> The first error message doesn't even make sense...


How is the compiler suppose to know that the programmer may have
meant

   program ifelif
   if (.TRUE.) i = 42
   if (.FALSE.) then
  j = 42
   end if
   end program

As for the message that you think makes no sense, I suspect
the parse has identified (.TRUE.) as a malformed expression.

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[rth at gcc dot gnu.org]

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

--- Comment #10 from Richard Henderson  ---
(In reply to Jakub Jelinek from comment #8)
> So, do we want to do this instead?  In this particular case, even no
> DW_OP_GNU_reinterpret is needed.

Well, except for the whole dhrs = NULL_TREE thing on the previous line.
Either we need a check for that on the IF, or that line really needs to
be a gcc_unreachable.

[Bug rtl-optimization/56965] nonoverlapping_component_refs_p is bogus

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> In the end I'd like to get rid of nonoverlapping_component_refs_p by moving
> it to the tree oracle (where there is a similar but less aggressive
> aliasing_component_refs_p).

No fundamental disagreement here, I already sort of initiated the process by
adding nonoverlapping_component_refs_of_decl_p to tree-ssa-alias.c.

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
So:
--- gcc/tree-sra.c.jj   2014-02-08 00:53:46.0 +0100
+++ gcc/tree-sra.c  2014-02-11 14:31:51.469937602 +0100
@@ -2950,6 +2950,10 @@ load_assign_lhs_subreplacements (struct
  lacc);
  else
drhs = NULL_TREE;
+ if (drhs
+ && !useless_type_conversion_p (lacc->type, TREE_TYPE (drhs)))
+   drhs = fold_build1_loc (loc, VIEW_CONVERT_EXPR,
+   lacc->type, drhs);
  ds = gimple_build_debug_bind (get_access_replacement (lacc),
drhs, gsi_stmt (*old_gsi));
  gsi_insert_after (new_gsi, ds, GSI_NEW_STMT);
?

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[rth at gcc dot gnu.org]

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

--- Comment #12 from Richard Henderson  ---
Works for me.

[Bug fortran/60144] Misleading error message when missing "then" after "if" and "else if"

[loximann at gmail dot com]

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

--- Comment #2 from Sergio Losilla  ---
(In reply to kargl from comment #1)
> How is the compiler suppose to know that the programmer may have
> meant
> 
>program ifelif
>if (.TRUE.) i = 42
>if (.FALSE.) then
>   j = 42
>end if
>end program

As far as I know, there are two possible statements starting with if:

if () then
if () 

The compiler should recognize that *something* is missing, be it either a then
or a statement.

> As for the message that you think makes no sense, I suspect
> the parse has identified (.TRUE.) as a malformed expression.

Well, the message objectively makes no sense because there is no assignment
whatsoever. At the very least, the message is confusing.

[Bug rtl-optimization/56965] nonoverlapping_component_refs_p is bogus

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 32105
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32105&action=edit
patch to make nonoverlapping_component_refs_p O (n log n)

Address O(3) complexity like the attached (otherwise should behave identically
other than search & find order).

The function is somewhat crippled since we no longer strip ARRAY_REFs from
mem-attrs MEM_EXPR, so testing coverage is probably low.  Still going to test
it,
despite the possibly non-trivial overhead for qsort of small N (N == 1 is
optimized already).  insn-recog.c on x86_64 is a big contender on this
function with -O2 --param max-gcse-memory=404857600

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #2)
> Works also with [...] or -O0 -fsanitize=address -g
> --param asan-use-after-return=0.

For what it is worth and with that comment rather unsurprisingly, the commit
causing the problem is r205476 (of 2013-11-28), which implements use after
return sanitization.

[Bug target/57907] warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch [enabled by default]

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #4 from Ramana Radhakrishnan  ---
fixed.

[Bug rtl-optimization/56965] nonoverlapping_component_refs_p is bogus and slow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #32105|0   |1
is obsolete||

--- Comment #5 from Richard Biener  ---
Created attachment 32106
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32106&action=edit
/suse/rguenther/p

Somewhat micro-optimized patch as otherwise it slows down the common cases too
much it seems (testing on insn-recog).  It's still slower than the non-sorting
version (but if we make it stronger by collecting more relevant FIELD_DECLs
we'll hit the trade-off limit faster ...).

Some statistics on insn-recog, fieldsx vs. fieldsy length:

184 rtl pre "ncr-1-1 == 1" 6192389
185 hoist "ncr-1-1 == 1" 252507
201 dse1 "ncr-1-1 == 1" 6743
227 dse2 "ncr-1-1 == 1" 6743
239 sched2 "ncr-1-1 == 1" 6743

which is interesting ;)  The most common case is just one.  Very easy to
very micro-optimize but still shows non-noise regression of about 1%
for the pathological case above.

We can also optimize the length 1 vs. arbitrary length case and avoid
sorting the 2nd vector (not done yet).

[Bug c++/60146] New: Regression: ICE when compiling this code with -fopenmp

[tweenk.pl at gmail dot com]

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

Bug ID: 60146
   Summary: Regression: ICE when compiling this code with -fopenmp
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tweenk.pl at gmail dot com

The linked preprocessed code compiled correctly in GCC 4.7.x (Ubuntu 13.04).
After upgrade to GCC 4.8.1 (Ubuntu 13.10), it crashes.

The code is too big (3.1MB) to attach it to the bug report and cannot be easily
reduced, so I'm providing a download link:

http://osch.chem.uw.edu.pl/gccbug.cpp

Compile with: g++ -fopenmp gccbug.cpp -c -o gccbug.o

Output:

In file included from ../tests/../common/include/Spectrum.h:16:0,
 from ../tests/TestSpectralData.cpp:2:
../tests/../common/include/SpectralData.h: In instantiation of
‘SpectrumRegionAxis<, ,
,  >::Self& SpectrumRegionAxis<,
, , 
>::operator=(const Self&) [with unsigned int D = 4u; C = short unsigned int; T
= float; unsigned int BLOCKSIZE = 32u; SpectrumRegionAxis<,
, ,  >::Self =
SpectrumRegionAxis<4u, short unsigned int, float, 32u>]’:
../tests/../common/include/SpectralData.h:1195:8:   required from
‘BinaryOutput& operator<<(BinaryOutput&, const SpectrumRegionAxis&) [with unsigned int D = 4u; C = short unsigned int; T = float; unsigned
int BSIZE = 32u]’
../tests/../common/include/Spectrum.h:75:6:   required from ‘BinaryOutput&
operator<<(BinaryOutput&, const Spectrum&) [with unsigned int D = 4u]’
../tests/TestSpectralData.cpp:163:9:   required from here
../tests/../common/include/SpectralData.h:650:5: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccsMy4oS.out file, please attach this to
your bugreport.

[Bug fortran/52370] [4.7/4.8/4.9 Regression] Spurious "may be used uninitialized" warning for check of optional argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Indeed, this regressed with r182211.

[Bug fortran/60147] New: [Regression] ICE with -fdump-tree-original and NAMELIST

[kargl at gcc dot gnu.org]

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

Bug ID: 60147
   Summary: [Regression] ICE with -fdump-tree-original and
NAMELIST
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org

program foo
   implicit none
   character(len=5) :: s = 'tue'
   namelist /mylist/ s
end program

% gfc4x -o z -fdump-tree-original g.f90
g.f90: In function 'foo':
g.f90:5:0: internal compiler error: Segmentation fault
 end program
 ^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) run -fdump-tree-original g.f90
Starting program:
/usr/home/sgk/work/4x/libexec/gcc/x86_64-unknown-freebsd11.0/4.9.0/f951
-fdump-tree-original g.f90
 foo
Program received signal SIGSEGV, Segmentation fault.
0x00b094a2 in dump_generic_node (buffer=0x18ccc00 , 
node=0x202f1f4c8, spc=2, flags=512, is_stmt=false)
at ../../gcc4x/gcc/tree-pretty-print.c:1495
1495../../gcc4x/gcc/tree-pretty-print.c: No such file or directory.
(gdb) bt
#0  0x00b094a2 in dump_generic_node (buffer=0x18ccc00 , 
node=0x202f1f4c8, spc=2, flags=512, is_stmt=false)
at ../../gcc4x/gcc/tree-pretty-print.c:1495
#1  0x00b18de5 in print_declaration (buffer=0x18ccc00 , 
t=0x202dff7e8, spc=2, flags=512)
at ../../gcc4x/gcc/tree-pretty-print.c:2759
#2  0x00b0a2d4 in dump_generic_node (buffer=0x18ccc00 , 
node=0x202dec510, spc=0, flags=512, is_stmt=true)
at ../../gcc4x/gcc/tree-pretty-print.c:1723
#3  0x00b1969e in print_generic_stmt_indented (file=, 
t=0x202dec510, flags=512, indent=0)
at ../../gcc4x/gcc/tree-pretty-print.c:157
#4  0x00a845b9 in dump_function_to_file (fndecl=, 
file=0x202bb3370, flags=512) at ../../gcc4x/gcc/tree-cfg.c:7117
#5  0x00a9de89 in dump_function (phase=5, fn=0x202f24b00)
at ../../gcc4x/gcc/tree-dump.c:170
#6  0x00607c33 in gfc_generate_function_code (ns=0x203459600)
at ../../gcc4x/gcc/fortran/trans-decl.c:5706
#7  0x0059a0b7 in translate_all_program_units (
main_in_tu=, gfc_global_ns_list=0x203459600)
at ../../gcc4x/gcc/fortran/parse.c:4536
#8  gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:4733
#9  0x005d7366 in gfc_be_parse_file ()
at ../../gcc4x/gcc/fortran/f95-lang.c:188
#10 0x00a4f136 in compile_file () at ../../gcc4x/gcc/toplev.c:548
#11 0x00a4f9f3 in do_compile () at ../../gcc4x/gcc/toplev.c:1914
#12 0x00a50562 in toplev_main (argc=3, argv=0x7fffd4c8)
at ../../gcc4x/gcc/toplev.c:1990
#13 0x00528daf in _start ()

[Bug fortran/60148] New: strings in NAMELIST do not honor DELIM= in open statement

[kargl at gcc dot gnu.org]

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

Bug ID: 60148
   Summary: strings in NAMELIST do not honor DELIM= in open
statement
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org

[Bug fortran/52370] [4.7/4.8/4.9 Regression] Spurious "may be used uninitialized" warning for check of optional argument

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Until we get more fine-grained warning control, I believe the only way to fix
this is make sure TREE_NO_WARNING is set on Fortran optional argument related
variables (not just the data pointer (b.0 here), but I think the others too
(bounds, size, ...).

[Bug c/60149] New: Message with percent character incorrectly marked c-format

[goeran at uddeborg dot se]

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

Bug ID: 60149
   Summary: Message with percent character incorrectly marked
c-format
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goeran at uddeborg dot se

In the po files for gcc 4.9 distributed through the Translation Project
recently there is a message like this:

#: params.def:417
#, c-format
msgid "Set the estimated probability in percentage for builtin expect. The
default value is 90% probability."

The "c-format" annotation makes the gettext tools believe that "% p" is a
conversion of a pointer with space as a flag.  This of course breaks in
translation.  The correct thing would be to avoid the c-format directive, but
I'm not sure how easy that is.

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||4.7.4, 4.8.3, 4.9.0

--- Comment #1 from kargl at gcc dot gnu.org ---
program namelistout
   implicit none
   character :: mystring*5 = 'tue'
   namelist /mylist/ mystring
   open(unit=10,file='junk1.dat',delim='apostrophe')
   write(10, mylist)
   close(10)
   open(unit=10,file='junk2.dat',delim='quote')
   write(10, mylist)
   close(10)
   open(unit=10,file='junk3.dat',delim='none')
   write(10, mylist)
   close(10)
   open(unit=10,file='junk4.dat')
   write(10, mylist)
   close(10)
end program

% gfc4x -o z g.f90 && ./z
% cat junk?.dat
&MYLIST
 MYSTRING='tue  ',
 /
&MYLIST
 MYSTRING="tue  ",
 /
&MYLIST
 MYSTRING="tue  ",
 /
&MYLIST
 MYSTRING="tue  ",
 /

junk3.dat and junk4.dat should contain
&MYLIST
 MYSTRING=tue,
 /


10.11.4.2   Namelist output editing

Values in namelist output records are edited as for
list-directed output (10.10.4).

10.10.4
...
Character sequences produced when the delimiter mode has a
value of NONE
  . are not delimited by apostrophes or quotation marks,
  . are not separated from each other by value separators,
  · have each internal apostrophe or quotation mark
represented externally by one apostrophe or quotation
mark, and
  · have a blank character inserted by the processor at the
beginning of any record that begins with the continuation
of a character sequence from the preceding record.

Character sequences produced when the delimiter mode has a
value of QUOTE are delimited by quotes, are preceded and
followed by a value separator, and have each internal quote
represented on the external medium by two contiguous quotes.

Character sequences produced when the delimiter mode has a
value of APOSTROPHE are delimited by apostrophes, are preceded
and followed by a value separator, and have each internal
apostrophe represented on the external medium by two contiguous
apostrophes.

9.5.6.8   DELIM= specifier in the OPEN statement

The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE,
or NONE.  The DELIM= specifier is permitted only for a connection
for formatted input/output.  It specifies the delimiter mode
(9.6.2.8) for list-directed (10.10.4) and namelist (10.11.4.2)
output for the connection.  This mode has no effect on input.  It
is a changeable mode (9.5.2).  If this specifier is omitted in an
OPEN statement that initiates a connection, the default value is NONE.

[Bug c++/58873] [4.7/4.8/4.9 Regression] [c++11] ICE with __underlying_type for broken enum

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz  ---
Issue here is that the argument type gets NULL for function-call of
cp_parser_functional_cast.  This invalid type is the result of
cp_parser_simple_type_specifier call.

A fix might be to checking within cp_parser_functional_cast for type == NULL
and set it to error_mark_node if so.

Index: parser.c
===
--- parser.c(Revision 207686)
+++ parser.c(Arbeitskopie)
@@ -23167,6 +23167,9 @@ cp_parser_functional_cast (cp_parser* parser, tree
   tree cast;
   bool nonconst_p;

+  if (!type)
+type = error_mark_node;
+
   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
 {
   maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);

[Bug driver/44049] Empty dependencies left may cause invalid builds

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I believe this was fixed in 4.5 by r145263.

[Bug fortran/52370] [4.7/4.8/4.9 Regression] Spurious "may be used uninitialized" warning for check of optional argument

[jakub at gcc dot gnu.org]

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

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

So, how about this patch?

[Bug fortran/60147] [4.9 Regression] ICE with -fdump-tree-original and NAMELIST

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-11
 CC||burnus at gcc dot gnu.org
Summary|[Regression] ICE with   |[4.9 Regression] ICE with
   |-fdump-tree-original and|-fdump-tree-original and
   |NAMELIST|NAMELIST
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed r205305 is OK and r205798 gives the ICE. Usual suspect is r205679.

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

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #5 from Tom Tromey  ---
I would like this bug to be reopened.

I've read through this bug and various dups,
and it seems that there are two rationales given
for skipping the warning for const statics:

1. rcs_id.  It seems to me that this case could
   be handled by __attribute__((used)).

2. "static const"s appearing in system headers.
   It seems to me that this could be handled by
   the usual in_system_header_at check.

This warning would have caught a couple of previously
unnoticed bugs in gdb:
https://sourceware.org/ml/gdb-patches/2014-02/msg00342.html

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 11 17:46:34 2014
New Revision: 207695

URL: http://gcc.gnu.org/viewcvs?rev=207695&root=gcc&view=rev
Log:
PR debug/59776
* tree-sra.c (load_assign_lhs_subreplacements): Add VIEW_CONVERT_EXPR
around drhs if type conversion to lacc->type is not useless.

* gcc.dg/guality/pr59776.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/guality/pr59776.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug middle-end/59776] [4.8 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 Status|NEW |ASSIGNED
   Assignee|rth at gcc dot gnu.org |jakub at gcc dot gnu.org
   Target Milestone|4.9.0   |4.8.3
Summary|[4.8/4.9 Regression] gcc -g |[4.8 Regression] gcc -g -O1
   |-O1 ICE in  |ICE in
   |expand_debug_locations, at  |expand_debug_locations, at
   |cfgexpand.c:3865|cfgexpand.c:3865

--- Comment #14 from Jakub Jelinek  ---
Fixed for the trunk so far.

[Bug lto/60150] New: [4.9 Regression] ICE in function_and_variable_visibility, at ipa.c:1000

[d.g.gorbachev at gmail dot com]

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

Bug ID: 60150
   Summary: [4.9 Regression] ICE in
function_and_variable_visibility, at ipa.c:1000
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.g.gorbachev at gmail dot com

Created attachment 32108
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32108&action=edit
Testcase

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[d.g.gorbachev at gmail dot com]

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

--- Comment #10 from Dmitry Gorbachev  ---
I confirm that there is no ICE with the 1st testcase. The 2nd still causes ICE
in function_and_variable_visibility, at ipa.c:1000.

(Something strange happened with the 2nd attachment. I filed another PR 60150
with re-attached testcase.)

[Bug libstdc++/59677] basic_istream::get leads to a mudflap violation

[fche at redhat dot com]

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

Frank Ch. Eigler  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fche at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #2 from Frank Ch. Eigler  ---
This was a sign of incompleteness of libstdc++ support for libmudflap.  Please
try the address-sanitizer options for the currently maintained variant of this
functionality.

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed on 4.7.4, 4.8.3, and trunk (4.9).

[Bug fortran/60144] Misleading error message when missing "then" after "if" and "else if"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Confirmed on 4.7.4, 4.8.3, and trunk (4.9). Related to pr32151.

[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Feb 11 18:59:24 2014
New Revision: 207697

URL: http://gcc.gnu.org/viewcvs?rev=207697&root=gcc&view=rev
Log:
PR target/59927
Revert
2013-12-15  Uros Bizjak  

PR testsuite/58630
* gcc.target/i386/pr43662.c (dg-options):
Add -maccumulate-outgoing-args.
* gcc.target/i386/pr43869.c (dg-options): Ditto.
* gcc.target/i386/pr57003.c (dg-options): Ditto.
* gcc.target/i386/avx-vzeroupper-16.c (dg-options):
Remove -mtune=generic and add -maccumulate-outgoing-args instead.
* gcc.target/i386/avx-vzeroupper-17.c (dg-options): Ditto.
* gcc.target/i386/avx-vzeroupper-18.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-1.c (dg-options):
Add -maccumulate-outgoing-args.
* gcc.target/x86_64/abi/callabi/func-2a.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-2b.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-indirect.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-indirect-2a.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-indirect-2b.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/leaf-1.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/leaf-2.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/pr38891.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-1.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-2.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-3.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-4a.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-4b.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-5a.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-5b.c (dg-options): Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c
trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c
trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c
trunk/gcc/testsuite/gcc.target/i386/pr43662.c
trunk/gcc/testsuite/gcc.target/i386/pr43869.c
trunk/gcc/testsuite/gcc.target/i386/pr57003.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2a.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2b.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-indirect-2a.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-indirect-2b.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-indirect.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/leaf-1.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/leaf-2.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/pr38891.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-1.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-2.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-3.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-4a.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-4b.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5a.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5b.c

[Bug testsuite/58630] [4.9 Regression] Revision 203171 breaks several MS-ABI tests

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Feb 11 18:59:24 2014
New Revision: 207697

URL: http://gcc.gnu.org/viewcvs?rev=207697&root=gcc&view=rev
Log:
PR target/59927
Revert
2013-12-15  Uros Bizjak  

PR testsuite/58630
* gcc.target/i386/pr43662.c (dg-options):
Add -maccumulate-outgoing-args.
* gcc.target/i386/pr43869.c (dg-options): Ditto.
* gcc.target/i386/pr57003.c (dg-options): Ditto.
* gcc.target/i386/avx-vzeroupper-16.c (dg-options):
Remove -mtune=generic and add -maccumulate-outgoing-args instead.
* gcc.target/i386/avx-vzeroupper-17.c (dg-options): Ditto.
* gcc.target/i386/avx-vzeroupper-18.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-1.c (dg-options):
Add -maccumulate-outgoing-args.
* gcc.target/x86_64/abi/callabi/func-2a.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-2b.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-indirect.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-indirect-2a.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/func-indirect-2b.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/leaf-1.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/leaf-2.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/pr38891.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-1.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-2.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-3.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-4a.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-4b.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-5a.c (dg-options): Ditto.
* gcc.target/x86_64/abi/callabi/vaarg-5b.c (dg-options): Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c
trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c
trunk/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c
trunk/gcc/testsuite/gcc.target/i386/pr43662.c
trunk/gcc/testsuite/gcc.target/i386/pr43869.c
trunk/gcc/testsuite/gcc.target/i386/pr57003.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2a.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2b.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-indirect-2a.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-indirect-2b.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-indirect.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/leaf-1.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/leaf-2.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/pr38891.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-1.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-2.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-3.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-4a.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-4b.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5a.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5b.c

[Bug target/60151] New: HAVE_AS_GOTOFF_IN_DATA is mis-detected on x86-64

[hjl.tools at gmail dot com]

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

Bug ID: 60151
   Summary: HAVE_AS_GOTOFF_IN_DATA is mis-detected on x86-64
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com

i386.h has

/* Under some conditions we need jump tables in the text section,
   because the assembler cannot handle label differences between
   sections.  This is the case for x86_64 on Mach-O for example.  */

#define JUMP_TABLES_IN_TEXT_SECTION \
  (flag_pic && ((TARGET_MACHO && TARGET_64BIT) \
   || (!TARGET_64BIT && !HAVE_AS_GOTOFF_IN_DATA)))

HAVE_AS_GOTOFF_IN_DATA is only used for 32-bit PIC.  However,
configure.ac has

gcc_GAS_CHECK_FEATURE([GOTOFF in data],
gcc_cv_as_ix86_gotoff_in_data, [2,11,0],,
[   .text
.L0:
nop
.data
.long .L0@GOTOFF])
AC_DEFINE_UNQUOTED(HAVE_AS_GOTOFF_IN_DATA,

On Linux/x86-64, we get

configure:25031: checking assembler for GOTOFF in data
configure:25048: /usr/local/bin/as --64  -o conftest.o conftest.s >&5
conftest.s: Assembler messages:
conftest.s:5: Error: 8-byte relocation cannot be applied to 4-byte field
configure:25051: $? = 1
configure: failed program was
.text
.L0:
nop
.data
.long .L0@GOTOFF
configure:25062: result: no

On Linux/i686, we get

configure:25026: checking assembler for GOTOFF in data
configure:25043: /usr/local32/bin/as --32  -o conftest.o conftest.s >&5
configure:25046: $? = 0
configure:25057: result: yes

As the result, we put jump table in .text section for -m32 -fPIC
on Linux/x86-64.

[Bug fortran/60147] [4.9 Regression] ICE with -fdump-tree-original and NAMELIST

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Usual suspect is r205679.

It is the culprit: r205678 is OK, r205679 gives the ICE.

[Bug target/56024] ARM NEON polynomial types behave as if signed

[t.p.northover at gmail dot com]

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

Tim Northover  changed:

   What|Removed |Added

 CC||t.p.northover at gmail dot com

--- Comment #2 from Tim Northover  ---
Are there any plans to fix this soon? It's become relevant again on the Clang
mailing list. 

We don't want to switch to a sane type if GCC decides sanity is less important
than ABI-compatibility, but every so often it causes someone extra work to
handle the discrepancy.

[Bug target/56024] ARM NEON polynomial types behave as if signed

[StaffLeavers at arm dot com]

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

--- Comment #3 from StaffLeavers at arm dot com ---
tim.northover no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug debug/60152] New: [4.9.0 Regression] multiple AT_calling_convention attributes generated after r205679

[dominiq at lps dot ens.fr]

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

Bug ID: 60152
   Summary: [4.9.0 Regression] multiple  AT_calling_convention
attributes generated after r205679
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: burnus at gcc dot gnu.org, rguenth at gcc dot gnu.org

After r205679, gfortran generates AT_calling_convention twice when compiling
gfortran.dg/namelist_51.f90 with '-g -O[01sg]', but only once with '-g -O2' and
above unless '-flto' is added. This causes the following waring on darwin

warning: invalid DWARF generated by the compiler: DIE 0x01f0 has multiple 
AT_calling_convention attributes in '...'

[Bug target/56024] ARM NEON polynomial types behave as if signed

[StaffLeavers at arm dot com]

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

--- Comment #4 from StaffLeavers at arm dot com ---
tim.northover no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug fortran/60060] [4.9 Regression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Looks like a different bug - can you please file it separately as this bug
> assigned to me is about LTO issues?

PR60152.

[Bug target/56024] ARM NEON polynomial types behave as if signed

[StaffLeavers at arm dot com]

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

--- Comment #7 from StaffLeavers at arm dot com ---
tim.northover no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug target/56024] ARM NEON polynomial types behave as if signed

[StaffLeavers at arm dot com]

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

--- Comment #6 from StaffLeavers at arm dot com ---
tim.northover no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug target/56024] ARM NEON polynomial types behave as if signed

[StaffLeavers at arm dot com]

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

--- Comment #5 from StaffLeavers at arm dot com ---
tim.northover no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug target/56024] ARM NEON polynomial types behave as if signed

[StaffLeavers at arm dot com]

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

--- Comment #8 from StaffLeavers at arm dot com ---
tim.northover no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug target/56024] ARM NEON polynomial types behave as if signed

[t.p.northover at gmail dot com]

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

--- Comment #9 from Tim Northover  ---
Yay for infinite e-mail loops! Very sorry about that, it should be fixed now.

[Bug c++/60153] New: Variadic template parameter's typedefs cause internal compile error: in dependent_type_p on RedHat

[nclimer at gmail dot com]

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

Bug ID: 60153
   Summary: Variadic template parameter's typedefs cause internal
compile error: in dependent_type_p on RedHat
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nclimer at gmail dot com

Created attachment 32109
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32109&action=edit
preprocessed source

While playing with variadic template, I ran into the following error:

#include 

enum class foo :int {x,y,z};

//class we're trying to generate
template 
class A
{
public:
  A()
  {
std::cout << a << "," << (int)b << std::endl;

  }
};

//class which generates information
template 
struct B
{
  typedef T value_type;
  static const T val;
};

template 
struct madscience_intitializer
{
  template 
  using ret_type = A;
};




int main(int argc, char** argv)
{
  madscience_intitializer,B >::ret_type<1,foo::y> a;
}

Causes this error:

main2.cpp: In function ‘int main(int, char**)’:
main2.cpp:37:61: internal compiler error: in dependent_type_p, at cp/pt.c:19526
   madscience_intitializer,B >::ret_type<1,foo::y> a;
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccqXFjQG.out file, please attach this to
your bugreport.
make: *** [main2] Error 1


g++ version
g++ (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7)
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.

[Bug fortran/52370] [4.7/4.8/4.9 Regression] Spurious "may be used uninitialized" warning for check of optional argument

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 11 20:48:26 2014
New Revision: 207698

URL: http://gcc.gnu.org/viewcvs?rev=207698&root=gcc&view=rev
Log:
PR fortran/52370
* trans-decl.c (gfc_build_dummy_array_decl): Set TREE_NO_WARNING
on decl if sym->attr.optional.

* gfortran.dg/pr52370.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr52370.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/52370] [4.7/4.8 Regression] Spurious "may be used uninitialized" warning for check of optional argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression]
   |Spurious "may be used   |Spurious "may be used
   |uninitialized" warning for  |uninitialized" warning for
   |check of optional argument  |check of optional argument

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/60137] Code fails with -mcpu=power8 -O3 -mno-vsx

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Tue Feb 11 21:05:35 2014
New Revision: 207699

URL: http://gcc.gnu.org/viewcvs?rev=207699&root=gcc&view=rev
Log:
[gcc]
2014-02-11  Michael Meissner  

PR target/60137
* config/rs6000/rs6000.md (128-bit GPR splitter): Add a splitter
for VSX/Altivec vectors that land in GPR registers.

[gcc/testsuite]
2014-02-11  Michael Meissner  

PR target/60137
* gcc.target/powerpc/pr60137.c: New file.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr60137.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug target/60137] Code fails with -mcpu=power8 -O3 -mno-vsx

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Tue Feb 11 21:24:15 2014
New Revision: 207700

URL: http://gcc.gnu.org/viewcvs?rev=207700&root=gcc&view=rev
Log:
[gcc]
2014-02-11  Michael Meissner  

Backport from mainline r207699.
2014-02-11  Michael Meissner  

PR target/60137
* config/rs6000/rs6000.md (128-bit GPR splitter): Add a splitter
for VSX/Altivec vectors that land in GPR registers.

[gcc/testsuite]
2014-02-11  Michael Meissner  

Backport from mainline r207699.
2014-02-11  Michael Meissner  

PR target/60137
* gcc.target/powerpc/pr60137.c: New file.


Added:
branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr60137.c
  - copied unchanged from r207699,
trunk/gcc/testsuite/gcc.target/powerpc/pr60137.c
Modified:
branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.md
branches/ibm/gcc-4_8-branch/gcc/testsuite/ChangeLog.ibm

[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom

[gnu at binarywings dot net]

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

Florian Philipp  changed:

   What|Removed |Added

 CC||gnu at binarywings dot net

--- Comment #9 from Florian Philipp  ---
Created attachment 32110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32110&action=edit
Patch without POSIX I/O

I find the original patch as applied to mainline unnecessarily complicated. You
can achieve the same just with std I/O by deactivating buffering with
std::setbuf. Basically a one line change when applied to the original version.

[Bug target/49008] A typo code found in genautomata.c

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Feb 11 22:00:04 2014
New Revision: 207701

URL: http://gcc.gnu.org/viewcvs?rev=207701&root=gcc&view=rev
Log:
2014-02-11  Vladimir Makarov  

PR target/49008
* genautomata.c (add_presence_absence): Fix typo with
{final_}presence_list.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/genautomata.c

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Author: hubicka
Date: Tue Feb 11 22:54:21 2014
New Revision: 207702

URL: http://gcc.gnu.org/viewcvs?rev=207702&root=gcc&view=rev
Log:

PR lto/59468
* ipa-utils.h (possible_polymorphic_call_targets): Update prototype
and wrapper.
* ipa-devirt.c: Include demangle.h
(odr_violation_reported): New static variable.
(add_type_duplicate): Update odr_violations.
(maybe_record_node): Add completep parameter; update it.
(record_target_from_binfo): Add COMPLETEP parameter;
update it as needed.
(possible_polymorphic_call_targets_1): Likewise.
(struct polymorphic_call_target_d): Add nonconstruction_targets;
rename FINAL to COMPLETE.
(record_targets_from_bases): Sanity check we found the binfo;
fix COMPLETEP updating.
(possible_polymorphic_call_targets): Add NONCONSTRUTION_TARGETSP
parameter, fix computing of COMPLETEP.
(dump_possible_polymorphic_call_targets): Imrove readability of dump; at
LTO time do demangling.
(ipa_devirt): Use nonconstruction_targets; Improve dumps.
* gimple-fold.c (gimple_get_virt_method_for_vtable): Add can_refer
parameter.
(gimple_get_virt_method_for_binfo): Likewise.
* gimple-fold.h (gimple_get_virt_method_for_binfo,
gimple_get_virt_method_for_vtable): Update prototypes.

PR lto/59468
* g++.dg/ipa/devirt-27.C: New testcase.
* g++.dg/ipa/devirt-26.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/ipa/devirt-26.C
trunk/gcc/testsuite/g++.dg/ipa/devirt-27.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-fold.h
trunk/gcc/ipa-devirt.c
trunk/gcc/ipa-utils.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/49636] [F03] ASSOCIATE construct confused with slightly complicated case

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Created attachment 32098 [details]
> A fix for this problem

AFAICT it fixes the problem for 64 bit mode only. In 32 bit mode the ICE is
gone, but I get at run time

i_good= 1 3 5
 i_bad= 1** 3

> I am sure that this trick will fix pr57019 too.  This latter is claimed 
> to be a regression but I am sure that it never worked :-)  Nonetheless, 
> I will take advantage of the regression label!
>
> I will work on it tomorrow night.
>
> By the way, this patch regtests OK on trunk.  I have to make sure 
> that substrings of character arrays work OK with ASSOCIATE.

Did you regtest with -m32? I see gfortran.dg/associated_target_5.f03 failing at
execution time with -m32, as well as the first test in pr57522

   0   1   2   3
   0   4   1   5

[Bug target/49008] A typo code found in genautomata.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Fixed.

[Bug go/60134] runtime_unmarkspan panics with "unaligned pointer"

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
I don't know which repository your git commit ID refers to.  The gofrontend
uses Mercurial and GCC uses Subversion.

I suspect this problem was fixed by revision 205940 in the GCC Subversion
repository, committed 2013-12-12,
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01202.html .

Do the sources you are building include that patch?

[Bug go/60134] runtime_unmarkspan panics with "unaligned pointer"

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Ian Lance Taylor from comment #1)
> I don't know which repository your git commit ID refers to.  The gofrontend
> uses Mercurial and GCC uses Subversion.

The git commit ID referenced is the official git which uses git-svn:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e63988cca99cbbf6e5c459379309fe3359fe7c09

> 
> I suspect this problem was fixed by revision 205940 in the GCC Subversion
> repository, committed 2013-12-12,
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01202.html .
> 
> Do the sources you are building include that patch?



which corresponds to revision 205617 which is before the revision you said it
was fixed in.

Thanks,
Andrew Pinski

[Bug ipa/60154] New: ICE: in cgraph_function_node at gcc/cgraph.c:2962

[danglin at gcc dot gnu.org]

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

Bug ID: 60154
   Summary: ICE: in cgraph_function_node at gcc/cgraph.c:2962
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 32111
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32111&action=edit
Preprocessed source

dave@mx3210:~/gnu/gcc/objdir$ gdb stage1-gcc/cc1plusGNU gdb (GDB) 7.6.2 (Debian
7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "hppa-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/dave/gnu/gcc/objdir/stage1-gcc/cc1plus...done.
(gdb) set args -fpreprocessed CMetricMapBuilderICP.ii -quiet -dumpbase
CMetricMapBuilderICP.ii -auxbase-strip CMetricMapBuilderICP.o -O3 -Wall
-Wno-long-long -Wno-write-strings -Wno-variadic-macros -Wpedantic -std=c++11
-version -fPIC -fpreprocessed -o CMetricMapBuilderICP.s
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/dave/gnu/gcc/objdir/stage1-gcc/cc1plus -fpreprocessed
CMetricMapBuilderICP.ii -quiet -dumpbase CMetricMapBuilderICP.ii -auxbase-strip
CMetricMapBuilderICP.o -O3 -Wall -Wno-long-long -Wno-write-strings
-Wno-variadic-macros -Wpedantic -std=c++11 -version -fPIC -fpreprocessed -o
CMetricMapBuilderICP.s
Program received signal SIGSEGV, Segmentation fault.
0x0067ac24 in cgraph_function_node (node=0xf4d97a10, availability=0x0)
at ../../gcc/gcc/cgraph.c:2962
2962  node = node->callees->callee;
(gdb) p node->callees
$5 = (cgraph_edge *) 0x0
(gdb) bt
#0  0x0067ac24 in cgraph_function_node (node=0xf4d97a10, availability=0x0)
at ../../gcc/gcc/cgraph.c:2962
#1  0x011a290c in self_recursive_p (node=0xf1758398)
at ../../gcc/gcc/ipa-pure-const.c:1091
#2  0x011a349c in propagate_pure_const ()
at ../../gcc/gcc/ipa-pure-const.c:1321

Also seen on trunk.

[Bug go/60134] runtime_unmarkspan panics with "unaligned pointer"

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Thanks Andrew.  Assuming this is fixed.  Please reopen if not.

[Bug rtl-optimization/60155] New: 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

Bug ID: 60155
   Summary: ICE: in get_pressure_class_and_nregs at gcse.c:3438
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 32112
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32112&action=edit
Preprocessed source

The following ICE occurs building openssh -6.5p1:

gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare
-Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign
-Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
-fno-builtin-memset -D_FORTIFY_SOURCE=2 -g -O2 -Wformat -Werror=format-security
-DLOGIN_PROGRAM=\"/bin/login\" -DLOGIN_NO_ENDOPT
-DSSH_EXTRAVERSION=\"Debian-2\"  -I. -I..  -I/usr/include/editline
-DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAUL
T=\"/usr/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/lib/openssh/sftp-server\" 
-D_PATH_SSH_KEY_SIGN=\"/usr/lib/openssh/ssh-keysign\"
-D_PATH_SSH_PKCS11_HELPER=\"/usr/lib/openssh/ssh-pkcs11-helper\"
-D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_P
RIVSEP_CHROOT_DIR=\"/var/run/sshd\" -DHAVE_CONFIG_H -c ../ssh-keygen.c
../ssh-keygen.c: In function ‘do_fingerprint’:
../ssh-keygen.c:887:1: internal compiler error: in
get_pressure_class_and_nregs,
 at gcse.c:3438
 }
 ^Please submit a full bug report,

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
This seems a little counter-intuitive to me.  However with delimiter="NONE" I
think the standard says that junk should be:

&MYLIST
 MYSTRING=tue  
 /

With two spaces after the 'tue'

Agree?

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Like this:

&MYLIST
 MYSTRING= 'tue  '
 /
 &MYLIST
 MYSTRING= "tue  "
 /
 &MYLIST
 MYSTRING= tue  
 /
 &MYLIST
 MYSTRING= tue  
 /

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> Like this:
> 
> &MYLIST
>  MYSTRING= 'tue  '
>  /
>  &MYLIST
>  MYSTRING= "tue  "
>  /
>  &MYLIST
>  MYSTRING= tue  
>  /
>  &MYLIST
>  MYSTRING= tue  
>  /

Dang!  You beat me to the patch.  Here's what I have.
I'm not sure if the first chunk is needed.  Currently,
running the testsuite.

Index: io/write.c
===
--- io/write.c  (revision 207664)
+++ io/write.c  (working copy)
@@ -1832,8 +1832,10 @@ nml_write_obj (st_parameter_dt *dtp, nam
dtp->u.p.current_unit->delim_status = DELIM_QUOTE;
  if (dtp->u.p.nml_delim == '\'')
dtp->u.p.current_unit->delim_status = DELIM_APOSTROPHE;
+ if (dtp->u.p.nml_delim == ' ')
+   dtp->u.p.current_unit->delim_status = DELIM_NONE;
  write_character (dtp, p, 1, obj->string_length);
-   dtp->u.p.current_unit->delim_status = tmp_delim;
+ dtp->u.p.current_unit->delim_status = tmp_delim;
   break;

case BT_REAL:
@@ -1972,7 +1974,12 @@ namelist_write (st_parameter_dt *dtp)
   /* Set the delimiter for namelist output.  */
   tmp_delim = dtp->u.p.current_unit->delim_status;

-  dtp->u.p.nml_delim = tmp_delim == DELIM_APOSTROPHE ? '\'' : '"';
+  if (tmp_delim == DELIM_APOSTROPHE)
+dtp->u.p.nml_delim = '\'';
+  else if (tmp_delim == DELIM_QUOTE)
+dtp->u.p.nml_delim = '"';
+  else
+dtp->u.p.nml_delim = ' ';

   /* Temporarily disable namelist delimters.  */
   dtp->u.p.current_unit->delim_status = DELIM_NONE;

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Wed, Feb 12, 2014 at 03:12:52AM +, kargl at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148
> 
> --- Comment #5 from kargl at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #4)
> > Like this:
> > 
> > &MYLIST
> >  MYSTRING= 'tue  '
> >  /
> >  &MYLIST
> >  MYSTRING= "tue  "
> >  /
> >  &MYLIST
> >  MYSTRING= tue  
> >  /
> >  &MYLIST
> >  MYSTRING= tue  
> >  /
> 
> Dang!  You beat me to the patch.  Here's what I have.
> I'm not sure if the first chunk is needed.  Currently,
> running the testsuite.
> 

There are few regressions, which I haven't looked through, yet.
I suspect these are related to looking for ' or " in a result
that was written to a file and then re-read.

[Bug go/60134] runtime_unmarkspan panics with "unaligned pointer"

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
On Wed, Feb 12, 2014 at 12:34:06AM +, ian at airs dot com wrote:
> I suspect this problem was fixed by revision 205940 in the GCC Subversion
> repository, committed 2013-12-12,
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01202.html .

Yes, that fixes it.  Thanks.

Ciao

Dominik ^_^  ^_^

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 12 07:35:50 2014
New Revision: 207711

URL: http://gcc.gnu.org/viewcvs?rev=207711&root=gcc&view=rev
Log:
PR c/60101
* c-common.c (merge_tlist): If copy is true, call new_tlist,
if false, add ADD itself, rather than vice versa.
(verify_tree): For COND_EXPR, don't call merge_tlist with non-zero
copy.  For SAVE_EXPR, only call merge_tlist once.

* c-c++-common/pr60101.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr60101.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c/60101] [4.7/4.8 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||4.9.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Long
   |Long compile times when |compile times when mixed
   |mixed complex floating  |complex floating point
   |point datatypes are used in |datatypes are used in
   |lengthy expressions |lengthy expressions
  Known to fail|4.9.0   |

--- Comment #13 from Jakub Jelinek  ---
Fixed on the trunk so far.