[Bug c/55892] Bogus compiler warning

[sworddragon2 at aol dot com]

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



sworddragon2 at aol dot com changed:



   What|Removed |Added



 Status|RESOLVED|UNCONFIRMED

 Resolution|INVALID |



--- Comment #2 from sworddragon2 at aol dot com 2013-01-07 08:01:36 UTC ---

> Take a line which is 16 characters long.

> The first time at beginning of the loop, limit: 8; readlimit: 8.

>

> The next time, limit:0 readlimit: 0.

> The next time limit: (unsigned long)(-8) readlimit: INT32_MAX

> Warn because readlimit > 1024.



You are right, limit -= read_limit; makes anyway no sense there so I removed it

(and the compiler wanring is gone too).



But there is still something strange on the old example: Why does line 33

trigger the warning but line 34 not? The only difference between them is that

line 33 uses a stack variable and line 34 a heap variable. Both have the same

size so shouldn't this warning trigger on both lines?

[Bug c++/52343] [C++11] alias-definition dont work in `template` params type

[dodji at gcc dot gnu.org]

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



--- Comment #5 from Dodji Seketeli  2013-01-07 
08:03:39 UTC ---

Author: dodji

Date: Mon Jan  7 08:03:33 2013

New Revision: 194960



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

Log:

PR c++/52343 - error with alias template as template template argument



In the example accompanying this patch, check_instantiated_arg tries

to ensure that a non-type template argument should be a constant if it

has integral or enumeration type.



The problem is that an alias template which type-id is, e.g, an

integer, looks like an argument that has integral/enumeration type:

its TREE_TYPE is an integer type.  So check_instantiated_arg

mistenkaly barks that this integral non-type argument is not a

constant.



Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.



gcc/cp/



PR c++/52343

* pt.c (check_instantiated_arg): Allow type template arguments.



gcc/testsuite/



PR c++/52343

* g++.dg/cpp0x/alias-decl-29.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-29.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/pt.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/55311] Cannot specialize template parameter of type 'const char *const' in 'using' alias

[dodji at gcc dot gnu.org]

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

--- Comment #4 from Dodji Seketeli  2013-01-07 
08:06:52 UTC ---
Author: dodji
Date: Mon Jan  7 08:06:46 2013
New Revision: 194961

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194961
Log:
PR c++/55311 - Cannot specialize alias template with arg of type array of char

Consider this test case:

 1template 
 2struct A
 3{};
 4
 5struct B {};
 6
 7extern constexpr char HELLO_WORLD[] = "hello world";
 8
 9A g; // <-- This works fine
10
11template 
12using PartiallySpecialized = A;  // <-- This fails
13

At line 12 G++ fails to instantiate the alias template that has a
string variable initialized with a string literal, with the error
message:

test.cc:12:46: error: ‘"hello world"’ is not a valid template argument of
type ‘const char*’ because ‘"hello world"’ is not a variable
 using PartiallySpecialized = A;  // <-- This fails
  ^

Note that instantiating the template A at line 9 with the same
arguments as in the problematic case above works.

This happens in the context of lookup_template_class_1, when it handles
the alias template instantiation A and thus passes the
VAR_DECL for HELLO_WORLD to convert_nontype_argument.

Note that from there decay_conversion replaces the the VAR_DECL with
its STRING_CST initializer[1].  Latter on, convert_nontype_argument
checks that the HELLO_WORLD constant it received as argument was
indeed a VAR_DECL:

  else
{
  tree decl;

  decl = ((TREE_CODE (expr) == ADDR_EXPR)
  ? TREE_OPERAND (expr, 0) : expr);
  if (TREE_CODE (decl) != VAR_DECL)
{
  error ("%qE is not a valid template argument of type %qT "
 "because %qE is not a variable",
 expr, type, decl);
  return NULL_TREE;
}

But the issue is, that VAR_DECL has been replaced by STRING_CST, so
the last 'if' above fails.

The fix is to teach decay_conversion to return the address of array,
rather than returning its initializer.

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

gcc/cp/

PR c++/55311
* pt.c (decay_conversion): Do not return the initializer of an array.

gcc/testsuite/

PR c++/55311
* g++.dg/cpp0x/alias-decl-30.C: New test.
* g++.dg/init/array21.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-30.C
Modified:
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.dg/init/array21.C

[Bug fortran/55763] Issues with some simpler CLASS(*) programs

[burnus at gcc dot gnu.org]

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



--- Comment #22 from Tobias Burnus  2013-01-07 
08:36:24 UTC ---

Author: burnus

Date: Mon Jan  7 08:36:16 2013

New Revision: 194962



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

Log:

2012-01-07  Tobias Burnus  



PR fortran/55763

* resolve.c (resolve_select_type): Reject intrinsic types for

a non-unlimited-polymorphic selector.



2012-01-07  Tobias Burnus  



PR fortran/55763

* gfortran.dg/select_type_32.f90: New.





Added:

trunk/gcc/testsuite/gfortran.dg/select_type_32.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/resolve.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/54992] [4.8 Regression] [OOP] Wrong offset in the array offset calculation when using nonclass%class(index)%nonclass

[pault at gcc dot gnu.org]

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



Paul Thomas  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Paul Thomas  2013-01-07 09:05:10 
UTC ---

Fixed by http://gcc.gnu.org/viewcvs?view=revision&revision=194953



It did not register here because I screwed up on the ChangeLog Format (I really

am rusty  :-) ).  I'll fix this tonight.



Thanks for the report.



Paul

[Bug fortran/54990] [4.8 Regression] [OOP] ICE in tree_operand_check on SELECT TYPE

[pault at gcc dot gnu.org]

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



Paul Thomas  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #2 from Paul Thomas  2013-01-07 09:06:26 
UTC ---

Fixed by http://gcc.gnu.org/viewcvs?view=revision&revision=194953



It did not register here because I screwed up on the ChangeLog Format (I really

am rusty  :-) ).  I'll fix this tonight.



Thanks for the report.



Paul

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[pault at gcc dot gnu.org]

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



Paul Thomas  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Paul Thomas  2013-01-07 09:07:24 
UTC ---

Fixed by http://gcc.gnu.org/viewcvs?view=revision&revision=194953



It did not register here because I screwed up on the ChangeLog Format (I really

am rusty  :-) ).  I'll fix this tonight.



Thanks for the report.



Paul

[Bug fortran/55891] Problem with shared library and EQUIVALENCE on darwin 11.4.2 x86_64

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org,

   ||dominiq at lps dot ens.fr



--- Comment #1 from Tobias Burnus  2013-01-07 
09:39:33 UTC ---

For what it is worth: It works with GCC 4.8 on x86-64-gnu-linux.

[Bug c++/55893] [4.7/4.8 Regression][C++11] runtime segfault with static const object with virtual destructor

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P2

  Known to work||4.6.3

   Target Milestone|--- |4.7.3

Summary|C++11: runtime segfault |[4.7/4.8 Regression][C++11]

   |with static const object|runtime segfault with

   |with virtual destructor |static const object with

   ||virtual destructor

  Known to fail||4.7.0



--- Comment #3 from Richard Biener  2013-01-07 
09:45:21 UTC ---

Works with 4.6.

[Bug tree-optimization/55890] [4.7/4.8 Regression] calling a builtin func through a cast triggers an ICE

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Keywords||ice-on-invalid-code

   Last reconfirmed||2013-01-07

  Component|c   |tree-optimization

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

   |gnu.org |

 Ever Confirmed|0   |1

Summary|calling a builtin func  |[4.7/4.8 Regression]

   |through a cast triggers an  |calling a builtin func

   |ICE |through a cast triggers an

   ||ICE

   Target Milestone|--- |4.7.3



