[Bug tree-optimization/56049] New: [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
Bug #: 56049
Summary: [4.8 Regression] Simplification to constants not done
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
>From http://gcc.gnu.org/ml/fortran/2013-01/msg00158.html :
program inline
integer i
integer a(8,8), b(8,8)
a = 0
do i = 1, 1000
call add(b, a, 1)
a = b
end do
print *, a
contains
subroutine add(b, a, o)
integer, intent(inout) :: b(8,8)
integer, intent(in) :: a(8,8), o
b = a + o
end subroutine add
end program inline
is simplified all the way to the final constant with 4.6 and
4.7 (example for 4.6.2):
;; Function inline (MAIN__) (executed once)
inline ()
{
struct array2_integer(kind=4) parm.3;
struct __st_parameter_dt dt_parm.2;
integer(kind=4) a[64];
:
a = {};
MEM[(integer(kind=4)[64] *)&a] = 1000;
MEM[(integer(kind=4)[64] *)&a + 4B] = 1000;
MEM[(integer(kind=4)[64] *)&a + 8B] = 1000;
MEM[(integer(kind=4)[64] *)&a + 12B] = 1000;
MEM[(integer(kind=4)[64] *)&a + 16B] = 1000;
MEM[(integer(kind=4)[64] *)&a + 20B] = 1000;
MEM[(integer(kind=4)[64] *)&a + 24B] = 1000;
MEM[(integer(kind=4)[64] *)&a + 28B] = 1000;
MEM[(integer(kind=4)[64] *)&a + 32B] = 1000;
... and so on. Current trunk converts this to
;; Function inline (MAIN__, funcdef_no=0, decl_uid=1874, cgraph_uid=1)
(executed once)
inline ()
{
vector(4) integer(kind=4) vect_var_.16;
vector(4) integer(kind=4) vect_var_.15;
vector(4) integer(kind=4) vect_var_.14;
struct array2_integer(kind=4) parm.3;
struct __st_parameter_dt dt_parm.2;
integer(kind=4) b[64];
integer(kind=4) a[64];
unsigned int ivtmp_153;
unsigned int ivtmp_154;
:
a = {};
:
# ivtmp_154 = PHI <1000(2), ivtmp_153(4)>
vect_var_.14_1 = MEM[(integer(kind=4)[64] *)&a];
vect_var_.15_42 = MEM[(integer(kind=4)[64] *)&a + 16B];
vect_var_.16_43 = vect_var_.14_1 + { 1, 1, 1, 1 };
vect_var_.16_44 = vect_var_.15_42 + { 1, 1, 1, 1 };
MEM[(integer(kind=4)[64] *)&b] = vect_var_.16_43;
MEM[(integer(kind=4)[64] *)&b + 16B] = vect_var_.16_44;
vect_var_.14_71 = MEM[(integer(kind=4)[64] *)&a + 32B];
vect_var_.15_77 = MEM[(integer(kind=4)[64] *)&a + 48B];
vect_var_.16_78 = vect_var_.14_71 + { 1, 1, 1, 1 };
vect_var_.16_79 = vect_var_.15_77 + { 1, 1, 1, 1 };
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Thomas Koenig changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 --- Comment #1 from Dominique d'Humieres 2013-01-20 10:32:18 UTC --- This occurred between revisions 193542 (2012-11-15) and 193573 (2012-11-16).
[Bug c++/56050] New: g++ compiler confused with virtual functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56050
Bug #: 56050
Summary: g++ compiler confused with virtual functions.
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: triste...@yahoo.com
the following example code compiles cleanly when the second-and-third-last
lines in the main function are commented out, however when it's uncommented it
fails with:
a.cpp: In function ‘int main(int, const char**)’:
a.cpp:39:7: error: no matching function for call to ‘derived::to()’
a.cpp:39:7: note: candidate is:
a.cpp:30:7: note: virtual void derived::to(std::map,
std::basic_string >)
a.cpp:30:7: note: candidate expects 1 argument, 0 provided
a.cpp:40:27: error: no matching function for call to
‘derived::from(std::string)’
a.cpp:40:27: note: candidate is:
a.cpp:26:7: note: virtual void derived::from(std::map,
std::basic_string >)
a.cpp:26:7: note: no known conversion for argument 1 from ‘std::string {aka
std::basic_string}’ to ‘std::map,
std::basic_string >’
that was simply from a command line: g++ a.cpp
as you can see from the code below the compiler doesn't seem able to
differentiate between the virtual functions and the base functions, even though
the parameters differ.
i think i was expecting the compiler to be able to differentiate between:
- "from" functions requiring std::string and std::map
- "to" functions requiring void and std::map
further, if the error is valid, i think i would expect the compilation to fail
regardless of whether the two lines in main are commented out or not, ie: the
compiler fails to detect the errors in the classes at compile-time.
regards
tristen
#include
#include
#include
class base
{
public:
void from(std::string p_value)
{
std::cout << p_value << std::endl;
}
void to()
{
}
virtual void from(std::map p_map) = 0;
virtual void to(std::map p_map) = 0;
};
class derived : public base
{
public:
void from(std::map p_map)
{
}
void to(std::map p_map)
{
}
};
int main(int, const char**)
{
derived d;
//d.to();
//d.from(std::string("one"));
return 0;
}
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|[4.8 Regression] ICE in in |[4.8 Regression] [OOP] ICE |gfc_conv_expr_op|in in gfc_conv_expr_op --- Comment #3 from janus at gcc dot gnu.org 2013-01-20 11:03:07 UTC --- (In reply to comment #2) > And the culprit is... > ... not me! Though I was not very far. :-) > > http://gcc.gnu.org/viewcvs?view=revision&revision=190420 Ouch. Why is it always gonna have to be me? ;) Reduced test case, which removes the dependence on iso_varying_string, and gives the same ICE as comment 0: module process_libraries implicit none type :: string_t end type type :: process_variant_def_t contains procedure, nopass :: type_string end type contains function type_string () result (string) type(string_t) :: string end function subroutine process_variant_def_allocate_by_name type(string_t) :: name class(process_variant_def_t), allocatable :: variant_def associate (template => variant_def) if (template%type_string () == name) return end associate end subroutine end module
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #4 from janus at gcc dot gnu.org 2013-01-20 11:09:36 UTC --- I think this baby is rather closely connected to PR 55984 (even though the ICE is a different one). Both deal with polymorphic ASSOCIATE statements.
[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044 --- Comment #5 from Dimitris Papavasiliou 2013-01-20 11:09:57 UTC --- Actually trying out -Wno-shadow indicates that it doesn't make any difference in this case. The compiler keeps complaining about the instance variable being hidden by the local one. If there is another warning option I can use to turn it off please let me know as I couldn't find it.
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #5 from janus at gcc dot gnu.org 2013-01-20 11:30:08 UTC --- Btw, while the ICE is obviously a 4.8 regression, 4.6 and 4.7 are not much more helpful, either: if (template%type_string () == name) return 1 Error: Operands of comparison operator '==' at (1) are TYPE(string_t)/TYPE(string_t)
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #6 from Dominique d'Humieres 2013-01-20 11:35:59 UTC --- > Btw, while the ICE is obviously a 4.8 regression, 4.6 and 4.7 are not much > more > helpful, either: > > if (template%type_string () == name) return > 1 > Error: Operands of comparison operator '==' at (1) are > TYPE(string_t)/TYPE(string_t) This is for the reduced test in comment #3. The original test compiles with 4.7.2 for me.
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #7 from janus at gcc dot gnu.org 2013-01-20 11:36:52 UTC --- (In reply to comment #5) > Btw, while the ICE is obviously a 4.8 regression, 4.6 and 4.7 are not much > more > helpful, either: > > if (template%type_string () == name) return > 1 > Error: Operands of comparison operator '==' at (1) are > TYPE(string_t)/TYPE(string_t) ... but that is just due to the absence of the full iso_varying_string code (in comment 3), which defines an equality operator for string_t. Both 4.6 and 4.7 cleanly compile the full test case in comment 0.
[Bug c++/56050] g++ compiler confused with virtual functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56050 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely 2013-01-20 11:41:39 UTC --- This is not a bug, it's called name hiding. For d.to() the compiler does name lookup for "to" in the scope of derived and finds a name, so it stops looking. Then overload resolution tries to match the arguments to the function and fails. You need to re-declare the names in the derived class so all overloaded names are visible in the derived class. using base::to; using base::from;
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #8 from janus at gcc dot gnu.org 2013-01-20 11:45:22 UTC --- Note that the patch from PR 55984 comment 4 fixes the ICE for both comment 0 and comment 3. This brings comment 3 to the same error message one gets with 4.6/4.7, while comment 0 yields a new ICE: associate (template => templates%initial(1)%variant_def) 1 Internal Error at (1): gfc_variable_attr(): Bad array reference
[Bug c/56051] New: Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051
Bug #: 56051
Summary: Wrong expression evaluation
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olivier@gmail.com
#include
int main(void)
{
int a, s = 8;
unsigned char data[1] = {0};
a = data[0] < (unsigned char) (1 << s);
printf("%d\n", a);
return 0;
}
The expression assigned to object a evaluates to 1 but I think it should
evaluate to 0. Tested on gcc 4.7.2 / Linux x64.
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #9 from Jürgen Reuter 2013-01-20 11:55:31 UTC --- Janus, long time no see! XD Greetings to my old home state!
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #10 from janus at gcc dot gnu.org 2013-01-20 12:05:11 UTC --- (In reply to comment #8) > Note that the patch from PR 55984 comment 4 fixes the ICE for both comment 0 > and comment 3. This brings comment 3 to the same error message one gets with > 4.6/4.7, while comment 0 yields a new ICE: > > associate (template => templates%initial(1)%variant_def) > 1 > Internal Error at (1): > gfc_variable_attr(): Bad array reference Reduced test case for this error: implicit none type :: process_variant_def_t end type type :: process_component_def_t class(process_variant_def_t), allocatable :: variant_def end type type(process_component_def_t), dimension(1:2) :: initial associate (template => initial(1)%variant_def) end associate end The error only occurs with the patch, but not with a clean trunk.
[Bug c/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-20 Ever Confirmed|0 |1 --- Comment #1 from Marc Glisse 2013-01-20 12:24:18 UTC --- fold-const.c:13561 doesn't check that the conversion is not narrowing before doing the optimization.
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 --- Comment #6 from Daniel Krügler 2013-01-20 12:27:20 UTC --- (In reply to comment #0) > The code uses C++11 lambda expressions in a constant expression context for > the SFINAE. As far as I can tell, SFINAE should apply since the lambda occurs > lexically within the immediate context for the substitution. I wonder why you think this would belong to the "immediate context". Actually it seems to me as if the instantiation of the body of a lambda expression is similarly non-immediate as the instantiation of a class template.
[Bug fortran/54033] gfortran: Passing file as include directory - add diagnostic and ICE with -cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54033 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Thomas Koenig 2013-01-20 12:33:50 UTC --- Really closing.
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #11 from janus at gcc dot gnu.org 2013-01-20 12:53:40 UTC --- (In reply to comment #9) > Janus, long time no see! XD Right! It's been a while since you submitted a bugreport (after all the procedure pointer bugs had been fixed) ... Are you also jumping on the polymorphic bandwagon now? > Greetings to my old home state! I guess you're referring to the state of Hessen? (IIRC, you mentioned that you studied in Darmstadt, right?)
[Bug fortran/56008] [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56008 --- Comment #5 from Dominique d'Humieres 2013-01-20 13:34:52 UTC --- > Created attachment 29221 [details] > Fix for this PR and PR 47517 I confirm for this PR. However while the original code of PR 47517 executes without error it has a huge memory leak: ==98070== HEAP SUMMARY: ==98070== in use at exit: 146,401,340 bytes in 2,700,054 blocks ==98070== total heap usage: 2,900,145 allocs, 200,091 frees, 170,502,858 bytes allocated ==98070== ==98070== 12 bytes in 1 blocks are definitely lost in loss record 1 of 42 ==98070==at 0x100019679: malloc (vg_replace_malloc.c:266) ==98070==by 0x10EBB: MAIN__ (in ./a.out) ==98070==by 0x17BC9: main (in ./a.out) ... ==98070== ==98070== 102,798,972 (71,999,280 direct, 30,799,692 indirect) bytes in 299,997 blocks are definitely lost in loss record 42 of 42 ==98070==at 0x100019679: malloc (vg_replace_malloc.c:266) ==98070==by 0x172A7: MAIN__ (in ./a.out) ==98070==by 0x17BC9: main (in ./a.out) ==98070== ==98070== LEAK SUMMARY: ==98070==definitely lost: 105,601,152 bytes in 500,046 blocks ==98070==indirectly lost: 40,800,100 bytes in 2,200,007 blocks ==98070== possibly lost: 0 bytes in 0 blocks ==98070==still reachable: 0 bytes in 0 blocks ==98070== suppressed: 88 bytes in 1 blocks ==98070== ==98070== For counts of detected and suppressed errors, rerun with: -v ==98070== ERROR SUMMARY: 34 errors from 34 contexts (suppressed: 0 from 0) (loop reduded to 10). The test in PR 47517 comment #1 still fails at runtime: 1>10 2>10 1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Compiling it with -fsanitize=address gives ==237== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x000103be06b0 at pc 0x10b75 bp 0x7fff5fbfd3a0 sp 0x7fff5fbfd398 READ of size 8 at 0x000103be06b0 thread T0
[Bug middle-end/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson 2013-01-20 14:11:20 UTC --- Technically the test case should use CHAR_BIT not 8. The bug is present in every release back to at least 2.95.3.
[Bug rtl-optimization/21182] [4.6/4.7/4.8 Regression] gcc can use registers but uses stack instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 --- Comment #11 from Denis Vlasenko 2013-01-20 14:39:42 UTC --- (In reply to comment #10) > 4.4.7 and 4.5.4 generate the same code (no stack use) for -D/-UNAIL_REGS. > With 4.6.3, the -DNAIL_REGS code regresses very much (IRA ...), the > -UNAIL_REGS code is nearly perfect but less good than 4.4/4.5 (if you > only consider grep esp serpent.s | wc -l). Same behavior with 4.7.2. > > Trunk got somewhat worse with -UNAIL_REGS but better with -DNAIL_REGS (at > -O2): > > -UNAIL_REGS -DNAIL_REGS > 4.5.4 3 3 > 4.6.315 101 This matches what I see with 4.6.3 - 15 insns with %esp (and no %ebp): $ grep '%esp' serpent-4.6.3-O2.asm 4: 83 ec 04sub$0x4,%esp 7: 8b 4c 24 20 mov0x20(%esp),%ecx b: 8b 44 24 18 mov0x18(%esp),%eax 22e: 89 0c 24mov%ecx,(%esp) 239: 23 3c 24and(%esp),%edi 588: 89 0c 24mov%ecx,(%esp) 58f: 23 3c 24and(%esp),%edi 8f4: 89 0c 24mov%ecx,(%esp) 8fd: 23 3c 24and(%esp),%edi c60: 89 0c 24mov%ecx,(%esp) c6b: 23 3c 24and(%esp),%edi d37: 89 14 24mov%edx,(%esp) d5a: 8b 44 24 1c mov0x1c(%esp),%eax d5e: 33 14 24xor(%esp),%edx d70: 83 c4 04add$0x4,%esp > The most important thing to fix is the -UNAIL_REGS case of course. Sure. NAIL_REGS is only a hack meant to demonstrate that regs *can* be allocated optimally.
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 Thomas Koenig changed: What|Removed |Added Attachment #29223|0 |1 is obsolete|| --- Comment #5 from Thomas Koenig 2013-01-20 14:55:50 UTC --- Created attachment 29225 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29225 Better patch This one is not yet symmetrical, but it does not cause regressions.
[Bug fortran/56052] New: [4.7/4.8 Regression] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 Bug #: 56052 Summary: [4.7/4.8 Regression] ICE in omp_add_variable, at gimplify.c:5606 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ja...@gcc.gnu.org As reported at http://gcc.gnu.org/ml/fortran/2013-01/msg00161.html the attached code ICE with 4.7.2 and trunk. This is a regression which occurred between revisions 181881 (2011-12-01, executable prints 'Correct') and 182076 (2011-12-07, ICE). Trunk at revision 195310 gives tst_openmp.f90: In function 'final': tst_openmp.f90:241:0: internal compiler error: in omp_add_variable, at gimplify.c:5894 select type (args)
[Bug fortran/56052] [4.7/4.8 Regression] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 --- Comment #1 from Dominique d'Humieres 2013-01-20 16:31:31 UTC --- Created attachment 29226 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29226 Failing test
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|middle-end |tree-optimization Target Milestone|--- |4.6.4
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 --- Comment #7 from Hubert Tong 2013-01-20 16:45:13 UTC --- (In reply to comment #6) > I wonder why you think this would belong to the "immediate context". Actually > it seems to me as if the instantiation of the body of a lambda expression is > similarly non-immediate as the instantiation of a class template. The body of a closure under N3290, forms a unique, singular "instance" which lexically eminates from the source location where the lambda expression occurs (by definition) and cannot be "instantiated" except by the presence of the lambda expression itself. That is, whether the "body" of the lambda expression is valid or not valid is not affected by unknowns such as what types it would be instantiated with or what names would be found if the lookup was moved to a different context.
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek 2013-01-20 16:46:04 UTC --- Created attachment 29227 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29227 gcc48-pr56051.patch Untested fix. As the testcase shows, also a widening conversion can be a problem, if it extends from signed integral type to wider unsigned one, because then for Y equal to bitsize of the narrower type - 1 we get more than one bit set. On the other side, the optimization doesn't hit when X isn't an ARRAY_REF, but just an integral variable, because then arg0 and arg1 are swapped. Guess for 4.9 we should handle those cases too.
[Bug tree-optimization/56053] New: FAIL: c-c++-common/asan/(global|stack)-overflow-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56053
Bug #: 56053
Summary: FAIL: c-c++-common/asan/(global|stack)-overflow-1.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: ja...@redhat.com, rguent...@suse.de
As reported in pr55679 comment #12, the tests
c-c++-common/asan/(global|stack)-overflow-1.c fail on x86_64-apple-darwin* with
optimization because the out of bound read is optimized out. Is the
optimization sound? If yes, why does not it occur for linux? If no, why does it
occur for darwin?
The tests pass with
/* { dg-options "-fno-builtin-memset -fno-tree-fre -fno-tree-pre" } */
[Bug tree-optimization/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56053 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-20 CC||howarth at bromo dot ||med.uc.edu Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2013-01-20 16:52:14 UTC --- I have forgotten to CC Jack Howarth.
[Bug fortran/56054] New: f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 Bug #: 56054 Summary: f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch gcc (4.8, 4.7, 4.6) ICEs on this invalid piece of code > cat small.f90 module kernels select type (args) end module kernels f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337 0x5ccc61 gfc_free_namespace(gfc_namespace*) ../../gcc/gcc/fortran/symbol.c:3337 0x5cd1df gfc_symbol_done_2() ../../gcc/gcc/fortran/symbol.c:3384 0x5899e8 gfc_done_2() ../../gcc/gcc/fortran/misc.c:267 0x596a0a clean_up_modules ../../gcc/gcc/fortran/parse.c:4416 0x59cec3 translate_all_program_units ../../gcc/gcc/fortran/parse.c:4486 0x59cec3 gfc_parse_file() ../../gcc/gcc/fortran/parse.c:4677 0x5da115 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:189 Please submit a full bug report,
[Bug fortran/56052] [4.7/4.8 Regression] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-20 Version|unknown |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2013-01-20 16:53:50 UTC --- Set the version.
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #20 from Dominique d'Humieres 2013-01-20 16:54:50 UTC --- (In reply to comment #18) > I am puzzled as to why this issue with global-overflow-1.c and > stack-overflow-1.c can't be triggered on x86_64 linux. The obvious change of > -mtune=core2 seems to be insufficient to cause the failures. I have opened pr56053 for these failures. This PR could probably be closed as fixed.
[Bug fortran/56052] [4.7/4.8 Regression] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #3 from Joost VandeVondele 2013-01-20 16:56:23 UTC --- reduced: subroutine middle(args) type args_t end type type, extends(args_t) :: scan_args_t end type class(args_t),intent(inout) :: args !$omp single select type (args) type is (scan_args_t) end select !$omp end single end subroutine middle
[Bug fortran/56052] [4.7/4.8 Regression] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Target Milestone|--- |4.7.3
[Bug fortran/56054] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-20 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2013-01-20 17:03:47 UTC --- Gfortran 4.5.3 gives pr56054.f90:2.24: select type (args) 1 Error: Selector shall be polymorphic in SELECT TYPE statement at (1) Revision 158253 (2010-04-13) gives the error; revision 162456 (2010-07-23) gives the ICE after error: pr56054.f90:2.24: select type (args) 1 Error: Unexpected SELECT TYPE statement in MODULE at (1) f951: internal compiler error: Segmentation fault Revision 163529 gives pr56054.f90:2.24: select type (args) 1 Error: Unexpected SELECT TYPE statement in MODULE at (1) f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3271
[Bug fortran/56054] [4.6/4.7/4.8 Regression] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 Dominique d'Humieres changed: What|Removed |Added Summary|f951: internal compiler |[4.6/4.7/4.8 Regression] |error: in |f951: internal compiler |gfc_free_namespace, at |error: in |fortran/symbol.c:3337 |gfc_free_namespace, at ||fortran/symbol.c:3337 --- Comment #2 from Dominique d'Humieres 2013-01-20 17:12:05 UTC --- Mark as a regression.
[Bug fortran/56054] [4.6/4.7/4.8 Regression] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin 2013-01-20 17:22:12 UTC --- Probable duplicate: PR50627
[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 --- Comment #10 from Mikael Morin 2013-01-20 17:31:24 UTC --- Created attachment 29228 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29228 Not working patch This patch implements comment #9. It fails on proc_decl* and proc_ptr* and cray_pointer_9 unfortunately. I investigated the last failure and the outcome is this: if the dummy arguments are not present in the procedure symbol, then the array spec and the character length shall be taken out of it as well, as they contain expressions that may refer to the dummy arguments. This makes the approach really too intrusive.
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2013-01-20 17:42:30 UTC --- Since http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193570 you need: --param max-completely-peeled-insns=129 to make this happen, as the defaults were lowered from 400 to 100.
[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730
--- Comment #8 from Mikael Morin 2013-01-20
17:47:34 UTC ---
(In reply to comment #7)
> Untested patch:
>
Probably better (still not fully correct):
diff --git a/array.c b/array.c
index 6787c05..1641629 100644
--- a/array.c
+++ b/array.c
@@ -1074,7 +1074,8 @@ gfc_match_array_constructor (gfc_expr **result)
/* Try to match an optional "type-spec ::" */
gfc_clear_ts (&ts);
- if (gfc_match_decl_type_spec (&ts, 0) == MATCH_YES)
+ m = gfc_match_decl_type_spec (&ts, 0);
+ if (m == MATCH_YES)
{
seen_ts = (gfc_match (" ::") == MATCH_YES);
@@ -1092,6 +1093,8 @@ gfc_match_array_constructor (gfc_expr **result)
}
}
}
+ else if (m == MATCH_ERROR)
+gfc_undo_symbols ();
if (! seen_ts)
gfc_current_locus = where;
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 --- Comment #8 from Hubert Tong 2013-01-20 17:50:50 UTC --- (In reply to comment #7) > That is, whether the "body" of the lambda expression is valid or not valid > is not affected by unknowns such as what types it would be instantiated with > or > what names would be found if the lookup was moved to a different context. I am referring to the case where the lambda is not inside a template declaration in the above. For the case where the lambda is in a template declaration, I believe that the properties I mentioned in comment #7 translate to the body of the lambda being within the "immediate context" of the instantiation when an instantiation of the enclosing template occurs.
[Bug fortran/50627] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Joost VandeVondele changed: What|Removed |Added Blocks||56054 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #5 from Joost VandeVondele 2013-01-20 18:08:20 UTC --- *** Bug 56054 has been marked as a duplicate of this bug. ***
[Bug fortran/56054] [4.6/4.7/4.8 Regression] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 Joost VandeVondele changed: What|Removed |Added Status|NEW |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Depends on||50627 Resolution||DUPLICATE --- Comment #4 from Joost VandeVondele 2013-01-20 18:08:20 UTC --- almost certainly a dup *** This bug has been marked as a duplicate of bug 50627 ***
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 --- Comment #4 from Marc Glisse 2013-01-20 18:09:40 UTC --- (In reply to comment #3) > Untested fix. As the testcase shows, also a widening conversion can be a > problem, if it extends from signed integral type to wider unsigned one, > because > then for Y equal to bitsize of the narrower type - 1 we get more than one bit > set. I assume this is because of the gcc extension documented as: "GCC does not use the latitude given in C99 only to treat certain aspects of signed `<<' as undefined, but this is subject to change." which prevents from assuming that 1<
[Bug fortran/50627] [4.6/4.7/4.8 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Joost VandeVondele changed: What|Removed |Added Summary|Error recovery: ICE in |[4.6/4.7/4.8 Regression] |gfc_free_namespace after|Error recovery: ICE in |diagnosing missing end of |gfc_free_namespace after |construct |diagnosing missing end of ||construct --- Comment #6 from Joost VandeVondele 2013-01-20 18:10:09 UTC --- The testcase in PR56054 shows the ICE is a regression wrt to 4.5
[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #8 from Ruben Van Boxem 2013-01-20 18:34:11 UTC --- I can confirm that this bug is present for GCC 4.8 dated 20121221, which is available here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.8-unstable/i686-w64-mingw32-gcc-4.8-unstable-win32_rubenvb.7z/download I get: lto1.exe: internal compiler error: cannot read LTO decls from R:\temp\ccgzHybZ.o Please submit a full bug report, with preprocessed source if appropriate. See for instructions. lto-wrapper: g++ returned 1 exit status m:/development/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe: lto-wrapper failed collect2.exe: error: ld returned 1 exit status
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 --- Comment #5 from Jakub Jelinek 2013-01-20 18:35:20 UTC --- Yeah, I'm afraid assuming you never do 1 << 31 is going to break simply way too much code in the wild.
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #5 from Damian Rouson 2013-01-20 18:59:54 UTC --- Hi Janus and Tobias, We're moving toward an internal release of the open-source package that exposed this bug. Any chance of this being fixed in the near future? The lead developer Karla Morris is cc'd on this. Damian
[Bug c++/55223] [C++11] Default lambda expression of a templated class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55223 --- Comment #2 from ak at gcc dot gnu.org 2013-01-20 19:03:29 UTC --- Author: ak Date: Sun Jan 20 19:03:22 2013 New Revision: 195321 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195321 Log: libstdc++: Add mem_order_hle_acquire/release to atomic.h v2 The underlying compiler supports additional __ATOMIC_HLE_ACQUIRE/RELEASE memmodel flags for TSX, but this was not exposed to the C++ wrapper. Handle it there. These are additional flags, so some of assert checks need to mask off the flags before checking the memory model type. libstdc++-v3/: 2013-01-12 Andi Kleen Jonathan Wakely PR libstdc++/55223 * include/bits/atomic_base.h (__memory_order_modifier): Add __memory_order_mask, __memory_order_modifier_mask, __memory_order_hle_acquire, __memory_order_hle_release. (operator|,operator&): Add. (__cmpexch_failure_order): Rename to __cmpexch_failure_order2. (__cmpexch_failure_order): Add. (clear, store, load, compare_exchange_weak, compare_exchange_strong): Handle flags. * testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc: Add. Added: trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_base.h
[Bug target/55433] [4.8 Regression][LRA] ICE on excessive reloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433 --- Comment #7 from Vladimir Makarov 2013-01-20 19:10:03 UTC --- Author: vmakarov Date: Sun Jan 20 19:09:58 2013 New Revision: 195322 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195322 Log: 2013-01-20 Vladimir Makarov PR target/55433 * lra-constraints.c (curr_insn_transform): Don't reuse original insn for secondary memory move when memory mode should be different. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug c++/55223] [C++11] Default lambda expression of a templated class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55223 --- Comment #3 from Daniel Krügler 2013-01-20 19:56:22 UTC --- (In reply to comment #2) > The underlying compiler supports additional __ATOMIC_HLE_ACQUIRE/RELEASE > memmodel flags for TSX, but this was not exposed to the C++ wrapper. > Handle it there. I'm confused: This comment seems not to match to the issue problem. Could it be that it should refer to another issue?
[Bug c++/55223] [C++11] Default lambda expression of a templated class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55223 --- Comment #4 from Jonathan Wakely 2013-01-20 20:04:30 UTC --- Typo in the commit, it should be PR 55233
[Bug libstdc++/55233] libstdc++ atomic does not support hle_acquire/release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55233 --- Comment #1 from Jonathan Wakely 2013-01-20 20:05:03 UTC --- N.B. The commit for this is attached to PR 55223
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 --- Comment #6 from Marc Glisse 2013-01-20 20:17:31 UTC --- (In reply to comment #5) > Yeah, I'm afraid assuming you never do 1 << 31 is going to break simply way > too > much code in the wild. I noticed that clang warns for 1 << 31, and with -fsanitize=shift tells you if there is 1<
[Bug debug/53235] [4.8 Regression] 20120504 broke -fdebug-types-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235 --- Comment #14 from mrs at gcc dot gnu.org 2013-01-20 20:35:56 UTC --- Author: mrs Date: Sun Jan 20 20:35:48 2013 New Revision: 195326 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195326 Log: 2013-01-20 Jack Howarth PR debug/53235 * g++.dg/debug/dwarf2/nested-4.C: XFAIL on darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-4.C
[Bug fortran/56047] [4.8 Regression] [OOP] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 --- Comment #12 from Jürgen Reuter 2013-01-20 22:11:30 UTC --- Am 20/1/13 1:53 PM, schrieb janus at gcc dot gnu.org: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 > > --- Comment #11 from janus at gcc dot gnu.org 2013-01-20 12:53:40 UTC --- > (In reply to comment #9) >> Janus, long time no see! XD > Right! It's been a while since you submitted a bugreport (after all the > procedure pointer bugs had been fixed) ... Ja, es war lange nichts mehr noetig XD Und auch mit einem anderen Account. (uni freiburg adresse). naja, ich war ja Juniorprofessor in Freiburg, aber nur befristet, und bin jetzt am DESY in Hamburg auf einer permanenten Stelle. Mittlerweile existiert der Freiburger Account nicht mehr, aber manche Sachen hab ich halt vergessen umzustellen. > Are you also jumping on the polymorphic bandwagon now? Ja, allerdings, es macht die Umstrukturierung unseres Programms wesentlich einfacher. Und ich kaempfe immer wieder gegen Leute an, die die Standard-Phrase verwenden: "old-fashioned programming like Fortran ... " >> Greetings to my old home state! > I guess you're referring to the state of Hessen? (IIRC, you mentioned that you > studied in Darmstadt, right?) Ja, allerdings, genau. Henrik van Hees, den du glaub ich ganz gut kennst, war dort mein Tutor in Ana I+II und Theo I XD Ciao, JRR
[Bug rtl-optimization/51447] [4.6/4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
||med.uc.edu
--- Comment #16 from Jack Howarth 2013-01-20
22:18:04 UTC ---
The test case gcc.c-torture/execute/pr51447.c fails its execution test at -m32
(but not -m64) on x86_64-apple-darwin12 in gcc trunk. Adding -fno-PIC to the
compile flags eliminates the execution failure at all optimization levels for
-m32 on x86_64-apple-darwin12.
# gdb ./pr51447.x0
GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug 5 03:00:42 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries ... done
(gdb) b main
Breakpoint 1 at 0x1eed: file
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130120/gcc/testsuite/gcc.c-torture/execute/pr51447.c,
line 13.
Breakpoint 2 at 0x1ec8: file
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130120/gcc/testsuite/gcc.c-torture/execute/pr51447.c,
line 18.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) disp/i $pc
(gdb) r
Starting program:
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/gcc/pr51447.x0
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries ++. done
Breakpoint 1, 0x1eed in main () at
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130120/gcc/testsuite/gcc.c-torture/execute/pr51447.c:13
13{
1: x/i $pc 0x1eed :call 0x1f3e <__x86.get_pc_thunk.bx>
(gdb) si
0x1f3e in __x86.get_pc_thunk.bx ()
1: x/i $pc 0x1f3e <__x86.get_pc_thunk.bx>:mov(%esp),%ebx
(gdb)
0x1f41 in __x86.get_pc_thunk.bx ()
1: x/i $pc 0x1f41 <__x86.get_pc_thunk.bx+3>:ret
(gdb)
0x1ef2 in main () at
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130120/gcc/testsuite/gcc.c-torture/execute/pr51447.c:13
13{
1: x/i $pc 0x1ef2 :lea-0x18(%ebp),%eax
(gdb)
0x1ef513{
1: x/i $pc 0x1ef5 :mov%eax,-0x24(%ebp)
(gdb)
0x1ef813{
1: x/i $pc 0x1ef8 :mov%esp,-0x20(%ebp)
(gdb)
21 bar (&&nonlocal_lab);
1: x/i $pc 0x1efb :lea-0x24(%ebp),%eax
(gdb)
0x1efe21 bar (&&nonlocal_lab);
1: x/i $pc 0x1efe :lea0x26(%ebx),%edx
(gdb)
0x1f0421 bar (&&nonlocal_lab);
1: x/i $pc 0x1f04 :mov%edx,(%esp)
(gdb)
0x1f0721 bar (&&nonlocal_lab);
1: x/i $pc 0x1f07 :mov%eax,%ecx
(gdb)
0x1f0921 bar (&&nonlocal_lab);
1: x/i $pc 0x1f09 :call 0x1ebd
(gdb)
bar (func=0x1f18) at
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130120/gcc/testsuite/gcc.c-torture/execute/pr51447.c:17
17 {
1: x/i $pc 0x1ebd :push %ebp
(gdb)
0x1ebe17 {
1: x/i $pc 0x1ebe :mov%esp,%ebp
(gdb)
0x1ec017 {
1: x/i $pc 0x1ec0 :push %ebx
(gdb)
0x1ec117 {
1: x/i $pc 0x1ec1 :call 0x1f3e <__x86.get_pc_thunk.bx>
(gdb)
0x1f3e in __x86.get_pc_thunk.bx ()
1: x/i $pc 0x1f3e <__x86.get_pc_thunk.bx>:mov(%esp),%ebx
(gdb)
0x1f41 in __x86.get_pc_thunk.bx ()
1: x/i $pc 0x1f41 <__x86.get_pc_thunk.bx+3>:ret
(gdb)
0x1ec6 in bar (func=0x1f18) at
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130120/gcc/testsuite/gcc.c-torture/execute/pr51447.c:17
17 {
1: x/i $pc 0x1ec6 :mov%ecx,%edx
(gdb)
Breakpoint 2, bar (func=0x1f18) at
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130120/gcc/testsuite/gcc.c-torture/execute/pr51447.c:18
18ptr = func;
1: x/i $pc 0x1ec8 :lea0x142(%ebx),%eax
(gdb)
0x1ece18ptr = func;
1: x/i $pc 0x1ece :mov(%eax),%eax
(gdb)
0x1ed018ptr = func;
1: x/i $pc 0x1ed0 :mov0x8(%ebp),%ecx
(gdb)
0x1ed318ptr = func;
1: x/i $pc 0x1ed3 :mov%ecx,(%eax)
(gdb)
19goto nonlocal_lab;
1: x/i $pc 0x1ed5 :mov%edx,%eax
(gdb)
0x1ed719goto nonlocal_lab;
1: x/i $pc 0x1ed7 :lea0x4f(%ebx),%edx
(gdb)
0x1edd19goto nonlocal_lab;
1: x/i $pc 0x1edd :mov (%eax),%ebp
(gdb)
0x1edf in bar (func=0xb8e0) at
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130120/gcc/testsuite/g
[Bug ada/56055] New: Delete_File won't delete special files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56055 Bug #: 56055 Summary: Delete_File won't delete special files Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: bj...@xn--rombobjrn-67a.se According to the Ada Reference Manual, Ada.Directories.Delete_File "deletes an existing ordinary or special file", that is any kind of file except a directory. Libgnat's implementation refuses to delete a socket (at least on GNU/Linux), claiming falsely that the socket doesn't exist. A more correct approach would be to check first that the file isn't a directory, then call unlink, and if unlink fails then check errno to see whether Name_Error or Use_Error should be raised. (To really do the right thing, fetch the error string with strerror_r and include it in the exception message.) Looking through a-direct.adb I see that several subprograms call Is_Regular_File, and I suspect that most of them will fail in the presence of special files. Rename for example should probably call File_Exists instead of Is_Regular_File and Is_Directory.
[Bug libstdc++/55233] libstdc++ atomic does not support hle_acquire/release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55233 --- Comment #2 from Andi Kleen 2013-01-21 01:22:14 UTC --- Oops typo, I'll fix the ChangeLog
[Bug c++/56056] New: internal compiler error: in get_builtin_code_for_version, at config/i386/i386.c:28686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56056
Bug #: 56056
Summary: internal compiler error: in
get_builtin_code_for_version, at
config/i386/i386.c:28686
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: crrodrig...@opensuse.org
cat countleadingzeros.cpp
#include
#include
#include
int foo (unsigned int x)
{
// The default version of foo.
return __builtin_clz(x);
}
// note, invalid attribute
__attribute__ ((target ("march=core-avx2")))
int foo (unsigned int x)
{
return __builtin_clz(x);
}
int main(void)
{
srand(time(NULL));
return foo(rand());
}
g++-4.8 countleadingzeros.cpp
countleadingzeros.cpp:12:24: error: attribute(target("march=core-avx2")) is
unknown
int foo (unsigned int x)
^
countleadingzeros.cpp: In function ‘int main()’:
countleadingzeros.cpp:21:22: error: attribute(target("march=core-avx2")) is
unknown
return foo(rand());
^
countleadingzeros.cpp:21:22: internal compiler error: in
get_builtin_code_for_version, at config/i386/i386.c:28686
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug other/56057] New: libbacktrace STILL doesn't honor --disable-werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56057 Bug #: 56057 Summary: libbacktrace STILL doesn't honor --disable-werror Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: lailavrazda1...@gmail.com libbacktrace is not honoring --disable-werror and using -fPIC, causing a warning (which is promoted to an error) when building a native compiler for x86_64-w64-mingw32. This happens with revision 195330, the latest, as of this writing. Errors below: libtool: compile: x86_64-w64-mingw32-gcc -L/root/win64-build/native/x86_64-w64-mingw32/lib -L/root/win64-build/native/mingw/lib -isystem /root/win64-build/native/x86_64-w64-mingw32/include -isystem /root/win64-build/native/mingw/include -DHAVE_CONFIG_H -I. -I../../../gcc-4.8.0/libbacktrace -I ../../../gcc-4.8.0/libbacktrace/../include -I ../../../gcc-4.8.0/libbacktrace/../libgcc -I ../libgcc -funwind-tables -frandom-seed=dwarf.lo -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -fPIC -g -O2 -c ../../../gcc-4.8.0/libbacktrace/dwarf.c -o dwarf.o ../../../gcc-4.8.0/libbacktrace/dwarf.c:1:0: error: -fPIC ignored for target (all code is position independent) [-Werror] /* dwarf.c -- Get file/line information from DWARF for backtraces. ^ cc1: all warnings being treated as errors make[3]: *** [dwarf.lo] Error 1 make[3]: Leaving directory `/root/win64-build/src/gcc-build/x86_64-w64-mingw32/libbacktrace' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/win64-build/src/gcc-build/x86_64-w64-mingw32/libbacktrace' make[1]: *** [all-target-libbacktrace] Error 2 make[1]: Leaving directory `/root/win64-build/src/gcc-build' make: *** [all] Error 2
[Bug c/55819] Conflicting declaration of getcwd breaks mingw-w64 compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55819 lailavrazda1979 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from lailavrazda1979 at gmail dot com 2013-01-21 05:28:14 UTC --- Seems to work now, strangely. Must have been an issue with my setup.
[Bug target/56058] New: GCC arm-none-eabi build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56058 Bug #: 56058 Summary: GCC arm-none-eabi build failure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amker.ch...@gmail.com I configured the gcc with: ../gcc/configure --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-none-eabi --prefix=... --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-lto --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-sysroot=... --with-gmp=... --with-mpfr=... --with-mpc=... --with-ppl=... --with-cloog=... --with-libelf=... --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-languages=c,c++ And it failed with message: build/gengtype \ -S ../../gcc/gcc -I gtyp-input.list -w tmp-gtype.state /bin/sh ../../gcc/gcc/../move-if-change tmp-gtype.state gtype.state build/gengtype \ -r gtype.state echo timestamp > s-gtype build/genattrtab ../../gcc/gcc/config/arm/arm.md insn-conditions.md \ -Atmp-attrtab.c -Dtmp-dfatab.c -Ltmp-latencytab.c genattrtab: unknown value `alu' for `type' attribute make[1]: *** [s-attrtab] Error 1 make[1]: Leaving directory `/home/binche01/work/gcc-patches/arm-none-eabi/trunk-scan_one_insn/build/gcc' make: *** [all-gcc] Error 2 It works if I revert r195295
[Bug c++/56059] New: SIGSEGV on invalid C++11 code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56059 Bug #: 56059 Summary: SIGSEGV on invalid C++11 code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 29229 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29229 Backtrace
[Bug c++/56060] New: ICE on invalid code in type_dependent_expression_p, at cp/pt.c:19742
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56060 Bug #: 56060 Summary: ICE on invalid code in type_dependent_expression_p, at cp/pt.c:19742 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 29230 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29230 Backtrace
[Bug lto/56061] New: [4.8 Regression] ICE in lto1 (in inline_call, at ipa-inline-transform.c:267)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56061 Bug #: 56061 Summary: [4.8 Regression] ICE in lto1 (in inline_call, at ipa-inline-transform.c:267) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 29231 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29231 Testcase GCC 4.8.0 20130120 (experimental). lto1: internal compiler error: in inline_call, at ipa-inline-transform.c:267 0x8367899 inline_call(cgraph_edge*, bool, vec*, int*, bool) ../../gcc-4.8/gcc/ipa-inline-transform.c:263 0x8357d10 inline_small_functions ../../gcc-4.8/gcc/ipa-inline.c:1613 0x835817f ipa_inline ../../gcc-4.8/gcc/ipa-inline.c:1794 Please submit a full bug report,
[Bug c++/56059] SIGSEGV on invalid C++11 code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56059 --- Comment #1 from Dmitry Gorbachev 2013-01-21 06:31:18 UTC --- Created attachment 29232 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29232 Testcase
[Bug c++/56060] ICE on invalid code in type_dependent_expression_p, at cp/pt.c:19742
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56060 --- Comment #1 from Dmitry Gorbachev 2013-01-21 06:31:59 UTC --- Created attachment 29233 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29233 Testcase
[Bug c++/56059] SIGSEGV on invalid C++11 code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56059 Dmitry Gorbachev changed: What|Removed |Added Keywords||ice-checking, ||ice-on-invalid-code Known to fail||4.7.3, 4.8.0 --- Comment #2 from Dmitry Gorbachev 2013-01-21 06:37:21 UTC --- Also happens in ver. 4.7.3 with checks enabled.
[Bug c++/56059] [4.7/4.8 Regression] SIGSEGV on invalid C++11 code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56059 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-21 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.7.3 Summary|SIGSEGV on invalid C++11|[4.7/4.8 Regression] |code|SIGSEGV on invalid C++11 ||code Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek 2013-01-21 06:53:27 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189298
[Bug c++/56060] ICE on invalid code in type_dependent_expression_p, at cp/pt.c:19742
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56060 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2013-01-21 06:56:14 UTC --- Seems to be very old, started in between r126000 and r127000.
[Bug driver/56062] New: Enhance -fuse-ld= option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56062 Bug #: 56062 Summary: Enhance -fuse-ld= option Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Currently, GCC supports options -fuse-ld=bfd and -fuse-ld=gold only. It could be generalized. For example, -fuse-ld=hjl would use a linker called ld.hjl.
