[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault

[mattyclarkson at gmail dot com]

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



--- Comment #7 from Matt Clarkson  2012-10-17 
08:19:20 UTC ---

Sorry about the bloated bug report - that was how I came across it.  In the

future I'll submit smaller test cases.



Thanks for looking into this.

[Bug rtl-optimization/54942] [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org

  Component|tree-optimization   |rtl-optimization

   Target Milestone|--- |4.8.0



--- Comment #3 from Richard Biener  2012-10-17 
09:20:01 UTC ---

Honza, this is most certainly yours.

[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2012-10-17 
09:22:41 UTC ---

"7.1.5.2.4 Evaluation of numeric intrinsic operations"

"The execution of any numeric operation whose result is not defined by the

arithmetic used by the processor is prohibited."



Hm, the arithmetic used by the processor specifies that HUGE(i) + 1 is -INF.

Does that mean the value after the loop should be the wrapped value?



>From the sentence above I do not read that the standard requires a

specific behavior, just that it prohibits undefined behavior.  Which

means this is similar to C implementation specific behavior?  Does

the standard require us to be consistent there then?  Currently GCC

assumes signed overflow invokes undefined behavior.

[Bug target/45475] target attribute use in libcpp breaks LTO bootstrap

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||lto

 Target||i?86-*-*

 Status|REOPENED|NEW

  Component|lto |target

Summary|target use in libcpp breaks |target attribute use in

   |LTO bootstrap   |libcpp breaks LTO bootstrap



--- Comment #16 from Richard Biener  2012-10-17 
09:34:14 UTC ---

The attribute handling side is missing from the LTO frontend, but I

wonder why handling the middle-end piece is not enough for it to work ...



The target / optimize attributes seem to be designed in a weird way ...

(ix86_valid_target_attribute_p does work besides checking whether

the attribute is "valid").  I'm sure that's not how it was intended to

work so I am calling this a target bug.  This work should be done

in the ix86_set_current_function hook.

[Bug libstdc++/54943] New: ARM - EABI - varargs floating point issue

[selvaraj.santhosh at gmail dot com]

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



 Bug #: 54943

   Summary: ARM - EABI - varargs floating point issue

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: selvaraj.santh...@gmail.com





I have a data-conversion function in our ARM9 code which uses varargs. I've

been using an arm-elf from a couple of years ago, with no problems. Recently,

we upgraded to the arm-eabi-none , and I'm finding that we now have problems

with floating point values. What I eventually discovered is that doubles are

being forced to 8-byte boundaries, and the existing varargs floating-point

handler didn't expect to find gaps in the args.



I can manually check the pointer and force it up to an eight-byte boundary (in

fact, I did that, and that fixed the issue entirely), but I'd like to know why

this has suddenly started happening.



I would appreciate any advice or insights that anyone could provide on these

issues.

[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)

[burnus at gcc dot gnu.org]

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



--- Comment #4 from Tobias Burnus  2012-10-17 
10:41:49 UTC ---

(In reply to comment #3)

> "7.1.5.2.4 Evaluation of numeric intrinsic operations"

> "The execution of any numeric operation whose result is not defined by the

> arithmetic used by the processor is prohibited."



(Note that "processor" in the standard refers to the combination of compiler,

libraries, operating system and hardware/CPU.)





> Hm, the arithmetic used by the processor specifies that HUGE(i) + 1 is -INF.



I think you mean -HUGE(i)-1. (That's at least the hardware part of the

"processor".)





> Does that mean the value after the loop should be the wrapped value?



Seems so - at least that is what one gets after "huge(i)+1" - at least if one

regards it as defined by the processor.





> From the sentence above I do not read that the standard requires a

> specific behavior, just that it prohibits undefined behavior.



The wording is a bit vague as it is a catch all phrase.



Well, to a certain extend it is undefined behaviour: It depends on the

"processor" whether it is valid or not.





> Which means this is similar to C implementation specific behavior?



I don't know the exact wording for this case in the C standard, but I assume

so.





> Does the standard require us to be consistent there then?  Currently GCC

> assumes signed overflow invokes undefined behavior.



I think it doesn't require (but permits) this consistency. (As the semantic

differs between C and Fortran it can't require it.) The standard only specifies

interoperability with the "companion processor" for variables and function

calls.





Thus, the question is mostly what can a user (reasonably) expect. Users

seemingly like to use HUGE in loop bounds (cf. also PR 40205). For real-world

code I could imagine some use like

  do i = 1, huge(i)

...

if (cond) exit

  end do

But I am not sure whether any real-world code contains such algorithms. At

least the two codes I use don't.

[Bug rtl-optimization/54944] New: 400.perlbench fails with segmentation fault

[Ganesh.Gopalasubramanian at amd dot com]

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



 Bug #: 54944

   Summary: 400.perlbench fails with segmentation fault

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ganesh.gopalasubraman...@amd.com





Perlbench fails with segmentation fault with latest trunk (r192528).



Commandline: gcc -o doop.o -O3 -DSPEC_CPU -DNDEBUG -DPERL_CORE

-funroll-all-loops -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX_X64 doop.c



doop.c: In function 'Perl_do_vop':

doop.c:1334:1: internal compiler error: Segmentation fault

 }

 ^

0x8c175f crash_signal

../../source1/gcc/toplev.c:335

0x60feb8 TEST_BIT

../../source1/gcc/sbitmap.h:107

0x60feb8 duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int,

simple_bitmap_def*, edge_def*, vec_t**, int)

../../source1/gcc/cfgloopmanip.c:1184

0x7e1066 peel_loop_completely

../../source1/gcc/loop-unroll.c:486

0x7e1066 peel_loops_completely

../../source1/gcc/loop-unroll.c:250

0x7e1066 unroll_and_peel_loops(int)

../../source1/gcc/loop-unroll.c:160

0x7d6387 rtl_unroll_and_peel_loops

../../source1/gcc/loop-init.c:378



I am drilling down the svn revision.

[Bug target/54943] ARM - EABI - varargs floating point issue

[mikpe at it dot uu.se]

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



--- Comment #1 from Mikael Pettersson  2012-10-17 
11:25:07 UTC ---

Please provide a test case.

[Bug c/54945] New: Too strong non-aliasing analysis?

[gcc at robbertkrebbers dot nl]

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



 Bug #: 54945

   Summary: Too strong non-aliasing analysis?

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: g...@robbertkrebbers.nl





Consider the following C program:



#include

#include



int main(void) {

  int x=30, y=31;

  int *p = &x+1, *q=&y;

  intptr_t i=(intptr_t)p, j=(intptr_t)q;

  printf("%" PRIdPTR " %" PRIdPTR " %d\n", i, j, i==j);

}



gcc (4.7.1, with -Wall -O2 -std=c99) compiles this program, without giving any

compilation errors or warnings, and print something like



  140734157513308 140734157513308 0



when ran on a Debian amd64 machine.



Here, gcc allocates the storage of x and y adjacently (which is perfectly

fine). Therefore, the pointers &x+1 and &y point to the same storage, and thus

when converting these pointers to integers, it yields the same integers. But,

apparently, gcc's aliasing analysis optimizes the comparison i==j to 0, as it

believes that i and j are "unrelated".



I am unsure whether optimizations as the above are valid with respect to the

C11 or C99 standard. On the hand hand, it seems pretty strange that an integer

comparison of equal integers yield 0. On the other hand, the infamous Defect

report #260



  http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm



states something like



  If two objects have identical bit-pattern

  representations and their types are the

  same they may still compare as unequal



in the committee's response. But I do not see if their notion of "origin" or

"provenance" applies to integers obtained via a cast from a pointer as well.



So, is this a bug (i.e. gcc performs optimizations it should not), or is there

some dark corner in the C standard allowing this? 



I do not believe there is any undefined behavior here. The only thing that

might be considered "strange" is creating the pointer &x+1. But as long as it

is not dereferenced, that is perfectly fine by the C standard (6.5.6p8).

[Bug rtl-optimization/54944] 400.perlbench fails with segmentation fault

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #1 from Igor Zamyatin  2012-10-17 
11:36:00 UTC ---

Probably this is a dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54942

[Bug target/54943] ARM - EABI - varargs floating point issue

[selvaraj.santhosh at gmail dot com]

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



--- Comment #2 from Santhosh Kumar Selvaraj  2012-10-17 11:41:00 UTC ---



int main()

{

float floatValue = 100.0;

char buffer[32];



sprintf (buffer, 32, "%f", floatValue);

printf ("The string is : %s\n", buffer);

return 0;

}



Result:

The string is : 100 (arm-elf) -> GCC less than V3.0

The string is : 5.333 (arm-eabi) -> GCC 4.7.1

[Bug rtl-optimization/54944] 400.perlbench fails with segmentation fault

[Ganesh.Gopalasubramanian at amd dot com]

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



--- Comment #2 from GGanesh  
2012-10-17 11:57:49 UTC ---

Yes occurs with revision r192219.

[Bug c++/54946] New: ICE on template parameter from cast char-pointer in C++11 constexpr struct

[bisqwit at iki dot fi]

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



 Bug #: 54946

   Summary: ICE on template parameter from cast char-pointer in

C++11 constexpr struct

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bisq...@iki.fi





The following C++11 code causes an ICE.



templatestatic void testfunc();

constexpr struct testtype { const char* str; } test = { "abc"} ;

void (*functionpointer)() = testfunc<(const char*) test.str>;



Sample GCC commandline to invoke the error: g++ test1.cc -std=c++0x



Error message on g++-4.7.1 (Debian 4.7.1-7 on x86_64)

test1.cc:5:29: internal compiler error: in convert_nontype_argument, at

cp/pt.c:5794



Error message on g++-4.6.3 (Debian 4.6.3-11 on x86_64):

test1.cc:5:29: internal compiler error: in convert_nontype_argument, at

cp/pt.c:5430



I do not know whether the code is valid.

Things that do not affect the error:

- Adding / removing "const" at any point or changing pointers into arrays at

any point

- Changing functionpointer into an array of function pointers

- Any code generation related options (such as -m32 or optimization levels)



Things that do hide the error:

- Removing the (const char*) cast entirely

- Changing the string pointers into integers

- Removing the struct encapsulation from str (making it constexpr const char*

str = "abc"; and removing "test." from the third line)

[Bug c/54945] Too strong non-aliasing analysis?

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-17

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-10-17 
12:06:59 UTC ---

Doesn't look like alias analysis to me, I'd say the problem is in

fold_sign_changed_comparison which has:



  if ((TYPE_UNSIGNED (inner_type) != TYPE_UNSIGNED (outer_type)

   || POINTER_TYPE_P (inner_type) != POINTER_TYPE_P (outer_type))

  && code != NE_EXPR

  && code != EQ_EXPR)

return NULL_TREE;



While for TYPE_UNSIGNED changes NE_EXPR/EQ_EXPR are just fine, for

POINTER_TYPE_P changes I'm afraid we just need to be conservative.

[Bug c++/54946] ICE on template parameter from cast char-pointer in C++11 constexpr struct

[bisqwit at iki dot fi]

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



--- Comment #1 from Joel Yliluoma  2012-10-17 12:10:21 
UTC ---

Please excuse the "conts" typo in the post; naturally it meant to say "const"

there. The typo is not relevant to the bug report.



I changed the code a few times trying to figure out what triggers the error and

what does not, and the version I copypasted was not a compiled one.

[Bug fortran/48636] Enable more inlining with -O2 and higher

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #23 from Jakub Jelinek  2012-10-17 
12:20:05 UTC ---

If the middle-end was hinted something about the array descriptors (what fields

in the struct are important and what not), perhaps IPA-CP could handle also

arguments pointing to array descriptors if all callers fill the descriptor in

certain important way (where important would be constant strides and/or

constant start/end in some of the dimension(s)).  I guess many Fortran routines

are just too large for inlining, but optimizing constant strides etc. might

still be useful.

[Bug c++/54770] sibling call optimization is not applied where it ought to be

[jakub at gcc dot gnu.org]

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



--- Comment #7 from Jakub Jelinek  2012-10-17 
12:27:15 UTC ---

It is just that though, a workaround, it doesn't workaround say:

void bar (char *);

int baz ();



int

foo ()

{

  {

char buf[64];

bar (buf);

  }

  return baz ();

}

[Bug c++/54501] infinite recursion on illegal code

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-10-17

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #2 from Paolo Carlini  2012-10-17 
12:28:35 UTC ---

On it.

[Bug c/54945] Too strong non-aliasing analysis?

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||mpolacek at gcc dot gnu.org

 AssignedTo|unassigned at gcc dot   |mpolacek at gcc dot gnu.org

   |gnu.org |



--- Comment #2 from Marek Polacek  2012-10-17 
12:50:42 UTC ---

I'll try something, mine for now.

[Bug c/54945] Too strong non-aliasing analysis?

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0



--- Comment #3 from Marek Polacek  2012-10-17 
13:01:15 UTC ---

Happens with trunk (r192499) as well.

[Bug target/54943] ARM - EABI - varargs floating point issue

[rearnsha at gcc dot gnu.org]

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



Richard Earnshaw  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Richard Earnshaw  2012-10-17 
13:07:19 UTC ---

Because that's what the EABI specification requires.  Yes it's a change from

the old ABI.



See:

http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html



And in particular the "ABI for the ARM Architecture" document.



The change was made because having strict alignment of data types can

significantly improve performance on implementations with 64-bit and wider

data-paths within the core.

[Bug c++/54947] New: [4.7/4.8 Regression] [C++11] lambda cannot capture-by-copy inside braced-init-list

[redi at gcc dot gnu.org]

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

 Bug #: 54947
   Summary: [4.7/4.8 Regression] [C++11] lambda cannot
capture-by-copy inside braced-init-list
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Blocks: 54367


struct X
{
  template
X(L)
{ }
};

template
  void
  test()
  {
int i = 0;

A a_ok_1( [=] { return i; } );  // OK
A a_ok_2( [i] { return i; } );  // OK

A a_err_1{ [i] { return i; } };  // error
A a_err_2{ [=] { return i; } };  // error
  }

int main()
{
  test();
}


lam.cc:17:17: error: the value of ‘i’ is not usable in a constant expression
 A a_err_1{ [i] { return i; } };  // error
 ^
lam.cc:12:9: note: ‘int i’ is not const
 int i = 0;
 ^
lam.cc:18:17: error: expression ‘ =
’ is not a constant-expression
 A a_err_2{ [=] { return i; } };  // error
 ^

There's no error when using direct-initialization, only list-initialization.
No error if test() is not a function template.

Works fine with 4.6 and clang++

[Bug fortran/48636] Enable more inlining with -O2 and higher

[dominiq at lps dot ens.fr]

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



--- Comment #24 from Dominique d'Humieres  
2012-10-17 13:13:24 UTC ---

Summary for the polyhedron tests (pb05):



(a) revision 192449 unpatched

(b) revision 192516 with patch in comment #20

options: -fprotect-parens -Ofast -funroll-loops -ftree-loop-linear \

 -fomit-frame-pointer -fwhole-program -flto -fno-tree-loop-if-convert



Benchmark CompileExecutable  Ave Run   

 Name  (secs)   (bytes)   (secs)  

  (a)   (b)(a) (b)(a)   (b) 

-   ---   ---  --  --   ---   ---

   ac  6.30  9.66   54904   54856  9.12  8.49

   aermod129.56178.13 1158904 1527680 17.69 17.28

  air 25.64 29.95  102752  106712  7.15  7.16

 capacita  6.34 18.99   69096  130536 42.00 40.57

  channel  2.99  3.51   34736   34736  3.03  3.02

doduc 19.51 23.70  163528  196016 27.54 27.65

  fatigue  7.03  7.54   69312   69248  4.92  2.94

  gas_dyn 14.65 14.91   99320   99280  3.72  3.88

   induct 19.50 21.02  149160  161552 13.18 13.14

linpk  1.84  2.91   22008   17832 21.65 21.69

 mdbx  6.59 10.14   68800   80968 12.85 12.78

   nf  6.34 24.25   59544  104544 18.95 18.88

  protein 22.27 46.34  119056  156048 35.65 35.41

   rnflow 17.75 31.23  114600  147280 23.56 23.54

 test_fpu 10.69 20.66   76640  117512 10.89 10.95

 tfft  1.62  2.93   22424   22384  3.34  3.33



Geometric Mean Execution Time =  (a) 11.88 seconds (b) 11.43 seconds



I also see many failures for the gcc.dg/tree-ssa/slsr-* tests: slsr-2.c to

slsr-11.c, slsr-14.c to slsr-20.c, slsr-24.c, and slsr-25.c, and for

gfortran.dg/vect/vect-8.f90: the loop



do while(ii >  1)

ipnt= ipntp

ipntp= ipntp+ii

ii= ishft(ii,-1)

i= ipntp+1

!dir$ vector always

   x(ipntp+2:ipntp+ii+1)=x(ipnt+2:ipntp:2)-v(ipnt+2:ipntp:2) &

 &*x(ipnt+1:ipntp-1:2)-v(ipnt+3:ipntp+1:2)*x(ipnt+3:ipntp+1:2)

END DO



is not vectorized because



154: not vectorized: complicated access pattern.

[Bug c++/54948] New: template unnecessarily displayed as "A< template-parameter-1-1 >" not "A"

[redi at gcc dot gnu.org]

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



 Bug #: 54948

   Summary: template unnecessarily displayed as "A<

template-parameter-1-1 >" not "A"

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: diagnostic

  Severity: enhancement

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: r...@gcc.gnu.org





template struct A;



template struct A { A(Y); };



A a;



This invalid code produces:



tp.cc: In instantiation of 'struct A':

tp.cc:5:8:   required from here

tp.cc:3:36: error: 'A<  >::Y' has incomplete type

 template struct A { A(Y); };

^

tp.cc:3:29: error: declaration of 'struct A'

 template struct A { A(Y); };

 ^



This is correct, but "A<  >::Y" is rather ugly.



At the point of the error the parameter has a name, so "A::Y" could be shown

instead.

[Bug target/54943] ARM - EABI - varargs floating point issue

[mikpe at it dot uu.se]

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



--- Comment #4 from Mikael Pettersson  2012-10-17 
13:30:09 UTC ---

Yes the EABI changes things, but I think the user error is that:



1. your sprintf uses homegrown varargs-parsing code, which won't work with

EABI; you should use  as supplied by gcc itself, or



2. somehow you're linking together library code compiled for pre-EABI with

application code compiled for EABI, though I would have expected the linker to

detect and reject such invalid combinations.



BTW, the test case is invalid, it's missing a needed #include  (you

mustn't call variadic functions without proper declarations in scope), and the

call to sprintf should call snprintf (or drop the ", 32" actual parameter).



Either way the error isn't in gcc.

[Bug fortran/54949] New: [F03] abstract procedure pointers not rejected

[janus at gcc dot gnu.org]

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



 Bug #: 54949

   Summary: [F03] abstract procedure pointers not rejected

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-invalid-code

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ja...@gcc.gnu.org





Test case (inspired by

https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/F_ROPgBJGpY):



program test

  implicit none

  abstract interface

subroutine abssub

end subroutine

  end interface

  pointer :: abssub



  abssub => sub



contains



  subroutine sub

  end subroutine



end







This currently gives an



internal compiler error: in fold_convert_loc, at fold-const.c:1979



but should be rejected, since a procedure pointer can not be ABSTRACT.

[Bug fortran/54949] [F03] abstract procedure pointers not rejected

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-10-17

 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from janus at gcc dot gnu.org 2012-10-17 13:52:54 UTC ---

Preliminary patch:



Index: gcc/fortran/symbol.c

===

--- gcc/fortran/symbol.c(revision 192392)

+++ gcc/fortran/symbol.c(working copy)

@@ -374,6 +374,7 @@ check_conflict (symbol_attribute *attr, const char

 *cray_pointee = "CRAY POINTEE", *data = "DATA", *value = "VALUE",

 *volatile_ = "VOLATILE", *is_protected = "PROTECTED",

 *is_bind_c = "BIND(C)", *procedure = "PROCEDURE",

+*proc_pointer = "PROCEDURE POINTER", *abstract = "ABSTRACT",

 *asynchronous = "ASYNCHRONOUS", *codimension = "CODIMENSION",

 *contiguous = "CONTIGUOUS", *generic = "GENERIC";

   static const char *threadprivate = "THREADPRIVATE";

@@ -604,6 +605,8 @@ check_conflict (symbol_attribute *attr, const char

   conf (procedure, asynchronous)

   conf (procedure, entry)



+  conf (proc_pointer, abstract)

+

   a1 = gfc_code2string (flavors, attr->flavor);



   if (attr->in_namelist

[Bug fortran/48636] Enable more inlining with -O2 and higher

[dominiq at lps dot ens.fr]

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



--- Comment #25 from Dominique d'Humieres  
2012-10-17 14:05:51 UTC ---

> I also see many failures for the gcc.dg/tree-ssa/slsr-* tests: slsr-2.c to

> slsr-11.c, slsr-14.c to slsr-20.c, slsr-24.c, and slsr-25.c, and for

> gfortran.dg/vect/vect-8.f90: the loop ...



This seems to be a glitch which appeared between r192440 and r192516 and

disappeared before or at r192531.

[Bug c/54950] New: Incorrect 32-bit moltiplication on m32c target

[m.galante at centrosistemi dot it]

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



 Bug #: 54950

   Summary: Incorrect 32-bit moltiplication on m32c target

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m.gala...@centrosistemi.it





m32c-elf-gcc (GCC) 4.7.2 hosted on Windows XP.



This simple program:



/*** BEGIN /

#include 



void multiply(unsigned char byte)

{

  printf("%ld\n", 100L * byte);

}



main()

{

  multiply(2);

  return 0;

}

/ END /



produces the correct result (200) only when compiled with -O0:



m32c-elf-gcc -msim -mcpu=m32c -O0 -omul32.out mul32.c

m32c-elf-run mul32.out



If I compile with -O1, -O2, -O3 or -Os I get 33920, which is 200 truncated

to 16-bit.

[Bug c/54951] New: Incorrect pointer handling on 32K boundary

[m.galante at centrosistemi dot it]

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



 Bug #: 54951

   Summary: Incorrect pointer handling on 32K boundary

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m.gala...@centrosistemi.it





Created attachment 28460

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28460

Simple test case to reproduce the bug



m32c-elf-gcc (GCC) 4.7.2 hosted on Windows XP.



The attached "run.bat" batch compiles and runs a simple program that adds a

constant value (COUNT) to a pointer (0x1) and prints the result.

The first result (a) is calculated by adding COUNT to the pointer, the second

result (b) is calculated by incrementing the pointer COUNT times.



When COUNT is 0x7FFF the result is correct for both a and b (0x17FFF).



When COUNT is 0x8000 the result is incorrect for a (0x8000) but correct for b

(0x18000).



When COUNT is 0x the result is incorrect for a (0x) but correct for b

(0x1) when compiled with -O0, and incorrect for both a and b (0x) when

compiled with -O1.

[Bug c/54952] New: Program crash on M32C when stack frame is more then 128 bytes

[m.galante at centrosistemi dot it]

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



 Bug #: 54952

   Summary: Program crash on M32C when stack frame is more then

128 bytes

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m.gala...@centrosistemi.it





Created attachment 28461

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28461

Test case



m32c-elf-gcc (GCC) 4.7.2 hosted on Windows XP.



If I compile and run the attached program with:



  m32c-elf-gcc -msim -mcpu=m32c -O1 -DDATASIZE=126 stack.c

  m32c-elf-run a.out



it works well. But if I increase DATASIZE to 127:



  m32c-elf-gcc -msim -mcpu=m32c -O1 -DDATASIZE=127 stack.c

  m32c-elf-run a.out



the program crashes.

[Bug fortran/54949] [F03] abstract procedure pointers not rejected

[janus at gcc dot gnu.org]

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



--- Comment #2 from janus at gcc dot gnu.org 2012-10-17 15:46:03 UTC ---

(In reply to comment #1)

> Preliminary patch:



... regtests cleanly.

[Bug debug/54953] New: [4.8 Regression] New sra-1.c FAILs on powerpc

[jakub at gcc dot gnu.org]

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



 Bug #: 54953

   Summary: [4.8 Regression] New sra-1.c FAILs on powerpc

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ja...@gcc.gnu.org

CC: aol...@gcc.gnu.org

Target: powerpc64-linux





When backporting the valtrack.c addition and related changes to 4.7 branch,

I've noticed it regresses some sra-1.c tests that used to pass, in particular

FAIL: gcc.dg/guality/sra-1.c  -O1  line 43 a.i == 4

(ditto for all other > -O1 levels).

The problem is that before fwprop1 we have:

(insn 11 10 12 2 (set (reg:HI 130 [ a$i ])

(asm_operands:HI ("") ("=r") 0 [

(reg:HI 131)

]

 [

(asm_input:HI ("0") (null):0)

]

 [] sra-1.c:40)) sra-1.c:40 -1

 (nil))

(insn 12 11 13 2 (set (reg:DI 127 [ a$i+-6 ])

(sign_extend:DI (reg:HI 130 [ a$i ]))) sra-1.c:40 21 {*rs6000.md:447}

 (nil))

(debug_insn 13 12 14 2 (var_location:HI a$i (subreg:HI (reg:DI 127 [ a$i+-6 ])

6)) sra-1.c:40 -1

 (nil))

and reg:HI 130 is really dead, and fwprop1 decides to propagate into the

debug_insn, so after fwprop1 debug_insn 13 contains (reg:HI 130) instead of the

subreg.  Then cprop1 comes and performs fast DCE, which decides to put a debug

temp for reg:HI 130 using DEBUG_TEMP_BEFORE_WITH_VALUE before the asm

instruction, but obviously asm_operands inside of var_location is never going

to expand to anything useful.  dce.c seems to be the only user of

DEBUG_TEMP_BEFORE_WITH_VALUE mode of insertion.  If the insn it is adding it to

is not marked (!marked_insn_p (insn)), then that is certainly the right thing

to do, the insn is going to be removed and we have no other option.  But if it

is

being kept, just debug temp is being added because of debug uses after the

pseudo became dead, then this is counterproductive.

[Bug debug/54953] [4.8 Regression] New sra-1.c FAILs on powerpc

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-17

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-10-17 
16:03:50 UTC ---

I've tried:

--- dce.c.jj12012-10-08 21:37:36.0 +0200

+++ dce.c2012-10-17 17:32:19.855891915 +0200

@@ -880,7 +880,9 @@ word_dce_process_block (basic_block bb,



 for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)

   dead_debug_insert_temp (&debug, DF_REF_REGNO (*def_rec), insn,

-  DEBUG_TEMP_BEFORE_WITH_VALUE);

+  marked_insn_p (insn)

+  ? DEBUG_TEMP_AFTER_WITH_REG

+  : DEBUG_TEMP_BEFORE_WITH_VALUE);

   }



 if (dump_file)

@@ -981,7 +983,9 @@ dce_process_block (basic_block bb, bool

 if (debug.used && !bitmap_empty_p (debug.used))

   for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)

 dead_debug_insert_temp (&debug, DF_REF_REGNO (*def_rec), insn,

-DEBUG_TEMP_BEFORE_WITH_VALUE);

+needed

+? DEBUG_TEMP_AFTER_WITH_REG

+: DEBUG_TEMP_BEFORE_WITH_VALUE);

   }



   dead_debug_local_finish (&debug, NULL);

but that isn't enough (well, it seems likely the testcase passes again, but

isn't correct).

The problem is in:

654  /* If there's a single (debug) use of an otherwise unused REG, and

655 the debug use is not part of a larger expression, then it

656 probably doesn't make sense to introduce a new debug temp.  */

657  if (where == DEBUG_TEMP_AFTER_WITH_REG && !uses->next)

658{

659  rtx next = DF_REF_INSN (uses->use);

660

661  if (DEBUG_INSN_P (next) && reg == INSN_VAR_LOCATION_LOC (next))

662{

663  XDELETE (uses);

664  return 0;

665}

666}

in dead_debug_insert_temp, which triggers in this case and just does nothing. 

I wonder why that hunk has been added, if the pseudo is live at that point,

surely it doesn't make sense, but if it becomes dead in between the insn and

the single debug use, then inserting a new debug temp is desirable even in that

case.  If it is fine for some reason for df-problems.c uses, perhaps we should

have another DEBUG_TEMP_AFTER_WITH_REG_FORCE where mode or similar that would

do the same thing as DEBUG_TEMP_AFTER_WITH_REG, but not trigger this kind of

?optimization?.

[Bug c/54954] New: malloc optimizations not disabled by -fno-builtin

[swalter at lexmark dot com]

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



 Bug #: 54954

   Summary: malloc optimizations not disabled by -fno-builtin

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: swal...@lexmark.com





Consider the code:



static int foo;



void bar ()

{

foo = 0;

malloc();

assert(foo);

}



foo is not reloaded after the call to malloc, even when -fno-builtin is thrown.

 This is incorrect behavior because malloc() could call back into the current

module, where foo is modified.  A full example is attached.



(Assume that malloc calls increment_count() if I can't get a second file to

attach...)

[Bug c/54954] malloc optimizations not disabled by -fno-builtin

[swalter at lexmark dot com]

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



--- Comment #1 from swalter at lexmark dot com 2012-10-17 16:10:29 UTC ---

Created attachment 28462

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28462

Bug testcase

[Bug c/54945] Too strong non-aliasing analysis?

[mpolacek at gcc dot gnu.org]

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



--- Comment #4 from Marek Polacek  2012-10-17 
16:11:08 UTC ---

In .ccp1 we have:

i_6 = (intptr_t) &MEM[(void *)&x + 4B];

j_7 = (intptr_t) &y;

_8 = i_6 == j_7;

_9 = (int) _8;

but in .forwprop1:

_8 = 0;

_9 = (int) _8;

[Bug c/54954] malloc optimizations not disabled by -fno-builtin

[swalter at lexmark dot com]

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



--- Comment #2 from swalter at lexmark dot com 2012-10-17 16:14:33 UTC ---

Created attachment 28463

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28463

malloc implementation for test.c

[Bug c++/54955] New: alignas example in gcc 4.8 changes.html won't compile

[mib.bugzilla at gmail dot com]

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



 Bug #: 54955

   Summary: alignas example in gcc 4.8 changes.html won't compile

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mib.bugzi...@gmail.com





gcc 4.8 changes.html file gives this example:

alignas(double) int i;



But the snapshot from Oct 14 2012 gives this message:

g++ -c -std=c++11 alignas.cpp

alignas.cpp:1:1: error: expected unqualified-id before 'alignas'

 alignas(double) int f;

 ^



If alignas is moved to the end of the declaration it compiles okay:

int f alignas(double);



doc error?



Could you also confirm whether c++11 keyword alignas is the same as c1x

_Alignas?



Thanks and regards

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

[mib.bugzilla at gmail dot com]

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



--- Comment #1 from mib.bugzilla at gmail dot com 2012-10-17 16:21:56 UTC ---

p.s.

This example is given here: http://en.cppreference.com/w/cpp/language/alignas



char alignas(128) cacheline[128];



but g++ complains similarly to the root report

[Bug other/54956] New: GCC 4.7.2: internal compiler error: in emit_move_insn, at expr.c:3435

[devurandom at gmx dot net]

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



 Bug #: 54956

   Summary: GCC 4.7.2: internal compiler error: in emit_move_insn,

at expr.c:3435

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: devuran...@gmx.net





When configuring libstdc++v3 for CHOST/CTARGET=spu-elf:

configure:15317: checking for atomic builtins for bool

configure:15319: 

/var/tmp/portage/cross-spu-elf/gcc-4.7.2/work/build/./gcc/xgcc -shared-libgcc

-B/var/tmp/portage/cross-spu-elf/gcc-4.7.2/work/b

uild/./gcc -nostdinc++

-L/var/tmp/portage/cross-spu-elf/gcc-4.7.2/work/build/spu-elf/libstdc++-v3/src

-L/var/tmp/portage/cross-spu-elf/gcc-4.7.2/

work/build/spu-elf/libstdc++-v3/src/.libs -B/usr/spu-elf/bin/

-B/usr/spu-elf/lib/ -isystem /usr/spu-elf/include -isystem

/usr/spu-elf/sys-include

-c -O0 -S  conftest.cpp >&5

configure: In function 'int main()':

configure:15309:47: internal compiler error: in emit_move_insn, at expr.c:3435

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

configure:15322: $? = 1

configure:15330: result: 



Code as found in gcc-4.7.2/libstdc++-v3/acinclude.m4:

   typedef bool atomic_type;

   atomic_type c1;

   atomic_type c2;

   atomic_type c3(0);

   __atomic_fetch_add(&c1, c2, __ATOMIC_RELAXED);

   __atomic_compare_exchange_n(&c1, &c2, c3, true, __ATOMIC_ACQ_REL,

   __ATOMIC_RELAXED);

   __atomic_test_and_set(&c1, __ATOMIC_RELAXED);

   __atomic_load_n(&c1, __ATOMIC_RELAXED);



Portage 2.2.0_alpha138 (default/linux/amd64/10.0, gcc-4.7.2, glibc-2.15-r2,

2.6.18-308.16.1.el5 x86_64)

=

System uname:

Linux-2.6.18-308.16.1.el5-x86_64-Quad-Core_AMD_Opteron-tm-_Processor_2352-with-gentoo-2.1

Timestamp of tree: Tue, 16 Oct 2012 21:45:01 +

distcc 3.1 x86_64-pc-linux-gnu [disabled]

app-shells/bash:  4.2_p37

dev-lang/python:  2.7.3-r2, 3.2.3::ambro-cross

sys-apps/baselayout:  2.1-r1

sys-apps/openrc:  0.9.8.4

sys-apps/sandbox: 2.5

sys-devel/autoconf:   2.68

sys-devel/automake:   1.11.6

sys-devel/binutils:   2.22-r1

sys-devel/gcc:4.7.2

sys-devel/gcc-config: 1.7.3

sys-devel/libtool:2.4-r1

sys-devel/make:   3.82-r3

sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers)

sys-libs/glibc:   2.15-r2

Repositories: gentoo ambro-cross local sunrise

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="* -@EULA"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-pipe -O2 -march=opteron-sse3"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf

/etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"

CXXFLAGS="-pipe -O2 -march=opteron-sse3"

DISTDIR="/var/cache/portage/distfiles"

EMERGE_DEFAULT_OPTS="--usepkg --binpkg-respect-use --keep-going"

FCFLAGS="-O2 -pipe"

FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified

distlocks ebuild-locks fixlafiles news parallel-fetch parallel-install p

reserve-libs protect-owned sandbox sfperms strict unknown-features-warn

unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"

FFLAGS="-O2 -pipe"

GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/

http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://distfiles.gentoo.o

rg"

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu"

PKGDIR="/var/cache/portage/packages"

PORTAGE_COMPRESS="xz"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress

--force --whole-file --delete --stats --human-readable --timeout=

180 --exclude=/distfiles --exclude=/local --exclude=/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/var/cache/portage/gentoo"

PORTDIR_OVERLAY="/var/lib/layman/ambro-cross /var/cache/portage/local

/var/cache/portage/overlays/sunrise"

[...]

Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS,

PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OP

TS, USE_PYTHON

[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #5 from Tobias Burnus  2012-10-17 
17:02:48 UTC ---

I asked at

https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/mkbYH6F9G2M

and two former J3 committee members concur that the code of comment 0 is

invalid:



Dick Hendrickson wrote: 'I think there was an interpretation request a few

years ago about something like this.  I think the answer was "bad program".'



Richard Maine wrote: [...] 'the answer from the standard, which is basically

that the program is not conforming on procesors where the result for i

is not defined.'





Thus, I close the bug as INVALID.

[Bug middle-end/40205] OpenMP do loop with MAXINT gives wrong trip count

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||burnus at gcc dot gnu.org

 Resolution||WONTFIX



--- Comment #4 from Tobias Burnus  2012-10-17 
17:10:40 UTC ---

(In reply to comment #0)

>   upper = huge(maxint)

>   lower = upper - 9! The 9 can of course be changed

> !$omp parallel do

>   do i = lower, upper



As the Fortran program is nonconforming (even without OpenMP), I close this PR

as WONTFIX.



The reason that the program is nonconforming is the same as the OpenMP issue:

One has "huge(i)+1" which is not representable.



In case of Fortran, the standard effectively mandates that the DO variable "i"

is "upper + 1" after the loop, but that number is not representable if "upper"

is "huge(i)". As it is not representable, the code is nonconforming. See PR

54932 for quotes from the standard.



(For the OpenMP part, one has "<= ubound" which is transformed to "< ubound+1".

That part could be fixed, but why should one bother if the Fortran code itself

is already invalid.)

[Bug web/54955] alignas example in gcc 4.8 changes.html won't compile

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2012-10-17 
17:21:58 UTC ---

I *think* the example is valid, so it's a compiler bug ... but I'm not sure.

[Bug middle-end/54945] Too strong non-aliasing analysis?

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 CC||pinskia at gcc dot gnu.org

  Component|c   |middle-end



--- Comment #5 from Andrew Pinski  2012-10-17 
17:40:14 UTC ---

There is most likely some stripping of casts which is not valid.

[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||kargl at gcc dot gnu.org



--- Comment #6 from kargl at gcc dot gnu.org 2012-10-17 17:58:08 UTC ---

(In reply to comment #5)

> I asked at

> https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/mkbYH6F9G2M

> and two former J3 committee members concur that the code of comment 0 is

> invalid:

> 

> Dick Hendrickson wrote: 'I think there was an interpretation request a few

> years ago about something like this.  I think the answer was "bad program".'

> 

> Richard Maine wrote: [...] 'the answer from the standard, which is basically

> that the program is not conforming on procesors where the result for i

> is not defined.'

> 

> 

> Thus, I close the bug as INVALID.



I don't care enough to re-open the PR, but you'll

see that at least one person disagrees with both

former J3 members.



The Standard does not define 'incremented' and

'incrementation', and in particular, these words

are not defined in terms of the numeric intrinsic

operations and so you cannot appeal to Section 7.

[Bug middle-end/54957] New: Two crashes introduced by rev192488

[rmansfield at qnx dot com]

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



 Bug #: 54957

   Summary: Two crashes introduced by rev192488

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: rmansfi...@qnx.com

CC: era...@google.com





http://gcc.gnu.org/viewcvs?view=revision&revision=192488





sh4-unknown-linux-gnu no longer builds libgcc.



0x7df7df emit_cmp_and_jump_insn_1

../../gcc/optabs.c:4273

0x7df7df emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,

machine_mode, int, rtx_def*, int)

../../gcc/optabs.c:4324

0x6136f6 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,

machine_mode, rtx_def*, rtx_def*, rtx_def*, int)

../../gcc/dojump.c:1072

0x61479b do_compare_and_jump

../../gcc/dojump.c:1154

0x6164c1 do_jump_1(tree_code, tree_node*, tree_node*, rtx_def*, rtx_def*, int)

../../gcc/dojump.c:206

0x5ba1de expand_gimple_cond

../../gcc/cfgexpand.c:1852

0x5c1b9b expand_gimple_basic_block

../../gcc/cfgexpand.c:3832

0x5c2ec5 gimple_expand_cfg

../../gcc/cfgexpand.c:4477

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.





arm-unknown-linux-gnu (not EABI) crashes building libstdc++-v3 (compiling

thread.cc)



Program received signal SIGSEGV, Segmentation fault.

0x087696fb in emit_case_dispatch_table (index_expr=0x1121f18, 

index_type=0x1403c0, case_list=0xa7de974, default_label=0x125e18c, 

minval=0x12b690, maxval=0x12bbf4, range=0x12bbf4, stmt_bb=0x0)

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/stmt.c:1919





#0  0x087696fb in emit_case_dispatch_table (index_expr=0x1121f18, 

index_type=0x1403c0, case_list=0xa7de974, default_label=0x125e18c, 

minval=0x12b690, maxval=0x12bbf4, range=0x12bbf4, stmt_bb=0x0)

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/stmt.c:1919

#1  0x08769fab in expand_sjlj_dispatch_table (dispatch_index=0x125bc9c, 

dispatch_table=0xa7b2be0)

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/stmt.c:2292

#2  0x084deedd in sjlj_emit_dispatch_table (dispatch_label=0x125a924, 

num_dispatch=6)

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/except.c:1363

#3  0x084df160 in sjlj_build_landing_pads ()

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/except.c:1420

#4  0x084df5fe in finish_eh_generation ()

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/except.c:1454

#5  0x08430102 in gimple_expand_cfg ()

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/cfgexpand.c:4579

#6  0x086d148a in execute_one_pass (pass=0x9094900)

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/passes.c:2320

#7  0x086d1a4d in execute_pass_list (pass=0x9094900)

at /builds/gnu-gcc-trunk/svn/arm-oabi/../gcc/passes.c:2381

[Bug middle-end/54957] Two crashes introduced by rev192488

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-10-17 
18:04:16 UTC ---

> arm-unknown-linux-gnu (not EABI) 

I thought that support was removed.

[Bug middle-end/54957] Two crashes introduced by rev192488

[rmansfield at qnx dot com]

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



--- Comment #2 from Ryan Mansfield  2012-10-17 
18:04:49 UTC ---

Created attachment 28464

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28464

preprocessed src (not reduced)

[Bug middle-end/54957] Two crashes introduced by rev192488

[eraman at google dot com]

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



--- Comment #3 from Easwaran Raman  2012-10-17 
18:08:24 UTC ---

(In reply to comment #0)

> http://gcc.gnu.org/viewcvs?view=revision&revision=192488

> 

> 

> sh4-unknown-linux-gnu no longer builds libgcc.

> 

> 0x7df7df emit_cmp_and_jump_insn_1

> ../../gcc/optabs.c:4273

> 0x7df7df emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,

> machine_mode, int, rtx_def*, int)

> ../../gcc/optabs.c:4324

> 0x6136f6 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,

> machine_mode, rtx_def*, rtx_def*, rtx_def*, int)

> ../../gcc/dojump.c:1072

> 0x61479b do_compare_and_jump

> ../../gcc/dojump.c:1154

> 0x6164c1 do_jump_1(tree_code, tree_node*, tree_node*, rtx_def*, rtx_def*, int)

> ../../gcc/dojump.c:206

> 0x5ba1de expand_gimple_cond

> ../../gcc/cfgexpand.c:1852

> 0x5c1b9b expand_gimple_basic_block

> ../../gcc/cfgexpand.c:3832

> 0x5c2ec5 gimple_expand_cfg

> ../../gcc/cfgexpand.c:4477

> Please submit a full bug report,

> with preprocessed source if appropriate.

> Please include the complete backtrace with any bug report.

> See  for instructions.

> 



The first one seems a dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938.

The obvious fix is to remove the assert. Will send out a patch.

[Bug middle-end/54957] Two crashes introduced by rev192488

[rmansfield at qnx dot com]

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



--- Comment #4 from Ryan Mansfield  2012-10-17 
18:10:25 UTC ---

(In reply to comment #1)

> > arm-unknown-linux-gnu (not EABI) 

> I thought that support was removed.



I have a local patch re-enabling it, but I don't think it's specific to the

configuration. Do you? I can try to reproduce it on another target..

[Bug middle-end/54957] Two crashes introduced by rev192488

[eraman at google dot com]

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



--- Comment #5 from Easwaran Raman  2012-10-17 
18:24:48 UTC ---

Created attachment 28465

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28465

Proposed patch

[Bug middle-end/54957] Two crashes introduced by rev192488

[eraman at google dot com]

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



--- Comment #6 from Easwaran Raman  2012-10-17 
18:26:30 UTC ---

(In reply to comment #5)

> Created attachment 28465 [details]

> Proposed patch



I haven't tested the patch. Ryan, could you please confirm this patch fixes the

crashes?



Thanks,

Easwaran

[Bug middle-end/54957] Two crashes introduced by rev192488

[rmansfield at qnx dot com]

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



--- Comment #7 from Ryan Mansfield  2012-10-17 
18:29:45 UTC ---

(In reply to comment #6)

> (In reply to comment #5)

> > Created attachment 28465 [details]

> > Proposed patch

> 

> I haven't tested the patch. Ryan, could you please confirm this patch fixes 
> the

> crashes?



The patch fixes the crash in emit_cmp_and_jump_insn_1, but not the one in

emit_case_dispatch_table.

[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)

[burnus at gcc dot gnu.org]

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



--- Comment #7 from Tobias Burnus  2012-10-17 
18:51:08 UTC ---

(In reply to comment #6)

> but you'll see that at least one person disagrees with both

> former J3 members.



The only way to get a definite answer is to fill an interpretation request and

wait until it has passed both the J3 and WG5 vote. However, based on my reading

of the standard and the three Richards (Maine, Hendrickson, and Biener), it is

invalid. I haven't seen so far any standard-backed argument which reasons why

it should be valid. (Besides that it were nice and I concur that, if one

forgets about the value after the loop, it seems to be reasonable if m2 ==

huge(int-do-var) were valid.)



I quickly tried to find the IR request





> The Standard does not define 'incremented' and

> 'incrementation', and in particular, these words

> are not defined in terms of the numeric intrinsic

> operations and so you cannot appeal to Section 7.



I disagree. One can surely read something differently, but I think it is very

difficult to have a reading which makes both sense in terms of the English

language ("increment" = "the action or process of increasing especially in

quantity or value : enlargement"; source: Marriam-Webster) and the common

understanding how programs behave.



For instance, for



  do i = 2, 5, 1

print *, i

  end do



The standard has: "The DO variable, if any, is incremented by the value of the

incrementation parameter m3."



In my reading of the standard, the program will print 2, 3, 4, 5 and after the

loop i has the value 6. That matches in my understanding "i = i + 1" where m3

== 1; thus, I fail to see why Section 7.1.5.2.4 shouldn't apply in this case.



Can you come up with a (somewhat sensible) different interpretation which still

allows the program of comment 0?



(I concur that the invalidity of the program when m2 ==

huge(integer-do-variable) is a bit surprising at a glance, but that doesn't

make the program valid. I also concur that one could have written the standard

differently such that the program becomes valid.)

[Bug middle-end/54957] Two crashes introduced by rev192488

[eraman at google dot com]

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



Easwaran Raman  changed:



   What|Removed |Added



  Attachment #28465|0   |1

is obsolete||



--- Comment #8 from Easwaran Raman  2012-10-17 
18:56:14 UTC ---

Created attachment 28466

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28466

Proposed patch



Handle the possibility that stmt_bb may be NULL in emit_case_dispatch_table.

Untested.

[Bug middle-end/54957] Two crashes introduced by rev192488

[rmansfield at qnx dot com]

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



--- Comment #9 from Ryan Mansfield  2012-10-17 
19:05:36 UTC ---

(In reply to comment #8)

> Created attachment 28466 [details]

> Proposed patch

> 

> Handle the possibility that stmt_bb may be NULL in emit_case_dispatch_table.

> Untested.



I was able to reproduce the crash in emit_case_dispatch_table on a stock 

sh4-unknown-linux-gnu configuration with another testcase. This patch fixes the

all crashes I've seen so far.

[Bug fortran/54958] New: Wrongly rejects ac-implied-DO variables which also occur with INTENT(IN)

[burnus at gcc dot gnu.org]

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



 Bug #: 54958

   Summary: Wrongly rejects ac-implied-DO variables which also

occur with INTENT(IN)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bur...@gcc.gnu.org





gfortran rejects all four uses of "i" in the following program with



  Error: Dummy argument 'i' with INTENT(IN) in variable definition context

 (iterator variable) at (1)



However, it should only reject the use as variable in io-implied-do and in the

do-stmt and not the (ac-,data-)implied-do variable. Cf. IR 76 at

ftp://ftp.nag.co.uk/sc22wg5/n1351-n1400/N1393.txt



g95, pathf95 and NAG properly handle this case, gfortran 4.1 to 4.8 doesn't.





subroutine test(i)

  integer, intent(in) :: i

  integer :: A(5)

  ! Valid: data-implied-do  [WRONGLY rejected by gfortran]

  DATA (A(i), i=1,5)/5*42/



  ! Valid: ac-implied-do  [WRONGLY rejected by gfortran]

  print *, [(i, i=1,5 )]



  ! Invalid: io-implied-do  [OK: rejected by gfortran]

  print *, (i, i=1,5 )



  ! Invalid: do-variable in a do-stmt  [OK: rejected by gfortran]

  do i = 1, 5

  end do

end









>From the standard (F2008):



"C539 (R523) A nonpointer object with the INTENT (IN) attribute shall not

appear in a variable definition context (16.6.7)."



and in "16.6.7 Variable definition context":



"(4) a do-variable in a do-stmt or io-implied-do;"





The reason that a data-implied-do and ac-implied-do is allowed is given at

"16.4 Statement and construct entities":



"The name of a data-i-do-variable in a DATA statement or an ac-do-variable in

an array constructor has a scope of its data-implied-do or ac-implied-do. [...]

The appearance of a name as a data-i-do-variable of an implied DO in a DATA

statement or an ac-do-variable in an array constructor is not an implicit

declaration of a variable whose scope is the scoping unit that contains the

statement."

[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)

[sgk at troutmask dot apl.washington.edu]

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



--- Comment #8 from Steve Kargl  
2012-10-17 19:21:22 UTC ---

On Wed, Oct 17, 2012 at 06:51:08PM +, burnus at gcc dot gnu.org wrote:

> 

> > The Standard does not define 'incremented' and

> > 'incrementation', and in particular, these words

> > are not defined in terms of the numeric intrinsic

> > operations and so you cannot appeal to Section 7.

> 

> I disagree. One can surely read something differently, but I think it is very

> difficult to have a reading which makes both sense in terms of the English

> language ("increment" = "the action or process of increasing especially in

> quantity or value : enlargement"; source: Marriam-Webster) and the common

> understanding how programs behave.

> 

> For instance, for

> 

>   do i = 2, 5, 1

> print *, i

>   end do

> 

> The standard has: "The DO variable, if any, is incremented by the value of the

> incrementation parameter m3."

> 

> In my reading of the standard, the program will print 2, 3, 4, 5 and after the

> loop i has the value 6. That matches in my understanding "i = i + 1" where m3

> == 1; thus, I fail to see why Section 7.1.5.2.4 shouldn't apply in this case.

> 

> Can you come up with a (somewhat sensible) different interpretation which 
> still

> allows the program of comment 0?

> 



As I point out in c.l.f, the incrementataion process is

not defined by the standard.  While certainly, one would

assume that this process is i = i + m3 and so Section 7

rules apply.  The incrementation process could be done

in some other manner such as



   integer(8)

   j = int(i,8) + m3

   if (j < int(huge(i),8) + 1) then

  i = j

   else

  i = - huge(i) - 1 + m3 ! Assume wrap around semantics

   end if! Preventing a possible hardware trap



or the incrementation process could be implemented via

bit-wise shift, and, and [x]or.  With bit manipulations

none of the numeric intrinsic operations are used, so

section 7 does not apply.



> (I concur that the invalidity of the program when m2 ==

> huge(integer-do-variable) is a bit surprising at a glance,

> but that doesn't make the program valid. I also concur that

> one could have written the standard differently such that

> the program becomes valid.)



The standard simply should have stated that the incrementation

process follows the rules of 7.1.5.2.4. 



As I said I don't care enough about the PR to 

re-open it.  In any event, gfortran should 

probably issue a warning if m2=huge(i) and

m3 > 0.

[Bug fortran/54940] [4.6/4.7/4.8 Regression] ICE in gfc_build_intrinsic_call, at fortran/expr.c:4609

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||janus at gcc dot gnu.org



--- Comment #2 from janus at gcc dot gnu.org 2012-10-17 19:22:34 UTC ---

(In reply to comment #1)

> The ICE starts with 4.6.3. The ICE occurs at

> 

>   gcc_assert (result->symtree

>   && (result->symtree->n.sym->attr.flavor == FL_PROCEDURE

>   || result->symtree->n.sym->attr.flavor == FL_UNKNOWN));

> 

> introduced by r183314



... which was Tobias' fix for PR 51904. I think the most straightforward thing

would be to just remove the assert again:





Index: gcc/fortran/expr.c

===

--- gcc/fortran/expr.c(revision 192392)

+++ gcc/fortran/expr.c(working copy)

@@ -4606,9 +4606,6 @@ gfc_build_intrinsic_call (const char* name, locus

   result->value.function.isym = isym;



   result->symtree = gfc_find_symtree (gfc_current_ns->sym_root, name);

-  gcc_assert (result->symtree

-  && (result->symtree->n.sym->attr.flavor == FL_PROCEDURE

-  || result->symtree->n.sym->attr.flavor == FL_UNKNOWN));



   va_start (ap, numarg);

   atail = NULL;





In a valid-code context the assert surely makes sense, but here it seems to

choke on the fallout of the two errors.

[Bug plugins/54959] New: current_pass == NULL during invocation of pass->gate within execute_ipa_summary_passes()

[dmalcolm at redhat dot com]

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

 Bug #: 54959
   Summary: current_pass == NULL during invocation of pass->gate
within execute_ipa_summary_passes()
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dmalc...@redhat.com


In my gcc-python-plugin I allow users to create custom passes.

(FWIW see
http://gcc-python-plugin.readthedocs.org/en/latest/passes.html#creating-new-optimization-passes
for what this looks like from the user's perspective).

In particular, I've been supporting a gate() method, mirroring that of the
underlying opt_pass.

I have a single impl_gate() handler that's shared by all such user-created
passes, which I then dispatch to appropriate python code.  Given that the
gate() callback takes no arguments, I've been looking up the relevant opt_pass*
by looking at the "current_pass" global.

This works for GIMPLE_PASS passes, but not for those of kind IPA_PASS.

Specifically, within gcc-4.7.0:gcc/passes.c:
  1875void
  1876execute_ipa_summary_passes (struct ipa_opt_pass_d *ipa_pass)
  1877{
  1878  while (ipa_pass)
  1879{
  1880  struct opt_pass *pass = &ipa_pass->pass;
  1881
  1882  /* Execute all of the IPA_PASSes in the list.  */
  1883  if (ipa_pass->pass.type == IPA_PASS
>>1884&& (!pass->gate || pass->gate ())
  1885  && ipa_pass->generate_summary)
  1886{

at line 1884, pass->gate() is called, but current_pass is NULL, so I don't see
to have a way of figuring out which opt_pass* the gate() callback was called
on.

Is it possible to set current_pass in this loop before calling gate()?

Alternatively, all such callbacks could gain an argument, passing in "pass"
(though that would be an API change).

Hope the above makes sense

[Bug c++/54946] ICE on template parameter from cast char-pointer in C++11 constexpr struct

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #2 from Daniel Krügler  
2012-10-17 19:36:14 UTC ---
The ICE still occurs in gcc 4.8.0 20121014 (experimental) with the message:

"internal compiler error: in convert_nontype_argument, at cp/pt.c:5533"

Let me add that your example is not valid C++11 (irrespective of typo or the
cast), because it doesn't satisfy the valid forms.

"a constant expression (5.19) that designates the address of an object with
static storage duration and external or internal linkage [..], expressed
(ignoring parentheses) as &id-expression [..]"

[Bug middle-end/54957] Two crashes introduced by rev192488

[rmansfield at qnx dot com]

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



--- Comment #10 from Ryan Mansfield  2012-10-17 
19:47:08 UTC ---

Created attachment 28467

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28467

emit_case_dispatch_table testcase



Here's a csmith generated testcase that crashes with -O0 -fexceptions on

sh4-unknown-linux-gnu. It's slightly reduced but I can reduce it further by

hand if necessary.

[Bug plugins/54959] current_pass == NULL during invocation of pass->gate within execute_ipa_summary_passes()

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-10-17 
19:48:07 UTC ---

> I have a single impl_gate() handler that's shared by all such user-created

> passes, which I then dispatch to appropriate python code.



I think this is bad coding.  You should have multiple impl_gate's that then get

dispatched to the appropriate python code.

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #3 from Daniel Krügler  
2012-10-17 19:55:34 UTC ---
I agree that this should be accepted (The grammar of a /simple-declaration/ in
Clause 7 says so).

[Bug plugins/54959] current_pass == NULL during invocation of pass->gate within execute_ipa_summary_passes()

[dmalcolm at redhat dot com]

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



--- Comment #2 from Dave Malcolm  2012-10-17 
20:00:05 UTC ---

The impl_gate is implemented in C, the gate functions in Python.



If I need multiple impl_gate functions, I somehow need to generate machine code

at runtime that curry the relevant arguments.



I guess I could use libffi to do this, perhaps, but it seems ugly and fragile.

[Bug middle-end/54961] New: [4.8 Regression] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440

[dominiq at lps dot ens.fr]

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



 Bug #: 54961

   Summary: [4.8 Regression] FAIL: gfortran.dg/pr48757.f  -O

(internal compiler error) after revision 192440

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: domi...@lps.ens.fr

CC: hjl.to...@gmail.com, ste...@gcc.gnu.org

Target: *86*-*-*





After revision 192440 (192439 is OK), compiling the test gfortran.dg/pr48757.f

on *86*-*-* targets (powerpc*-*-* ones work fine) with '-w -m32 -O2' gives an

ICE:



/opt/gcc/work/gcc/testsuite/gfortran.dg/pr48757.f: In function 'dfconc':

/opt/gcc/work/gcc/testsuite/gfortran.dg/pr48757.f:54:0: internal compiler

error: in compensate_edge, at reg-stack.c:2805

   END



The backtrace is



#9  0x00010059d5ee in rest_of_handle_stack_regs () at

../../p_work/gcc/reg-stack.c:2805

#10 0x000100576aef in execute_one_pass (pass=) at

../../p_work/gcc/passes.c:2320

#11 0x000100576efd in execute_pass_list (pass=) at

../../p_work/gcc/passes.c:2381

#12 0x000100576f0f in execute_pass_list (pass=) at

../../p_work/gcc/passes.c:2382

#13 0x000100576f0f in execute_pass_list (pass=) at

../../p_work/gcc/passes.c:2382

#14 0x000100576f0f in execute_pass_list (pass=) at

../../p_work/gcc/passes.c:2382

#15 0x00010032f182 in expand_function (node=) at

../../p_work/gcc/cgraphunit.c:1601

#16 0x0001003307ba in compile () at ../../p_work/gcc/cgraphunit.c:1705

#17 0x000100330d7f in finalize_compilation_unit () at

../../p_work/gcc/cgraphunit.c:2080

#18 0x00010051c3cd in write_global_declarations () at

../../p_work/gcc/langhooks.c:323

#19 0x000100622891 in compile_file () at ../../p_work/gcc/toplev.c:560

#20 0x0001006242ec in toplev_main (argc=5, argv=0x7fff5fbfd678) at

../../p_work/gcc/toplev.c:1866

#21 0x0001a654 in start (pc=, bases=0x0) at

../../../p_work/libgcc/unwind-dw2-fde.c:1055



Note that there is an additional ICE for gfortran.dg/pr40587.f on

i686-pc-linux-gnu (see

http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg01902.html ), but I don't know

how to reproduce it on x86_64-apple-darwin10.

[Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO

[dmalcolm at redhat dot com]

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



 Bug #: 54962

   Summary: Strange-looking diagnostics from

diagnostic_report_current_module() from warnings

emitted during LTO

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dmalc...@redhat.com





I'm working on a whole-program static analyzer that runs from a gcc plugin

during lto1 when invoked via

  -flto -flto-partition=none

as an IPA_PASS registered before "whole-program".



I'm currently emitting errors using error_at() with inform() to give extra

information on the (possibly interprocedural) execution path taken to reach the

error.  This works, but leads to unusual-looking output.



For example, with:

  $ gcc -flto -flto-partition=none [...various plugin args...] input-f.c

input-g.c input-h.c



my code detects a double-free involving an execution path between input-h.c and

input-g.c and calls

  error_at("double-free of r")

on a location_t from input-h.c and gets this strange output on stderr:



  In file included from test.h:1:0,

   from /usr/include/stdlib.h:489,

   from input-f.c:14,

   from :3:

  input-h.c:13:9: error: double-free of r



it then calls

inform("q passed to free()")

on a location_t from input-g.c (to show the location of the 1st free call) and

gets this on stderr:



  In file included from test.h:1:0,

   from /usr/include/stdlib.h:489,

   from input-f.c:14,

   from :3:

  input-g.c:11:7: note: q passed to free()



In both cases, the "In file included from " hierarchies look bogus: the files

are being directly compiled, not included.



Debugging, it comes from gcc/diagnostic.c:diagnostic_report_current_module()

where I see this code:



  275  if (map && diagnostic_last_module_changed (context, map))

  276{

  277  diagnostic_set_last_module (context, map);

  278  if (! MAIN_FILE_P (map))

  279{

  280  map = INCLUDED_FROM (line_table, map);

  281  if (context->show_column)

  282pp_verbatim (context->printer,

  283 "In file included from %s:%d:%d",

  284 LINEMAP_FILE (map),

  285 LAST_SOURCE_LINE (map), LAST_SOURCE_COLUMN (map));

  286  else

  287pp_verbatim (context->printer,

  288 "In file included from %s:%d",

  289 LINEMAP_FILE (map), LAST_SOURCE_LINE (map));

  290  while (! MAIN_FILE_P (map))

  291{

  292  map = INCLUDED_FROM (line_table, map);



This code appears to assume (via MAIN_FILE_P) that there is a concept of a main

file, and that everything else is included from it.  However in the context of

diagnostics emitted during LTO it's not clear that this concept makes sense (or

maybe I'm missing something?  I also wonder if by attempting to issue

diagnostics from within lto1 if I'm in unexplored territory here?)



This is called by default_tree_diagnostic_starter FWIW; perhaps lto1 needs its

own implementation of this?

[Bug middle-end/54957] Two crashes introduced by rev192488

[eraman at google dot com]

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



--- Comment #11 from Easwaran Raman  2012-10-17 
20:31:21 UTC ---

(In reply to comment #10)

> Created attachment 28467 [details]

> emit_case_dispatch_table testcase

> 

> Here's a csmith generated testcase that crashes with -O0 -fexceptions on

> sh4-unknown-linux-gnu. It's slightly reduced but I can reduce it further by

> hand if necessary.



Does my second patch fix this as well or is it still there?



- Easwaran

[Bug middle-end/54957] Two crashes introduced by rev192488

[rmansfield at qnx dot com]

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



--- Comment #12 from Ryan Mansfield  2012-10-17 
20:38:56 UTC ---

(In reply to comment #11)

> (In reply to comment #10)

> > Created attachment 28467 [details]

> > emit_case_dispatch_table testcase

> > 

> > Here's a csmith generated testcase that crashes with -O0 -fexceptions on

> > sh4-unknown-linux-gnu. It's slightly reduced but I can reduce it further by

> > hand if necessary.

> 

> Does my second patch fix this as well or is it still there?



Sorry for being unclear. Yes, it fixes the crash. I was attaching it in as a

reference.

[Bug lto/54962] Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  2012-10-17 
20:43:51 UTC ---
Where doe the line_maps that LTO use come from? Perhaps they are not
saved/restored correctly?

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[dominiq at lps dot ens.fr]

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



--- Comment #5 from Dominique d'Humieres  2012-10-17 
20:45:37 UTC ---

> ... On darwin12 at least, this still leaves the failures in...

>

> obj-c++.dg/torture/strings/const-str-10.mm

> obj-c++.dg/torture/strings/const-str-11.mm

> obj-c++.dg/torture/strings/const-str-9.mm 

> obj-c++.dg/torture/strings/string1.mm

>

> to be addressed as well as those in objc...

>

> objc.dg/strings/const-cfstring-5.m

> objc.dg/strings/const-str-12b.m 

> objc.dg/torture/strings/const-str-10.m 

> objc.dg/torture/strings/const-str-11.m 

> objc.dg/torture/strings/const-str-9.m 

> objc.dg/torture/strings/string1.m 



I don't see these errors on darwin10. Could you look at the errors in the log

files and try to sort them by categories.

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-17

 Ever Confirmed|0   |1

[Bug target/54950] Incorrect 32-bit moltiplication on m32c target

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



  Component|c   |target

   Severity|critical|normal

[Bug rtl-optimization/54900] write introduction incorrect wrt the C11 memory model (2)

[aldyh at gcc dot gnu.org]

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



--- Comment #3 from Aldy Hernandez  2012-10-17 
20:59:43 UTC ---

Author: aldyh

Date: Wed Oct 17 20:59:40 2012

New Revision: 192548



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

Log:

PR rtl-optimization/54900

* ifcvt.c (noce_can_store_speculate_p): Call

memory_must_be_modified_in_insn_p.

* alias.c (memory_must_be_modified_in_insn_p): New.

(set_dest_equal_p): New.

* rtl.h (memory_must_be_modified_in_p): Protoize.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/alias.c

trunk/gcc/ifcvt.c

trunk/gcc/rtl.h

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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



--- Comment #6 from Jack Howarth  2012-10-17 
21:04:36 UTC ---

These are not failing with Xcode 4.2 on darwin10 but are with Xcode 4.5.1 on

darwin12 as follows...



Executing on host:

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/obj-c++/../../g++

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/obj-c++/../../

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/obj-c++.dg/torture/strings/const-str-10.mm

 -fno-diagnostics-show-caret  -nostdinc++

-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0

-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include

-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/libstdc++-v3/libsupc++

-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/libstdc++-v3/include/backward

-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/libstdc++-v3/testsuite/util

-fmessage-length=0  -O0  -fnext-runtime -mno-constant-cfstrings  -S  -m64 -o

const-str-10.s(timeout = 300)

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/obj-c++.dg/torture/strings/const-str-10.mm:12:22:

error: cannot find interface declaration for 'Object', superclass of

'NSString'^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/obj-c++.dg/torture/strings/const-str-10.mm:31:34:

error: interface 'NSConstantString' does not have valid constant string

layout^M



FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O0  -fnext-runtime (test for

excess errors)



The same error occurs for obj-c++.dg/torture/strings/const-str-11.mm and

obj-c++.dg/torture/strings/const-str-9.mm. 



The obj-c++.dg/torture/strings/string1.mm failure on darwin12 is as follows...



Executing on host:

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/obj-c++/../../g++

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/obj-c++/../../

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/obj-c++.dg/torture/strings/string1.mm

 -fno-diagnostics-show-caret  -nostdinc++

-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include/x86_64-apple-darwin12.2.0

-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include

-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/libstdc++-v3/libsupc++

-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/libstdc++-v3/include/backward

-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/libstdc++-v3/testsuite/util

-fmessage-length=0  -O2 -flto -flto-partition=none  -fnext-runtime

-mno-constant-cfstrings  

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/obj-c++.dg/torture/strings/../../../objc-obj-c++-shared/nsconstantstring-class-impl.mm

 

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/src/.libs



-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/src/.libs



-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/src/.libs



-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/src/.libs



-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libobjc/.libs



-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libobjc/.libs

 -multiply_defined suppress -lobjc -lm   -m32 -o ./string1.exe(timeout =

300)

ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in

/var/tmp//ccoRzvrL.lto.o^M

output is:

ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in

/var/tmp//ccoRzvrL.lto.o^M



FAIL: obj-c++.dg/torture/strings/string1.mm  -O2 -flto -flto-partition=none 

-fnext-runtime (test for excess errors)

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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



--- Comment #7 from Jack Howarth  2012-10-17 
21:17:41 UTC ---

The failure for objc.dg/strings/const-cfstring-5.m on darwin12 is as follows...



Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/strings/const-cfstring-5.m

 -fno-diagnostics-show-caret  -fnext-runtime -mconstant-cfstrings 

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs

 

-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs

 -S  -m64 -o const-cfstring-5.s(timeout = 300)

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/strings/const-cfstring-5.m:11:1:

error: cannot find interface declaration for 'Object', superclass of 'Foo'^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/strings/const-cfstring-5.m:19:1:

error: cannot find interface declaration for 'Object', superclass of 'Bar'^M

...

FAIL: objc.dg/strings/const-cfstring-5.m -fnext-runtime (test for excess

errors)



The failure of objc.dg/strings/const-str-12b.m  is as follows...



Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/strings/const-str-12b.m

 -fno-diagnostics-show-caret  -fnext-runtime -mno-constant-cfstrings

-fconstant-string-class=Foo 

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs

 

-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs

 -S  -m64 -o const-str-12b.s(timeout = 300)

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/strings/const-str-12b.m:11:1:

error: cannot find interface declaration for 'Object', superclass of 'Foo'^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/strings/const-str-12b.m:19:1:

error: cannot find interface declaration for 'Object', superclass of 'Bar'^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/strings/const-str-12b.m:

In function '+[Bar getString:]':^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/strings/const-str-12b.m:26:3:

error: interface 'Foo' does not have valid constant string layout^M

...

FAIL: objc.dg/strings/const-str-12b.m -fnext-runtime (test for excess errors)



The failure in objc.dg/torture/strings/const-str-11.m appears as...



Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/torture/strings/const-str-11.m

 -fno-diagnostics-show-caret   -O0  -fnext-runtime -mno-constant-cfstrings

-fconstant-string-class=XStr 

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs

 

-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs

 -S  -m64 -o const-str-11.s(timeout = 300)

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/torture/strings/const-str-11.m:13:1:

error: cannot find interface declaration for 'Object', superclass of

'XString'^M

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/torture/strings/const-str-11.m:31:1:

error: interface 'XStr' does not have valid constant string layout^M



FAIL: objc.dg/torture/strings/const-str-11.m  -O0  -fnext-runtime (test for

excess errors)



which is the same as in obj-c++. The failures of

objc.dg/torture/strings/const-str-10.m and

objc.dg/torture/strings/const-str-9.m and objc.dg/torture/strings/string1.m are

the same as in obj-c++.

[Bug middle-end/54893] unable to access volatile variable within relaxed transaction

[aldyh at gcc dot gnu.org]

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



--- Comment #5 from Aldy Hernandez  2012-10-17 
21:18:21 UTC ---

Author: aldyh

Date: Wed Oct 17 21:18:16 2012

New Revision: 192549



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

Log:

PR middle-end/54893

* trans-mem.c (diagnose_tm_1_op): Allow volatiles inside relaxed

transactions.



Added:

trunk/gcc/testsuite/c-c++-common/tm/pr54893.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/trans-mem.c

[Bug middle-end/54893] unable to access volatile variable within relaxed transaction

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #6 from Aldy Hernandez  2012-10-17 
21:19:29 UTC ---

fixed on mainline

[Bug web/54711] Fix --target_board examples on test.html page

[sje at gcc dot gnu.org]

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



Steve Ellcey  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #8 from Steve Ellcey  2012-10-17 21:22:04 
UTC ---

This has been resolved now with the patch to install.texi.

[Bug fortran/54949] [F03] abstract procedure pointers not rejected

[janus at gcc dot gnu.org]

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



--- Comment #3 from janus at gcc dot gnu.org 2012-10-17 22:03:29 UTC ---

(In reply to comment #1)

> Preliminary patch:



Unfortunately, this does not help for the variant, where the POINTER

declaration comes before the interface body:



  pointer :: abssub

  abstract interface

subroutine abssub

end subroutine

  end interface





Like the original test case, this results in an ICE.

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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



--- Comment #8 from Jack Howarth  2012-10-17 
23:06:33 UTC ---

(In reply to comment #5)

> 

> I don't see these errors on darwin10. Could you look at the errors in the log

> files and try to sort them by categories.



Only the errors...



FAIL: obj-c++.dg/torture/strings/string1.mm  -O2 -flto -flto-partition=none 

-fnext-runtime (test for excess errors)

FAIL: obj-c++.dg/torture/strings/string1.mm  -O2 -flto  -fnext-runtime (test

for excess errors)



are seen on darwin11 with Xcode 4.5.1 (which potentially could be a linker bug

so I'll open a radar).

The remaining failures are darwin12 only and might represent ABI changes in

10.8 perhaps.

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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



--- Comment #9 from Jack Howarth  2012-10-17 
23:15:28 UTC ---

Note the the string1.m/string1.mm failures are from warnings and the resulting

binaries run fine.

[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[pthaugen at gcc dot gnu.org]

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



--- Comment #5 from Pat Haugen  2012-10-17 
23:38:16 UTC ---

I'm seeing the same thing on cpu2006 benchmark 44.namd on PowerPC64. A load is

being moved above a store to the same location, starting with revision 191493.



Reduced testcase and compile command:



[pthaugen@igoo pr54850]$ cat junk.C

// g++ -S -m64 -O2 -mcpu=power7 junk.C



class Vector {

   public:

 double x,y,z;



 //  v1 += v2;

 inline void operator+=(const Vector &v2) {

   x += v2.x;

   y += v2.y;

   z += v2.z;

 }

};





Vector* foo(Vector *p, Vector *shift, Vector *p1, int n) {

  int i;



  for(i = 0; i < n; i++) {

p[i] = p1[i];

p[i] += *shift;

  }

  return p;

}



[pthaugen@igoo pr54850]$ /home/pthaugen/install/gcc/temp/bin/g++ -S -m64 -O2

-mcpu=power7 junk.C





The sched1 dump correctly lists forward dependencies of the initial store(s) to

p1[i] to the subsequent loads of p1[i], but those dependencies are gone in the

.sched2 pass.



>From .sched1  (stores are insn 75,77,79, and dependent loads are insn

80,84,88):



;;   ==

;;   -- basic block 4 from 74 to 96 -- before reload

;;   ==



;;   --- forward dependences: 



;;   --- Region Dependences --- b 4 bb 0

;;  insn  codebb   dep  prio  cost   reservation

;;    --   ---       ---

;;   74   379 4 047 2   DU_power7,LSU_power7: 96 92

91n 87n 83n 79n 77n 75nm

;;   76   379 4 045 2   DU_power7,LSU_power7: 96 92

91n 87n 83n 79n 77nm 75n

;;   78   379 4 045 2   DU_power7,LSU_power7: 96 92

91n 87n 83n 79nm 77n 75n

;;   75   379 4 345 6   DU_power7,(LSU_power7+FXU_power7)  

: 96m 93 89n 85n 83n 81n 80n

;;   77   379 4 331 6   DU_power7,(LSU_power7+FXU_power7)  

: 96m 93 89n 87n 85n 84n

;;   79   379 4 317 6   DU_power7,(LSU_power7+FXU_power7)  

: 96m 93 91n 89n 88n

;;   80   366 4 139 2   DU_power7,LSU_power7: 96 93

83n 82

;;   81   366 4 139 2   DU_power7,LSU_power7: 96

91n 87n 83n 82

;;   82   740 4 237 6   DU_power7,VSU_power7: 96 83

;;   83   366 4 731 6   DU_power7,(LSU_power7+FXU_power7)  

: 96m 93 89n 85n

;;   84   366 4 125 2   DU_power7,LSU_power7: 96 93

87n 86

;;   85   366 4 325 2   DU_power7,LSU_power7: 96

91n 87n 86

;;   86   740 4 223 6   DU_power7,VSU_power7: 96 87

;;   87   366 4 817 6   DU_power7,(LSU_power7+FXU_power7)  

: 96m 93 89n

;;   88   366 4 111 2   DU_power7,LSU_power7: 96 93

91n 90







>From .sched2 pass:



;;   ==

;;   -- basic block 4 from 74 to 96 -- after reload

;;   ==



;;   --- forward dependences: 



;;   --- Region Dependences --- b 4 bb 0

;;  insn  codebb   dep  prio  cost   reservation

;;    --   ---       ---

;;   74   379 4 050 2   DU_power7,LSU_power7: 96

91n 87n 83n 92 79n 77n 75nm

;;   76   379 4 048 2   DU_power7,LSU_power7: 96

91n 87n 83n 92 79n 77nm 75n

;;   78   379 4 048 2   DU_power7,LSU_power7: 96

91n 87n 83n 92 79nm 77n 75n

;;   75   379 4 348 6   DU_power7,(LSU_power7+FXU_power7)  

: 96m 89n 85n 81n 93

;;   77   379 4 343 6   DU_power7,(LSU_power7+FXU_power7)  

: 96m 89n 85n 93

;;   79   379 4 343 6   DU_power7,(LSU_power7+FXU_power7)  

: 96m 89n 93

;;   9280 4 3 7 1   DU_power7,FXU_power7: 96 95

;;   95   545 4 1 6 1   DU_power7,FXU_power7: 96m

;;   9380 4 343 1   DU_power7,FXU_power7: 96 91

87 83 88 84 80

;;   81   366 4 142 3   DU_power7,LSU_power7: 96

91n 87n 83n 82m

;;   80   366 4 142 3   DU_power7,LSU_power7: 96

83n 88 82

;;   84   366 4 127 3   DU_power7,LSU_power7: 96

87n 86

;;   82   740 4 239 6   DU_power7,VSU_power7: 96 85

83 88

;;   88   366 4 312 3   DU_power7,LSU_power7: 96

91n 90

[Bug middle-end/54963] New: Wrong code generated for libgfortran/generated/eoshift3_8.c on SH

[kkojima at gcc dot gnu.org]

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



 Bug #: 54963

   Summary: Wrong code generated for

libgfortran/generated/eoshift3_8.c on SH

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: wrong-code

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: kkoj...@gcc.gnu.org

Target: sh*-*-*





Created attachment 28469

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28469

A test case



Several fortran tests using some eoshift functions fail on

sh4-unknown-linux-gnu for a while.  The above test case is

a reduced one which fails sh-elf with -O2 -ml -m4.  The right

result would be "adhbeh..." but it wrongly returns "ticzzz...".

It seems that the compiler allocates a stack slot at r15+60

for "len" variable first for the line 126:



   len = ((array)->dim[dim]._ubound + 1 - (array)->dim[dim].lower_bound);



then computes len - abs (sh) for the line 184;



   for (n = 0; n < len - delta; n++)



using "len" variable at r15+68.  The error went away with

-fno-ira-share-spill-slots.

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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



--- Comment #10 from Jack Howarth  2012-10-17 
23:58:36 UTC ---

(In reply to comment #9)

> Note the the string1.m/string1.mm failures are from warnings and the resulting

> binaries run fine.



These linker warnings are http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094. I

also see these failures under darwin10 with Xcode 4.2's linker. This linker

warning doesn't occur with the linker from Xcode 3.2.6 under darwin10.

[Bug driver/54964] New: -MMD is silently ignored with -x assembler (or inferred language from .s extension)

[ami at fischman dot org]

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

 Bug #: 54964
   Summary: -MMD is silently ignored with -x assembler (or
inferred language from .s extension)
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@fischman.org


When gcc is asked to compile a .s into a .o, or when told to compile a language
"assembler" file, it ignores the request for a dependency file.  -x
assembler-with-cpp emits the requested dependency file.  

It would be nice if gcc never ignored the -MMD flag.

Repro: note the first two commands fail to create empty.o.d, whereas the last
command does not fail:

$ rm -f empty.o* ; touch empty.s ; gcc -MMD -MF empty.o.d -c empty.s -o empty.o
; ls -al empty.o*
-rw-r--r-- 1 fischman eng 657 Oct 17 17:04 empty.o
$ rm -f empty.o* ; gcc -MMD -MF empty.o.d -x assembler /dev/null -c -o empty.o
; ls -al empty.o*
-rw-r--r-- 1 fischman eng 657 Oct 17 16:56 empty.o
$ rm -f empty.o* ; gcc -MMD -MF empty.o.d -x assembler-with-cpp /dev/null -c -o
empty.o ; ls -al empty.o*
-rw-r--r-- 1 fischman eng 657 Oct 17 16:56 empty.o
-rw-r--r-- 1 fischman eng  19 Oct 17 16:56 empty.o.d

[Bug driver/54964] -MMD is silently ignored with -x assembler (or inferred language from .s extension)

[ami at fischman dot org]

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



--- Comment #2 from Ami Fischman  2012-10-18 00:14:30 
UTC ---

It would still be nice to not act differently for .s files than for

.{S,cc,cpp,c} files...

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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



--- Comment #11 from Jack Howarth  2012-10-18 
00:15:58 UTC ---

The darwin12 specific non-linker failures are suppressed if...



-isysroot `xcode-select

--print-path`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk



is added to the compilation flags indicating that this is an ABI change.

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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



--- Comment #12 from Jack Howarth  2012-10-18 
00:23:55 UTC ---

Created attachment 28470

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28470

preprocessed source for const-str-10.m against 10.7 SDK



/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/

/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/torture/strings/const-str-10.m

-fno-diagnostics-show-caret -O0 -fnext-runtime -mno-constant-cfstrings

-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs

-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs

-S -m64 -isysroot `xcode-select

--print-path`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -o

const-str-10.s --save-temps

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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

--- Comment #13 from Jack Howarth  2012-10-18 
00:25:15 UTC ---
Created attachment 28471
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28471
preprocessed source for const-str-10.m against 10.8 SDK

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/torture/strings/const-str-10.m
-fno-diagnostics-show-caret -O0 -fnext-runtime -mno-constant-cfstrings
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libobjc/.libs
-S -m64 -o const-str-10.s --save-temps
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/torture/strings/const-str-10.m:13:1:
error: cannot find interface declaration for ‘Object’, superclass of ‘NSString’
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121017/gcc/testsuite/objc.dg/torture/strings/const-str-10.m:31:1:
error: interface ‘NSConstantString’ does not have valid constant string layout

[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186978

[howarth at nitro dot med.uc.edu]

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



--- Comment #14 from Jack Howarth  2012-10-18 
00:29:40 UTC ---

Created attachment 28472

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28472

diff of preprocessed sources for const-str-10.m against 10.7 and 10.8 SDK

[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[pthaugen at gcc dot gnu.org]

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



--- Comment #6 from Pat Haugen  2012-10-18 
01:44:35 UTC ---

> The sched1 dump correctly lists forward dependencies of the initial store(s) 
> to

> p1[i] to the subsequent loads of p1[i], but those dependencies are gone in the

> .sched2 pass.

> 



Sorry, I obviously meant stores/loads of p[i].

[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[pthaugen at gcc dot gnu.org]

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



--- Comment #7 from Pat Haugen  2012-10-18 
01:50:00 UTC ---

Created attachment 28473

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28473

sched1 dump

[Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining

[siarhei.siamashka at gmail dot com]

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

 Bug #: 54965
   Summary: [4.6] sorry, unimplemented: inlining failed in call to
'foo': function not considered for inlining
Classification: Unclassified
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siarhei.siamas...@gmail.com


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

GCC 4.6 fails when compiling current git versions of pixman:
https://bugs.freedesktop.org/show_bug.cgi?id=55630

Bisecting shows that this problem started occurring in 4.6 branch after the
following commit:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3d5f815b529fe4b8b79d4f2a04e6eb670faee04d

3d5f815b529fe4b8b79d4f2a04e6eb670faee04d is the first bad commit
commit 3d5f815b529fe4b8b79d4f2a04e6eb670faee04d
Author: hubicka 
Date:   Thu Nov 11 22:08:26 2010 +

PR tree-optimize/40436
* gcc.dg/tree-ssa/inline-5.c: New testcase.
* gcc.dg/tree-ssa/inline-6.c: New testcase.

* ipa-inline.c (likely_eliminated_by_inlining_p): Rename to ...
(eliminated_by_inlining_prob): ... this one; return 50% probability for
SRA.
(estimate_function_body_sizes): Update use of
eliminated_by_inlining_prob;
estimate static function size for 2 instructions.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@166624
138bc75d-0d04-0410-961f-82ee72b054a4


The problem disappears in 4.7 branch after:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=526b36a8a249c8c8698ca48ffeb8bff552f5a6fd

526b36a8a249c8c8698ca48ffeb8bff552f5a6fd is the first bad commit
commit 526b36a8a249c8c8698ca48ffeb8bff552f5a6fd
Author: rguenth 
Date:   Fri Mar 25 11:59:19 2011 +

2011-03-25  Richard Guenther  

* passes.c (init_optimization_passes): Add FRE pass after
early SRA.

* g++.dg/tree-ssa/pr41186.C: Scan the appropriate FRE dump.
* g++.dg/tree-ssa/pr8781.C: Likewise.
* gcc.dg/ipa/ipa-pta-13.c: Likewise.
* gcc.dg/ipa/ipa-pta-3.c: Likewise.
* gcc.dg/ipa/ipa-pta-4.c: Likewise.
* gcc.dg/tree-ssa/20041122-1.c: Likewise.
* gcc.dg/tree-ssa/alias-18.c: Likewise.
* gcc.dg/tree-ssa/foldstring-1.c: Likewise.
* gcc.dg/tree-ssa/forwprop-10.c: Likewise.
* gcc.dg/tree-ssa/forwprop-9.c: Likewise.
* gcc.dg/tree-ssa/fre-vce-1.c: Likewise.
* gcc.dg/tree-ssa/loadpre6.c: Likewise.
* gcc.dg/tree-ssa/pr21574.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-cse-1.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-1.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-12.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-13.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-14.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-15.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-17.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-18.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-19.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-21.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-22.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-23.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-24.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-25.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-26.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-27.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-4.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-5.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-6.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-8.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-9.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-10.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-26.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-8.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-9.c: Likewise.
* gcc.dg/tree-ssa/ssa-sccvn-1.c: Likewise.
* gcc.dg/tree-ssa/ssa-sccvn-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-sccvn-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-sccvn-4.c: Likewise.
* gcc.dg/tree-ssa/struct-aliasing-1.c: Likewise.
* gcc.dg/tree-ssa/struct-aliasing-2.c: Likewise.
* c-c++-common/pr46562-2.c: Likewise.
* gfortran.dg/pr42108.f90: Likewise.
* gcc.dg/torture/pta-structcopy-1.c: Scan ealias dump, force
foo to be inlined even at -O1.
* gcc.dg/tree-ssa/ssa-dce-4.c: Disable FRE.
* gcc.dg/ipa/ipa-pta-14.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-1.c: Adjust.
* gcc.dg/matrix/matrix.exp: Disable FRE.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@171450
138bc75d-0

[Bug target/54950] Incorrect 32-bit moltiplication on m32c target

[dj at gcc dot gnu.org]

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



--- Comment #1 from dj at gcc dot gnu.org  2012-10-18 
01:50:35 UTC ---

Author: dj

Date: Thu Oct 18 01:50:24 2012

New Revision: 192553



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

Log:

PR target/54950

* config/m32c/predicates.md (m32c_const_u16_operand): New.

* config/m32c/muldiv.md: Use it.



Modified:

branches/gcc-4_6-branch/gcc/ChangeLog

branches/gcc-4_6-branch/gcc/config/m32c/muldiv.md

branches/gcc-4_6-branch/gcc/config/m32c/predicates.md

[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[pthaugen at gcc dot gnu.org]

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



--- Comment #8 from Pat Haugen  2012-10-18 
01:51:03 UTC ---

Created attachment 28475

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28475

sched2 dump

[Bug tree-optimization/54965] [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining

[siarhei.siamashka at gmail dot com]

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



--- Comment #1 from Siarhei Siamashka  
2012-10-18 01:56:34 UTC ---

Created attachment 28476

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28476

pixman-combine-float.i.gz - the original full preprocessed source



Applying the changes from

http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=526b36a8a249c8c8698ca48ffeb8bff552f5a6fd

to 'passes.c' in GCC 4.6 branch "fixes" the reduced testcase. But pixman still

can't be compiled successfully, so also attaching the original full

preprocessed source.

[Bug target/54951] Incorrect pointer handling on 32K boundary

[dj at redhat dot com]

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



DJ Delorie  changed:



   What|Removed |Added



 CC||dj at redhat dot com



--- Comment #1 from DJ Delorie  2012-10-18 02:14:48 UTC 
---

This is, unfortunately, the expected behavior for m32c.  The m32c has 20-bit

pointers but 16-bit math operations, so size_t is 16 bits resulting in many

pointer math operations being truncated to 16 bits.  So, a COUNT of 0x may

be interpreted as -1 instead of 65536, etc.

[Bug target/54952] Program crash on M32C when stack frame is more then 128 bytes

[dj at redhat dot com]

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



DJ Delorie  changed:



   What|Removed |Added



 CC||dj at redhat dot com



--- Comment #1 from DJ Delorie  2012-10-18 06:03:14 UTC 
---

FYI this looks like an assembler bug, not a gcc bug...  The "add.l #128,sp"

opcode is being assembled as "add.l #-128,sp" instead.