--- Comment #1 from Richard Biener  2013-01-07 
09:53:24 UTC ---

Confirmed.  Of course the testcase is somewhat "invalid".  Since GCC 4.7

we preserve the original function type that is in effect for performing the

call but we are able to still propagate the actual function decl to the

call stmt.  Code inspecting arguments based on the fact the called function

is a builtin decl needs additional verification now ...



Mine.

[Bug tree-optimization/55890] [4.7/4.8 Regression] calling a builtin func through a cast triggers an ICE

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2013-01-07 
10:03:30 UTC ---

Created attachment 29094

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

prototype patch



For example fixed with something like the following.



Of course it's always going to produce some GIGO in builtins analyzing code

this way.  So the other fix would be to verify that for a builtin call

the number of actual arguments matches the ones required for the builtin

(though types also can differ ...).



Quite some amount of code to audit against these things - I suppose we might

decide to simply deal with this during next stage1 ...

[Bug tree-optimization/55888] [4.8 regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:867

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #3 from Richard Biener  2013-01-07 
10:04:59 UTC ---

Hmpf.  Mine.

[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug tree-optimization/55883] with -fwrapv, (x < 0 && -x < 0) is assumed to be false

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Richard Biener  2013-01-07 
10:06:31 UTC ---

Yeah, looks like a dup.



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

[Bug tree-optimization/55236] gcc.c-torture/execute/pr22493-1.c FAILs with -fPIC

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||xi.wang at gmail dot com



--- Comment #4 from Richard Biener  2013-01-07 
10:06:31 UTC ---

*** Bug 55883 has been marked as a duplicate of this bug. ***

[Bug c++/55881] #pragma GCC diagnostic ignored ignored when inlining

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||diagnostic

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-07

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-01-07 
10:08:32 UTC ---

This is because uninitialized var usage is warned during optimization and

inlining has no way of handling the diagnostic pragma (I even doubt it works

very well during optimization - it's at most function granular there).



Well - confirmed.  Unlikely to be fixed.

[Bug c/55882] unaligned load/store : incorrect struct offset

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-01-07

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-01-07 
10:09:58 UTC ---

Without a complete testcase it's impossible to tell what is going on.  If you

really cannot produce one you may be able to help by bisecting to a revision

that broke your test.

[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO

[rguenth at gcc dot gnu.org]

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



--- Comment #7 from Richard Biener  2013-01-07 
10:12:53 UTC ---

It's a global, why should it get collected?

[Bug c++/55878] [4.7/4.8 Regression] --enable-checking=yes rejection of typeid

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.7.3

[Bug ada/864] --program-suffix is ignored (for ada)

[rguenth at gcc dot gnu.org]

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



--- Comment #24 from Richard Biener  2013-01-07 
10:14:54 UTC ---

Author: rguenth

Date: Mon Jan  7 10:14:48 2013

New Revision: 194964



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

Log:

2013-01-04  Richard Biener  



PR ada/864

* gcc-interface/Make-lang.in (ada.install-common): Always apply

program_transform_name.



Modified:

trunk/gcc/ada/ChangeLog

trunk/gcc/ada/gcc-interface/Make-lang.in

[Bug ada/864] --program-suffix is ignored (for ada)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #25 from Richard Biener  2013-01-07 
10:17:09 UTC ---

Fixed for 4.8.

[Bug c++/53900] [regression] Too optimistic on a alignment assert

[chtz at informatik dot uni-bremen.de]

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



--- Comment #7 from Christoph Hertzberg  
2013-01-07 10:19:13 UTC ---

(In reply to comment #6)

> >  __attribute__((aligned(16))) float array[4];

> 

> Explicitly says the array is aligned to 16 bytes which means it is undefined 
> by

> the C/C++ standard what happens if you a pointer to the struct which contains

> this array.  As this pointer will always be aligned by definition of the 
> struct

> (and any other use of it is undefined), then by definition

> std::ptrdiff_t(array) will always have the lower 8bits be zero.



So does that mean that new and std::allocator act undefined for aligned

objects?

Is there anything wrong with Gael's second test case?

[Bug target/55876] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:776

[vries at gcc dot gnu.org]

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



--- Comment #4 from vries at gcc dot gnu.org 2013-01-07 10:20:52 UTC ---

> Another way to go about it is to prevent the assert from triggering:



Tested and submitted fix:

http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00288.html

[Bug c++/53900] [regression] Too optimistic on a alignment assert

[pinskia at gcc dot gnu.org]

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



--- Comment #8 from Andrew Pinski  2013-01-07 
10:21:44 UTC ---

(In reply to comment #7)

> (In reply to comment #6)

> > >  __attribute__((aligned(16))) float array[4];

> > 

> > Explicitly says the array is aligned to 16 bytes which means it is 
> > undefined by

> > the C/C++ standard what happens if you a pointer to the struct which 
> > contains

> > this array.  As this pointer will always be aligned by definition of the 
> > struct

> > (and any other use of it is undefined), then by definition

> > std::ptrdiff_t(array) will always have the lower 8bits be zero.

> 

> So does that mean that new and std::allocator act undefined for aligned

> objects?

> Is there anything wrong with Gael's second test case?



It is rather a bug in libstdc++ which should be reported separately though it

needs an ABI change to work correctly.

[Bug libstdc++/55872] Crash issue with RTLD_DEEPBIND usage with stdc++ library

[gauryogesh.nsit at gmail dot com]

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



--- Comment #4 from Yogesh Gaur  2013-01-07 
10:31:19 UTC ---

Hello,



Actually issue is combination of copy_relocation plus RTLD_DEEPBIND flag.



If I didn't give -fPIE flag while compiling my executable and pass

RTLD_DEEPBIND flag while opening library using dlopen(), then result is

un-expected.



I checked similar issue exist on gcc also:

--Source Code -

$ cat main.c

#include 

extern int alpha;

int main()

{

char const * const name = "./lib1.so";

void * handle = dlopen(name, RTLD_NOW | RTLD_LOCAL | RTLD_DEEPBIND);

typedef void (*library_function_type)();

library_function_type func1 = dlsym(handle, "func1");



alpha = 10;

(*func1)();

func2();



dlclose(handle);

return 0;

}



$ cat lib1.c

#include 

extern int alpha;

void func1(){

printf("lib1: Addr=%p, value=%d\n", &alpha, alpha);

}



$ cat lib2.c

#include 

int alpha;

void func2(){

printf("lib2: Addr=%p, value=%d\n", &alpha, alpha);

}

 END --



Compilation command and output:



gcc -shared -fPIC lib2.c -o lib2.so

gcc -shared -fPIC lib1.c lib2.so -o lib1.so

gcc -ldl main.c lib2.so -o a.out

LD_LIBRARY_PATH=$PWD ./a.out 

 lib1: Addr=0x7f5a39663028, value=0

 lib2: Addr=0x601038, value=10

=



Thus for same symbol, alpha, we get two addresses values.



If I remove RTLD_DEEPBIND while opening library, I didn't get this issue:

  lib1: Addr=0x601038, value=10

  lib2: Addr=0x601038, value=10



Reason for this also I know that in case of RTLD_DEEPBIND scope of search for

lib1.so is its internal library first and then only global library's being

searched.



I want to know that apart from usage of -fPIE flag at compilation time did

any-other solution exist for this issue? As using -fPIE has it's own

side-affect.



--

Regards,

Yogesh Gaur.

[Bug c++/52343] [C++11] alias-definition dont work in `template` params type

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Dodji Seketeli  2013-01-07 
10:44:14 UTC ---

This should be fixed in trunk (4.8)

[Bug tree-optimization/55888] [4.8 regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:867

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-01-07 
10:45:37 UTC ---

(gdb) call debug_bitmap_set (set)

debug[0] := { message_7(D) (0007), rv_26 (0024), _30 (0034), {plus_expr,i_62,1}

(0021), vntemp_50 (0044), {convert_expr,vntemp_50} (0069) }



but value_expressions[44] only contains len_31.



So the question is where we added vntemp_50 (well, the bisect shows us where).

This is a VN value-number created for an expression that might need to be

inserted somewhere ((const size_t) _41).  We fail to add that to its value.

Alternatively we fail to do the valueization "properly" when translating

an SSA_NAME.



In fact as original the valueization after PHI-translating SSA names looks

superfluous.  The fix for PR55862 probably simply made us prune sth from

the antic set which resolved the oscillation.



Back to the drawing-board for PR55862 ...

[Bug c++/55311] Cannot specialize template parameter of type 'const char *const' in 'using' alias

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Dodji Seketeli  2013-01-07 
11:00:32 UTC ---

This should be fixed in trunk (4.8).

[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647

[burnus at gcc dot gnu.org]

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



--- Comment #7 from Tobias Burnus  2013-01-07 
11:11:01 UTC ---

Author: burnus

Date: Mon Jan  7 11:10:53 2013

New Revision: 194966



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

Log:

2013-01-07  Tobias Burnus  

Thomas Koenig  



PR fortran/55852

* expr.c (gfc_build_intrinsic_call): Avoid clashes

with user's procedures.

* gfortran.h (gfc_build_intrinsic_call): Update prototype.

* simplify.c (gfc_simplify_size): Update call.

* class.c (finalization_scalarizer, finalization_get_offset,

finalizer_insert_packed_call, generate_finalization_wrapper):

Clean up by using gfc_build_intrinsic_call.



2013-01-07  Tobias Burnus  



PR fortran/55852

* gfortran.dg/intrinsic_size_3.f90: New.





Added:

trunk/gcc/testsuite/gfortran.dg/intrinsic_size_3.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/class.c

trunk/gcc/fortran/expr.c

trunk/gcc/fortran/gfortran.h

trunk/gcc/fortran/simplify.c

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/55890] [4.7/4.8 Regression] calling a builtin func through a cast triggers an ICE

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-01-07 
11:21:44 UTC ---

Other testcase:



extern void *memmove();

main() { memmove(); }



also fails with GCC 4.6, 4.5 but not 4.4 or older.

[Bug fortran/55891] Problem with shared library and EQUIVALENCE on darwin 11.4.2 x86_64

[dominiq at lps dot ens.fr]

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



--- Comment #2 from Dominique d'Humieres  2013-01-07 
11:49:53 UTC ---

I see this behavior with gcc 4.8 on x86_64-apple-darwin10. It happens even if

the -fPIC options are removed (isn't it the default on darwin?). I recover the

expected behavior if I add -c when compiling mod.f90, but I cannot say more

since I don't understand what is intended.

[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0

[george.thomas at atmel dot com]

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



--- Comment #5 from George Thomas  2013-01-07 
12:04:22 UTC ---

Created attachment 29095

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

Draft Patch for the fix of 54218



The issue is happening because stack space is allocated twice



1. assign_params_setup_stack and

2. expand_used_vars



The proposed fix is to allocate the space only once in assign_params_stack

by explicitly checking in expand_used_vars if the tree node is of type

PARM_DECL.



if its PARM_DECL, it would mean that it would already have been expanded and

hence do not require further expansion.



This fixes the issue and allows debugging to work properly.



I would like to know if it would be an acceptable change.

[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0

[george.thomas at atmel dot com]

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



George Thomas  changed:



   What|Removed |Added



 CC||george.thomas at atmel dot

   ||com



--- Comment #6 from George Thomas  2013-01-07 
12:06:01 UTC ---

Another alternative thought of for the fix was to,



Make the Parameters to be the default def of the next use. In this case,

the condition mentioned above will not expand the variable.



if (!bitmap_bit_p (SA.partition_has_default_def, i))

  {

expand_one_var (var, true, true);

gcc_assert (SA.partition_to_pseudo[i]);

  }

[Bug tree-optimization/55890] [4.7/4.8 Regression] calling a builtin func through a cast triggers an ICE

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-01-07 
12:07:14 UTC ---

Created attachment 29096

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

alternative patch



This verifies call arguments in gimple_call_builtin_p and adds a new overload

suitable for replacing



  if ((fndecl = gimple_call_fndecl (stmt))

  && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)

   switch (DECL_FUNCTION_CODE (fndecl))

 ...



with



  if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))

   switch (DECL_FUNCTION_CODE (gimple_call_fndecl (stmt)))

 ...

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  2013-01-07 12:08:27 UTC ---

I can now confirm that using g++ 4.7 as bootstrap compiler works out of

the box.  Even with the problems I've observed with g++ 4.4, this seems

a suitable way out.  Maybe the requirement/suggestion to use a bootstrap

compiler supporting -static-libstdc++ should be documented?



Thanks.

Rainer

[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org,

   ||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-01-07 
12:50:56 UTC ---

Guess related to -fintrinsic-module-path.

In some spots it still has the right argument:

-fintrinsic-modules-path /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgomp

but in other spots that argument is gone:

-fintrinsic-modules-path -B ...

thus -B is taken as -fintrinsic-modules-path argument and the original -B

argument is considered another source file.



Can you try perhaps:

--- libgomp/testsuite/libgomp.fortran/fortran.exp2012-12-20

11:38:48.663282599 +0100

+++ libgomp/testsuite/libgomp.fortran/fortran.exp2013-01-07

13:45:51.557361907 +0100

@@ -14,7 +14,7 @@ set quadmath_library_path "../libquadmat

 dg-init



 if { $blddir != "" } {

-lappend ALWAYS_CFLAGS "additional_flags=-fintrinsic-modules-path

${blddir}"

+lappend ALWAYS_CFLAGS "additional_flags=-fintrinsic-modules-path${blddir}"

 # Look for a static libgfortran first.

 if [file exists "${blddir}/${lang_library_path}/libgfortran.a"] {

 set lang_test_file "${lang_library_path}/libgfortran.a"



?  Though, I'd say using Joined Separate for such named option is just wrong,

it is fine for single letter options like -B, -A, -D, -U etc., but for options

of this kind I think it would be much better if it was

fintrinsic-modules-path

Fortran RejectNegative Separate

Specify where to find the compiled intrinsic modules



fintrinsic-modules-path=

Fortran RejectNegative Joined

Specify where to find the compiled intrinsic modules



instead and handle OPT_fintrinsic_modules_path_ the same as

OPT_fintrinsic_modules_path.  But given that the option has been added already

back in 2007, it is probably too late for that.

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[jakub at gcc dot gnu.org]

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



--- Comment #17 from Jakub Jelinek  2013-01-07 
12:55:39 UTC ---

But that is not a requirement.  The requirement is using a C++ compiler that

works out of the box (compiler configured in a path where its shared libraries

aren't found by the dynamic linker isn't), or making sure through

LD_LIBRARY_PATH or tweaking spec (to add -rpath) that the compiler works out of

the box, or compiler which supports -static-libstdc++.

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||INVALID



--- Comment #18 from Jakub Jelinek  2013-01-07 
13:01:38 UTC ---

.

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  2013-01-07 13:06:16 UTC ---

> --- Comment #17 from Jakub Jelinek  2013-01-07

> 12:55:39 UTC ---

> But that is not a requirement.  The requirement is using a C++ compiler that

> works out of the box (compiler configured in a path where its shared libraries

> aren't found by the dynamic linker isn't), or making sure through

> LD_LIBRARY_PATH or tweaking spec (to add -rpath) that the compiler works out 
> of

> the box, or compiler which supports -static-libstdc++.



But that first part (every single user of executables built with a g++

installed into non-system directories having to tweak LD_LIBRARY_PATH,

gcc builders/installers having to tweak specs or whatever) has been a

major shortcoming of gcc for years.  There needs to be a way that gcc

DTRT out of the box; a compiler producing executables that don't work

without prior additional setup is a joke.  Maybe I can work on this in

the 4.9 timeframe.



Rainer

[Bug target/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

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



--- Comment #31 from Georg-Johann Lay  2013-01-07 
13:12:18 UTC ---

Author: gjl

Date: Mon Jan  7 13:12:10 2013

New Revision: 194970



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

Log:

Backport from 2013-01-07 trunk r194968.



PR other/55243

* config/avr/t-avr: Don't automatically rebuild

$(srcdir)/config/avr/t-multilib

$(srcdir)/config/avr/avr-tables.opt

(avr-mcus): New phony target to build them on request.

(s-avr-mlib): Remove.

* avr/avr-mcus.def: Adjust comments.





Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/avr/avr-mcus.def

branches/gcc-4_7-branch/gcc/config/avr/t-avr

[Bug target/55894] New: No constant propagation in Intel intrinsics

[glisse at gcc dot gnu.org]

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



 Bug #: 55894

   Summary: No constant propagation in Intel intrinsics

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: gli...@gcc.gnu.org

Target: x86_64-linux-gnu





I was comparing ways to generate a constant (Intel 12.0 doesn't support the

first one), and noticed that these functions result in different asm. In

particular, there doesn't seem to be a lot of constant propagation going on :-(

-Ofast and various -march only managed to change 'g' to movddup.LC1(%rip),

%xmm0 (which in itself looks better than movapd, except that if I change g to

take an argument __m128d a and return _mm_xor_pd(a,m), that prevents gcc from

compacting it to a single insn, and I really don't see a reason for f and g to

generate different code as they look so similar). By the way, if you have a

suggestion on the simplest portable way to get this constant...



#include 

__m128d f(){

  const __m128d m = _mm_castsi128_pd (_mm_set1_epi64x (0x7fff));

  return m;

}

__m128d g(){

  const __m128d m = _mm_castsi128_pd (_mm_set1_epi64

(_mm_set_pi32(0x7fff,0x)));

  return m;

}

__m128d h(){

  const __m128d x = _mm_set1_pd (-0.);

  const __m128d m1 = _mm_cmpeq_pd (x, x);

  const __m128d m = _mm_xor_pd (x, m1);

  return m;

}



_Z1fv:

.LFB539:

.cfi_startproc

movapd.LC0(%rip), %xmm0

ret

.cfi_endproc

[...]

_Z1gv:

.LFB540:

.cfi_startproc

movq.LC1(%rip), %xmm0

punpcklqdq%xmm0, %xmm0

ret

.cfi_endproc

[...]

_Z1hv:

.LFB541:

.cfi_startproc

movapd.LC3(%rip), %xmm0

movapd%xmm0, %xmm1

cmpeqpd%xmm0, %xmm1

xorpd%xmm1, %xmm0

ret

.cfi_endproc

[...]

.LC0:

.long4294967295

.long2147483647

.long4294967295

.long2147483647

.section.rodata.cst8,"aM",@progbits,8

.align 8

.LC1:

.long-1

.long2147483647

.section.rodata.cst16

.align 16

.LC3:

.long0

.long-2147483648

.long0

.long-2147483648

[Bug target/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



   Priority|P3  |P5

 Status|NEW |RESOLVED

  Known to work||4.7.3

 Resolution||FIXED

   Target Milestone|--- |4.7.3



--- Comment #32 from Georg-Johann Lay  2013-01-07 
13:16:24 UTC ---

Fixed for 4.7.3



Change set for trunk:

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

[Bug fortran/55895] New: multiple type-bound procedures

[valeryweber at hotmail dot com]

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



 Bug #: 55895

   Summary: multiple type-bound procedures

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: fortran

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

ReportedBy: valerywe...@hotmail.com





Dear All

Should gfortran complain with the following code (so far it doesnt with the

trunk)?

Valery



module 

  type :: t

   contains

 procedure ::foo => afoo, bfoo

  end type t

contains

  subroutine afoo(this)

class(t) :: this

  end subroutine afoo

  subroutine bfoo(this)

class(t) :: this

  end subroutine bfoo

end module 

[Bug rtl-optimization/54524] [4.6/4.7 Regression] Spurious add on sum of bitshifts (forward-propagate issue)

[jan.sm...@alcatel-lucent.com]

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



Jan Smets  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #10 from Jan Smets  2013-01-07 
13:30:40 UTC ---

Verified

[Bug target/55894] No constant propagation in Intel intrinsics

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-07

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-01-07 
13:36:15 UTC ---

Usually target built-in folders are missing (targetm.fold_builtin).

[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation

[hubicka at gcc dot gnu.org]

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



--- Comment #3 from Jan Hubicka  2013-01-07 
13:36:58 UTC ---

OK, the problem seems to be already in what simple_iv returns for SSA name 12. 

Here we should have -1.  While analyzing the cast

(gdb) p debug_gimple_stmt (at_stmt)

_12 = (long unsigned int) _11;

that effectively changes addition to minus, we get to

CASE_CONVERT:

  /* In case we have a truncation of a widened operation that in

 the truncated type has undefined overflow behavior analyze

 the operation done in an unsigned type of the same precision

 as the final truncation.  We cannot derive a scalar evolution

 for the widened operation but for the truncated result.  */

  if (TREE_CODE (type) == INTEGER_TYPE

  && TREE_CODE (TREE_TYPE (rhs1)) == INTEGER_TYPE

  && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (rhs1))

  && TYPE_OVERFLOW_UNDEFINED (type)

  && TREE_CODE (rhs1) == SSA_NAME

  && (def = SSA_NAME_DEF_STMT (rhs1))

  && is_gimple_assign (def)

  && TREE_CODE_CLASS (gimple_assign_rhs_code (def)) == tcc_binary

  && TREE_CODE (gimple_assign_rhs2 (def)) == INTEGER_CST)

{ 

  tree utype = unsigned_type_for (type);

  chrec1 = interpret_rhs_expr (loop, at_stmt, utype,

   gimple_assign_rhs1 (def),

   gimple_assign_rhs_code (def),

   gimple_assign_rhs2 (def));

}

  else

chrec1 = analyze_scalar_evolution (loop, rhs1);



Here for widening conversions we do nothing. So we get

 

unit size 

align 32 symtab 0 alias set -1 canonical type 0x76ee8690 precision

32 min  max 

pointer_to_this >



arg 0 

constant 1>

arg 1  constant 4294967295>

arg 2  constant 1>>



this is correct, since it is done in unsigned int.

Next we do:

  res = chrec_convert (type, chrec1, at_stmt);

Eventually we go to convert_affine_scev and we set enforce_overflow_semantics

  enforce_overflow_semantics = (use_overflow_semantics

&& nowrap_type_p (type));



This test looks backwards to me.  If the type is nowrap, we do not need to

enforce anything about overflows, when it is wrap, then we have to.



Flipping it however do not change fix the testcase.

Anyway, the result of convert_affince_scev makes us to produce

 

unit size 

align 64 symtab 0 alias set -1 canonical type 0x76ee87e0 precision

64 min  max >



arg 0 

constant 1>

arg 1  constant 4294967295>

arg 2  constant 1>>



that seems already wrong.

So the bug seems to be that convert_affince_scev is not doing the right thing

here? But what the right thing is? Conversion to -1 or giving up?

[Bug target/55894] No constant propagation in Intel intrinsics

[glisse at gcc dot gnu.org]

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



--- Comment #2 from Marc Glisse  2013-01-07 13:48:17 
UTC ---

(In reply to comment #1)

> Usually target built-in folders are missing (targetm.fold_builtin).



That's one possibility. But I was wondering (and almost filed it in

rtl-optimization) why the folding was not already happening in RTL. The

builtins are expanded to standard vec_duplicate, eq, xor.

[Bug c/55896] New: Annoying compiler warning

[sworddragon2 at aol dot com]

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



 Bug #: 55896

   Summary: Annoying compiler warning

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: sworddrag...@aol.com





Created attachment 29097

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

Example code



After changing a global struct to a static variable I got a compiler warning. I

have analyzed this and tried to produce a minimum testcase. In the attachments

is an example code and compiling it with "gcc -O3 -Wall -Wextra -o test

-pedantic test.c" will result in the following warning:



In file included from /usr/include/string.h:638:0,

 from test.c:3:

In function 'strncat',

inlined from 'load_app_settings' at test.c:39:10:

/usr/include/x86_64-linux-gnu/bits/string3.h:150:3: warning: call to

__builtin___strncat_chk might overflow destination buffer [enabled by default]



Removing static from "static struct status STATUS;" solves the problem. Any

random change in load_app_settings() can solve the problem too even if the

change has nothing to do with the problem. For example if "strncat(content_2,

content_1, w_strlen(content_1) - 1);" is changed to "strncat(content_2,

content_1, w_strlen(content_1));" or " && content_1[0] == '['" is removed in

the condition.

[Bug tree-optimization/55862] [4.8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2495

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-01-07 
13:50:03 UTC ---

Followup, because of PR55888.  We have



  :

  # c_21 = PHI 

  # p_41 = PHI 

  a.1_42 = a;

  goto ;



  :

  # c_57 = PHI 

  # a.1_63 = PHI 

  # p_65 = PHI 

  *c_57 = 0;



and when PHI-translating p_65 we end up with p_41 (or c_21 value-ized).  But

AVAIL_OUT of BB 11 is:



debug[0] := { c_12(D) (0014), p_32(D) (0027), g.0_11 (0013), c_21 (0033),

a.1_42 (0034) }



thus contains _only_ c_21 (well, exactly one expression per value - it is

a value set after all).  And clean via valid_in_sets does



case NAME:

  return bitmap_set_contains_expr (AVAIL_OUT (block), expr);



thus checks for the expression availability.  That looks bogus to me.

Instead we should verify if there is a leader for the NAME in AVAIL_OUT.

[Bug fortran/55895] multiple type-bound procedures

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-01-07

 CC||burnus at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Tobias Burnus  2013-01-07 
13:51:52 UTC ---

(In reply to comment #0)

> Should gfortran complain with the following code



I think it okay:



  procedure ::foo => afoo, bfoo



is equivalent to:



  procedure :: foo => afoo

  procedure :: bfoo => bfoo





>From Fortran 2008:



R448   type-bound-procedure-stmt

   is  PROCEDURE [ [ , binding-attr -list ] :: ] type-bound-proc-decl-list



R449  type-bound-proc-decl  is  binding-name [ => procedure-name ]



C464 (R448)  If => procedure-name appears in a type-bound-proc-decl, the

double-colon separator shall appear.



If neither => procedure-name nor interface-name appears in a

type-bound-proc-decl, it is as though => procedure-name had appeared with a

procedure name the same as the binding name.







Note: Fortran 2003 didn't allow a list, i.e. with -std=f2003 it is correctly

rejected.



Fortran 2003:



R451  specific-binding

   is PROCEDURE [ (interface-name) ] [ [ , binding-attr -list ] :: ]

binding-name [ => procedure-name ]

[Bug fortran/55868] [4.8 Regression] gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org

   Target Milestone|--- |4.8.0

Summary|gfortran generates for  |[4.8 Regression] gfortran

   |CLASS(*)|generates for CLASS(*)

   |__m_MOD___vtab__$tar on |__m_MOD___vtab__$tar on

   |NO_DOLLAR_IN_LABEL systems  |NO_DOLLAR_IN_LABEL systems



--- Comment #1 from Tobias Burnus  2013-01-07 
14:00:22 UTC ---

Mark as regression to ensure it is fixed before the 4.8 release

[Bug tree-optimization/55888] [4.8 regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:867

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-01-07 
14:06:32 UTC ---

Author: rguenth

Date: Mon Jan  7 14:06:26 2013

New Revision: 194971



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

Log:

2013-01-07  Richard Biener  



PR tree-optimization/55888

PR tree-optimization/55862

* tree-ssa-pre.c (phi_translate_1): Revert previous change.

(valid_in_sets): Check if a NAME has a leader in AVAIL_OUT,

not if it is contained therein.



* gcc.dg/torture/pr55888.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr55888.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/55862] [4.8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2495

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-01-07 
14:06:32 UTC ---

Author: rguenth

Date: Mon Jan  7 14:06:26 2013

New Revision: 194971



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

Log:

2013-01-07  Richard Biener  



PR tree-optimization/55888

PR tree-optimization/55862

* tree-ssa-pre.c (phi_translate_1): Revert previous change.

(valid_in_sets): Check if a NAME has a leader in AVAIL_OUT,

not if it is contained therein.



* gcc.dg/torture/pr55888.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr55888.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation

[rakdver at iuuk dot mff.cuni.cz]

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



--- Comment #4 from rakdver at iuuk dot mff.cuni.cz 2013-01-07 14:09:18 UTC ---

> this is correct, since it is done in unsigned int.

> Next we do:

>   res = chrec_convert (type, chrec1, at_stmt);

> Eventually we go to convert_affine_scev and we set enforce_overflow_semantics

>   enforce_overflow_semantics = (use_overflow_semantics

> && nowrap_type_p (type));

> 

> This test looks backwards to me.  If the type is nowrap, we do not need to

> enforce anything about overflows, when it is wrap, then we have to.



The test is correct -- here, type is the type we are converting to; so, if

the type is nowrap, we have to make sure that the conversion is not creating

an overflowing iv.



Anyway, that is irrelevant to the problem: the check of scev_probably_wraps_p

below should return false -- which is probably what got broken by the #of

iterations estimation change.



Zdenek

[Bug tree-optimization/55888] [4.8 regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:867

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Richard Biener  2013-01-07 
14:09:40 UTC ---

Fixed.

[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation

[rakdver at gcc dot gnu.org]

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



--- Comment #5 from Zdenek Dvorak  2013-01-07 
14:11:29 UTC ---

(In reply to comment #4)

> the check of scev_probably_wraps_p below should return false



this should be "should return true"

[Bug target/55897] New: [avr] Allocate __memx data to .progmemx.data

[gjl at gcc dot gnu.org]

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



 Bug #: 55897

   Summary: [avr] Allocate __memx data to .progmemx.data

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: g...@gcc.gnu.org

Target: avr





Currently, data in address space __memx is allocated to .progmem.data, i.e. the

same section as for __flash resp. progmem.  However, there os no need that

__memx goes onto the same section.



In order to support better data layout, __memx should go in a different section

than .progmem, e.g. progmemx.

[Bug target/55894] No constant propagation in Intel intrinsics

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-01-07 
14:25:33 UTC ---

The reason why it doesn't happen during combine is that the insns don't allow

constants, they require loads from memory, so while the compiler is aware

of the folded constant, e.g. in the g function:

(insn 12 7 15 2 (set (reg/i:V2DF 21 xmm0)

(subreg:V2DF (reg:V2DI 65 [ D.4526 ]) 0)) pr55894.c:16 1157

{*movv2df_internal}

 (expr_list:REG_DEAD (reg:V2DI 65 [ D.4526 ])

(expr_list:REG_EQUAL (const_vector:V2DF [

(const_double:DF +QNaN [+QNaN])

(const_double:DF +QNaN [+QNaN])

])

(nil

it fails to match and thus isn't actually used in the code.  A pass that would

see you load a constant from memory, do some transformations on it which are

all foldable by the compiler and transforming that into just load of a

different constant could handle this (or do it in combine?), but the problem

with that is that it could in theory increase the constant pool too much.

[Bug lto/55525] ICE: tree check: expected array_type, have pointer_type in array_ref_low_bound, at expr.c:6768

[ro at gcc dot gnu.org]

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



Rainer Orth  changed:



   What|Removed |Added



 CC||ro at gcc dot gnu.org



--- Comment #6 from Rainer Orth  2013-01-07 14:47:53 UTC 
---

Unfortunately, the testcase fails for 32-bit on Solaris with Sun ld:



ld: fatal: symbol 's' has differing sizes:

(file c_lto_pr55525_0.o value=0x8; file c_lto_pr55525_1.o value=0x4);

tentative symbol cannot override defined symbol of smaller size

ld: fatal: file processing errors. No output written to

gcc-dg-lto-pr55525-01.ex

e

collect2: error: ld returned 1 exit status



  Rainer

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2013-01-07 
14:51:26 UTC ---

I don't see any differences in assembly, when I compile either version of

random.i with -std=gnu99 -fcx-fortran-rules -g -O2 with a r189365 vs. r189366

x86_64-linux -> hppa2.0w-hp-hpux11.11 cross.  Can try i686-linux ->

hppa2.0w-hp-hpux11.11 cross in case it is HWINT related...

[Bug lto/55525] ICE: tree check: expected array_type, have pointer_type in array_ref_low_bound, at expr.c:6768

[rguenther at suse dot de]

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



--- Comment #7 from rguenther at suse dot de  
2013-01-07 14:55:31 UTC ---

On Mon, 7 Jan 2013, ro at gcc dot gnu.org wrote:



> 

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

> 

> Rainer Orth  changed:

> 

>What|Removed |Added

> 

>  CC||ro at gcc dot gnu.org

> 

> --- Comment #6 from Rainer Orth  2013-01-07 14:47:53 
> UTC ---

> Unfortunately, the testcase fails for 32-bit on Solaris with Sun ld:

> 

> ld: fatal: symbol 's' has differing sizes:

> (file c_lto_pr55525_0.o value=0x8; file c_lto_pr55525_1.o value=0x4);

> tentative symbol cannot override defined symbol of smaller size

> ld: fatal: file processing errors. No output written to

> gcc-dg-lto-pr55525-01.ex

> e

> collect2: error: ld returned 1 exit status



Does it work with replacing char s[8] with char s[sizeof (char *)]?



If so, patch is ok.



Richard.

[Bug c++/55898] New: Can't obtain stack trace

[net147 at gmail dot com]

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



 Bug #: 55898

   Summary: Can't obtain stack trace

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

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

ReportedBy: net...@gmail.com





Created attachment 29098

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

Test case



Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=c:/mbgcc-sjlj/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.0/lto-wrapper.exe

Target: x86_64-w64-mingw32

Configured with: ../../../mingw-sources/gcc-trunk/configure

--host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32

--target=x86_64-w64-mingw32

--prefix=/temp/x64-trunk-snapshot-win32-sjlj-rev2/prefix

--with-sysroot=/temp/x64-trunk-snapshot-win32-sjlj-rev2/prefix --enable-shared

--enable-static --enable-targets=all --enable-multilib

--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes

--enable-threads=win32 --enable-libgomp --enable-lto --enable-graphite

--enable-cloog-backend=isl --enable-checking=release

--enable-fully-dynamic-string --enable-version-specific-runtime-libs

--enable-sjlj-exceptions --disable-ppl-version-check

--disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug

--disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls

--disable-werror --disable-symvers --with-gnu-as --with-gnu-ld

--with-tune=generic --with-host-libstdcxx='-static -lstdc++' --with-libiconv

--with-gmp=/temp/mingw-prereq/x86_64-w64-mingw32-static

--with-mpfr=/temp/mingw-prereq/x86_64-w64-mingw32-static

--with-mpc=/temp/mingw-prereq/x86_64-w64-mingw32-static

--with-ppl=/temp/mingw-prereq/x86_64-w64-mingw32-static

--with-cloog=/temp/mingw-prereq/x86_64-w64-mingw32-static

--with-pkgversion='Built by MinGW-builds project'

--with-bugurl=http://sourceforge.net/projects/mingwbuilds/ CFLAGS='-O2 -pipe

-fomit-frame-pointer -I/temp/x64-trunk-snapshot-win32-sjlj-rev2/libs/include

-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe

-fomit-frame-pointer' CPPFLAGS= LDFLAGS='-pipe

-L/temp/x64-trunk-snapshot-win32-sjlj-rev2/libs/lib

-L/temp/mingw-prereq/x86_64-w64-mingw32-static/lib

-L/temp/x64-trunk-snapshot-win32-sjlj-rev2/prefix/opt/lib'

Thread model: win32

gcc version 4.8.0 20121225 (experimental) (Built by MinGW-builds project) 



g++ -g test.cpp

gdb a.exe

(gdb) break test.cpp:19

(gdb) run

(gdb) where

#0  Derived::Derived (this=0x22fd70) at test.cpp:19

#1  0x in ?? ()



This affects MinGW-w64 GCC 64-bit SJLJ builds. GCC versions known to be

affected: 4.6.1, 4.6.3, 4.7.2, 4.8.0 20121225.



It does not seem to affect MinGW-w64 GCC 64-bit SEH builds.

[Bug other/55899] New: GCC should provide built-ins in data types flavor/version/variation

[yann at droneaud dot fr]

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



 Bug #: 55899

   Summary: GCC should provide built-ins in  data types

flavor/version/variation

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: other

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

ReportedBy: y...@droneaud.fr





Built-in functions such as 

 __builtin_clz(unsigned int x)

 __builtin_ctz(unsigned int x)

 __builtin_ffs(unsigned int x)

 etc.

are lacking variant based on C99  data type.



Currently there's

 __builtin_clzl(unsigned long x)

 __builtin_clzll(unsigned long long x)



I'd like to have:

 __builtin_clz32(uint32_t x)

 __builtin_clz64(uint64_t x)



This would help to hard code the number of bits when using such construct to

know the number of bit needed to hold a value:



(8 * sizeof(unsigned int)) - __builtin_clz(value)



when value is of type uint32_t:



 32 - __builtin_clz32(value)



Note: there's already __builtin_bswap32(int32_t x) and

__builtin_bswap64(int64_t x)

[Bug target/43961] [4.6/4.7/4.8 Regression] [ARM thumb] "branch out of range" with thumb1_output_casesi

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.6.4

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

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||DUPLICATE



--- Comment #3 from Tobias Burnus  2013-01-07 
15:23:51 UTC ---

I believe this bug is fixed by the just committed patch for PR 55852, which

restores the error message of comment 1. The commit is:



Date: Mon Jan  7 11:10:53 2013

New Revision: 194966

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



Thus, I mark this PR as duplicate.







Thanks for the report and sorry for the breakage.



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

[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||slayoo at staszic dot

   ||waw.pl



--- Comment #8 from Tobias Burnus  2013-01-07 
15:23:51 UTC ---

*** Bug 54940 has been marked as a duplicate of this bug. ***

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-w64-mingw32

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-01-07

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-01-07 
15:25:22 UTC ---

Are you sure that you do not somehow pull in LTO objects from older releases?

Needs someone with access to $target to debug.

[Bug rtl-optimization/55627] [4.8 Regression] FAIL: g++.dg/bprob/g++-bprob-1.C execution, -Os -fprofile-arcs

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||wrong-code



--- Comment #2 from Richard Biener  2013-01-07 
15:29:07 UTC ---

Needs more analysis from someone with pa access.  Or maybe it works again?

[Bug rtl-optimization/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

[Bug rtl-optimization/55686] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1244

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

[Bug c++/55885] Modulo operator crashes for int and long variables if they have minimal value

[joseph at codesourcery dot com]

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



--- Comment #5 from joseph at codesourcery dot com  2013-01-07 15:34:34 UTC ---

INT_MIN % -1 and INT_MIN / -1 *should* be made defined by -fwrapv; that's 

bug 30484.



Without -fwrapv, C11 made explicit the intent that the modulo operation is 

undefined in the cases where division is undefined ("If the quotient a/b 

is representable, the expression (a/b)*b + a%b shall equal a; otherwise, 

the behavior of both a/b and a%b is undefined."); I don't know about C++.

[Bug tree-optimization/55890] [4.7/4.8 Regression] calling a builtin func through a cast triggers an ICE

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-01-07 
15:34:48 UTC ---

Author: rguenth

Date: Mon Jan  7 15:34:43 2013

New Revision: 194975



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

Log:

2013-01-07  Richard Biener  



PR middle-end/55890

* gimple.h (gimple_call_builtin_p): New overload.

* gimple.c (validate_call): New function.

(gimple_call_builtin_p): Likewise.

* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):

Use gimple_call_builtin_p.

(find_func_clobbers): Likewise.

* tree-ssa-strlen.c (adjust_last_stmt): Likewise.

(strlen_optimize_stmt): Likewise.



* gcc.dg/torture/pr55890-1.c: New testcase.

* gcc.dg/torture/pr55890-2.c: Likewise.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr55890-1.c

trunk/gcc/testsuite/gcc.dg/torture/pr55890-2.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/gimple.c

trunk/gcc/gimple.h

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-strlen.c

trunk/gcc/tree-ssa-structalias.c

[Bug target/55718] [4.8 Regression] ICE in gen_reg_rtx, at emit-rtl.c:866

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Known to work||4.8.0

Summary|[4.7/4.8 Regression]|[4.7 Regression] calling a

   |calling a builtin func  |builtin func through a cast

   |through a cast triggers an  |triggers an ICE

   |ICE |



--- Comment #6 from Richard Biener  2013-01-07 
15:36:06 UTC ---

Fixed on trunk for the testcase(s) in question.

[Bug rtl-optimization/55719] [4.8 Regression] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|REOPENED|RESOLVED

 Resolution||FIXED



--- Comment #11 from Richard Biener  2013-01-07 
15:39:18 UTC ---

It's a different bug though.

[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO

[hjl.tools at gmail dot com]

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



--- Comment #8 from H.J. Lu  2013-01-07 15:40:16 
UTC ---

(In reply to comment #7)

> It's a global, why should it get collected?



Because it is empty when ggc_collect is called.

[Bug c++/55900] New: internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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



 Bug #: 55900

   Summary: internal compiler error: Segmentation fault

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: rgue...@gcc.gnu.org





Cloned from PR55753, 2nd testcase.



> ./cc1plus -quiet t.ii -std=c++11

testcase.cpp: In constructor 'B::B()':

testcase.cpp:6:61:   in constexpr expansion of 'std::complex(1.0e+0)'

testcase.cpp:6:61: internal compiler error: Segmentation fault

0xca7579 crash_signal

/space/rguenther/src/svn/trunk/gcc/toplev.c:334

0x589ba7 tree_check(tree_node*, char const*, int, char const*, tree_code)

/space/rguenther/src/svn/trunk/gcc/tree.h:3670

0x768c67 lookup_parameter_binding

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:6432

0x76de8b cxx_eval_constant_expression

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:7676

0x76a335 cxx_eval_binary_expression

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:6804

0x76e577 cxx_eval_constant_expression

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:7852

0x76b8dc cxx_eval_bare_aggregate

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:7125

0x76e6e6 cxx_eval_constant_expression

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:7896

0x769c8c cxx_eval_call_expression

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:6695

0x76def1 cxx_eval_constant_expression

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:7691

0x76dff2 cxx_eval_constant_expression

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:7712

0x76eb15 cxx_eval_outermost_constant_expr

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:7992

0x76f241 maybe_constant_value(tree_node*)

/space/rguenther/src/svn/trunk/gcc/cp/semantics.c:8103

0x65b7b6 build_non_dependent_expr(tree_node*)

/space/rguenther/src/svn/trunk/gcc/cp/pt.c:20204

0x65bc26 make_args_non_dependent(vec*)

/space/rguenther/src/svn/trunk/gcc/cp/pt.c:20281

0x5a5c61 build_new_method_call_1

/space/rguenther/src/svn/trunk/gcc/cp/call.c:7450

0x5a7c25 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)

/space/rguenther/src/svn/trunk/gcc/cp/call.c:7741

0x5a55ef build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)

/space/rguenther/src/svn/trunk/gcc/cp/call.c:7323

0x59e156 build_temp

/space/rguenther/src/svn/trunk/gcc/cp/call.c:5718

0x59ffd5 convert_like_real

/space/rguenther/src/svn/trunk/gcc/cp/call.c:6065

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug c++/55900] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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



--- Comment #1 from Richard Biener  2013-01-07 
15:41:18 UTC ---

Reducing.

[Bug fortran/55789] [4.6/4.7/4.8 Regression] Needless realloc with array constructor.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P4

[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

[Bug rtl-optimization/55829] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||ra

   Priority|P3  |P1

[Bug rtl-optimization/55845] [4.8 Regression] 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

[Bug c++/55878] [4.7/4.8 Regression] --enable-checking=yes rejection of typeid

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1



--- Comment #1 from Richard Biener  2013-01-07 
15:48:24 UTC ---

Definitely P1, we should be consistent with accepting/rejecting code

with/without checking enabled.

[Bug c++/55900] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||ice-on-valid-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-07

 Ever Confirmed|0   |1

  Known to fail||4.7.2, 4.8.0



--- Comment #2 from Richard Biener  2013-01-07 
15:54:32 UTC ---

Reduced testcase:



template class complex;

template<> 

struct complex

{

  typedef __complex__ double _ComplexT;

  constexpr complex(double __r = 0.0, double __i = 0.0)

  : _M_value{ __r, __i } { }

  _ComplexT _M_value;

};

template  

struct B

{

  B() { complex((true ? 1.0 : complex())); } 

};



4.6 does not support the initializer list, so technically not a regression.

[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P2

[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||dnovillo at gcc dot gnu.org



--- Comment #9 from Richard Biener  2013-01-07 
16:01:52 UTC ---

Eh.  Diego, how does GTY((user)) work here?  It smells like a bug in vec.h

to me.



/* Garbage collection support for vec.  */



template

void

gt_ggc_mx (vec *v)

{

  extern void gt_ggc_mx (T &);

  for (unsigned i = 0; i < v->length (); i++)

gt_ggc_mx ((*v)[i]);

}



doesn't it need to mark the vec itself?  Maybe automatic registration of

roots (this is a GC root) does not work with GTY((user))?



As far as I understand HJ the vec struct itself is GCed but the global

var pointing to it (the root) is not zeroed (I say it shouldn't be collected

at all).

[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

Summary|Bad memory access with  |[4.8 Regression] Bad memory

   |profiledbootstrap and LTO   |access with

   ||profiledbootstrap and LTO



--- Comment #10 from Richard Biener  2013-01-07 
16:02:38 UTC ---

vec + GC related regression.

[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)

[dave.anglin at bell dot net]

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



--- Comment #4 from dave.anglin at bell dot net 2013-01-07 16:09:14 UTC ---

On 1/7/2013 7:50 AM, jakub at gcc dot gnu.org wrote:

> Guess related to -fintrinsic-module-path.

Have being doing a regression search and it seems to be

pointing to this change.  Seem to have to do a full bootstrap

to test.  Sometimes test is unresolved.



Will try you your suggestion.



Dave

[Bug c/55882] unaligned load/store : incorrect struct offset

[jan.sm...@alcatel-lucent.com]

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



--- Comment #3 from Jan Smets  2013-01-07 
16:20:32 UTC ---





 : :

...

  20:   03c21021  adduv0,s8,v0  20:   03c21021  adduv0,s8,v0



  24:   8c44000c  lw  a0,12(v0) |   24:   8c44000a  lw  a0,10(v0)  



  28:   3c03000f  lui v1,0xf|   28:   3c03  lui v1,0x

  2c:   3463  ori v1,v1,0x  |   2c:   3463000f  ori v1,v1,0xf

  30:   00831824  and v1,a0,v1  30:   00831824  and v1,a0,v1



  34:   ac43000c  sw  v1,12(v0) |   34:   ac43000a  sw  v1,10(v0)   



  38:   03c0e82d  movesp,s8 38:   03c0e82d  movesp,s8

  3c:   8fbe03ec  lw  s8,1004(sp)   3c:   8fbe03ec  lw  s8,1004(sp)

  40:   27bd03f0  addiu   sp,sp,100840:   27bd03f0  addiu   sp,sp,1008

  44:   03e8  jr  ra44:   03e8  jr  ra

  48:     nop   48:     nop

[Bug c/55882] unaligned load/store : incorrect struct offset

[jan.sm...@alcatel-lucent.com]

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



--- Comment #4 from Jan Smets  2013-01-07 
16:22:17 UTC ---

Created attachment 29099

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

testcase-pr55882.c

[Bug target/54461] [avr] add configure option for better AVR-Libc integration

[gjl at gcc dot gnu.org]

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



--- Comment #5 from Georg-Johann Lay  2013-01-07 
16:23:13 UTC ---

Author: gjl

Date: Mon Jan  7 16:22:59 2013

New Revision: 194981



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

Log:

Backport from 2013-01-07 trunk r194978.

PR target/54461

* doc/install.texi (Cross-Compiler-Specific Options): Document

--with-avrlibc.





Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/doc/install.texi

[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets

[dje at gcc dot gnu.org]

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



--- Comment #7 from David Edelsohn  2013-01-07 16:32:04 
UTC ---

I re-ran a patched version of configure on AIX and it correctly does not define

HWCAP_FLAGS as -nH, so the configure patch seems to work as intended on AIX.



Thanks.

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

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



--- Comment #11 from Jakub Jelinek  2013-01-07 
16:34:14 UTC ---

Ah, ok, seems indeed to be HWI size related and also (due to an earlier bug)

related to the revision you've mentioned.

So, with an i686-linux -> hppa2.0w-hp-hpux11.11 cross this is reproduceable

with -O2 on:

extern unsigned int *kiss_seed_1;

extern unsigned int *kiss_seed_2;

unsigned int kiss_random_kernel(unsigned int * seed);



void

foo (double *x)

{

  unsigned long long mask, kiss = ((unsigned long long) kiss_random_kernel

(kiss_seed_1)) << 32;

  kiss += kiss_random_kernel (kiss_seed_2);

  mask = ~ (unsigned long long) 0u << (64 - 53);

  kiss = kiss & mask;

  *x = (double) kiss * (0x1.p-64);

}



and the problem is that starting with r189366 VRP incorrectly does:

   kiss_9 = kiss_8 & 0xf800;

-  D.1358_10 = (double) kiss_9;

+  D.1363_17 = (signed int) kiss_9;

+  D.1358_10 = (double) D.1363_17;



The bugs seem to be in simplify_float_conversion_using_ranges and

range_fits_type_p.  The simplify_float_conversion_using_ranges bug (now just

code consistency issue, before r189366 a real bug) is that the second

can_float_p is tested for != 0 (implicitly) instead of != CODE_FOR_nothing.

Starting with r189366 it doesn't make a real difference, before that

CODE_FOR_nothing was some big number and this fact hid the other bug.



>From the kiss_9 assignment, VRP determines vr to be

[0, 0xf800]

(in unsigned long long type).



And now the bug is that while range_fits_type_p (vr, 8, 0) and

range_fits_type_p (vr, 64, 0) correctly return false, such big 64-bit range

really doesn't fit into signed 8-bit or signed 64-bit range,

range_fits_type_p (vr, 16, 0) and range_fits_type_p (vr, 32, 0) incorrectly

return true - and for floatsidf2 there is a pattern, which is why we miscompile

it.

[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets

[ro at gcc dot gnu.org]

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



Rainer Orth  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2013-01/msg00329.htm

   ||l



--- Comment #8 from Rainer Orth  2013-01-07 16:41:28 UTC 
---

Patch submitted.

[Bug c++/55877] [4.6 Regression] Anon visibility issues

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|FIXED   |



--- Comment #6 from Jason Merrill  2013-01-07 
16:43:55 UTC ---

(In reply to comment #4)

> BTW, what about:

> typedef struct {

>   typedef enum { X, Y } A;

>   typedef struct { } B;

>   struct C {

> static void fn1 (B) { }

> static void fn2 (C) { }

>   };

> } D;



Hmm, yes, that's still a regression from 4.4.

[Bug driver/55470] Support -fuse-ld=bfd and -fuse-ld=gold

[hjl at gcc dot gnu.org]

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



--- Comment #2 from hjl at gcc dot gnu.org  2013-01-07 
16:54:39 UTC ---

Author: hjl

Date: Mon Jan  7 16:54:33 2013

New Revision: 194983



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

Log:

Support -fuse-ld=bfd and -fuse-ld=gold



PR driver/55470

* collect2.c (main): Support -fuse-ld=bfd and -fuse-ld=gold.



* common.opt: Add fuse-ld=bfd and fuse-ld=gold.



* gcc.c (LINK_COMMAND_SPEC): Pass -fuse-ld=* to collect2.



* opts.c (comman_handle_option): Ignore -fuse-ld=bfd and

-fuse-ld=gold.



* doc/invoke.texi: Document -fuse-ld=bfd and -fuse-ld=gold.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/collect2.c

trunk/gcc/common.opt

trunk/gcc/doc/invoke.texi

trunk/gcc/gcc.c

trunk/gcc/opts.c

[Bug c++/55898] Can't obtain stack trace

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||ktietz at gcc dot gnu.org



--- Comment #1 from Paolo Carlini  2013-01-07 
16:58:04 UTC ---

Kai, can you have a look?